7.0-RELEASE && panic after ~4 hours

[Kevin Lo]

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