On Mon, Nov 06, 2000 at 03:19:41PM -0800, David Ford wrote:
>
> Undoubtedly :( But it used to work when I used your i82365 module instead of
> the kernel's yenta module. The i82365 module now gives the same failure
> output as the yenta module.
How long ago was this? I would need to know what kernel versions and
what PCMCIA driver versions were involved. It has been months since I
changed any of the PCI bridge setup code in the PCMCIA modules.
> I modprobed the following to get things up and running, (all your pkg)
> pcmcia_core, i82365, and ds. Then ran cardmgr. All was well. Now when I
> load i82365, it yields the pci irq failure and the irq type is changed.
>
> 2nd sentc: What changed in the last two-three weeks? I notice that the
> current pcmcia (yours) code loads a new module called pci_fixup.
There is no module called pci_fixup. There is an object file called
pci_fixup that is linked into pcmcia_core. This has been there since
PCMCIA release 3.1.11.
> Intel PCIC probe: <4>PCI: No IRQ known for interrupt pin A of device 00:03.0.
> PCI: No IRQ known for interrupt pin B of device 00:03.1.
This is a PCI subsystem issue; the PCMCIA code asks the PCI subsystem
to activate the bridge device and isn't working.
> Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x10000000
> host opts [0]: [isa irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat
> 168/176] [bus 2/5]
> host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat
> 168/176] [bus 6/9]
> ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms
>
> Previous output was:
> Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x10000000
> host opts [0]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat
> 168/176] [bus 2/5]
> host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat
> 168/176] [bus 6/9]
> ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms
>
> Notice the change from serial irq to isa irq.
This is odd. I don't have an explanation for this, especially without
knowing what PCMCIA driver releases were involved. Unless you specify
otherwise, the i82365 driver just reports the bridge settings that it
finds; it won't change the interrupt delivery mode unless told to do
so. So something else has caused your two sockets to be set up in
different ways; there isn't any way to tell the i82365 module to do
that.
-- Dave