Re: PCMCIA versioning...

Re: PCMCIA versioning...

[David Hinds]

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

Right now, no; the user space utilities grab the version number from
the header files.  I haven't figured out a sane way to straighten this
out; this was the best I could come up with for now.  In general, the
version of the kernel stuff is what matters: the user space tools
don't change much, and the API is pretty much static, so you don't
need to recompile them all the time.

-- 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: 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/

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/