Bug 12758

Summary: Adjusting the idle priority of a process causes panic
Product: Base System Reporter: Jos.Backus <Jos.Backus>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.0-CURRENT   
Hardware: Any   
OS: Any   

Description Jos.Backus 1999-07-22 10:10:01 UTC
	See below.

Fix: 

No idea.
How-To-Repeat: 
	% primes 3 > /dev/null &
	[1] 306
	% primes 3 > /dev/null &
	[2] 307
	% su
	# idprio 31 -306
	# idprio -t -306
	# panic: remrq
	Debugger("panic") at ...
	db> trace
	Debugger(c01dba5b) at Debugger+0x38
	panic(c01c21fe,c012e00b2,c832a8c0,0,c012dfa4) at panic+0x74
	rem1(0,40000000,280ef774,bfbfd940,a) at rem1
	softclock(0,2f,2f,2f,a) at softclock+0xde
	doreti_swi() at doreti_swi+0xf

	Apparently this only happens when the CPU load is above normal, hence
	two instances of the primes program had to be started.
Comment 1 Andy Farkas 2000-06-28 16:52:47 UTC
This PR is comming up to its first year anniversary!

I just tried it on a 4.0-STABLE built Jun 28 2000 and got a "kernel trap
12 with interrupts disabled" followed by two(!) "Fatal trap 12: page fault
while in kernel mode" dumps.  Reproducable.

It triggers when you kill the idprio'd process, which is a bit different
<from the original...

Doubtfully hardware, but my system is a 90MHz P54C with 32MB RAM, 1 ide
disk on MB controller, 1 8-bit 3c503.

On 22 Jul 1999, Jos Backus wrote:

> Date: 22 Jul 1999 08:59:22 -0000
> From: Jos Backus <Jos.Backus@nl.origin-it.com>
> To: FreeBSD-gnats-submit@FreeBSD.ORG
> Subject: kern/12758: idprio-related panic in -stable and -current
[snip] 
> >How-To-Repeat:
> 
> 	% primes 3 > /dev/null &
> 	[1] 306
> 	% primes 3 > /dev/null &
> 	[2] 307
> 	% su
> 	# idprio 31 -306
> 	# idprio -t -306
> 	# panic: remrq
> 	Debugger("panic") at ...
> 	db> trace
> 	Debugger(c01dba5b) at Debugger+0x38
> 	panic(c01c21fe,c012e00b2,c832a8c0,0,c012dfa4) at panic+0x74
> 	rem1(0,40000000,280ef774,bfbfd940,a) at rem1
> 	softclock(0,2f,2f,2f,a) at softclock+0xde
> 	doreti_swi() at doreti_swi+0xf
> 
> 	Apparently this only happens when the CPU load is above normal, hence
> 	two instances of the primes program had to be started.
> 
> >Fix:
> 	
> 	No idea.
> 
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 

--
 
 :{ andyf@speednet.com.au
  
        Andy Farkas
    System Administrator
   Speednet Communications
 http://www.speednet.com.au/
Comment 2 Andy Farkas 2000-06-29 02:45:31 UTC
Richard Seaman, Jr. wrote:

> I'm attaching some patches against 5.0-current, though I think they might
> apply cleanly to a 4.0 system like yours (I don't have a 4.0 system, sorry).

The patches applied cleanly except for conf/files (-stable has v1.340.2.8) 
but the 1 line deletetion was easy to apply manually.

The system no longer panics when doing the test.

> -- 
> Richard Seaman, Jr.        email:    dick@tar.com
> 5182 N. Maple Lane         phone:    262-367-5450
> Nashotah WI 53058            fax:    262-367-5852
> 

--
 
 :{ andyf@speednet.com.au
  
        Andy Farkas
    System Administrator
   Speednet Communications
 http://www.speednet.com.au/
Comment 3 dick 2000-06-29 12:32:24 UTC
On Thu, Jun 29, 2000 at 11:45:31AM +1000, Andy Farkas wrote:

> The patches applied cleanly except for conf/files (-stable has v1.340.2.8) 
> but the 1 line deletetion was easy to apply manually.
> 
> The system no longer panics when doing the test.

Thanks for confirming this.  The patches definately need more work.
At a minimum there's a missing splhigh, and a PRISON_CHECK should
probably be added to rtprio (or dortprio), though there may be other
changes needed too.

-- 
Richard Seaman, Jr.        email:    dick@tar.com
5182 N. Maple Lane         phone:    262-367-5450
Nashotah WI 53058            fax:    262-367-5852
Comment 4 Mike Barcroft freebsd_committer freebsd_triage 2001-07-21 00:51:57 UTC
State Changed
From-To: open->closed


Duplicate of PR: kern/5641