FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 09-03-2011, 05:36 PM
Jonathan Nieder
 
Default Bug#548630: linux-image-2.6.26-2-686: Crash/Hang with heavy disk write when using SATA AHCI mode

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, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110903173549.GA24034@elie">http://lists.debian.org/20110903173549.GA24034@elie
 
Old 09-12-2011, 07:54 PM
Hans IJ
 
Default Bug#548630: linux-image-2.6.26-2-686: Crash/Hang with heavy disk write when using SATA AHCI mode

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 regardsHans

On Sat, Sep 3, 2011 at 7:36 PM, Jonathan Nieder <jrnieder@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-unsubscribe@bugs.debian.org.
 
Old 09-12-2011, 09:15 PM
Jonathan Nieder
 
Default Bug#548630: linux-image-2.6.26-2-686: Crash/Hang with heavy disk write when using SATA AHCI mode

tags 548630 + moreinfo
quit

Hi,

Hans IJ wrote:

> 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...

No problem. If there won't be time in the next month or so I guess we
should close the bug and reopen when someone else experiences it or it
happens again. If you or anyone else experiencing this ends up in a
position to reproduce it, in addition to trying a recent kernel it
would be interesting to try the debugging patch from [1] (the
surrounding thread is about a different bug that was introduced in a
newer kernel, but the patch makes the kernel print the right
information).

Also, it's possible (though unlikely) that a description of the
problem (plus hardware information they ask about in follow-up) could
be enough to ring a bell for the Linux memory management subsystem
maintainers; feel free to ask them at linux-mm@kvack.org (no
subscription required and the convention is always to reply-to-all
there), cc-ing this bug.

Sorry I have no better insights.
Jonathan

[1] http://thread.gmane.org/gmane.linux.kernel.mm/66536



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110912211551.GB2448@elie.gateway.2wire.net">http ://lists.debian.org/20110912211551.GB2448@elie.gateway.2wire.net
 

Thread Tools




All times are GMT. The time now is 01:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org