Re: Unable to format or use floppies since 2.6.28

[Mark Hounschell]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/