On Sat, Sep 09 2000, Ravi K. Swamy wrote:
I just downloaded the new packet writing code and tried it out on my system. no SMP, HP 9200 SCSI CD-RW drive.
I was copying over a ~260MB dir with cp -a but the copying seems kind of strange. While the "cp" is running, my CD-RW "write LED" isn't on, I assumed it was some write caching/buffering but the cp was taking >30min so I typed "sync" and all of a sudden the write LED came on. Shouldn't the kernel be syncing more frequently?
Well, yes and no. If you have enough memory to hold it all in cache, then there's no point in starting a flush early. However, if the cp as stalled we are indeed not flushing when we should. I'll try and reproduce it here.
I got tired of the cp so I kill -9'ed the cp process, when I tried to umount the cdrw I got the following message. I then cp -a the data back from cdrw to hard drive, one file has some directory entry but no real contents, I ran md5sum on the original files and the copied back from cdrw files and about 10 of 60 files have incorrect md5sums.
The corruption is now a known issue that I'm looking into.
assert failed sectors == rq->nr_sectors,pkt_recheck_segments at 142 kernel BUG at pktcdvd.c:142! invalid operand: 0000 CPU: 0 EIP: 0010:[<c018da28>] EFLAGS: 00010286 eax: 0000001d ebx: 0000001c ecx: 00000001 edx: 00000000 esi: 00000080 edi: dff6ade0 ebp: dff6ade0 esp: dff5df2c ds: 0018 es: 0018 ss: 0018 Process kpacketd (pid: 5, stackpage=dff5d000) Stack: c024b865 c024ba6e 0000008e df8ccda0 df8ccda0 00002800 c018e342 dff6ade0 dff6ade0 dff5e000 dff5e06c dff6e480 dff3c940 00000004 00000070 00002800 00002780 c018e429 dff5e000 dff6ade0 dff6ade0 00000000 c018e513 dff5e000 Call Trace: [<c024b865>] [<c024ba6e>] [<c018e342>] [<c018e429>] [<c018e513>] [
] [<c0108aaf>] Code: 0f 0b 83 c4 0c 8d 76 00 5b 5e 5f c3 83 ec 0c 55 31 c9 57 8b
Can you run this through ksymoops to get some symbols attached to
the call trace?
--
* Jens Axboe