Re: current snapshots of pcmcia

Re: current snapshots of pcmcia

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 2390 bytes --]

(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 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.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Re: current snapshots of pcmcia

[David Hinds]

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/

Re: current snapshots of pcmcia

[Jeff V. Merkey]

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/

Re: current snapshots of pcmcia

[David Hinds]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: current snapshots of pcmcia

[Jeff V. Merkey]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: current snapshots of pcmcia

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]

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 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.

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'."



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Re: current snapshots of pcmcia

[David Hinds]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: current snapshots of pcmcia

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

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'."



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

PCMCIA versioning...

[Simon Huggins]

On Mon, Nov 06, 2000 at 03:40:39PM -0800, David Hinds wrote:
> [..]  I would need to know what kernel versions and what PCMCIA driver
> versions were involved. [..]

Is there actually a way to work out what version of userspace utilities
you are using?

I read Changes and it tells me that I need pcmcia-cs 3.1.21 (for
test10-final).  It also tells me I can find out the version using
cardmgr -V.
Yet whenever I build the pcmcia utils it grabs the version from
the kernel tree (include/pcmcia/version.h) and not from the file under
pcmcia-3.1.21 (in config.mk kernel is before local include dir).

Hence the bizarre result:
[huggie@langly /usr/src]$ pcmcia-cs-3.1.21/cardmgr/cardmgr -V
cardmgr version 3.1.22

(kernel's version.h is 3.1.22).

Um, is this normal, good, right and proper?
Does the version in Changes really mean "you should recompile
{cardmgr,cardctl} with each kernel"?

[ I'm using the kernel's pcmcia modules ]

-- 
----------(  "Have you seen a man who's lost his luggage?"   )----------
----------(                   -- Suitcase                    )----------
Simon ----(                                                  )---- Nomis
                             Htag.pl 0.0.17
-
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/