#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