Re: Regression from 3.4.9 to 3.4.16 "stable" kernel

[Mark Lord <kernel@teksavvy.com>]

On 12-10-29 10:22 AM, Mark Lord wrote:
> On 12-10-29 02:46 AM, Willy Tarreau wrote:
>> On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
>>> My server here runs the 3.4.xx series of "stable" kernels.
>>> Until today, it was running 3.4.9.
>>> Today I tried to upgrade it to 3.4.16.
>>> It hangs in setup.c.
>>>
>>> I've isolated the fault down to this specific change
>>> that was made between 3.4.9 and 3.4.16.
>>> Reverting this change allows the system to boot/run normally again.
..
>> For the record, it is this commit introduced in 3.4.16 :
>>
>> commit efd5fa0c1a1d1b46846ea6e8d1a783d0d8a6a721
>> Author: Jacob Shin <jacob.shin@amd.com>
>> Date:   Thu Oct 20 16:15:26 2011 -0500
>>
>>     x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping.
>>     
>>     commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream.
>>     
>>     On systems with very large memory (1 TB in our case), BIOS may report a
>>     reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
>>     these from the direct mapping.
>>     
>>     [ hpa: this should be done not just for > 4 GB but for everything above the legacy
>>       region (1 MB), at the very least.  That, however, turns out to require significant
>>       restructuring.  That work is well underway, but is not suitable for rc/stable. ]
>>     
>>     Signed-off-by: Jacob Shin <jacob.shin@amd.com>
>>     Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com
>>     Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
>>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
..
> I've also now downloaded linux-3.7.0-rc3, and it boots/runs without need for patching.
> So there's a fix somewhere in between that perhaps could also get backported to -stable.
..

Heh.. except that kernel has its own issues -- hangs in some kind of screen loop
in the Radeon code (?) when trying to shutdown.  ctrl-alt-sysrq s+u+s+b gets out of that,
but it hangs in a similar fashion during the subsequent reboot.

A full power-off was required to get the Radeon video to behave so I could reboot
the system with 3.4.16 again.  I'm not going to pursue that issue for now, though.