Re: strange problem with Intenso 4GB SDHC card

2008-08-11 Thread Joachim Steiger
Andy Green wrote:
[...]
 Hey don't lose hope.  There are two issues.  First is just some big
 cards are too slow to respond at default 16MHz clock with Glamo 16-bit
 clock count timeout counter.  See this
 
 https://docs.openmoko.org/trac/ticket/1743
 
 Suspend / resume (partition overwrite is only a suspend / resume issue)
 has been fundamentally broken on GTA02 since before I got here last
 December, it didn't work at all until a series of deathmatches with it.
 ~ The biggest deathmatch of all to clean and fix it is going on at the
 minute on 2.6.26 branch here and it exposed the biggest underlying
 problem for us which is Glamo behaviours.  Assuming I kill it before it
 kills me, we will have a far less racy and more complete suspend and
 resume ordering situation then.

yay!


 Other projects using Linux also have that problem of partition overwrite
 on resume, but I suspect resume ordering and racing is behind their
 problems too.  When we clear that in the 2.6.26 branch we stand a chance
 to synthesize random or moving delays in resume action and try to flush
 out where it comes from.

i played with it a bit and came to the conclusion that it eats exactly
1024byte from the beginning of the 'physical' blockdevice. atleast when
i backup these to nand, write them back via dd after loosing it and do a
ioctl via fdisk /dev/mmcblk0 - press w to trigger the block layer
rereading the device i am fine.

sounds weird.. is a buffer getting nulled on suspend, and gets written
back to disk even if it shouldnt?


-- 

Joachim Steiger
Openmoko Central Services

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-08-11 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| i played with it a bit and came to the conclusion that it eats exactly
| 1024byte from the beginning of the 'physical' blockdevice. atleast when
| i backup these to nand, write them back via dd after loosing it and do a
| ioctl via fdisk /dev/mmcblk0 - press w to trigger the block layer
| rereading the device i am fine.
|
| sounds weird.. is a buffer getting nulled on suspend, and gets written
| back to disk even if it shouldnt?

Huh.  Well SD is predicated around 512 byte blocks, so it is a 2-block
transaction.  When I dump what the driver sees for requests, they are
usually 2 or 8 512 byte blocks (1KBytes or 4KBytes).  So that part isn't
very foreign to the kind of transactions that are seen.

In 2.6.24 the PMU is taken down real early in suspend, it yanks SD Card
power (and CPU core power LOL) long before the MCI / MMC / SD driver and
stack try to deselect the card nicely.  One of the changes in
andy-2.6.26 is to make Glamo (and other things) a child of the PMU, so
the ordering is all changed around and SD Card can complete suspend
sanely with the card still powered.  The PMU goes down towards the end
of all the suspend actions too which is much better considering CPU core
power.

The main striking thing about the SD Card overwrite issue for me is that
we got rid of it for a long time just by removing the synchronous low
level debug config... we could literally make this overwrite issue come
and go by basically changing timing of suspend and resume actions alone.
~ So I believe that we deal with races at the heart of all this.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkigoaYACgkQOjLpvpq7dMqk/ACfXI+8eLkpvn9/QBd3i9COMIMf
UH0An0Q0vm3BL+kN2CH4/7kvjK3tyyzU
=UJPs
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-08-08 Thread Gianluigi
Alle 01:16, sabato 26 luglio 2008, Thomas B. ha scritto:
 On Fri, Jul 25, 2008 at 11:44:37PM +0200, AVee wrote:
  On Friday 25 July 2008 10:54, arne anka wrote:
   i got a 4 gig card too (can't say if from intenso, have to check the
   wrapping).
   my card's boot sector is not erased but -- after a resume the card is
   mounted wrongly!
  
   fstab says as mountpoint /media/card and after booting that's where the
   card is.
   after suspend/resume the card (often) is mounted to /media/mmcblk1p1
   instead -- thus every attempt to read from or write to the sd card goes
   to the built-in memory instead.
 
  I can confirm seeing the same behaviour with a Sandisk 8GB card...

 Me too (also Sandisk 8GB). It bit me while running Qtopia from SD card:
 Upon resuming the system crashed, probably because the rootfs was
 gone...

 I could reproduce this after having booted from flash. dmesg log of the
 suspend/resume cycle is attached.

 Regards,
 Thomas

Any fix for this problem?

I've made many test with a 4G SD.
If use it for boot qtopia from vfat and ext2 partions it work fine. Slowly but 
fine.

If I start system from 2007.2 in flash the mounted SD partitions give me many 
errors.

Sometime was mounted 1st partion, sometime all of than.
I've tried to access it in reading and writing and frequently I get I/O errors 
in dmesg.

On time was loose partition table (in suspend/resume session).

I've tried many partitions schemas (mixed FAT and ext2) but always I/O errors 
come.

I've reformatted in a unique partition with FAT and I've filled in it about 
1GB of maps for tangogps from my PC.

The partition was mounted in /media/card and when tangogps start to read from 
SD some file was read good and many other not.
The screen become full noised when SD is reading and get I/O errors.
After the read go to end the screen come back showing fine.

The 4GB SD with my PC work fine, no I/O errors.
The 512M SD in FR package always work very well.

The 4GB SD is a Apacer Micro SDHC 4GB Class 6.

-- 
The sooner our happiness together begins, the longer it will last.
-- Miramanee, The Paradise Syndrome, stardate 4842.6

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-08-08 Thread vale

yes i am loosing my partition table every couple of day. very annoying! i
cant trust anymore my data beeing secure on the openmoko.

i have a sandisk 8gb class4 sdhc card with one ext3 partition. 

i hope there will be a fix soon, but i'm loosing hope :(


-- 
View this message in context: 
http://n2.nabble.com/strange-problem-with-Intenso-4GB-SDHC-card-tp579169p680129.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-08-08 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| yes i am loosing my partition table every couple of day. very annoying! i
| cant trust anymore my data beeing secure on the openmoko.
|
| i have a sandisk 8gb class4 sdhc card with one ext3 partition.
|
| i hope there will be a fix soon, but i'm loosing hope :(

Hey don't lose hope.  There are two issues.  First is just some big
cards are too slow to respond at default 16MHz clock with Glamo 16-bit
clock count timeout counter.  See this

https://docs.openmoko.org/trac/ticket/1743

Suspend / resume (partition overwrite is only a suspend / resume issue)
has been fundamentally broken on GTA02 since before I got here last
December, it didn't work at all until a series of deathmatches with it.
~ The biggest deathmatch of all to clean and fix it is going on at the
minute on 2.6.26 branch here and it exposed the biggest underlying
problem for us which is Glamo behaviours.  Assuming I kill it before it
kills me, we will have a far less racy and more complete suspend and
resume ordering situation then.

Other projects using Linux also have that problem of partition overwrite
on resume, but I suspect resume ordering and racing is behind their
problems too.  When we clear that in the 2.6.26 branch we stand a chance
to synthesize random or moving delays in resume action and try to flush
out where it comes from.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkicG6cACgkQOjLpvpq7dMoYOACdHxsTW9deFxs0p6xlP99mbPbk
788An3r++lSrpASbliku2hSP5nROaKbz
=Hgum
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-27 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Andrew Burgess said (on the OLPC bug tracker):
|
| ...For me the SD card corruption is 100% fixed now. I run a swap to the
| first sd card partition and I could guarantee partition wipe by turning
| off power or shutting down with swap on. I could work around it 100% by
| running swapoff before power down. I never enabled suspend. Now
| everything works. It suspends and resumes at will with swap running.
| Shutdown or mash the power button, partition table is fine...
|
| http://dev.laptop.org/ticket/6532#comment:63

What is the swap situation on the image you are running?  I noticed
Debian was doing something about it on initscripts, but I didn't notice
before that we run swap on ASU?

If as I believe this is very sensitive to a race, then not syncing swap
can change the behaviour miles away from the swap itself and change the
symptom, as could a bunch of other stuff.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiMJGQACgkQOjLpvpq7dMoBGQCfTZGoHzScbI+RtGdmKEtLlN0X
4fgAnjeHUc2iowstBWGgXmeVjd9kEr0k
=uvX+
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-27 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| With all ext2 partitions, I get this in dmesg
|
| FAT: bogus number of reserved sectors
| VFS: Can't find a valid FAT filesystem on dev mmcblk0.
| FAT: bogus number of reserved sectors
| VFS: Can't find a valid FAT filesystem on dev mmcblk0.
| JFFS2 warning: (956) jffs2_sum_write_sumnode: Not enough space for
summary,
| padsize = -1
|
| a problem?

No, it doesn't mean any problem about SD Card.

First it tries to mount the thing vfat, before ext2 / 3, so those 4
lines are OK.

Second the last line is ongoing jffs2 trouble that does not seem to make
a symptom, when we move to 2.6.26 there is a at least one patch in there
noticed by Holger that may impact this.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiMI5oACgkQOjLpvpq7dMqz2wCghkIiD+jxCd3mNgN2jyyVRC3C
zyoAn1J/y1BvvzoJQcL4tr9EIYktjihl
=eIaD
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-26 Thread Doug Jones
Joerg Reisenweber wrote:

snip

 As I think this seems to be quite a good clue to what's really happening here,
 quote from the OLPC ticket #6532:

snip


Yes, anybody working on this issue really ought to read that ticket in 
its entirety:

http://dev.laptop.org/ticket/6532

(keeping in mind that some of the earlier entries, from months ago, may 
contain erroneous data)

Note that some people think that this problem may affect things other 
than the SD card, and that external storage connected through USB might 
have a problem too.

OLPC really really wants to do aggressive power management.  They want 
to do things like halt the processor between keystrokes.  If they can't 
do suspend and resume in  100 msec, they may not ever be able to 
deliver the holy grail:  a laptop that can run for ten minutes on the 
power provided by one minute of muscle power from a four-year-old child.

If they can achieve this, then OpenMoko ought to be able to achieve such 
aggressive power management too.  That's how you get really long battery 
life.

It seems that reconciling the need for data integrity on flash drives 
with the desire to achieve excellent power management is a hard problem.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-26 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| As I think this seems to be quite a good clue to what's really
happening here,
| quote from the OLPC ticket #6532:
| (HTH)
| cc dilinger added
|  I've spend some time digging deep into the bowels of the VFS and
block layer
| and gathering some debug output and have an explanation for the partition
| table corruption:

That's a great post you found Joerg and it is to the point.  But what is
killing me is this was working seemingly until we followed Sean
McNeil's lead about removing printks of all things from PMU driver while
trying to find the GSM crash in resume problem.  That's not to blame his
insight; clearly if we only work because async printks let it work,
we're not really working at all.  Previous to that, enabling synchronous
low level debug in the kernel forced the bad behaviour and disabling it
gave the good behaviour.

This is ultimately a resume race of some kind, the VFS layer corruption
and taking a whiz on block 0 (noticeable as it is) is downstream of
whatever is truly responsible.

I have made half the device a child of the PMU device now reflecting the
relationship more clearly and this is honoured by the suspend / resume
ordering now.  It means that we still have power at the SD Card while
glamo-mci driver is suspending, but we still fail to get a good result
from the last command sent on suspend, cmd7 to deselect the card.  I
have to fix more problems today before I can see how MMC resumes from it.

I'm also doing this on 2.6.26 in case MCI layer changes make a different
result.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiKyrkACgkQOjLpvpq7dMpUbQCeK6fTmQRTf8A/Fm6Ze7Phiw/U
YsYAn06RnSAuZbZUtRnP+56jY4Bau9OF
=lJhb
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-26 Thread vale

i had the same problem here, with sandisk 8gb sdhc class 4 using ext2
partition. partition table was completley deleted :(

hope this gets fixed soon.
-- 
View this message in context: 
http://n2.nabble.com/strange-problem-with-Intenso-4GB-SDHC-card-tp579169p584908.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-26 Thread thewtex
David Meder-Marouelli [EMAIL PROTECTED] writes:


 After the the card settles (see above in this thread), i can do the
 following:
 
 1) fdisk -l /dev/mmcblk0
 Result: error
 2) fdisk -l /dev/mmcblk0
 Result: empty partition table!!!
 3) fdisk -l /dev/mmcblk0
 Result: correct full partition table!!!
 

I can confirm the fdisk magic on my 4GB AData SDHC.  It was partitioned with 4
ext2 partitions.

Are these problems limited to only SDHC?



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-26 Thread thewtex
thewtex [EMAIL PROTECTED] writes:

 
 David Meder-Marouelli [EMAIL PROTECTED] writes:
 
  After the the card settles (see above in this thread), i can do the
  following:
  
  1) fdisk -l /dev/mmcblk0
  Result: error
  2) fdisk -l /dev/mmcblk0
  Result: empty partition table!!!
  3) fdisk -l /dev/mmcblk0
  Result: correct full partition table!!!
  
 
 I can confirm the fdisk magic on my 4GB AData SDHC.  It was partitioned with 4
 ext2 partitions.
 
 Are these problems limited to only SDHC?
 

With all ext2 partitions, I get this in dmesg

FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev mmcblk0.
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev mmcblk0.
JFFS2 warning: (956) jffs2_sum_write_sumnode: Not enough space for summary,
padsize = -1

a problem?



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread arne anka
i got a 4 gig card too (can't say if from intenso, have to check the  
wrapping).
my card's boot sector is not erased but -- after a resume the card is  
mounted wrongly!

fstab says as mountpoint /media/card and after booting that's where the  
card is.
after suspend/resume the card (often) is mounted to /media/mmcblk1p1  
instead -- thus every attempt to read from or write to the sd card goes to  
the built-in memory instead.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| i got a 4 gig card too (can't say if from intenso, have to check the
| wrapping).
| my card's boot sector is not erased but -- after a resume the card is
| mounted wrongly!
|
| fstab says as mountpoint /media/card and after booting that's where the
| card is.
| after suspend/resume the card (often) is mounted to /media/mmcblk1p1
| instead -- thus every attempt to read from or write to the sd card
goes to
| the built-in memory instead.

This is definitely the signature of the old MMC resume problems, not
anything else.

I am deep down that mine at the minute, this is getting intensely looked at.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiJn8YACgkQOjLpvpq7dMonOACfTUfolw3wMrey+x51IwF/zl4W
MxsAnjIkOZu9PLLGPZEX6L4l7a1g6x2d
=vnNT
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread arne anka
 This is definitely the signature of the old MMC resume problems, not
 anything else.

oh, ok. thought it to be related to the wiped out boot sector and thus  
maybe helpful.

 I am deep down that mine at the minute, this is getting intensely looked  
 at.

is there a workaround for the time being?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| This is definitely the signature of the old MMC resume problems, not
| anything else.
|
| oh, ok. thought it to be related to the wiped out boot sector and thus
| maybe helpful.

It can be related, I expect the trashed block 0 thing is also
suspend-related only.

| I am deep down that mine at the minute, this is getting intensely
looked
| at.
|
| is there a workaround for the time being?

Not that I know of.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiJrMsACgkQOjLpvpq7dMot8wCfXb8MuDMypvOB9u/wFNxtjkp6
n/gAn3HE4ZZ7BhlTbgeK5krC1ppHBQaM
=Pyiu
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread arne anka
btw: just checked and the default _device_ ist mmcblk0p1, after resume it  
disappears and instead there is mmcblk1p1.
dunno if it is news to you ...

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread arne anka
well, the card is a kingston 4gb class 4.
yesterday i downloaded a map with tangogps and meanwhile the fr went to  
suspend. afterwards a few directories were misisng.
trying
ls /media/card/Maps/om/adirectorynotthere/
gives errors (something w/ read access i think)
so i decided to delete the entire /media/card/Maps folder from within the  
fr -- but that fails with read-only filesystem. and indedd magically the  
card is mounted read only.
mount /media/card -o remount,rw
changes that, but next thing i know is read only filesystem.

not sure if that fits into the original problem with the fried boot sector.
is there a trac ticket where i may add those informations?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread AVee
On Friday 25 July 2008 10:54, arne anka wrote:
 i got a 4 gig card too (can't say if from intenso, have to check the
 wrapping).
 my card's boot sector is not erased but -- after a resume the card is
 mounted wrongly!

 fstab says as mountpoint /media/card and after booting that's where the
 card is.
 after suspend/resume the card (often) is mounted to /media/mmcblk1p1
 instead -- thus every attempt to read from or write to the sd card goes to
 the built-in memory instead.

I can confirm seeing the same behaviour with a Sandisk 8GB card...

AVee

-- 
I haven't lost my mind -- it's backed up on tape somewhere.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread Thomas B.
On Fri, Jul 25, 2008 at 11:44:37PM +0200, AVee wrote:
 On Friday 25 July 2008 10:54, arne anka wrote:
  i got a 4 gig card too (can't say if from intenso, have to check the
  wrapping).
  my card's boot sector is not erased but -- after a resume the card is
  mounted wrongly!
 
  fstab says as mountpoint /media/card and after booting that's where the
  card is.
  after suspend/resume the card (often) is mounted to /media/mmcblk1p1
  instead -- thus every attempt to read from or write to the sd card goes to
  the built-in memory instead.
 
 I can confirm seeing the same behaviour with a Sandisk 8GB card...

Me too (also Sandisk 8GB). It bit me while running Qtopia from SD card:
Upon resuming the system crashed, probably because the rootfs was
gone...

I could reproduce this after having booted from flash. dmesg log of the
suspend/resume cycle is attached.

Regards,
Thomas

