From: Philippe N. <pn....@gm...> - 2007-09-13 20:22:20
|
hi excuse my english, i am french i use verdex motherboard with bluetooth dongle and i create a simply program which scan all device bluetooth and push it information (bluez+openobex) but i don't make a finish product, because in a unpredictable way the verdex stop and if i connect it to a terminal to verify, i have : > > Gumstix Flash ROM: buffer write error (status 0xd0) > > Write clean marker to block at 0x00a40000 failed: -22 > > Gumstix Flash ROM: Chip not ready after erase suspended: status = > > 0x0 > before the net configuration and it was stopped ... i thinks it's in module section ... this error does not appear at each boot, it works perfectly during several days and one day, ..... how to repare this problem because i don't find any bug in my configuration ? can you help me to find where is the bad definition of parameters. to repare it, i juste use this parameters on boot : setenv bootargs $bootargs init=/bin/sh boot and i stoppe the power and i restart ... but it's not a solution for a finish product ! thanks philippe |
From: Craig H. <cr...@gu...> - 2007-09-17 18:13:34
|
On Sep 13, 2007, at 1:21 PM, Philippe NAHOUM wrote: > but i don't make a finish product, because in a unpredictable way the > verdex stop and if i connect it to a terminal to verify, i have : > >>> Gumstix Flash ROM: buffer write error (status 0xd0) >>> Write clean marker to block at 0x00a40000 failed: -22 >>> Gumstix Flash ROM: Chip not ready after erase suspended: =20 >>> status =3D >>> 0x0 Philippe, I think I've seen that a couple of times in the last couple of years =20 during boot, when people have been doing heavy numbers of tiny writes =20= to files in JFFS2. When you do that, I think JFFS2 gets heavily =20 fragmented because each write ends up relocating chunks of the flash =20 due to wear-leveling and stuff (I think). The error you're showing =20 above comes from when the kernel is trying to suspend a flash erase =20 operation in order to perform some other op (probably a read at boot =20 time) from the device. It looks like there's a ~1 second timeout =20 (jiffies > old_jiffies+HZ) trying to wait for the suspend to be =20 reported as having happened, and that timeout's being exceeded. The =20 flash chip spec says that the latency there should be a max of 25=C2=B5s, = =20 so this is a little odd. BUT -- it's possible that something funky =20 is happening if the chip is under very heavy load, due to heavy FS =20 fragmentation. I'd suggest asking this question on the JFFS2 mailing list -- they'll =20= have a much better idea of what the FS is doing at boot time which =20 might be causing this timeout to get exceeded. I assume that the =20 hardware is indeed OK; ie that if you erase the flash in u-boot and =20 re-write it, it's still fine? C= |