On Tue, Apr 24, 2007 at 10:38:32AM -0400, Gene Heskett wrote: > On Tuesday 24 April 2007, Ingo Molnar wrote: > >* David Lang <[EMAIL PROTECTED]> wrote: > >> > (Btw., to protect against such mishaps in the future i have changed > >> > the SysRq-N [SysRq-Nice] implementation in my tree to not only > >> > change real-time tasks to SCHED_OTHER, but to also renice negative > >> > nice levels back to 0 - this will show up in -v6. That way you'd > >> > only have had to hit SysRq-N to get the system out of the wedge.) > >> > >> if you are trying to unwedge a system it may be a good idea to renice > >> all tasks to 0, it could be that a task at +19 is holding a lock that > >> something else is waiting for. > > > >Yeah, that's possible too, but +19 tasks are getting a small but > >guaranteed share of the CPU so eventually it ought to release it. It's > >still a possibility, but i think i'll wait for a specific incident to > >happen first, and then react to that incident :-) > > > > Ingo > > In the instance I created, even the SysRq+b was ignored, and ISTR thats > supposed to initiate a reboot is it not? So it was well and truly wedged.
On many machines I use this on, I have to release Alt while still holding B. Don't know why, but it works like this. Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