PM: Preparing system for mem sleep
Freezing user space processes ... (elapsed 0.09 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
PM: Entering mem sleep
Suspending console(s)
pcf50633 0-0073: pcf50633_suspend
glamo-mci glamo-mci.0: faking cmd 7 during suspend
mmc_set_power(power_mode=0, vdd=0
glamo-mci glamo-mci.0: glamo_mci_set_ios: power down.
gta02_udc_command(2)
suspending dma channel 0
suspending dma channel 1
suspending dma channel 2
suspending dma channel 3
GSTATUS3 0x30376074
GSTATUS4 0x
s3c2440-i2c s3c2440-i2c: slave address 0x10
s3c2440-i2c s3c2440-i2c: bus frequency set to 390 KHz
gta02_udc_command(1)
s3c2440-nand s3c2440-nand: Tacls=3, 30ns Twrph0=7 70ns, Twrph1=3 30ns
not changing prescaler of PWM 3, since it's shared with timer4 (clock tick)
timer_usec_ticks = 7864
timer tcon=00599109, tcnt a2c1, tcfg 0200,2000, usec 1eb8
mmc_set_power(power_mode=1, vdd=20
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus 
width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: Error after cmd: 0x120
mmc0: card d555 removed
MMC: killing requests for dead queue
mmc_set_power(power_mode=0, vdd=0
glamo-mci glamo-mci.0: glamo_mci_set_ios: power down.
mmc_set_power(power_mode=1, vdd=20
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus 
width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: Error after cmd: 0x8120
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: Error after cmd: 0x8120
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
soc-audio soc-audio: scheduling resume work
PM: Finishing wakeup.
Restarting tasks ... 6soc-audio soc-audio: starting resume work
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). 
Bus width=2
mmc0: new high speed SDHC card at address d555
mmcblk1: mmc0:d555 SU08G 7977472KiB 
 mmcblk1: p1 p2 p3
done.
soc-audio soc-audio: resume work completed
dma2: channel has nothing loaded
EXT2-fs error (device mmcblk1): ext2_check_descriptors: Block bitmap for group 
0 not in group (block 0)!
EXT2-fs: group descriptors corrupted!
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-25 Thread Joerg Reisenweber
Am Do  24. Juli 2008 schrieb Andy Green:
 Somebody in the thread at some point said:
 | Hi all,
 |
 | I can now reliably reproduce the issue, as dd'ing the mbr back to the
 | card so far restores sane behaviour :
 |
 | If sd_drive is set to 0, then after a resume from sync  apm -s the
 | MBR of my 4GB SanDisk is wiped - so far I haven't noticed any other
 | errors, but have not looked very closely.
 ...
 
 | PS: Can somebody please tell me how to re-initialize the card without
 | going through another suspend/resume cycle ?
 
 sd_drive setting isn't actually used until next time we access the card,
 so provoking an access will do it, eg, touch /something ; sync.
 
 But the two explanations for what goes on seem mixed still here, we
 affect sd_drive and we do a suspend.  My guess / hope is that this
 problem is coming from the suspend action alone and the change of
 sd_drive is bogus here.  Maybe you can bang on it a little more trying
 to disprove that hypothesis?
 
 -Andy

As I think this seems to be quite a good clue to what's really happening here,
quote from the OLPC ticket #6532:
(HTH)

cc dilinger added 
 I've spend some time digging deep into the bowels of the VFS and block layer 
and gathering some debug output and have an explanation for the partition 
table corruption: 
 Upon coming out of resume, the SD code, with CONFIG_MMC_UNSAFE_SUSPEND 
enabled, checks to see if there is a card plugged into the system and whether 
that card is the same as the one that was plugged into the system at suspend 
time. This is accomplished by reading the card ID of the device and for some 
reason, very possibly #1339, we fail this detection. In this case, the kernel 
removes the old device from the system and in this execution path, the 
partition information for this device is zeroed. 
 Even though the device is removed, the device is still mounted and upon 
unmount, ext2 syncs the superblock, even if the file system is sync'd 
beforehand. The superblock is block 0 of the partition and the block layer 
adds to this the partition start offset before submitting the write to the 
lower layers. As the partition information has already been zeroed out, we 
end up writing to block 0 of the disk itself, overwriting the partition table 
and the geometry information. I've verified this by both gathering debug 
output and 'dd' + 'hexdump' of corrupted and uncorrupted media. 
 Some interesting points: 
We are able to delete a block device even though it is still mounted. 
Even though the device has been deleted, the write submitted to it does not 
fail. 
 Note that this is still not 100% reproducible and in certain cases the 
superblock write during unmount does fail with block I/O errors, meaning that 
the queue is properly deleted. As per dilinger's comments on IRC, the VFS has 
lots of refcounts and there is a timing issue/race condition that we're 
hitting. As per #1339, we may be able to add an OLPC specific hackto wait 
500ms or so upon resume to get around this. I will try this but I don't think 
this is acceptable given our suspend/resume requirements. 
 Something I don't quite understand at the moment is how/when our userland env 
(journal specifically I think?) unmounts the device as I've been testing via 
command line suspend mount, and unmount while running in console mode. 
 Next steps: 
Get an understanding of the what is happening with our userland and brainstorm 
with cjb about the possibility of simply unmounting the SD device upon 
suspend. There are issues around this as we may have files open and that will 
keep us from suspending. 
Test adding a timeout to the resume path to see if it solves our problem to 
validate that it is indeed something related to our HW. 
Dig into the unmount/write to non-existing bdev some more nad discuss this 
upstream if needed. 
 (Adding dilinger to cc:) 
 
/j


signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Doug Jones
Mikael Berthe wrote:
 * Doug Jones [EMAIL PROTECTED] [2008-07-24 01:21 +0200]:
 There have been some indications that partition type may have some 
 effect on this problem on the OLPC.
 
 I doubt it.
 
 So, shrink the default vfat partition that came on the card and put
 an ext3 on there too.  If you want to be adventurous, try some other
 types.
 
 Happens to me with ext3 partitions as well (or mixed vfat/ext3
 partitions).
 
 However if I restore the partition table the data are not corrupted,
 at least so far it's been all right...


Most people who use SD cards on OLPC are leaving them formatted as vfat, 
because Sugar can't see any other type.  I don't recall seeing any 
reports of partition table mangling from these people, who are the vast 
majority of OLPC users.

It's when they try something other than vfat that the corruption occurs. 
  When it happened to me, I had one vfat and one ext3 on there.

So on the OLPC at least, the corruption does seem to be correlated with 
partition type.


Because the number of people trying different file systems on the SD 
card was relatively small, and because the corruption was happening sort 
of randomly, it's been difficult to figure out what's happening.  Sample 
size too small.

People were making all kinds of assumptions based on the limited 
reports, some of them wrong.  If you look through that bug ticket and 
also various reports on forums and lists, you find contradictory 
information regarding which builds were affected, which file systems 
were affected, and so on.  This kind of noise makes it a lot harder to 
debug.  It's still not clear that this problem is understood, even six 
months later.

This is why I suggested that lots of people try various file systems in 
their Neos, even if they don't need to have a card in there right now. 
If there is indeed an SD problem in the Neo, we need lots of reports, 
otherwise the sampling size problem might drag out the debugging for 
months as happened with OLPC.

If there is no problem with SD, then there's no harm done.  You'll just 
have a lot of people walking around with SD cards they aren't using yet 
sitting inside their phones.



And of course it's entirely possible that the OLPC / SD problem has 
nothing to do with the Neo.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread arne anka
 Everybody, get a Micro-SD card and stick it in your Neo.  Put some

should that apply to multiboot or to _every_ use of the sd card?
i use suspend/resume more or less successfully for a week or 10 days now  
and the files on my sd card (4gb, how do i determine the exact name from a  
running system?) still are unharmed.
gta02, 2007.2, upgrade every or every second day.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Stefan Fröbe
Hi all,

I can now reliably reproduce the issue, as dd'ing the mbr back to the card
so far restores sane behaviour :

If sd_drive is set to 0, then after a resume from sync  apm -s the MBR
of my 4GB SanDisk is wiped - so far I haven't noticed any other errors, but
have not looked very closely.

To recover, I use the following commands:
---
# re-write MBR
dd if=mmcblk0_512_1.dump of=/dev/mmcblk0
# recognize partitions again
echo 1/sys/module/glamo_mci/parameters/sd_drive
apm -s


So it looks as if the sd_drive parameter does have a role in this - any
suggestions on what else I should try, or what logs you guys need ?

Unmounting the card before suspend should help, and I'll also gladly try
another kernel and other partitions setup if I find the time.

Btw, this all happens on a 4GB SanDisk with 4 primary partitions:
20M vfat + (196M +196M +3.2G ) ext2 and kernel om-gta02 2.6.24 Wed Jul 23
06:34:19

Stefan

PS: Can somebody please tell me how to re-initialize the card without going
through another suspend/resume cycle ?




On Thu, Jul 24, 2008 at 9:53 AM, arne anka [EMAIL PROTECTED] wrote:

  Everybody, get a Micro-SD card and stick it in your Neo.  Put some

 should that apply to multiboot or to _every_ use of the sd card?
 i use suspend/resume more or less successfully for a week or 10 days now
 and the files on my sd card (4gb, how do i determine the exact name from a
 running system?) still are unharmed.
 gta02, 2007.2, upgrade every or every second day.

 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community

ices/platform/neo1973-button.0/input/input0
wake enabled for irq 48
s3c2440-ts s3c2440-ts: successfully loaded
input: s3c2410 TouchScreen as /devices/virtual/input/input1
input: lis302-1 (top) as /devices/virtual/input/input2
lis302dl spi0.0: Found lis302-1 (top)
input: lis302-2 (bottom) as /devices/virtual/input/input3
lis302dl spi0.1: Found lis302-2 (bottom)
i2c /dev entries driver
s3c2440-i2c s3c2440-i2c: slave address 0x10
s3c2440-i2c s3c2440-i2c: bus frequency set to 390 KHz
s3c2440-i2c s3c2440-i2c: i2c-0: S3C I2C adapter
input: GTA02 PMU events as 
/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/input/input4
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus 
width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
usb0: full speed config #1: 500 mA, Ethernet Gadget, using CDC Ethernet
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: Error after cmd: 0x8120
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: Error after cmd: 0x8120
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
wake enabled for irq 53
pcf50633: dev (254:0)
pcf50633 0-0073: rtc core: registered pcf50633 as rtc0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). 
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req: 1kHz). 
Bus width=2
mmc0: new high speed SDHC card at address d555
neo1973-pm-bt neo1973-pm-bt.0: FIC Neo1973 Bluetooth Power Management: starting
neo1973-pm-gps neo1973-pm-gps.0: FIC Neo1973 GPS Power Managerment:starting
APM Battery Driver
bq27000-battery bq27000-battery.0: BQ27000 Battery Driver (C) 2008 Openmoko, Inc
mmcblk0: mmc0:d555 SU04G 3979776KiB 
 mmcblk0: p1 p2 p3 p4
S3c2440 SDIO Host controller
SDIO BusDriver - SDIO_GetBusOSDevice, registering driver: sdio_s3c24xx_hcd 
DMAmask: 0x0
pnp: the driver 'sdio_s3c24xx_hcd' has been registered
mapped channel 0 to 0
S3c24xx SDIO: IRQ:37 Detect IRQ:0 DMA channel:0 [EMAIL PROTECTED] [EMAIL 
PROTECTED] kHz
SDIO Bus Driver: HCD:sdio_s3c24xx should set module ptr!
sdio_s3c24xx_hcd 00:00: driver attached
sdio_s3c24xx_hcd 00:00: SDIO device, IDs SD_0008 (active)
pnp: the driver 'sdio_wlan' has been registered
Registered led device: neo1973:vibrator
Registered led device: gta02-power:orange
Registered led device: gta02-power:blue
Registered led device: gta02-aux:red
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
pcf50633 0-0073: setting system clock to 2008-07-24 12:59:39 UTC (1216904379)
Using lowest clock rate
CRCFAIL 0x1a3f

Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hi all,
|
| I can now reliably reproduce the issue, as dd'ing the mbr back to the
| card so far restores sane behaviour :
|
| If sd_drive is set to 0, then after a resume from sync  apm -s the
| MBR of my 4GB SanDisk is wiped - so far I haven't noticed any other
| errors, but have not looked very closely.
...

| PS: Can somebody please tell me how to re-initialize the card without
| going through another suspend/resume cycle ?

sd_drive setting isn't actually used until next time we access the card,
so provoking an access will do it, eg, touch /something ; sync.

But the two explanations for what goes on seem mixed still here, we
affect sd_drive and we do a suspend.  My guess / hope is that this
problem is coming from the suspend action alone and the change of
sd_drive is bogus here.  Maybe you can bang on it a little more trying
to disprove that hypothesis?

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiIbpQACgkQOjLpvpq7dMoFygCfagDp2oeJBH3TWSCtzgfeKiBX
SOkAnibMEKKHWCf7w5UDCp+9Jy2V8aqj
=FgHS
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread David Meder-Marouelli
Hi Stefan,

maybe it turn out to be the same problem that I also have.

After the the card settles (see above in this thread), i can do the
following:

1) fdisk -l /dev/mmcblk0
Result: error
2) fdisk -l /dev/mmcblk0
Result: empty partition table!!!
3) fdisk -l /dev/mmcblk0
Result: correct full partition table!!!

