EFLAGS: 00010202
EIP is at _stext+0x3feffd68/0x28
Stack:
rcu_do_batch+0x1f/0x70
rcu_process_callbacks+0x5d/0x70
tasklet_action+0x73/0xd0
__do_softirq+0xc5/0xe0
do_softirq+0x32/0x40
irq_exit+0x3e/0x40
do_IRQ+0x1e/0x30
common_interrupt+0x1a/0x20
acpi_processor_idle+0x129/0x2b4
cpu_idle+0x67/0x70
start_kernel+0x161/0x180
unknown_bootoption+0x0/0x1b0
Both times it happened, the stack trace was pretty much the same. If I instead only specify one nexthop, then I don't get this kernel panic.
for x in $(seq 1 254); do for y in $(seq 1 254); do for z in $(seq 1 254); do ip r g 1.$x.$y.$z; done; done; done
If I run that, with 2 nexthop's, it kernel panics fairly quickly, after 500-1000 iterations roughly? With only 1 nexthop specified it had gone up to roughly 4000 iterations and beyond with no kernel panic. Possibly the patches aren't compatible with other patches the gentoo kernel has applied... going to research what I can on that.
- Jody
On 1/18/06, Jody Shumaker <jody.shumaker@xxxxxxxxx> wrote:
- JodyDo you have script to ping/arping the gateways on eth device(s)?
The NOARP devices are always preferred if the GWs on ARP devices are
not marked reachable in ARP cache.
Yes, I have a script that pings the gateways on both devices every minute. I also just checked with `arp -an` and the gateway for the eth1 device is listed. Also, if I swap the order of the nexthop's then I can have it favor the eth1 over ppp0 always.
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc