/etc/init.d/net.eth0 fails to start and returns error message "SIOCSIFFLAGS: Device or resource busy" Reproducible: Always Steps to Reproduce: 1. Compile kernel with: Device drivers ---> ATA/ATAPI/MFM/RLL support ---> ...under "*** IDE chipset support/bugfixes ***": Activate/select "generic/default IDE chipset support" (CONFIG_IDE_GENERIC) ...while having also selected a driver module under "*** PCI IDE chipsets support ***" in the same page of "make menuconfig" ...You then get, in /bin/dmesg output: "ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports". ...also, my network card driver is the "8139too" module. 2. Add "ide_generic.probe_mask=0x3f" as kernel boot param ...You then get: "ide_generic: enforcing probing of I/O ports upon user request "ide_generic: I/O resource 0x1F0-0x1F7 not free. "ide_generic: I/O resource 0x170-0x177 not free." 3. Run "/etc/init.d/net.eth0 start" Actual Results: Receive error message "SIOCSIFFLAGS: Device or resource busy", and net.eth0 fails to complete its start. Expected Results: * Starting eth0 * Bringing up eth0 * dhcp * Running dhcpcd ... [ ok ] * eth0 received address <xxx>.<yyy>.<nnn>.<mmm>/<aa> Solution: either do not provide the above-mentioned boot parametre, or do not activate "CONFIG_IDE_GENERIC" at all in your kernel. Somehow i had it as a module (which loaded automatically), but note that the kernel configuration help page fails to indicate the name of the module. (sys-kernel/gentoo-sources:2.6.28-r5 and :2.6.29-r5) The ide_generic message asking for a specific hex address boot param did not use to appear in sys-kernel/gentoo-sources:2.6.23-r3
IDE_GENERIC is terribly broken and has been known to eat computers+humans. I hope we don't have it in any defconfigs for genkernel, etc? If not, not much we can do here
It is enabled in all of the default genkernel kconfigs except for ia64. However, it's probably time to whack the entire set of IDE drivers and go completely with the PATA drivers. Is there an equivalent option for PATA that I should (or shouldn't) enable?
(In reply to comment #2) > it's probably time to whack the entire set of IDE drivers and go > completely with the PATA drivers. Is there an equivalent option for PATA that I > should (or shouldn't) enable? > Hopefully this question wasn't aimed at me, as i am unable to distinguish the PATA drivers from the IDE set ('been searching in menuconfig menu hierarchy, in .config, and in Documentation/00-INDEX). There is the BLK_DEV_GENERIC option which fills the same purpose as that of IDE_GENERIC, but it seems to be restricted to PCI bus, whereas the other one is meant to work in ISA too (and perhaps other busses too, i wouldn't know).
Excuse me, but this doesn't sound like a bug to me. By enabling 'probe_mask=0x3f' you ask for ide_generic to probe all legacy ISA IDE ports. There is always a chance that the resources may be in use by another ISA device, which is what's probably happening in your case. Do you have any reasons to use that boot parameter (apart from that informative message mentioning it)? Do you have any reasons to believe that it should work without any problems? Thanks
(In reply to comment #4) > Excuse me, but this doesn't sound like a bug to me. By enabling > 'probe_mask=0x3f' you ask for ide_generic to probe all legacy ISA IDE ports. > There is always a chance that the resources may be in use by another ISA > device, which is what's probably happening in your case. > > Do you have any reasons to use that boot parameter (apart from that informative > message mentioning it)? Do you have any reasons to believe that it should work > without any problems? > > Thanks > As you understood, i added this boot parametre to follow instructions. Although not entirely blindly so, as i checked /proc/ioports beforehand, where i did not detect the possibility of a resource conflict. But you're right, whether it is a bug is debatable indeed. It would be nice if people didn't run into that problem, as many seem to have, if you google for it. Many of whom never got a suitable answer in the various discussion fora. One of the reasons i filed this bug is so that the solution i found be documented somewhere. I hope this helps. I think that it would have been nice if i had been informed that i did not need to select that kernel configuration parameter at all. So this is more of a kernel documentation issue than a Gentoo Linux bug; i thought it might be of interest to the Gentoo team, who in turn might deem it worthy to pass it on upstream.
(In reply to comment #5) > (In reply to comment #4) > > Excuse me, but this doesn't sound like a bug to me. By enabling > > 'probe_mask=0x3f' you ask for ide_generic to probe all legacy ISA IDE ports. > > There is always a chance that the resources may be in use by another ISA > > device, which is what's probably happening in your case. > > > > Do you have any reasons to use that boot parameter (apart from that informative > > message mentioning it)? Do you have any reasons to believe that it should work > > without any problems? > > > > Thanks > > > > As you understood, i added this boot parametre to follow instructions. Although > not entirely blindly so, as i checked /proc/ioports beforehand, where i did not > detect the possibility of a resource conflict. > > But you're right, whether it is a bug is debatable indeed. It would be nice if > people didn't run into that problem, as many seem to have, if you google for > it. Many of whom never got a suitable answer in the various discussion fora. > One of the reasons i filed this bug is so that the solution i found be > documented somewhere. I hope this helps. > > I think that it would have been nice if i had been informed that i did not need > to select that kernel configuration parameter at all. So this is more of a > kernel documentation issue than a Gentoo Linux bug; i thought it might be of > interest to the Gentoo team, who in turn might deem it worthy to pass it on > upstream. > The story is that Linux was probing all legacy ISA IDE ports by default but that started causing problems and was fixed to it's current behavior (commit 0cbccbc30a60ff60dbeb203154f1f527c632de9b). The probe_mask option message is purely informative and by no means suggestive. If you think that it's tone should be changed to reflect that, feel free to open a bug report upstream (bugzilla.kernel.org), 'till then I'll have to mark the report as INVALID ;) Thanks for the bug report, Jerome!
