Re: current snapshots of pcmcia

["Jeff V. Merkey" <jmerkey@timpanogas.org>]

David [Hinds],

On a related topic, I've pulled down your stuff at sourceforge and we
are using it for our 2.4 build.  Is this the baest place or do you have
somewhere more recent and is this the list to report bugs?  We have seen
some problems with IBM thinkpads with DSP devices having some issues
(like the volume control doesn't work right on 2.4).  Most are just
annoyances and what I would classify as level IV bugs (very
non-critical).

Thanks,

Jeff

David Hinds wrote:
> 
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/