#7973 BLOC 8.2.0 (: libertas unknown event IDs and hang

Zarro Boogs per Child bugtracker at laptop.org
Mon Aug 25 15:35:11 EDT 2008


#7973: libertas unknown event IDs and hang
------------------------+---------------------------------------------------
   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        
Next_action:  diagnose  |    Verified:  0                   
  Blockedby:            |    Blocking:                      
------------------------+---------------------------------------------------

Comment(by dcbw):

 We need documentation of these internal firmware dependencies then.  The
 specs don't say much here, except in section 2.2 (Driver and Firmware
 After Card Insertion) which _might_ indicate how it's supposed to work but
 is highly unclear with respect to post-insertion operations.

 A few questions:

 - Is a scan required after every CMD_802_11_DEAUTHENTICATE command?
 - What is the host driver supposed to do if the DEAUTH command returns an
 error?  Retry the command after a timeout?  If so, how long should that
 timeout be?
 - Do any of the Marvell-provided drivers handle an error response from
 DEAUTHENTICATE?

 I checked the original 8388 code drop, the
 SD-8686-FEDORA26-8.73.7.p3-26340P58 driver, and the moblin.org v9 driver,
 and the gumstix cf8385 5.0.13 driver, and none of them do anything
 different from the libertas driver after failure of a DEAUTHENTICATE
 command.  They don't even run the code that resets the internal driver
 state to disconnected.  What should be happening here in the driver?

 If the driver requires certain steps to be performed in a specific order,
 or the commands have interdependencies, then those need to be documented
 in the specification much like the sequence of RSN setup is documented in
 v5.1 section 7.1.1.  Otherwise, there's no way we can ever figure out how
 to work correctly with binary firmware drops.

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


More information about the Bugs mailing list