On Tue, 5 Dec 2000, Linus Torvalds wrote:
> Anybody else who has had problems with PCI interrupt routing (tends to be
> "new" devices like CardBus, ACPI, USB etc), can you verify that this
> either fixes things or at least doesn't break a setup that had started
> working earlier..
problems with recent 2.4.0-test1* on my HP OmniBook 800 are probably
combined PCMCIA(CB) / PCI / APM issues. The point is my 16bit cards
(modem+ne2k) are working perfectly fine with yenta sockets until the first
suspend/resume. Afterwards the PCI config space of the Cardbus
bridge(s) is completely messed up forcing me to reboot.
So I just applied your patch vs. 2.4.0-t12p3 (had to cleanup one rejected
hunk due to an eisa_set_level_irq() which is already there).
pcmcia-cs is 3.1.22.
result: issue remains unchanged but nothing seems to be broken so far.
The only difference I've noticed is the following two lines appearing when
modprobing the pcmcia_core/yenta stuff:
IRQ for 00:04.0(0) via 00:04.0 -> PIRQ 01, mask 8eb8, \
excl 0000 -> newirq=9 ... failed
IRQ for 00:04.1(1) via 00:04.1 -> PIRQ 04, mask 8eb8, \
excl 0000 -> newirq=7 ... failed
My guess: might be due to the PCI-IRQ-router (VLSI 82C534 PCI-bridge,
id=1004:0102) without special support (defaults to r->get == NULL).
Furthermore, I've noticed at 2.4.0-t10 the PCI-IRQ's of the CB-bridges
were lost (reset to 0) during suspend/resume whereas at 2.4.0-t12p3 they
survive (-t11 not tried). However memory and io-mapping get lost.
I'd consider this the main reason for the failure, but I'm not sure
whether it's the Cardbus bridges' fault or a PCI or APM issue.
But nothing - neither fixed nor broken - has changed for me by this patch,
except for the two lines which apparently do not matter anyway.
attached: dmesg and lspci traces with some comments.
What more information/debugging would be helpful?
Regards
Martin
This archive was generated by hypermail 2b29 : Thu Dec 07 2000 - 21:00:15 EST