On Fri, 19 Oct 2007 11:50:16 +0200 "Jan Nikitenko" wrote: > On 10/10/07, Pierre Ossman wrote: > > > > Odd. Could you point to the byte swapping in the earlier version? > > It was present in mmc-spi update patch posted here for example: > http://sourceforge.net/mailarchive/message.php?msg_id=200706042025.18252.david-b%40pacbell.net > Check the mmc_spi_read_cXd(), there are be32_to_cpus() calls present. > Ah. I see what you mean now. The problem is in the data transfer, not a response field. So Sacha's patch was almost correct. Could you test if the included patch solves your issue? > What do you mean by FTL on the card? > The wear leveling and other voodoo that translates block commands to NAND storage. If we send a write multiple times and the card fails it partially, then we have no idea what it has actually committed to NAND. Hence we play it safe and let upper layers handle the policy of retrying. > > Without the !blk_queue_stopped(q) check, the suspend waits until dd > command finishes it's job. Not quite. It should just wait for the data dd has currently queued up (which should be 1 bs plus possible read-ahead). > If the check is there, it's possible to suspend when dd command (or > any other file copy command) is running and properly resume after. > OTOH, letting them finish reduces the number of dirty pages that might have to be committed to disk for a hibernation. Is this really a problem that plagues you, or just something you noticed in the code? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org