[Berlin-wireless] kernel uups

Andreas Burgfels burgfels
Mo Jan 28 16:28:38 CET 2008


Hallo Sven,
der Fehler, den ich Dir letzten Mittwoch zeigen wollte, ist wieder auf unserem
Internet-GW, 104.129.81.1, aufgetaucht. FFF 1.6.22.

Interessant zum Debuggen, oder kann ich ein 'reboot'-Aufruf starten?

Grusz a*


dmesg sagt folgendes dazu:
---------------------------------------------------------------------------
Kernel unaligned instruction access in unaligned.c::do_ade, line 550:
$0 : 00000000 1000fc00 007e0000 00000000 801e3060 818b1e98 00000000 ffffffea
$8 : 00000000 0000fc00 00000000 8016c000 0000192a 1000fc01 00000000 00000001
$16: 801c0000 00000000 00000000 816d8000 816c0000 818b1e90 00020000 801c0000
$24: ba2e8ba3 00000001                   818b0000 818b1e60 801d0000 8013fdd4
Hi : 00000000
Lo : 00000001
epc   : 00000001    Tainted: P
Status: 1000fc03
Cause : 00000010
PrId  : 00029007
Process nvram (pid: 1704, stackpage=818b0000)
Stack:    d5718000 800690bc 81c06140 ffffffea 00020000 00000002 816d8000
 00000000 00000000 818b0000 818b1e90 818b1e90 818b1e88 818b1e88 801e3460
 007e0000 00020000 800243e8 00000002 2ab709c0 00000002 8013fba4 818b1e90
 2ab709c0 81c06278 81c06260 81c06280 00000000 00018000 fffffff7 00000000
 ffffffe7 48534c46 81a30420 00000003 00400654 7fff7ec4 00000002 00000000
 800486f8 ...
Call Trace:   [<800690bc>] [<800243e8>] [<8013fba4>] [<800486f8>] [<80036af4>]
 [<800088e0>] [<8005aefc>]

Code: (Bad address in epc)

Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 1000fc00 464c457e 464c457f 00400000 00000000 00000000 0000002a
$8 : 00008996 81431e9c 06010001 d3660f00 00000002 81431e68 00000000 00000001
$16: 81eba2c0 0000002a 81431e68 81a2e420 00000060 0000002a 100006f4 00000005
$24: 00000000 81418070                   81430000 81431db0 00000000 800c64cc
Hi : 00000000
Lo : 00000049
epc   : 800c6520    Tainted: P
Status: 1000fc03
Cause : 00000004
PrId  : 00029007
Process olsrd (pid: 8980, stackpage=81430000)
Stack:    00000060 0000002a 100006f4 00000005 81eba2c0 80130078 00000000
 81e17460 81431ee0 00000001 80047190 80047094 0000002a 00000001 00000060
 81431e20 0000002a 813b1348 81431e68 81431e88 800c29e8 8004d5e8 41200000
 81430298 801d3460 81e17460 81431e20 00000000 00000000 00000000 00000000
 00000000 00000000 00000005 813b1348 0000002a 00000020 7fff6ba8 7fff6bd8
 800c3924 ...
Call Trace:   [<80130078>] [<80047190>] [<80047094>] [<800c29e8>] [<8004d5e8>]
 [<800c3924>] [<8008e450>] [<8008dde8>] [<800865d0>] [<80049b28>] [<80007178>]
 [<800088e0>] [<80005928>]

Code: 00000000  c0830000  2462ffff <e0820000> 1040fffc  2462ffff  0000000f
14400003  00000000
------------------------------------------------------------------------------


Das Logread steht voll mit solchen Ausdruecken; rrdcollect steht doch im
zusammenhang mit dem Gateway-Plugin bzw. Accounting-Datenbank - ein Zusammenhang
zwischen logread vs dmesg sehe ich nicht.
------------------------------------------------------------------------------
Jan 28 15:21:55 (none) kern.debug rrdcollect[3839]: tick
Jan 28 15:21:55 (none) kern.debug rrdcollect[3839]: rrdlib_update(5,'update')
Jan 28 15:21:55 (none) kern.debug rrdcollect[3839]: rrdlib_update(5,'update')
------------------------------------------------------------------------------




Mehr Informationen über die Mailingliste Berlin