#12694 NORM Future : page allocation failure, mwifiex

[Zarro Boogs per Child]

#12694: page allocation failure, mwifiex
------------------------------+---------------------------------------------
           Reporter:  Quozl   |       Owner:                          
               Type:  defect  |      Status:  new                     
           Priority:  normal  |   Milestone:  Future Release          
          Component:  kernel  |     Version:  Software Build 13.2.0-13
         Resolution:          |    Keywords:                          
        Next_action:  design  |    Verified:  0                       
Deployment_affected:          |   Blockedby:                          
           Blocking:          |  
------------------------------+---------------------------------------------
Changes (by Quozl):

 * cc: dsd (added)
  * next_action:  diagnose => design


Comment:

 Analysis: the driver is responding to an interrupt from the wireless card,
 the interrupt is for arriving data, and a memory allocation made at the
 time of the interrupt fails because the system is out of memory.  The
 remainder of the job of reading the data from the card does not occur.
 The card is left in an inappropriate state.  Further commands time out.
 powerd forks ethtool which hangs in D state.  powerd does not recover,
 leaving the display off but the power indicator on.

 A few things were looked at:
  * the failure is in drivers/net/wireless/mwifiex/sdio.c where the
 function mwifiex_process_int_status calls dev_alloc_skb,
  * there are no new changes to sdio.c in upstream kernel.org,
  * none of the changes in git seemed to relate to the problem,
  * to gather more data, sdio.c was changed to report allocation size;
 allocations for 256 bytes and 1792 bytes were seen; not unremarkable, and
 seems sane,
  * as speculation, sdio.c was changed to write 0x04 to configuration
 register as nearby code does; there was no change to symptom.

 Speculation:
  * the wrong memory allocation technique is being used, (but my knowledge
 of the available techniques is insufficient),
  * the actions required to read the packets and dismiss the interrupt
 might be done even if memory cannot be allocated, losing the data, but at
 least the card should be left in a usable state.

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