Kernel Bug Tracker – Bug 5017
pcmcia: trouble inserting network card and then network unstability
Last modified: 2005-11-15 08:57:21 UTC
Most recent kernel where this bug did not occur: 18.104.22.168
Hardware Environment: c.f. cardbus bridge in lspci output below + Enterasys
RoamAbout pcmcia card (http://www.enterasys.com/products/wireless/RBTBG-AW/)
Problem Description: pcmcia card not seen at first insert, seen at 2nd insert
but then network instability (debian/waproamd searching for the AP every 2/3
Under 2.6.13-rc* (I verified with 2.6.13-rc1 and also with latest as of today,
i.e. 2.6.13-rc5-git4); if I insert my network card (driven by madwifi external
module), using network works for some seconds, 1 mn max, and then the system
seems to loose connection to the AP, debian/waproamd start to search again for
an AP, network comes back; etc.
I have seen nothing particular in /var/log/syslog except:
os_wait_semaphore : Failed to acquire semaphore[ebf6
I am unfortunately not at all a kernel hacker, don't know why this is
happening - but I hope I can help to find!
Here is my lspci (as of 22.214.171.124):
0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device cbb2 (rev 02)
0000:00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M]
0000:00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link
Controller Audio Device (rev 02)
0000:00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV]
0000:00:08.0 Modem: ALi Corporation M5457 AC'97 Modem Controller
0000:00:0a.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller
0000:00:0b.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50)
0000:00:0b.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50)
0000:00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
0000:00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000
0000:00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
0000:00:11.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
0000:00:12.0 Ethernet controller: National Semiconductor Corporation DP83815
(MacPhyter) Ethernet Controller
0000:01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 340M
0000:02:00.0 Ethernet controller: Atheros Communications, Inc. AR5212
802.11abg NIC (rev 01)
My interrupts (as of 126.96.36.199):
% cat /proc/interrupts
0: 1644859 XT-PIC timer
1: 5528 XT-PIC i8042
2: 0 XT-PIC cascade
5: 285 XT-PIC ALI 5451
7: 3 XT-PIC parport0
9: 535 XT-PIC acpi
10: 177305 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2, ohci1394, eth1,
11: 30217 XT-PIC yenta, ehci_hcd:usb3, ath0
12: 123 XT-PIC i8042
14: 12041 XT-PIC ide0
15: 18242 XT-PIC ide1
Steps to reproduce:
Run 2.6.13-rc* serie and insert a network card in a similar h/w than mine
Created attachment 5535 [details]
/var/log/syslog showing waproamd scanning again and again for an AP
Strangely I do not see the "osl : wait for semaphore" error in my latest try.
Nevertheless network instability is still here.
Here is the /var/log/syslog of a kernel compiled with pci and pcmcia debug.
Search for "HERE" in this attachment.
Created attachment 5536 [details]
my /proc/interrupts as of 2.6.13-rc5-git4
Created attachment 5537 [details]
my /proc/pci as of 2.6.13-rc5-git4
Created attachment 5538 [details]
my /proc/iomem as of 2.6.13-rc5-git4
Created attachment 5539 [details]
my /proc/ioports as of 2.6.13-rc5-git4
Created attachment 5540 [details]
my /proc/version as of 2.6.13-rc5-git4
FYI, I tried with 2.6.13-rc6 - same thing: AP found, network available for few
seconds, and then AP search again, etc.
An update with 2.6.13-rc5-mm1. The network card is not seen at startup, and
after few seconds there is:
osl-0884  os_wait_semaphore : Failed to acquire semaphore[ebf6e700|1|
When I get the card out there is:
cs: pcmcia_socket0: parse_events: events 00000080
> An update with 2.6.13-rc5-mm1. The network card is not seen at startup, andI
I mean: is not seen when I insert it. Sorry.
I also see those semaphore errors: See Bug #5008 and the C program attached
there to reliably generate those errors. From a fair amount of testing, I find
that the errors correlate with running a pre-emptible kernel: the
non-preemptible kernels don't show it, and the voluntary preempt or fully
preemptible ones do.
Which I suspect is also correlated with S3 sleep hanging on my thinkpad (Bug #5037).
Did not thought to preemption, so thanks! Will give it a try.
Before that, I am doing rc6-git5 with a lot of debug flags turned on;
suspecting irq routing - personal printk()s in pci and pcmcia indicated they
were not called.
Thanks again for your update; hoping progress for your reports!
> personal printk()s in pci and pcmcia indicated they were not called.
I meant: not called when I insert the card. Which the first thing that differ
compared to 188.8.131.52. Finding why might help resolve the rest - who knows.
Trying to isolate where is going the irq and/or if it seen is my first goal!
Not being a knowledgable person about kernel is not a plus - but that's ok -
time to learn.
Played with preemption - no go - Not tried official 2.6.13 yet.
In the meantime my enterasys card got broken by my daughter...!
Will use a linksys wpc54g card from now on.
Tried with linux-184.108.40.206 and pcmciautils 010 : still I have to insert the
card twice _but_ network looks stable.
I guess this bug report now resumes only to the fact that the card has to be
inserted twice, which is a minor issue for me... You might want to close this
Thanks, Regards, Jean-Damien.
The bug hit me a few days ago, when I upgraded from 2.6.12 to 2.6.14 (debian
I use pcmcia-cs, since pcmciautils is not yet packaged.
See http://lists.debian.org/debian-powerpc/2005/10/msg00548.html for more
Additionnally, I cannot remove/reinsert the card (Cisco 350 series), because
almost everytime the computer freezes. (The computer freezes generally also on
resuming from sleeping, is this due to Cisco driver?!)
I am happy with pcmciautils010 and linux 220.127.116.11.
Packaging a minimal pcmciautils (i.e. no *cis file, no special setup - just
the udev facts) is not that hard (this is what I did).
Bug seems to be closed (cf. comment #16 ) -- if this impression is wrong, please