From: Chase Venters <chase.venters@clientec.com>
To: Andreas Mohr <andi@rhlx01.fht-esslingen.de>
Cc: linux-kernel@vger.kernel.org, ck@vds.kolivas.org
Subject: Re: [ck] Bad page state at free_hot_cold_page
Date: Thu, 12 Jan 2006 03:36:02 -0600 [thread overview]
Message-ID: <200601120336.03289.chase.venters@clientec.com> (raw)
In-Reply-To: <20060112092406.GA2587@rhlx01.fht-esslingen.de>
On Thursday 12 January 2006 03:24, Andreas Mohr wrote:
> AFAIK random page state toggling often happens due to bad RAM.
>
> Care to run memtest86 or similar to confirm this?
> Or also try running an older kernel to verify whether it doesn't happen
> there. But I'm betting on bad RAM :-\
Andreas,
I've been looking into this problem a little bit more (did some digging to
try and teach myself a little bit about the page flags). I noticed after
posting that I had bad page states reported in dmesg for amarokapp (new ones)
as well.
So I got a bit curious and looked to see what bits were stuck on... and I
started to wonder if it could have something to do with ALSA. (Unfortunately
I'm quickly reaching the limit of my current understanding of the kernel's
innards)
Anyway, I tried a test - made sure both amarokapp and artsd were dead, then
used rmmod to pluck out every last "snd" module. I put them back in, fired up
amarok, and went to play a song. It played fine with no noticeable latency,
so I tried switching to another track. Doing so caused the system to freeze
for a few seconds and another set of bad page states to go rushing through
the log.
I can accept bad memory (though I think it's unlikely on this system because
I've tested that fairly recently) but the page states, while bad, are
consistently (not randomly) so.
I'd reboot right now and test it, but at the moment I'm capable of
reproducing these page state errors 100% of the time, so if there are any
sorts of things I can do to debug the thing while it's up I'd like to move
forward with that before I reboot and lose whatever 'ideal state' got me here
in the first place.
Thanks,
Chase
> Andreas Mohr
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2006-01-12 9:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-12 9:00 Bad page state at free_hot_cold_page Chase Venters
2006-01-12 9:24 ` [ck] " Andreas Mohr
2006-01-12 9:36 ` Chase Venters [this message]
2006-01-12 11:15 ` [ck] Bad page state at free_hot_cold_page : Three more reports, suspend2 but non-ck as far as I know Nigel Cunningham
2006-01-12 22:00 ` [ck] Bad page state at free_hot_cold_page Jan Engelhardt
[not found] ` <200601121047.13016.oyvinst@ifi.uio.no>
2006-01-12 9:55 ` Chase Venters
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=200601120336.03289.chase.venters@clientec.com \
--to=chase.venters@clientec.com \
--cc=andi@rhlx01.fht-esslingen.de \
--cc=ck@vds.kolivas.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