Hi, On Sat, Sep 29, 2007 at 10:35:16AM +0200, Pierre Ossman wrote: > On Sat, 29 Sep 2007 05:42:37 +0200 (CEST) > Adam Wysocki <[EMAIL PROTECTED]> wrote: > > > [CCd to possibly interested Pierre Ossman and Rodolfo Giometti] > > > > Hi there, > > > > First, sorry for my poor english - I am not a native. > > > > I know there have been a thread about this problem few months ago, > > but as far as I see it did not led to any results: > > http://groups.google.com/group/linux.kernel/browse_thread/thread/19116cafe8a20b5/4a28c3b15bb999df > > > > I have the same problem, as described there, with Kingston 2GB SD > > card. My card reader is embedded into Fujitsu-Siemens AMILO Pro V3505 > > notebook and Linux sees it as: > > > > If it's just this card, then I would have to conclude that it is indeed > broken. You'd have to return it to the store and get a new one.
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 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? 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? 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. I'm now giving up on tracking this down myself (I'll just bail the check for now to have it boot properly) since originally I had more productive things in mind ;) (note that disabling the check on 2.6.24 makes the card boot ok up to a full mobile desktop) Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/