From debug info added to the DSDT this is: IRQ: 7 DMA: 0 But parport driver states (and this is odd):
https://bugzilla.novell.com/show_bug.cgi?id=375836 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c33 --- Comment #33 from Thomas Renninger <trenn@novell.com> 2008-05-21 10:21:19 MST --- Milisav: Thanks, this really helps a lot! Do not forget to remove the DSDT again: Remove the entry from /etc/sysconfig/kernel to ACPI_DSDT="" and then invoke mkinitrd. What does it tell us: IRQ and DMA gets modified on the fly in _CRS. I mean these templates: IRQNoFlags () {7} DMA (Compatibility, NotBusMaster, Transfer8, ) {3} When the port is enabled in BIOS, the irq and dma will still be correct and the values above will be overridden with the same values (7,3) in _CRS. But if the parallel port in BIOS is disabled, only IRQ gets modified (means, DMCH is 0x4 and DMAC, which should be the dma channel passed to pnpacpi in the end is set to zero). ------------------ Most important: If the parallel port is disabled _STA returns 0xD otherwise 0xF (Even if disabled, _STA gets evaluated four times, one time before the rest of ACPI gets initialized, I didn't know that _STA gets evaluated that early..., two times shortly after initialization of the interpreter and one time if the PNP initialization starts..., looks like there is optimation possible...). ------------------ If the parallel port is disabled, _CRS is not called at PNP initialization time, but much later when the parport_pc driver is loaded and it is called there twice. Ahh and I see why: dev->active = device->status.enabled; is set in pnpacpi/core.c Means the PNP device is added as such, but set inactive. It is activated(as Bjorn already stated) when the parport_pc driver is loaded. ------------------ Conclusion: Patch from comment #29 should help and is IMO the right fix, Bjorn could you comment/review, pls. Hmm, it's a rather easy fix... I'll add it. When _STA returns 0xD _CRS data must not be evaluated. Some things I do not understand and I expect further bugs: Arbitrary data may be returned, when present bit is not set (0xD, this I understand...): parport0: PC-style at 0x378 (0x778), irq 5, dma 1 The parport driver did not modify this, but just takes the values from the pnp layer: if (pnp_dma_valid(dev,0) && !(pnp_dma_flags(dev,0) & IORESOURCE_DISABLED)) dma = pnp_dma(dev,0); same for irq. Why is this irq 5 and not 7? Why is this dma 1 and not 0? Next question is why did _CRS get called twice when parport_pc got loaded? I very much expect bugs in pnp or pnpacpi layer when the device's _CRS did not get parsed at PNP init time (only when present bit is not set), but gets activated later. I will add the patch now (oh, I must leave, I'll add it on Fr) and will not look at this further (not worth it, the patch should be sufficient for 11.0). Things will change heavily in upcoming kernels, I'd more like to help and test with the dynamic resource PNP implementations. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.