From: Scott Lee <scottlee@redhot.rose.hp.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Debugging hard lockups (hardware?)
Date: Tue, 8 Apr 2003 11:36:44 -0700 (PDT) [thread overview]
Message-ID: <200304081836.LAA26103@redhot.rose.hp.com> (raw)
I too am experiencing hard lockups.
I'm using 2.4.18-rc1-ac2 (2.4.18-18.7.x) on multiple units with fairly uniform HW. (HW differences being PGA vs BGA processor and RAM/HD size.) Because of the stage of software development I'm not really able roll the kernel. It seems unlikely that it is bad hardware because it is happening on multiple units and those same units are rock solid if running older (2.0 kernel) based firmware.
Unfortunately I'm on a National GX1 processor so I don't have NMI capability. The lockups are very sporatic and can not be reproduced at will. Additionally most of the units are headless which complicates matters. I've looked at the state of SUSPA# on a locked up box and it is not asserted which indicates that the CPU is not halted. I can't be 100% sure but it looks like the only memory activity is refresh related so it seems like the CPU is in a loop that runs out of its puny 16K unified cache.
Since this is an embedded device it is running a fairly stripped kernel. I suppose I can post the config if necessary but it's basically using ide, ext3, and pcnet32. (Yes I know about the ext3 patches but they don't seem to help in my case.)
Also, recently, Jerry Carter (of Samba) has asked me for some help regarding one of his personal systems as he too is seeing hard lockups. He hasn't yet had time to try the nmi_watchdog but I'll prod him some more on this. His system has a SiS 730 chipset with Athlon 200XP+ and Promise IDE ultra 100 controller. He has ATI Rage II PCI video but he has also seen the problem when using the onboard video. As for kernels he is using 2.4.20 and has seen the problem w/ and w/o the ext3 patches and acl patches. Additionally, he reverted his fs to ext2 at one point and still saw the problem. He generally sees the problem when playing back mp3s but it has happened at other times.
Regards,
Scott Lee
next reply other threads:[~2003-04-08 18:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-08 18:36 Scott Lee [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-04-11 18:08 Debugging hard lockups (hardware?) Scott Lee
2003-04-11 19:22 ` Bernd Eckenfels
2003-04-07 23:24 Richard J Moore
2003-04-09 1:24 ` Nick Urbanik
2003-04-06 10:12 mikpe
2003-04-06 16:01 ` Nick Urbanik
2003-04-06 6:32 Nick Urbanik
2003-04-06 6:39 ` Nick Urbanik
2003-04-06 9:27 ` John Bradford
2003-04-06 10:55 ` Bruce Harada
2003-04-06 18:34 ` Alan Cox
2003-04-06 20:29 ` Arador
2003-04-06 21:04 ` Alan Cox
2003-04-17 16:12 ` Arador
2003-04-06 20:31 ` Dave Jones
2003-04-06 22:02 ` Nick Urbanik
2003-04-06 23:15 ` Dave Jones
2003-04-08 3:33 ` Andre Hedrick
2003-04-08 12:35 ` Dave Jones
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=200304081836.LAA26103@redhot.rose.hp.com \
--to=scottlee@redhot.rose.hp.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox