All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Hickey <bugfood-ml@fatooh.org>
To: linux-kernel@vger.kernel.org
Subject: Re: 2.6.20.1: reproducible hard lockup (with some configurations)
Date: Sat, 17 Mar 2007 01:04:58 -0700	[thread overview]
Message-ID: <45FBA12A.1000103@fatooh.org> (raw)
In-Reply-To: <45EA3159.4020508@fatooh.org>

Corey Hickey wrote:
> Hello,
> 
> I am experiencing a hard lockup with 2.6.20.1. Whenever the system locks
> up, it locks up hard: nothing is printed to the console and the magic
> SysRQ key has no effect--the only thing I can do is poke the reset
> button. I have reasonable faith in the stability of my hardware: I can
> run memtest86+ for hours without problems; likewise with burnK7,
> mencoder, and various other programs that stress the CPU. I've never had
> this problem (or any similar one) with 2.6.19 and earlier.
> 
> The problem originally manifested whenever I initiated a RAID-5 resync.
> I reported the problem to linux-raid, but Neil Brown wasn't able to
> reproduce it and he suggested I was having trouble with a lower-level
> driver. I've messed around for many hours with many different kernel
> configurations, but all I've been able to find out is that, with some
> configurations, the RAID resync doesn't immediately cause a lockup, but
> a lockup happens later (sometimes hours later) nonetheless. Since the
> late lockup isn't as easily reproducible, I'll concentrate the rest of
> this report on conditions that lead to immediate lockup.
> 
> When the lockup is triggered by a resync, it is very easy to reproduce:
> 1. Boot with 'init=/bin/bash'.
> 2. Run 'mdadm -A /dev/md2 -U resync'.
> 3. Wait about 1 second. The system will lock up.
> 
> System information:
> Athlon64 3400+
> 64-bit Linux 2.6.20.1 compiled with GCC 4.1.2
> 64-bit Debian Sid
> RAID-5 of 5 devices:
>    /dev/hda   (IDE hard drive)
>    /dev/sda6  (partition on SATA hard drive)
>    /dev/sdb   (SATA hard drive)
>    /dev/sdc6  (partition on SATA hard drive)
>    /dev/sdd   (SATA hard drive)
> SATA and IDE drives mounted to onboard nVidia controllers
> I'm using the libata SATA driver and the old IDE driver
> 
> My full kernel .config is here:
> http://fatooh.org/files/tmp/config-2.6.20.1
> ...and the output of 'lspci -v' is here:
> http://fatooh.org/files/tmp/lspci-v
> 
> If anybody has any suggestions, I would be very grateful. I'd also be
> happy to run further tests or provide any other information that may be
> useful.

Just in case this is helpful for somebody:

After I sent the last message, I kept trying to find a solution;
eventually I tried compiling without CONFIG_CC_OPTIMIZE_FOR_SIZE, and
that seems to have fixed the problem. Uptime is 12 days so far, without
any issues.

-Corey

      reply	other threads:[~2007-03-17  8:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-04  2:39 2.6.20.1: reproducible hard lockup (with some configurations) Corey Hickey
2007-03-17  8:04 ` Corey Hickey [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45FBA12A.1000103@fatooh.org \
    --to=bugfood-ml@fatooh.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.