lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <18408.36288.352280.87141@notabene.brown>
Date:	Tue, 25 Mar 2008 16:29:36 +1100
From:	Neil Brown <neilb@...e.de>
To:	"Andrew Paprocki" <andrew@...iboo.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.24.3 kernel panic in md raid1d queue_delayed_work_on

On Sunday March 16, andrew@...iboo.com wrote:
> I had an embedded machine hang last night with a kernel panic in
> queue_delayed_work_on. I couldn't scroll back the terminal to get more
> of the trace, but I jotted down what I could see on the screen. This
> is a Geode LX system running a SATA RAID1 array as md0 on a SiI 3114
> controller using libata. Any ideas? If the .config or boot log from
> this machine would be useful, let me know and I'll get them.

I'm afraid there isn't much here to base any guesses on.

> 
> Thanks,
> -Andrew
> 
> ----- top of scrollback
> handle_IRQ_event+0x1a/0x3f
> handle_level_irq+0x4f/0x84
> do_IRQ+0x53/0x6b
> common_interrupt+0x23/0x28
> __make_request+0x480/0x48a
> generic_make_request+0x1fd/0x22a
> common_interrupt+0x23/0x28
> __generic_unplug_device+0x14/0x1f
> generic_unplug_device+0x6/0x8
> blk_remove_plug+0x4e/0x5a

blk_remove_plug is always called with interrupts disabled.  So why
there are "do_IRQ" and similar calls further up the stack is
surprising.
However the list of function names is only indicative, not
definitive.... 

> raid1d+0xc3/0xc35
> irq_exit+0x40/0x58
> do_IRQ+0x58/0x6b
> update_curr+0x52/0xc4
> schedule+0x1f3/0x20d
> schedule_timeout+0x13/0x97
> sys_capget+0x54/0xcb
> md_thread+0xb5/0xcb
> autoremove_wake_function+0x0/0x35
> md_thread+0x0/0xcb
> kthread+0x36/0x5c
> kthread+0x0/0x5c
> kernel_thread_helper+0x7/0x10
> 
> Code: 8d 50 10 e9 48 ff ff ff 31 d2 e9 41 ff ff ff 57 89 c7 56 89 d6
> 53 8d 59 3(clipped)
>  0f ba 29 00 19 c0 31 d2 85 c0 75 61 83 79 10 00 74 04 <0f> 0b eb fe
                                                          ^^^^^^

This shows that it died on a "BUG" or "BUG_ON" call.  Did you see the
text of that?

Why do you say there was "a kernel panic in queue_delayed_work_on".
What exactly provided that information?

NeilBrown


> 8d 41 04 3(clipped)
>  41 04 74 04 0f 0b eb fe 8b 01 8b 16 a8
> EIP: [<c022609a>] queue_delayed_work_on+0x1c/0x7d SS:ESP 0068:cf359d80
> Kernel panic - not syncing: Fatal exception in interrupt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