[Note: nothing else changed in between]

To re-ead the partition table just start fdisk /dev/mmcblk0, verify
that partition table is ok with p, re-write unaltered partition table
with w. After that it's re-read by the kernel and the Frerunner
recognises it.

Cheers,

David

Stefan Fröbe schrieb:
 Hi all,

 I can now reliably reproduce the issue, as dd'ing the mbr back to the
 card so far restores sane behaviour :

 If sd_drive is set to 0, then after a resume from sync  apm -s
 the MBR of my 4GB SanDisk is wiped - so far I haven't noticed any
 other errors, but have not looked very closely.

 To recover, I use the following commands:
 ---
 # re-write MBR
 dd if=mmcblk0_512_1.dump of=/dev/mmcblk0
 # recognize partitions again
 echo 1/sys/module/glamo_mci/parameters/sd_drive
 apm -s
 

 So it looks as if the sd_drive parameter does have a role in this -
 any suggestions on what else I should try, or what logs you guys need ?

 Unmounting the card before suspend should help, and I'll also gladly
 try another kernel and other partitions setup if I find the time.

 Btw, this all happens on a 4GB SanDisk with 4 primary partitions:
 20M vfat + (196M +196M +3.2G ) ext2 and kernel om-gta02 2.6.24 Wed Jul
 23 06:34:19

 Stefan

 PS: Can somebody please tell me how to re-initialize the card without
 going through another suspend/resume cycle ?




 On Thu, Jul 24, 2008 at 9:53 AM, arne anka [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

  Everybody, get a Micro-SD card and stick it in your Neo.  Put some

 should that apply to multiboot or to _every_ use of the sd card?
 i use suspend/resume more or less successfully for a week or 10
 days now
 and the files on my sd card (4gb, how do i determine the exact
 name from a
 running system?) still are unharmed.
 gta02, 2007.2, upgrade every or every second day.

 ___
 Openmoko community mailing list
 community@lists.openmoko.org mailto:community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community


 

 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Stefan Fröbe
Hi David,

 After the the card settles (see above in this thread), i can do the
 following:

 1) fdisk -l /dev/mmcblk0
 Result: error
...
No matter how often I call this, it never changes as the MBR is
completely zeroed out.

 To re-ead the partition table just start fdisk /dev/mmcblk0, verify
 that partition table is ok with p, re-write unaltered partition table
 with w. After that it's re-read by the kernel and the Frerunner
 recognises it.

 That works great after I dd the mbr back, thanks for the pointer!

Stefan

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Stefan Fröbe
Hi Andy,

 sd_drive setting isn't actually used until next time we access the card,
 so provoking an access will do it, eg, touch /something ; sync.

Good point, but now it is getting really strange (all with sd_drive=0
prior to suspend):
Adding a touch /media/mmcblk0p4/suspending and it works,
also adding the sync and it doesn't, and finally also adding a sleep
1 to the line and it gives me mixed results.
Maybe it is a timing issue, and the previously mentioned 400-500ms
delay is needed?

 But the two explanations for what goes on seem mixed still here, we
 affect sd_drive and we do a suspend.  My guess / hope is that this
 problem is coming from the suspend action alone and the change of
 sd_drive is bogus here.  Maybe you can bang on it a little more trying
 to disprove that hypothesis?

