Re: test9, complete lockup, ipchains related

Re: test9, complete lockup, ipchains related

[Éric Brunet]

Hello all,

This is a repost of a message I sent yesterday to linux-kernel. I
understand I should have sent it there right away. Please note, that
another instance of (probably) the same problem on an ia64 platform has
also been reported by David Mosberger on linux-kernel, and he has a
better trace than I do. Please see
<http://marc.theaimsgroup.com/?l=linux-kernel&m=106730476106084&w=2> 
and  <http://tinyurl.com/sm9d> for his report.

Please, Cc me any answer.

Thanks,

	Éric Brunet

On Mon, Oct 27, 2003 at 09:52:35PM +0100, Éric Brunet wrote:
> I have the following setup on my PIV computer, shuttle motherboard,
> 2.6.0-test9 kernel:
> 
> eth1 is a RTL-8029 and connects me to the outside world
> eth0 is a RT8139 and is where I plug my laptop.
> 
> Using ipchains, I masqerade the laptop, so that it can also access the
> outside world.
> 
> The problem is that my computer locks up when I try to do a big backup
> with rsync over ssh from the laptop to a computer in the outside world.
> No mouse, no keyboard, nothing in the logs.
> 
> I couldn't reproduce it with some scp from the laptop to a computer over
> the outside world. I don't know what is so special with rsync.
> 
> I couldn't reproduce it with a rsync from the laptop to my computer. That
> is why I think it is ipchains related.
> 
> Everything is working fine with kernels -test1 and -test4. The lockup is
> already present in -test8 and, I think, -test7 (need to check that).
> 
> Once I constated the problem with a complete boot (X11, kde, many
> services), I have reproduced them in booting in single user mode, with no
> more operations than ifup'ing eth0, eth1, loading ipchains and setting
> the one single rule (masqerading) I need.
> 
> ONCE, I got some kernel trace spit out on the console before the computer
> locked. Unfortunately, I only got the 24 last lines. I tried to obtain
> another trace in a 80x60 vga mode, but failed. Here is the trace, hand
> copied:
> 
> 	ip_rcv_finish +0x1c5/0x22c
> 	ip_rcv_finish +0x0/0x22c
> 	nf_hook_slow +0xd4/0x122
> 	ip_rcv_finish +0x0/0x22c
> 	ip_rcv +0x3c5/0x480
> 	ip_rcv_finish +0x0/0x22c
> 	netif_receive_skb +0x12b/0x164
> 	process_backlog +0x6e/0xfd
> 	net_rx_action +0x6a/0xe4
> 	do_softirq +0x95/0x97
> 	do_IRQ +0xca/0xe5
> 	default_idle +0x0/0x27
> 	rest_init +0x0/0x27
> 	common_interrupt +0x18/0x20
> 	default_idle +0x0/0x27
> 	rest_init +0x0/0x27
> 	default_idle +0x24/0x27
> 	cpu_idle +0x2e/0x37
> 	start_kernel +0x163/0x191
> 	unknown_bootoption +0x0/0xff
> Code 8b 53 08 0f b7 47 0e 31 f6 66 39 42 1e 74 1f 85 f6 75 07 a1
> 	Kernel panic: Fatal exception in interrupt
> 	In interrupt handler - not syncing
> 
> .config, dmesg, lspci, etc. available on
> http://perso.nerim.net/~tudia/bug-reports
> 
> 
> Regards,
> 
> 	Éric Brunet