Mailinglist Archive: opensuse-bugs (19306 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=381795

User milisav.radmanic@xxxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=381795#c40





--- Comment #40 from Milisav Radmanic <milisav.radmanic@xxxxxxxxxx>  2008-05-14 
09:57:17 MST ---
(In reply to comment #38 from Thomas Renninger)
> 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.