#8301 BLOC 8.2.0 (: Fast suspend/resume cycle causes a libertas crash

[Zarro Boogs per Child]

#8301: Fast suspend/resume cycle causes a libertas crash
------------------------+---------------------------------------------------
   Reporter:  cjb       |       Owner:  dsaxena                        
       Type:  defect    |      Status:  new                            
   Priority:  blocker   |   Milestone:  8.2.0 (was Update.2)           
  Component:  kernel    |     Version:  not specified                  
 Resolution:            |    Keywords:  blocks-:8.2.0 cjbfor8.2 relnote
Next_action:  diagnose  |    Verified:  0                              
  Blockedby:            |    Blocking:                                 
------------------------+---------------------------------------------------

Comment(by dcbw):

 lbs_stop_card() should be clearing out any in-flight commands, and the
 driver should also be failing command prep if priv->surpriseremoved == 1,
 which is done in __lbs_cmd_async() for direct commands and
 lbs_prepare_and_send_command() for old-style commands.  So there
 definitely shouldn't be any commands getting through after
 if_usb_disconnect().

 But the command 6 (SCAN) surely is coming from earlier since nothing in
 the disconnect path will call scan, since there isn't any indication of a
 WEXT scan request coming in, and since there isn't any indication of an
 association request (which triggers a scan) coming in either.

 scan.c::lbs_do_scan() calls cmd.c::__lbs_cmd(CMD_802_11_SCAN), which then
 blocks on cmdnode->cmd_waitq.  When lbs_stop_card() cycles through all the
 commands in the queue and stops them,

 Argh.  I forgot about LBS_DEB_HOST, which is what most of the command code
 uses when queuing commands.  I hate to ask, but could you get another log
 with 0x126007 (which adds LBS_DEB_HOST) and also see if you can retrieve
 about 15 - 20 seconds of earlier logging before the stuff that you've
 attached so far?  That should be enough to show us where the actual
 command that's in-flight at the time of disconnect is getting queued, and
 if it's successfully blocking on its cmdnode waitq.  Thanks!

-- 
Ticket URL: <http://dev.laptop.org/ticket/8301#comment:34>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system