linux-kernel - Re: [semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure version 1

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:	Thu, 7 Feb 2008 20:41:20 +0100
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Andreas Mohr <andi@...as.de>
Cc:	Adam Wysocki <gophi-lkml@...urka.net>,
	linux-kernel@...r.kernel.org, giometti@...eenne.com
Subject: Re: [semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure
 version 1

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

> 
> 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. :)

> 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?

> 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.

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