Created attachment 22552 [details]
Patch to fix cpa memtype set_pages_array_xx reserving
With the set_pages_array_xx() interface, the page virtual address is used to reserve memtype ranges instead of the page physical address. This causes incorrect ranges to be reserved with various symptoms, in particular false errors.
Furthermore, highmem pages were not handled correctly. CPA should ignore them. One can argue that it is an error to call set_pages_array_xx() with highmem pages, but usually the page arrays that are used as arguments to this interface contain a mix of highmem and lowmem pages.
Patch that seems to fix the problem attached.
On Fri, 31 Jul 2009 13:39:31 GMT
That seems fairly serious and might be 2.6.31 material (or earlier!)
Please don't submit patches via bugzilla - it mucks up everyone's
processes and tools.
Please resend the patch via email as per
Documentation/SubmittingPatches. Suitable recipients are
"H. Peter Anvin" <firstname.lastname@example.org>
Ingo Molnar <email@example.com>
Thomas Gleixner <firstname.lastname@example.org>
Venkatesh Pallipadi <email@example.com>
"Siddha, Suresh B" <firstname.lastname@example.org>
Yuk.... Using virtual address instead of physical. Thats second bug since yesterday related to PAT. I think I should not send any patches for next few days.
Regarding the fix, may be it is better to use __pa() like rest of set_memory_* routines are using.
Author: email@example.com <firstname.lastname@example.org>
Date: Thu Mar 19 14:51:14 2009 -0700
x86, PAT: Add support for struct page pointer array in cpa set_clr
First-Bad-Commit : 9ae2847591c857bed44bc094b908b412bfa1b244
Notify-Also : Ingo Molnar <email@example.com>
Handled-By : Thomas Hellstrom <firstname.lastname@example.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=22552
*** Bug 13667 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> Regarding the fix, may be it is better to use __pa() like rest of
> routines are using.
Those interfaces already have the virtual address so it's easy to convert to physical using __pa().
However, when converting a struct page * to a physical address I think it's confusing to first convert to virtual and then to physical. Better to use page_to_pfn() IMHO. I don't feel strongly about it, though, so if you feel like changing it please do so. As for now, I'm posting the original patch.
I think this bug is also responsible for an issue I've been seeing with KDE with both .30 and .31.
Sometimes, when I start a second X session from KDE to log in as a different user, ksplash (the kde splash screen) will sometimes end in an endless loop and race the CPU.
I've not seen that happening anymore since I applied this patch. Please push it for both .30 and .31, thanks.
> I think this bug is also responsible for an issue I've been seeing
> with KDE with both .30 and .31.
> Sometimes, when I start a second X session from KDE to log in as a
> different user, ksplash (the kde splash screen) will sometimes end
> in an endless loop and race the CPU.
> I've not seen that happening anymore since I applied this patch.
> Please push it for both .30 and .31, thanks.
those affected APIs are not used on v2.6.30 at all.
I've marked the fixes for a .30 backport but it would still be nice
to double check whether you have any additional graphics drivers in
your .30 kernel, beyond what is in vanilla v2.6.30.
On Tuesday 04 August 2009, you wrote:
> those affected APIs are not used on v2.6.30 at all.
> I've marked the fixes for a .30 backport but it would still be nice
> to double check whether you have any additional graphics drivers in
> your .30 kernel, beyond what is in vanilla v2.6.30.
I don't. The only "weird" thing about my video setup is that I use vesafb
for my consoles. The rest is bog standard vanilla Intel drivers.
I may be wrong about this patch being involved; it may have been fixed by
some other commit in .31. I just noticed that I suddenly no longer needed
to kill the ksplash process regularly and that did roughly coincide
with -rc5 or maybe -rc4 and applying this patch.
If needed I can try to verify, but as the problem did not occur 100%
reliably that might be tricky and would cost a lot of time.
> If needed I can try to verify, but as the problem did not occur
> 100% reliably that might be tricky and would cost a lot of time.
Not needed - just wanted to inquire in case there are some easy
"No kernel bugs to report" is a desired state that should not
require any extra work on your part! ;-)
Fixed by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8523acfe40efc1a8d3da8f473ca67cb195b06f0c .