Re: 2.4.4 kernel freeze

Re: 2.4.4 kernel freeze

[Stephan Brauss]

> Any other hints are welcome (other than the noapic, which didn't help).
My system is always completely dead as soon as I start a larger (interrupt
driven?) data transfer to/from any (? I tested with two different NICs and a Promise
Ultra100) PCI card in slot 4 or 5. And it seems that it really only occurs 
in slots 4 and 5... To get rid of it, I switched to 2.2.19.

Re: 2.4.4 kernel freeze

[Jens Gecius]

	Stephan Brauss <sbrauss@bluewin.ch> writes:

> > Any other hints are welcome (other than the noapic, which didn't help).

> My system is always completely dead as soon as I start a larger (interrupt
> driven?) data transfer to/from any (? I tested with two different NICs and a Promise
> Ultra100) PCI card in slot 4 or 5. And it seems that it really only occurs 
> in slots 4 and 5... To get rid of it, I switched to 2.2.19.

I couldn't. Problems getting devfsd patched in 2.2.19 :-( - and I'm
going on vacation in shortly...

Now after the last couple of "lost interrupts" I set a debian-stable
as my primary firewall/router box in front of my server - this way I
got rid of the second nic and freed both slot 4 and 5. Unfortunately,
after a couple hours running my box again lost irq :-(.

And there's no obvious huge transfer going on. The boxes were just
alone. Now I try again noapic (different setup). Hope that
works. Otherwise I'm kind of lost...

-- 
Tschoe,                    Get my gpg-public-key here
 Jens                     http://gecius.de/gpg-key.txt

Re: 2.4.4 kernel freeze

[Jens Gecius]

	Jens Gecius <jens@gecius.de> writes:

> > > what do you mean by freeze?  in theory, the fact that the irq
> > I cannot ping the machine anymore, no Ooops, no kernel messages, the
> > attached screen is freezed (which implies that no more interrupts
> > are handled, right?)
> 
> Excuse me hopping in.
> 
> I have that situation here, too. Screen frozen, no pings from the
> local network, sysrq doesn't work (keyboard dead).
> 
> maniac kernel: NETDEV WATCHDOG: eth1: transmit timed out
> maniac kernel: eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3,
> t=21.
> 
> All this happened on 2.4.3 and 2.4.4 (don't excactly remember on
> earlier 2.4).
> 
> I followed your suggestion regarding PCI-slots. Both my nics used to
> use PCI 4 and 5 (on a gigabyte vxd7, dual 1GHz). Only the one in slot
> 4 had the problems. I switched the card to slot 1 and will monitor the
> situation. I'll mail the list in case it doesn't change my situation.

OK - now it even got worse. After just a couple hours slot5 was dead
(that was the one working just fine with the other card in
slot4). Three minutes later slot1 was dead, too. Both cards share
irq12.

Fortunately, the box wasn't frozen this time. X was up and running
fine and I was able to reboot in a sound manner.

I'll try another change in slots, but unfortunately, my nics are the
ones with the lowest traffic: one other is SCSI, the other one
firewire... (even though the latter one is hardly used).
 
> Any other hints are welcome (other than the noapic, which didn't help).

I have to reiterate this one. Any hints are very welcome.

-- 
Tschoe,                    Get my gpg-public-key here
 Jens                     http://gecius.de/gpg-key.txt

Re: 2.4.4 kernel freeze

[Jens Gecius]

	Stephan Brauss <sbrauss@bluewin.ch> writes:

> > what do you mean by freeze?  in theory, the fact that the irq
> I cannot ping the machine anymore, no Ooops, no kernel messages, the
> attached screen is freezed (which implies that no more interrupts
> are handled, right?)

Excuse me hopping in.

I have that situation here, too. Screen frozen, no pings from the
local network, sysrq doesn't work (keyboard dead).

BUT: the other interface (internet) works just fine. When I look
in the logs afterwards, I find everything worked fine except the
following:

maniac kernel: NETDEV WATCHDOG: eth1: transmit timed out
maniac kernel: eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3,
t=21.

Basically, the nic for my local lan is gone. And due to the fact, that
the box is unsuable for me (don't have another internet connection to
log in *that* remote), I have to reboot hard. Thank god there's
reiserfs ;-).

All this happened on 2.4.3 and 2.4.4 (don't excactly remember on
earlier 2.4).

I followed your suggestion regarding PCI-slots. Both my nics used to
use PCI 4 and 5 (on a gigabyte vxd7, dual 1GHz). Only the one in slot
4 had the problems. I switched the card to slot 1 and will monitor the
situation. I'll mail the list in case it doesn't change my situation.

Any other hints are welcome (other than the noapic, which didn't help).

-- 
Tschoe,                    Get my gpg-public-key here
 Jens                     http://gecius.de/gpg-key.txt

Re: 2.4.4 kernel freeze

[Stephan Brauss]

Hello,

> what do you mean by freeze?  in theory, the fact that the irq
I cannot ping the machine anymore, no Ooops, no kernel messages, the
attached screen is freezed (which implies that no more interrupts
are handled, right?)

> for those slots is shared with arbitrary onboard peripherals
> shouldn't matter, since PCI devices can all share irq's.
Yes... And it is not the problem, as I make use of interrupt 
sharing on the first three slots.

> I guess it would be valuable to compare the boot messages
>From 2.2.19 and 2.4.4?

> under these conditions, since a real freeze implies that the 
> kernel is adjusting irq routing incorrectly...
Yes, one could think. But I checked that interrupt handling basically
works for slots 4+5 with "cat /proc/interrupts". As soon as
I start a larger ftp data transfer over an ethernet adapter in
one of these slots the problem occurs.

2.4.4 kernel freeze

[Stephan Brauss]

Hello,

I have an ASUS A7V133 (VIA VT8363A) with 5 PCI slots
and I installed kernel 2.4.4.
All runs fine when I only use PCI slots 1 to 3.
When I use slots 4 or 5, the system
freezes when data is passed to a device in one of
these slots. I tested with a Promise Ultra100, an Intel
Etherexpress Pro 100, and a DEC EtherWorks.
The problem does not turn up in 2.4.0 and 2.2.18 (standard
kernels from SuSE 7.1). I reproduced the error in a second
simillar system with the same motherboard.

Maybe this information is usefull...
If someone wants to know more details, please email me
directly as I'm currently not subscribed to this list.

Stephan