From: Matti Aarnio <matti.aarnio@zmailer.org>
To: linux-kernel@vger.kernel.org
Subject: Bug? 2.4.17-rc1 RAID1, SMP, 750MB+ -> hangups...
Date: Thu, 27 Dec 2001 23:45:42 +0200 [thread overview]
Message-ID: <20011227234542.C1072@mea-ext.zmailer.org> (raw)
I have had problems with 2.4.17-rc1, but also with
2.4.10-ac1, and few others in between.
System with problems:
2.4.17-rc1, 2.4.10
Dual P-III 750 MHz
750 MB (or 1024 MB)
SCSI disks with RAID1 mirroring of all partitions (including swap)
(Had IDE-disks in previous incarnation, same behaviour.)
EXT3
Some 410 000 files in filesystems
(no cmdline parameters)
--> hangups
Systems without (apparently) problems:
2.4.17 (release)
Dual P-II 266 MHz
256 MB
IDE disks with RAID1 mirroring of all partitions (including swap)
(these disks were used at the trouble machine)
EXT3
Some 130 000 files in filesystems
(no cmdline parameters)
--> works
rh2.4.16-0.9custom
Dual P-III 800 MHz
512 MB
IDE disks with RAID1 mirroring of all partitions (including swap)
EXT2
Some 1.2 million files in filesystems
(no cmdline parameters)
--> works
2.4.10
Dual PPro200
128 MB
IDE disks wirth RAID1 mirroring of all partitions (including swap)
EXT2
Some 200 000 files in filesystems
("noapic" -- machine has faulty MP dataset)
--> works
Elsewere talking about the problems, I got a comment that the problem
does appear with largeish memory SMP machines with RAID1 (mirror)
disks, and the problem seem to go away when "noapic" option is used
forcing all IO interrupts to fall into one processor.
As I understood, 2.4.9 does not exhibit this problem, but 2.4.10 thru
2.4.13 do, the commentator returned to 2.4.9 for production systems...
Apparently the problem appears all the way thru to 2.4.17.
The problem appears as complete hungup of the system, when something
is run at 4:00 - 4:20 AM by cron (at a RedHat system: updatedb, and/or
"catman -w", and/or ...)
Machine attached keyboard can not command anything when the hangup
has happened. Configured magic-sysrq doesn't work during hangup.
Problem machine is now being run with: "noapic nosmp nmi_watchdog=1"
which may (or may not) help. Seen comments give an impression,
that "nosmp" could be removed, as long as "noapic" is present for
stable operation.
I can't test the problem, the machine now running in forced
uniprocessor mode is mission-criticalish box, and anyway trying
to trigger the problem does appear rather difficult -- besides
of it being nearly guaranteed to happen at 4 AM - if not tonight,
within 2-3 nights anyway.
/Matti Aarnio <matti.aarnio@zmailer.org>
reply other threads:[~2001-12-27 21:46 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20011227234542.C1072@mea-ext.zmailer.org \
--to=matti.aarnio@zmailer.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®