> > OK. IRQ11 looks like it's shared, don't know if that makes any difference: > > $ dmesg | grep -i "irq.*11" > pci_link0: <ACPI PCI Link LNKA> irq 11 on acpi0 > pci_link3: <ACPI PCI Link LNKD> irq 11 on acpi0 > uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xcce0-0xccff irq 11 at device 7.2 on pci0 > ifpi0: <AVM Fritz!Card PCI> port 0xdce0-0xdcff mem 0xfafffc00-0xfafffc1f irq 11 at device 9.0 on pci2 > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xcc00-0xcc7f mem 0xff201000-0xff20107f irq 11 at device 17.0 on pci0 > $ > > (xl0 is the main "uplink" interface for this system, so there's quite a bit > of traffic on it) > > Now, as you suggested I moved the card to a different PCI slot, at the same > time taking out the ISDN card which was also in there, and hey presto I get > a whole load of stuff logged! Nobody ever tries the simple stuff first. > ndis0: <NETGEAR WG311v2 802.11g Wireless PCI Adapter> mem 0xfaffe000-0xfaffffff,0xfafc0000-0xfafdffff irq 11 at device 9.0 on pci2 > ndis0: [GIANT-LOCKED] > ndis0: NDIS API version: 5.1 > ndis0: Ethernet address: 00:0f:b5:45:fb:ae > Sleeping on "ndissp" with the following non-sleepable locks held: > exclusive sleep mutex ndis softc lock (network driver) r = 0 (0xc1a72db4) locked _at_ /export/src/5.3-RELEASE/usr/src/sys/compat/ndis/kern_ndis.c:1098 > KDB: stack backtrace: > kdb_backtrace(1,1,1,c1a8f600,c17c0000) at kdb_backtrace+0x29 > witness_warn(5,c0a26e40,c08c0506,c08de706) at witness_warn+0x19a > msleep(c1a8f738,c0a26e40,0,c08de706,0) at msleep+0x42 > ndis_thsuspend(c1a8f600,c0a26e40,0) at ndis_thsuspend+0x34 > KeWaitForSingleObject(c154425c,0,0,1,0,c154424c,0,0) at KeWaitForSingleObject+0x1f9 > KeFlushQueuedDpcs(c1794000,fe,480,c1a72000,d1577b48) at KeFlushQueuedDpcs+0x41 Bleh. Ok, I can fix that by moving the timer reaping code outside the NDIS_LOCK()ed region. > I thought it wasn't actually working: > > $ ifconfig ndis0 > ndis0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 > ether 00:0f:b5:45:fb:ae > media: IEEE 802.11 Wireless Ethernet autoselect > status: no carrier > ssid "" > authmode OPEN privacy OFF txpowmax 100 > $ ifconfig ndis0 scan > $ > > until I did 'ifconfig ndis0 up', and at that point I can see wireless > networks (although 'ifconfig ndis0' still logs 'ndis0: failed to get bssid' > each time) Uh... yeah. Bear in mind people: the card is _NOT_ running until you call the MiniportInitialize() function in the Windows driver via ndis_init_nic(), and that only happens when you bring the interface up. The ndis_attach() routine will call ndis_init_nic() once in order to be able to query the device's capabilities and read its station address, but it will bring it back down by calling MiniportHalt() as soon as it's done, and leave it that way until you bring it up. Among other things, this means that for wireless cards the radio will be kept off until the user is ready to turn it on. > On my first attempt strangely I was also getting a whole bunch of fxp0 > command queue timeout, SCB timeout, device timeout and DMA timeout errors > (even though I didn't touch anything to do with fxp0). Next tried moving the > Netgear to a different PCI slot again, and putting the ISDN card back where > it was. I get the same ndis0 behaviour as above (non-sleepable lock, lock > order reversal), but no fxp0 errors. > > Oh well, this gives me something more to play with... I didn't realise PCI > was so weird, thanks for the suggestion :-) That's nothing: I've had it happen that perfectly good cards that had been sitting around on the shelf for a while would not work, until I scraped/cleaned the oxidation off their edge connector contacts. > Afraid I can't help you with 6-snapshot servers; I did a 5.3-RELEASE install > then a cvsup / makeworld. Takes a good 5 hours on this old system :-( > > Regards, > > Brian. I'll have to experiment a bit later to fix the locking issues. Not sure what I can do about the WPA-PSK stuff though since I didn't write it, and I don't have a test environment set up to experiment with it. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul_at_windriver.com | Wind River Systems ============================================================================= <adamw> you're just BEGGING to face the moose =============================================================================Received on Tue May 10 2005 - 13:48:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:34 UTC