#12657 NORM 13.2.0: Fix btmrvl/mwifiex suspend interactions

Zarro Boogs per Child bugtracker at laptop.org
Wed May 22 17:11:28 EDT 2013


#12657: Fix btmrvl/mwifiex suspend interactions
------------------------------+---------------------------------------------
           Reporter:  dsd     |       Owner:  pgf          
               Type:  defect  |      Status:  new          
           Priority:  normal  |   Milestone:  13.2.0       
          Component:  kernel  |     Version:  not specified
         Resolution:          |    Keywords:               
        Next_action:  code    |    Verified:  0            
Deployment_affected:          |   Blockedby:               
           Blocking:          |  
------------------------------+---------------------------------------------

Comment(by dsd):

 I don't think there is a race condition with async cancellation of host
 sleep and other commands - commands are still submitted in order, even if
 an async one comes first. Even if there is a race here, we have not found
 the concrete details that would explain a hang like this.

 The is_suspended change seems to have its effect in that it disables half
 of the mwifiex_sdio_resume handler. Its also not really clear why that
 helps things.

 I am also finding that adding printks here and there (or enabling
 no_console_suspend) makes the bug go away. So without good diagnosis I am
 not sure if the above 2 changes have any significance other than they
 affect the timing in small ways.

 On IRC you said that the hang happens in netif_carrier_off (called from
 mwifiex_remove_card) and I have also reproduced the hang there a few
 times. I've also seen it move around slightly though. Anyway, digging down
 through the layers I get to the first call to schedule_delayed_work() in
 linkwatch_schedule_work() - that never returns. I haven't gone further,
 since I suspect more and more that the problem isn't actually in this code
 at all.

 Maybe the kernel is switching to another task at this time, which hangs
 the system. Indeed, disabling kernel preemption does make the problem go
 away as well. But no doubt that also changes timings, so there is a chance
 this is also an irrelevant detail.

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


More information about the Bugs mailing list