Openmoko Bug #1983: eth0 doesn't exist / Oops during bootup

Openmoko Public Trac bugs at docs.openmoko.org
Thu Sep 11 21:23:47 CEST 2008


#1983: eth0 doesn't exist / Oops during bootup
----------------------------+-----------------------------------------------
    Reporter:  Weiss        |        Owner:  openmoko-devel
        Type:  defect       |       Status:  new           
    Priority:  normal       |    Milestone:                
   Component:  unknown      |      Version:                
    Severity:  normal       |   Resolution:                
    Keywords:  wifi kernel  |    Blockedby:                
Reproducible:  always       |     Blocking:                
----------------------------+-----------------------------------------------

Comment(by werner):

 Thanks for the logs ! It seems that the complaints only start after the
 SDIO stack has already decided that there is a WLAN device. I.e., after
 it has accessed the module.

 The command it was trying to issue is a read operation that normally
 follows a sequence of other read operations, and is roughly the 146th
 command sent to the device. So basic communication appears to work.

 The switch from a 1-bit bus to the 4-bit bus happens much earlier,
 around the 36th command. So it seems that this was uneventful.

 What does happen around that time is that the function is activated.
 (IOE1 is set in CCCR.) The failing access is still for the CCCR,
 though.

 So it appears that enabling the function upsets your WLAN module such
 that it either completely fails to communicate over SDIO, or that it
 sends information the SDIO stack is unhappy with (after which it tries
 to remove the device, causing the Oops).

 So this would make the operation that sometimes begins the string of
 timeouts the call to Cmd52ReadByteCommon following the call to
 Cmd52WriteByteCommon in the function SDEnableFunction in
 drivers/sdio/stack/busdriver/sdio_bus_misc.c

 The "silent" failure path (i.e., no timeout messages) is probably
 the error exit where SDEnableFunction sets status =
 SDIO_STATUS_FUNC_ENABLE_TIMEOUT. This theory could be confirmed by
 putting a printk there.

 If this is only a temporary confusion, e.g., a race condition inside
 the WLAN module, perhaps adding a delay(10) after Cmd52WriteByteCommon
 might help.

 Otherwise, this still looks like a defective WLAN module.

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


More information about the buglog mailing list