| Summary: | Adjusting the idle priority of a process causes panic | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Jos.Backus <Jos.Backus> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
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/ 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/ 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 State Changed From-To: open->closed Duplicate of PR: kern/5641 |
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.