Bug 10018

Summary:	General unreliability and kernel panics on Ultra2 Creator system
Product:	[Retired] Red Hat Linux	Reporter:	Adam Keys <adam>
Component:	kernel	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.1	CC:	alan
Target Milestone:	---
Target Release:	---
Hardware:	sparc
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-09-16 21:20:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Keys 2000-03-06 23:16:38 UTC

Hardware:
Sun Ultra2 Creator
300 Mhz UltraSparc
384 MB RAM
Creator videocard
2 4 gig SCSI drives
hardware raid5 controller?
128 mb swap

The installation process goes smoothly enough.  I am using the default
GNOME workstation setup, enabling RAID0 and a network card.  I have not
yet experienced a crash during setup.  Once the setup is complete, the
machine reboots.  The machine lasts for anywhere between 1-30 minutes
after this reboot.  Several times I have gotten a kernel panic.  Programs
such as linuxconf and PAM have segfaulted, even less(1) or ping(1).

The kernel panic error looks like this:
Unable to handle kernel NULL pointer dereference
tsk->mm->context = <zeros>
tsk->mm->pgd = ffff8000000ec00
<smiley face>
swapper(0): Oops
TSTATE: <registers>
Aieee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In swapper task - not syncing

The kernel is the default for Redhat 6.1 (2.2.12-something I beleive).

Good luck,
Adam Keys

Comment 1 Alan Cox 2000-08-22 18:49:21 UTC

Does this still occur with the 6.2 kernels ?

Comment 2 Alan Cox 2000-09-16 21:20:37 UTC

No reply, so hopefully not. If so - reopen this

Comment 3 Adam Keys 2000-09-18 13:20:33 UTC

As it turns out, the machine has two ethernet interfaces.  The first (eth0) is
built part of the SCSI controller.  It is a Sunlance, and this is the kernel
output:

sunlance.c:v1.12 11/Mar/99 Miguel de Icaza (miguel.mx)
eth0: LANCE 08:00:20:8a:3d:31

Using the other ethernet interface (eth1) has been rock solid however.  I can't
find the output in /var/log/dmesg, but I know the sucker is there.

I have not had a chance to test this with the newer kernel.