Re: kernel oops and panic in acpi_atomic_read under 2.6.39.3. call trace included

[rick@microway.com]

Hi Huang,

I've been running for a while now with this new patch.  I have not gotten
any panic output though.  This is the only output I have from GHES:

[22256.616069] GHES: gar accessed: 0, 0xbf7b9370
[102115.873369] GHES: gar accessed: 0, 0xbf7b9370
[175460.888809] GHES: gar accessed: 0, 0xbf7b9370
[223652.976925] GHES: gar accessed: 0, 0xbf7b9370
[284678.016631] GHES: gar accessed: 0, 0xbf7b9370
[321563.363578] GHES: gar accessed: 0, 0xbf7b9370
[500789.731559] GHES: gar accessed: 0, 0xbf7b9370
[539808.495653] GHES: gar accessed: 0, 0xbf7b9370
[545116.419274] GHES: gar accessed: 0, 0xbf7b9370
[686744.665292] GHES: gar accessed: 0, 0xbf7b9370

Do you think changing from 5620-5670 cpus changed the behavior?

Thanks,
Rick


> On 09/03/2011 07:32 AM, rick@microway.com wrote:
>> Hi Huang,
>>
>> Sorry for the delay in my response.  Hurricane Irene delayed our testing
>> a
>> bit.
>>
>> I had to switch the 5620 CPUS I had for 5670s.  After 4 days of running
>> (it was usually about 2 before) I finally got this output in dmesg:
>>
>> [337296.365930] GHES: gar accessed: 0, 0xbf7b9370
>> [337296.365936] ACPI atomic read mem: addr 0xbf7b9370 mapped to
>> ffffc90013ee8370
>>
>> It is not mapped to 0 as expected, but it didn't crash now!
>
> But I don't think this patch fixed the issue.  Maybe just hided the
> issue.  Do you have time to try the new patch attached?
>
> Best Regards,
> Huang Ying
>
>