Mailinglist Archive: opensuse-bugs (19817 mails)

< Previous Next >
[Bug 375836] parallel driver grabs IRQ14 preventing legacy SFF ATA controller from working
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Fri, 23 May 2008 07:19:54 -0600 (MDT)
  • Message-id: <20080523131954.AA84D24538D@xxxxxxxxxxxxxxxxxxxxxx>

User trenn@xxxxxxxxxx added comment

--- Comment #37 from Thomas Renninger <trenn@xxxxxxxxxx> 2008-05-23 07:19:53
MST ---
Patch from comment #34 is wrong, please do not do that.

The mechanism to activate (and parse the resources of) the device when the
driver is loaded also if the Bit 1 of _STA is not set is:
1) broken: output from comment #32 shows that the IRQ in _CRS is set to
7 and dma to 0, but the PNP layer gets it wrong and passes
random numbers to the driver (in Milisav's debug case above
IRQ 5 and DMA 1, when he installed it was irq 14 and dma ?).
2) wrong: ACPI Spec 3.0, chap. 6.3.7 states about _STA function:
"Bit 1 Set if the device is enabled and decoding its resources."
"A device can only decode its hardware resources if both bits 0 and
1 are set. If the device is not present (bit 0 cleared) or not
enabled (bit 1 cleared), then the device must not decode its
Our special case is that Bit 1 is not set. But PNP layer will
decode its resources if the driver gets loaded, that is
In fact, all the PNP layer can do is decoding resources, so
it must take its hands off completely. This is what my patch

IMO, in 0xD case the driver itself can try to get the device activate by
guessing its resources.

PNP must tell the driver when it registers either that:
- The device is disabled (also do not try to touch it yourself)
- The device is enabled, use pnp info for setting it up
- The device (may be) enabled, try to find the resources yourself
The latter is missing.

Look at parport_pc driver, there are functions like:

/* Onboard SuperIO chipsets that show themselves on the PCI bus. */
count += parport_pc_init_superio(autoirq, autodma);

/* PnP ports, skip detection if SuperIO already found them */
if (!count) {
This order must be exchanged to do it correctly, but touching this old driver
is probably not a good idea.
Correctly it should first register for PNP. If the device is present, but
decoding ACPI resources if forbidden then above functions should get active
(maybe then it's save to remove the #ifdef from them? Hmm, probably only on
Windows if one already knows from the vendor which HW to poke...).

I have a Toshiba Portege 4000 with a parallel port. There is no BIOS
setting to enable or disable the port, but the BIOS always leaves the ACPI
device marked disabled. If we completely ignored the device, Linux would
never be able to use it.
Or whatabout:
options parport_pc io= irq=

This is already pre-defined in our modprobe.conf, seems there already have been
a lot reports about this driver:
# options parport_pc io=0x378 irq=none,none
# If you have multiple parallel ports, specify them this way:
# options parport_pc io=0x378,0x278 irq=none,none

I prefer to go the save (and IMO cleaner) way for 11.0, that irq 14 was chosen
here seem to be absolutely random.
People can still activate their parport with module params.
We might get some devices then not working anymore (should be really seldom,
when others also return 0xD and PNP does it wrong but by luck gets the right
info), working around with pnpacpi=off should still work in all cases.

I'll keep this bug open a bit longer for discussion...

Milisav: A short check whether installation really works for you (finds the
disk) in the next Beta would be great.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >