[Bug 788] Starting or stopping gsmd completely locks up the Neo

bugzilla-daemon at bugzilla.openmoko.org bugzilla-daemon at bugzilla.openmoko.org
Sun Sep 2 20:52:24 CEST 2007


http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=788





------- Additional Comments From fabchevalier at free.fr  2007-09-02 20:52 -------
More details on the issue:
In fact neo crashes during gsmd init script stop.

The line that triggers neo crashes is : 
echo "0" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on

I managed to reproduce it quite reliably doing the folloging:
echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on
start gsmd
stop gsmd
echo "0" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on

The funny thing is that if gsmd is not started and stopped (step 2 and 3), then
the 4th step does not trigger the crash.

I attached the debug board and did a bt to see where we are:

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: shared library handler failed to enable breakpoint
s3c24xx_serial_console_putchar (port=0xc033b080, ch=48) at
drivers/serial/s3c2410.c:1706
1706                    ufstat = rd_regl(port, S3C2410_UFSTAT);
(gdb) l
1701            unsigned long ufstat, utrstat;
1702
1703            if (ufcon & S3C2410_UFCON_FIFOMODE) {
1704                    /* fifo mode - check ammount of data in fifo registers... */
1705
1706                    ufstat = rd_regl(port, S3C2410_UFSTAT);
1707                    return (ufstat & info->tx_fifofull) ? 0 : 1;
1708            }
1709
1710            /* in non-fifo mode, we go and use the tx buffer empty */
(gdb) bt
#0  s3c24xx_serial_console_putchar (port=0xc033b080, ch=48) at
drivers/serial/s3c2410.c:1706
#1  0xc01851bc in uart_console_write (port=0xc033b080, 
    s=0xc034cfa3 "gta01-pm-gsm gta01-pm-gsm.0: powered down GSM, thus enabhling
seial console\n", count=76, 
    putchar=0xc018829c <s3c24xx_serial_console_putchar>) at
drivers/serial/serial_core.c:1785
#2  0xc01888d0 in s3c24xx_serial_console_write (co=<value optimized out>, s=0x30
<Address 0x30 out of bounds>, 
    count=520) at drivers/serial/s3c2410.c:1729
Cannot access memory at address 0xe89da7fc
(gdb) 

Does any experienced (==> not me ;-) ) kernel hacker see where that could come
from ?

Cheers,

Fabien



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the buglog mailing list