Re: problems with qtmoko continuously re-starting
Radek Polak pson...@seznam.cz writes: On Thursday, May 17, 2012 12:55:13 AM Robin Paulson wrote: it printed this, i'm not sure what it means: QDBusObjectPath: invalid path Method call /-DefaultAdapter() failed: QDBusError(org.bluez.Error.NoSuchAdapter, No such adapter) I'm also seeing this problem now, and (unlike Robin) I don't think I've physically done anything to my bluetooth chip. So possibly this is a software problem after all. If you need bluetooth we have to figure out what is wrong with it. You can try dmesg and hciconfig to find what if blueooth adapter is up and working (e.g. is hcitool scan works). dmesg: -8-- [0.00] Linux version 3.2.14-gta04+ (root@qtmoko-buildhost) (gcc version 4.6.2 (Debian 4.6.2-12) ) #1 PREEMPT Tue Apr 10 16:42:22 UTC 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: GTA04 [0.00] Ignoring tag cmdline (using the default kernel command line) [0.00] debug: ignoring loglevel setting. [0.00] Reserving 12582912 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 128000 [0.00] free_area_init_node: node 0, pgdat c0726b74, node_mem_map c0948000 [0.00] Normal zone: 1024 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 126976 pages, LIFO batch:31 [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 126976 [0.00] Kernel command line: console=ttyO2,115200n8 mpurate=800 vram=12M omapfb.rotate_type=0 omapdss.def_disp=lcd root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel [0.00] log_buf_len: 8388608 [0.00] early log buf free: 2095643(99%) [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 500MB = 500MB total [0.00] Memory: 489772k/489772k available, 34516k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xf800 ( 376 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc0625218 (6261 kB) [0.00] .init : 0xc0626000 - 0xc06b ( 552 kB) [0.00] .data : 0xc06b - 0xc07273a0 ( 477 kB) [0.00].bss : 0xc07273c4 - 0xc09479f0 (2178 kB) [0.00] NR_IRQS:410 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.000183] Calibrating delay loop... 475.76 BogoMIPS (lpj=1855488) [0.074401] pid_max: default: 32768 minimum: 301 [0.074554] Mount-cache hash table entries: 512 [0.074951] CPU: Testing write buffer coherency: ok [0.075958] devtmpfs: initialized [0.077484] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck. [0.079406] print_constraints: dummy: [0.079650] NET: Registered protocol family 16 [0.079803] GPMC revision 5.0 [0.081237] OMAP GPIO hardware version 2.5 [0.082489] running gta04_init() [0.082489] omap_mux_init: Add partition: #1: core, flags: 0 [0.083496] Running gta04_init_rev() [0.083801] gta04_rev 3 [0.085815] Reprogramming SDRC clock to 33200 Hz [0.088745] Revision GTA04A3 [0.090393] Found NAND on CS0 [0.090393] Registering NAND on CS0 [0.090637] gta04_init done... [0.090698] hw-breakpoint: debug architecture 0x4 unsupported. [0.095214] Calibrating delay loop (skipped) already calibrated this CPU [0.095336] Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/800 MHz [0.095489] OMAP DMA hardware revision 5.0 [0.100280] bio: create slab bio-0 at 0 [0.101257] SCSI subsystem initialized [0.102142] usbcore: registered new interface driver usbfs [0.102233] usbcore: registered new interface driver hub [0.102386] usbcore: registered new device driver usb [0.102905] omap_i2c omap_i2c.1:
Re: problems with qtmoko continuously re-starting
On Sunday 10 June 2012 14:23:20 Neil Jerram wrote: rfkill state: -8-- root@neo:~# rfkill list 0: GPS: GPS Soft blocked: no Hard blocked: no 1: Bluetooth: Bluetooth Soft blocked: yes ^^ this looks like bluetooth if off. Can you try unblock it? IIRC it was: rfkill unblock bluetooth Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
Radek Polak pson...@seznam.cz writes: On Sunday 10 June 2012 14:23:20 Neil Jerram wrote: rfkill state: -8-- root@neo:~# rfkill list 0: GPS: GPS Soft blocked: no Hard blocked: no 1: Bluetooth: Bluetooth Soft blocked: yes ^^ this looks like bluetooth if off. Can you try unblock it? IIRC it was: rfkill unblock bluetooth Well there is a line rfkill block bluetooth in qpe.sh, so I guess that is what blocked it. Also I'd guess now that this problem - QtMoko restarting because of a bluetooth problem - is a simple race between that background rfkill command and the rest of the qpe.sh script. (It then makes sense that if QtMoko doesn't start quickly enough the first time, because of bluetooth already being off, it will never start on any further iterations.) Here's what I see after commenting out that rfkill line: - QtMoko starts up fine. (This is not yet significant, though, because it often starts up fine anyway.) - Bluetooth symbol is shown in the top line of the UI - Diagnostic output: -8-- root@neo:/opt/qtmoko# hciconfig hci0: Type: BR/EDR Bus: UART BD Address: 00:19:88:19:DD:23 ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:1564 acl:0 sco:0 events:47 errors:0 TX bytes:510 acl:0 sco:0 commands:47 errors:0 root@neo:/opt/qtmoko# hcitool scan Scanning ... root@neo:/opt/qtmoko# rfkill list 0: GPS: GPS Soft blocked: no Hard blocked: no 1: Bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: hso-5: Wireless WAN Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 4: hci0: Bluetooth Soft blocked: no Hard blocked: no -8-- Presumably, then, the right fix for this is either to ensure somehow that the rfkill block bluetooth happens after QtMoko startup, or to make QtMoko start up even if bluetooth is off. The latter would be better, because someone might have switched bluetooth off and then choose to Restart QtMoko. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
On Sunday 10 June 2012 18:25:56 Neil Jerram wrote: Presumably, then, the right fix for this is either to ensure somehow that the rfkill block bluetooth happens after QtMoko startup, or to make QtMoko start up even if bluetooth is off. The latter would be better, because someone might have switched bluetooth off and then choose to Restart QtMoko. Sure, if i find some time, i'll try to fix this for v46. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
Thats solves my problem too. I have disabled bluetooth (and GSM) in my GTA02 in init script, left device some time unused (and forgot about this small change) and then woder why crashes. Dne 10.6.2012 23:24, Radek Polak napsal(a): On Sunday 10 June 2012 18:25:56 Neil Jerram wrote: Presumably, then, the right fix for this is either to ensure somehow that the rfkill block bluetooth happens after QtMoko startup, or to make QtMoko start up even if bluetooth is off. The latter would be better, because someone might have switched bluetooth off and then choose to Restart QtMoko. Sure, if i find some time, i'll try to fix this for v46. Regards Radek ___ 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: problems with qtmoko continuously re-starting
Radek Polak pson...@seznam.cz writes: On Thursday, May 17, 2012 12:55:13 AM Robin Paulson wrote: it printed this, i'm not sure what it means: QDBusObjectPath: invalid path Method call /-DefaultAdapter() failed: QDBusError(org.bluez.Error.NoSuchAdapter, No such adapter) It looks like bluetooth adapter and bluez are not working. You can try: [...] I wonder if it would be a generally useful idea to catch and show qpe's output in cases like this, and then give the user the choice of restarting or powering off? I think that might be less alarming that seeing the UI restarting repeatedly. When this restarting last happened to me, I was worried if it would be safe to force the phone to power off - so it would be nice to have an explicit option for that. Alternatively, the top level loop could measure how quickly qpe is restarting, and power off automatically if it restarts twice in less than 1 minute. In that case it might also pop up a notice/explanation, with a reference to where to look (on the SD card) to see qpe's output. What do you think? Are either of those worthwhile? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
On Monday, June 04, 2012 09:38:17 AM Neil Jerram wrote: I wonder if it would be a generally useful idea to catch and show qpe's output in cases like this, and then give the user the choice of restarting or powering off? I think that might be less alarming that seeing the UI restarting repeatedly. When this restarting last happened to me, I was worried if it would be safe to force the phone to power off - so it would be nice to have an explicit option for that. Alternatively, the top level loop could measure how quickly qpe is restarting, and power off automatically if it restarts twice in less than 1 minute. In that case it might also pop up a notice/explanation, with a reference to where to look (on the SD card) to see qpe's output. What do you think? Are either of those worthwhile? In this case it's quite obvious bug - qtmoko should not segfault when bluetooth is not working. The bluetooth stuff needs to be done much better. The bluez bindings should be autogenrated from .xml dbus files - like it's done for FSO and oFono and they should handle the case when bluetooth is not working correctly. But if you'd like to implement this logic i wont have problem including it - if it's not too much complex. E.g. redirecting qpe output to /dev/tty0 in case it crashes should not be too hard. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
On 17 May 2012 18:35, Radek Polak pson...@seznam.cz wrote: It looks like bluetooth adapter and bluez are not working. You can try: /etc/init.d/bluetooth stop or update-rc.d -f bluetooth remove First commands stops bluetooth and after that qtmoko will start ok. Second one disable bluetooth during init, so you will have qtmoko working also after restart (but without bluetooth). success! it is working now If you need bluetooth we have to figure out what is wrong with it. You can i think i physically fubar'd the bluetooth board when i replaced the screen. i remember thinking i had pressed too hard and wondered which part of the phone it was. fortunately i've never used bluetooth and don't intent to, so no problems. thanks for the help -- robin http://fu.ac.nz - Auckland's Free University ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
On Thursday, May 17, 2012 12:55:13 AM Robin Paulson wrote: it printed this, i'm not sure what it means: QDBusObjectPath: invalid path Method call /-DefaultAdapter() failed: QDBusError(org.bluez.Error.NoSuchAdapter, No such adapter) It looks like bluetooth adapter and bluez are not working. You can try: /etc/init.d/bluetooth stop or update-rc.d -f bluetooth remove First commands stops bluetooth and after that qtmoko will start ok. Second one disable bluetooth during init, so you will have qtmoko working also after restart (but without bluetooth). If you need bluetooth we have to figure out what is wrong with it. You can try dmesg and hciconfig to find what if blueooth adapter is up and working (e.g. is hcitool scan works). Regards Radek___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
On Wednesday, May 16, 2012 02:30:36 AM Robin Paulson wrote: any suggestions what to do? i've checked the connections on the screen and they are fine. i wonder if it's anything to do with the calibration of the touchpad? is there anyway to manually edit it, i.e. a .conf file somewhere? You can try to start qtmoko from ssh: ssh root@192.168.0.202 /etc/init.d/qtmoko-neo stop . /opt/qtmoko/qpe.env qpe It should print something useful. Regards Radek___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
On 16 May 2012 22:28, Radek Polak pson...@seznam.cz wrote: You can try to start qtmoko from ssh: ssh root@192.168.0.202 /etc/init.d/qtmoko-neo stop . /opt/qtmoko/qpe.env qpe It should print something useful. it printed this, i'm not sure what it means: QDBusObjectPath: invalid path Method call /-DefaultAdapter() failed: QDBusError(org.bluez.Error.NoSuchAdapter, No such adapter) -- robin http://fu.ac.nz - Auckland's Free University ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
On Thu, 17 May 2012 10:55:13 +1200 Robin Paulson robin.paul...@gmail.com wrote: On 16 May 2012 22:28, Radek Polak pson...@seznam.cz wrote: You can try to start qtmoko from ssh: ssh root@192.168.0.202 /etc/init.d/qtmoko-neo stop . /opt/qtmoko/qpe.env qpe It should print something useful. it printed this, i'm not sure what it means: QDBusObjectPath: invalid path Method call /-DefaultAdapter() failed: QDBusError(org.bluez.Error.NoSuchAdapter, No such adapter) That's suggesting a bluetooth device error because of an empty path. I don't think that's likely to be the cause of your trouble. It's probably indicative of something you may have missed during reassembly perhaps which may be the root cause. This is also assuming you've already attempted trying other distros on known to work media of course. Brian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
problems with qtmoko continuously re-starting
hi all, i broke the screen on my freerunner a while back (although it still displayed, and the touch part sort of worked), and put a new one in last week, bought from a seller on ebay. i booted the freerunner up, and the screen appeared to work fine, boot text was moving across the screen. however, when qtmoko started, the timer thing in the centre of the screen stayed on, and then qtmoko restarted. then it restarted again, and again, and again. i ran top via ssh from my laptop, and cpu for qpe is very high all the time. so, i uninstalled and purged qtmoko, then reinstalled (v.44-1). same thing again. any suggestions what to do? i've checked the connections on the screen and they are fine. i wonder if it's anything to do with the calibration of the touchpad? is there anyway to manually edit it, i.e. a .conf file somewhere? cheers, -- robin http://fu.ac.nz - Auckland's Free University ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
