Re: current snapshots of pcmcia
David Hinds wrote: > Incidentally, the i82365 module should work ok (using ISA interrupts) > despite the "No IRQ known" messages. The Yenta driver won't work at > all if PCI interrupts aren't set up. So I guess another question > would be, what card(s) are you using and how are they misbehaving? I'm using tulip based cards and a linksys PC 10/100 + 56K mdm. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Re: current snapshots of pcmcia
Incidentally, the i82365 module should work ok (using ISA interrupts) despite the "No IRQ known" messages. The Yenta driver won't work at all if PCI interrupts aren't set up. So I guess another question would be, what card(s) are you using and how are they misbehaving? -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: current snapshots of pcmcia
David Hinds wrote: > > On Mon, Nov 06, 2000 at 04:45:52PM -0700, Jeff V. Merkey wrote: > > > > 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). > > The sourceforge site is the most up to date place for PCMCIA. That is > the best place to report bugs that are specific to that code. For > bugs that are specific to things in the 2.4 tree and/or have to do > with how PCMCIA interacts with other subsystems (i.e., the problem > that started this thread, where I think the problem is in the PCI > subsystem), then linux-kernel is probably a better place. Thanks :-) Jeff > > -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: current snapshots of pcmcia
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. test10-pre6, your code from mid october worked (with gross hack I made for the L1 cache define). test10 release, nothing works now. > > 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. Hmm, lsmod showed it. I'll duplicate and report. > > 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 0x1000 > > 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 0x1000 > > 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. Ok. I'll go back to test10-pre6 and get a working pcmcia system and we'll go from there. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Re: current snapshots of pcmcia
On Mon, Nov 06, 2000 at 04:45:52PM -0700, Jeff V. Merkey wrote: > > 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). The sourceforge site is the most up to date place for PCMCIA. That is the best place to report bugs that are specific to that code. For bugs that are specific to things in the 2.4 tree and/or have to do with how PCMCIA interacts with other subsystems (i.e., the problem that started this thread, where I think the problem is in the PCI subsystem), then linux-kernel is probably a better place. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: current snapshots of pcmcia
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 0x1000 > > 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 0x1000 > > 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: current snapshots of pcmcia
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 0x1000 > 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 0x1000 > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: current snapshots of pcmcia
(cc: lkml) David Hinds wrote: > On Mon, Nov 06, 2000 at 01:10:24AM -0800, David Ford wrote: > > :( > > > > Ok. Here's the story. 2.3/2.4 kernel pcmcia gave up the ghost on my > > socket controller several versions back. It is unable to assign an irq. > > PCMCIA in 2.4 (whether you build the modules in the kernel, or build > the modules in the standalone package) is completely dependent on the > kernel PCI layer to assign PCI interrupts (I assume that's what you > mean by "an irq"? without system log messages I can't be sure). > There has been no change in this in recent months; there may have been > changes in the PCI layer that broke your setup. > > > What changed in the last ~two weeks? I notice that the current snapshot > > also loads pci fixup. > > I don't understand the second sentence. Please explain. 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. 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. The dmesg output from loading i82365 is: 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. Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 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 0x1000 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. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
