The "GFP_BUFFER" issue was discussed in July see mail list archives.
I have had the "patch" in my 2.2.17 kernel since July and the problem still
exists. The server is general purpose: samba; mail; squid; etc running raid 1.
Generally the system falls over under heavy load eg compiling a kernel but it
also falls over unexpectedly. As the kernel has a large number of patches raid,
ide, ipsec, pptpd I have not tried the latest 2.2.18pre. There has also been
some
discussion on the kernel mailing lists about other VM problems and Marcelo
Tosatti <[EMAIL PROTECTED]> on the dbrd list posted
"So its not drbd fault, its VM fault.
Andrea's VM patch fixes this problem:
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre9/VM* "
It seems to me that the patch posted to this list (raid) alone will not fix the
problem
and the patch above will not apply to 2.2.17, so for me I wait until 2.2.18 and
see if it fixes the problem.
Having the machine reboot daily is not nice it is nearly as bad as windows.
(Sometimes it stays up for 5 days)
Godfrey
Roy Bixler wrote:
> On Monday 23 October 2000 15:50, Micah Anderson wrote:
> > This message sort of came out of the blue to the linux-raid mailing list -
> > it sounds like something that has been a discussion on the linux-kernel
> > list, but someone decided it was time to cross-post to the linux-raid list.
>
> >
> > Unfortunately, the context was lost completely.
>
> The context (for me) is that I have a moderately busy mail server running
> Linux 2.2.16 + Ingo RAID 0.90 patch and, after upgrading to 2.2.17 + Tosatti
> repacking of Ingo RAID 0.90 patch, I found that users with large inboxes on
> the RAID1 /var partition were getting popper connections stuck in the R state
> with 'kupdate' and/or 'kswapd' stuck in the D state. Only a reboot can clear
> the stuck 'popper' connections. When I tried going from 2.2.17 to
> 2.2.18pre15, mayhem broke loose. Here's quoting from my original bug report
> to Marcelo Tosatti and Alan Cox:
>
> situation developed where 'kupdate' and 'kswapd' were both stuck in
> the 'D' state (WCHAN for each was 'wait_on_buffer'). After a few
> minutes, the system became non-responcive and the console was flooded
> with 'do_try_to_free_pages failed' messages for various processes. I
> had no choice but to hit the Power (sic - Reset) button.
>
> I haven't had any more problems after reverting to 2.2.16 + Ingo RAID 0.90
> patch.
>
> > I have been the victim of the VM stuff for several kernels now - completely
> > bringing several machines to their knees. My solution, thus far, has been
> > to upgrade to 2.2.18-pre15 (seems to be the most stable), I have been
> > sucessful in installing the 2.2.17-RAID patches to continue the software
> > RAID setups that I have.
>
> Odd -- that's just about opposite of my situation where 2.2.18pre15 only made
> things worse.
>
> > I am wondering if this message, and the patch included in it, indicates
> > that the VM problem is related to software RAID? If so, does this patch fix
> > it? If this patch fixes it, is there any chance it will be tested? It is
> > nice to get patches that fix things, but only ones that work. I dont see
> > the point putting time into finding the problem, developing a patch, and
> > then distributing the patch but not testing the patch to see if it works.
> > This message to the linux-raid list has garnered no response, mostly
> > because I think everyone else on this list got it and thought to
> > themselves, "huh? what is this about? [delete]"...
>
> Perhaps my problem is not a widespread one, but I thought I heard of a few
> people on linux-kernel complain of a similar-sounding problem. The system I
> had trouble on is a production system and so I don't have the luxury of
> trying out untested patches. I would feel better if someone who has a
> problem similar reports that Marcelo's patch does indeed fix the problem.
>
>
> Thanks,
>
> --
> Roy Bixler | [EMAIL PROTECTED]
> The University of Chicago Press | AAUP Online Catalog
> http://www.press.uchicago.edu | http://aaup.uchicago.edu
> | http://aaup.princeton.edu
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
