On 12/10/2009 02:46 PM, Mark Hounschell wrote:

I have many boxes. They all do the same thing. Running different versions of SuSE, 10.3-11.2. Any kernel at or above 2.6.28 fails to fdformat a floppy. These same machines, using the same floppies and drives, running kernels older than 2.6.28 work just fine. I googled and found other such reports but no solution. I know better than to just assume it's a kernel bug but it sure looks like it could be so I'm inquiring about it here.

# fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Problem reading cylinder 1, expected 18432, read 2048

dmesg from 2.6.32:

Dec 10 14:24:21 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 10 14:24:21 harley kernel: Buffer I/O error on device fd0, logical block 5 Dec 10 14:24:23 harley kernel: end_request: I/O error, dev fd0, sector 72 Dec 10 14:24:23 harley kernel: Buffer I/O error on device fd0, logical block 9 Dec 10 14:24:26 harley kernel: end_request: I/O error, dev fd0, sector 117 Dec 10 14:24:26 harley kernel: Buffer I/O error on device fd0, logical block 14 Dec 10 14:24:28 harley kernel: end_request: I/O error, dev fd0, sector 127 Dec 10 14:24:28 harley kernel: Buffer I/O error on device fd0, logical block 15 Dec 10 14:24:30 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 10 14:24:30 harley kernel: Buffer I/O error on device fd0, logical block 5 Dec 10 14:24:32 harley kernel: end_request: I/O error, dev fd0, sector 144 Dec 10 14:24:32 harley kernel: Buffer I/O error on device fd0, logical block 18 Dec 10 14:24:34 harley kernel: end_request: I/O error, dev fd0, sector 189 Dec 10 14:24:34 harley kernel: Buffer I/O error on device fd0, logical block 23 Dec 10 14:24:36 harley kernel: end_request: I/O error, dev fd0, sector 216 Dec 10 14:24:36 harley kernel: Buffer I/O error on device fd0, logical block 27 Dec 10 14:24:39 harley kernel: end_request: I/O error, dev fd0, sector 261 Dec 10 14:24:39 harley kernel: Buffer I/O error on device fd0, logical block 32 Dec 10 14:24:41 harley kernel: end_request: I/O error, dev fd0, sector 288 Dec 10 14:24:41 harley kernel: Buffer I/O error on device fd0, logical block 36 Dec 10 14:24:43 harley kernel: end_request: I/O error, dev fd0, sector 333 Dec 10 14:24:43 harley kernel: Buffer I/O error on device fd0, logical block 41 Dec 10 14:24:45 harley kernel: end_request: I/O error, dev fd0, sector 360 Dec 10 14:24:45 harley kernel: Buffer I/O error on device fd0, logical block 45

# rpm -qf /usr/sbin/fdformat util-linux-2.16-4.5.1.i586

Again, on this very machine, running 2.6.27.41 all is fine....

The last known working kernel here is 2.6.27.41. 2.6.28 fails. How many from changes 2.7.27 to 2.6.28? There has been some development on this problem on the fdutils list. It turns out that if dma is disabled, (floppy=nodma) fdformat works just fine on kernels from 2.6.28 to current. So Alain Knaff is trying to help sort it out over on the fdutils list. Dan, I'm adding Alain Knaff and the fdutils list to the CC list and quoting your response in this email so he will see it there. I don't thinkAlain has been monitoring this list for this problem and it might help.

On 12/17/2009 03:30 AM, Dan Carpenter wrote: I don't know if this is related to your bug, but it's a weirdness in floppy.c (from 2.6.32-rc8 sorry I suck for being up to date).

drivers/block/floppy.c 2532 size = blk_rq_cur_bytes(current_req); 2533 2534 rq_for_each_segment(bv, current_req, iter) { 2535 if (!remaining) 2536 break; 2537 2538 size = bv->bv_len;

We never use the first size = blk_rq_cur_bytes() assignment.

What we have been able to see when dma is enabled appears to be corruption of the track label buffer while in transit (dma) to the FDC. It seems that starting with track 1 and then every 4 tracks or so after that, the track number in the label for sector 0x0a is 1 less than it should be. We see the buffer (via printks) is correct before and after transit but does not get transmitted correctly when DMA is used. The thread on the fdutils list is getting long but progress is being made. Please CC that list if anyone can help further. Thanks and regards Mark