On Thu, 7 Feb 2008 00:10:16 +0100
Andreas Mohr <andi@lisas.de> wrote:

quoted text
> 
> My Toshiba SD-512-T card (Toshiba-specific specs are available as
> TOSHIBA_SD_Card_Specification.pdf) shows the same "SCR structure version 1"
> error message with 2.6.24 on a Motorola E680 (PXAMCI), whereas
> on 2.6.21 it did _NOT_ have it (and all SCR values there are a 1:1 match
> with the values listed in the spec .pdf!).
> 
> For me at least it turned out that while on 2.6.21, raw_scr had
> 0x00a50000 0x10011602
> on 2.6.24 raw_scr had
> 0x10011602 0x00000000
> 

Ouch. That would explain more or less any SCR related bug. :)

quoted text
> IOW, the whole thing is simply shifted by one unsigned int, rendering any
> SCR interpretation fatally wrong (which, I believe, could be a
> _permanent_ error in the SD stack itself which randomly -
> depending on the exact bit content of a card's SCR dump -
> causes the SCR version check to trigger for various cards).
> Is this unsigned int shifting due to a transfer setup issue in the
> highlevel SD stack or do you think it is due to a setup issue in the
> lower-level pxamci driver in my case? If so, what setting could have
> distorted it?

I'm not seeing it on any controller here, so right now I'd guess a driver problem. No idea why though.

Are you seeing this effect on other cards?

quoted text
> Weak voltage settings are not to blame, I believe (removed some configs to
> increase a bit from minimum supported voltage).
> If you don't have any specific ideas yet, any hints on how to proceed
> with tracking this down?

There's always bisecting the issue until you find the offending commit. Time consuming, but it gets the job done.

Other than that, try adding some printk() to pxamci's data transfer routines and dump the data when it is fresh.

quoted text
> 
> I'd advise at least adding dumping the raw_scr values
> in the SCR version error to be able to track such error postings better
> in the future.
> 

It's definitely something to remember in future bug reports.

Rgds
-- 
     -- Pierre Ossman

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