[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#442877: marked as done (forcedeth kernel panic)



Your message dated Fri, 26 Dec 2008 00:52:48 +0100
with message-id <20081225235248.GA3726@galadriel.inutil.org>
and subject line Re: forcedeth kernel panic
has caused the Debian Bug report #442877,
regarding forcedeth kernel panic
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
442877: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442877
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-2.6.22-2-amd64
Version: 2.6.22-4

Freshly built new machine based on ASUS M2N32 WS Pro motherboard with two on-board GBit network adapters driven by the forcedeth driver and running 64bit Etch crashes reliably stock debian kernels 2.6.18 (Etch), 2.6.21 (backports.org) and also 2.6.22 (Sid backported to Etch by apt-get -b source). The crash occurs under high network load generated by tserv from dbench package within about 20 minutes of tserv run against this machine (which is running tserv_srv as it is to be a samba server).

Before it crashes it fills the kernel log with the following messages that may or may not be related to the crash:

Sep 17 14:51:27 harapes kernel: eth0: too many iterations (6) in nv_nic_irq.
Sep 17 14:51:58 harapes last message repeated 1026 times
Sep 17 14:52:59 harapes last message repeated 2063 times
Sep 17 14:54:00 harapes last message repeated 2055 times
Sep 17 14:55:01 harapes last message repeated 2044 times

I wrote it may not be related because I got here an older nForce4 based machine that is running the tserv against the crashing server and it also fills the log with the same messages - but fortunately it does not crash...

The kernel panic looks for 2.6.22-2 as follows (hand-copied from a screenshot made by digital camera) and is fatal - even SysRq doesn't work.

Call Trace:
<IRQ> :forcedeth: nv_nic_irq_optimized+0x89/0x22c
 handle_IRQ_event+0x25/0x53
 __do_softirq+0x55/0xc3
 handle_edge_irq+0xe4/0x127
 do_IRQ+0x6c/0xd5
 default_idle+0x0/0x3d
 ret_from_intr+0x0/0xa
 <EOI> default_idle+0x29/0x3d
 cpu_idle+0x8b/0xae

Code: 8a 83 84 00 00 00 83 e0 f3 83 c8 04 88 83 84 00 00 00 83 7b
RIP :forcedeth:nv_rx_process_optimized+0xe6/0x380
Kernel panic - not syncing: Aiee, killing interrupt handler!

As said this crash is reliable, I managed to kill the machine several times in a row. Though right now I am testing a different setup - the forcedeth driver loaded with "optimization_mode=1" parameter and so far (65 minutes of tserv run) it didn't crash...

Petr



--- End Message ---
--- Begin Message ---
On Fri, Dec 26, 2008 at 12:35:05AM +0100, Petr Stehlik wrote:
> Moritz Muehlenhoff píše v Pá 26. 12. 2008 v 00:21 +0100:
> > On Mon, Sep 17, 2007 at 05:49:04PM +0200, Petr Stehlik wrote:
> > > Package: linux-image-2.6.22-2-amd64
> > > Version: 2.6.22-4
> > >
> > > Freshly built new machine based on ASUS M2N32 WS Pro motherboard with  
> > > two on-board GBit network adapters driven by the forcedeth driver and  
> > > running 64bit Etch crashes reliably stock debian kernels 2.6.18 (Etch),  
> > > 2.6.21 (backports.org) and also 2.6.22 (Sid backported to Etch by  
> 
> > Does this error still occur with more recent kernel versions?
> 
> I don't remember where the machine is now as the bug report is 15 months
> old. It is either running fine under normal load now or we disabled the
> onboard NICs and have been using a PCI GB cards since then. Or it may
> have even died some time ago and we replaced the board with some other
> one.
> 
> Sorry. Too late. You may close this.

Thanks, closing the bug then.

Cheers,
        Moritz


--- End Message ---

Reply to: