fdformat /dev/fd0 hangs the kernel on the verification phase (read/write). This does not occur with the stock linux 2.4.17 sans Gentoo patches. dd if=file of=/dev/fd0 also hangs the kernel. Will try disabling advanced options of the gentoo kernel to see if this is a general problem with the gentoo kernel patches or is related to an individual feature. MB is a Tyan Tiger 100, fyi.
This problem also seemed to exist in the -mjc3 kernel. Weird. We may be tracking down a bug here.
ok, this is what I'd like you to do. Try a vanilla 2.4.18-pre7 kernel and see what happens. If it doesn't work, we'll report it to LKML. If it does work, I'll test each of our patches one by one until I find the problem.
I tried installing tomsrtbt (a floppy-based linux distro) to provide a baseline test for each of these kernels, though pretty much any floppy read operation will do. You can download it from here:http://www.toms.net/rb/ These are my findings: Vanilla 2.4.18-pre7 kernel - install tomsrtbt to fd0 perfectly - Pass Gentoo 2.4.18-pre3 kernel - locks on verification stage of floppy format - Fail Gentoo 2.4.17-r2 kernel - locks on verification stage of floppy format - Fail I will included my kernel .config file to help reproduce the problem. I used the same configuration for each kernel (did not enable any special features in the Gentoo kernels)
I will attach a .config file when file attachments work in Bugzilla again. My setup is quite generic, however. Enable USB, ACPI, no sound, i686, etc.
Tried 2.4.17-r3, works better than 2.4.17-r2 but still locks under certain floppy reads. For instance, when installing tomsrtbt, a disk containing 82 sectors is formated (/dev/fd0u1720 or something), which works fine with 2.4.18-pre7. With 2.4.17-r2, the format operation hangs when verifying (reading from) sector 0. With 2.4.17-r3, the format operation hangs when verifying sector 80.
OK. It would be interesting to know if this bug exists with a stock 2.4.17 kernel. I'm going to insist that you to try (yet another) kernel, but if you have some free time... well why not? :) If the problem exists in stock 2.4.17, then the problem you are having is unrelated to the kernel patches and when we move up to 2.4.18 the problem should go away. *But*, if the problem doesn't exist in 2.4.17, then it's very likely being caused by one of the patches we added. If that's the case, the problem will likely *not* go away at 2.4.18 and needs to be addressed now. Make sense?
I noted in my first comment that this bug is not in the 2.4.17 stock kernel. I am running currently 2.4.18-pre7-ac2, and also no problems with floppy access either. Perhaps if there were a way that I could apply individual patches from your kernel tree instead of the one big gentoo patch, I could do some trial and error (simple, one at a time. I don't think that I could try every permutation!) I know that older revisions of the gentoo kernel applied individual patches.
Ooops. OK, great. Well, we have the info to begin tracking down the bug. The first thing I'd suggest if you haven't tried this already is to try 2.4.17-r3 with preempt turned off. If you've already tried this, let me know and we'll move on to the next step.
We're going to try to drop patches in the following order: preempt, read-latency, ide, irqrate.
OK, this has been isolated. From Brent: The irqrate-2.4.17-A1 patch causes the hang. I tried formating and verifying a floppy using tomsrtbt, and a hang occurred when reading from sector 81.
irqrate-2.4.17-A1 has been removed from linux-sources-2.4.17-r4 (being released tonight). This bug will be fixed on CVS within the hour. Give it a test, but it should be fixed.
