Linux-kernel mailing list archive 1999-20,: Re: Silent freezes with kernels through 2.2.9. No Oops. - Same here

# Re: Silent freezes with kernels through 2.2.9. No Oops. - Same here

Jelle Foks (jelle@flying.demon.nl)
Sun, 16 May 1999 16:29:36 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andrew Tridgell: "emulating netbench"
- Previous message: Manfred Spraul: "Re: [PATCH][2.3.0] Read-write locks instead semaphores on UTS structures"

Hi Mark,

We also experience silent freezes problems here on SMP. 2.2.7 has no
problems (or at least much less), and 2.2.8 and 2.2.9 crash regularly
(often after a few minutes) while running bonnie filesystem tests (bonnie
-s 2000) and/or while doing parallel kernel compiles. For now, we've
rolled back to 2.2.7.

Our freezes don't show the eth0 message though. Our configuration is a
dual system (2x450Mhz) with 4 UDMA disks on Promise/33 controllers in
software raid0, 128MB DIMM, dec21143 (tulip) 10/100MB nic, i740 8MB/AGP
video. Software configuration is a pristine RedHat 6.0 'install
everything'.

The freezes are complete; no more num/capslock, no more magic sysrq, no
more ping responses, no more screen updates. We've tried running without
update/bdflush, which changed the frequency of the crashes, but the
freezes still remain.

Maybe, did you try Dimitris' patch of May 14? It fixes 2 races in the
scheduler, so it could be the one (I'll try as soon as I have access to
the machine again).

Cya,

Jelle.

On Fri, 14 May 1999, Mark Hanson wrote:

> If anyone has any ideas on this one, please mail me.
>
> Thanks,
> Mark
>
> [1.] One line summary of the problem:
>
> Silent freezes with kernels through 2.2.9. No Oops.
>
> [2.] Full description of the problem/report:
>
> We have been experiencing periodic freezes on an SMP machine using
> several versions of the kernel back to 2.0.36. Started using 2.2.0
> when it became available, but the freezes continue. There is no Oops
> output and usually no response from the machine. I was hoping that the
> recent interrupt/network card fix in 2.2.8 would be the trick (even
> though we have a different network card), but we just had another crash
> with 2.2.9. Seems to happen during builds (lots of file system
> activity), but we build all the time and the freezes only once in a
> while. Maximum uptimes are in the range of 20 days.
>
> A few seconds after this crash, an error message popped up on the screen.
> It said:
>
> eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
>
> I have not seen any output after a crash with previous kernels.
>
> I tried to sync the disks with Alt-SysRq-s, but never got the "OK" or
> "Done" messages.
>
> Our network card reports:
> 3c59x.c:v0.99H 11/17/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/
> vortex.html
> eth0: 3Com 3c905B Cyclone 100baseTx at 0xe880, 00:10:4b:75:c9:f4, IRQ 10
> 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
> MII transceiver found at address 24, status 786d.
> MII transceiver found at address 0, status 786d.
> Enabling bus-master transmits and whole-frame receives.
>
> [3.] Keywords (i.e., modules, networking, kernel):
>
> kernel, freeze, no oops
>
> [4.] Kernel version (from /proc/version):
>
> Linux version 2.2.9 (root@mercury) (gcc version 2.7.2.3) #1 SMP Fri May 14 06:58:26 PDT 1999
>
> [5.] Output of Oops.. message (if applicable) with symbolic information
> resolved (see Documentation/oops-tracing.txt)
>
> Not available.
>
> [6.] A small shell script or example program which triggers the
> problem (if possible)
>
> Not available.
>
> [7.] Environment
>
> [7.1.] Software (add the output of the ver_linux script here)
>
> Linux mercury 2.2.9 #1 SMP Fri May 14 06:58:26 PDT 1999 i686 unknown
> Kernel modules 2.1.121
> Gnu C 2.7.2.3
> Binutils 2.9.1.0.15
> Linux C Library 2.0.7
> Dynamic linker ldd (GNU libc) 2.0.7
> Linux C++ Library 2.8.0
> Procps 1.2.9
> Mount 2.9
> Net-tools 1.50
> Kbd 0.96
> Sh-utils 1.16
> cat: /proc/modules: No such file or directory
> Modules Loaded
>
> [7.2.] Processor information (from /proc/cpuinfo):
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 5
> model name : Pentium II (Deschutes)
> stepping : 0
> cpu MHz : 331.927246
> cache size : 512 KB
> fdiv_bug : no
> hlt_bug : no
> sep_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx osfxsr
> bogomips : 330.96
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 5
> model name : Pentium II (Deschutes)
> stepping : 0
> cpu MHz : 331.927246
> cache size : 512 KB
> fdiv_bug : no
> hlt_bug : no
> sep_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx osfxsr
> bogomips : 331.78
>
> [7.3.] Module information (from /proc/modules):
>
> Modules not enabled in kernel.
>
> [7.4.] SCSI information (from /proc/scsi/scsi)
>
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SEAGATE Model: ST19101W Rev: 0014
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
> Vendor: SEAGATE Model: ST19101W Rev: 0014
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 02 Lun: 00
> Vendor: PLEXTOR Model: CD-ROM PX-32TS Rev: 1.01
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 04 Lun: 00
> Vendor: SONY Model: SDT-9000 Rev: 0200
> Type: Sequential-Access ANSI SCSI revision: 02
>
> [7.5.] Other information that might be relevant to the problem
> (please look in /proc and include all information that you
> think to be relevant):
>
> Other than the network card, I can't think of anything. Let me know
> if you want to know something specific.
>
> [X.] Other notes, patches, fixes, workarounds:
>
> None.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Andrew Tridgell: "emulating netbench"
- Previous message: Manfred Spraul: "Re: [PATCH][2.3.0] Read-write locks instead semaphores on UTS structures"