Ok,

I use Pim's vfdhack to rsync-2.5.5 and ext3. I compiled up hijack 312 with ext3 on (only 309 was avaialble at the time for download) and today when I ran rsync I got a nasty little oops.

So, I downloaded the 'proper' ext3 version of hijack 313 (now its available) and it did the same thing (at least I know my 312 build wasn't the problem).

So I downloaded the real hijack 314 and that doesn't have the problem. So it seems somewhere from ext3-301 to ext3-313 something bad has happened.

Anyway, I'm attaching the oops info if anyone could help.

The Oooops was in the ext3 filesystem code, so I am ignoring it.l

And peaking of receng kernels.. Hijack v314 incorrectly identifies itself as v313.

Fixed in v315, out shortly.

-ml

The Oooops was in the ext3 filesystem code, so I am ignoring it

I'll try to take a look at it this weekend. Andy, can you give me as many details as possible so I can try to reproduce it. Does it happen everytime? At what point in the rsync does it happen, etc? Is the player running at the same time? Can you try it with version 303 and/or version 309 to see if you can narrow down where it broke.

-Mike

Mike,

It happened about 7 times with 312 (which I compiled) and then again when I tried your 313. It always happened at exactly the same place in the rsync (somewhere in /drive0/fids/_00014) but I didn't take note of where (bad me).

I had stopped the player app first and had swap on both discs. I also was telnet'ed in rather than running it on the console via hyperterm.

After installing the non modified 314, it rsync'ed ok (guess I could have just mounted them as ext2). Anyway, I then loaded the ext3-313 and it didn't oops, but it didn't have to rsync.

My other empeg is on ext3 version of 302 (I think) and needs rsync'ing anyway. So, I'll do some experimenting with that one over the weekend and let you know.

I don't have the ext3 versions of 303 or 309, so unless you've got a copy or Mark has the patch source so I can build it, I'll be unable to try it.

I don't have the ext3 versions of 303 or 309

Mike put links to them in his post... (The bold orange "version 303" and "version 309")

/Michael

in the words of Homer Simpson 'DOH!'

Mike,

been doing some more testing, and since the problem stopped occuring not using ext3, I can't make it happen again using ext3.

Tried a number of things. Mainly forcing it to sync the directory that it was having problems with.

Anyway, should it occur again, I'll test it on all the kernels I've got (302,303,309,312,313).

Btw, I did even force a full fsck and it even oops'ed after that.

My 2nd empeg is currently rsyncing. However that will take a number of hours before it gets to the problem place).

My 2nd empeg is currently rsyncing. However that will take a number of hours before it gets to the problem place).

OK, let me know how it goes. I'll get rsync setup on my spare player (I have been meaning to play with that anyway) and see if I can reproduce it. When the problem was occuring did you ever fully reboot the player? I am wondering if something got screwed up in a buffer somewhere that got cleared out after a reboot (when you installed the stock hijack) which might explain why it is behaving fine now.

-Mike

Mike,

I had to power cycle the empeg as you couldn't mount/umount any of the ext3 filesystems. ext3 wasn't very happy.

Btw, using Pim's mp2tofid as well obviously.

So far the 2nd empeg is syncing ok.

So far the 2nd empeg is syncing ok.

I just rsynced almost 4gigs to my empeg with hijack 313/ext3 with no problems (by the way, props to the mp3tofid/rsync maintainer that worked beautifully). Unless you can find a way to reproduce the Oops I am inclined to call it a one time fluke. Although, it wouldn't surprise me at all if there are some bugs floating around in the ext3 code still as it hasn't been maintained for the 2.2 kernel for quite some time.

-Mike

Mike,

I tend to agree, even though it did it half a dozen times. This time I was more concerned about find out where the problem was. So should it occur again I won't fix it and we can see what we can find.

I've tried searching for this, but can't find out why v315 is listed as 'Never released' on the Hijack web page.

This wouldn't, of course, bother me, except that whenever I last updated Hijack automatically with JEmplode, it somehow managed to download v315 and install it on my player. Am I special? Does anyone else have this version?

Mike,

Good news (depending on your point of view). I've just had another oops in do_get_write_access(). Well had a lot actually. I added a new album, ran Pim's mp3tofid on my linux box and then started the rsync. It's oops'ed 3 times so far.

I tried to move the problem files out of the way on the linux server (moved 2 so far) and it still oops'ed. I'm sure if I remove the entire album it will be ok.

The oops is at the same point as the last one. I'm attaching the output.

I removed 3 files (ok symlinks) from my linux server and it sync'ed ok.

./drive0/fids/_00014/080 090 0a0

Putting them back didn't cause the problem to re-occur which is slightly annoying.

Good news (depending on your point of view)

We obviously have different points of view ;-)

It is going to be a few days before I can look into this as my server/build machine melted down last weekend and I haven't got it fixed yet. If you don't want to wait for me you can try grabbing the stock linux kernel source version 2.2.20 and the ext3-0.0.7a patch. Patch the 2.2.20 source and then diff transaction.c from it with the version from a recent hijack patched empeg kernel. Or try to compile an empeg kernel with the newer transaction.c you patched. Perhaps I screwed up something with all the patches I had to hack in by hand to get ext3 working against the older empeg kernel source.

If you didn't follow that give me a couple of days and I'll try to take a look myself

-Mike

Mike, I'm on call this weekend, so depending on customers I'll give it a try. I just added 3 new cd's to my empeg and it happened again. Just rsyncing my other player (which hasn't been synced for a while) and its going fine (at least so far). As both players are on the same setup as far as s/w is

concerned, although they have different disc sizes and therefore I used mp3tofid with different options to different directories, but I might just reinstall the problem one if the other machine sync's ok.

I'll let you know how I get on over the weekend with the patch.

Just rsyncing my other player (which hasn't been synced for a while) and its going fine (at least so far).

Have you ever had an Oops with that second player? I am just wondering if maybe one of the drives in the first player is a little flakey since AFAIK nobody else has had this problem.

-Mike

The 2nd player has just finished sync'ing. No problems with it.

As for a flakey drive I guess that is possible. I'll leave a dd of the drive running over night to see if that finds anything. The last 2 oops have both been on drive0. I can't remember where the original one was. I thought it was drive1, but I can't be sure so it is possible.