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]
Date:	Thu, 23 Nov 2006 19:57:57 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Vitaly Wool <vitalywool@...il.com>, drzeus-mmc@...eus.cx,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix random SD/MMC card recognition failures on ARM Versatile

On Thu, Nov 23, 2006 at 07:42:36PM +0000, Russell King wrote:
> On Thu, Nov 23, 2006 at 10:29:30PM +0300, Vitaly Wool wrote:
> > On 11/23/06, Russell King <rmk+lkml@....linux.org.uk> wrote:
> > >Doubtful.  mmci_stop_data() already does this, which will be called
> > >immediately prior to mmci_request_end().  So you're doubling up the
> > >writes to registers again.
> > 
> > There's the case (mmci_cmd_irq) where mmc_stop_data is not called
> > prior to mmci_request_end(), so it's not that simple.
> 
> Ah, I see it.  In that case we need to call mmc_stop_data() when
> we're ending the initial command due to an error.  IOW, like this:

I'll also add that with the way we handle the MMCI, it is highly likely
that you _will_ see FIFO errors from time to time on this platform.

The problem is that we don't have DMA up and running on this platform,
so we are entirely at the mercy of interrupt-driven PIO.  In addition,
the MMCI FIFOs must be read _before_ they completely fill to avoid
overrun errors.  Coupling these two facts together, it's easy to see
that interrupt latency is _critical_ to avoiding FIFO overruns (error 3).

In general, if you do _anything_ with the board while it's trying to
access MMC cards, you will probably get some FIFO overruns.

There are three solutions:

1. Lower the maximum clock rate that the MMCI will allow, eg:
   insmod mmci fmax=257816

2. Avoid all other system activity while MMC is being accessed.

3. Someone needs to _sanely_ implement DMA on this platform.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