USB networking problem on Sheevaplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I've recently been encountering a problem on my Sheevaplug home server.
It's currently set up as a router, using the built-in ethernet for
inside and a USB widget for outside. This has been running happily for
months --- indeed, I went away for five weeks and had no problems.
However, during the past week the USB networking has twice failed. Stack
trace enclosed.
This *may* be related to running out of memory; the only thing I've done
to it in the past week is to start running Java on it. OTOH, the machine
does have 512MB of RAM and a further 1GB of swapfile.
This is kind of a big deal, as it's a server connected to the outside
world and runs my website and email! So, can anyone suggest:
(a) why it's failing, and whether there's a fix;
(b) where I can get a network watchdog that will automatically reboot
the box if the networking fails. Because if this happens while I'm out,
I'm not going to be able to reboot it manually...
Would any more technical information be useful?
Stack trace (sorry about the bad formatting):
Jul 28 21:31:31 chur kernel: [215085.000000] ------------[ cut here
]------------
Jul 28 21:31:31 chur kernel: [215085.000000] WARNING: at
/home/tbm/kernel/linux-2.6-2.6.30~rc8/debian/build/source_armel_none/net/sched/sch_generic.c:226
dev_watchdog+0x150/0x240()
Jul 28 21:31:31 chur kernel: [215085.010000] NETDEV WATCHDOG: eth1
(rtl8150): transmit timed out
Jul 28 21:31:31 chur kernel: [215085.020000] Modules linked in: xt_state
ipv6 ipt_MASQUERADE ipt_REDIRECT xt_tcpudp iptable_nat nf_nat
nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables
x_tables reiserfs loop gpio_keys mmc_block rtl8150 mvsdio mv643xx_eth
libphy mmc_core jfs nls_base raid0 md_mod sd_mod crc_t10dif ehci_hcd
usb_storage usbcore scsi_mod ext3 jbd ext2 mbcache
Jul 28 21:31:31 chur kernel: [215085.050000] [<c002bcec>]
(unwind_backtrace+0x0/0xd4) from [<c003e664>]
(warn_slowpath_common+0x4c/0x68)
Jul 28 21:31:31 chur kernel: [215085.060000] [<c003e664>]
(warn_slowpath_common+0x4c/0x68) from [<c003e6bc>]
(warn_slowpath_fmt+0x28/0x38)
Jul 28 21:31:31 chur kernel: [215085.070000] [<c003e6bc>]
(warn_slowpath_fmt+0x28/0x38) from [<c021e60c>] (dev_watchdog+0x150/0x240)
Jul 28 21:31:31 chur kernel: [215085.080000] [<c021e60c>]
(dev_watchdog+0x150/0x240) from [<c0047878>] (run_timer_softirq+0x170/0x204)
Jul 28 21:31:31 chur kernel: [215085.090000] [<c0047878>]
(run_timer_softirq+0x170/0x204) from [<c0043538>] (__do_softirq+0x98/0x160)
Jul 28 21:31:31 chur kernel: [215085.100000] [<c0043538>]
(__do_softirq+0x98/0x160) from [<c004381c>] (irq_exit+0x40/0x90)
Jul 28 21:31:31 chur kernel: [215085.110000] [<c004381c>]
(irq_exit+0x40/0x90) from [<c0025054>] (_text+0x54/0x6c)
Jul 28 21:31:31 chur kernel: [215085.120000] [<c0025054>]
(_text+0x54/0x6c) from [<c00259b4>] (__irq_svc+0x34/0x80)
Jul 28 21:31:31 chur kernel: [215085.120000] Exception stack(0xc0369f40
to 0xc0369f88)
Jul 28 21:31:31 chur kernel: [215085.130000] 9f40: 000bbff6 000003e8
00000000 4a6f6023 c036dd28 c036dd28 c0022ee8 c036bde8
Jul 28 21:31:31 chur kernel: [215085.140000] 9f60: c036dd28 56251311
c03edc00 00000000 2de5d9ce c0369f88 c0059e54 c002fb9c
Jul 28 21:31:31 chur kernel: [215085.150000] 9f80: 20000013 ffffffff
Jul 28 21:31:31 chur kernel: [215085.150000] [<c00259b4>]
(__irq_svc+0x34/0x80) from [<c0059e54>] (do_gettimeofday+0x28/0x34)
Jul 28 21:31:31 chur kernel: [215085.160000] [<c0059e54>]
(do_gettimeofday+0x28/0x34) from [<000b76e8>] (0xb76e8)
Jul 28 21:31:31 chur kernel: [215085.170000] ---[ end trace
d75f9ad0583752ea ]---
Jul 28 21:31:31 chur kernel: [215085.170000] net eth1: Tx timeout.
Jul 28 21:31:31 chur kernel: [215085.180000] usb 1-1.4: eth1: Tx status -104
Jul 28 21:31:33 chur kernel: [215087.000000] net eth1: Tx timeout.
Jul 28 21:31:33 chur kernel: [215087.000000] usb 1-1.4: eth1: Tx status -104
[...repeated every two seconds until reboot...]
- --
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "People who think they know everything really annoy those of us who
│ know we don't." --- Bjarne Stroustrup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKb2mTf9E0noFvlzgRAuLCAJ0WkzFHNef33Y7n/C5StteMeE9b2gCgxvyf
YG+mhVK2FCoGMrvOdzjaFnA=
=+OAa
-----END PGP SIGNATURE-----
Reply to: