Hi all, i have some problems/questions regarding the airo.c driver used in conjunction with cisco air-pcm352 (pcmcia) cards. The driver i am using is the one from pcmcia-cs-3.1.34, which seems to be identical to the one in the linux-2.4.18 source tree in the "critical" parts. First, the general performance is very low, although the card is located in a PCI-PCMCIA-Bridge (Ricoh R5C475), it seems that tha transfer speed of packets to the card is about 2MB/s, which gives about 30% CPU load on a 300MHz Geode CPU when receiving a maximum-rate multicast stream... Transmit is about the same cpu hog. I guess there can be nothing done about this, it is the usual "PCMCIA is ISA-PNP is crap" scenario... What really disgusts me is that interrupts are disabled during the whole transmit (and receive, but i did not try to fix the latter yet) sequence, resulting in a HUGE interrupt latency, because interrupts are disabled for something like 800microseconds then. What i did now is: - change the spin_lock_irqsave to spin_lock in airo_start_xmit - change the spin_lock_irqsave to spin_lock in issuecommand (probably not the bad one here) - inserted OUT4500( priv, EVINTEN, EV_TX|EV_TXEXC ); in airo_start_xmit directly after the spin_lock, and OUT4500( priv, EVINTEN, STATUS_INTS ); after spin_unlock - used EVINTEN (== savedInterrupts) in airo_interrupt to handle only TX/TX_EXC interrupts during this "locked" stage The driver works quite fine like this, interrupt latency is vastly improved, and also transmit performance seems to be slightly better. But, what happens is that from time to time - after 1 hour, or 2 days, no real "sequence" to be seen - i get a "BAP setup error" for the transmit BAP, and the card locks up until i reload the driver. I could not yet reproduce this with the original driver, but tried to further diagnose the problem, but i still can not see a plot. There is no special short or long period to the last transmitted packet, neither an interrupt happening during the bap_setup runtime. Is there anybody familiar with the card/firmware and has an idea? Also a workaround for resetting the card from this state would be nice. I tried calling setup_card after 10 consecutive BAP setup errors, but up to now the error condition was not met again, so i don't know about the effect. :) Thanks, Wolfgang - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
