xserver-xglamo eats 100% cpu time after resume

[lindi]

xserver-xglamo seems to spend 100% cpu time after resume from suspend sometimes.

I am using debian with

ii linux-image-2.6.24-openmoko-gta02 20081103.git7172ec57-1 Linux 2.6.24 kernel image for the Openmoko Neo Freerunner
ii xserver-xglamo 1.3.0.0+git20080807-3 tiny X server for the SMedia Glamo graphics chipset

Strace shows that xglamo calls gettimeofday again and again. The attached file xglamo-instructions.txt shows what instructions xglamo is executing according to gdb but backtrace prints just

#0 0x00014e3c in ?? ()
Cannot access memory at address 0x0

so it is not very usable. I can not kill X with kill -9 and dmesg shows

BUG: scheduling while atomic: X/1885/0x00000002
[<c0344a08>] (dump_stack+0x0/0x14) from [<c0041cdc>] (__schedule_bug+0x50/0x5c)
[<c0041c8c>] (__schedule_bug+0x0/0x5c) from [<c02b7c78>] (schedule+0x6c/0x2d4)
 r4:0001c33b
[<c02b7c0c>] (schedule+0x0/0x2d4) from [<c0041fec>] (sys_sched_yield+0x48/0x54)
[<c0041fa4>] (sys_sched_yield+0x0/0x54) from [<c02b8024>] (yield+0x24/0x28)
[<c02b8000>] (yield+0x0/0x28) from [<c01ad0d0>] (glamofb_cmd_mode+0x24/0xf0)
[<c01ad0ac>] (glamofb_cmd_mode+0x0/0xf0) from [<c01ad200>] (glamofb_set_par+0x64/0x444)
 r5:c7c6ce74 r4:c7c6cc00
[<c01ad19c>] (glamofb_set_par+0x0/0x444) from [<c01740ac>] (fb_set_var+0x1ac/0x258)
 r8:00000020 r7:c71abe48 r6:c7c6cc00 r5:c71abe48 r4:c01ace70
[<c0173f00>] (fb_set_var+0x0/0x258) from [<c01742ac>] (fb_ioctl+0x154/0x4dc)
[<c0174158>] (fb_ioctl+0x0/0x4dc) from [<c00a3b48>] (do_ioctl+0x80/0x9c)
 r8:c0029128 r7:00134628 r6:00004601 r5:00134628 r4:c7e652c0
[<c00a3ac8>] (do_ioctl+0x0/0x9c) from [<c00a3e1c>] (vfs_ioctl+0x2b8/0x2e8)
 r6:00004601 r5:c7e652c0 r4:c7ea80a4
[<c00a3b64>] (vfs_ioctl+0x0/0x2e8) from [<c00a3e8c>] (sys_ioctl+0x40/0x60)
 r7:c7e652c0 r6:00004601 r5:00134628 r4:00000004
[<c00a3e4c>] (sys_ioctl+0x0/0x60) from [<c0028f80>] (ret_fast_syscall+0x0/0x2c)
 r7:00000036 r6:00134fe0 r5:001351a8 r4:00134628

[andy]

I believe I fixed this on stable-tracking a while ago

​http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=cd21081b281a4bfc00a5a41280bda734d2139f65

[lindi]

Thanks for your patch. I started a kernel build to test your patch but meanwhile the bug occured again.

X seems to respond to touchscreen, I can move the mouse pointer but there is a lag of several seconds before it moves to a new position. X does not seem to ever finish redrawing xvkbd buttons (it has drawn the first row of letters but nothing new seems to be drawn). This time I don't see BUG print from kernel so maybe it is only printed if I try to kill -9 X? Before I could issue the kill command try this the device suddenly stopped responding to ping over usb network and did not react to anything on the touchscreen. I had to remove the battery to make it boot again.

I have not changed kernel recently. The only major change was upgrading to new version of fso-frameworkd and using.

mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/Usage org.freesmartphone.Usage.Suspend

instead of

mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Device.PrepareForSuspend
apm -s
mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Device.RecoverFromSuspend

to issue suspend (I had to do this since the API changed and the daemon itself now wants to do the "apm -s" invocation.)

[lindi]

changing

os.system("apm -s")

in the frameworkd source code to

os.system("sleep 4; apm -s; sleep 4")

seems to workaround the issue. Maybe this is some sort of race that happens when other processes slow down xglamo enough?

[lindi]

With your patch I was able to do multiple suspends without any crashes (without those extra sleeps). I am now testing stable-tracking (with gta02-moredrivers-defconfig) which afaik has that patch too so I'll report back if I see xglamo freezing on resume again.

[andy]

Great... you're better off with stable-tracking for suspend issues overall for sure.

FWIW Graeme is making full xorg solution for glamo

​http://git.openmoko.org/?p=xglamo.git;a=shortlog;h=xora/xorg-driver

it's intended this will rewrite and fix the worst issues in there.

[lindi]

I hit this now with stable-tracking at 1b17c67794364bee. I am attaching full dmesg output.

[lindi]

output of 1b17c67794364bee from bootup till the moment where xglamo gets stuck

[lindi]

I can kill -9 xglamo this time. When I start xglamo again it does not exit but I do not see anything on the screen either. Kernel prints the following:

Nov 25 15:04:50 ginger user.err kernel: [43325.595000] glamofb_update_lcd_controller spin_lock_irqsave
Nov 25 15:04:50 ginger user.err kernel: [43325.595000] glamofb_update_lcd_controller spin_unlock_irqrestore
Nov 25 15:04:50 ginger user.err kernel: [43325.615000] fbcon_event_notify action=1, data=c7269df0
Nov 25 15:04:50 ginger user.err kernel: [43325.660000] glamofb_update_lcd_controller spin_lock_irqsave
Nov 25 15:04:50 ginger user.err kernel: [43325.660000] glamofb_update_lcd_controller spin_unlock_irqrestore
Nov 25 15:04:50 ginger user.err kernel: [43325.665000] fbcon_event_notify action=1, data=c7269df0

Also trying to set the backlight does not work anymore with X or without X running:

root@ginger:~# echo 1 > /sys/class/backlight/pcf50633-bl/bl_power
root@ginger:~# cat /sys/class/backlight/pcf50633-bl/bl_power
1
root@ginger:~# echo 63 > /sys/class/backlight/pcf50633-bl/brightness
root@ginger:~# cat /sys/class/backlight/pcf50633-bl/actual_brightness
2

Shouldn't backlight be adjustable always like that? (And would mean that this is actually a kernel bug and not xglamo bug).

[zecke]

Duplicate of #1315 and #2221 (filed by you?). Maybe you want to copy some of this to the other bug.