Not sure exactly when this happened. I applied the latest patch, used the UDF setup tools and copied a small-ish (1-200k) file to the mounted cd. Some time later I noticed this Oops in the serial console@ __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? Incorrect segment count at 0xc01c3c91nr_segments is a counted segments is 8 Flags 1 0 Segment 0xc3c768c0, blocks 4, addr 0xef9fff Segment 0xc11468a0, blocks 4, addr 0xefa7ff Segment 0xc2da02a0, blocks 4, addr 0x2b2cfff Segment 0xc2490b60, blocks 4, addr 0x2b2d7ff Segment 0xc2177760, blocks 4, addr 0x46dfff Segment 0xc246e920, blocks 4, addr 0x46e7ff Segment 0xc2abd8c0, blocks 4, addr 0xd69fff Segment 0xc28b58c0, blocks 4, addr 0xd6a7ff Segment 0xc32e6ce0, blocks 4, addr 0x2fdafff Segment 0xc24a9660, blocks 4, addr 0x2fdb7ff Segment 0xc336c8e0, blocks 4, addr 0xfcbfff Segment 0xc2c40860, blocks 4, addr 0xfcc7ff Segment 0xc036b320, blocks 4, addr 0x2bf4fff Segment 0xc25e4920, blocks 4, addr 0x2bf57ff Segment 0xc2c307c0, blocks 4, addr 0x3e2dfff Kernel panic: Ththththaats all folks. Too dangerous to continue. bh timed out: sector 10236 dev/rdev 0b:00/0b:00, count 2, state 1c, end_io c4839460, private c05e5000, list 137 scsi0:0:3:0: Attempting to queue an ABORT message scsi0:0:3:0: Command found on device queue aic7xxx_abort returns 8194 rq->cmd=1, rq->sector=10188, rq->nr_sectors=52 kernel BUG at pktcdvd.c:1086! invalid operand: 0000 CPU: 0 EIP: 0010:[<c483a55b>] EFLAGS: 00010082 eax: 0000001e ebx: 000027cc ecx: c2778000 edx: c02af1e4 esi: 00000034 edi: c09b1500 ebp: c11fd600 esp: c0e51f68 ds: 0018 es: 0018 ss: 0018 Process pktcdvd0 (pid: 1224, stackpage=c0e51000) Stack: c483c1d4 c483c350 0000043e 00000282 00000003 00000009 c05e511c c05e5000 00000007 c09b1500 c031d480 c0e50000 c05e5120 c05e5120 c0e50000 c0e50000 c05e5074 c05e5000 c11fd618 c483a394 c05e5074 c05e509c 00000000 c0e50000 Call Trace: [<c483c1d4>] [<c483c350>] [<c483a394>] [<c01074a6>] [<c483a280>] Code: 0f 0b 83 c4 0c 8d 54 24 20 bb 00 e0 ff ff 8d 85 1c 01 00 00 The result of decoding the Oops is:
EIP; c483a55b
Trace; c483a280 : Code; c483a55b
There were also lots of messages like this: bh timed out: sector 10120 dev/rdev 61:00/61:00, count 1, state 1d, end_io c017fbb0, private 00000000, list 1 Hope this is useful. Adam
On Mon, Mar 26, 2001 at 12:11:30AM +0100, Adam Huffman wrote:
Not sure exactly when this happened. I applied the latest patch, used the UDF setup tools and copied a small-ish (1-200k) file to the mounted cd. Some time later I noticed this Oops in the serial console@
__refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move? __refile_buffer: rdev is packet, should move?
These are caused by the wierd buffer changes I don't understand =) I tried reverting buffer.c back to the 2.4.2 version and it didn't seem to directly cause any problems. I copied a 200 meg file and about 80 megs into it a read failed with a NOT_READY error which is kinda wacky =) The copy chugged along pretty quickly with the write light on almost solid till then.. So if you want to try something different.... =)
Incorrect segment count at 0xc01c3c91nr_segments is a counted segments is 8 Flags 1 0 Segment 0xc3c768c0, blocks 4, addr 0xef9fff Segment 0xc11468a0, blocks 4, addr 0xefa7ff Segment 0xc2da02a0, blocks 4, addr 0x2b2cfff Segment 0xc2490b60, blocks 4, addr 0x2b2d7ff Segment 0xc2177760, blocks 4, addr 0x46dfff Segment 0xc246e920, blocks 4, addr 0x46e7ff Segment 0xc2abd8c0, blocks 4, addr 0xd69fff Segment 0xc28b58c0, blocks 4, addr 0xd6a7ff Segment 0xc32e6ce0, blocks 4, addr 0x2fdafff Segment 0xc24a9660, blocks 4, addr 0x2fdb7ff Segment 0xc336c8e0, blocks 4, addr 0xfcbfff Segment 0xc2c40860, blocks 4, addr 0xfcc7ff Segment 0xc036b320, blocks 4, addr 0x2bf4fff Segment 0xc25e4920, blocks 4, addr 0x2bf57ff Segment 0xc2c307c0, blocks 4, addr 0x3e2dfff
Joy joy joy.. More segment counting problems!
rq->cmd=1, rq->sector=10188, rq->nr_sectors=52 kernel BUG at pktcdvd.c:1086!
This is really strange, as it shouldn't occur. While it shouldn't have occured in this case, in pkt_merge_requests_fn change: #if 0 if (ZONE(rq->sector, pd) != ZONE(next->sector + next->nr_sectors - 1, pd )) return 0; #endif to if (ZONE(rq->sector, pd) != ZONE(next->sector + next->nr_sectors - 1, pd)) return 0; (remove the #if 0/#endif pair) Ben -- Linux UDF - http://linux-udf.sourceforge.net Latest Is - udf-0.9.3 (http://www.csc.calpoly.edu/~bfennema/udf.html)
On Mon, 26 Mar 2001, Ben Fennema wrote:
__refile_buffer: rdev is packet, should move?
These are caused by the wierd buffer changes I don't understand =) I tried reverting buffer.c back to the 2.4.2 version and it didn't seem to directly cause any problems.
I copied a 200 meg file and about 80 megs into it a read failed with a NOT_READY error which is kinda wacky =)
The copy chugged along pretty quickly with the write light on almost solid till then.. So if you want to try something different.... =)
Incorrect segment count at 0xc01c3c91nr_segments is a counted segments is 8 Flags 1 0 Segment 0xc3c768c0, blocks 4, addr 0xef9fff
Joy joy joy.. More segment counting problems!
rq->cmd=1, rq->sector=10188, rq->nr_sectors=52 kernel BUG at pktcdvd.c:1086!
This is really strange, as it shouldn't occur. While it shouldn't have occured in this case, in pkt_merge_requests_fn change:
#if 0 if (ZONE(rq->sector, pd) != ZONE(next->sector + next->nr_sectors - 1, pd )) return 0; #endif
to
if (ZONE(rq->sector, pd) != ZONE(next->sector + next->nr_sectors - 1, pd)) return 0;
(remove the #if 0/#endif pair)
Ben
Okay, I've tried again with the change you made, and I did get another Oops but it was a little different. There was no 'kernel BUG!' this time and none of the __refile_buffer messages. The test was copying a ~130Mb tar file. In terms of drive light action, there was an initial burst of activity but then nothing. The patch was applied against 2.4.3-pre8 with Justin Gibbs' latest aic7xxx driver. Here's what the console captured: pktcdvd: kernel thread pktcdvd0 started pktcdvd: writer sr0 sucessfully registered udf: registering filesystem pktcdvd: inserted media is CD-RW pktcdvd: Fixed packets, 32 blocks / packet, Mode-2 disc pktcdvd: disabled write caching on pktcdvd0 pktcdvd: speed (R/W) 6/4 pktcdvd: 452288KB available on disc bh timed out: sector 33660 dev/rdev 0b:00/0b:00, count 2, state 1c, end_io c4827scsi0:0:3:0: Attempting to queue an ABORT message scsi0:0:3:0: Command found on device queue aic7xxx_abort returns 8194 Incorrect segment count at 0xc01c1d91nr_segments is 11 counted segments is 10 Flags 1 0 Segment 0xc38d97c0, blocks 4, addr 0x18317ff Segment 0xc278d360, blocks 4, addr 0x1638fff Segment 0xc278dd60, blocks 4, addr 0x16397ff Segment 0xc27cd360, blocks 4, addr 0x2ba2fff Segment 0xc278db60, blocks 4, addr 0x2ba37ff Segment 0xc27cd660, blocks 4, addr 0x2a31fff Segment 0xc27cd5e0, blocks 4, addr 0x2a327ff Segment 0xc27cd960, blocks 4, addr 0x1ca4fff Segment 0xc27cd8e0, blocks 4, addr 0x1ca57ff Segment 0xc27cdbe0, blocks 4, addr 0x324efff Segment 0xc27cdb60, blocks 4, addr 0x324f7ff Segment 0xc27cdce0, blocks 4, addr 0x12ccfff Segment 0xc27cdc60, blocks 4, addr 0x12cd7ff Segment 0xc27cdde0, blocks 4, addr 0x27e0fff Segment 0xc271c240, blocks 4, addr 0x27e17ff Segment 0xc3be3120, blocks 4, addr 0x169efff Segment 0xc3be30a0, blocks 4, addr 0x169f7ff Segment 0xc3be31a0, blocks 4, addr 0x20f1fff Segment 0xc38d9140, blocks 4, addr 0x20f27ff Segment 0xc3be33a0, blocks 4, addr 0x1dd2fff Segment 0xc3be3320, blocks 4, addr 0x1dd37ff Segment 0xc3be3420, blocks 4, addr 0x3083fff Segment 0xc14fee60, blocks 4, addr 0x30847ff Segment 0xc3be36a0, blocks 4, addr 0x18a6fff Segment 0xc3be3620, blocks 4, addr 0x18a77ff Segment 0xc3be37a0, blocks 4, addr 0x383ffff Segment 0xc3be3720, blocks 4, addr 0x38407ff Segment 0xc3be39a0, blocks 4, addr 0x319efff Segment 0xc3be3920, blocks 4, addr 0x319f7ff Segment 0xc3be3aa0, blocks 4, addr 0x36a7fff Kernel panic: Ththththaats all folks. Too dangerous to continue. and here's the processed Oops: ksymoops 2.3.4 on i586 2.4.3-pre8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre8/ (default) -m /boot/System.map-2.4.3-pre8 (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(alloc_etherdev) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(ether_setup) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(init_etherdev) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(register_netdev) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(unregister_netdev) not found in System.map. Ignoring ksyms_base entry Kernel panic: Ththththaats all folks. Too dangerous to continue. Unable to handle kernel NULL pointer dereference at virtual address 00000004 c0110a85 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c0110a85>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: c11fd71c ebx: c0f01f9c ecx: 00000000 edx: c0f01f94 esi: c11fd720 edi: 00000086 ebp: c11fd600 esp: c0f01f64 ds: 0018 es: 0018 ss: 0018 Process pktcdvd0 (pid: 1838, stackpage=c0f01000) Stack: c0f00000 c1cf9074 c08f2c60 c48285f2 00000282 00000003 00000009 c1cf911c c1cf9000 00000007 c08f2c60 c031d480 00000000 c0f00000 00000000 00000000 c0f00000 c1cf9074 c1cf9000 c11fd618 c48283f4 c1cf9074 c1cf909c 00000000 Call Trace: [<c48285f2>] [<c48283f4>] [<c01054a6>] [<c48282e0>] Code: 89 59 04 89 4a 08 89 73 04 89 58 04 57 9d 5b 5e 5f c3 89 f6
EIP; c0110a85
<===== Trace; c48285f2 <.data.end+3f93/??? Trace; c48283f4 <.data.end+3d95/??? Trace; c01054a6 Trace; c48282e0 <.data.end+3c81/??? Code; c0110a85 00000000 <_EIP>: Code; c0110a85 <===== 0: 89 59 04 mov %ebx,0x4(%ecx) <===== Code; c0110a88 3: 89 4a 08 mov %ecx,0x8(%edx) Code; c0110a8b 6: 89 73 04 mov %esi,0x4(%ebx) Code; c0110a8e 9: 89 58 04 mov %ebx,0x4(%eax) Code; c0110a91 c: 57 push %edi Code; c0110a92 d: 9d popf Code; c0110a93 e: 5b pop %ebx Code; c0110a94 f: 5e pop %esi Code; c0110a95 10: 5f pop %edi Code; c0110a96 11: c3 ret Code; c0110a97 12: 89 f6 mov %esi,%esi
5 warnings issued. Results may not be reliable. Sorry for the repetitive bad news... Adam
On Thu, Mar 29, 2001 at 12:54:36AM +0100, Adam Huffman wrote:
Okay, I've tried again with the change you made, and I did get another Oops but it was a little different. There was no 'kernel BUG!' this time and none of the __refile_buffer messages. The test was copying a ~130Mb tar file. In terms of drive light action, there was an initial burst of activity but then nothing.
I'll have to put a new patch up tonight. Currently, I copied a 200 meg file and had no problems whatsoever.
The patch was applied against 2.4.3-pre8 with Justin Gibbs' latest aic7xxx driver.
I'll try 2.4.3-pre8 and see if I have any different results. Ben -- Linux UDF - http://linux-udf.sourceforge.net Latest Is - udf-0.9.3 (http://www.csc.calpoly.edu/~bfennema/udf.html)
participants (2)
-
Adam Huffman
-
Ben Fennema