https://bugzilla.novell.com/show_bug.cgi?id=381795
User milisav.radmanic@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=381795#c40
--- Comment #40 from Milisav Radmanic
This ... parport driver again. Last time it tried to grab dma 7... Can you attach acpidump output, pls. I doubt it gets the irq 14 info from acpi, the parport driver falls back and tries to make up his own values somehow (or pokes a superIO chip for it? I have to look at it again).
I don't want to touch this driver, the author, a redhat guy told me that this one is out of maintenance for quite some time already and he does not want to touch it.
Does pnpacpi=off help?
Yes it does.
What does this throw out (without pnpacpi=off)?: cat /sys/devices/pnp0/00:07/resources (00:07 should be parport, dmesg|grep parport should show).
it throws: io 0x378-0x37f io 0x778-0x77d irq 14 dma 1
What exactly does pci=routeirq do?
I think I've found the root cause of this. After a look in the BIOS setup I've found that the parallel port was deactivated. I don't know why it was, but I guess it was shipped like that. If I activate the device it in the BIOS the parport module successfully locates a parallel port at IRQ 7 dma3 and does not hijack IRQ 14 - hence the harddrive gets found. The issue is reproducible by activating and deactivating the parallel port in the BIOS. I'll attach the output of acpidump here for completeness, but will Greg's advise to continue the discussion at bug 375836. -- 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.