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

Zarro Boogs per Child bugtracker at laptop.org
Sat Sep 6 18:19:42 EDT 2008


#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):

 Replying to [comment:26 dsaxena]:
 >
 > The command we are seeing timeout is 1d, which is an RF_CHANNEL, and in
 the previous logs it was 6, which is a SCAN. Are we also possibly still
 accepting commands from network manager once we get the USB disonnect? Or
 are those leftovers from the insmod/resume path that did not get processed
 before we shutdown power?

 SCAN commands are definitely left around from before; the driver isn't
 clearing the command queue correctly.  There's work to be done with
 command handling; priv->cur_cmd_retcode and cmdnode->result are all
 muddled together and used interchangably in some places.  I'll try to fix
 that up.

 RF_CHANNEL (set) only ever gets called from the association worker code as
 a result of WEXT calls. RF_CHANNEL (get) only gets called from WEXT code,
 or from the mesh autostart code when the firmware sends
 MACREG_INT_CODE_MESH_AUTO_STARTED, to ensure the driver and firmware agree
 on a channel.

 I think that (besides the async MAC_CONTROL commands) all the commands
 we're seeing here are in-flight commands that aren't properly canceled
 while tearing down the driver.

 cjb: any chance you can reproduce the failed suspend with the ~20s hang?

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


More information about the Bugs mailing list