sata_sil driver returns error -16 when trying to detect attached sata devices at boot. Specifically, at boot, I get: Sep 15 13:25:57 archiso kernel: sata_sil 0000:02:0c.0: version 2.4 Sep 15 13:25:57 archiso kernel: genirq: Flags mismatch irq 6. 00000080 (sata_sil) vs. 00000000 (floppy) Sep 15 13:25:57 archiso kernel: sata_sil: probe of 0000:02:0c.0 failed with error -16 This happens with all bios versions of the adaptec 1210sa (which is just a fancy Silicon Image sil 3112 chipset) I suspect this is a kernel issue because I've booted other distros of linux, all of which have different kernel versions, and this device works. When I looked into the issue on my own, it seems like this driver gets broken from time to time, but then it'll only get fixed for the next release and get broken again.
Does this occur if you don't have floppy support built in ?
I can try disabling my on-board floppy adapter, is that what you mean?
Oh you actually have a real floppy adapter - yes that would also be interesting as well as trying a kernel without floppy driver enabled.
For what it's worth, the system board(s) I gathered the error on is the Intel D820LP, using the Adaptec 1210sa, which is where the sata_sil driver comes in. I'll give it a shot with the floppy disabled and let you know what I find.
I get the same error if the floppy controller is disabled or not.
Assuming the driver is built into your kernel try booting with floppy.FLOPPY_IRQ=0 if it's not built in then try the boot option floppy.blacklist=y What seems to be happening is your BIOS is assigning the same interrupt to both the floppy (an ISA non sharable interrupt) and the 1210SA.
whoa....well, luckily I don't really need floppy support. I wonder if I can force an IRQ on the 1210sa?
The BIOS may let you change the PCI IRQ allocations. I assume the floppy controller is on the motherboard ?
Correct. Although it just hit me, I'm able to get older linux kernels (2.6.x) to boot up (specifically the SliTaz distro) and I don't get any IRQ issues there, it all just works, which led me to believe this was a kernel issue.