Bug 5978

Summary: kernel causes SRM to panic on reboot or shutdown
Product: [Retired] Red Hat Linux Reporter: phiber
Component: kernelAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-01-04 22:27:26 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 phiber 1999-10-15 07:18:24 UTC
I'm running RedHat 6.0 on a PC164 with SRM 5.5-1 firmware.
When I reboot or shutdown, all processes terminate as
normal, and then "reset_for_srm" gets called in the kernel
causing SRM to panic.  I must then hit the reset button.
This is obviously not normal behavior, as it renders
rebooting impossible, especially remotely.
This same machine also has NetBSD on it, with no such
problem; so I know there's nothing wrong with my machine or
firmware.  I've tried both 2.2.5-16 and the 2.2.5-22 update
and both behave the same.  Is there some fix for this?????
Using the ARC firmware is not an option.  The
"reset_for_srm" kernel code is obviously broken.
Please help.

Comment 1 phiber 1999-10-15 22:31:59 UTC
I've fixed the problem!  Or at least, I can work around it.
The problem is with the md (multiple disk) driver.  Apparently one of
its threads is still running when reset_for_srm is called in the
shutdown process, confusing SRM into panicking.  I've disabled the md
driver altogether, since I'm not using any kind of RAID or drive
concatenation.  Now everything works fine.  However, the md driver
SHOULD get fixed, since this behavior is definitely broken.

Comment 2 Cristian Gafton 2000-01-04 22:27:59 UTC
Assigned to dledford

Comment 3 Phil Copeland 2001-06-04 15:17:43 UTC
Delinquent record (old)
Assuming that 6.2/7.0 fixes the problem