Re: Resume bug on 2.6.39 kernel identified! (was QTMoko v55 GTA02 flash issue)
On Tue, Jan 21, 2014 at 08:15:27AM +0100, Radek Polak wrote: I tried rmmod ar6000 and i cant reproduce my resume issues anymore! I had running my dial script over night. Freerunner now shows 333 succesful resumes, while it used to fail after 30 resumes before. So please if you are using 2.6.39 kernel edit /etc/modules, remove or comment out line with ar6000, reboot and report if your resume issues are gone. Good news Radek, thanks for the update. I haven't upgraded from v55 to v58 yet, mostly because of the unreliable suspend issue, but I shall certainly do so soon! Thanks again for your continued work. Nick ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Resume bug on 2.6.39 kernel identified! (was QTMoko v55 GTA02 flash issue)
hi radek, thank for digging in so deep to find the bug. If I remove the ar6000 does that also mean that I will not be able to use wifi (that would be my guess)? and as an off topic question: if I remove btusb and bluetooth (as I am not using bluetooth at all) would this somehow interfere with qtmoko (eg are those modules expected to be present somewhere else?) best regards and as always: many thanks to you and the extended qtmoko development crew for keeping the GTA02 alive!!! robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
qtmoko tethering
hi, I was just wondering if someone has managed to share a qtmoko-gsm connection via bluetooth to an android device. If so would you please share the steps necessary. best regards robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Resume bug on 2.6.39 kernel identified! (was QTMoko v55 GTA02 flash issue)
On Tuesday, January 21, 2014 10:53:08 AM robin wrote: hi radek, thank for digging in so deep to find the bug. If I remove the ar6000 does that also mean that I will not be able to use wifi (that would be my guess)? Yes Maybe it would be possible to use before-suspend.sh and after-resume.sh scripts to rmmod ar6000 and modprobe ar6000 + rfkill unblock wifi. This way wifi should work as before. But I hope we can find proper kernel fix for this. and as an off topic question: if I remove btusb and bluetooth (as I am not using bluetooth at all) would this somehow interfere with qtmoko (eg are those modules expected to be present somewhere else?) It can, i saw some errors during boot when bluetooth was not working. Maybe you would have to disable bluetooth service too to make it working. But i am not sure if it's worth the trouble. Bluetooth is by default off anyways so it should not eat your battery or CPU. best regards and as always: many thanks to you and the extended qtmoko development crew for keeping the GTA02 alive!!! Thanks :) I am also happy that things are moving on. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Resume bug on 2.6.39 kernel identified! (was QTMoko v55 GTA02 flash issue)
On Tuesday, January 21, 2014 10:21:09 AM Jake Drexel wrote: On 1/21/14, Jake Drexel jackram...@googlemail.com wrote: Good to hear that. The strange thing is that the issue also is hw dependend. After I took apart my phone, reseated the wifi-board, put it back together, and replaced the two screws which I unsrcewed years ago, I didn't have a single resume (or rather suspend) problem in the last 6 weeks. The imminent problem why the kernel does not suspend again, is that in the kernel there is some handler registered which calls a function off mmc, when going into supend. But the function doesn't return (as it can't communicate with the ar6000?). So it just sits there. This sounds like a good explanation (although i am not kernel dev). Thanks! Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko tethering
On Tuesday, January 21, 2014 10:56:25 AM robin wrote: I was just wondering if someone has managed to share a qtmoko-gsm connection via bluetooth to an android device. If so would you please share the steps necessary. I think it should work. You have to dial GSM on Freerunner. Then you should start bluetooth personal area network (PAN). There used to be pand command and IIRC the argument to start bluetooth net was -nap (network access point). Then you will have to connect with android - i think there are apps for this like this one: http://www.appsapk.com/tetherblu-free/ Once connected you will have network interface on Freerunner called pan0 and you can use iptables to enable IP forwarding (you can see qtmoko's share- gprs.sh script for inspiration). But i havent tried myself - i dont have any android devices. BR Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Building qtmoko for Neo.
On 01/20/2014 06:16 PM, Radek Polak wrote: 1. The cdebootstrap step in the script fails unless I add --allow-unauthenticated. Not sure what is going on nor whose fault it is. Hmm maybe you have to install debian/emdebian apt keyring to get rid of this. I am on debian, that's maybe why it works for me... I do have debian-keyring and emdebian-archive-keyring installed, will look a bit further. 2. At some point during the script running, something breaks in my box. Some applets hang, and chromium starts to fail to load complaining on incorrect permissions on /dev/shm. Doing sudo chmod 1777 /dev/shm seems to fix that, but I don't know what else is happening. Ahh interesting, i am getting this error too, but it never occured to me that this is because of qtmoko chroot. It can be related to binded mounts... (will comment later) You can try append -verbose to see more details. Otherwise you might need the devel packages like libasound2-dev libssl-dev but i wonder why they are not installed - i have checked the qtmoko-chroot- armel.sh and they are there. Yes, the packages are there, and running with -verbose show the following: --- arm-linux-gnueabi-g++ -MMD -MF /root/qte/build/config.tests/alsa/.obj/main.cpp.d -c -pipe -DQT_QWS_FICGTA01 -fno-exceptions -fno-rtti -fno-rtti -fno-exceptions -O2 -fomit-frame-pointer -finline-functions -falign-functions=2 -falign-loops=2 -falign-jumps=2 -march=armv4t -mtune=arm920t -msoft-float -D_FORTIFY_SOURCE=0 -D_FORTIFY_SOURCE=0 -DQT_NO_DYNAMIC_CAST -I/root/qte/build/sdk/devices/root/qte/qtmoko/devices/neo/mkspecs/qws/linux-neo-g++ -I/root/qte/build/config.tests/devices/root/qte/qtmoko/devices/neo/mkspecs/qws/linux-neo-g++ -I/root/qte/qtmoko/devices/neo/mkspecs/qws/linux-neo-g++ -I/root/qte/build/config.tests/alsa -I/root/qte/qtmoko/config.tests/alsa -I/root/qte/qtmoko/alsa -I/root/qte/build/alsa -o /root/qte/build/config.tests/alsa/.obj/main.o /root/qte/qtmoko/config.tests/alsa/main.cpp /root/qte/qtmoko/config.tests/alsa/main.cpp:1:28: warning: alsa/asoundlib.h: No such file or directory --- Nevertheless, the file /usr/include/alsa/asoundlib.h is in place, don't know why it doesn't find it. On mounts, yes, there is definitely something fishy. Mount shows the following that does not look right: --- /dev on /home/jvisca/sources/qtmoko-chroot/dev type none (rw,bind) /home/jvisca/sources on /home/jvisca/sources/qtmoko-chroot/root/qte type none (rw,bind) /home/jvisca/sources on /home/jvisca/sources/qtmoko-chroot/var/lib/dbus type none (rw,bind) /var/lib/dbus on /home/jvisca/sources/qtmoko-chroot/var/lib/dbus type none (rw,bind) --- Actually, that is a bit scary :) Regards, Jorge ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: CSD calls from Neo Freerunner
On Monday 20 January 2014 07:31:55 Michael Spacefalcon wrote: For those who don't know what CSD is: http://en.wikipedia.org/wiki/Circuit_Switched_Data [snip test call logs] CSD calls may be placed from a GSM mobile either to a land line or to another mobile. (I don't know if it's possible to establish a CSD connection from a land line to a mobile.) It's possible to establish the connection from land line to mobile, with both analogue and ISDN landlines. I used to use it for remote access to condition monitoring systems. You should be able to send and receive faxes too. It does need carrier support though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: CSD calls from Neo Freerunner
On Tue 21 January 2014 15:42:20 Al Johnson wrote: On Monday 20 January 2014 07:31:55 Michael Spacefalcon wrote: For those who don't know what CSD is: http://en.wikipedia.org/wiki/Circuit_Switched_Data [snip test call logs] CSD calls may be placed from a GSM mobile either to a land line or to another mobile. (I don't know if it's possible to establish a CSD connection from a land line to a mobile.) It's possible to establish the connection from land line to mobile, with both analogue and ISDN landlines. I used to use it for remote access to condition monitoring systems. You should be able to send and receive faxes too. It does need carrier support though. For landline to mobile you need to signal to carrier that the OTA connection shall not use GSM-codec for voice but rather establish a 9k6 data connection. From ISDN you can set the data service class flag, from analog landline there is no such flag. So usually a dedicated telephone number for inbound CSD- datacalls is mandatory and carriers rarely support this nowadays, anyway you have to ask your carrier to provide such number for your mobile. IIRC there's another method where mobile switches type of a connection on the fly, so you'd initiate a voice call from landline to mobile and then mobile switches type to datacall. Can't remember what the according AT-commands been to accomplish that. cheers jOERG -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (alas the above page got scrapped due to resignation(!!), so here some supplementary links:) http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German) 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
