Date: Sun, 19 Aug 2001 09:14:52 -0400 From: Jonathan Chen <jon@FreeBSD.ORG> To: Sam Habash <the@llama.com> Cc: freebsd-gnats-submit@FreeBSD.ORG, mobile@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kern/24854: NEWCARD support for aironet driver an(4) Message-ID: <20010819091452.A86632@enterprise.spock.org> In-Reply-To: <20010818212011.A33879@llama.com>; from the@llama.com on Sat, Aug 18, 2001 at 09:20:11PM -0700 References: <20010817011103.A25841@llama.com> <20010818110728.A20719@enterprise.spock.org> <20010818092654.C28694@llama.com> <20010818124503.A26350@enterprise.spock.org> <20010818212011.A33879@llama.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[summary of past events for the benefit of gnats] - original PR filed for Cisco aironet not working under newcard - My LMC342 works just fine, and I though this might be a bug in newcard (as opposed to the an driver as suggested in the pr), suggested Sam to try the updated newcard (http://people.freebsd.org/~jon/newcard.diff.3) - this patch makes an work under newcard without the proposed changes in the pr. > I believe I already tried just uncommenting 'optional ata pccard' > with the -current source, without any luck. Sam, I'm not sure what you mean here. > The first time I tried it (not in X) removal and reinsertion of the > Aironet card was fine. > > The second time (while in X), removal was ok, but card reinsertion caused > a reboot (no panic)... > > Let me know what you want me to do exactly, in terms of what kind of > debugging you need...once I hear back I'll build a debug kernel. Are you sure there is no panic while in X? Your X server might have futzed with the video card so you might not actually see the panic. If you can try to reproduce this in text mode, then the panic message as well as a traceback would be a very good start. But before you do that, I believe I may have found a fix for a possible panic situation. This panic occurs in witness_destroy as a supervisor read page not present error (I presume while trying to dereference lock). This panic can be easily reproduced by running dhclient an0, removing and reinserting the card, then killing dhclient. The fix appears to be shockingly simple: diff -u -r1.8 if_an_pccard.c --- sys/dev/an/if_an_pccard.c 2001/05/26 09:26:58 1.8 +++ sys/dev/an/if_an_pccard.c 2001/08/19 12:57:14 @@ -118,6 +118,7 @@ sc->an_gone = 1; bus_teardown_intr(dev, sc->irq_res, sc->irq_handle); an_release_resources(dev); + mtx_destroy(&sc->an_mtx); return (0); } Here's where I require some guidance from someone in the know. While this patch appears to avoid the problem on my system, does it in fact work? How does the panic occur and how does this fix the problem, if indeed it does? I'm quite clueless as to the implementation of mutex locking on freebsd, and I suppose it's just plain luck that the first thing I tried turned out to have done the trick... -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010819091452.A86632>