Will do if I find the time, but for now completely unmounting the card
seems like the only viable solution apart from dd'ing mbrs back and
forth until the root cause is found...
Hopefully the data storage on card is not impeded, but personally I
will do backups more often now ;-) ...

STefan

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Steven **
I experienced the same issue with my card (also the A-Data 8GB) after
flashing the kernel and rootfs builds from the 22nd.  My partition
table seems to have been deleted.  I'm pretty sure it happened after a
suspend/resume cycle (what happens when you have power management set
to dim first, then lock).

I had a vfat and an ext3 partition on there that I was using to dual-boot.

Is there a bug report/ticket for this issue I should be adding to?

At the very least, doesn't this belong on the support mailing list
instead of community?

-Steven


On Wed, Jul 23, 2008 at 5:20 PM, Matt Luzum [EMAIL PROTECTED] wrote:
 Andy Green wrote:
 There's a race of some kind in suspend / resume that can do this, the
 signature effect of it is on resume your device comes back as mmcblk1
 and the logical filesystem in memory is corrupted.  We didn't see this
 for a long time though.  Maybe keep an eye out for such shenanigans on
 resume.

 I just thought I'd mention that I had a similar thing happen.  Three
 times in the past couple days, my 8 GB A-Data microSDHC card somehow
 seemed to have its partition table deleted.  No partitions would show up
 on my card anyway, although I could make new partitions and read and
 write from them with a card reader.  I haven't had time to investigate
 more thoroughly, so I don't know whether it happens on resume or if it
 only happens when I'm doing something in particular.  I've had the
 original half gig card in there since yesterday and it hasn't had any
 problems, even though the SDHC card previously had problems several
 times in short order, so there might be some difference there.

 Sorry I can't be of more help with specifics, but I can confirm that
 there's someone else having this problem.

 Matt


 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Steven **
Does anyone know an equivalent tool for Linux?
fdisk just says unable to open.  So, I can't even re-write the data
to the card.  It's just dead!

-Steven

On Wed, Jul 23, 2008 at 4:15 PM, Stefan Fröbe [EMAIL PROTECTED] wrote:
 Hi,

 just a quick observation from my side that could possibly be related:
 Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g.
 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got me a
 new kernel I was surprised to see the card not beeing recognized anymore -
 furthermore, its MBR was zeroed out, and no tool could read or reformat it
 except a SD-Card recovery tool by Panasonic ( sdfv2003.exe running only
 under Windows, of course ) !

 I now backup'ed the partition table and mbrs in hope to be able to dd it
 back, should this happen again. Sorry, but I haven't got any logs as I was
 busy recovering what was left, but I'll surly save them next time ...

 Stefan

 uname -a
 Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl
 unknown


 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Steven **
Nevermind.  Gparted could read it.

-Steven

On Thu, Jul 24, 2008 at 6:37 PM, Steven ** [EMAIL PROTECTED] wrote:
 Does anyone know an equivalent tool for Linux?
 fdisk just says unable to open.  So, I can't even re-write the data
 to the card.  It's just dead!

 -Steven

 On Wed, Jul 23, 2008 at 4:15 PM, Stefan Fröbe [EMAIL PROTECTED] wrote:
 Hi,

 just a quick observation from my side that could possibly be related:
 Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g.
 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got me a
 new kernel I was surprised to see the card not beeing recognized anymore -
 furthermore, its MBR was zeroed out, and no tool could read or reformat it
 except a SD-Card recovery tool by Panasonic ( sdfv2003.exe running only
 under Windows, of course ) !

 I now backup'ed the partition table and mbrs in hope to be able to dd it
 back, should this happen again. Sorry, but I haven't got any logs as I was
 busy recovering what was left, but I'll surly save them next time ...

 Stefan

 uname -a
 Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl
 unknown


 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread AVee
On Thursday 24 July 2008 08:39, Doug Jones wrote:
 Mikael Berthe wrote:
  * Doug Jones [EMAIL PROTECTED] [2008-07-24 01:21 +0200]:
  There have been some indications that partition type may have some
  effect on this problem on the OLPC.
 
  I doubt it.
 
  So, shrink the default vfat partition that came on the card and put
  an ext3 on there too.  If you want to be adventurous, try some other
  types.
 
  Happens to me with ext3 partitions as well (or mixed vfat/ext3
  partitions).
 
  However if I restore the partition table the data are not corrupted,
  at least so far it's been all right...

 Most people who use SD cards on OLPC are leaving them formatted as vfat,
 because Sugar can't see any other type.  I don't recall seeing any
 reports of partition table mangling from these people, who are the vast
 majority of OLPC users.

 It's when they try something other than vfat that the corruption occurs.
   When it happened to me, I had one vfat and one ext3 on there.

 So on the OLPC at least, the corruption does seem to be correlated with
 partition type.

I haven't been able to find a publicly available version of any SD Card or 
SDHC spec. But both of the documents below seem to suggest that fat32 is part 
of the specification:
http://www.sdcard.org/about/sdhc/
http://www.kingston.com/flash/pdf_files/MKF_1127_SDHC_Topic_Paper.pdf

If that is the case both the controller and logic on the card may assume it 
contains a single full-size fat32 partition. They surely will not be tested 
with anything other then fat32. 

Does anyone here have access to official specs from the SDCard Association? It 
be interesting to have at least a hint about what the spec says about 
partitioning...

AVee

-- 
I always finish what I...

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


strange problem with Intenso 4GB SDHC card

2008-07-23 Thread David Meder-Marouelli
Hi,

I observed an interesting phenomenon with my newly bought Intenso 4GB
SDHC card.

While the 512MB card shipped with my Freerunner runs reliably and stable
the new card shows the following behaviour:

1) Errors during boot process:

[EMAIL PROTECTED]:~# dmesg |grep -E glamo|mmc
glamo3362 glamo3362.0: Detected Glamo core 3650 Revision 0002
(49119232Hz CPU / 81887232Hz Memory)
glamo3362 glamo3362.0: Glamo core now 49119232Hz CPU / 81887232Hz Memory)
glamo-spi-gpio glamo-spi-gpio.0: registering c0373838: jbt6k74
glamo-mci glamo-mci.0: glamo_mci driver (C)2007 Openmoko, Inc
glamo-mci glamo-mci.0: probe: mapped mci_base:c8864400 irq:0.
glamo-mci glamo-mci.0: glamo_mci_set_ios: power down.
glamo-mci glamo-mci.0: initialisation done.
mmc_set_power(power_mode=1, vdd=20
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz).
Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req:
195kHz). Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req:
195kHz). Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req:
195kHz). Bus width=0
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: Error after cmd: 0x8120
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: Error after cmd: 0x8120
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req:
195kHz). Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req:
195kHz). Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req:
195kHz). Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req:
195kHz). Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req:
195kHz). Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req:
1kHz). Bus width=0
glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req:
1kHz). Bus width=2
mmc0: new high speed SDHC card at address b368
mmcblk0: mmc0:b368 SD3931136KiB
 mmcblk0:6glamo-mci glamo-mci.0: Error after cmd: 0x8310
