Re: BUG: unable to handle kernel NULL pointer dereference at IP: [<ffffffff8105ae4c>] process_one_work+

[Scott Garron <xen-devel@sce.pridelands.org>]

On 06/14/2011 09:55 AM, Konrad Rzeszutek Wilk wrote:
> But the curious thing is that you have two CPUs assigned to Dom0 and
> while CPU0 looks to be bouncing back and forth, CPU1 is doing
> something. The RIP is 0xffffffff8108820c. Can you try to run this
> through System.map? Or the whole bunch of these:
>
> ffffffff8108820c ffffffff81088100 ffffffff810881a7 ffffffff8108811a
> ffffffff816101a8 ffffffff81006c32 ffffffff816114a4 ffffffff8108803a
> ffffffff8105f5bd ffffffff81618564 ffffffff81617973 ffffffff816117a1
> ffffffff81618560

      I grabbed code snippets for each of these locations and put them here:

http://pridelands.org/~simba/xen/hailstorm-debugnotes.txt

> The other idea is to limit Dom0 to only run on one CPU. You can do
> this by having 'dom0_max_vcpus=1 dom0_vcpus_pin' and see if it fails
> somewhere else? It probably will die in the 0xffffffff810013aa :-(

      After setting dom0_max_vcpus=1 and dom0_vcpus_pin, the boot got to
"Trying to unpack rootfs image as initramfs..." and hung there.  The
serial console as well as the CTRL_A(x3) * outputs are here:

http://pridelands.org/~simba/xen/hailstorm-fullserial20110614.txt

> But irregardless of what I mentioned above we need to find out why
> process_one_worker got a toxic parameter. Can you disassemble
> 0xffffffff8105ae4c and see what it does and how it corresponds to
> 'process_one_work' in kernel/workqueue.c?

      I put the disassembly of it in the hailstorm-debugnotes.txt file
that I mentioned above.  Let me know if you need more than that.

> You can also instrument the code to find out what:
>
> 1804         work_func_t f = work->func;
>
> is

      I think this request is starting to go a little beyond what I know
how to do.

-- 
Scott Garron