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....
Thanks in advance
Mark
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
Similar problems on debian testing: see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434
However, fdformat is ok on Gentoo under 2.6.31 and also on Ubuntu
2.6.32-rc6, so it seems it is not just the kernel version in any
simplistic way.
A git-bisect seems the obvious next step?
ael
On Thu, Dec 10, 2009 at 02:46:15PM -0500, 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.
>
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.
regards,
dan carpenter
On Sat, Dec 12, 2009 at 5:33 PM, ael <[email protected]> wrote:
> 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
>
> Similar problems on debian testing: see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434
>
> However, fdformat is ok on Gentoo under 2.6.31 and also on Ubuntu
> 2.6.32-rc6, so it seems it is not just the kernel version in any
> simplistic way.
>
> A git-bisect seems the obvious next step?
>
Wait...
There are only 13 changes related to floppy since 2.6.28, kick out 2 changes
which just did some constifying, there are 11 only.
The most suspicious one should be commit 1011c1b9f2e from Tejun.
Mark, reverting that patch can help?
Hello,
On 12/17/2009 06:04 PM, Américo Wang wrote:
> On Sat, Dec 12, 2009 at 5:33 PM, ael <[email protected]> wrote:
>> 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.
Hmmm... Strange.
>>> # 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
>>
>> Similar problems on debian testing: see
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434
>>
>> However, fdformat is ok on Gentoo under 2.6.31 and also on Ubuntu
>> 2.6.32-rc6, so it seems it is not just the kernel version in any
>> simplistic way.
Double strange.
>> A git-bisect seems the obvious next step?
>
> Wait...
>
> There are only 13 changes related to floppy since 2.6.28, kick out 2 changes
> which just did some constifying, there are 11 only.
>
> The most suspicious one should be commit 1011c1b9f2e from Tejun.
>
> Mark, reverting that patch can help?
I don't think you can back that single patch out. There were a lot of
cleanups in request handling after that. How about trying 2.6.32
vanilla kernel? Does it work? How about copying fdformat from suse
to gentoo?
Thanks.
--
tejun
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
On 12/17/2009 05:07 AM, Mark Hounschell wrote:
FYI, the current vanilla 2.6.32.1 fails too.
Mark
On 17/12/09 11:35, Mark Hounschell wrote:
> On 12/17/2009 05:07 AM, Mark Hounschell wrote:
>
> FYI, the current vanilla 2.6.32.1 fails too.
>
> Mark
Any news about trying to "mis"align the format headers, and whether that
fixes it?
Thanks,
Alain
On 12/17/2009 05:36 AM, Alain Knaff wrote:
> On 17/12/09 11:35, Mark Hounschell wrote:
>> On 12/17/2009 05:07 AM, Mark Hounschell wrote:
>>
>> FYI, the current vanilla 2.6.32.1 fails too.
>>
>> Mark
>
> Any news about trying to "mis"align the format headers, and whether that
> fixes it?
>
I won't be able to try it until I get to work. I turned on the Firewall before I
left and can't get in from here. My only machine here at home with a floppy,
doesn't fail.
I'll see what I can do first thing.
Mark