[lkml]   [2001]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up
On Tuesday 20 February 2001 22:21, Colonel wrote:
> From: "Tom Sightler" <>
> Cc: <>
> Date: Tue, 20 Feb 2001 14:43:07 -0500
> Content-Type: text/plain;
> charset="iso-8859-1"
> > > >I'm building a firewall on a P133 with 48 MB of memory using RH
> > > > 7.0, latest updates, etc. and kernel 2.4.1.
> > > >I've built a customized install of RH (~200MB) which I untar
> > > > onto
> the
> > > >system after building my raid arrays, etc. via a Rescue CD which
> > > > I created using Timo's Rescue CD project. The booting kernel
> > > > is 2.4.1-ac10, no networking, raid compiled in but raid1 as a
> > > > module
> > >
> > > Hmm, raid as a module was always a Bad Idea(tm) in the 2.2
> > > "alpha" raid (which was misnamed and is 2.4 raid). I suggest you
> > > change that and update, as I had no problems with 2.4.2-pre2/3,
> > > nor have any been posted to the raid list.
> >
> > I just tried with 2.4.1-ac14, raid and raid1 compiled in and it did
> > the same thing. I'm going to try to compile reiserfs in (if I have
> > enough
> room
> > to still fit the kernel on the floppy with it's initial ramdisk,
> > etc.)
> and
> > see what that does.
> There seem to be several reports of reiserfs falling over when memory is
> low. It seems to be undetermined if this problem is actually reiserfs
> or MM related, but there are other threads on this list regarding similar
> issues. This would explain why the same disk would work on a different
> machine with more memory. Any chance you could add memory to the box
> temporarily just to see if it helps, this may help prove if this is the
> problem or not.
> Well, I didn't happen to start the thread, but your comments may
> explain some "gee I wonder if it died" problems I just had with my
> 2.4.1-pre2+reiser test box. It only has 16M, so it's always low
> memory (never been a real problem in the past however). The test
> situation is easily repeatable for me [1]. It's a 486 wall mount, so
> it's easier to convert the fs than add memory, and it showed about
> 200k free at the time of the sluggishness. Previous 2.4.1 testing
> with ext2 fs didn't show any sluggishness, but I also didn't happen to
> run the test above either. When I come back to the office later, I'll
> convert the fs, repeat the test and pass on the results.
> [1] Since I decided to try to catch up on kernels, I had just grabbed
> -ac18, cd to ~linux and run "rm -r *" via an ssh connection. In a
> second connection, I tried a simple "dmesg" and waited over a minute
> for results (long enough to log in directly on the box and bring up
> top) followed by loading emacs for ftp transfers from,
> which again 'went to sleep'.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at

If these are freezes I had them too in 2.4.1, 2.4.2-pre1 fixed it for me.
Really I think it was the patch in handle_mm_fault setting TASK_RUNNING.


Home page:
none currently
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:17    [from the cache]
©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site