mmcblk0: error -110 sending read/write command
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
glamo-mci glamo-mci.0: Error after cmd: 0x120
glamo-mci glamo-mci.0: Error after cmd: 0x122
mmcblk0: error -84 sending read/write command

[many more of the last few lines following]

2) I can trick it to work doing the following steps:
   - check sd_drive parameter (not required)
 [EMAIL PROTECTED]:~# cat /sys/module/glamo_mci/parameters/sd_drive
 0
   - re-set it to this (or possibly any other) value
 [EMAIL PROTECTED]:~# echo 0  /sys/module/glamo_mci/parameters/sd_drive
   - now the device works fine:
 [EMAIL PROTECTED]:~# fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes
126 heads, 61 sectors/track, 1022 cylinders
Units = cylinders of 7686 * 512 = 3935232 bytes

Device Boot  Start End  Blocks  Id System
/dev/mmcblk0p1   11022 3927515+ 83 Linux
==

A suspend/resume cycle seems to do the trick as well.
I think that some parameter connected to sd_drive might be uninitialised
before sd_drive is explicitly rewritten.

Any ideas?

Cheers,

David



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| glamo-mci glamo-mci.0: Error after cmd: 0x120
| glamo-mci glamo-mci.0: Error after cmd: 0x8120
| glamo-mci glamo-mci.0: Error after cmd: 0x120
| glamo-mci glamo-mci.0: Error after cmd: 0x8120
| glamo-mci glamo-mci.0: Error after cmd: 0x120

This bit is normal, it's the Linux MMC / SD stack seeing if it is an
SDIO card.

| glamo-mci glamo-mci.0: powered (vdd = 20) clk: 1kHz div=2 (req:
| 1kHz). Bus width=2

This bit is a good sign, it was able to complete getting recognized by
the stack and put into 4-bit mode at 16MHz SD_CLK.

| mmc0: new high speed SDHC card at address b368
| mmcblk0: mmc0:b368 SD3931136KiB
|  mmcblk0:6glamo-mci glamo-mci.0: Error after cmd: 0x8310
| mmcblk0: error -110 sending read/write command

This first real error is ETIMEDOUT.  It can be a genuine timeout because
your card is a bit slow, but it could also mean communication problems.

| 2) I can trick it to work doing the following steps:
|- check sd_drive parameter (not required)
|  [EMAIL PROTECTED]:~# cat /sys/module/glamo_mci/parameters/sd_drive
|  0
|- re-set it to this (or possibly any other) value
|  [EMAIL PROTECTED]:~# echo 0  /sys/module/glamo_mci/parameters/sd_drive
|- now the device works fine:

I don't see how that can impact it, none of our code runs when you
change that, it simply gets written to the int that holds sd_drive
behind our back.  And when you catted it, that is the real value of that
int, it doesn't keep a copy somewhere.  Maybe something else in the
threshing around helped.

|  [EMAIL PROTECTED]:~# fdisk -l /dev/mmcblk0
|
| Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes
| 126 heads, 61 sectors/track, 1022 cylinders
| Units = cylinders of 7686 * 512 = 3935232 bytes
|
| Device Boot  Start End  Blocks  Id System
| /dev/mmcblk0p1   11022 3927515+ 83 Linux
| ==
|
| A suspend/resume cycle seems to do the trick as well.
| I think that some parameter connected to sd_drive might be uninitialised
| before sd_drive is explicitly rewritten.

I don't see it can be uninitialzed data, it is more likely working or
not working according to its own plan.

Once you formatted it, can you write reliably to it and read stuff back
with same md5sum after umount to flush the cache?

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiHkqcACgkQOjLpvpq7dMpeOwCfWfNTye1954C23FKy6aA7lvg+
fSgAnjun7jOgrNFnzuWu2yT//YFwuVEl
=wt0V
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread David Meder-Marouelli
Hi Andy,

thanks for the quick reply.

Andy Green schrieb:
 | mmc0: new high speed SDHC card at address b368
 | mmcblk0: mmc0:b368 SD3931136KiB
 |  mmcblk0:6glamo-mci glamo-mci.0: Error after cmd: 0x8310
 | mmcblk0: error -110 sending read/write command

 This first real error is ETIMEDOUT.  It can be a genuine timeout because
 your card is a bit slow, but it could also mean communication problems.
Not really good timing would probably be a good guess since Intenso is
a low cost brand around here (germany).

 | 2) I can trick it to work doing the following steps:
 |- re-set it to this (or possibly any other) value
 |  [EMAIL PROTECTED]:~# echo 0 
 /sys/module/glamo_mci/parameters/sd_drive
Thanks for your guidance. It's _not_ the sd_drive parameter.

It's actually just waiting for about 1-2min. After that the device is
readily accessible. (Need to force a re-read of the partition table to
mount though.)

Anyways I made sure that the data I wrote to the card yesterday is still
OK (md5sum) - although it's only around 1MB. I can do more tests tomorrow...

Cheers,

David



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Stefan Fröbe
Hi,

just a quick observation from my side that could possibly be related:
Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g.
2008-07-22 or 21) kernel - after an opkg upgrade this morning that got me a
new kernel I was surprised to see the card not beeing recognized anymore -
furthermore, its MBR was zeroed out, and no tool could read or reformat it
except a SD-Card recovery tool by Panasonic ( sdfv2003.exe running only
under Windows, of course ) !

I now backup'ed the partition table and mbrs in hope to be able to dd it
back, should this happen again. Sorry, but I haven't got any logs as I was
busy recovering what was left, but I'll surly save them next time ...

Stefan

uname -a
Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl
unknown
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Hi,
|
| just a quick observation from my side that could possibly be related:
| Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g.
| 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got
| me a new kernel I was surprised to see the card not beeing recognized
| anymore - furthermore, its MBR was zeroed out, and no tool could read or
| reformat it except a SD-Card recovery tool by Panasonic ( sdfv2003.exe
| running only under Windows, of course ) !
|
| I now backup'ed the partition table and mbrs in hope to be able to dd it
| back, should this happen again. Sorry, but I haven't got any logs as I
| was busy recovering what was left, but I'll surly save them next time ...

