Greetings!

While copying files from the old hard drives to the new ones, I noticed that on the Mark2A I would receive an error, but would not on the Mark2. Both are running 20b7, brand new hard drives with builder. It looks almost like a memory error. I would not have bothered with it, but I was able to reproduce it on two different target Mark2As.

I really don't need this resolved. I was curious if someone else knew if it was a problem and what it meant. I was able to load everything, after rebuilding the target hard drive and turning swap on before executing the copy batch file.

-=-=-

From a "cp -v /drive1/fids/1* /drive0/fids" (I needed to break it down because of the number of files...)

[snip]
/drive1/fids/12dc1 -> /drive0/fids/12dc1
cp: /drive0/fids/12dc1: Invalid argument
/drive1/fids/12dd0 -> /drive0/fids/12dd0
Unable to handle kernel paging request at virtual address c1001ae0
memmap = C0984000, pgd = c0984000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: 2
CPU: 0
pc : [<c0045254>] lr : [<c0045234>]
sp : c0a43e18 ip : 00000001 fp : 00000000
r10: 02002013 r9 : c0fd6820 r8 : c0a43e30
r7 : 00001001 r6 : c0ffda00 r5 : 00000012 r4 : c0a43e30
r3 : c0ffdadc r2 : 00000000 r1 : 00002000 r0 : 00000012
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: C098517D Table: C098517D DAC: 00000015
Process cp (pid: 42, stackpage=c0a43000)
Stack:
c0a43e00: c0045234 c0045254 60000013 ffffffff 00000400 c0ffda30
c0a43e20: c0ff9000 c0daaba0 c0daaba4 c0031670 c0fdfd20 02002013 c0daaaa0 c0a43eec
c0a43e40: 02002013 c0daab5c 00000008 00000008 c0047d0c c0a43eec 00000000 c0daaaa0
c0a43e60: 00000008 c0048008 00000002 00000001 00000100 c0daaaa0 00000008 00000008
c0a43e80: c0a43eec 00000008 00000001 c0048464 c0a43eec c001dbdc c00153f0 00000010
c0a43ea0: c0daaaec 00000400 ffffffea c0daaaa0 bffe6bc4 00001000 00002000 c0046574
c0a43ec0: bffe77c4 c0a43eec 00000000 00000000 c0ffda00 00000000 00000000 00000008
c0a43ee0: c0f9ab74 c0f9ab60 c0c631e0 ffffffe4 0000a000 c0fa2660 00000000 00000140
c0a43f00: c0a43f14 c0024ba0 c00e52f0 20000013 ffffffff 00001000 00001000 c0a43f78
c0a43f20: 00001000 c014afc8 c0f9abc0 00000000 00000000 c0fa2660 c0024b74 0001f000
c0a43f40: 00000000 00000001 00003000 c0024b7c c0a43f78 c0f9abd4 bffe6bc4 c0f9abd4
c0a43f60: 00000000 00001000 bffe6bc4 00000004 c0daaaec c0f9ab60 ffffffea 00000000
c0a43f80: 00001000 00000004 bffe6bc4 c002f7b0 c002f65c c0309f00 00000000 c000a0e8
c0a43fa0: 00000004 c0a42000 c0a43ff4 00000000 c0009f40 00000000 00000004 bffe6bc4
c0a43fc0: 00001000 00001000 00000000 00001000 bffe6bc4 00000000 00000004 00000004
c0a43fe0: 00000000 bffe6bbc 02010260 bffe6b9c 020055f4 400aceb4 20000010 00000004
Backtrace: no frame pointer
Code: 1a000004 e28630dc (e7932107) e3520000 13a00000
./copy.sh: line 2: 42 Segmentation fault cp -v /drive1/fids/1* /drive0/fids
/drive1/fids/200 -> /drive0/fids/200

The traceback is useless without the System.map file from kernel build time.. so if you want to install a Hijack kernel and do it again, then we will be able to diagnose (and maybe fix) the kernel bug you are seeing (since I have the map files for the more recent Hijack kernels).

Cheers

Totally tangential, but I've been meaning to find out. I infer from your post, Mark, that System.map is a map to the symbols in the kernel binary (Edit: which would have been obvious if I'd ever looked at the file, something I can't believe I never did in the last ten years). Is it useful for anything else? I've always really meant to find out, but never bothered, and now seems like as good a time as any, since we have an expert on hand.

The System.map is just a list of public symbols (mostly functions) from the kernel. It used to be used as the basis for the kernel module loader, prior to the introduction of /proc/ksyms (hey, maybe that exists on the empeg.. gotta check).

So when you load a "kernel module", the System.map or /proc/ksyms are what are used by the loader to map references for things like "kmalloc()" to the actual code for the module being loaded.

Debuggers (kadb) also rely on those.

Apart from that, they're mostly just a waste of space.

Cheers

Greetings!

