Re: Tracebacks from dom0 pvops changeset 2342

[Jeremy Fitzhardinge <jeremy@goop.org>]

M A Young wrote:
> I have managed to get a dom0 kernel based on pvops changeset 2342 and 
> a Fedora kernel package to boot from a USB linux image, and it 
> finishes eventually, but there are several bug tracebacks on the way. 
> The full dmesg output (gzipped) is attached, but samples are below. 
> Are these useful, and would further information help?
>
>     Michael Young
>
> ------------[ cut here ]------------
> WARNING: at kernel/lockdep.c:2185 
> trace_hardirqs_on_caller+0xd1/0x151() (Not tainted)

I see this too, but it doesn't appear to be harmful.  I need to look 
into it to see what's really happening.

>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<(null)>] (null)
> PGD 0
> Oops: 0010 [#1] SMP DEBUG_PAGEALLOC
> last sysfs file: /sys/devices/LNXSYSTM:00/modalias
> CPU 0
> Modules linked in: intelfb(+) i2c_algo_bit i2c_core wmi video output 
> squashfs vf
> at fat usb_storage sdhci_pci sdhci mmc_core firewire_ohci 
> firewire_core crc_itu_
> t ata_generic pata_acpi
> Pid: 12, comm: work_on_cpu/0 Tainted: G        W 
> 2.6.29-0.41.rc2.pvops2342.fc10
> .x86_64 #1
> RIP: e030:[<0000000000000000>]  [<(null)>] (null)
> RSP: e02b:ffff8800de219c68  EFLAGS: 00010282
> RAX: ffffffff815382e0 RBX: 00000000fffffffa RCX: 0000000000000001
> RDX: 0000000000000001 RSI: 0000000000010000 RDI: 00000000000e0000
> RBP: ffff8800de219cd0 R08: 0000000000000002 R09: ffff8800dbc6c368
> R10: ffff8800de210200 R11: ffff8800dc84ab28 R12: 00000000000e0000
> R13: ffff8800dc470201 R14: 0000000000000001 R15: 00000000000e0000
> FS:  00007fc7af5fe790(0000) GS:ffff8800090c3000(0000) 
> knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001001000 CR4: 0000000000002620
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process work_on_cpu/0 (pid: 12, threadinfo ffff8800de218000, task 
> ffff8800de2100
> 00)
> Stack:
>  ffffffff8101f381 ffff8800de219c90 01ffffff8100ebd6 0000000000010000
>  ffff8800dbc6c350 ffff8800de219cb0 ffffffff8119666d 0000000000003001
>  0000000000010000 00000000000e0000 ffff8800dc470201 0000000000000001
> Call Trace:
>  [<ffffffff8101f381>] ? mtrr_add_page+0x3a/0x34f
>  [<ffffffff8119666d>] ? _raw_spin_unlock+0x8e/0x93
>  [<ffffffff8101f6d5>] mtrr_add+0x3f/0x4e

I haven't seen this particular one, but I haven't tried using intelfb 
yet.  The mtrr code needs some attention in general.

>  [<ffffffffa008b862>] intelfb_pci_register+0x6d0/0xde9 [intelfb]
>  [<ffffffff8106cd05>] ? trace_hardirqs_on_caller+0x1f/0x151
>  [<ffffffff8100dc09>] ? xen_force_evtchn_callback+0xd/0xf
>  [<ffffffff8100e2f2>] ? check_events+0x12/0x20
>  [<ffffffff811a03f3>] local_pci_probe+0x12/0x16
>  [<ffffffff8105a61f>] do_work_for_cpu+0x13/0x1b
>  [<ffffffff8105a815>] run_workqueue+0x13a/0x242
>  [<ffffffff8105a7c1>] ? run_workqueue+0xe6/0x242
>  [<ffffffff8105a60c>] ? do_work_for_cpu+0x0/0x1b
>  [<ffffffff8100e2df>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff8138113b>] ? __mutex_unlock_slowpath+0x128/0x133
>  [<ffffffff8105a9fd>] worker_thread+0xe0/0xf1
>  [<ffffffff8105e6c4>] ? autoremove_wake_function+0x0/0x38
>  [<ffffffff8105a91d>] ? worker_thread+0x0/0xf1
>  [<ffffffff8105e34c>] kthread+0x49/0x76
>  [<ffffffff8101322a>] child_rip+0xa/0x20
>  [<ffffffff81044800>] ? finish_task_switch+0x49/0x115
>  [<ffffffff8106ce44>] ? trace_hardirqs_on+0xd/0xf
>  [<ffffffff81012c10>] ? restore_args+0x0/0x30
>  [<ffffffff81013220>] ? child_rip+0x0/0x20
> Code:  Bad RIP value.
> RIP  [<(null)>] (null)
>  RSP <ffff8800de219c68>
> CR2: 0000000000000000
>
> swap_dup: Bad swap file entry 80000000006ba970
> swap_free: Bad swap file entry 80000000006aeee0
> BUG: Bad page map in process lvm  pte:d5ddc020 pmd:dccbc067

Hm, these should have been fixed by x86-fix-__supported_pte_mask.patch...

Thanks for the reports,
    J