Greetings. I've been experimenting with bridging an ethernet device
with an ethertap device (using the Linux tun/tap driver). This is
running with the bridge code in the Linux kernel version 2.4.20 as
provided by Red Hat (2.4.20-18.9). I also seem to have seen the problem
with 2.4.21 from the Red Hat beta kernel. I'm going to try a generic
kernel as soon as I can get the remote machine rebooted.
What I've done is set up the tap device using the OpenVPN software to
another machine, and then want to bridge eth1 to that tap device, with
transport for it happening over eth0.
Things all seem to work fine for some small period of time, but at some
point it will cause the kernel to Oops (oops output provided below).
The Oops doesn't seem to be load-related. I was able to download a
couple copies of the Linux kernel over it without any problems, then
when I tried setting up policy routing, it oopsed.
I'm probably going to just switch to a routed network instead of using
the bridge, but I wanted to pass this information on in case it helped
make the bridging more stable. I have a test setup which I can try
reproducing this problem on if it helps. I'd love to dig into the
kernel code, but I don't have the time right now.
I've dug through the mailing list arcives and looked for more up-to-date
bridge code, but haven't found anything obvious for either of those.
Thanks,
Sean
========================
Call Trace: [<c01f1ffb>] dev_queue_xmit [kernel] 0x26b (0xc0349e60))
[<c819ef6b>] __dev_queue_push_xmit [bridge] 0x2b (0xc0349e78))
[<c819efab>] __br_forward_finish [bridge] 0x1b (0xc0349e8c))
[<c819f1ce>] br_flood [bridge] 0x7e (0xc0349ea8))
[<c819f050>] __br_forward [bridge] 0x0 (0xc0349eb4))
[<c819f287>] br_flood_forward [bridge] 0x27 (0xc0349ec8))
[<c819f050>] __br_forward [bridge] 0x0 (0xc0349ed8))
[<c819fc7f>] br_handle_frame_finish [bridge] 0xff (0xc0349edc))
[<c01f246a>] netif_receive_skb [kernel] 0xba (0xc0349efc))
[<c01f261d>] process_backlog [kernel] 0x6d (0xc0349f1c))
[<c01f272a>] net_rx_action [kernel] 0x6a (0xc0349f34))
[<c0121014>] do_softirq [kernel] 0x94 (0xc0349f50))
[<c010aa8f>] do_IRQ [kernel] 0xaf (0xc0349f68))
[<c010d498>] call_do_IRQ [kernel] 0x5 (0xc0349f88))
[<c0106ec3>] default_idle [kernel] 0x23 (0xc0349fb4))
[<c011564f>] apm_cpu_idle [kernel] 0x9f (0xc0349fc0))
[<c01155b0>] apm_cpu_idle [kernel] 0x0 (0xc0349fc4))
[<c0106f35>] cpu_idle [kernel] 0x35 (0xc0349fd4))
[<c0105000>] stext [kernel] 0x0 (0xc0349fe0))
Code: 0f 0b df 03 f2 ba 25 c0 89 c0 c1 e1 10 25 00 00 ff ff 01 c8
<0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
--
If you don't learn from a mistake you make, you've made two mistakes.
-- Sean Reifschneider, 2002
Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]>
tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin
_______________________________________________
Bridge mailing list
[EMAIL PROTECTED]
http://www.math.leidenuniv.nl/mailman/listinfo/bridge
