lkml.org 
[lkml]   [2012]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Regression: ONE CPU fails bootup at Re: [3.2.0-RC7] BUG: unable to handle kernel NULL pointer dereference at 0000000000000598 1.478005] IP: [<ffffffff8107a6c4>] queue_work_on+0x4/0x30
On 04.01.2012 19:36, John Stultz wrote:
> On Wed, 2012-01-04 at 09:17 +0100, Stefan Bader wrote:
>> Over night I had still be thinking on this and maybe one important fact I had
>> been ignoring. This really has only been observed on paravirt guests on Xen as
>> far as I know. And one thing that I should have pointed out is that
>>
>> [ 0.792634] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
>> [ 0.792725] rtc_cmos: probe of rtc_cmos failed with error -38
>>
>> So first the registration is done and the first line is the last thing printed
>> in the registration function. Then, and that line always comes after, the probe,
>> which looks like being done asynchronously, detects that the rtc is not
>> implemented. I would assume that this causes the rtc to be unregistered again
>> and that is probably the point where, under the right circumstances, the worker
>> triggered by the initialize alarm is trying to set another alarm. Probably while
>> some of the elements of the structure started to be torn down. I need to check
>> on that code path, yet. So right now its more a guess.
>
> Hrm. Do you see the same probe error with 3.1 kernels as well?
>
Yes. But I think this is not really wrong. Remember this is in a paravirtualized
guest. Which does not necessarily have access to all physical hardware. Maybe
something usually not expected. And having the class device registered before
the probe finally finds out about it not being present could be a bit suboptimal
in that case.

-Stefan

> Konrad: Is the probe failure a known issue on Xen? Any clues on whats
> going on there?
>
> thanks
> -john
>
>



\
 
 \ /
  Last update: 2012-01-04 19:53    [W:0.273 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site