Hi Jonathan,
I cannot use the hardware to reproduce. It is currently my LAMP server, and
used 24/7. Sorry. I was able to fix at that time the bug by putting the two
DDR modules in 32 bit configuration, and not in 64 bit.
I hope this helps a bit...
Best regards
Hans
On Sat, Sep 3, 2011 at 7:36 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> Hi,
>
> Hans IJ wrote:
>
> > I can reproduce this problem on both an ASUS P5Q-VM and Intel DG45ID
> > Motherboard. Both MB's have same ICH10 chipset.
> > Let me know if you need more.
>
> Sorry for the loong delay. The assertion triggered here is in
> mm/vmscan.c, function isolate_lru_pages():
>
> switch (__isolate_lru_page(page, mode, file)) {
> case 0:
> [...]
>
> case -EBUSY:
> [...]
> continue;
>
> default:
> BUG();
> }
>
> eax contains -EINVAL, so chances are that was the error code. It
> means the PageLRU flag was clear, the page's mode didn't match "mode",
> the page's is_file_cache flag didn't match "file", or the page was
> unevictable.
>
> Maybe this is fixed by v2.6.39~59 (mm: check PageUnevictable in
> lru_deactivate_fn(), 2011-05-11), even though the case that prompted
> that patch was not broken until v2.6.39-rc1~329 (2011-03-22). Can you
> still reproduce this? If so, could you test 2.6.39 (which would
> work according to that hypothesis) and 2.6.39-rc7 (which wouldn't) to
> check?
>
> Hope that helps,
> Jonathan
>
>
>
> --
> To unsubscribe, send mail to 548630-unsubscr...@bugs.debian.org.
>
