[I'm not subscribed, so please Cc me in any replies]
In short: I'm using an HP Ombibook 800CT, have started using
a Carbus PCMCIA network card and am losing the card after
suspends.
I've tried searching lkml for similar things but didn't find
anything that seemed close enough, so here's a little more
detail (though I don't want to add too much until I know you
want to hear about it).
"modprobe yenta_socket" normally logs:
Sep 4 21:39:10 graffito kernel: Linux Kernel Card Services 3.1.22
Sep 4 21:39:10 graffito kernel: options: [pci] [cardbus] [pm]
Sep 4 21:39:10 graffito kernel: PCI: Found IRQ 9 for device 00:04.0
Sep 4 21:39:10 graffito kernel: PCI: Found IRQ 7 for device 00:04.1
Sep 4 21:39:10 graffito kernel: Yenta IRQ list 0448, PCI irq9
Sep 4 21:39:10 graffito kernel: Socket status: 30000020
Sep 4 21:39:10 graffito kernel: Yenta IRQ list 0448, PCI irq7
Sep 4 21:39:10 graffito kernel: Socket status: 30000006
but after "apm --suspend" I get the same except:
Sep 6 23:23:55 graffito kernel: Socket status: 66012d18
...
Sep 6 23:23:55 graffito kernel: Socket status: 2a035c8a
The effect of this is that it can't see anything in the
socket, so I can't get it to load the driver for the PCMCIA
card. It only happens if the machine has been on battery
power during the suspend. It doesn't happen if the socket is
set to PCIC mode in the BIOS, though in that case I can't
use the card anyway. It happens whether or not the card is
present, and whether or not cardmgr is running, and it
happens in 2.4.21, 2.4.22 and 2.6.0-test4.
Rebooting without powering off clears the condition, but
nothing else I've tried (cardctl eject &c, loading and
unloading modules round the suspend, using setpci to restore
the registers of the bridge, passing do_apm=0 to
pcmcia_core) makes any difference.
The card in question is a netgear FA511, but I don't think
that's relevant as the problem happens even if I don't plug
it in until after the suspend, and so long as yenta_socket
reports a sensible status it works fine (with the tulip
driver).
Please let me know if you need more information.
Thanks,
J?n
--
J?n Fairbairn
On Wed, Sep 10, 2003 at 10:22:32PM +0100, Jon Fairbairn wrote:
> In short: I'm using an HP Ombibook 800CT, have started using
> a Carbus PCMCIA network card and am losing the card after
> suspends.
I'm only interested in the 2.6.0-test5 results.
Please run lspci -vvb twice - once when you have just booted
the machine, and once when you resume.
> Sep 4 21:39:10 graffito kernel: Linux Kernel Card Services 3.1.22
> Sep 4 21:39:10 graffito kernel: options: [pci] [cardbus] [pm]
> Sep 4 21:39:10 graffito kernel: PCI: Found IRQ 9 for device 00:04.0
> Sep 4 21:39:10 graffito kernel: PCI: Found IRQ 7 for device 00:04.1
> Sep 4 21:39:10 graffito kernel: Yenta IRQ list 0448, PCI irq9
> Sep 4 21:39:10 graffito kernel: Socket status: 30000020
> Sep 4 21:39:10 graffito kernel: Yenta IRQ list 0448, PCI irq7
> Sep 4 21:39:10 graffito kernel: Socket status: 30000006
>
> but after "apm --suspend" I get the same except:
>
> Sep 6 23:23:55 graffito kernel: Socket status: 66012d18
> ...
> Sep 6 23:23:55 graffito kernel: Socket status: 2a035c8a
It looks like the cardbus controller configuration wasn't correctly
restored.
--
Russell King ([email protected]) http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
2.6 ARM Linux - http://www.arm.linux.org.uk/
2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On 2003-09-10 at 23:45BST Russell King wrote:
> On Wed, Sep 10, 2003 at 10:22:32PM +0100, Jon Fairbairn wrote:
> > In short: I'm using an HP Ombibook 800CT, have started using
> > a Carbus PCMCIA network card and am losing the card after
> > suspends.
>
> I'm only interested in the 2.6.0-test5 results.
OK. Pause for recompilation...
> Please run lspci -vvb twice - once when you have just booted
> the machine, and once when you resume.
The following is done without unloading the modules round
the suspend.
Before:
------
00:00.0 Host bridge: VLSI Technology Inc 82C535 (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
00:01.0 PCI bridge: VLSI Technology Inc 82C534 [Eagle] (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00004000-00007fff
Memory behind bridge: 20000000-2fffffff
Prefetchable memory behind bridge: 30000000-3fffffff
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset+ FastB2B-
00:02.0 Class ff00: VLSI Technology Inc 82C532 (rev 02)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:03.0 VGA compatible controller: Neomagic Corporation NM2070 [MagicGraph 128] (rev 01) (prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
Region 0: Memory at c0000000 (32-bit, prefetchable)
00:04.0 CardBus bridge: Texas Instruments PCI1130 (rev 04)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 08
Interrupt: pin A routed to IRQ 9
Region 0: Memory at 000e6000 (32-bit, non-prefetchable)
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 10000000-103ff000 (prefetchable)
Memory window 1: 10400000-107ff000
I/O window 0: 00008000-000080ff
I/O window 1: 00008400-000084ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
16-bit legacy interface ports at 0001
00:04.1 CardBus bridge: Texas Instruments PCI1130 (rev 04)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 08
Interrupt: pin B routed to IRQ 7
Region 0: Memory at 000e7000 (32-bit, non-prefetchable)
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: 10800000-10bff000 (prefetchable)
Memory window 1: 10c00000-10fff000
I/O window 0: 00008800-000088ff
I/O window 1: 00008c00-00008cff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00:06.0 IRDA controller: VLSI Technology Inc 82C147 (rev 02)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at 1000 [disabled]
02:00.0 Ethernet controller: Linksys Fast Ethernet 10/100 (rev 11)
Subsystem: Netgear FA511 10/100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (63750ns min, 63750ns max)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 8000
Region 1: Memory at 10400000 (32-bit, non-prefetchable)
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
------
After:
------
00:00.0 Host bridge: VLSI Technology Inc 82C535 (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
00:01.0 PCI bridge: VLSI Technology Inc 82C534 [Eagle] (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00004000-00007fff
Memory behind bridge: 20000000-2fffffff
Prefetchable memory behind bridge: 30000000-3fffffff
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset+ FastB2B-
00:02.0 Class ff00: VLSI Technology Inc 82C532 (rev 02)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:03.0 VGA compatible controller: Neomagic Corporation NM2070 [MagicGraph 128] (rev 01) (prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
Region 0: Memory at c0000000 (32-bit, prefetchable)
00:04.0 CardBus bridge: Texas Instruments PCI1130 (rev 04)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 08
Interrupt: pin A routed to IRQ 9
Region 0: Memory at 000e6000 (32-bit, non-prefetchable)
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 10000000-103ff000 (prefetchable)
Memory window 1: 10400000-107ff000
I/O window 0: 00008000-000080ff
I/O window 1: 00008400-000084ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite+
16-bit legacy interface ports at 0001
00:04.1 CardBus bridge: Texas Instruments PCI1130 (rev 04)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 08
Interrupt: pin B routed to IRQ 7
Region 0: Memory at 000e7000 (32-bit, non-prefetchable)
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: 10800000-10bff000 (prefetchable)
Memory window 1: 10c00000-10fff000
I/O window 0: 00008800-000088ff
I/O window 1: 00008c00-00008cff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00:06.0 IRDA controller: VLSI Technology Inc 82C147 (rev 02)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at 1000 [disabled]
02:00.0 Class ffff: Linksys Fast Ethernet 10/100 (rev ff) (prog-if ff)
!!! Unknown header type 7f
------
So there's a Reset- v a Reset+ there.
Curiously, the output after a suspend on mains is the same
(says diff) as the output after a suspend on battery, even
though the former doesn't stop it working while the latter
does.
> > ...
> > Sep 6 23:23:55 graffito kernel: Socket status: 2a035c8a
>
> It looks like the cardbus controller configuration wasn't correctly
> restored.
Indeed, though it always seems to give the same dodgy looking
status.
> --
> Russell King ([email protected]) http://www.arm.linux.org.uk/personal/
> Linux kernel maintainer of:
> 2.6 ARM Linux - http://www.arm.linux.org.uk/
Wish I still had an ARM...
--
J?n Fairbairn
On Wed, 10 Sep 2003, Russell King wrote:
> On Wed, Sep 10, 2003 at 10:22:32PM +0100, Jon Fairbairn wrote:
> > In short: I'm using an HP Ombibook 800CT, have started using
> > a Carbus PCMCIA network card and am losing the card after
> > suspends.
I had a similar problem with my OB800. It turned out the problem is the
BIOS maps the yenta memory window into legacy address range below 1MB.
What happens next is the host bridge doesn't restore the access to the
legacy area on pci. IIRC Linus' comment was it's not the hostbridge's
fault because mapping pci memory resource to legacy area would be bogus in
the first place.
> > but after "apm --suspend" I get the same except:
> >
> > Sep 6 23:23:55 graffito kernel: Socket status: 66012d18
> > ...
> > Sep 6 23:23:55 graffito kernel: Socket status: 2a035c8a
>
> It looks like the cardbus controller configuration wasn't correctly
> restored.
Yep, this is what happens fo me in the sitation above. And the next time
one inserts/ejects any card the box dies in interrupt storm because the
irq cannot be acknoledged.
The patch below is how I work around this issue: fixup to force the kernel
to forget the bogus mapping and create a new sane one. Works for me since
ages (2.4-test IIRC). Maybe it would help here too.
Martin
-----------------------
--- linux-2.6.0-test3/drivers/pci/quirks.c Sat Aug 9 10:01:57 2003
+++ v2.6.0-test3-md-ob/drivers/pci/quirks.c Sat Aug 9 11:49:26 2003
@@ -490,6 +490,54 @@
pci_write_config_dword(dev, PCI_CB_LEGACY_MODE_BASE, 0);
}
+/* BIOS might have mapped the cardbus memory resource to a bogus location
+ * in legacy memory area and the hostbridge somehow loses this window
+ * after pm-suspend (seen on OB800).
+ * We try to detect and fix this by re-assigning the resource if we
+ * find it mapped to legacy area <1M. But we don't try, if the (obsolete)
+ * MEM_TYPE_1M flag is set, just in case...
+ */
+
+static void __devinit quirk_cardbus_map(struct pci_dev *dev)
+{
+ u32 temp, extend;
+ struct resource *res;
+
+ if (dev->class != (PCI_CLASS_BRIDGE_CARDBUS << 8))
+ return;
+
+ res = &dev->resource[0];
+ if (!(res->flags & IORESOURCE_MEM))
+ return; /* not cardbus memory map */
+
+ /* done if already mapped above 1MB legacy area */
+ if (res->start >= 0x00100000UL)
+ return;
+
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &temp);
+
+ if (temp & PCI_BASE_ADDRESS_MEM_TYPE_64)
+ return; /* don't touch 64-bit mappings */
+
+ if (temp & PCI_BASE_ADDRESS_MEM_TYPE_1M) {
+ printk(KERN_DEBUG "%s: cardbus memory with obsolete 1M flag\n",
+ __FUNCTION__);
+ return;
+ }
+
+ /* re-read required size and flags from device */
+
+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, ~0UL);
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &temp);
+ extend = ~(u32)(temp & PCI_BASE_ADDRESS_MEM_MASK);
+
+ res->start = 0; /* will be mapped to new sane location */
+ res->end = res->start + extend;
+ res->flags = IORESOURCE_MEM;
+ if (temp & PCI_BASE_ADDRESS_MEM_PREFETCH)
+ res->flags |= IORESOURCE_PREFETCH;
+}
+
/*
* Following the PCI ordering rules is optional on the AMD762. I'm not
* sure what the designers were smoking but let's not inhale...
@@ -807,6 +855,7 @@
{ PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID, quirk_ide_bases },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_bridge },
{ PCI_FIXUP_FINAL, PCI_ANY_ID, PCI_ANY_ID, quirk_cardbus_legacy },
+ { PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID, quirk_cardbus_map },
#ifdef CONFIG_X86_IO_APIC
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_ioapic },
[please cc me as not subscribed]
On 2003-09-11 at 23:18+0200 Martin Diehl wrote:
> On Wed, 10 Sep 2003, Russell King wrote:
>
> > On Wed, Sep 10, 2003 at 10:22:32PM +0100, Jon Fairbairn wrote:
> > > In short: I'm using an HP Ombibook 800CT, have started using
> > > a Carbus PCMCIA network card and am losing the card after
> > > suspends.
>
> I had a similar problem with my OB800. It turned out the
> problem is the BIOS maps the yenta memory window into
> legacy address range below 1MB.
This appears to be the correct diagnosis. I applied your
patch to 2.4.22 and the Omnibook now correctly restarts the
network after a suspend. Vielen dank!
What's the status of a patch like this? It's obviously of
use to more than one person, and it took me a great deal of
time to find you and your solution -- I suspect fainter
hearted folk might just have given up and said "Linux
doesn't work with this combination of hardware" which would
have been a shame.
I haven't tried it with 2.6 yet; I don't normally get into
test kernels, but I might try out of curiosity. I'll post
the result if anyone indicates that it's a worthwhile thing
to do.
> Yep, this is what happens fo me in the sitation above. And
> the next time one inserts/ejects any card the box dies in
> interrupt storm because the irq cannot be acknoledged.
I think I got that too, at least, reinserting the card caused
a lockup. With the patch applied I can eject and reinsert,
which is fortunate because there seems to be another problem
where the card switches off when I switch VCs, but it's hard
to reproduce. (and inconvenient because /usr is on nfs on
this machine)
Thanks again,
J?n
--
J?n Fairbairn
Sorry for the delay...
On Sat, 13 Sep 2003, Jon Fairbairn wrote:
> > I had a similar problem with my OB800. It turned out the
> > problem is the BIOS maps the yenta memory window into
> > legacy address range below 1MB.
>
> This appears to be the correct diagnosis. I applied your
> patch to 2.4.22 and the Omnibook now correctly restarts the
> network after a suspend. Vielen dank!
You're welcome.
> What's the status of a patch like this? It's obviously of
> use to more than one person, and it took me a great deal of
> time to find you and your solution -- I suspect fainter
> hearted folk might just have given up and said "Linux
> doesn't work with this combination of hardware" which would
> have been a shame.
Well, I've sent it to lkml once or twice some years ago. It was apparently
lost in the noise and I personally didn't care much resending it because
nobody else reported a similar problem. So I've just included it in my
local patchset - just the "fixed and forget because nobody else reports
this problem" case ;-)
> I haven't tried it with 2.6 yet; I don't normally get into
> test kernels, but I might try out of curiosity. I'll post
> the result if anyone indicates that it's a worthwhile thing
> to do.
Right, except for some fuzz the patch should work with both 2.4 and 2.6 -
at least it does for me. I'm not sure if this is the best possible way to
work around the issue. But it does the job and I've taken considerable
care to avoid breaking other boxes.
Of course I personally have no objections wrt. including it in the
official tree. Russel, what do you think - do you want to apply it? Or
shall I send it to Greg directly?
> > Yep, this is what happens fo me in the sitation above. And
> > the next time one inserts/ejects any card the box dies in
> > interrupt storm because the irq cannot be acknoledged.
>
> I think I got that too, at least, reinserting the card caused
> a lockup. With the patch applied I can eject and reinsert,
> which is fortunate because there seems to be another problem
> where the card switches off when I switch VCs, but it's hard
> to reproduce. (and inconvenient because /usr is on nfs on
> this machine)
No idea - sounds strange to me. No such problem here with any of
serial_cs, pcnet_cs or orinoco_cs with my ob800 (neither 2.4 nor 2.6).
Martin
On Tue, Sep 16, 2003 at 11:13:54PM +0200, Martin Diehl wrote:
> Of course I personally have no objections wrt. including it in the
> official tree. Russel, what do you think - do you want to apply it? Or
> shall I send it to Greg directly?
I think it would be a good idea to forward it to Greg, especially if
Linus seemed to think the current behaviour is wrong. Certainly
allocating the yenta resources in the memory hole seems like a silly
thing to do.
> On Sat, 13 Sep 2003, Jon Fairbairn wrote:
> > I think I got that too, at least, reinserting the card caused
> > a lockup. With the patch applied I can eject and reinsert,
> > which is fortunate because there seems to be another problem
> > where the card switches off when I switch VCs, but it's hard
> > to reproduce. (and inconvenient because /usr is on nfs on
> > this machine)
>
> No idea - sounds strange to me. No such problem here with any of
> serial_cs, pcnet_cs or orinoco_cs with my ob800 (neither 2.4 nor 2.6).
The following patch may help to track down this problem. Assuming
Jon has sysfs mounted on /sys, there should be a bunch of files in
/sys/class/pcmcia_socket/*/* - if Jon could get those to me after
its gone wrong, it may be helpful.
I'll also see about merging a patch which fixes up the debugging
(and adds some more) so we can see what's going on.
--- orig/drivers/pcmcia/Makefile Mon Jun 23 11:51:13 2003
+++ linux/drivers/pcmcia/Makefile Sat Sep 6 16:39:24 2003
@@ -2,7 +2,7 @@
# Makefile for the kernel pcmcia subsystem (c/o David Hinds)
#
-obj-$(CONFIG_PCMCIA) += pcmcia_core.o ds.o
+obj-$(CONFIG_PCMCIA) += pcmcia_core.o ds.o pcmcia_debug.o
obj-$(CONFIG_YENTA) += yenta_socket.o
obj-$(CONFIG_I82365) += i82365.o
--- /dev/null Sat Apr 26 08:56:46 1997
+++ linux/drivers/pcmcia/pcmcia_debug.c Sat Sep 6 19:27:30 2003
@@ -0,0 +1,153 @@
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/device.h>
+
+#include <pcmcia/cs_types.h>
+#include <pcmcia/ss.h>
+#include <pcmcia/cs.h>
+#include <pcmcia/cistpl.h>
+
+#include "cs_internal.h"
+
+struct bittbl {
+ unsigned int mask;
+ const char *name;
+};
+
+#define BIT(x) { x, #x }
+
+static struct bittbl state_bits[] = {
+ BIT(SOCKET_PRESENT),
+ BIT(SOCKET_INUSE),
+ BIT(SOCKET_SUSPEND),
+ BIT(SOCKET_WIN_REQ(0)),
+ BIT(SOCKET_WIN_REQ(1)),
+ BIT(SOCKET_WIN_REQ(2)),
+ BIT(SOCKET_WIN_REQ(3)),
+ BIT(SOCKET_REGION_INFO),
+ BIT(SOCKET_CARDBUS),
+ BIT(SOCKET_CARDBUS_CONFIG),
+};
+
+static struct bittbl status_bits[] = {
+ BIT(SS_WRPROT),
+ BIT(SS_CARDLOCK),
+ BIT(SS_EJECTION),
+ BIT(SS_INSERTION),
+ BIT(SS_BATDEAD),
+ BIT(SS_BATWARN),
+ BIT(SS_READY),
+ BIT(SS_DETECT),
+ BIT(SS_POWERON),
+ BIT(SS_GPI),
+ BIT(SS_STSCHG),
+ BIT(SS_CARDBUS),
+ BIT(SS_3VCARD),
+ BIT(SS_XVCARD),
+ BIT(SS_PENDING),
+ BIT(SS_ZVCARD),
+};
+
+static struct bittbl conf_bits[] = {
+ BIT(SS_PWR_AUTO),
+ BIT(SS_IOCARD),
+ BIT(SS_RESET),
+ BIT(SS_DMA_MODE),
+ BIT(SS_SPKR_ENA),
+ BIT(SS_OUTPUT_ENA),
+};
+
+static int dump_bits(char *p, unsigned int val, struct bittbl *bits, int sz)
+{
+ char *b = p;
+ int i;
+
+ for (i = 0; i < sz; i++)
+ if (val & bits[i].mask)
+ b += sprintf(b, "%s ", bits[i].name);
+ *b++ = '\n';
+ return b - p;
+}
+
+static ssize_t show_skt_socket_vpp(struct class_device *dev, char *buf)
+{
+ struct pcmcia_socket *skt = dev->class_data;
+ return sprintf(buf, "%d\n", skt->socket.Vpp);
+}
+static CLASS_DEVICE_ATTR(socket_vpp, S_IRUSR, show_skt_socket_vpp, NULL);
+
+static ssize_t show_skt_socket_vcc(struct class_device *dev, char *buf)
+{
+ struct pcmcia_socket *skt = dev->class_data;
+ return sprintf(buf, "%d\n", skt->socket.Vcc);
+}
+static CLASS_DEVICE_ATTR(socket_vcc, S_IRUSR, show_skt_socket_vcc, NULL);
+
+static ssize_t show_skt_socket_flags(struct class_device *dev, char *buf)
+{
+ struct pcmcia_socket *skt = dev->class_data;
+ return dump_bits(buf, skt->socket.flags, conf_bits, ARRAY_SIZE(conf_bits));
+}
+static CLASS_DEVICE_ATTR(socket_flags, S_IRUSR, show_skt_socket_flags, NULL);
+
+static ssize_t show_skt_status(struct class_device *dev, char *buf)
+{
+ struct pcmcia_socket *skt = dev->class_data;
+ int status;
+
+ skt->ops->get_status(skt, &status);
+ return dump_bits(buf, status, status_bits, ARRAY_SIZE(status_bits));
+}
+static CLASS_DEVICE_ATTR(status, S_IRUSR, show_skt_status, NULL);
+
+static ssize_t show_skt_state(struct class_device *dev, char *buf)
+{
+ struct pcmcia_socket *skt = dev->class_data;
+ return dump_bits(buf, skt->state, state_bits, ARRAY_SIZE(state_bits));
+}
+static CLASS_DEVICE_ATTR(state, S_IRUSR, show_skt_state, NULL);
+
+static struct class_device_attribute *attrs[] = {
+ &class_device_attr_socket_vpp,
+ &class_device_attr_socket_vcc,
+ &class_device_attr_socket_flags,
+ &class_device_attr_status,
+ &class_device_attr_state,
+};
+
+static int pcmcia_debug_add_socket(struct class_device *class_dev)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(attrs); i++)
+ class_device_create_file(class_dev, attrs[i]);
+
+ return 0;
+}
+
+static void pcmcia_debug_remove_socket(struct class_device *class_dev)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(attrs); i++)
+ class_device_remove_file(class_dev, attrs[i]);
+}
+
+static struct class_interface pcmcia_debug_interface = {
+ .class = &pcmcia_socket_class,
+ .add = &pcmcia_debug_add_socket,
+ .remove = &pcmcia_debug_remove_socket,
+};
+
+static int __init pcmcia_debug_init(void)
+{
+ return class_interface_register(&pcmcia_debug_interface);
+}
+
+static void __exit pcmcia_debug_exit(void)
+{
+ return class_interface_unregister(&pcmcia_debug_interface);
+}
+
+fs_initcall(pcmcia_debug_init);
+module_exit(pcmcia_debug_exit);
--
Russell King ([email protected]) http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
2.6 ARM Linux - http://www.arm.linux.org.uk/
2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On 2003-09-16 at 23:56BST Russell King wrote:
> On Tue, Sep 16, 2003 at 11:13:54PM +0200, Martin Diehl wrote:
> > Of course I personally have no objections wrt. including it in the
> > official tree. Russel, what do you think - do you want to apply it? Or
> > shall I send it to Greg directly?
>
> I think it would be a good idea to forward it to Greg
That might please me :-)
> > On Sat, 13 Sep 2003, Jon Fairbairn wrote:
> > > I think I got that too, at least, reinserting the card caused
> > > a lockup. With the patch applied I can eject and reinsert,
> > > which is fortunate because there seems to be another problem
> > > where the card switches off when I switch VCs, but it's hard
> > > to reproduce. (and inconvenient because /usr is on nfs on
> > > this machine)
> >
> > No idea - sounds strange to me. No such problem here with any of
> > serial_cs, pcnet_cs or orinoco_cs with my ob800 (neither 2.4 nor 2.6).
I've experimented a bit more. With 2.4.22 the problem occurs
predictably if I initiate a suspend while displaying an X
console. The system resumes OK, but when I next change to a
text VC, the light goes out on the network card (and I get
swamped with log messages about nfs server not responding),
but I can clear it up by physically ejecting and reinserting
the network card. After that it's back to normal. I can't
see any clues in the logs -- as far as I can see the nfs
errors start without being preceded by any other error, and
inserting the card just brings it back up as if nothing had
been wrong.
> The following patch may help to track down this problem.
> Assuming Jon has sysfs mounted on /sys, there should be a
> bunch of files in /sys/class/pcmcia_socket/*/* - if Jon
> could get those to me after its gone wrong, it may be
> helpful.
I applied Martin's patch to 2.6.0-test5, and that seems to
solve the original problem. I also applied your patch, but
haven't had any luck getting the stuff from /sys. With
2.6.0-test5 patched like this (I didn't try it without your
patch, I'm afraid), if I initiate suspend from a text VC all
is fine, but if I initiate it from X, the machine suspends,
but when turned back on it just locks up with a blank
display. No apparent response to anything I do to the
keyboard, including magic sysrq :-(. Not mounting sysfs
doesn't change the behaviour AFAICT.
It's not exactly a show-stopper as bracketing the apm
sequence with appropriate calls to chvt avoids it.
I haven't tried your patch with 2.4 as it doesn't have
sysfs -- or is there some way of retrofitting it?
Cheers,
J?n
--
J?n Fairbairn [email protected]