From: Lewis G. <gi...@nm...> - 2009-06-18 18:24:28
|
i still suspect power supply problems, esp since it happens when you are turning the modem on and off. 1. try disconnecting the modem from the system (so it draws no power) and then see if your pppd script still crashes (obviously it won't work but it shouldn't crash) 2. hook up a scope to the power that is supplied to the gumstix to see if you see any drop in voltage when the crash occurs 3. it sounds like your main power supply is sufficient but if you have a dc/dc converter supplying the modem and gumstix, make sure that is able to produce the required current On Thu, Jun 18, 2009 at 1:59 PM, rketcham <Ric...@gm...> wrote: > > Hi Lewis, > > I have a bit more information. After a lot of debugging, waiting, and > reseting I found that one of my scripts was the culprit. I have a python > script that I use to upload data to a remote server I'll call > UploadData.py. > If the gumstix is using a cell modem UploadData.py uses a class called > pppdManager that manages the pppd connection. If the pppdManager fails to > get a connection after a number of tries it then resets the modem using an > init script in /etc/init.d/ called S52setup_modem. The pppdManager simply > calls: > > /etc/init.d/S52setup_modem restart > > > # cat S52setup_modem > #! /bin/sh > # > #Load the GPIO module > #GPIO can be accessed via /proc/gpio/ > #Bring the Modem On/Off GPIO to high > #Modem starts up when on/off pin is brought low and then high > # > > start() { > > if ! lsmod | grep proc_gpio > /dev/null > then > echo -n "Start GPIO module..." > modprobe proc_gpio > echo "GPIO in" > /proc/gpio/GPIO60 > echo "GPIO in" > /proc/gpio/GPIO86 > echo "done." > fi > > #If the modem isn't on, turn it on > if ! cat /proc/gpio/GPIO60 | grep set > /dev/null > then > echo -n "Turn cell modem on..." > #Common level (input high) > echo "GPIO out set" > /proc/gpio/GPIO86 > > #Turn Cell Modem On > echo "GPIO out clear" > /proc/gpio/GPIO86 #Set pin low > sleep 1 #Needs to be at least 1 > echo "GPIO out set" > /proc/gpio/GPIO86 #Set pin high > echo "done." > fi > > } > stop() { > #If the modem is on, turn it off > if cat /proc/gpio/GPIO60 | grep set > /dev/null > then > echo -n "Turn off modem." > > #Set both pins to high. > echo "GPIO out set" > /proc/gpio/GPIO86 > > sleep 1 # Let it settle for a sec... > > #Turn off modem. > echo "GPIO out clear" > /proc/gpio/GPIO86 #Set pin low > > sleep 3 #Sleep for at least 2 seconds > > echo "GPIO out set" > /proc/gpio/GPIO86 #Set pin high > echo "done." > fi > > } > restart() { > echo "Restart the modem" > stop > sleep 2 > start > } > > case "$1" in > start) > start > ;; > stop) > stop > ;; > restart|reload) > restart > ;; > *) > echo $"Usage: $0 {start|stop|restart}" > exit 1 > esac > > exit $? > > > Well, after tracing back to this I wanted to see if it was just this script > or the combination so I wrote an sh script which restarts the modem: > > # cat /pw/ModemTest.sh > #!/bin/sh > > while true > do > if ! ps | grep S52setup_modem | grep -v grep > /dev/null > then > echo "REStarting S52modem stuff..." > /etc/init.d/S52setup_modem restart& > else > echo "Don't launch upload..." > fi > sleep 5 > > done > > > After looping a number of times the gumstix usually locks up and restarts. > The lockups seem to occur all over the place either at the echo "GPIO... or > at one of the if statements. There usually isn't an oops but one did occur > after a reset which I'll post below. > > Do you have any thoughts on this? > > Thanks, > Rich > > Process events/0 (pid: 4, stack limit = 0xc0354260) > Stack: (0xc0355ed8 to 0xc0356000) > 5ec0: c0355f14 > c0355ee8 > 5ee0: c007232c c002d864 c0355f14 c033d9b0 00000001 c033d9a0 c0337f20 > 00000000 > 5f00: 00000000 00000000 c0355f34 c0355f18 c00724c8 c00722d0 c033eca0 > c0337f20 > 5f20: 00000000 c0209290 c0355f5c c0355f38 c0073a30 c0072428 00000000 > c0045fd8 > 5f40: 80000013 c0336da0 c0354000 c00739ec c0355f7c c0355f60 c00491e8 > c00739f8 > 5f60: c0336da8 c0354000 c0336da0 c0336db0 c0355fcc c0355f80 c0049a7c > c004913c > 5f80: 00000001 00000000 c0029bc8 00010000 00000000 00000000 c0346580 > c0035e10 > 5fa0: 00100100 00200200 ffffffff ffffffff c0336da0 c0354000 c0349ef4 > c0049958 > 5fc0: c0355ff4 c0355fd0 c004cf90 c0049964 ffffffff ffffffff 00000000 > 00000000 > 5fe0: 00000000 00000000 00000000 c0355ff8 c003be50 c004ceb4 00000000 > 00000000 > Backtrace: > [<c002d858>] (__bug+0x0/0x2c) from [<c007232c>] (free_block+0x68/0x158) > [<c00722c4>] (free_block+0x0/0x158) from [<c00724c8>] > (drain_array+0xac/0xd8) > [<c007241c>] (drain_array+0x0/0xd8) from [<c0073a30>] > (cache_reap+0x44/0x11c) > r7 = C0209290 r6 = 00000000 r5 = C0337F20 r4 = C033ECA0 > [<c00739ec>] (cache_reap+0x0/0x11c) from [<c00491e8>] > (run_workqueue+0xb8/0x158) > r7 = C00739EC r6 = C0354000 r5 = C0336DA0 r4 = 80000013 > [<c0049130>] (run_workqueue+0x0/0x158) from [<c0049a7c>] > (worker_thread+0x124/0x168) > r7 = C0336DB0 r6 = C0336DA0 r5 = C0354000 r4 = C0336DA8 > [<c0049958>] (worker_thread+0x0/0x168) from [<c004cf90>] > (kthread+0xe8/0x128) > r7 = C0049958 r6 = C0349EF4 r5 = C0354000 r4 = C0336DA0 > [<c004cea8>] (kthread+0x0/0x128) from [<c003be50>] (do_exit+0x0/0x7b4) > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > Code: e1a01000 e59f000c eb0030fa e3a03000 (e5833000) > Unable to handle kernel paging request at virtual address fffffeff > pgd = c7154000 > [fffffeff] *pgd=a0002021, *pte=00000000, *ppte=00000000 > Internal error: Oops: 817 [#2] > Modules linked in: cpufreq_conservative proc_gpio sa1100_wdt ipv6 smc911x > mii gumstix_smc911x cp2101 usbserial nls_iso8859_1 nls_cp437 vfat fat > nls_base ohci_hcd usbcore pxamci mmc_block mmc_core unix > CPU: 0 > PC is at __strncpy_from_user+0x10/0x40 > LR is at getname+0x98/0xe4 > pc : [<c00d4c30>] lr : [<c007e21c>] Not tainted > sp : c7027f48 ip : 400ca2d8 fp : c7027f64 > r10: 400d5e58 r9 : c7026000 r8 : c0029d64 > r7 : 00000005 r6 : fffffeff r5 : 00001000 r4 : 400ca2d8 > r3 : 0000002f r2 : 00000fff r1 : 400ca2d9 r0 : fffffeff > Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user > Control: 397F > Table: A7154000 DAC: 00000015 > Process klogd (pid: 515, stack limit = 0xc7026260) > Stack: (0xc7027f48 to 0xc7028000) > 7f40: c0029d64 00000000 00000000 ffffff9c c7027f94 > c7027f68 > 7f60: c0074354 c007e190 c0029d64 be800870 00000008 00000000 be8009b0 > be800840 > 7f80: 00000005 c0029d64 c7027fa4 c7027f98 c007444c c007433c 00000000 > c7027fa8 > 7fa0: c0029be0 c0074434 00000000 be8009b0 400ca2d8 00000000 00000000 > 00000000 > 7fc0: 00000000 be8009b0 be800840 00000005 00000000 400d6478 400d5e58 > be800df0 > 7fe0: 400ca2e1 be800778 40058f48 4004a884 60000010 400ca2d8 e5840060 > ea000005 > Backtrace: > [<c007e184>] (getname+0x0/0xe4) from [<c0074354>] (do_sys_open+0x24/0xe4) > r6 = FFFFFF9C r5 = 00000000 r4 = 00000000 > [<c0074330>] (do_sys_open+0x0/0xe4) from [<c007444c>] (sys_open+0x24/0x28) > r8 = C0029D64 r7 = 00000005 r6 = BE800840 r5 = BE8009B0 > r4 = 00000000 > [<c0074428>] (sys_open+0x0/0x28) from [<c0029be0>] > (ret_fast_syscall+0x0/0x2c) > Code: e1a0c001 e2522001 54f13001 4a000003 (e4c03001) > Unable to handle kernel paging request at virtual address ffffffff > pgd = c7d6c000 > [ffffffff] *pgd=a0002021, *pte=00000000, *ppte=00000000 > Internal error: Oops: 817 [#3] > Modules linked in: cpufreq_conservative proc_gpio sa1100_wdt ipv6 smc911x > mii gumstix_smc911x cp2101 usbserial nls_iso8859_1 nls_cp437 vfat fat > nls_base ohci_hcd usbcore pxamci mmc_block mmc_core unix > CPU: 0 > PC is at __strncpy_from_user+0x10/0x40 > LR is at getname+0x98/0xe4 > pc : [<c00d4c30>] lr : [<c007e21c>] Not tainted > sp : c0349f48 ip : 400ca2d8 fp : c0349f64 > r10: 400d5e58 r9 : c0348000 r8 : c0029d64 > r7 : 00000005 r6 : ffffffff r5 : 00001000 r4 : 400ca2d8 > r3 : 0000002f r2 : 00000fff r1 : 400ca2d9 r0 : ffffffff > Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user > Control: 397F > Table: A7D6C000 DAC: 00000015 > Process init (pid: 1, stack limit = 0xc0348260) > Stack: (0xc0349f48 to 0xc034a000) > 9f40: 00000000 00000000 00000000 ffffff9c c0349f94 > c0349f68 > 9f60: c0074354 c007e190 c0029d64 bed8d410 00000008 00000000 bed8d550 > bed8d3e0 > 9f80: 00000005 c0029d64 c0349fa4 c0349f98 c007444c c007433c 00000000 > c0349fa8 > 9fa0: c0029be0 c0074434 00000000 bed8d550 400ca2d8 00000000 00000000 > 00000000 > 9fc0: 00000000 bed8d550 bed8d3e0 00000005 fffebae8 400d6478 400d5e58 > bed8d990 > 9fe0: 400ca2e1 bed8d318 40058f48 4004a884 60000010 400ca2d8 00000000 > 00000010 > Backtrace: > [<c007e184>] (getname+0x0/0xe4) from [<c0074354>] (do_sys_open+0x24/0xe4) > r6 = FFFFFF9C r5 = 00000000 r4 = 00000000 > [<c0074330>] (do_sys_open+0x0/0xe4) from [<c007444c>] (sys_open+0x24/0x28) > r8 = C0029D64 r7 = 00000005 r6 = BED8D3E0 r5 = BED8D550 > r4 = 00000000 > [<c0074428>] (sys_open+0x0/0x28) from [<c0029be0>] > (ret_fast_syscall+0x0/0x2c) > Code: e1a0c001 e2522001 54f13001 4a000003 (e4c03001) > Kernel panic - not syncing: Attempted to kill init! > > > > > > > > Lewis Girod wrote: > > > > is the behavior deterministic and easily repeatable? > > maybe try starting pppd from a serial console and using strace or ltrace > > to > > see at what point it hangs? > > the serial console will also output any kernel "oopses" that might occur > > > > you might also try running the whole system from 5V. in my experience > > this > > has been OK and it gives you more headroom > > > > On Fri, Jun 12, 2009 at 3:11 PM, rketcham <Ric...@gm...> > wrote: > > > > > > -- > View this message in context: > http://www.nabble.com/Gumstix-Freezes%2C-need-advice...-tp23952168p24095359.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |