Date: Thu, 27 Mar 2008 11:30:14 +0800 From: Kevin Lo <kevlo@FreeBSD.org> To: Alphons Fonz van Werven <a.j.werven@student.utwente.nl> Cc: Matthias Apitz <matthias.apitz@oclc.org>, Sam Leffler <sam@FreeBSD.org>, freebsd-mobile@FreeBSD.org Subject: Re: 7.0-RELEASE && panic after ~4 hours Message-ID: <1206588614.6146.23.camel@monet> In-Reply-To: <47EAAEB8.6000204@freebsd.org> References: <20080326124324.GA1756@rebelion.Sisis.de> <47EA53D5.4070106@student.utwente.nl> <47EA73D9.6050302@freebsd.org> <47EA8949.9070700@student.utwente.nl> <47EA8E43.1080308@freebsd.org> <47EA94AD.5010400@student.utwente.nl> <47EAAEB8.6000204@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On δΈ‰, 2008-03-26 at 13:14 -0700, Sam Leffler wrote: > Alphons "Fonz" van Werven wrote: > > Sam Leffler wrote: > > > >> You said there were panics; please point me at PR's that show them > > > > See below. > > > >> Understand that most all Intel wireless cards up to the 4965 have issues > >> with firmware mis-design that make developing reliable drivers hard > >> (even > >> more so given Intel's unwillingness in helping anyone not using linux). > > > > I'm aware of that. Therefore, it wasn't my intent to criticise, merely to > > observe. > > > >>> rum: Works but panics after a while. PR has been filed, but seems to > >>> be stuck at feedback status (anyone know more about this one?). > > > >> PR #? Unfortunately my rum card seems to have vanished. The > >> committer looking after rum has been occupied which may explain the > >> inaction. > > > > kern/120966 > > > > The PR was sent by somebody else, but I have the same problem and I can > > reproduce it, so if any additional info is needed I'd be more than happy > > to provide it. > > Looks like the driver isn't clearing pending xfer's properly. > Unfortunately this is a good example of how there's insufficient info to > make progress; the output of wpa_supplicant -d and/or wlandebug > state+scan would help a lot (the latter more than the former). > > Unfortunately I can't do much until I locate my stick. Hopefully Kevin > will re-appear and look at the issue. Sorry to reply so late because I'm busy with my work. The backtrace of the kernel panic you got shows that the variable priv/data itself is null in rum_txeof() so the added check for data->m is a null pointer dereference itself. Would you simply add a null pointer to check for data/priv to the rum_txeof() function and see whether it improves the situation? Thanks. > Sam Kevin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1206588614.6146.23.camel>