Most recent kernel where this bug did not occur: 2.6.12.4 Distribution: Debian/unstable Hardware Environment: c.f. cardbus bridge in lspci output below + Enterasys RoamAbout pcmcia card (http://www.enterasys.com/products/wireless/RBTBG-AW/) Software Environment: 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 minutes). 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 e5c0|1|0], AE_TIME 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 2.6.12.4): % lspci 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 Controller (PHY/Link) 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 2.6.12.4): % cat /proc/interrupts CPU0 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, radeon@pci:0000:01:05.0 11: 30217 XT-PIC yenta, ehci_hcd:usb3, ath0 12: 123 XT-PIC i8042 14: 12041 XT-PIC ide0 15: 18242 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 1 MIS: 0 Steps to reproduce: Run 2.6.13-rc* serie and insert a network card in a similar h/w than mine Cheers, JD.
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 [139] os_wait_semaphore : Failed to acquire semaphore[ebf6e700|1| 0],AE_TIME 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).
Dear Sanjoy, 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! Cheers, JD.
> 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 2.6.12.4. 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. Cheers! JD.
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-2.6.13.4 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 bug, though. Thanks, Regards, Jean-Damien.
The bug hit me a few days ago, when I upgraded from 2.6.12 to 2.6.14 (debian kernels). I use pcmcia-cs, since pcmciautils is not yet packaged. See http://lists.debian.org/debian-powerpc/2005/10/msg00548.html for more information. 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?!) Eugen
I am happy with pcmciautils010 and linux 2.6.13.4. 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). Cheers, JD.
Bug seems to be closed (cf. comment #16 ) -- if this impression is wrong, please re-open.