ACPI + Floppy detection problem in 2.6.8.1-mm4

Yup, the current -mm4 code assumes that if you have 6 ports in the first region, they are 0x3f2-0x3f7. But your BIOS reports 6 ports at 0x3f0-0x3f5.

So I guess we'll have to do something like Petr's approach of ignoring the low three bits. Thanks for the report. I'll send you a patch to try shortly.

Bjorn

Aric and Petr, can you give this patch a try? It's a replacement for the one currently in 2.6.8.1-mm4. I adopted Petr's strategy of just clearing the low three bits of the first I/O port region, and also his module unload fixes.

I also added a couple validity checks (for firmware that doesn't report 0x3f7 or reports 0x3f0 or 0x3f6), and made them ignore the device altogether if "acpi=strict". Any comments on that, Len?

Add ACPI-based floppy controller enumeration.

This can be disabled with "floppy=no_acpi", which should only be required if your BIOS supplies incorrect ACPI _CRS information about I/O ports, IRQs, or DMA channels.

===== Documentation/floppy.txt 1.1 vs edited =====

@@ -187,6 +187,11 @@
 	   It's been recommended that take about 1/4 of the default speed
 	   in some more extreme cases."
 
+ floppy=no_acpi
+	Don't enumerate floppy controllers using ACPI namespace.
+	You may need this if your ACPI is buggy and reports incorrect
+	I/O port, IRQ, or DMA information.
+
 
 
 Supporting utilities and additional documentation:

===== drivers/block/floppy.c 1.103 vs edited =====

Great! Seems to work now:

[-snip-]
inserting floppy driver for 2.6.8.1-mm4
floppy: controller ACPI FDC0 at I/O 0x3f0-0x3f5, 0x3f7 irq 6 dma channel 2
floppy: FDC0 _CRS erroneously includes 0x3f0
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
[-snip-]

I'm not sure if that warning is really necessary or not, but for debug purposes it is not a problem. As such, might want to consider change that message to a KERNEL_DEBUG. Not really a big issue though I guess. I just don't like the word "erroneously" in my kernel logs each time I boot :)

I have to remove the acpi_strict code that you added in order to get the driver to load. I am using it as a module, and the acpi_strict symbol does not seem to be exported by the kernel. Since I am not using the acpi=strict flag anyways, I just killed the related 6 lines from your patch before applying it. I'm sure it would have been fine had I compiled the driver into the kernel, but as it stands now the acpi_strict variable would need to be exported I guess.

Aric Cyr <acyr at alumni dot uwaterloo dot ca>    (http://acyr.net)
gpg fingerprint: 943A 1549 47AC D766 B7F8  D551 6703 7142 C282 D542

OK, here's something that I think should be suitable for the next -mm patchset.

We report exactly what ACPI tells us about I/O port regions. We mask off the low three bits of the first region, so we can handle all the reasonable ACPI weirdnesses. We warn only about the case where we claim a port ACPI didn't tell us about. All the acpi_strict stuff is gone, at least for now. The module unload stuff should be fixed.

Add ACPI-based floppy controller enumeration.

This can be disabled with "floppy=no_acpi", which should only be required if your BIOS supplies incorrect ACPI _CRS information about I/O ports, IRQs, or DMA channels.

===== Documentation/floppy.txt 1.1 vs edited =====

@@ -187,6 +187,12 @@
 	   It's been recommended that take about 1/4 of the default speed
 	   in some more extreme cases."
 
+ floppy=no_acpi
+	Don't enumerate floppy controllers using ACPI namespace.
+	You may need this if your ACPI is buggy and doesn't report
+	a floppy controller when it actually exists, or if it
+	reports incorrect I/O port, IRQ, or DMA information.
+
 
 
 Supporting utilities and additional documentation:

===== drivers/block/floppy.c 1.103 vs edited =====