linux-kernel - Re: [Regression?] qemu-system-arm flooding "sd_write

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] [day] [month] [year] [list]

Date:	Tue, 15 Apr 2014 22:40:52 +0100
From:	Peter Maydell <peter.maydell@...aro.org>
To:	Ulf Hansson <ulf.hansson@...aro.org>
Cc:	John Stultz <john.stultz@...aro.org>,
	Chris Ball <chris@...ntf.net>,
	Johan Rudholm <jrudholm@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Regression?] qemu-system-arm flooding "sd_write_data: not in
 Receiving-Data state"

On 15 April 2014 08:26, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> Though, maybe you can provide me with some information about the qemu
> environment you are using?
>
> 1. Especially, what variant of the ARM primcell pl180 is being
> modelled/used here? The mmci driver handles a handful of different
> variants.

QEMU's device modelling is not generally sufficiently accurate
to make this a very meaningful question :-) We model a PL181,
but we will inevitably behave differently from h/w one way or another.
(Most notably, data read/write operations will complete instantaneously,
whereas on real h/w there's always some delay. There's also a hack
in the pl181 model working around a Linux 2.6.x driver bug:
    /* The linux 2.6.21 driver is buggy, and misbehaves if new data arrives
       while it is reading the FIFO.  We hack around this be defering
       subsequent transfers until after the driver polls the status word.
       http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4446/1
     */
I hate those, because once they get into QEMU it's very hard
to get them back out again...)

> 2. What type of mmc/sd card is being modelled/used here?

The comment at the top of the source file says "as defined in the
"SD Memory Card Physical layer specification, Version 1.10."
It might even still be accurate...

The message from QEMU indicates that the SD card model's
state machine thinks that it should not be receiving data but
it has just got a pile of data from the pl181. The obvious guess
is that what you did in the CMD irq handling has moved it from
"ok for data" to something else.

Beyond that, somebody would need to reproduce with a newer
QEMU than 1.5.0 and enable debugging printfs in the kernel
and the model to figure out what the interaction is here.
Chances are quite high that this is a QEMU model bug, but it's
not 100% :-)

thanks
-- PMM
--
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/