There's a race of some kind in suspend / resume that can do this, the
signature effect of it is on resume your device comes back as mmcblk1
and the logical filesystem in memory is corrupted.  We didn't see this
for a long time though.  Maybe keep an eye out for such shenanigans on
resume.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiHqaMACgkQOjLpvpq7dMpmjACeLCn3EHaubbZvLQWiBOqbJEIC
X1kAnipwM3etDG0tcQbVWArQuNNbV1vp
=qSZM
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Doug Jones
Stefan Fröbe wrote:
 Hi,
 
 just a quick observation from my side that could possibly be related:
 Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g. 
 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got 
 me a new kernel I was surprised to see the card not beeing recognized 
 anymore - furthermore, its MBR was zeroed out, and no tool could read or 
 reformat it except a SD-Card recovery tool by Panasonic ( sdfv2003.exe 
 running only under Windows, of course ) !
 
 I now backup'ed the partition table and mbrs in hope to be able to dd it 
 back, should this happen again. Sorry, but I haven't got any logs as I 
 was busy recovering what was left, but I'll surly save them next time ...
 
 Stefan
 
 uname -a
 Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl 
 unknown


Not sure if this is connected with what you are seeing, but...

Something similar has been happening with SD cards on the OLPC laptop 
(another example of hardware specifically designed for the FOSS world) 
for at least the last six months.  Last time I checked, there was still 
no real fix.  Has been a major pain for people who want to multiboot  -- 
  forces them to use storage devices that don't fit inside the case.

http://dev.laptop.org/ticket/6532

I am getting the impression that interfacing to SD cards is hard.



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Matt Luzum
Andy Green wrote:
 There's a race of some kind in suspend / resume that can do this, the
 signature effect of it is on resume your device comes back as mmcblk1
 and the logical filesystem in memory is corrupted.  We didn't see this
 for a long time though.  Maybe keep an eye out for such shenanigans on
 resume.

I just thought I'd mention that I had a similar thing happen.  Three 
times in the past couple days, my 8 GB A-Data microSDHC card somehow 
seemed to have its partition table deleted.  No partitions would show up 
on my card anyway, although I could make new partitions and read and 
write from them with a card reader.  I haven't had time to investigate 
more thoroughly, so I don't know whether it happens on resume or if it 
only happens when I'm doing something in particular.  I've had the 
original half gig card in there since yesterday and it hasn't had any 
problems, even though the SDHC card previously had problems several 
times in short order, so there might be some difference there.

Sorry I can't be of more help with specifics, but I can confirm that 
there's someone else having this problem.

Matt


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Stefan Fröbe
Thanks for the link, seems to be quite valuable to me as it explains the
background quite well!

Something similar has been happening with SD cards on the OLPC laptop
 (another example of hardware specifically designed for the FOSS world)
 for at least the last six months.  Last time I checked, there was still
 no real fix.


Well, from recent comments it looks like a 400ms delay (yuck!) in
drivers/mmc/core/sd.c is a temporary workaround, but the root cause (as Andy
already suggested) seems to be related to the resume cycle.

Has been a major pain for people who want to multiboot  --
  forces them to use storage devices that don't fit inside the case.

 http://dev.laptop.org/ticket/6532


At least it doesn't look like a HW issue with the card, then.

Stefan
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Thanks for the link, seems to be quite valuable to me as it explains the
| background quite well!
|
| Something similar has been happening with SD cards on the OLPC laptop
| (another example of hardware specifically designed for the FOSS world)
| for at least the last six months.  Last time I checked, there was
still
| no real fix.
|
|
| Well, from recent comments it looks like a 400ms delay (yuck!) in
| drivers/mmc/core/sd.c is a temporary workaround, but the root cause (as
| Andy already suggested) seems to be related to the resume cycle.
|
| Has been a major pain for people who want to multiboot  --
|  forces them to use storage devices that don't fit inside the case.
|
| http://dev.laptop.org/ticket/6532
|
|
| At least it doesn't look like a HW issue with the card, then.

Yes when we originally had this problem I found OLPC had it and indeed
Eee PC at that time.  What cured it for us was removing the low level
debug config option in the kernel, but that really is all about changing
timing too.

There's another complicated problem that can be related about the
relationship between the PMU and the Glamo.  The PMU device is only
created really late in boot because it is on I2C bus.  That means it is
suspended very early in suspend, yanking a lot of power rails (including
the CPU core power!  But it goes on long enough from caps) before the
MMC stack has a chance to talk to the card and close it down gently.

Although suspend / resume has been acting well these last weeks it is
fragile and we'll be doing a lot more work on it.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiHtWgACgkQOjLpvpq7dMqZIQCgkQdTUr6+4RrgkvCVG3fgWt3y
Od0AmwTQhXUu0Iklzfbi+1f0I4oWn3kT
=q9q1
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Doug Jones
Stefan Fröbe wrote:
 Thanks for the link, seems to be quite valuable to me as it explains the 
 background quite well!
 
 Something similar has been happening with SD cards on the OLPC laptop
 (another example of hardware specifically designed for the FOSS world)
 for at least the last six months.  Last time I checked, there was still
 no real fix.  
 
  
 Well, from recent comments it looks like a 400ms delay (yuck!) in
 drivers/mmc/core/sd.c is a temporary workaround, but the root cause (as 
 Andy already suggested) seems to be related to the resume cycle.
 
 Has been a major pain for people who want to multiboot  --
  forces them to use storage devices that don't fit inside the case.
 
 http://dev.laptop.org/ticket/6532
 
  
 At least it doesn't look like a HW issue with the card, then.
 
 Stefan


Just spent some time looking at that bug ticket again.  I've been trying 
to follow this story ever since my OLPC trashed the partition table on 
my 16GB SDHC card back in January.

A consensus seems to be building that suspend/resume is involved.  But I 
don't think anybody really understands what's going on, and people have 
been bashing their heads against this again and again for six months.

If something like this is happening in the Neo, then this could turn 
into a world of hurt.


Recommendation:


Everybody, get a Micro-SD card and stick it in your Neo.  Put some 
random files on it, you don't have to do anything serious with it, just 
let it sit in there for a while.  Periodically check that you can still 
see those files.  If you lose those files, post about it.  Maybe we 
should start a new thread to keep track of this data.

There have been some indications that partition type may have some 
effect on this problem on the OLPC.  So, shrink the default vfat 
partition that came on the card and put an ext3 on there too.  If you 
want to be adventurous, try some other types.

If more people start seeing problems like this, we ought to start 
comparing notes with the OLPC people who are working on this.  And 
Pierre Ossman too, he did a lot of work on SD support in the kernel.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Mikael Berthe
* Doug Jones [EMAIL PROTECTED] [2008-07-24 01:21 +0200]:
 
 There have been some indications that partition type may have some 
 effect on this problem on the OLPC.

I doubt it.

 So, shrink the default vfat partition that came on the card and put
 an ext3 on there too.  If you want to be adventurous, try some other
 types.

Happens to me with ext3 partitions as well (or mixed vfat/ext3
partitions).

However if I restore the partition table the data are not corrupted,
at least so far it's been all right...
-- 
MiKael

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community