Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161856 - alt-sysrq-b may cause system to panic
Summary: alt-sysrq-b may cause system to panic
Keywords:
Status: CLOSED DUPLICATE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Dave Anderson
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-27 21:13 UTC by David Milburn
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-07-08 15:45:19 UTC


Attachments (Terms of Use)
Patch to fix alt-sysrq-b panic (deleted)
2005-06-27 21:15 UTC, David Milburn
no flags Details | Diff

Description David Milburn 2005-06-27 21:13:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2

Description of problem:
On RHEL4, x86_64 system, sometimes alt-sysrq-b causes the system to panic:

SysRq : Resetting
Debug: sleeping function called from invalid context at kernel/sched.c:2925
in_atomic():1[expected: 0], irqs_disabled():1

Call Trace:<IRQ> <ffffffff80130697>{__might_sleep+173} <ffffffff802f7c9b>{wait_
      <ffffffff80130201>{try_to_wake_up+734} <ffffffff80131f76>{set_cpus_allow
      <ffffffff8011719b>{machine_shutdown+43} <ffffffff801171e5>{machine_resta
      <ffffffff80229bd8>{__handle_sysrq+102} <ffffffff80223f44>{kbd_event+173}
      <ffffffff80285b87>{input_event+867} <ffffffff80288a72>{atkbd_report_key+
      <ffffffff80288f73>{atkbd_interrupt+1252} <ffffffff802307f4>{serio_interr
      <ffffffff80230ca3>{i8042_interrupt+354} <ffffffff80112ade>{handle_IRQ_ev
      <ffffffff80112d58>{do_IRQ+197} <ffffffff8011059b>{ret_from_intr+0}
       <EOI> <ffffffff8010e6cc>{mwait_idle+86} <ffffffff8010e65c>{cpu_idle+26}

bad: scheduling while atomic!

Call Trace:<IRQ> <ffffffff802f706b>{schedule+73} <ffffffff8011059b>{ret_from_in
      <ffffffff802f7d21>{wait_for_completion+167} <ffffffff80131766>{default_w
      <ffffffff80131766>{default_wake_function+0} <ffffffff80131f76>{set_cpus_
      <ffffffff8011719b>{machine_shutdown+43} <ffffffff801171e5>{machine_resta
      <ffffffff80229bd8>{__handle_sysrq+102} <ffffffff80223f44>{kbd_event+173}
      <ffffffff80285b87>{input_event+867} <ffffffff80288a72>{atkbd_report_key+
      <ffffffff80288f73>{atkbd_interrupt+1252} <ffffffff802307f4>{serio_interr
      <ffffffff80230ca3>{i8042_interrupt+354} <ffffffff80112ade>{handle_IRQ_ev
      <ffffffff80112d58>{do_IRQ+197} <ffffffff8011059b>{ret_from_intr+0}
       <EOI> <ffffffff8010e6cc>{mwait_idle+86} <ffffffff8010e65c>{cpu_idle+26}

bad: scheduling from the idle thread!

Call Trace:<IRQ> <ffffffff802f70c2>{schedule+160} <ffffffff8011059b>{ret_from_i
      <ffffffff802f7d21>{wait_for_completion+167} <ffffffff80131766>{default_w
      <ffffffff80131766>{default_wake_function+0} <ffffffff80131f76>{set_cpus_
      <ffffffff8011719b>{machine_shutdown+43} <ffffffff801171e5>{machine_resta
      <ffffffff80229bd8>{__handle_sysrq+102} <ffffffff80223f44>{kbd_event+173}
      <ffffffff80285b87>{input_event+867} <ffffffff80288a72>{atkbd_report_key+
      <ffffffff80288f73>{atkbd_interrupt+1252} <ffffffff802307f4>{serio_interr
      <ffffffff80230ca3>{i8042_interrupt+354} <ffffffff80112ade>{handle_IRQ_ev
      <ffffffff80112d58>{do_IRQ+197} <ffffffff8011059b>{ret_from_intr+0}
       <EOI> <ffffffff8010e6cc>{mwait_idle+86} <ffffffff8010e65c>{cpu_idle+26}

Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
<ffffffff8012faa6>{dequeue_task+4}

It came from

void __might_sleep(char *file, int line, int atomic_depth)
{
#if defined(in_atomic)
       static unsigned long prev_jiffy;        /* ratelimiting */

#ifndef CONFIG_PREEMPT
       atomic_depth = 0;
#endif
       if (((in_atomic() != atomic_depth) || irqs_disabled()) &&
           system_state == SYSTEM_RUNNING) {
               if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
                       return;
               prev_jiffy = jiffies;
               printk(KERN_ERR "Debug: sleeping function called from invalid"
                              " context at %s:%d\n", file, line);
               printk("in_atomic():%d[expected: %d], irqs_disabled():%d\n",
                       in_atomic(), atomic_depth, irqs_disabled());           
    dump_stack();
       }
#endif
}

The problem is sysrq_handle_reboot didn't set system_state to SYSTEM_RESTART.


Version-Release number of selected component (if applicable):
kernel-2.6.9-5.EL

How reproducible:
Sometimes

Steps to Reproduce:
1. alt-sysrq-b
2.
3.
  

Actual Results:  System crashes.

Expected Results:  System should reboot.

Additional info:

Attaching a patch for review that customer supplied to fix the problem.

Comment 1 David Milburn 2005-06-27 21:15:00 UTC
Created attachment 116032 [details]
Patch to fix alt-sysrq-b panic

Comment 5 Dave Anderson 2005-07-08 15:36:22 UTC

Ah -- I see what you mean here re: patch application, Dave.

The current sysrq_handle_reboot() has been changed to only
perform in process context, as a result of BZ #140792
(RHEL4 U1: Alt+SysRq+B kernel panics EM64T systems),
so the problem seen here would not occur.

So I believe that this BZ is a duplicate of that one
and should be closed.




Note You need to log in before you can comment on or make changes to this bug.