Re: 2+4+2 timing seemed to disrupt access to the sdcard
Em 31-07-2010 01:02, Marco Trevisan (Treviño) escreveu: On 26/07/2010 - 10.58 +0200, Helge Hafting wrote: I have been using the qi with 2+4+2 timing over the weekend, and noted two problems. (This with shr unstable and its 2.6.32 kernel.) First, lots of WSODs. This required lots of suspending (or reboot) without seeing the screen. This is not always possible, so lots of battery removal. Using this kernel [1] the WSODs stopped (I'm using this SHR unstable running from a µSD card)... However with it I can't use my wifi device. It isn't found at all by the phone! [1] http://www.bsdmn.com/openmoko/glamo/242/shrkernel_nows/ Have you tried to load yourself the ar6000 module? With July 30th SHR-U image I had to do that... modprobe ar6000 See if it brings wifi back to life (should be automatic but something is wrong). Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2+4+2 timing seemed to disrupt access to the sdcard
Rui Miguel Silva Seabra wrote: Em 31-07-2010 01:02, Marco Trevisan (Treviño) escreveu: On 26/07/2010 - 10.58 +0200, Helge Hafting wrote: I have been using the qi with 2+4+2 timing over the weekend, and noted two problems. (This with shr unstable and its 2.6.32 kernel.) First, lots of WSODs. This required lots of suspending (or reboot) without seeing the screen. This is not always possible, so lots of battery removal. Using this kernel [1] the WSODs stopped (I'm using this SHR unstable running from a µSD card)... However with it I can't use my wifi device. It isn't found at all by the phone! [1] http://www.bsdmn.com/openmoko/glamo/242/shrkernel_nows/ Have you tried to load yourself the ar6000 module? With July 30th SHR-U image I had to do that... modprobe ar6000 Fine... That worked. I forgot to check the module. :P However this kernel seems to work well, except for the resume white shadow which it leaves over the opened application until it doesn't get refreshed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2+4+2 timing seemed to disrupt access to the sdcard
On 26/07/2010 - 10.58 +0200, Helge Hafting wrote: I have been using the qi with 2+4+2 timing over the weekend, and noted two problems. (This with shr unstable and its 2.6.32 kernel.) First, lots of WSODs. This required lots of suspending (or reboot) without seeing the screen. This is not always possible, so lots of battery removal. Using this kernel [1] the WSODs stopped (I'm using this SHR unstable running from a µSD card)... However with it I can't use my wifi device. It isn't found at all by the phone! [1] http://www.bsdmn.com/openmoko/glamo/242/shrkernel_nows/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
2+4+2 timing seemed to disrupt access to the sdcard
I have been using the qi with 2+4+2 timing over the weekend, and noted two problems. (This with shr unstable and its 2.6.32 kernel.) First, lots of WSODs. This required lots of suspending (or reboot) without seeing the screen. This is not always possible, so lots of battery removal. All this crashing caused some filesystem trouble. And then the second problem showed up. I got i/o errors reading from the sdcard. Sometimes, I didn't get tiles for tangogps or pictures for my contacts. Unmounting the sdcard and running fsck ought to fix this. But the fix was temporary. fsck would claim to fix some issues, and when I remounted the card, I had normal access to the files. But it was all in the page cache - it wasn't real. Reboot, and exactly the same errors came up again. fsck would give exactly the same messages while running. And things would work for a while, but another reboot would always bring the same problems back. It was as if writes to the sdcard failed - but failed silently. So the kernel didn't notice. But nothing actually got written, it just stayed in the page cache so everything seemed ok. I also had a lot of hangs - probably because I have swap on the sdcard. If swapping to the card silently fail, then surely there is trouble when the stuff is swapped back in. Do the sdcard and the glamo share a bus? Maybe glamo can handle a speed that the sdcard cannot? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2+4+2 timing seemed to disrupt access to the sdcard
All this crashing caused some filesystem trouble. And then the second problem showed up. I got i/o errors reading from the sdcard. Sometimes, I didn't get tiles for tangogps or pictures for my contacts. Unmounting the sdcard and running fsck ought to fix this. But the fix was temporary. fsck would claim to fix some issues, and when I remounted the card, I had normal access to the files. But it was all in the page cache - it wasn't real. Reboot, and exactly the same errors came up again. fsck would give exactly the same messages while running. And things would work for a while, but another reboot would always bring the same problems back. It was as if writes to the sdcard failed - but failed silently. So the kernel didn't notice. But nothing actually got written, it just stayed in the page cache so everything seemed ok. I also had a lot of hangs - probably because I have swap on the sdcard. If swapping to the card silently fail, then surely there is trouble when the stuff is swapped back in. Do the sdcard and the glamo share a bus? Maybe glamo can handle a speed that the sdcard cannot? This is not related to the timing settings. I still use the default timing with new SHR-U and I have the same problem. I already opened a ticket in shr trac: http://trac.shr-project.org/trac/ticket/1143 The problem came up woth the new kernel, so I guess there is a problem with the sd driver in 2.6.32 -- n...@el-hennig.de Lubarsky's Law of Cybernetic Entomology: There's always one more bug. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2+4+2 timing seemed to disrupt access to the sdcard
Le 26/07/2010 10:58, Helge Hafting a écrit : First, lots of WSODs. This required lots of suspending (or reboot) without seeing the screen. This is not always possible, so lots of battery removal. I think the power button is a standard ATX button, if you keep it pressed for few seconds (5 ?) it should power off your Freerunner :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2+4+2 timing seemed to disrupt access to the sdcard
Am 26.07.2010 11:15, schrieb Xavier Cremaschi: Le 26/07/2010 10:58, Helge Hafting a écrit : First, lots of WSODs. This required lots of suspending (or reboot) without seeing the screen. This is not always possible, so lots of battery removal. I think the power button is a standard ATX button, if you keep it pressed for few seconds (5 ?) it should power off your Freerunner :) Sadly this function doesn't work with the 2.6.32 anymore. Or at least for me it doesn't work since change from 2.6.29 to 2.6.32. Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2+4+2 timing seemed to disrupt access to the sdcard
On Monday, 26. July 2010 11:50:15 Fox Mulder wrote: Am 26.07.2010 11:15, schrieb Xavier Cremaschi: Le 26/07/2010 10:58, Helge Hafting a écrit : First, lots of WSODs. This required lots of suspending (or reboot) without seeing the screen. This is not always possible, so lots of battery removal. I think the power button is a standard ATX button, if you keep it pressed for few seconds (5 ?) it should power off your Freerunner :) Sadly this function doesn't work with the 2.6.32 anymore. Or at least for me it doesn't work since change from 2.6.29 to 2.6.32. Ciao, Rainer I think there was a kernel patch, that did a shutdown on 8sec power button press, which I desperatley miss on 2.6.32... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