Would I need to have the map files on the empeg as the error occurs? I have already loaded both of the players (adding the swap seemed to help), so I do not believe I will get to it anytime soon. But it is something I will test going forward. Do you think it might be a good idea to add turning swap on for the disk upgrade FAQ?

Meanwhile, the 120GB combination is working very well!

No, there is no need for the .map files to be on the player. They just need to be available, in order to figure out what died and when.

Also, it should NOT be necessary to have swap enabled to do drive copies.. but if there's a small memory leak in the copy program ("cp" ??) then it might run out of physical ram over a (did you say) 90GB copy of 10000-15000 files.. so it looks like swap on might be a good thing here (it would never be a BAD thing for cloning).

cheers

Cool! Next time I mess with bulk copies (probably when I start experimenting with mp3tool variations), I will do some testing there as well. As to the number of files, approximately 15,000 per drive, assuming fid files and mp3 files evenly distributed.

The command I used was "cp -v /driveA/fids/X* /driveB/fids" where A & B are drive numbers (specific for direction of copy) and X is the first digit of the fids. I needed to write a batch and break down the copy because of a cp error (too many files at one time).

The odd thing is that it only happened on the Mark2A, not the Mark2. I would suspect, given identical kernels, that it would fail first on the Mark2 with less physical memory. Unless there was something specific about the source hard drive that the files were being copied from that was the issue.

Greetings!

I was doing some file manipulation on the empeg today, and ran into similar problems (segment faults) with the "rm" command. This was with swap enabled and with hijack 188 loaded. I loaded the original developer kernel, and I no longer have the problem. The error dump is below. I know that you have the map files for this, so it might be of some help. If you need any additional information, please let me know.

-=-=-
empeg:/drive0/mirror/empeg-car/Alphabetical# rm -rf P
Unable to handle kernel paging request at virtual address c1000008
memmap = C0834000, pgd = c0834000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: 2
CPU: 0
pc : [<c0044f9c>] lr : [<c0044f64>]
sp : c05b1f00 ip : 00000001 fp : 00000000
r10: 00000003 r9 : c0ff5000 r8 : 03296003
r7 : 0000194b r6 : c0ff9a00 r5 : 00002000 r4 : 03296002
r3 : c0ff9adc r2 : 00000000 r1 : 00002000 r0 : 00000002
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: C083517D Table: C083517D DAC: 00000015
Process rm (pid: 35, stackpage=c05b1000)
Stack:
c05b1ee0: c0044f64 c0044f9c 60000013 ffffffff
c05b1f00: c0ff9a00 c0ff9a30 00000000 00000002 c064b440 c08c9430 c064b3e0 c08c9430
c05b1f20: 0329600e 00000009 000000a8 03296003 00000003 c004cdfc 00000002 00000000
c05b1f40: c08c9430 c08c9430 00000000 c08c9500 c08c94fc 0200d7cc c012df98 c004d4c8
c05b1f60: c08c9430 c08c9430 c08c9430 00000000 c0777000 c05b1ff4 0200d7f8 c0047d14
c05b1f80: c010a4c4 c0040444 c0f9d4e0 c0f9dde0 c003e548 c0f9d4e0 c0f9dde0 c0039954
c05b1fa0: ffffffe9 c000a108 00000028 c05b0000 c0009f60 ffffffe9 bffff8c0 00000000
c05b1fc0: 0200ea48 00000000 ffffffe9 0200d7f8 0200d7cc bffff8c0 bffffd68 0200d7cc
c05b1fe0: 0200d7f8 bffff918 400ae610 bffff8bc 0200273c 400ae614 20000010 bffff8c0
Backtrace: no frame pointer
Code: 1a000004 e28630dc (e7932107) e3520000 13a02000
Segmentation fault
-=-=-

Assuming that was a "Mk2" unit, the crash happened in the ext2 filesystem code, in "ext2_free_blocks()". Since the virtual address was nothing like "null", I think it may have died due to a kernel bug -- ext2 needed a page from the swapfile, which is stored on ext2.. a virtual loop that cannot be satisfied.

This is a bug that would be in the standard kernel as well as the hijack kernel, and is probably fixed in newer versions of the 2.2 kernel series.

Pure luck that it happened with Hijack running. It could just as easily happen with swap activity with the stock kernel.

Cheers

-ml

Mmm. Shouldn't be, the swapfile hasn't been on the ext2 partition since... well, before 1.00 anyway as far as I can remember. /dev/hda6 is a swap parition for that reason.

Hugo

Greetings!

Well, I put the normal kernel in place, and I was able to do my disk changes. I reloaded hijack and am running fine now. I know I have seen similar issues without hijack loaded, so there might be an intermittent problem somewhere.

If it is of any help, after the error, any command that I executed, no matter how tame (i.e., "ls") locked the empeg. If you need any testing or debugging assistance (short of mailing the unit to the UK), let me know.

I just want to bring any strangeness to your (collective) attention because I tend to be bleeding edge with disk. Others will follow...