From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Tracebacks from dom0 pvops changeset 2342 Date: Sun, 08 Feb 2009 17:39:54 -0800 Message-ID: <498F896A.5070505@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: M A Young Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.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: > [] ? mtrr_add_page+0x3a/0x34f > [] ? _raw_spin_unlock+0x8e/0x93 > [] 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. > [] intelfb_pci_register+0x6d0/0xde9 [intelfb] > [] ? trace_hardirqs_on_caller+0x1f/0x151 > [] ? xen_force_evtchn_callback+0xd/0xf > [] ? check_events+0x12/0x20 > [] local_pci_probe+0x12/0x16 > [] do_work_for_cpu+0x13/0x1b > [] run_workqueue+0x13a/0x242 > [] ? run_workqueue+0xe6/0x242 > [] ? do_work_for_cpu+0x0/0x1b > [] ? xen_restore_fl_direct_end+0x0/0x1 > [] ? __mutex_unlock_slowpath+0x128/0x133 > [] worker_thread+0xe0/0xf1 > [] ? autoremove_wake_function+0x0/0x38 > [] ? worker_thread+0x0/0xf1 > [] kthread+0x49/0x76 > [] child_rip+0xa/0x20 > [] ? finish_task_switch+0x49/0x115 > [] ? trace_hardirqs_on+0xd/0xf > [] ? restore_args+0x0/0x30 > [] ? child_rip+0x0/0x20 > Code: Bad RIP value. > RIP [<(null)>] (null) > RSP > 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