* PV HVM Linux drivers fail
@ 2010-07-28 21:53 Leo
2010-07-28 21:57 ` Leo
2010-07-29 14:47 ` Stefano Stabellini
0 siblings, 2 replies; 9+ messages in thread
From: Leo @ 2010-07-28 21:53 UTC (permalink / raw)
To: xen-devel, xen-users
[-- Attachment #1.1: Type: text/plain, Size: 12530 bytes --]
Hi,
I don't see anyone having similar issues when running domU kernel in HVM.
Hopefully it's just some very obvious stuff I missed.
I am using the 2.6.34-pvhvm-v6 branch from git://
xenbits.xen.org/people/sstabellini/linux-pvhvm. I compiled the kernel with
just about everything as modules, including platform-pci, xen-blkfront and
xen-netfront.
When I use the kernel parameter xen_emul_unplug=ignore, both ata_piix and
8139cp drivers attach to the emulated devices and work just fine.
When I unplug either the nic or the ide-disk, the loading order of the 3
modules makes some difference. If I load platform-pci first before either
of the frontend drivers, I get XENBUS Timeout. Note that loading the
platform-pci module doesn't cause any error, it is loading the frontend
drivers when I see this error: (This happens when I load the xen-netfront
driver. platform-pci is loaded at 58s. I also trimmed the wait time from
300s to 30s)
[ 102.570177] Initialising Xen virtual ethernet driver.
[ 107.676025] XENBUS: Waiting for devices to initialise:
25s...20s...15s...10s...5s...0s...
[ 132.677038] XENBUS: Timeout connecting to device: device/vif/0 (local
state 1, remote state 2)
So I have to load the frontend drivers before platform-pci, and none of this
error like this occured. And because of that I cannot compile in all the
three modules as they'll always be waiting to connect.
However I get some other error. When I unplug ide-disks, I get this:
<4>[ 29.842072] ------------[ cut here ]------------
<4>[ 29.842785] WARNING: at fs/sysfs/dir.c:451 sysfs_add_one+0xac/0xc0()
<4>[ 29.843434] Hardware name: HVM domU
<4>[ 29.844070] sysfs: cannot create duplicate filename '/block/xvda'
<4>[ 29.844713] Modules linked in: 8139cp mii platform_pci xen_netfront
xen_blkfront
<4>[ 29.847272] Pid: 20, comm: xenwatch Not tainted 2.6.34-pvhvm #10
<4>[ 29.847945] Call Trace:
<4>[ 29.856027] [<ffffffff81146ebc>] ? sysfs_add_one+0xac/0xc0
<4>[ 29.856722] [<ffffffff810424fa>] warn_slowpath_common+0x77/0x8f
<4>[ 29.857372] [<ffffffff81042587>] warn_slowpath_fmt+0x64/0x66
<4>[ 29.858015] [<ffffffff8106e6c8>] ? do_raw_spin_unlock+0x17/0x1b
<4>[ 29.858722] [<ffffffff81146e32>] ? sysfs_add_one+0x22/0xc0
<4>[ 29.859358] [<ffffffff812b3b94>] ? __mutex_lock_common+0x229/0x243
<4>[ 29.860034] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
<4>[ 29.860815] [<ffffffff81146d7a>] ? sysfs_pathname+0x37/0x3f
<4>[ 29.861461] [<ffffffff81146d7a>] ? sysfs_pathname+0x37/0x3f
<4>[ 29.862126] [<ffffffff81146ebc>] sysfs_add_one+0xac/0xc0
<4>[ 29.862768] [<ffffffff811475f1>] create_dir+0x58/0x87
<4>[ 29.863393] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
<4>[ 29.864092] [<ffffffff81147658>] sysfs_create_dir+0x38/0x4f
<4>[ 29.864833] [<ffffffff812b49f8>] ? _raw_spin_unlock+0x2d/0x38
<4>[ 29.865525] [<ffffffff8119aa6d>] kobject_add_internal+0xdb/0x19b
<4>[ 29.866186] [<ffffffff8119ac05>] kobject_add_varg+0x41/0x4e
<4>[ 29.866858] [<ffffffff8119b0d0>] kobject_add+0x89/0x8b
<4>[ 29.867590] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
<4>[ 29.868280] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
<4>[ 29.868936] [<ffffffff8119405c>] ? exact_lock+0x0/0x14
<4>[ 29.869574] [<ffffffff810e71d8>] ? __kmalloc+0x106/0x118
<4>[ 29.870232] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
<4>[ 29.870866] [<ffffffff8119a98a>] ? kobject_get+0x1a/0x22
<4>[ 29.871510] [<ffffffff81209ea0>] ? get_device+0x14/0x1a
<4>[ 29.872209] [<ffffffff8120a451>] device_add+0xdc/0x60c
<4>[ 29.872866] [<ffffffff8120ee8e>] ? kobj_map+0x68/0x12a
<4>[ 29.873506] [<ffffffff8114082b>] register_disk+0x3c/0x11d
<4>[ 29.874240] [<ffffffff81194db7>] add_disk+0xb8/0x119
<4>[ 29.874922] [<ffffffffa000125b>] backend_changed+0x441/0x45b
[xen_blkfront]
<4>[ 29.875604] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
<4>[ 29.876245] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
<4>[ 29.876864] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
<4>[ 29.877481] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
<4>[ 29.878134] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
<4>[ 29.878886] [<ffffffff8105c35e>] kthread+0x69/0x71
<4>[ 29.879517] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
<4>[ 29.880198] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
<4>[ 29.880923] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
<4>[ 29.908017] ---[ end trace 3f99b54d0b8663be ]---
<3>[ 29.909904] kobject_add_internal failed for xvda with -EEXIST, don't
try to register things with the same name in the same directory.
<4>[ 29.911103] Pid: 20, comm: xenwatch Tainted: G W 2.6.34-pvhvm
#10
<4>[ 29.916378] Call Trace:
<4>[ 29.917001] [<ffffffff8119a861>] ? kobject_put+0x47/0x4b
<4>[ 29.917682] [<ffffffff8119aaeb>] kobject_add_internal+0x159/0x19b
<4>[ 29.918389] [<ffffffff8119ac05>] kobject_add_varg+0x41/0x4e
<4>[ 29.919124] [<ffffffff8119b0d0>] kobject_add+0x89/0x8b
<4>[ 29.919834] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
<4>[ 29.920474] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
<4>[ 29.921191] [<ffffffff8119405c>] ? exact_lock+0x0/0x14
<4>[ 29.921955] [<ffffffff810e71d8>] ? __kmalloc+0x106/0x118
<4>[ 29.922690] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
<4>[ 29.923578] [<ffffffff8119a98a>] ? kobject_get+0x1a/0x22
<4>[ 29.924324] [<ffffffff81209ea0>] ? get_device+0x14/0x1a
<4>[ 29.925178] [<ffffffff8120a451>] device_add+0xdc/0x60c
<4>[ 29.925873] [<ffffffff8120ee8e>] ? kobj_map+0x68/0x12a
<4>[ 29.926567] [<ffffffff8114082b>] register_disk+0x3c/0x11d
<4>[ 29.927195] [<ffffffff81194db7>] add_disk+0xb8/0x119
<4>[ 29.927821] [<ffffffffa000125b>] backend_changed+0x441/0x45b
[xen_blkfront]
<4>[ 29.928566] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
<4>[ 29.929211] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
<4>[ 29.929855] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
<4>[ 29.930490] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
<4>[ 29.931151] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
<4>[ 29.931787] [<ffffffff8105c35e>] kthread+0x69/0x71
<4>[ 29.932550] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
<4>[ 29.933201] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
<4>[ 29.933834] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
<5>[ 29.966562] SCSI subsystem initialized
<0>[ 29.984037] ------------[ cut here ]------------
<2>[ 29.984721] kernel BUG at fs/sysfs/group.c:65!
<0>[ 29.985357] invalid opcode: 0000 [#1] PREEMPT SMP
<0>[ 29.987151] last sysfs file: /sys/class/firmware/timeout
<4>[ 29.987978] CPU 0
<4>[ 29.988014] Modules linked in: sd_mod scsi_mod ext3 jbd mbcache 8139cp
mii platform_pci xen_netfront xen_blkfront
<4>[ 29.988014]
<4>[ 29.988014] Pid: 20, comm: xenwatch Tainted: G W 2.6.34-pvhvm
#10 /HVM domU
<4>[ 29.988014] RIP: 0010:[<ffffffff8114883a>] [<ffffffff8114883a>]
internal_create_group+0x2a/0x127
<4>[ 29.988014] RSP: 0018:ffff88001f97fd00 EFLAGS: 00010246
<4>[ 29.988014] RAX: 00000000ffffffef RBX: ffff88001e200870 RCX:
ffffffff8120a927
<4>[ 29.988014] RDX: ffffffff81640280 RSI: 0000000000000000 RDI:
ffff88001e200870
<4>[ 29.988014] RBP: ffff88001f97fd40 R08: ffff88001f97e000 R09:
ffff880001a14c20
<4>[ 29.988014] R10: ffff88001f97fca0 R11: 0000000000000000 R12:
ffff88001e0e88a8
<4>[ 29.988014] R13: 000000000000000f R14: ffff88001e200860 R15:
ffffffff81640280
<4>[ 29.988014] FS: 0000000000000000(0000) GS:ffff880001a00000(0000)
knlGS:0000000000000000
<4>[ 29.988014] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
<4>[ 29.988014] CR2: 00007f151c82200f CR3: 000000001e7bc000 CR4:
00000000000006b0
<4>[ 29.988014] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
<4>[ 29.988014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
<4>[ 29.988014] Process xenwatch (pid: 20, threadinfo ffff88001f97e000,
task ffff88001f975b80)
<0>[ 29.988014] Stack:
<4>[ 29.988014] 0000000000000000 0000000089700e79 ffff88001f97fd70
ffff88001e200800
<4>[ 29.988014] <0> ffff88001e0e88a8 000000000000000f ffff88001e200860
0000000000000000
<4>[ 29.988014] <0> ffff88001f97fd50 ffffffff81148958 ffff88001f97fd60
ffffffff810a39fe
<0>[ 29.988014] Call Trace:
<4>[ 29.988014] [<ffffffff81148958>] sysfs_create_group+0xe/0x12
<4>[ 29.988014] [<ffffffff810a39fe>] blk_trace_init_sysfs+0x14/0x16
<4>[ 29.988014] [<ffffffff8118ff11>] blk_register_queue+0x42/0xc8
<4>[ 29.988014] [<ffffffff81194dbf>] add_disk+0xc0/0x119
<4>[ 29.988014] [<ffffffffa000125b>] backend_changed+0x441/0x45b
[xen_blkfront]
<4>[ 29.988014] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
<4>[ 29.988014] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
<4>[ 29.988014] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
<4>[ 29.988014] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
<4>[ 29.988014] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
<4>[ 29.988014] [<ffffffff8105c35e>] kthread+0x69/0x71
<4>[ 29.988014] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
<4>[ 29.988014] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
<4>[ 29.988014] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
<0>[ 29.988014] Code: c3 55 48 89 e5 41 57 49 89 d7 41 56 41 55 41 54 53
48 89 fb 48 83 ec 18 48 85 ff 89 75 c0 74 0b 85 f6 75 11 48 83 7f 30 00 75
04 <0f> 0b eb fe 83 7d c0 00 74 11 48 83 7b 30 00 41 bd ea ff ff ff
<1>[ 29.988014] RIP [<ffffffff8114883a>] internal_create_group+0x2a/0x127
<4>[ 29.988014] RSP <ffff88001f97fd00>
<4>[ 30.132020] ---[ end trace 3f99b54d0b8663bf ]---
Then when I do an fdisk on block device 202:0, I get this:
<4>[ 223.840262] ------------[ cut here ]------------
<4>[ 223.841061] WARNING: at fs/fs-writeback.c:1105
__mark_inode_dirty+0xed/0x130()
<4>[ 223.842008] Hardware name: HVM domU
<4>[ 223.842585] Modules linked in: ata_piix libata sd_mod scsi_mod ext3
jbd mbcache 8139cp mii platform_pci xen_netfront xen_blkfront
<4>[ 223.847533] Pid: 875, comm: busybox Tainted: G D W 2.6.34-pvhvm
#10
<4>[ 223.848259] Call Trace:
<4>[ 223.848994] [<ffffffff8110e33a>] ? __mark_inode_dirty+0xed/0x130
<4>[ 223.849761] [<ffffffff810424fa>] warn_slowpath_common+0x77/0x8f
<4>[ 223.850651] [<ffffffff81042521>] warn_slowpath_null+0xf/0x11
<4>[ 223.851509] [<ffffffff8110e33a>] __mark_inode_dirty+0xed/0x130
<4>[ 223.852195] [<ffffffff810b55ac>] ? sync_page_killable+0x0/0x3e
<4>[ 223.853449] [<ffffffff811041cd>] mark_inode_dirty_sync+0xe/0x10
<4>[ 223.854260] [<ffffffff81105554>] touch_atime+0xfb/0x120
<4>[ 223.855144] [<ffffffff810b41a6>] file_accessed+0x17/0x19
<4>[ 223.855956] [<ffffffff810b5ac4>] generic_file_aio_read+0x4da/0x53e
<4>[ 223.856686] [<ffffffff810f27c7>] do_sync_read+0xc2/0x106
<4>[ 223.857307] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
<4>[ 223.858023] [<ffffffff8115aca4>] ? security_file_permission+0x11/0x13
<4>[ 223.858993] [<ffffffff810f2e9d>] vfs_read+0xa8/0x102
<4>[ 223.859658] [<ffffffff810f313f>] sys_read+0x47/0x6d
<4>[ 223.860379] [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
<4>[ 223.861296] ---[ end trace 3f99b54d0b8663c0 ]---
<3>[ 223.861934] bdi-block not registered
Reading from the block device returns some random data: (here I am doing an
fdisk on the block device 202:0), and it's returning the wrong disk size.
The virtual disk is 15GiB.
Disk /dev/xvda: 4393 MB, 4393723904 bytes
255 heads, 63 sectors/track, 534 cylinders, total 8581492 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk /dev/xvda doesn't contain a valid partition table
If I unplug the nics, there is no error,
[ 29.738321] Initialising Xen virtual ethernet driver.
[ 29.748844] alloc irq_desc for 28 on node -1
[ 29.748847] alloc kstat_irqs on node -1
[ 29.748866] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level,
low) -> IRQ 28
[ 29.750216] Grant table initialized
[ 29.753307] vif vif-0: 2 parsing device/vif/0/mac
8130cp, as expected, is not attached to eth0. However, it seems
xen-netfront cannot get the MAC address of eth0:
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Is it something very obvious that I missed?
Thanks!
Leo
[-- Attachment #1.2: Type: text/html, Size: 31087 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PV HVM Linux drivers fail
2010-07-28 21:53 PV HVM Linux drivers fail Leo
@ 2010-07-28 21:57 ` Leo
2010-07-29 14:47 ` Stefano Stabellini
1 sibling, 0 replies; 9+ messages in thread
From: Leo @ 2010-07-28 21:57 UTC (permalink / raw)
To: xen-devel, xen-users
[-- Attachment #1.1: Type: text/plain, Size: 13282 bytes --]
Oh, I forgot to mention the Xen version is major 3, minor 4, extra .2,
Platform PCI I/O protocol version 1, does not support pvclock on HVM (pv
timer disabled). And HVMOP_pagetable_dying is not supported.
Leo
On Wed, Jul 28, 2010 at 2:53 PM, Leo <fencingleo@gmail.com> wrote:
> Hi,
>
> I don't see anyone having similar issues when running domU kernel in HVM.
> Hopefully it's just some very obvious stuff I missed.
>
> I am using the 2.6.34-pvhvm-v6 branch from git://
> xenbits.xen.org/people/sstabellini/linux-pvhvm. I compiled the kernel
> with just about everything as modules, including platform-pci, xen-blkfront
> and xen-netfront.
>
> When I use the kernel parameter xen_emul_unplug=ignore, both ata_piix and
> 8139cp drivers attach to the emulated devices and work just fine.
>
> When I unplug either the nic or the ide-disk, the loading order of the 3
> modules makes some difference. If I load platform-pci first before either
> of the frontend drivers, I get XENBUS Timeout. Note that loading the
> platform-pci module doesn't cause any error, it is loading the frontend
> drivers when I see this error: (This happens when I load the xen-netfront
> driver. platform-pci is loaded at 58s. I also trimmed the wait time from
> 300s to 30s)
>
> [ 102.570177] Initialising Xen virtual ethernet driver.
> [ 107.676025] XENBUS: Waiting for devices to initialise:
> 25s...20s...15s...10s...5s...0s...
> [ 132.677038] XENBUS: Timeout connecting to device: device/vif/0 (local
> state 1, remote state 2)
>
> So I have to load the frontend drivers before platform-pci, and none of
> this error like this occured. And because of that I cannot compile in all
> the three modules as they'll always be waiting to connect.
>
> However I get some other error. When I unplug ide-disks, I get this:
>
> <4>[ 29.842072] ------------[ cut here ]------------
> <4>[ 29.842785] WARNING: at fs/sysfs/dir.c:451 sysfs_add_one+0xac/0xc0()
> <4>[ 29.843434] Hardware name: HVM domU
> <4>[ 29.844070] sysfs: cannot create duplicate filename '/block/xvda'
> <4>[ 29.844713] Modules linked in: 8139cp mii platform_pci xen_netfront
> xen_blkfront
> <4>[ 29.847272] Pid: 20, comm: xenwatch Not tainted 2.6.34-pvhvm #10
> <4>[ 29.847945] Call Trace:
> <4>[ 29.856027] [<ffffffff81146ebc>] ? sysfs_add_one+0xac/0xc0
> <4>[ 29.856722] [<ffffffff810424fa>] warn_slowpath_common+0x77/0x8f
> <4>[ 29.857372] [<ffffffff81042587>] warn_slowpath_fmt+0x64/0x66
> <4>[ 29.858015] [<ffffffff8106e6c8>] ? do_raw_spin_unlock+0x17/0x1b
> <4>[ 29.858722] [<ffffffff81146e32>] ? sysfs_add_one+0x22/0xc0
> <4>[ 29.859358] [<ffffffff812b3b94>] ? __mutex_lock_common+0x229/0x243
> <4>[ 29.860034] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> <4>[ 29.860815] [<ffffffff81146d7a>] ? sysfs_pathname+0x37/0x3f
> <4>[ 29.861461] [<ffffffff81146d7a>] ? sysfs_pathname+0x37/0x3f
> <4>[ 29.862126] [<ffffffff81146ebc>] sysfs_add_one+0xac/0xc0
> <4>[ 29.862768] [<ffffffff811475f1>] create_dir+0x58/0x87
> <4>[ 29.863393] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> <4>[ 29.864092] [<ffffffff81147658>] sysfs_create_dir+0x38/0x4f
> <4>[ 29.864833] [<ffffffff812b49f8>] ? _raw_spin_unlock+0x2d/0x38
> <4>[ 29.865525] [<ffffffff8119aa6d>] kobject_add_internal+0xdb/0x19b
> <4>[ 29.866186] [<ffffffff8119ac05>] kobject_add_varg+0x41/0x4e
> <4>[ 29.866858] [<ffffffff8119b0d0>] kobject_add+0x89/0x8b
> <4>[ 29.867590] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.868280] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.868936] [<ffffffff8119405c>] ? exact_lock+0x0/0x14
> <4>[ 29.869574] [<ffffffff810e71d8>] ? __kmalloc+0x106/0x118
> <4>[ 29.870232] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.870866] [<ffffffff8119a98a>] ? kobject_get+0x1a/0x22
> <4>[ 29.871510] [<ffffffff81209ea0>] ? get_device+0x14/0x1a
> <4>[ 29.872209] [<ffffffff8120a451>] device_add+0xdc/0x60c
> <4>[ 29.872866] [<ffffffff8120ee8e>] ? kobj_map+0x68/0x12a
> <4>[ 29.873506] [<ffffffff8114082b>] register_disk+0x3c/0x11d
> <4>[ 29.874240] [<ffffffff81194db7>] add_disk+0xb8/0x119
> <4>[ 29.874922] [<ffffffffa000125b>] backend_changed+0x441/0x45b
> [xen_blkfront]
> <4>[ 29.875604] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.876245] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> <4>[ 29.876864] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> <4>[ 29.877481] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
> <4>[ 29.878134] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.878886] [<ffffffff8105c35e>] kthread+0x69/0x71
> <4>[ 29.879517] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> <4>[ 29.880198] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> <4>[ 29.880923] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> <4>[ 29.908017] ---[ end trace 3f99b54d0b8663be ]---
> <3>[ 29.909904] kobject_add_internal failed for xvda with -EEXIST, don't
> try to register things with the same name in the same directory.
> <4>[ 29.911103] Pid: 20, comm: xenwatch Tainted: G W 2.6.34-pvhvm
> #10
> <4>[ 29.916378] Call Trace:
> <4>[ 29.917001] [<ffffffff8119a861>] ? kobject_put+0x47/0x4b
> <4>[ 29.917682] [<ffffffff8119aaeb>] kobject_add_internal+0x159/0x19b
> <4>[ 29.918389] [<ffffffff8119ac05>] kobject_add_varg+0x41/0x4e
> <4>[ 29.919124] [<ffffffff8119b0d0>] kobject_add+0x89/0x8b
> <4>[ 29.919834] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.920474] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.921191] [<ffffffff8119405c>] ? exact_lock+0x0/0x14
> <4>[ 29.921955] [<ffffffff810e71d8>] ? __kmalloc+0x106/0x118
> <4>[ 29.922690] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.923578] [<ffffffff8119a98a>] ? kobject_get+0x1a/0x22
> <4>[ 29.924324] [<ffffffff81209ea0>] ? get_device+0x14/0x1a
> <4>[ 29.925178] [<ffffffff8120a451>] device_add+0xdc/0x60c
> <4>[ 29.925873] [<ffffffff8120ee8e>] ? kobj_map+0x68/0x12a
> <4>[ 29.926567] [<ffffffff8114082b>] register_disk+0x3c/0x11d
> <4>[ 29.927195] [<ffffffff81194db7>] add_disk+0xb8/0x119
> <4>[ 29.927821] [<ffffffffa000125b>] backend_changed+0x441/0x45b
> [xen_blkfront]
> <4>[ 29.928566] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.929211] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> <4>[ 29.929855] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> <4>[ 29.930490] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
> <4>[ 29.931151] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.931787] [<ffffffff8105c35e>] kthread+0x69/0x71
> <4>[ 29.932550] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> <4>[ 29.933201] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> <4>[ 29.933834] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> <5>[ 29.966562] SCSI subsystem initialized
> <0>[ 29.984037] ------------[ cut here ]------------
> <2>[ 29.984721] kernel BUG at fs/sysfs/group.c:65!
> <0>[ 29.985357] invalid opcode: 0000 [#1] PREEMPT SMP
> <0>[ 29.987151] last sysfs file: /sys/class/firmware/timeout
> <4>[ 29.987978] CPU 0
> <4>[ 29.988014] Modules linked in: sd_mod scsi_mod ext3 jbd mbcache
> 8139cp mii platform_pci xen_netfront xen_blkfront
> <4>[ 29.988014]
> <4>[ 29.988014] Pid: 20, comm: xenwatch Tainted: G W 2.6.34-pvhvm
> #10 /HVM domU
> <4>[ 29.988014] RIP: 0010:[<ffffffff8114883a>] [<ffffffff8114883a>]
> internal_create_group+0x2a/0x127
> <4>[ 29.988014] RSP: 0018:ffff88001f97fd00 EFLAGS: 00010246
> <4>[ 29.988014] RAX: 00000000ffffffef RBX: ffff88001e200870 RCX:
> ffffffff8120a927
> <4>[ 29.988014] RDX: ffffffff81640280 RSI: 0000000000000000 RDI:
> ffff88001e200870
> <4>[ 29.988014] RBP: ffff88001f97fd40 R08: ffff88001f97e000 R09:
> ffff880001a14c20
> <4>[ 29.988014] R10: ffff88001f97fca0 R11: 0000000000000000 R12:
> ffff88001e0e88a8
> <4>[ 29.988014] R13: 000000000000000f R14: ffff88001e200860 R15:
> ffffffff81640280
> <4>[ 29.988014] FS: 0000000000000000(0000) GS:ffff880001a00000(0000)
> knlGS:0000000000000000
> <4>[ 29.988014] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> <4>[ 29.988014] CR2: 00007f151c82200f CR3: 000000001e7bc000 CR4:
> 00000000000006b0
> <4>[ 29.988014] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> <4>[ 29.988014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> <4>[ 29.988014] Process xenwatch (pid: 20, threadinfo ffff88001f97e000,
> task ffff88001f975b80)
> <0>[ 29.988014] Stack:
> <4>[ 29.988014] 0000000000000000 0000000089700e79 ffff88001f97fd70
> ffff88001e200800
> <4>[ 29.988014] <0> ffff88001e0e88a8 000000000000000f ffff88001e200860
> 0000000000000000
> <4>[ 29.988014] <0> ffff88001f97fd50 ffffffff81148958 ffff88001f97fd60
> ffffffff810a39fe
> <0>[ 29.988014] Call Trace:
> <4>[ 29.988014] [<ffffffff81148958>] sysfs_create_group+0xe/0x12
> <4>[ 29.988014] [<ffffffff810a39fe>] blk_trace_init_sysfs+0x14/0x16
> <4>[ 29.988014] [<ffffffff8118ff11>] blk_register_queue+0x42/0xc8
> <4>[ 29.988014] [<ffffffff81194dbf>] add_disk+0xc0/0x119
> <4>[ 29.988014] [<ffffffffa000125b>] backend_changed+0x441/0x45b
> [xen_blkfront]
> <4>[ 29.988014] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.988014] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> <4>[ 29.988014] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> <4>[ 29.988014] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
> <4>[ 29.988014] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.988014] [<ffffffff8105c35e>] kthread+0x69/0x71
> <4>[ 29.988014] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> <4>[ 29.988014] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> <4>[ 29.988014] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> <0>[ 29.988014] Code: c3 55 48 89 e5 41 57 49 89 d7 41 56 41 55 41 54 53
> 48 89 fb 48 83 ec 18 48 85 ff 89 75 c0 74 0b 85 f6 75 11 48 83 7f 30 00 75
> 04 <0f> 0b eb fe 83 7d c0 00 74 11 48 83 7b 30 00 41 bd ea ff ff ff
> <1>[ 29.988014] RIP [<ffffffff8114883a>]
> internal_create_group+0x2a/0x127
> <4>[ 29.988014] RSP <ffff88001f97fd00>
> <4>[ 30.132020] ---[ end trace 3f99b54d0b8663bf ]---
>
> Then when I do an fdisk on block device 202:0, I get this:
>
> <4>[ 223.840262] ------------[ cut here ]------------
> <4>[ 223.841061] WARNING: at fs/fs-writeback.c:1105
> __mark_inode_dirty+0xed/0x130()
> <4>[ 223.842008] Hardware name: HVM domU
> <4>[ 223.842585] Modules linked in: ata_piix libata sd_mod scsi_mod ext3
> jbd mbcache 8139cp mii platform_pci xen_netfront xen_blkfront
> <4>[ 223.847533] Pid: 875, comm: busybox Tainted: G D W 2.6.34-pvhvm
> #10
> <4>[ 223.848259] Call Trace:
> <4>[ 223.848994] [<ffffffff8110e33a>] ? __mark_inode_dirty+0xed/0x130
> <4>[ 223.849761] [<ffffffff810424fa>] warn_slowpath_common+0x77/0x8f
> <4>[ 223.850651] [<ffffffff81042521>] warn_slowpath_null+0xf/0x11
> <4>[ 223.851509] [<ffffffff8110e33a>] __mark_inode_dirty+0xed/0x130
> <4>[ 223.852195] [<ffffffff810b55ac>] ? sync_page_killable+0x0/0x3e
> <4>[ 223.853449] [<ffffffff811041cd>] mark_inode_dirty_sync+0xe/0x10
> <4>[ 223.854260] [<ffffffff81105554>] touch_atime+0xfb/0x120
> <4>[ 223.855144] [<ffffffff810b41a6>] file_accessed+0x17/0x19
> <4>[ 223.855956] [<ffffffff810b5ac4>] generic_file_aio_read+0x4da/0x53e
> <4>[ 223.856686] [<ffffffff810f27c7>] do_sync_read+0xc2/0x106
> <4>[ 223.857307] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> <4>[ 223.858023] [<ffffffff8115aca4>] ?
> security_file_permission+0x11/0x13
> <4>[ 223.858993] [<ffffffff810f2e9d>] vfs_read+0xa8/0x102
> <4>[ 223.859658] [<ffffffff810f313f>] sys_read+0x47/0x6d
> <4>[ 223.860379] [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
> <4>[ 223.861296] ---[ end trace 3f99b54d0b8663c0 ]---
> <3>[ 223.861934] bdi-block not registered
>
> Reading from the block device returns some random data: (here I am doing
> an fdisk on the block device 202:0), and it's returning the wrong disk
> size. The virtual disk is 15GiB.
>
> Disk /dev/xvda: 4393 MB, 4393723904 bytes
> 255 heads, 63 sectors/track, 534 cylinders, total 8581492 sectors
> Units = sectors of 1 * 512 = 512 bytes
>
> Disk /dev/xvda doesn't contain a valid partition table
>
>
> If I unplug the nics, there is no error,
>
> [ 29.738321] Initialising Xen virtual ethernet driver.
> [ 29.748844] alloc irq_desc for 28 on node -1
> [ 29.748847] alloc kstat_irqs on node -1
> [ 29.748866] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level,
> low) -> IRQ 28
> [ 29.750216] Grant table initialized
> [ 29.753307] vif vif-0: 2 parsing device/vif/0/mac
>
> 8130cp, as expected, is not attached to eth0. However, it seems
> xen-netfront cannot get the MAC address of eth0:
>
> eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> Is it something very obvious that I missed?
>
>
> Thanks!
>
> Leo
>
[-- Attachment #1.2: Type: text/html, Size: 31854 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PV HVM Linux drivers fail
2010-07-28 21:53 PV HVM Linux drivers fail Leo
2010-07-28 21:57 ` Leo
@ 2010-07-29 14:47 ` Stefano Stabellini
2010-07-29 16:44 ` [Xen-devel] " Leo
1 sibling, 1 reply; 9+ messages in thread
From: Stefano Stabellini @ 2010-07-29 14:47 UTC (permalink / raw)
To: Leo; +Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
[-- Attachment #1: Type: text/plain, Size: 13686 bytes --]
On Wed, 28 Jul 2010, Leo wrote:
> Hi,
>
> I don't see anyone having similar issues when running domU kernel in HVM. Hopefully it's just some very obvious stuff I
> missed.
>
> I am using the 2.6.34-pvhvm-v6 branch from git://xenbits.xen.org/people/sstabellini/linux-pvhvm. I compiled the kernel
> with just about everything as modules, including platform-pci, xen-blkfront and xen-netfront.
>
> When I use the kernel parameter xen_emul_unplug=ignore, both ata_piix and 8139cp drivers attach to the emulated devices
> and work just fine.
>
> When I unplug either the nic or the ide-disk, the loading order of the 3 modules makes some difference. If I load
> platform-pci first before either of the frontend drivers, I get XENBUS Timeout. Note that loading the platform-pci module
> doesn't cause any error, it is loading the frontend drivers when I see this error: (This happens when I load the
> xen-netfront driver. platform-pci is loaded at 58s. I also trimmed the wait time from 300s to 30s)
>
> [ 102.570177] Initialising Xen virtual ethernet driver.
> [ 107.676025] XENBUS: Waiting for devices to initialise: 25s...20s...15s...10s...5s...0s...
> [ 132.677038] XENBUS: Timeout connecting to device: device/vif/0 (local state 1, remote state 2)
>
> So I have to load the frontend drivers before platform-pci, and none of this error like this occured. And because of that
> I cannot compile in all the three modules as they'll always be waiting to connect.
>
You are right about the module loading order: you need to load the PV
driver modules before platform-pci otherwise it won't find any xenbus
devices.
But you should be able to compile-in platform-pci, blkfront and netfront
and everything should work fine.
> However I get some other error. When I unplug ide-disks, I get this:
>
> <4>[ 29.842072] ------------[ cut here ]------------
> <4>[ 29.842785] WARNING: at fs/sysfs/dir.c:451 sysfs_add_one+0xac/0xc0()
> <4>[ 29.843434] Hardware name: HVM domU
> <4>[ 29.844070] sysfs: cannot create duplicate filename '/block/xvda'
> <4>[ 29.844713] Modules linked in: 8139cp mii platform_pci xen_netfront xen_blkfront
> <4>[ 29.847272] Pid: 20, comm: xenwatch Not tainted 2.6.34-pvhvm #10
> <4>[ 29.847945] Call Trace:
> <4>[ 29.856027] [<ffffffff81146ebc>] ? sysfs_add_one+0xac/0xc0
> <4>[ 29.856722] [<ffffffff810424fa>] warn_slowpath_common+0x77/0x8f
> <4>[ 29.857372] [<ffffffff81042587>] warn_slowpath_fmt+0x64/0x66
> <4>[ 29.858015] [<ffffffff8106e6c8>] ? do_raw_spin_unlock+0x17/0x1b
> <4>[ 29.858722] [<ffffffff81146e32>] ? sysfs_add_one+0x22/0xc0
> <4>[ 29.859358] [<ffffffff812b3b94>] ? __mutex_lock_common+0x229/0x243
> <4>[ 29.860034] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> <4>[ 29.860815] [<ffffffff81146d7a>] ? sysfs_pathname+0x37/0x3f
> <4>[ 29.861461] [<ffffffff81146d7a>] ? sysfs_pathname+0x37/0x3f
> <4>[ 29.862126] [<ffffffff81146ebc>] sysfs_add_one+0xac/0xc0
> <4>[ 29.862768] [<ffffffff811475f1>] create_dir+0x58/0x87
> <4>[ 29.863393] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> <4>[ 29.864092] [<ffffffff81147658>] sysfs_create_dir+0x38/0x4f
> <4>[ 29.864833] [<ffffffff812b49f8>] ? _raw_spin_unlock+0x2d/0x38
> <4>[ 29.865525] [<ffffffff8119aa6d>] kobject_add_internal+0xdb/0x19b
> <4>[ 29.866186] [<ffffffff8119ac05>] kobject_add_varg+0x41/0x4e
> <4>[ 29.866858] [<ffffffff8119b0d0>] kobject_add+0x89/0x8b
> <4>[ 29.867590] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.868280] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.868936] [<ffffffff8119405c>] ? exact_lock+0x0/0x14
> <4>[ 29.869574] [<ffffffff810e71d8>] ? __kmalloc+0x106/0x118
> <4>[ 29.870232] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.870866] [<ffffffff8119a98a>] ? kobject_get+0x1a/0x22
> <4>[ 29.871510] [<ffffffff81209ea0>] ? get_device+0x14/0x1a
> <4>[ 29.872209] [<ffffffff8120a451>] device_add+0xdc/0x60c
> <4>[ 29.872866] [<ffffffff8120ee8e>] ? kobj_map+0x68/0x12a
> <4>[ 29.873506] [<ffffffff8114082b>] register_disk+0x3c/0x11d
> <4>[ 29.874240] [<ffffffff81194db7>] add_disk+0xb8/0x119
> <4>[ 29.874922] [<ffffffffa000125b>] backend_changed+0x441/0x45b [xen_blkfront]
> <4>[ 29.875604] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.876245] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> <4>[ 29.876864] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> <4>[ 29.877481] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
> <4>[ 29.878134] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.878886] [<ffffffff8105c35e>] kthread+0x69/0x71
> <4>[ 29.879517] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> <4>[ 29.880198] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> <4>[ 29.880923] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> <4>[ 29.908017] ---[ end trace 3f99b54d0b8663be ]---
> <3>[ 29.909904] kobject_add_internal failed for xvda with -EEXIST, don't try to register things with the same name in
> the same directory.
> <4>[ 29.911103] Pid: 20, comm: xenwatch Tainted: G W 2.6.34-pvhvm #10
> <4>[ 29.916378] Call Trace:
> <4>[ 29.917001] [<ffffffff8119a861>] ? kobject_put+0x47/0x4b
> <4>[ 29.917682] [<ffffffff8119aaeb>] kobject_add_internal+0x159/0x19b
> <4>[ 29.918389] [<ffffffff8119ac05>] kobject_add_varg+0x41/0x4e
> <4>[ 29.919124] [<ffffffff8119b0d0>] kobject_add+0x89/0x8b
> <4>[ 29.919834] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.920474] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.921191] [<ffffffff8119405c>] ? exact_lock+0x0/0x14
> <4>[ 29.921955] [<ffffffff810e71d8>] ? __kmalloc+0x106/0x118
> <4>[ 29.922690] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> <4>[ 29.923578] [<ffffffff8119a98a>] ? kobject_get+0x1a/0x22
> <4>[ 29.924324] [<ffffffff81209ea0>] ? get_device+0x14/0x1a
> <4>[ 29.925178] [<ffffffff8120a451>] device_add+0xdc/0x60c
> <4>[ 29.925873] [<ffffffff8120ee8e>] ? kobj_map+0x68/0x12a
> <4>[ 29.926567] [<ffffffff8114082b>] register_disk+0x3c/0x11d
> <4>[ 29.927195] [<ffffffff81194db7>] add_disk+0xb8/0x119
> <4>[ 29.927821] [<ffffffffa000125b>] backend_changed+0x441/0x45b [xen_blkfront]
> <4>[ 29.928566] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.929211] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> <4>[ 29.929855] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> <4>[ 29.930490] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
> <4>[ 29.931151] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.931787] [<ffffffff8105c35e>] kthread+0x69/0x71
> <4>[ 29.932550] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> <4>[ 29.933201] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> <4>[ 29.933834] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> <5>[ 29.966562] SCSI subsystem initialized
> <0>[ 29.984037] ------------[ cut here ]------------
> <2>[ 29.984721] kernel BUG at fs/sysfs/group.c:65!
> <0>[ 29.985357] invalid opcode: 0000 [#1] PREEMPT SMP
> <0>[ 29.987151] last sysfs file: /sys/class/firmware/timeout
> <4>[ 29.987978] CPU 0
> <4>[ 29.988014] Modules linked in: sd_mod scsi_mod ext3 jbd mbcache 8139cp mii platform_pci xen_netfront xen_blkfront
> <4>[ 29.988014]
> <4>[ 29.988014] Pid: 20, comm: xenwatch Tainted: G W 2.6.34-pvhvm #10 /HVM domU
> <4>[ 29.988014] RIP: 0010:[<ffffffff8114883a>] [<ffffffff8114883a>] internal_create_group+0x2a/0x127
> <4>[ 29.988014] RSP: 0018:ffff88001f97fd00 EFLAGS: 00010246
> <4>[ 29.988014] RAX: 00000000ffffffef RBX: ffff88001e200870 RCX: ffffffff8120a927
> <4>[ 29.988014] RDX: ffffffff81640280 RSI: 0000000000000000 RDI: ffff88001e200870
> <4>[ 29.988014] RBP: ffff88001f97fd40 R08: ffff88001f97e000 R09: ffff880001a14c20
> <4>[ 29.988014] R10: ffff88001f97fca0 R11: 0000000000000000 R12: ffff88001e0e88a8
> <4>[ 29.988014] R13: 000000000000000f R14: ffff88001e200860 R15: ffffffff81640280
> <4>[ 29.988014] FS: 0000000000000000(0000) GS:ffff880001a00000(0000) knlGS:0000000000000000
> <4>[ 29.988014] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> <4>[ 29.988014] CR2: 00007f151c82200f CR3: 000000001e7bc000 CR4: 00000000000006b0
> <4>[ 29.988014] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> <4>[ 29.988014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> <4>[ 29.988014] Process xenwatch (pid: 20, threadinfo ffff88001f97e000, task ffff88001f975b80)
> <0>[ 29.988014] Stack:
> <4>[ 29.988014] 0000000000000000 0000000089700e79 ffff88001f97fd70 ffff88001e200800
> <4>[ 29.988014] <0> ffff88001e0e88a8 000000000000000f ffff88001e200860 0000000000000000
> <4>[ 29.988014] <0> ffff88001f97fd50 ffffffff81148958 ffff88001f97fd60 ffffffff810a39fe
> <0>[ 29.988014] Call Trace:
> <4>[ 29.988014] [<ffffffff81148958>] sysfs_create_group+0xe/0x12
> <4>[ 29.988014] [<ffffffff810a39fe>] blk_trace_init_sysfs+0x14/0x16
> <4>[ 29.988014] [<ffffffff8118ff11>] blk_register_queue+0x42/0xc8
> <4>[ 29.988014] [<ffffffff81194dbf>] add_disk+0xc0/0x119
> <4>[ 29.988014] [<ffffffffa000125b>] backend_changed+0x441/0x45b [xen_blkfront]
> <4>[ 29.988014] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.988014] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> <4>[ 29.988014] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> <4>[ 29.988014] [<ffffffff8105c560>] ? autoremove_wake_function+0x0/0x38
> <4>[ 29.988014] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> <4>[ 29.988014] [<ffffffff8105c35e>] kthread+0x69/0x71
> <4>[ 29.988014] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> <4>[ 29.988014] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> <4>[ 29.988014] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> <0>[ 29.988014] Code: c3 55 48 89 e5 41 57 49 89 d7 41 56 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 89 75 c0 74 0b 85
> f6 75 11 48 83 7f 30 00 75 04 <0f> 0b eb fe 83 7d c0 00 74 11 48 83 7b 30 00 41 bd ea ff ff ff
> <1>[ 29.988014] RIP [<ffffffff8114883a>] internal_create_group+0x2a/0x127
> <4>[ 29.988014] RSP <ffff88001f97fd00>
> <4>[ 30.132020] ---[ end trace 3f99b54d0b8663bf ]---
>
> Then when I do an fdisk on block device 202:0, I get this:
>
> <4>[ 223.840262] ------------[ cut here ]------------
> <4>[ 223.841061] WARNING: at fs/fs-writeback.c:1105 __mark_inode_dirty+0xed/0x130()
> <4>[ 223.842008] Hardware name: HVM domU
> <4>[ 223.842585] Modules linked in: ata_piix libata sd_mod scsi_mod ext3 jbd mbcache 8139cp mii platform_pci xen_netfront
> xen_blkfront
> <4>[ 223.847533] Pid: 875, comm: busybox Tainted: G D W 2.6.34-pvhvm #10
> <4>[ 223.848259] Call Trace:
> <4>[ 223.848994] [<ffffffff8110e33a>] ? __mark_inode_dirty+0xed/0x130
> <4>[ 223.849761] [<ffffffff810424fa>] warn_slowpath_common+0x77/0x8f
> <4>[ 223.850651] [<ffffffff81042521>] warn_slowpath_null+0xf/0x11
> <4>[ 223.851509] [<ffffffff8110e33a>] __mark_inode_dirty+0xed/0x130
> <4>[ 223.852195] [<ffffffff810b55ac>] ? sync_page_killable+0x0/0x3e
> <4>[ 223.853449] [<ffffffff811041cd>] mark_inode_dirty_sync+0xe/0x10
> <4>[ 223.854260] [<ffffffff81105554>] touch_atime+0xfb/0x120
> <4>[ 223.855144] [<ffffffff810b41a6>] file_accessed+0x17/0x19
> <4>[ 223.855956] [<ffffffff810b5ac4>] generic_file_aio_read+0x4da/0x53e
> <4>[ 223.856686] [<ffffffff810f27c7>] do_sync_read+0xc2/0x106
> <4>[ 223.857307] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> <4>[ 223.858023] [<ffffffff8115aca4>] ? security_file_permission+0x11/0x13
> <4>[ 223.858993] [<ffffffff810f2e9d>] vfs_read+0xa8/0x102
> <4>[ 223.859658] [<ffffffff810f313f>] sys_read+0x47/0x6d
> <4>[ 223.860379] [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
> <4>[ 223.861296] ---[ end trace 3f99b54d0b8663c0 ]---
> <3>[ 223.861934] bdi-block not registered
>
> Reading from the block device returns some random data: (here I am doing an fdisk on the block device 202:0), and it's
> returning the wrong disk size. The virtual disk is 15GiB.
>
> Disk /dev/xvda: 4393 MB, 4393723904 bytes
> 255 heads, 63 sectors/track, 534 cylinders, total 8581492 sectors
> Units = sectors of 1 * 512 = 512 bytes
>
> Disk /dev/xvda doesn't contain a valid partition table
>
>
> If I unplug the nics, there is no error,
>
> [ 29.738321] Initialising Xen virtual ethernet driver.
> [ 29.748844] alloc irq_desc for 28 on node -1
> [ 29.748847] alloc kstat_irqs on node -1
> [ 29.748866] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
> [ 29.750216] Grant table initialized
> [ 29.753307] vif vif-0: 2 parsing device/vif/0/mac
>
> 8130cp, as expected, is not attached to eth0. However, it seems xen-netfront cannot get the MAC address of eth0:
>
> eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> Is it something very obvious that I missed?
this is an actual bug, I have a fix for it in a new branch (that we are
trying to merge with linux-next as we speak):
2.6.35-rc5-pvhvm-v6
the problem is due to a bug in the way blkfront names devices that have
major numbers different from XENVBD.
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PV HVM Linux drivers fail
2010-07-29 14:47 ` Stefano Stabellini
@ 2010-07-29 16:44 ` Leo
2010-07-30 14:34 ` Stefano Stabellini
0 siblings, 1 reply; 9+ messages in thread
From: Leo @ 2010-07-29 16:44 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
[-- Attachment #1.1: Type: text/plain, Size: 14493 bytes --]
Thanks for the info Stefano.
When I compile-in the three devices, it always get into the XENBUS wait
loop. Drivers loading order has always been a mystery to me (though I
haven't spent much time on that.)
I am waiting for the new branch for the fix then. Does the bug also affect
netfront to not able to get the MAC address? It's also what I'm seeing as
well, described near the end of my message.
Thank you!
Leo
On Thu, Jul 29, 2010 at 7:47 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 28 Jul 2010, Leo wrote:
> > Hi,
> >
> > I don't see anyone having similar issues when running domU kernel in
> HVM. Hopefully it's just some very obvious stuff I
> > missed.
> >
> > I am using the 2.6.34-pvhvm-v6 branch from git://
> xenbits.xen.org/people/sstabellini/linux-pvhvm. I compiled the kernel
> > with just about everything as modules, including platform-pci,
> xen-blkfront and xen-netfront.
> >
> > When I use the kernel parameter xen_emul_unplug=ignore, both ata_piix and
> 8139cp drivers attach to the emulated devices
> > and work just fine.
> >
> > When I unplug either the nic or the ide-disk, the loading order of the 3
> modules makes some difference. If I load
> > platform-pci first before either of the frontend drivers, I get XENBUS
> Timeout. Note that loading the platform-pci module
> > doesn't cause any error, it is loading the frontend drivers when I see
> this error: (This happens when I load the
> > xen-netfront driver. platform-pci is loaded at 58s. I also trimmed the
> wait time from 300s to 30s)
> >
> > [ 102.570177] Initialising Xen virtual ethernet driver.
> > [ 107.676025] XENBUS: Waiting for devices to initialise:
> 25s...20s...15s...10s...5s...0s...
> > [ 132.677038] XENBUS: Timeout connecting to device: device/vif/0 (local
> state 1, remote state 2)
> >
> > So I have to load the frontend drivers before platform-pci, and none of
> this error like this occured. And because of that
> > I cannot compile in all the three modules as they'll always be waiting to
> connect.
> >
>
> You are right about the module loading order: you need to load the PV
> driver modules before platform-pci otherwise it won't find any xenbus
> devices.
> But you should be able to compile-in platform-pci, blkfront and netfront
> and everything should work fine.
>
>
> > However I get some other error. When I unplug ide-disks, I get this:
> >
> > <4>[ 29.842072] ------------[ cut here ]------------
> > <4>[ 29.842785] WARNING: at fs/sysfs/dir.c:451
> sysfs_add_one+0xac/0xc0()
> > <4>[ 29.843434] Hardware name: HVM domU
> > <4>[ 29.844070] sysfs: cannot create duplicate filename '/block/xvda'
> > <4>[ 29.844713] Modules linked in: 8139cp mii platform_pci xen_netfront
> xen_blkfront
> > <4>[ 29.847272] Pid: 20, comm: xenwatch Not tainted 2.6.34-pvhvm #10
> > <4>[ 29.847945] Call Trace:
> > <4>[ 29.856027] [<ffffffff81146ebc>] ? sysfs_add_one+0xac/0xc0
> > <4>[ 29.856722] [<ffffffff810424fa>] warn_slowpath_common+0x77/0x8f
> > <4>[ 29.857372] [<ffffffff81042587>] warn_slowpath_fmt+0x64/0x66
> > <4>[ 29.858015] [<ffffffff8106e6c8>] ? do_raw_spin_unlock+0x17/0x1b
> > <4>[ 29.858722] [<ffffffff81146e32>] ? sysfs_add_one+0x22/0xc0
> > <4>[ 29.859358] [<ffffffff812b3b94>] ? __mutex_lock_common+0x229/0x243
> > <4>[ 29.860034] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> > <4>[ 29.860815] [<ffffffff81146d7a>] ? sysfs_pathname+0x37/0x3f
> > <4>[ 29.861461] [<ffffffff81146d7a>] ? sysfs_pathname+0x37/0x3f
> > <4>[ 29.862126] [<ffffffff81146ebc>] sysfs_add_one+0xac/0xc0
> > <4>[ 29.862768] [<ffffffff811475f1>] create_dir+0x58/0x87
> > <4>[ 29.863393] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> > <4>[ 29.864092] [<ffffffff81147658>] sysfs_create_dir+0x38/0x4f
> > <4>[ 29.864833] [<ffffffff812b49f8>] ? _raw_spin_unlock+0x2d/0x38
> > <4>[ 29.865525] [<ffffffff8119aa6d>] kobject_add_internal+0xdb/0x19b
> > <4>[ 29.866186] [<ffffffff8119ac05>] kobject_add_varg+0x41/0x4e
> > <4>[ 29.866858] [<ffffffff8119b0d0>] kobject_add+0x89/0x8b
> > <4>[ 29.867590] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> > <4>[ 29.868280] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> > <4>[ 29.868936] [<ffffffff8119405c>] ? exact_lock+0x0/0x14
> > <4>[ 29.869574] [<ffffffff810e71d8>] ? __kmalloc+0x106/0x118
> > <4>[ 29.870232] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> > <4>[ 29.870866] [<ffffffff8119a98a>] ? kobject_get+0x1a/0x22
> > <4>[ 29.871510] [<ffffffff81209ea0>] ? get_device+0x14/0x1a
> > <4>[ 29.872209] [<ffffffff8120a451>] device_add+0xdc/0x60c
> > <4>[ 29.872866] [<ffffffff8120ee8e>] ? kobj_map+0x68/0x12a
> > <4>[ 29.873506] [<ffffffff8114082b>] register_disk+0x3c/0x11d
> > <4>[ 29.874240] [<ffffffff81194db7>] add_disk+0xb8/0x119
> > <4>[ 29.874922] [<ffffffffa000125b>] backend_changed+0x441/0x45b
> [xen_blkfront]
> > <4>[ 29.875604] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> > <4>[ 29.876245] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> > <4>[ 29.876864] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> > <4>[ 29.877481] [<ffffffff8105c560>] ?
> autoremove_wake_function+0x0/0x38
> > <4>[ 29.878134] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> > <4>[ 29.878886] [<ffffffff8105c35e>] kthread+0x69/0x71
> > <4>[ 29.879517] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> > <4>[ 29.880198] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> > <4>[ 29.880923] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> > <4>[ 29.908017] ---[ end trace 3f99b54d0b8663be ]---
> > <3>[ 29.909904] kobject_add_internal failed for xvda with -EEXIST,
> don't try to register things with the same name in
> > the same directory.
> > <4>[ 29.911103] Pid: 20, comm: xenwatch Tainted: G W
> 2.6.34-pvhvm #10
> > <4>[ 29.916378] Call Trace:
> > <4>[ 29.917001] [<ffffffff8119a861>] ? kobject_put+0x47/0x4b
> > <4>[ 29.917682] [<ffffffff8119aaeb>] kobject_add_internal+0x159/0x19b
> > <4>[ 29.918389] [<ffffffff8119ac05>] kobject_add_varg+0x41/0x4e
> > <4>[ 29.919124] [<ffffffff8119b0d0>] kobject_add+0x89/0x8b
> > <4>[ 29.919834] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> > <4>[ 29.920474] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> > <4>[ 29.921191] [<ffffffff8119405c>] ? exact_lock+0x0/0x14
> > <4>[ 29.921955] [<ffffffff810e71d8>] ? __kmalloc+0x106/0x118
> > <4>[ 29.922690] [<ffffffff812098b6>] ? kzalloc+0xf/0x11
> > <4>[ 29.923578] [<ffffffff8119a98a>] ? kobject_get+0x1a/0x22
> > <4>[ 29.924324] [<ffffffff81209ea0>] ? get_device+0x14/0x1a
> > <4>[ 29.925178] [<ffffffff8120a451>] device_add+0xdc/0x60c
> > <4>[ 29.925873] [<ffffffff8120ee8e>] ? kobj_map+0x68/0x12a
> > <4>[ 29.926567] [<ffffffff8114082b>] register_disk+0x3c/0x11d
> > <4>[ 29.927195] [<ffffffff81194db7>] add_disk+0xb8/0x119
> > <4>[ 29.927821] [<ffffffffa000125b>] backend_changed+0x441/0x45b
> [xen_blkfront]
> > <4>[ 29.928566] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> > <4>[ 29.929211] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> > <4>[ 29.929855] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> > <4>[ 29.930490] [<ffffffff8105c560>] ?
> autoremove_wake_function+0x0/0x38
> > <4>[ 29.931151] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> > <4>[ 29.931787] [<ffffffff8105c35e>] kthread+0x69/0x71
> > <4>[ 29.932550] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> > <4>[ 29.933201] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> > <4>[ 29.933834] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> > <5>[ 29.966562] SCSI subsystem initialized
> > <0>[ 29.984037] ------------[ cut here ]------------
> > <2>[ 29.984721] kernel BUG at fs/sysfs/group.c:65!
> > <0>[ 29.985357] invalid opcode: 0000 [#1] PREEMPT SMP
> > <0>[ 29.987151] last sysfs file: /sys/class/firmware/timeout
> > <4>[ 29.987978] CPU 0
> > <4>[ 29.988014] Modules linked in: sd_mod scsi_mod ext3 jbd mbcache
> 8139cp mii platform_pci xen_netfront xen_blkfront
> > <4>[ 29.988014]
> > <4>[ 29.988014] Pid: 20, comm: xenwatch Tainted: G W
> 2.6.34-pvhvm #10 /HVM domU
> > <4>[ 29.988014] RIP: 0010:[<ffffffff8114883a>] [<ffffffff8114883a>]
> internal_create_group+0x2a/0x127
> > <4>[ 29.988014] RSP: 0018:ffff88001f97fd00 EFLAGS: 00010246
> > <4>[ 29.988014] RAX: 00000000ffffffef RBX: ffff88001e200870 RCX:
> ffffffff8120a927
> > <4>[ 29.988014] RDX: ffffffff81640280 RSI: 0000000000000000 RDI:
> ffff88001e200870
> > <4>[ 29.988014] RBP: ffff88001f97fd40 R08: ffff88001f97e000 R09:
> ffff880001a14c20
> > <4>[ 29.988014] R10: ffff88001f97fca0 R11: 0000000000000000 R12:
> ffff88001e0e88a8
> > <4>[ 29.988014] R13: 000000000000000f R14: ffff88001e200860 R15:
> ffffffff81640280
> > <4>[ 29.988014] FS: 0000000000000000(0000) GS:ffff880001a00000(0000)
> knlGS:0000000000000000
> > <4>[ 29.988014] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > <4>[ 29.988014] CR2: 00007f151c82200f CR3: 000000001e7bc000 CR4:
> 00000000000006b0
> > <4>[ 29.988014] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> > <4>[ 29.988014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> > <4>[ 29.988014] Process xenwatch (pid: 20, threadinfo ffff88001f97e000,
> task ffff88001f975b80)
> > <0>[ 29.988014] Stack:
> > <4>[ 29.988014] 0000000000000000 0000000089700e79 ffff88001f97fd70
> ffff88001e200800
> > <4>[ 29.988014] <0> ffff88001e0e88a8 000000000000000f ffff88001e200860
> 0000000000000000
> > <4>[ 29.988014] <0> ffff88001f97fd50 ffffffff81148958 ffff88001f97fd60
> ffffffff810a39fe
> > <0>[ 29.988014] Call Trace:
> > <4>[ 29.988014] [<ffffffff81148958>] sysfs_create_group+0xe/0x12
> > <4>[ 29.988014] [<ffffffff810a39fe>] blk_trace_init_sysfs+0x14/0x16
> > <4>[ 29.988014] [<ffffffff8118ff11>] blk_register_queue+0x42/0xc8
> > <4>[ 29.988014] [<ffffffff81194dbf>] add_disk+0xc0/0x119
> > <4>[ 29.988014] [<ffffffffa000125b>] backend_changed+0x441/0x45b
> [xen_blkfront]
> > <4>[ 29.988014] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> > <4>[ 29.988014] [<ffffffff811ec5ac>] otherend_changed+0x82/0x8b
> > <4>[ 29.988014] [<ffffffff811eb7ea>] xenwatch_thread+0x118/0x152
> > <4>[ 29.988014] [<ffffffff8105c560>] ?
> autoremove_wake_function+0x0/0x38
> > <4>[ 29.988014] [<ffffffff811eb6d2>] ? xenwatch_thread+0x0/0x152
> > <4>[ 29.988014] [<ffffffff8105c35e>] kthread+0x69/0x71
> > <4>[ 29.988014] [<ffffffff8100aa04>] kernel_thread_helper+0x4/0x10
> > <4>[ 29.988014] [<ffffffff8105c2f5>] ? kthread+0x0/0x71
> > <4>[ 29.988014] [<ffffffff8100aa00>] ? kernel_thread_helper+0x0/0x10
> > <0>[ 29.988014] Code: c3 55 48 89 e5 41 57 49 89 d7 41 56 41 55 41 54
> 53 48 89 fb 48 83 ec 18 48 85 ff 89 75 c0 74 0b 85
> > f6 75 11 48 83 7f 30 00 75 04 <0f> 0b eb fe 83 7d c0 00 74 11 48 83 7b 30
> 00 41 bd ea ff ff ff
> > <1>[ 29.988014] RIP [<ffffffff8114883a>]
> internal_create_group+0x2a/0x127
> > <4>[ 29.988014] RSP <ffff88001f97fd00>
> > <4>[ 30.132020] ---[ end trace 3f99b54d0b8663bf ]---
> >
> > Then when I do an fdisk on block device 202:0, I get this:
> >
> > <4>[ 223.840262] ------------[ cut here ]------------
> > <4>[ 223.841061] WARNING: at fs/fs-writeback.c:1105
> __mark_inode_dirty+0xed/0x130()
> > <4>[ 223.842008] Hardware name: HVM domU
> > <4>[ 223.842585] Modules linked in: ata_piix libata sd_mod scsi_mod ext3
> jbd mbcache 8139cp mii platform_pci xen_netfront
> > xen_blkfront
> > <4>[ 223.847533] Pid: 875, comm: busybox Tainted: G D W
> 2.6.34-pvhvm #10
> > <4>[ 223.848259] Call Trace:
> > <4>[ 223.848994] [<ffffffff8110e33a>] ? __mark_inode_dirty+0xed/0x130
> > <4>[ 223.849761] [<ffffffff810424fa>] warn_slowpath_common+0x77/0x8f
> > <4>[ 223.850651] [<ffffffff81042521>] warn_slowpath_null+0xf/0x11
> > <4>[ 223.851509] [<ffffffff8110e33a>] __mark_inode_dirty+0xed/0x130
> > <4>[ 223.852195] [<ffffffff810b55ac>] ? sync_page_killable+0x0/0x3e
> > <4>[ 223.853449] [<ffffffff811041cd>] mark_inode_dirty_sync+0xe/0x10
> > <4>[ 223.854260] [<ffffffff81105554>] touch_atime+0xfb/0x120
> > <4>[ 223.855144] [<ffffffff810b41a6>] file_accessed+0x17/0x19
> > <4>[ 223.855956] [<ffffffff810b5ac4>] generic_file_aio_read+0x4da/0x53e
> > <4>[ 223.856686] [<ffffffff810f27c7>] do_sync_read+0xc2/0x106
> > <4>[ 223.857307] [<ffffffff810e433d>] ? __raw_local_irq_save+0x22/0x28
> > <4>[ 223.858023] [<ffffffff8115aca4>] ?
> security_file_permission+0x11/0x13
> > <4>[ 223.858993] [<ffffffff810f2e9d>] vfs_read+0xa8/0x102
> > <4>[ 223.859658] [<ffffffff810f313f>] sys_read+0x47/0x6d
> > <4>[ 223.860379] [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
> > <4>[ 223.861296] ---[ end trace 3f99b54d0b8663c0 ]---
> > <3>[ 223.861934] bdi-block not registered
> >
> > Reading from the block device returns some random data: (here I am doing
> an fdisk on the block device 202:0), and it's
> > returning the wrong disk size. The virtual disk is 15GiB.
> >
> > Disk /dev/xvda: 4393 MB, 4393723904 bytes
> > 255 heads, 63 sectors/track, 534 cylinders, total 8581492 sectors
> > Units = sectors of 1 * 512 = 512 bytes
> >
> > Disk /dev/xvda doesn't contain a valid partition table
> >
> >
> > If I unplug the nics, there is no error,
> >
> > [ 29.738321] Initialising Xen virtual ethernet driver.
> > [ 29.748844] alloc irq_desc for 28 on node -1
> > [ 29.748847] alloc kstat_irqs on node -1
> > [ 29.748866] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level,
> low) -> IRQ 28
> > [ 29.750216] Grant table initialized
> > [ 29.753307] vif vif-0: 2 parsing device/vif/0/mac
> >
> > 8130cp, as expected, is not attached to eth0. However, it seems
> xen-netfront cannot get the MAC address of eth0:
> >
> > eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
> > BROADCAST MULTICAST MTU:1500 Metric:1
> > RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> >
> > Is it something very obvious that I missed?
>
> this is an actual bug, I have a fix for it in a new branch (that we are
> trying to merge with linux-next as we speak):
>
> 2.6.35-rc5-pvhvm-v6
>
> the problem is due to a bug in the way blkfront names devices that have
> major numbers different from XENVBD.
>
>
[-- Attachment #1.2: Type: text/html, Size: 17633 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PV HVM Linux drivers fail
2010-07-29 16:44 ` [Xen-devel] " Leo
@ 2010-07-30 14:34 ` Stefano Stabellini
2010-07-30 17:24 ` Leo
0 siblings, 1 reply; 9+ messages in thread
From: Stefano Stabellini @ 2010-07-30 14:34 UTC (permalink / raw)
To: Leo
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
Stefano Stabellini
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
On Thu, 29 Jul 2010, Leo wrote:
> Thanks for the info Stefano.
>
> When I compile-in the three devices, it always get into the XENBUS wait loop. Drivers loading order has always been a
> mystery to me (though I haven't spent much time on that.)
>
I took some time to read the code again and do few tests: it seems to me
that everything is working just fine in all cases. I am not sure what's
wrong with your setup but I can boot my guest with all three components
built-in or modules.
> I am waiting for the new branch for the fix then.
the new branch is ready, please give it a try and let me know.
> Does the bug also affect netfront to not able to get the MAC address?
> It's also what I'm seeing as well, described near the end of my message.
>
do you have a bridge correctly configured in your testbox?
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PV HVM Linux drivers fail
2010-07-30 14:34 ` Stefano Stabellini
@ 2010-07-30 17:24 ` Leo
2010-08-02 22:48 ` Leo
2010-08-03 10:22 ` [Xen-devel] " Stefano Stabellini
0 siblings, 2 replies; 9+ messages in thread
From: Leo @ 2010-07-30 17:24 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
[-- Attachment #1.1: Type: text/plain, Size: 1303 bytes --]
Hi Stefano,
Great. I will test the new code this weekend. I will also try to figure
how exactly the module initialization fails when all three are compiled in.
As for the network MAC address problem, the card is working just fine if I
don't unplug it and let 8139cp take over the device. So the bridge is set
up correctly, isn't it?
Thanks!
Leo
On Fri, Jul 30, 2010 at 7:34 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 29 Jul 2010, Leo wrote:
> > Thanks for the info Stefano.
> >
> > When I compile-in the three devices, it always get into the XENBUS wait
> loop. Drivers loading order has always been a
> > mystery to me (though I haven't spent much time on that.)
> >
>
> I took some time to read the code again and do few tests: it seems to me
> that everything is working just fine in all cases. I am not sure what's
> wrong with your setup but I can boot my guest with all three components
> built-in or modules.
>
> > I am waiting for the new branch for the fix then.
>
> the new branch is ready, please give it a try and let me know.
>
> > Does the bug also affect netfront to not able to get the MAC address?
> > It's also what I'm seeing as well, described near the end of my message.
> >
>
> do you have a bridge correctly configured in your testbox?
[-- Attachment #1.2: Type: text/html, Size: 1782 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PV HVM Linux drivers fail
2010-07-30 17:24 ` Leo
@ 2010-08-02 22:48 ` Leo
2010-08-03 0:17 ` Don Dutile
2010-08-03 10:22 ` [Xen-devel] " Stefano Stabellini
1 sibling, 1 reply; 9+ messages in thread
From: Leo @ 2010-08-02 22:48 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
[-- Attachment #1.1: Type: text/plain, Size: 1798 bytes --]
The code from 2.6.35-rc5-pvhvm-v6 works well! Thanks! I can access
/dev/hda created by blkfront. However, the netfront driver still can't
detect the MAC address of the nic if I unplug it. (If I don't unplug it,
8139cp works with the device just fine) And this code there seems to be no
dependency on the loading order of platform-pci and netfront/blkfront.
Leo
On Fri, Jul 30, 2010 at 10:24 AM, Leo <fencingleo@gmail.com> wrote:
> Hi Stefano,
>
> Great. I will test the new code this weekend. I will also try to figure
> how exactly the module initialization fails when all three are compiled in.
>
> As for the network MAC address problem, the card is working just fine if I
> don't unplug it and let 8139cp take over the device. So the bridge is set
> up correctly, isn't it?
>
>
> Thanks!
>
> Leo
>
>
> On Fri, Jul 30, 2010 at 7:34 AM, Stefano Stabellini <
> stefano.stabellini@eu.citrix.com> wrote:
>
>> On Thu, 29 Jul 2010, Leo wrote:
>> > Thanks for the info Stefano.
>> >
>> > When I compile-in the three devices, it always get into the XENBUS wait
>> loop. Drivers loading order has always been a
>> > mystery to me (though I haven't spent much time on that.)
>> >
>>
>> I took some time to read the code again and do few tests: it seems to me
>> that everything is working just fine in all cases. I am not sure what's
>> wrong with your setup but I can boot my guest with all three components
>> built-in or modules.
>>
>> > I am waiting for the new branch for the fix then.
>>
>> the new branch is ready, please give it a try and let me know.
>>
>> > Does the bug also affect netfront to not able to get the MAC address?
>> > It's also what I'm seeing as well, described near the end of my message.
>> >
>>
>> do you have a bridge correctly configured in your testbox?
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 2559 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PV HVM Linux drivers fail
2010-08-02 22:48 ` Leo
@ 2010-08-03 0:17 ` Don Dutile
0 siblings, 0 replies; 9+ messages in thread
From: Don Dutile @ 2010-08-03 0:17 UTC (permalink / raw)
To: Leo
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
Stefano Stabellini
Leo wrote:
> The code from 2.6.35-rc5-pvhvm-v6 works well! Thanks! I can access
> /dev/hda created by blkfront. However, the netfront driver still can't
> detect the MAC address of the nic if I unplug it. (If I don't unplug
> it, 8139cp works with the device just fine) And this code there seems
> to be no dependency on the loading order of platform-pci and
> netfront/blkfront.
>
>
> Leo
>
What does your xen guest config file look like?
a dump of it on this thread may be interesting...
> On Fri, Jul 30, 2010 at 10:24 AM, Leo <fencingleo@gmail.com
> <mailto:fencingleo@gmail.com>> wrote:
>
> Hi Stefano,
>
> Great. I will test the new code this weekend. I will also try to
> figure how exactly the module initialization fails when all three
> are compiled in.
>
> As for the network MAC address problem, the card is working just
> fine if I don't unplug it and let 8139cp take over the device. So
> the bridge is set up correctly, isn't it?
>
>
> Thanks!
>
> Leo
>
>
> On Fri, Jul 30, 2010 at 7:34 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com
> <mailto:stefano.stabellini@eu.citrix.com>> wrote:
>
> On Thu, 29 Jul 2010, Leo wrote:
> > Thanks for the info Stefano.
> >
> > When I compile-in the three devices, it always get into the
> XENBUS wait loop. Drivers loading order has always been a
> > mystery to me (though I haven't spent much time on that.)
> >
>
> I took some time to read the code again and do few tests: it
> seems to me
> that everything is working just fine in all cases. I am not sure
> what's
> wrong with your setup but I can boot my guest with all three
> components
> built-in or modules.
>
> > I am waiting for the new branch for the fix then.
>
> the new branch is ready, please give it a try and let me know.
>
> > Does the bug also affect netfront to not able to get the MAC
> address?
> > It's also what I'm seeing as well, described near the end of
> my message.
> >
>
> do you have a bridge correctly configured in your testbox?
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PV HVM Linux drivers fail
2010-07-30 17:24 ` Leo
2010-08-02 22:48 ` Leo
@ 2010-08-03 10:22 ` Stefano Stabellini
1 sibling, 0 replies; 9+ messages in thread
From: Stefano Stabellini @ 2010-08-03 10:22 UTC (permalink / raw)
To: Leo
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
Stefano Stabellini
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
On Fri, 30 Jul 2010, Leo wrote:
> Hi Stefano,
>
> Great. I will test the new code this weekend. I will also try to figure how exactly the module initialization fails when
> all three are compiled in.
>
> As for the network MAC address problem, the card is working just fine if I don't unplug it and let 8139cp take over the
> device. So the bridge is set up correctly, isn't it?
>
The scripts to setup a vif and a tap device are different at the moment,
so I wouldn't be so sure.
Can you execute 'brctl show' and post the output here?
If nothing shows up, could you try executing
/etc/xen/scripts/network-bridge start
to automatically setup a bridge (using your distro's config file would
be better) and run the test again?
Thanks,
Stefano
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-08-03 10:22 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-28 21:53 PV HVM Linux drivers fail Leo
2010-07-28 21:57 ` Leo
2010-07-29 14:47 ` Stefano Stabellini
2010-07-29 16:44 ` [Xen-devel] " Leo
2010-07-30 14:34 ` Stefano Stabellini
2010-07-30 17:24 ` Leo
2010-08-02 22:48 ` Leo
2010-08-03 0:17 ` Don Dutile
2010-08-03 10:22 ` [Xen-devel] " Stefano Stabellini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).