linux-kernel - Re: SDIO driver not receiving responses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080207205136.1a38f4fe@poseidon.drzeus.cx>
Date:	Thu, 7 Feb 2008 20:51:36 +0100
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Farbod Nejati <farbodn@...icrosystems.com>
Cc:	Philip Ryan <Philip.Ryan@...icrosystems.com>,
	linux-kernel@...r.kernel.org,
	"Chad O'Neill" <chad@...icrosystems.com>,
	Tom McDermott <tom.mcdermott@...icrosystems.com>
Subject: Re: SDIO driver not receiving responses

Don't hijack threads, it completely messes up everyone's mail box and makes your mail very difficult to find.

On Thu, 31 Jan 2008 17:35:51 +1100
Farbod Nejati <farbodn@...icrosystems.com> wrote:

> The mmc_send_io_op_cond() function call in core.c::mmc_rescan() is 
> returning with a -110 (a timeout error). I traced this deeper and 
> noticed that CMD5 is being sent out via sdhci.c::sdhci_send_command() (I 
> verified this using a logic analyser, the host *is* transmitting a CMD5 
> [IO_SEND_OP_COND] packet in the correct format). However, when the 
> client responds with the IO_SEND_OP_COND Response R4 (SD mode), it does 
> not seem to be received by the host. Again, I verified using the logic 
> analyser that the response is as would be expected. An IRQ *is* 
> triggered, however it is 0x00018000 (SDHCI_INT_TIMEOUT|SDHCI_INT_ERROR). 
> I'm not too familiar with Linux kernel programming but I suspect that 
> whatever is waiting for a valid response is giving up instead and 
> triggering the above-mentioned interrupt instead.

That would be the hardware. We don't do any software timeout handling.

Have you checked the time from command to reply with the logic analyser? The chip might simply be out of spec.

> 
> Why would the output of the above code differ from the one produced by 
> lspci -xxx. Could this have something to do with this issue???
> 

lspci shows you the PCI config space, not the device io space, which is what your code dumped. ;)

> 
> I'm fresh out of ideas on this one and would greatly appreciate some 
> hints or assistance. I'm happy to provide any further information if needed.
> 

I can only see one of two options here. Either there is some miscalculation of the timeout, or you have a hardware bug. And to determine that we need to check what is actually going over the wire. As you've checked the data contents, that isn't the problem. So the only remaining thing is checking the timing.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/