Openmoko Bug #2327: wifi sometimes fails to start with "ar6000_activate: Failed to activate -4" when DEBUG_KERNEL/PREEMPT are disabled

[Openmoko Public Trac]

#2327: wifi sometimes fails to start with "ar6000_activate: Failed to activate -4"
when DEBUG_KERNEL/PREEMPT are disabled
-----------------------------+----------------------------------------------
 Reporter:  lindi            |          Owner:  openmoko-kernel
     Type:  defect           |         Status:  new            
 Priority:  normal           |      Milestone:                 
Component:  System Software  |        Version:                 
 Severity:  normal           |       Keywords:                 
 Haspatch:  0                |      Blockedby:                 
Estimated:                   |    Patchreview:                 
 Blocking:                   |   Reproducible:  sometimes      
-----------------------------+----------------------------------------------

Comment(by gena2x):

 I reviewed this problem, first i got as close to cause of problem as
 following:

 The s2c sdi driver is getting syncronous (not from any thread) write
 request from ar6000 driver, but get "error: data timeout" from host sdio.
 Request seem to disable interrupts on device ( __DevDisableInterrupts__
 function). As this request is part of initializations, whole
 initialization fails.

 This happens in process of initialization. enabling any debug messages
 eliminates this error, as they seem add required delay.

 Real case of error is not available on level of as some different errors
 are hidden under 'EILSEQ' Illegal byte sequence. This cause is available
 on lowest level of ar6000  - process_request function which calls sdio
 level functions.

 I saw two ways to fix problem:

 1. for the first request, retry the request if is fails.
 2. add some delay to initalization sequence.

 way (1) look better, in fact, first i added code to process_request to
 retry attempt, and that seem worked, but it turned out that this require
 relatively large patch to find place where to store the state that this
 request is first. Other variant was to retry any write request, which
 fails with same error and print some kernel message to check that we have
 no problems with such requests, and keeping in mind that for some kinds of
 requests return value is not even checked. But is bad solution, as where
 is some other kind of errors where retry is not need.

 way (2) this way was considered as solution at all because of following
 comment in code:
  * - Atheros call deviceInsertedHandler from a thread spawned off the
 probe or
  *   device insertion function. The original explanation for the Atheros
 SDIO
  *   stack said that this is done because a delay is needed to let the
 chip
  *   complete initialization. There is indeed a one second delay in the
 thread.
  *
  *   The Atheros Linux SDIO HIF removes the delay and only retains the
 thread.
  *   Experimentally removing the thread didn't show any conflicts, so
 let's get
  *   rid of it for good.

 So, as we are not willing one second as delay - I added just 10millisecond
 delay, and this works fine. Why 10milliseconds? it seems large enough for
 device (according to tests) and negligible for suspend/resume and normal
 boot. Review and comments are welcome.

 So, I propose simple patch attached to fix problem.  It have advantage
 that it's simple and will not harm anything in any case.

 Until any other solution will be found or review done, i'll include it to
 my kernel build, which is available at:
 http://www.bsdmn.com/openmoko/kernel/optim-stage2/ . This kernel include
 nodebug/nopreempt options.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2327#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac