thr3ads.net - Xen devel - [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out) [Oct 2011]

If this information is useful, please help other people find it:
Share via:

Pasi Kärkkäinen

2011-Oct-31 18:49 UTC

[Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Hello,

While testing Xen 4.1.2 and HVM guests I noticed the following problem
with Fedora 16 HVM guests (using Linux 3.1.0 kernel in the VM):

The errors (call trace) happens pretty much immediately when there''s
some network traffic going on..

Simple "yum update" in the VM triggers the problem..


[    0.000000] Linux version 3.1.0-5.fc16.x86_64
(mockbuild@x86-10.phx2.fedoraproject.org) (gcc version 4.6.1 20111003 (Red Hat
4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC 2011
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
root=/dev/mapper/vg_f16test64hvm-lv_root ro rd.lvm.lv=vg_f16test64hvm/lv_root
rd.dm=0 SYSFONT=latarcyrheb-sun16 rhgb KEYTABLE=fi rd.md=0 rd.luks=0
rd.lvm.lv=vg_f16test64hvm/lv_swap LANG=en_US.UTF-8 console=ttyS0,38400
console=tty0
<snip>

[   28.998481] 8139cp 0000:00:03.0: eth0: link up, 100Mbps, full-duplex, lpa
0x05E1
[  149.712071] ------------[ cut here ]------------
[  149.717216] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xf0/0x150()
[  149.724709] Hardware name: HVM domU
[  149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit queue 0 timed out
[  149.735537] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state ip6_tables
nf_conntrack 81
39too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core joydev [last
unloaded: scsi_wait_scan]
[  149.768028] Pid: 0, comm: swapper Not tainted 3.1.0-5.fc16.x86_64 #1
[  149.774639] Call Trace:
[  149.777765]  <IRQ>  [<ffffffff81057a56>]
warn_slowpath_common+0x83/0x9b
[  149.784024]  [<ffffffff81057b11>] warn_slowpath_fmt+0x46/0x48
[  149.790141]  [<ffffffff813ef49d>] ? netif_tx_lock+0x4a/0x7c
[  149.799007]  [<ffffffff813ef613>] dev_watchdog+0xf0/0x150
[  149.806361]  [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
[  149.814392]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
[  149.821650]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
[  149.828926]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
[  149.836803]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
[  149.843422]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
[  149.850067]  [<ffffffff81010b45>] do_softirq+0x46/0x81
[  149.856760]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
[  149.863035]  [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
[  149.871144]  [<ffffffff814be76e>] xen_hvm_callback_vector+0x6e/0x80
[  149.879494]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
[  149.888220]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
[  149.894962]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
[  149.901461]  [<ffffffff814934ee>] rest_init+0x72/0x74
[  149.908949]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
[  149.916617]  [<ffffffff81b762c4>] x86_64_start_reservations+0xaf/0xb3
[  149.929148]  [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
[  149.936797]  [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
[  149.944336] ---[ end trace d8786cb7d6a57f8a ]---
[  149.950406] 8139cp 0000:00:03.0: eth0: Transmit timeout, status  d   3b   15
80ff
[  149.961879] ------------[ cut here ]------------
[  149.962245] WARNING: at kernel/softirq.c:159 _local_bh_enable_ip+0x44/0x8e()
[  149.962245] Hardware name: HVM domU
[  149.962245] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state ip6_tables
nf_conntrack 8139too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core
joydev [last unloaded: scsi_wait_scan]
[  149.962245] Pid: 0, comm: swapper Tainted: G        W   3.1.0-5.fc16.x86_64
#1
[  149.962245] Call Trace:
[  149.962245]  <IRQ>  [<ffffffff81057a56>]
warn_slowpath_common+0x83/0x9b
[  149.962245]  [<ffffffff813ce599>] ? skb_release_data+0xca/0xcf
[  149.962245]  [<ffffffff81057a88>] warn_slowpath_null+0x1a/0x1c
[  149.962245]  [<ffffffff8105d462>] _local_bh_enable_ip+0x44/0x8e
[  149.962245]  [<ffffffff8105d4ba>] local_bh_enable_ip+0xe/0x10
[  149.962245]  [<ffffffff814b5db4>] _raw_spin_unlock_bh+0x15/0x17
[  149.962245]  [<ffffffffa0053969>] destroy_conntrack+0x9d/0xdc
[nf_conntrack]
[  149.962245]  [<ffffffff813fa343>] nf_conntrack_destroy+0x19/0x1b
[  149.962245]  [<ffffffff813ce7ad>] skb_release_head_state+0xa7/0xef
[  149.962245]  [<ffffffff813ce5b1>] __kfree_skb+0x13/0x83
[  149.962245]  [<ffffffff813ce677>] consume_skb+0x56/0x6b
[  149.962245]  [<ffffffffa003c1b9>] cp_clean_rings+0xb4/0x114 [8139cp]
[  149.962245]  [<ffffffffa003c371>] cp_tx_timeout+0x88/0x10e [8139cp]
[  149.962245]  [<ffffffff813ef627>] dev_watchdog+0x104/0x150
[  149.962245]  [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
[  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
[  149.962245]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
[  149.962245]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
[  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
[  149.962245]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
[  149.962245]  [<ffffffff81010b45>] do_softirq+0x46/0x81
[  149.962245]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
[  149.962245]  [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
[  149.962245]  [<ffffffff814be76e>] xen_hvm_callback_vector+0x6e/0x80
[  149.962245]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
[  149.962245]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
[  149.962245]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
[  149.962245]  [<ffffffff814934ee>] rest_init+0x72/0x74
[  149.962245]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
[  149.962245]  [<ffffffff81b762c4>] x86_64_start_reservations+0xaf/0xb3
[  149.962245]  [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
[  149.962245]  [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
[  149.962245] ---[ end trace d8786cb7d6a57f8b ]---

Full guest kernel dmesg attached to this email.
The host is running F16 with Xen 4.1.2 and Linux 3.1.0 dom0 kernel.

Xen cfgfile for the HVM domain:

kernel = "hvmloader"
builder=''hvm''
device_model = ''qemu-dm''
name = "f16test64hvm"
memory = 1024
vcpus=1
pae=1
acpi=1
apic=1
vif = [ ''type=ioemu, mac=00:16:3f:03:01:14, bridge=virbr0'' ]
disk = [ ''phy:/dev/vg_f16/f16test64hvm,hda,w'',
''file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r''
]
boot=''cd''
xen_platform_pci=0
on_poweroff = ''destroy''
on_reboot   = ''restart''
on_crash    = ''restart''
sdl=0
vnc=1
vncpasswd=''''
stdvga=0
serial=''pty''
tsc_mode=0
usb=1
usbdevice=''tablet''
keymap=''fi''


Using "model=e1000" instead for the vif works OK.. no problems with
the emulated intel nic.

Any ideas what the problem with the emulated realtek nic? 

Thanks,


-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Oct-31 18:52 UTC

head link

Re: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

And added fedora xen mailinglist to CC aswell..

On Mon, Oct 31, 2011 at 08:49:07PM +0200, Pasi Kärkkäinen
wrote:> Hello,
> 
> While testing Xen 4.1.2 and HVM guests I noticed the following problem
> with Fedora 16 HVM guests (using Linux 3.1.0 kernel in the VM):
> 
> The errors (call trace) happens pretty much immediately when
there''s some network traffic going on..
> 
> Simple "yum update" in the VM triggers the problem..
> 
> 
> [    0.000000] Linux version 3.1.0-5.fc16.x86_64
(mockbuild@x86-10.phx2.fedoraproject.org) (gcc version 4.6.1 20111003 (Red Hat
4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC 2011
> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
root=/dev/mapper/vg_f16test64hvm-lv_root ro rd.lvm.lv=vg_f16test64hvm/lv_root
rd.dm=0 SYSFONT=latarcyrheb-sun16 rhgb KEYTABLE=fi rd.md=0 rd.luks=0
rd.lvm.lv=vg_f16test64hvm/lv_swap LANG=en_US.UTF-8 console=ttyS0,38400
console=tty0
> <snip>
> 
> [   28.998481] 8139cp 0000:00:03.0: eth0: link up, 100Mbps, full-duplex,
lpa 0x05E1
> [  149.712071] ------------[ cut here ]------------
> [  149.717216] WARNING: at net/sched/sch_generic.c:255
dev_watchdog+0xf0/0x150()
> [  149.724709] Hardware name: HVM domU
> [  149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit queue 0 timed out
> [  149.735537] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state
ip6_tables nf_conntrack 81
> 39too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core joydev [last
unloaded: scsi_wait_scan]
> [  149.768028] Pid: 0, comm: swapper Not tainted 3.1.0-5.fc16.x86_64 #1
> [  149.774639] Call Trace:
> [  149.777765]  <IRQ>  [<ffffffff81057a56>]
warn_slowpath_common+0x83/0x9b
> [  149.784024]  [<ffffffff81057b11>] warn_slowpath_fmt+0x46/0x48
> [  149.790141]  [<ffffffff813ef49d>] ? netif_tx_lock+0x4a/0x7c
> [  149.799007]  [<ffffffff813ef613>] dev_watchdog+0xf0/0x150
> [  149.806361]  [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
> [  149.814392]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [  149.821650]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
> [  149.828926]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
> [  149.836803]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [  149.843422]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
> [  149.850067]  [<ffffffff81010b45>] do_softirq+0x46/0x81
> [  149.856760]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
> [  149.863035]  [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
> [  149.871144]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
> [  149.879494]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
> [  149.888220]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
> [  149.894962]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> [  149.901461]  [<ffffffff814934ee>] rest_init+0x72/0x74
> [  149.908949]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
> [  149.916617]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
> [  149.929148]  [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
> [  149.936797]  [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
> [  149.944336] ---[ end trace d8786cb7d6a57f8a ]---
> [  149.950406] 8139cp 0000:00:03.0: eth0: Transmit timeout, status  d   3b 
15 80ff
> [  149.961879] ------------[ cut here ]------------
> [  149.962245] WARNING: at kernel/softirq.c:159
_local_bh_enable_ip+0x44/0x8e()
> [  149.962245] Hardware name: HVM domU
> [  149.962245] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state
ip6_tables nf_conntrack 8139too 8139cp ppdev parport_pc mii parport i2c_piix4
i2c_core joydev [last unloaded: scsi_wait_scan]
> [  149.962245] Pid: 0, comm: swapper Tainted: G        W  
3.1.0-5.fc16.x86_64 #1
> [  149.962245] Call Trace:
> [  149.962245]  <IRQ>  [<ffffffff81057a56>]
warn_slowpath_common+0x83/0x9b
> [  149.962245]  [<ffffffff813ce599>] ? skb_release_data+0xca/0xcf
> [  149.962245]  [<ffffffff81057a88>] warn_slowpath_null+0x1a/0x1c
> [  149.962245]  [<ffffffff8105d462>] _local_bh_enable_ip+0x44/0x8e
> [  149.962245]  [<ffffffff8105d4ba>] local_bh_enable_ip+0xe/0x10
> [  149.962245]  [<ffffffff814b5db4>] _raw_spin_unlock_bh+0x15/0x17
> [  149.962245]  [<ffffffffa0053969>] destroy_conntrack+0x9d/0xdc
[nf_conntrack]
> [  149.962245]  [<ffffffff813fa343>] nf_conntrack_destroy+0x19/0x1b
> [  149.962245]  [<ffffffff813ce7ad>] skb_release_head_state+0xa7/0xef
> [  149.962245]  [<ffffffff813ce5b1>] __kfree_skb+0x13/0x83
> [  149.962245]  [<ffffffff813ce677>] consume_skb+0x56/0x6b
> [  149.962245]  [<ffffffffa003c1b9>] cp_clean_rings+0xb4/0x114
[8139cp]
> [  149.962245]  [<ffffffffa003c371>] cp_tx_timeout+0x88/0x10e
[8139cp]
> [  149.962245]  [<ffffffff813ef627>] dev_watchdog+0x104/0x150
> [  149.962245]  [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
> [  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [  149.962245]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
> [  149.962245]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
> [  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [  149.962245]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
> [  149.962245]  [<ffffffff81010b45>] do_softirq+0x46/0x81
> [  149.962245]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
> [  149.962245]  [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
> [  149.962245]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
> [  149.962245]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
> [  149.962245]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
> [  149.962245]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> [  149.962245]  [<ffffffff814934ee>] rest_init+0x72/0x74
> [  149.962245]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
> [  149.962245]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
> [  149.962245]  [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
> [  149.962245]  [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
> [  149.962245] ---[ end trace d8786cb7d6a57f8b ]---
> 
> Full guest kernel dmesg attached to this email.
> The host is running F16 with Xen 4.1.2 and Linux 3.1.0 dom0 kernel.
> 
> Xen cfgfile for the HVM domain:
> 
> kernel = "hvmloader"
> builder=''hvm''
> device_model = ''qemu-dm''
> name = "f16test64hvm"
> memory = 1024
> vcpus=1
> pae=1
> acpi=1
> apic=1
> vif = [ ''type=ioemu, mac=00:16:3f:03:01:14,
bridge=virbr0'' ]
> disk = [ ''phy:/dev/vg_f16/f16test64hvm,hda,w'',
''file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r''
]
> boot=''cd''
> xen_platform_pci=0
> on_poweroff = ''destroy''
> on_reboot   = ''restart''
> on_crash    = ''restart''
> sdl=0
> vnc=1
> vncpasswd=''''
> stdvga=0
> serial=''pty''
> tsc_mode=0
> usb=1
> usbdevice=''tablet''
> keymap=''fi''
> 
> 
> Using "model=e1000" instead for the vif works OK.. no problems
with the emulated intel nic.
> 
> Any ideas what the problem with the emulated realtek nic? 
> 
> Thanks,
> 
> 
> -- Pasi
> 
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.1.0-5.fc16.x86_64
(mockbuild@x86-10.phx2.fedoraproject.org) (gcc version 4.6.1 20111003 (Red Hat
4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC 2011
> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
root=/dev/mapper/vg_f16test64hvm-lv_root ro rd.lvm.lv=vg_f16test64hvm/lv_root
rd.dm=0 SYSFONT=latarcyrheb-sun16 rhgb KEYTABLE=fi rd.md=0 rd.luks=0
rd.lvm.lv=vg_f16test64hvm/lv_swap LANG=en_US.UTF-8 console=ttyS0,38400
console=tty0
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
> [    0.000000]  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
> [    0.000000]  BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
> [    0.000000] Using x86 segment limits to approximate NX protection
> [    0.000000] DMI 2.4 present.
> [    0.000000] Hypervisor detected: Xen HVM
> [    0.000000] Xen version 4.1.
> [    0.000000] Xen Platform PCI: unrecognised magic value
> [    0.000000] No AGP bridge found
> [    0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000
> [    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new
0x7010600070106
> [    0.000000] found SMP MP-table at [ffff8800000fbc70] fbc70
> [    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
> [    0.000000] RAMDISK: 36608000 - 372fc000
> [    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
> [    0.000000] ACPI: XSDT 00000000fc0134b0 00034 (v01    Xen      HVM
00000000 HVML 00000000)
> [    0.000000] ACPI: FACP 00000000fc0132d0 000F4 (v04    Xen      HVM
00000000 HVML 00000000)
> [    0.000000] ACPI: DSDT 00000000fc003440 0FE05 (v02    Xen      HVM
00000000 INTL 20100528)
> [    0.000000] ACPI: FACS 00000000fc003400 00040
> [    0.000000] ACPI: APIC 00000000fc0133d0 000D8 (v02    Xen      HVM
00000000 HVML 00000000)
> [    0.000000] No NUMA configuration found
> [    0.000000] Faking a node at 0000000000000000-0000000040000000
> [    0.000000] Initmem setup node 0 0000000000000000-0000000040000000
> [    0.000000]   NODE_DATA [000000003ffec000 - 000000003fffffff]
> [    0.000000] Zone PFN ranges:
> [    0.000000]   DMA      0x00000010 -> 0x00001000
> [    0.000000]   DMA32    0x00001000 -> 0x00100000
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start PFN for each node
> [    0.000000] early_node_map[2] active PFN ranges
> [    0.000000]     0: 0x00000010 -> 0x0000009e
> [    0.000000]     0: 0x00000100 -> 0x00040000
> [    0.000000] ACPI: PM-Timer IO Port: 0xb008
> [    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
> [    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI
0-47
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
> [    0.000000] Using ACPI (MADT) for SMP configuration information
> [    0.000000] SMP: Allowing 15 CPUs, 14 hotplug CPUs
> [    0.000000] PM: Registered nosave memory: 000000000009e000 -
00000000000a0000
> [    0.000000] PM: Registered nosave memory: 00000000000a0000 -
00000000000e0000
> [    0.000000] PM: Registered nosave memory: 00000000000e0000 -
0000000000100000
> [    0.000000] Allocating PCI resources starting at 40000000 (gap:
40000000:bc000000)
> [    0.000000] Booting paravirtualized kernel on Xen HVM
> [    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:15
nr_node_ids:1
> [    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88003fc00000 s81024 r8192
d21376 u131072
> [    0.000000] Built 1 zonelists in Node order, mobility grouping on. 
Total pages: 257929
> [    0.000000] Policy zone: DMA32
> [    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
root=/dev/mapper/vg_f16test64hvm-lv_root ro rd.lvm.lv=vg_f16test64hvm/lv_root
rd.dm=0 SYSFONT=latarcyrheb-sun16 rhgb KEYTABLE=fi rd.md=0 rd.luks=0
rd.lvm.lv=vg_f16test64hvm/lv_swap LANG=en_US.UTF-8 console=ttyS0,38400
console=tty0
> [    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
> [    0.000000] Checking aperture...
> [    0.000000] No AGP bridge found
> [    0.000000] Memory: 1002468k/1048576k available (4867k kernel code, 456k
absent, 45652k reserved, 6782k data, 940k init)
> [    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0,
CPUs=15, Nodes=1
> [    0.000000] Hierarchical RCU implementation.
> [    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
> [    0.000000] NR_IRQS:16640 nr_irqs:1208 16
> [    0.000000] Xen HVM callback vector for event delivery is enabled
> [    0.000000] Console: colour VGA+ 80x25
> [    0.000000] console [tty0] enabled
> [    0.000000] console [ttyS0] enabled
> [    0.000000] allocated 8388608 bytes of page_cgroup
> [    0.000000] please try ''cgroup_disable=memory'' option
if you don''t want memory cgroups
> [    0.000000] Detected 2677.244 MHz processor.
> [    0.005999] Calibrating delay loop (skipped), value calculated using
timer frequency.. 5354.48 BogoMIPS (lpj=2677244)
> [    0.015004] pid_max: default: 32768 minimum: 301
> [    0.021037] Security Framework initialized
> [    0.025012] SELinux:  Initializing.
> [    0.030209] Dentry cache hash table entries: 131072 (order: 8, 1048576
bytes)
> [    0.039268] Inode-cache hash table entries: 65536 (order: 7, 524288
bytes)
> [    0.047115] Mount-cache hash table entries: 256
> [    0.051161] Initializing cgroup subsys cpuacct
> [    0.056007] Initializing cgroup subsys memory
> [    0.060013] Initializing cgroup subsys devices
> [    0.063998] Initializing cgroup subsys freezer
> [    0.071007] Initializing cgroup subsys net_cls
> [    0.077002] Initializing cgroup subsys blkio
> [    0.092016] Initializing cgroup subsys perf_event
> [    0.097110] CPU: Physical Processor ID: 0
> [    0.105998] CPU: Processor Core ID: 0
> [    0.114998] mce: CPU supports 9 MCE banks
> [    0.120027] SMP alternatives: switching to UP code
> [    0.137406] ACPI: Core revision 20110623
> [    0.154723] ftrace: allocating 25204 entries in 99 pages
> [    0.203985] Not enabling x2apic, Intr-remapping init failed.
> [    0.212983] Switched APIC routing to physical flat.
> [    0.227511] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
> [    0.247910] CPU0: Intel(R) Core(TM) i5 CPU       M 560  @ 2.67GHz
stepping 05
> [    0.266997] installing Xen timer for CPU 0
> [    0.279095] Performance Events: unsupported p6 CPU model 37 no PMU
driver, software events only.
> [    0.288052] NMI watchdog disabled (cpu0): hardware events not enabled
> [    0.289014] Brought up 1 CPUs
> [    0.289980] Total of 1 processors activated (5354.48 BogoMIPS).
> [    0.295080] devtmpfs: initialized
> [    0.334074] atomic64 test passed for x86-64 platform with CX8 and with
SSE
> [    0.335009] RTC time: 18:48:31, date: 10/31/11
> [    0.336031] NET: Registered protocol family 16
> [    0.340028] ACPI: bus type pci registered
> [    0.343066] PCI: Using configuration type 1 for base access
> [    0.352055] bio: create slab <bio-0> at 0
> [    0.354016] ACPI: Added _OSI(Module Device)
> [    0.354986] ACPI: Added _OSI(Processor Device)
> [    0.355988] ACPI: Added _OSI(3.0 _SCP Extensions)
> [    0.356976] ACPI: Added _OSI(Processor Aggregator Device)
> [    0.461035] ACPI: Interpreter enabled
> [    0.461960] ACPI: (supports S0 S3 S4 S5)
> [    0.466962] ACPI: Using IOAPIC for interrupt routing
> [    1.042887] ACPI: No dock devices found.
> [    1.043879] HEST: Table not found.
> [    1.044874] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
> [    1.045996] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
> [    1.047922] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
> [    1.048872] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
> [    1.049876] pci_root PNP0A03:00: host bridge window [mem
0x000a0000-0x000bffff]
> [    1.050885] pci_root PNP0A03:00: host bridge window [mem
0xf0000000-0xfbffffff]
> [    1.148854] * Found PM-Timer Bug on the chipset. Due to workarounds for
a bug,
> [    1.148856] * this clock source is slow. Consider trying other clock
sources
> [    1.174862] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by
PIIX4 ACPI
> [    1.249999]  pci0000:00: Unable to request _OSC control (_OSC support
mask: 0x1e)
> [    1.988937] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
> [    1.995734] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
> [    2.002022] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
> [    2.007986] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
> [    2.013926] xen/balloon: Initialising balloon driver.
> [    2.014721] last_pfn = 0x40000 max_arch_pfn = 0x400000000
> [    2.015744] xen-balloon: Initialising balloon driver.
> [    2.016893] vgaarb: device added:
PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
> [    2.017723] vgaarb: loaded
> [    2.018717] vgaarb: bridge control possible 0000:00:02.0
> [    2.019908] SCSI subsystem initialized
> [    2.020926] usbcore: registered new interface driver usbfs
> [    2.021751] usbcore: registered new interface driver hub
> [    2.022778] usbcore: registered new device driver usb
> [    2.023833] PCI: Using ACPI for IRQ routing
> [    2.027000] NetLabel: Initializing
> [    2.027726] NetLabel:  domain hash size = 128
> [    2.028719] NetLabel:  protocols = UNLABELED CIPSOv4
> [    2.029771] NetLabel:  unlabeled traffic allowed by default
> [    2.030738] Switching to clocksource xen
> [    2.032064] Switched to NOHz mode on CPU #0
> [    2.058600] pnp: PnP ACPI init
> [    2.070312] ACPI: bus type pnp registered
> [    2.081358] system 00:00: [mem 0x00000000-0x0009ffff] could not be
reserved
> [    2.105526] system 00:02: [io  0x10c0-0x1141] has been reserved
> [    2.123586] system 00:02: [io  0xb044-0xb047] has been reserved
> [    2.140716] system 00:03: [io  0x08a0-0x08a3] has been reserved
> [    2.155376] system 00:03: [io  0x0cc0-0x0ccf] has been reserved
> [    2.171720] system 00:03: [io  0x04d0-0x04d1] has been reserved
> [    2.235079] pnp: PnP ACPI: found 12 devices
> [    2.239980] ACPI: ACPI bus type pnp unregistered
> [    2.252651] NET: Registered protocol family 2
> [    2.262951] IP route cache hash table entries: 32768 (order: 6, 262144
bytes)
> [    2.271095] TCP established hash table entries: 131072 (order: 9,
2097152 bytes)
> [    2.282685] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> [    2.293164] TCP: Hash tables configured (established 131072 bind 65536)
> [    2.302409] TCP reno registered
> [    2.307217] UDP hash table entries: 512 (order: 2, 16384 bytes)
> [    2.317125] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> [    2.326389] NET: Registered protocol family 1
> [    2.331960] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
> [    2.341391] pci 0000:00:01.0: PIIX3: Enabling Passive Release
> [    2.353138] pci 0000:00:01.0: Activating ISA DMA hang workarounds
> [    2.361559] Unpacking initramfs...
> [    2.699968] Freeing initrd memory: 13264k freed
> [    2.710147] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
> [    2.717216] audit: initializing netlink socket (disabled)
> [    2.722974] type=2000 audit(1320086915.409:1): initialized
> [    2.752235] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    2.764915] VFS: Disk quotas dquot_6.5.2
> [    2.769491] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    2.776668] msgmni has been set to 1983
> [    2.781504] alg: No test for stdrng (krng)
> [    2.787102] NET: Registered protocol family 38
> [    2.792422] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 253)
> [    2.801199] io scheduler noop registered
> [    2.806077] io scheduler deadline registered
> [    2.811278] io scheduler cfq registered (default)
> [    2.818821] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [    2.825681] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
> [    2.831486] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> [    2.838723] acpiphp: Slot [0] registered
> [    2.842985] acpiphp: Slot [1] registered
> [    2.847352] acpiphp: Slot [2] registered
> [    2.851192] acpiphp: Slot [3] registered
> [    2.855526] acpiphp: Slot [4] registered
> [    2.859987] acpiphp: Slot [5] registered
> [    2.865216] acpiphp: Slot [6] registered
> [    2.870721] acpiphp: Slot [7] registered
> [    2.875193] acpiphp: Slot [8] registered
> [    2.882170] acpiphp: Slot [9] registered
> [    2.887602] acpiphp: Slot [10] registered
> [    2.893553] acpiphp: Slot [11] registered
> [    2.901005] acpiphp: Slot [12] registered
> [    2.909484] acpiphp: Slot [13] registered
> [    2.927108] acpiphp: Slot [14] registered
> [    2.936646] acpiphp: Slot [15] registered
> [    2.947352] acpiphp: Slot [16] registered
> [    2.959370] acpiphp: Slot [17] registered
> [    2.975306] acpiphp: Slot [18] registered
> [    2.986962] acpiphp: Slot [19] registered
> [    2.998507] acpiphp: Slot [20] registered
> [    3.008809] acpiphp: Slot [21] registered
> [    3.019088] acpiphp: Slot [22] registered
> [    3.028701] acpiphp: Slot [23] registered
> [    3.041087] acpiphp: Slot [24] registered
> [    3.054701] acpiphp: Slot [25] registered
> [    3.088485] acpiphp: Slot [26] registered
> [    3.096559] acpiphp: Slot [27] registered
> [    3.104123] acpiphp: Slot [28] registered
> [    3.112335] acpiphp: Slot [29] registered
> [    3.120729] acpiphp: Slot [30] registered
> [    3.128063] acpiphp: Slot [31] registered
> [    3.140336] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
> [    3.152824] ACPI: Power Button [PWRF]
> [    3.159164] input: Sleep Button as
/devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
> [    3.170535] ACPI: Sleep Button [SLPF]
> [    3.240741] ERST: Table is not found!
> [    3.247178] GHES: HEST is not enabled!
> [    3.255081] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    3.299342] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [    3.339144] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [    3.348389] Non-volatile memory driver v1.3
> [    3.359031] Linux agpgart interface v0.103
> [    3.373452] loop: module loaded
> [    3.380620] scsi0 : ata_piix
> [    3.385158] scsi1 : ata_piix
> [    3.392804] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc120 irq
14
> [    3.406093] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc128 irq
15
> [    3.424665] Fixed MDIO Bus: probed
> [    3.432049] ehci_hcd: USB 2.0 ''Enhanced'' Host
Controller (EHCI) Driver
> [    3.452302] ohci_hcd: USB 1.1 ''Open'' Host Controller
(OHCI) Driver
> [    3.465814] uhci_hcd: USB Universal Host Controller Interface driver
> [    3.480645] uhci_hcd 0000:00:01.2: PCI INT D -> GSI 23 (level, low)
-> IRQ 23
> [    3.495010] uhci_hcd 0000:00:01.2: UHCI Host Controller
> [    3.509922] uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus
number 1
> [    3.532921] uhci_hcd 0000:00:01.2: irq 23, io base 0x0000c100
> [    3.556237] usb usb1: New USB device found, idVendor=1d6b,
idProduct=0001
> [    3.577164] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
> [    3.597277] usb usb1: Product: UHCI Host Controller
> [    3.609990] usb usb1: Manufacturer: Linux 3.1.0-5.fc16.x86_64 uhci_hcd
> [    3.623617] usb usb1: SerialNumber: 0000:00:01.2
> [    3.633485] hub 1-0:1.0: USB hub found
> [    3.641829] hub 1-0:1.0: 2 ports detected
> [    3.654394] usbcore: registered new interface driver usbserial
> [    3.834631] Refined TSC clocksource calibration: 2677.188 MHz.
> [    3.849203] ata2.00: ATAPI: QEMU DVD-ROM, 0.10.2, max UDMA/100
> [    3.860117] ata1.00: ATA-7: QEMU HARDDISK, 0.10.2, max UDMA/100
> [    3.867830] ata1.00: 62914560 sectors, multi 16: LBA48 
> [    3.880575] ata2.00: configured for MWDMA2
> [    3.888438] ata1.00: configured for MWDMA2
> [    3.897324] scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK   
0.10 PQ: 0 ANSI: 5
> [    3.909309] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [    3.921146] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM    
0.10 PQ: 0 ANSI: 5
> [    3.940204] sd 0:0:0:0: [sda] 62914560 512-byte logical blocks: (32.2
GB/30.0 GiB)
> [    3.953575] sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
> [    3.972245] cdrom: Uniform CD-ROM driver Revision: 3.20
> [    3.985565] sd 0:0:0:0: [sda] Write Protect is off
> [    3.995242] sr 1:0:0:0: Attached scsi generic sg1 type 5
> [    4.003515] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn''t support DPO or FUA
> [    4.030638] USB Serial support registered for generic
> [    4.071098] usb 1-2: new full speed USB device number 2 using uhci_hcd
> [    4.116603]  sda: sda1 sda2 sda3
> [    4.122784] sd 0:0:0:0: [sda] Attached SCSI disk
> [    4.279332] usb 1-2: New USB device found, idVendor=0627, idProduct=0001
> [    4.285003] usb 1-2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
> [    4.291626] usb 1-2: Product: QEMU USB Tablet
> [    4.296035] usb 1-2: Manufacturer: QEMU 0.10.2
> [    4.301072] usb 1-2: SerialNumber: 1
> [    4.327941] usbcore: registered new interface driver usbserial_generic
> [    4.334045] usbserial: USB Serial Driver core
> [    4.338689] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at
0x60,0x64 irq 1,12
> [    4.356131] serio: i8042 KBD port at 0x60,0x64 irq 1
> [    4.365819] serio: i8042 AUX port at 0x60,0x64 irq 12
> [    4.377814] mousedev: PS/2 mouse device common for all mice
> [    4.391350] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input2
> [    4.409931] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
> [    4.423898] rtc0: alarms up to one day, 114 bytes nvram
> [    4.435841] device-mapper: uevent: version 1.0.3
> [    4.449590] device-mapper: ioctl: 4.21.0-ioctl (2011-07-06) initialised:
dm-devel@redhat.com
> [    4.495727] cpuidle: using governor ladder
> [    4.504718] cpuidle: using governor menu
> [    4.513536] EFI Variables Facility v0.08 2004-May-17
> [    4.552133] input: QEMU 0.10.2 QEMU USB Tablet as
/devices/pci0000:00/0000:00:01.2/usb1/1-2/1-2:1.0/input/input3
> [    4.574945] generic-usb 0003:0627:0001.0001: input,hidraw0: USB HID
v0.01 Pointer [QEMU 0.10.2 QEMU USB Tablet] on usb-0000:00:01.2-2/input0
> [    4.604382] usbcore: registered new interface driver usbhid
> [    4.615480] usbhid: USB HID core driver
> [    4.632689] ip_tables: (C) 2000-2006 Netfilter Core Team
> [    4.642932] TCP cubic registered
> [    4.650070] Initializing XFRM netlink socket
> [    4.659989] NET: Registered protocol family 10
> [    4.670710] Mobile IPv6
> [    4.676439] NET: Registered protocol family 17
> [    4.686698] Registering the dns_resolver key type
> [    4.698703] registered taskstats version 1
> [    4.710470] IMA: No TPM chip found, activating TPM-bypass!
> [    4.727752]   Magic number: 15:53:849
> [    4.737301] graphics fbcon: hash matches
> [    4.747845] rtc_cmos 00:05: setting system clock to 2011-10-31 18:48:35
UTC (1320086915)
> [    4.766933] Initializing network drop monitor service
> [    4.778567] Freeing unused kernel memory: 940k freed
> [    4.790390] Write protecting the kernel read-only data: 10240k
> [    4.816829] Freeing unused kernel memory: 1260k freed
> [    4.847132] Freeing unused kernel memory: 1584k freed
> [    4.946739] input: ImExPS/2 Generic Explorer Mouse as
/devices/platform/i8042/serio1/input/input4
> [    5.069194] dracut: dracut-013-16.fc16
> [    5.086672] udevd[115]: starting version 173
> [    5.237375] dracut: Starting plymouth daemon
> %G[    5.437681] dracut: rd.dm=0: removing DM RAID activation
> [    5.456883] dracut: rd.md.imsm=0: no MD RAID for imsm/isw raids
> [    5.471879] dracut: rd.md.ddf=0: no MD RAID for SNIA ddf raids
> %G[    6.056855] dracut: Scanning devices sda3  for LVM logical volumes
vg_f16test64hvm/lv_root vg_f16test64hvm/lv_swap
> [    6.099044] dracut: inactive
''/dev/vg_f16test64hvm/lv_swap'' [1.97 GiB] inherit
> [    6.107308] dracut: inactive
''/dev/vg_f16test64hvm/lv_root'' [27.53 GiB] inherit
> [    6.615218] EXT4-fs (dm-1): INFO: recovery required on readonly
filesystem
> [    6.623572] EXT4-fs (dm-1): write access will be enabled during recovery
> [    7.513709] EXT4-fs (dm-1): recovery complete
> [    7.539777] EXT4-fs (dm-1): mounted filesystem with ordered data mode.
Opts: (null)
> [    7.596678] dracut: Checking ext4: /dev/mapper/vg_f16test64hvm-lv_root
> [    7.603638] dracut: issuing e2fsck -a 
/dev/mapper/vg_f16test64hvm-lv_root
> [    7.657115] dracut: /dev/mapper/vg_f16test64hvm-lv_root: clean,
18709/1806896 files, 289903/7217152 blocks
> [    7.666279] dracut: Remounting /dev/mapper/vg_f16test64hvm-lv_root with
-o ro
> [    7.680814] EXT4-fs (dm-1): mounted filesystem with ordered data mode.
Opts: (null)
> [    7.717573] dracut: Mounted root filesystem
/dev/mapper/vg_f16test64hvm-lv_root
> [    7.854983] dracut: Switching root
> [    8.204987] type=1404 audit(1320086918.956:2): enforcing=1
old_enforcing=0 auid=4294967295 ses=4294967295
> [    8.329675] type=1403 audit(1320086919.081:3): policy loaded
auid=4294967295 ses=4294967295
> [    8.353773] systemd[1]: Successfully loaded SELinux policy in 165ms
166us.
> [    8.451859] systemd[1]: Successfully loaded SELinux database in 77ms
139us, size on heap is 475K.
> [    8.509781] systemd[1]: RTC configured in localtime, applying delta of
120 minutes to system time.
> [    8.660676] systemd[1]: Relabelled /dev and /run in 87ms 636us.
> [    8.689704] systemd[1]: systemd 36 running in system mode. (+PAM
+LIBWRAP +AUDIT +SELINUX +SYSVINIT +LIBCRYPTSETUP; fedora)
> 
> Welcome to [0;34mFedora release 16 (Verne)!
> 
> [    8.755902] systemd[1]: Set hostname to
<f16test64hvm.localdomain>.
> Starting Collect Read-Ahead Data...
> Started Replay Read-Ahead Data.
> Starting Media Directory...
> [    9.215716] systemd-readahead-collect[402]: Disabling readahead
collector due to execution in virtualized environment.
> Started Lock Directory.
> Started Runtime Directory.
> Starting Debug File System...
> Starting POSIX Message Queue File System...
> Starting Security File System...
> Starting Huge Pages File System...
> Starting udev Coldplug all Devices...
> Starting udev Kernel Device Manager...
> Starting Syslog Kernel Log Buffer Bridge...
> Started Syslog Kernel Log Buffer Bridge.
> [    9.410090] udevd[410]: starting version 173
> Started udev Kernel Device Manager.
> Started Collect Read-Ahead Data.
> Started Load legacy module configuration.
> Started File System Check on Root Device.
> Starting Remount API VFS...
> Starting Remount Root FS...
> Started Set Up Additional Binary Formats.
> Started Load Kernel Modules.
> Started FUSE Control File System.
> Started Configuration File System.
> Starting Apply Kernel Variables...
> Starting Setup Virtual Console...
> Starting STDOUT Syslog Bridge...
> Started STDOUT Syslog Bridge.
> Started udev Coldplug all Devices.
> Started Remount API VFS.
> Started Apply Kernel Variables.
> Starting udev Wait for Complete Device Initialization...
> Started Security File System.
> Started POSIX Message Queue File System.
> Started Debug File System.
> Started Huge Pages File System.
> [    9.798875] EXT4-fs (dm-1): re-mounted. Opts: (null)
> Started Media Directory.
> Started Remount Root FS.
> Starting Configure read-only root support...
> Started Configure read-only root support.
> Started Setup Virtual Console.
> Starting /dev/mapper/vg_f16test64hvm-lv_swap...
> [   10.958370] Adding 2064380k swap on /dev/mapper/vg_f16test64hvm-lv_swap.
Priority:0 extents:1 across:2064380k
> Started /dev/mapper/vg_f16test64hvm-lv_swap.
> [   11.009608] piix4_smbus 0000:00:01.3: SMBus base address uninitialized -
upgrade BIOS or use force_addr=0xaddr
> [   11.038011] parport_pc 00:0b: reported by Plug and Play ACPI
> [   11.047803] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
> [   11.094629] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22,
2004)
> [   11.125422] 8139cp 0000:00:03.0: PCI INT A -> GSI 28 (level, low)
-> IRQ 28
> [   11.160994] 8139cp 0000:00:03.0: eth0: RTL-8139C+ at 0xffffc9000019e000,
00:16:3f:03:01:14, IRQ 28
> [   11.186450] ppdev: user-space parallel port driver
> Starting File System Check on
/dev/disk/by-uuid/6d0e406a-ac9c-443d-a84c-34d0cc56d2a2...[   11.279756] 8139too: 8139too Fast Ethernet driver
0.9.28> 
> Started udev Wait for Complete Device Initialization.[   11.449395]
rmmod[598]: ERROR: Module scsi_wait_scan does not exist in /proc/modules
> 
> Started Show Plymouth Boot Screen.
> Starting Wait for storage scan...
> Started Wait for storage scan.
> Starting Initialize storage subsystems (RAID, LVM, etc.)...
> systemd-fsck[   11.727436] systemd-fsck[591]: /dev/sda2: recovering journal
> [591]: /dev/sda2: recovering journal
> systemd-fsck[591]: /dev/sda2: clean, 219/128016 files, 48307/512000 blocks[
11.841965] systemd-fsck[591]: /dev/sda2: clean, 219/128016 files, 48307/512000
blocks
> 
> Started File System Check on
/dev/disk/by-uuid/6d0e406a-ac9c-443d-a84c-34d0cc56d2a2.
> Starting /boot...
> [   12.185717] EXT4-fs (sda2): mounted filesystem with ordered data mode.
Opts: (null)
> Started /boot.
> [   12.462997] fedora-storage-init[604]: Setting up Logical Volume
Management:   2 logical volume(s) in volume group "vg_f16test64hvm"
now active
> Started Initialize storage subsystems (RAID, LVM, etc.).
> Starting Initialize storage subsystems (RAID, LVM, etc.)...
> [   12.528806] fedora-storage-init[604]: [  OK  ]
> [   12.639613] fedora-storage-init[618]: Setting up Logical Volume
Management:   2 logical volume(s) in volume group "vg_f16test64hvm"
now active
> Started Initialize storage subsystems (RAID, LVM, etc.).
> Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or
progress polling...
> [   12.787931] fedora-storage-init[618]: [  OK  ]
> [   12.857150] lvm[624]: 2 logical volume(s) in volume group
"vg_f16test64hvm" monitored
> Started Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or
progress polling.
> Started Mark the need to relabel after reboot.
> Started Relabel all filesystems, if necessary.
> Started Reconfigure the system on administrator request.
> Starting Load Random Seed...
> Starting Tell Plymouth To Write Out Runtime Data...
> Starting Recreate Volatile Files and Directories...
> Started Load Random Seed.
> [   13.065835] systemd-tmpfiles[629]: Successfully loaded SELinux database
in 36ms 529us, size on heap is 476K.
> Started Tell Plymouth To Write Out Runtime Data.
> Started Recreate Volatile Files and Directories.
> Starting LSB: Mount and unmount network filesystems....
> Starting IPv4 firewall with iptables...
> Starting IPv6 firewall with ip6tables...
> Starting Security Auditing Service...
> Starting SSH server keys generation....[   13.419101] auditd[635]: Started dispatcher: /sbin/audispd pid:
645> 
> Starting Sendmail Mail Transport Agent...
> Starting System Logging Service...
> Starting Login Service...
> Started /etc/rc.local Compatibility.
> Starting Wait for Plymouth Boot Screen to Quit...
> Starting Terminate Plymouth Boot Screen...
> Starting D-Bus System Message Bus...
> Stopping Syslog Kernel Log Buffer Bridge...
> [   14.410603] nf_conntrack version 0.5.0 (7964 buckets, 31856 max)
> [   14.418528] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [   28.998481] 8139cp 0000:00:03.0: eth0: link up, 100Mbps, full-duplex,
lpa 0x05E1
> [  149.712071] ------------[ cut here ]------------
> [  149.717216] WARNING: at net/sched/sch_generic.c:255
dev_watchdog+0xf0/0x150()
> [  149.724709] Hardware name: HVM domU
> [  149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit queue 0 timed out
> [  149.735537] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state
ip6_tables nf_conntrack 8139too 8139cp ppdev parport_pc mii parport i2c_piix4
i2c_core joydev [last unloaded: scsi_wait_scan]
> [  149.768028] Pid: 0, comm: swapper Not tainted 3.1.0-5.fc16.x86_64 #1
> [  149.774639] Call Trace:
> [  149.777765]  <IRQ>  [<ffffffff81057a56>]
warn_slowpath_common+0x83/0x9b
> [  149.784024]  [<ffffffff81057b11>] warn_slowpath_fmt+0x46/0x48
> [  149.790141]  [<ffffffff813ef49d>] ? netif_tx_lock+0x4a/0x7c
> [  149.799007]  [<ffffffff813ef613>] dev_watchdog+0xf0/0x150
> [  149.806361]  [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
> [  149.814392]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [  149.821650]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
> [  149.828926]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
> [  149.836803]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [  149.843422]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
> [  149.850067]  [<ffffffff81010b45>] do_softirq+0x46/0x81
> [  149.856760]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
> [  149.863035]  [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
> [  149.871144]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
> [  149.879494]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
> [  149.888220]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
> [  149.894962]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> [  149.901461]  [<ffffffff814934ee>] rest_init+0x72/0x74
> [  149.908949]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
> [  149.916617]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
> [  149.929148]  [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
> [  149.936797]  [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
> [  149.944336] ---[ end trace d8786cb7d6a57f8a ]---
> [  149.950406] 8139cp 0000:00:03.0: eth0: Transmit timeout, status  d   3b 
15 80ff
> [  149.961879] ------------[ cut here ]------------
> [  149.962245] WARNING: at kernel/softirq.c:159
_local_bh_enable_ip+0x44/0x8e()
> [  149.962245] Hardware name: HVM domU
> [  149.962245] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state
ip6_tables nf_conntrack 8139too 8139cp ppdev parport_pc mii parport i2c_piix4
i2c_core joydev [last unloaded: scsi_wait_scan]
> [  149.962245] Pid: 0, comm: swapper Tainted: G        W  
3.1.0-5.fc16.x86_64 #1
> [  149.962245] Call Trace:
> [  149.962245]  <IRQ>  [<ffffffff81057a56>]
warn_slowpath_common+0x83/0x9b
> [  149.962245]  [<ffffffff813ce599>] ? skb_release_data+0xca/0xcf
> [  149.962245]  [<ffffffff81057a88>] warn_slowpath_null+0x1a/0x1c
> [  149.962245]  [<ffffffff8105d462>] _local_bh_enable_ip+0x44/0x8e
> [  149.962245]  [<ffffffff8105d4ba>] local_bh_enable_ip+0xe/0x10
> [  149.962245]  [<ffffffff814b5db4>] _raw_spin_unlock_bh+0x15/0x17
> [  149.962245]  [<ffffffffa0053969>] destroy_conntrack+0x9d/0xdc
[nf_conntrack]
> [  149.962245]  [<ffffffff813fa343>] nf_conntrack_destroy+0x19/0x1b
> [  149.962245]  [<ffffffff813ce7ad>] skb_release_head_state+0xa7/0xef
> [  149.962245]  [<ffffffff813ce5b1>] __kfree_skb+0x13/0x83
> [  149.962245]  [<ffffffff813ce677>] consume_skb+0x56/0x6b
> [  149.962245]  [<ffffffffa003c1b9>] cp_clean_rings+0xb4/0x114
[8139cp]
> [  149.962245]  [<ffffffffa003c371>] cp_tx_timeout+0x88/0x10e
[8139cp]
> [  149.962245]  [<ffffffff813ef627>] dev_watchdog+0x104/0x150
> [  149.962245]  [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
> [  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [  149.962245]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
> [  149.962245]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
> [  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> [  149.962245]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
> [  149.962245]  [<ffffffff81010b45>] do_softirq+0x46/0x81
> [  149.962245]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
> [  149.962245]  [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
> [  149.962245]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
> [  149.962245]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
> [  149.962245]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
> [  149.962245]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> [  149.962245]  [<ffffffff814934ee>] rest_init+0x72/0x74
> [  149.962245]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
> [  149.962245]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
> [  149.962245]  [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
> [  149.962245]  [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
> [  149.962245] ---[ end trace d8786cb7d6a57f8b ]---
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2011-Oct-31 19:24 UTC

head link

Re: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Seems to related

https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829

Boris.

--- On Mon, 10/31/11, Pasi Kärkkäinen <pasik@iki.fi> wrote:

From: Pasi Kärkkäinen <pasik@iki.fi>
Subject: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp
transmit queue timed out)
To: xen-devel@lists.xensource.com
Date: Monday, October 31, 2011, 2:49 PM

Hello,

While testing Xen 4.1.2 and HVM guests I noticed the following problem
with Fedora 16 HVM guests (using Linux 3.1.0 kernel in the VM):

The errors (call trace) happens pretty much immediately when there''s
some network traffic going on..

Simple "yum update" in the VM triggers the problem..


[    0.000000] Linux version 3.1.0-5.fc16.x86_64
(mockbuild@x86-10.phx2.fedoraproject.org) (gcc version 4.6.1 20111003 (Red Hat
4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC 2011
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
root=/dev/mapper/vg_f16test64hvm-lv_root ro rd.lvm.lv=vg_f16test64hvm/lv_root
rd.dm=0 SYSFONT=latarcyrheb-sun16 rhgb KEYTABLE=fi rd.md=0 rd.luks=0
rd.lvm.lv=vg_f16test64hvm/lv_swap LANG=en_US.UTF-8 console=ttyS0,38400
console=tty0
<snip>

[   28.998481] 8139cp 0000:00:03.0: eth0: link up, 100Mbps, full-duplex, lpa
0x05E1
[  149.712071] ------------[ cut here ]------------
[  149.717216] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xf0/0x150()
[  149.724709] Hardware name: HVM domU
[  149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit queue 0 timed out
[  149.735537] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state ip6_tables
nf_conntrack 81
39too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core joydev [last
unloaded: scsi_wait_scan]
[  149.768028] Pid: 0, comm: swapper Not tainted 3.1.0-5.fc16.x86_64 #1
[  149.774639] Call Trace:
[  149.777765]  <IRQ>  [<ffffffff81057a56>]
warn_slowpath_common+0x83/0x9b
[  149.784024]  [<ffffffff81057b11>] warn_slowpath_fmt+0x46/0x48
[  149.790141]  [<ffffffff813ef49d>] ? netif_tx_lock+0x4a/0x7c
[  149.799007]  [<ffffffff813ef613>] dev_watchdog+0xf0/0x150
[  149.806361]  [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
[  149.814392]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
[  149.821650]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
[  149.828926]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
[  149.836803]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
[  149.843422]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
[  149.850067]  [<ffffffff81010b45>] do_softirq+0x46/0x81
[  149.856760]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
[  149.863035]  [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
[  149.871144]  [<ffffffff814be76e>] xen_hvm_callback_vector+0x6e/0x80
[  149.879494]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
[  149.888220]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
[  149.894962]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
[  149.901461]  [<ffffffff814934ee>] rest_init+0x72/0x74
[  149.908949]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
[  149.916617]  [<ffffffff81b762c4>] x86_64_start_reservations+0xaf/0xb3
[  149.929148]  [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
[  149.936797]  [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
[  149.944336] ---[ end trace d8786cb7d6a57f8a ]---
[  149.950406] 8139cp 0000:00:03.0: eth0: Transmit timeout, status  d   3b   15
80ff
[  149.961879] ------------[ cut here ]------------
[  149.962245] WARNING: at kernel/softirq.c:159 _local_bh_enable_ip+0x44/0x8e()
[  149.962245] Hardware name: HVM domU
[  149.962245] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state ip6_tables
nf_conntrack 8139too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core
joydev [last unloaded: scsi_wait_scan]
[  149.962245] Pid: 0, comm: swapper Tainted: G        W   3.1.0-5.fc16.x86_64
#1
[  149.962245] Call Trace:
[  149.962245]  <IRQ>  [<ffffffff81057a56>]
warn_slowpath_common+0x83/0x9b
[  149.962245]  [<ffffffff813ce599>] ? skb_release_data+0xca/0xcf
[  149.962245]  [<ffffffff81057a88>] warn_slowpath_null+0x1a/0x1c
[  149.962245]  [<ffffffff8105d462>] _local_bh_enable_ip+0x44/0x8e
[  149.962245]  [<ffffffff8105d4ba>] local_bh_enable_ip+0xe/0x10
[  149.962245]  [<ffffffff814b5db4>] _raw_spin_unlock_bh+0x15/0x17
[  149.962245]  [<ffffffffa0053969>] destroy_conntrack+0x9d/0xdc
[nf_conntrack]
[  149.962245]  [<ffffffff813fa343>] nf_conntrack_destroy+0x19/0x1b
[  149.962245]  [<ffffffff813ce7ad>] skb_release_head_state+0xa7/0xef
[  149.962245]  [<ffffffff813ce5b1>] __kfree_skb+0x13/0x83
[  149.962245]  [<ffffffff813ce677>] consume_skb+0x56/0x6b
[  149.962245]  [<ffffffffa003c1b9>] cp_clean_rings+0xb4/0x114 [8139cp]
[  149.962245]  [<ffffffffa003c371>] cp_tx_timeout+0x88/0x10e [8139cp]
[  149.962245]  [<ffffffff813ef627>] dev_watchdog+0x104/0x150
[  149.962245]  [<ffffffff81064b51>] run_timer_softirq+0x19b/0x280
[  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
[  149.962245]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
[  149.962245]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
[  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
[  149.962245]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
[  149.962245]  [<ffffffff81010b45>] do_softirq+0x46/0x81
[  149.962245]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
[  149.962245]  [<ffffffff812a39d3>] xen_evtchn_do_upcall+0x31/0x3e
[  149.962245]  [<ffffffff814be76e>] xen_hvm_callback_vector+0x6e/0x80
[  149.962245]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
[  149.962245]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
[  149.962245]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
[  149.962245]  [<ffffffff814934ee>] rest_init+0x72/0x74
[  149.962245]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
[  149.962245]  [<ffffffff81b762c4>] x86_64_start_reservations+0xaf/0xb3
[  149.962245]  [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140
[  149.962245]  [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111
[  149.962245] ---[ end trace d8786cb7d6a57f8b ]---

Full guest kernel dmesg attached to this email.
The host is running F16 with Xen 4.1.2 and Linux 3.1.0 dom0 kernel.

Xen cfgfile for the HVM domain:

kernel = "hvmloader"
builder=''hvm''
device_model = ''qemu-dm''
name = "f16test64hvm"
memory = 1024
vcpus=1
pae=1
acpi=1
apic=1
vif = [ ''type=ioemu, mac=00:16:3f:03:01:14, bridge=virbr0'' ]
disk = [ ''phy:/dev/vg_f16/f16test64hvm,hda,w'',
''file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r''
]
boot=''cd''
xen_platform_pci=0
on_poweroff = ''destroy''
on_reboot   = ''restart''
on_crash    = ''restart''
sdl=0
vnc=1
vncpasswd=''''
stdvga=0
serial=''pty''
tsc_mode=0
usb=1
usbdevice=''tablet''
keymap=''fi''


Using "model=e1000" instead for the vif works OK.. no problems with
the emulated intel nic.

Any ideas what the problem with the emulated realtek nic? 

Thanks,


-- Pasi


-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Oct-31 19:29 UTC

head link

Re: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Mon, Oct 31, 2011 at 12:24:14PM -0700, Boris Derzhavets
wrote:>    Seems to related
> 
>    https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829
> 
Thanks, that seems to be the same bug.

Is the bugfix patch from xen-unstable going to backported to xen-4.1-testing.hg
?
(4.1 backported patch available on ubuntu''s launchpad above..)


-- Pasi

>    Boris.
> 
>    --- On Mon, 10/31/11, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> 
>      From: Pasi Kärkkäinen <pasik@iki.fi>
>      Subject: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0
>      8139cp transmit queue timed out)
>      To: xen-devel@lists.xensource.com
>      Date: Monday, October 31, 2011, 2:49 PM
> 
>      Hello,
> 
>      While testing Xen 4.1.2 and HVM guests I noticed the following problem
>      with Fedora 16 HVM guests (using Linux 3.1.0 kernel in the VM):
> 
>      The errors (call trace) happens pretty much immediately when
there''s
>      some network traffic going on..
> 
>      Simple "yum update" in the VM triggers the problem..
> 
>      [    0.000000] Linux version 3.1.0-5.fc16.x86_64
>      ([1]mockbuild@x86-10.phx2.fedoraproject.org) (gcc version 4.6.1
20111003
>      (Red Hat 4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC 2011
>      [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
>      root=/dev/mapper/vg_f16test64hvm-lv_root ro
>      rd.lvm.lv=vg_f16test64hvm/lv_root rd.dm=0 SYSFONT=latarcyrheb-sun16
rhgb
>      KEYTABLE=fi rd.md=0 rd.luks=0 rd.lvm.lv=vg_f16test64hvm/lv_swap
>      LANG=en_US.UTF-8 console=ttyS0,38400 console=tty0
>      <snip>
> 
>      [   28.998481] 8139cp 0000:00:03.0: eth0: link up, 100Mbps,
full-duplex,
>      lpa 0x05E1
>      [  149.712071] ------------[ cut here ]------------
>      [  149.717216] WARNING: at net/sched/sch_generic.c:255
>      dev_watchdog+0xf0/0x150()
>      [  149.724709] Hardware name: HVM domU
>      [  149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit queue 0 timed
>      out
>      [  149.735537] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
>      nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter
xt_state
>      ip6_tables nf_conntrack 81
>      39too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core joydev
>      [last unloaded: scsi_wait_scan]
>      [  149.768028] Pid: 0, comm: swapper Not tainted 3.1.0-5.fc16.x86_64
#1
>      [  149.774639] Call Trace:
>      [  149.777765]  <IRQ>  [<ffffffff81057a56>]
>      warn_slowpath_common+0x83/0x9b
>      [  149.784024]  [<ffffffff81057b11>] warn_slowpath_fmt+0x46/0x48
>      [  149.790141]  [<ffffffff813ef49d>] ? netif_tx_lock+0x4a/0x7c
>      [  149.799007]  [<ffffffff813ef613>] dev_watchdog+0xf0/0x150
>      [  149.806361]  [<ffffffff81064b51>]
run_timer_softirq+0x19b/0x280
>      [  149.814392]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
>      [  149.821650]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
>      [  149.828926]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
>      [  149.836803]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
>      [  149.843422]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
>      [  149.850067]  [<ffffffff81010b45>] do_softirq+0x46/0x81
>      [  149.856760]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
>      [  149.863035]  [<ffffffff812a39d3>]
xen_evtchn_do_upcall+0x31/0x3e
>      [  149.871144]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
>      [  149.879494]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
>      [  149.888220]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
>      [  149.894962]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
>      [  149.901461]  [<ffffffff814934ee>] rest_init+0x72/0x74
>      [  149.908949]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
>      [  149.916617]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
>      [  149.929148]  [<ffffffff81b76140>] ?
early_idt_handlers+0x140/0x140
>      [  149.936797]  [<ffffffff81b763ca>]
x86_64_start_kernel+0x102/0x111
>      [  149.944336] ---[ end trace d8786cb7d6a57f8a ]---
>      [  149.950406] 8139cp 0000:00:03.0: eth0: Transmit timeout, status
>      d   3b   15 80ff
>      [  149.961879] ------------[ cut here ]------------
>      [  149.962245] WARNING: at kernel/softirq.c:159
>      _local_bh_enable_ip+0x44/0x8e()
>      [  149.962245] Hardware name: HVM domU
>      [  149.962245] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
>      nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter
xt_state
>      ip6_tables nf_conntrack 8139too 8139cp ppdev parport_pc mii parport
>      i2c_piix4 i2c_core joydev [last unloaded: scsi_wait_scan]
>      [  149.962245] Pid: 0, comm: swapper Tainted: G
>      W   3.1.0-5.fc16.x86_64 #1
>      [  149.962245] Call Trace:
>      [  149.962245]  <IRQ>  [<ffffffff81057a56>]
>      warn_slowpath_common+0x83/0x9b
>      [  149.962245]  [<ffffffff813ce599>] ?
skb_release_data+0xca/0xcf
>      [  149.962245]  [<ffffffff81057a88>]
warn_slowpath_null+0x1a/0x1c
>      [  149.962245]  [<ffffffff8105d462>]
_local_bh_enable_ip+0x44/0x8e
>      [  149.962245]  [<ffffffff8105d4ba>] local_bh_enable_ip+0xe/0x10
>      [  149.962245]  [<ffffffff814b5db4>]
_raw_spin_unlock_bh+0x15/0x17
>      [  149.962245]  [<ffffffffa0053969>] destroy_conntrack+0x9d/0xdc
>      [nf_conntrack]
>      [  149.962245]  [<ffffffff813fa343>]
nf_conntrack_destroy+0x19/0x1b
>      [  149.962245]  [<ffffffff813ce7ad>]
skb_release_head_state+0xa7/0xef
>      [  149.962245]  [<ffffffff813ce5b1>] __kfree_skb+0x13/0x83
>      [  149.962245]  [<ffffffff813ce677>] consume_skb+0x56/0x6b
>      [  149.962245]  [<ffffffffa003c1b9>] cp_clean_rings+0xb4/0x114
[8139cp]
>      [  149.962245]  [<ffffffffa003c371>] cp_tx_timeout+0x88/0x10e
[8139cp]
>      [  149.962245]  [<ffffffff813ef627>] dev_watchdog+0x104/0x150
>      [  149.962245]  [<ffffffff81064b51>]
run_timer_softirq+0x19b/0x280
>      [  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
>      [  149.962245]  [<ffffffff813ef523>] ? netif_tx_unlock+0x54/0x54
>      [  149.962245]  [<ffffffff8105d6b3>] __do_softirq+0xc9/0x1b5
>      [  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
>      [  149.962245]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
>      [  149.962245]  [<ffffffff81010b45>] do_softirq+0x46/0x81
>      [  149.962245]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
>      [  149.962245]  [<ffffffff812a39d3>]
xen_evtchn_do_upcall+0x31/0x3e
>      [  149.962245]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
>      [  149.962245]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
>      [  149.962245]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
>      [  149.962245]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
>      [  149.962245]  [<ffffffff814934ee>] rest_init+0x72/0x74
>      [  149.962245]  [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6
>      [  149.962245]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
>      [  149.962245]  [<ffffffff81b76140>] ?
early_idt_handlers+0x140/0x140
>      [  149.962245]  [<ffffffff81b763ca>]
x86_64_start_kernel+0x102/0x111
>      [  149.962245] ---[ end trace d8786cb7d6a57f8b ]---
> 
>      Full guest kernel dmesg attached to this email.
>      The host is running F16 with Xen 4.1.2 and Linux 3.1.0 dom0 kernel.
> 
>      Xen cfgfile for the HVM domain:
> 
>      kernel = "hvmloader"
>      builder=''hvm''
>      device_model = ''qemu-dm''
>      name = "f16test64hvm"
>      memory = 1024
>      vcpus=1
>      pae=1
>      acpi=1
>      apic=1
>      vif = [ ''type=ioemu, mac=00:16:3f:03:01:14,
bridge=virbr0'' ]
>      disk = [ ''phy:/dev/vg_f16/f16test64hvm,hda,w'',
>     
''file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r''
]
>      boot=''cd''
>      xen_platform_pci=0
>      on_poweroff = ''destroy''
>      on_reboot   = ''restart''
>      on_crash    = ''restart''
>      sdl=0
>      vnc=1
>      vncpasswd=''''
>      stdvga=0
>      serial=''pty''
>      tsc_mode=0
>      usb=1
>      usbdevice=''tablet''
>      keymap=''fi''
> 
>      Using "model=e1000" instead for the vif works OK.. no
problems with the
>      emulated intel nic.
> 
>      Any ideas what the problem with the emulated realtek nic?
> 
>      Thanks,
> 
>      -- Pasi
> 
>      -----Inline Attachment Follows-----
> 
>      _______________________________________________
>      Xen-devel mailing list
>      [2]Xen-devel@lists.xensource.com
>      [3]http://lists.xensource.com/xen-devel
> 
> References
> 
>    Visible links
>    1. file:///mc/compose?to=mockbuild@x86-10.phx2.fedoraproject.org
>    2. file:///mc/compose?to=Xen-devel@lists.xensource.com
>    3. http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Nov-01 20:56 UTC

head link

Re: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out) [PATCH]

On Mon, Oct 31, 2011 at 09:29:24PM +0200, Pasi Kärkkäinen
wrote:> On Mon, Oct 31, 2011 at 12:24:14PM -0700, Boris Derzhavets wrote:
> >    Seems to related
> > 
> >    https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829
> > 
> 
> Thanks, that seems to be the same bug.
> 
> Is the bugfix patch from xen-unstable going to backported to
xen-4.1-testing.hg ?
> (4.1 backported patch available on ubuntu''s launchpad above..)
> 
So the Ubuntu backport from xen-unstable to Xen 4.1.1 is here:
https://launchpadlibrarian.net/81948978/xen-pirq-resubmit-irq.patch

It seems to be shipping in Ubuntu 11.10 xen 4.1.1-2ubuntu4.1 packages.

Does that patch look suitable to be applied to xen-4.1-testing.hg ? 
This bug should be fixed for Xen 4.1.3.
 
-- Pasi

> 
> 
> >    Boris.
> > 
> >    --- On Mon, 10/31/11, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > 
> >      From: Pasi Kärkkäinen <pasik@iki.fi>
> >      Subject: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems
(eth0
> >      8139cp transmit queue timed out)
> >      To: xen-devel@lists.xensource.com
> >      Date: Monday, October 31, 2011, 2:49 PM
> > 
> >      Hello,
> > 
> >      While testing Xen 4.1.2 and HVM guests I noticed the following
problem
> >      with Fedora 16 HVM guests (using Linux 3.1.0 kernel in the VM):
> > 
> >      The errors (call trace) happens pretty much immediately when
there''s
> >      some network traffic going on..
> > 
> >      Simple "yum update" in the VM triggers the problem..
> > 
> >      [    0.000000] Linux version 3.1.0-5.fc16.x86_64
> >      ([1]mockbuild@x86-10.phx2.fedoraproject.org) (gcc version 4.6.1
20111003
> >      (Red Hat 4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC 2011
> >      [    0.000000] Command line:
BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
> >      root=/dev/mapper/vg_f16test64hvm-lv_root ro
> >      rd.lvm.lv=vg_f16test64hvm/lv_root rd.dm=0
SYSFONT=latarcyrheb-sun16 rhgb
> >      KEYTABLE=fi rd.md=0 rd.luks=0 rd.lvm.lv=vg_f16test64hvm/lv_swap
> >      LANG=en_US.UTF-8 console=ttyS0,38400 console=tty0
> >      <snip>
> > 
> >      [   28.998481] 8139cp 0000:00:03.0: eth0: link up, 100Mbps,
full-duplex,
> >      lpa 0x05E1
> >      [  149.712071] ------------[ cut here ]------------
> >      [  149.717216] WARNING: at net/sched/sch_generic.c:255
> >      dev_watchdog+0xf0/0x150()
> >      [  149.724709] Hardware name: HVM domU
> >      [  149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit queue 0
timed
> >      out
> >      [  149.735537] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
> >      nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter
xt_state
> >      ip6_tables nf_conntrack 81
> >      39too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core
joydev
> >      [last unloaded: scsi_wait_scan]
> >      [  149.768028] Pid: 0, comm: swapper Not tainted
3.1.0-5.fc16.x86_64 #1
> >      [  149.774639] Call Trace:
> >      [  149.777765]  <IRQ>  [<ffffffff81057a56>]
> >      warn_slowpath_common+0x83/0x9b
> >      [  149.784024]  [<ffffffff81057b11>]
warn_slowpath_fmt+0x46/0x48
> >      [  149.790141]  [<ffffffff813ef49d>] ?
netif_tx_lock+0x4a/0x7c
> >      [  149.799007]  [<ffffffff813ef613>]
dev_watchdog+0xf0/0x150
> >      [  149.806361]  [<ffffffff81064b51>]
run_timer_softirq+0x19b/0x280
> >      [  149.814392]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> >      [  149.821650]  [<ffffffff813ef523>] ?
netif_tx_unlock+0x54/0x54
> >      [  149.828926]  [<ffffffff8105d6b3>]
__do_softirq+0xc9/0x1b5
> >      [  149.836803]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> >      [  149.843422]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
> >      [  149.850067]  [<ffffffff81010b45>] do_softirq+0x46/0x81
> >      [  149.856760]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
> >      [  149.863035]  [<ffffffff812a39d3>]
xen_evtchn_do_upcall+0x31/0x3e
> >      [  149.871144]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
> >      [  149.879494]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
> >      [  149.888220]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
> >      [  149.894962]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> >      [  149.901461]  [<ffffffff814934ee>] rest_init+0x72/0x74
> >      [  149.908949]  [<ffffffff81b76b7d>]
start_kernel+0x3ab/0x3b6
> >      [  149.916617]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
> >      [  149.929148]  [<ffffffff81b76140>] ?
early_idt_handlers+0x140/0x140
> >      [  149.936797]  [<ffffffff81b763ca>]
x86_64_start_kernel+0x102/0x111
> >      [  149.944336] ---[ end trace d8786cb7d6a57f8a ]---
> >      [  149.950406] 8139cp 0000:00:03.0: eth0: Transmit timeout,
status
> >      d   3b   15 80ff
> >      [  149.961879] ------------[ cut here ]------------
> >      [  149.962245] WARNING: at kernel/softirq.c:159
> >      _local_bh_enable_ip+0x44/0x8e()
> >      [  149.962245] Hardware name: HVM domU
> >      [  149.962245] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
> >      nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter
xt_state
> >      ip6_tables nf_conntrack 8139too 8139cp ppdev parport_pc mii
parport
> >      i2c_piix4 i2c_core joydev [last unloaded: scsi_wait_scan]
> >      [  149.962245] Pid: 0, comm: swapper Tainted: G
> >      W   3.1.0-5.fc16.x86_64 #1
> >      [  149.962245] Call Trace:
> >      [  149.962245]  <IRQ>  [<ffffffff81057a56>]
> >      warn_slowpath_common+0x83/0x9b
> >      [  149.962245]  [<ffffffff813ce599>] ?
skb_release_data+0xca/0xcf
> >      [  149.962245]  [<ffffffff81057a88>]
warn_slowpath_null+0x1a/0x1c
> >      [  149.962245]  [<ffffffff8105d462>]
_local_bh_enable_ip+0x44/0x8e
> >      [  149.962245]  [<ffffffff8105d4ba>]
local_bh_enable_ip+0xe/0x10
> >      [  149.962245]  [<ffffffff814b5db4>]
_raw_spin_unlock_bh+0x15/0x17
> >      [  149.962245]  [<ffffffffa0053969>]
destroy_conntrack+0x9d/0xdc
> >      [nf_conntrack]
> >      [  149.962245]  [<ffffffff813fa343>]
nf_conntrack_destroy+0x19/0x1b
> >      [  149.962245]  [<ffffffff813ce7ad>]
skb_release_head_state+0xa7/0xef
> >      [  149.962245]  [<ffffffff813ce5b1>] __kfree_skb+0x13/0x83
> >      [  149.962245]  [<ffffffff813ce677>] consume_skb+0x56/0x6b
> >      [  149.962245]  [<ffffffffa003c1b9>]
cp_clean_rings+0xb4/0x114 [8139cp]
> >      [  149.962245]  [<ffffffffa003c371>]
cp_tx_timeout+0x88/0x10e [8139cp]
> >      [  149.962245]  [<ffffffff813ef627>]
dev_watchdog+0x104/0x150
> >      [  149.962245]  [<ffffffff81064b51>]
run_timer_softirq+0x19b/0x280
> >      [  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> >      [  149.962245]  [<ffffffff813ef523>] ?
netif_tx_unlock+0x54/0x54
> >      [  149.962245]  [<ffffffff8105d6b3>]
__do_softirq+0xc9/0x1b5
> >      [  149.962245]  [<ffffffff81014fec>] ? sched_clock+0x9/0xd
> >      [  149.962245]  [<ffffffff814be5ec>] call_softirq+0x1c/0x30
> >      [  149.962245]  [<ffffffff81010b45>] do_softirq+0x46/0x81
> >      [  149.962245]  [<ffffffff8105d97b>] irq_exit+0x57/0xb1
> >      [  149.962245]  [<ffffffff812a39d3>]
xen_evtchn_do_upcall+0x31/0x3e
> >      [  149.962245]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
> >      [  149.962245]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
> >      [  149.962245]  [<ffffffff81015b7e>] default_idle+0x4e/0x86
> >      [  149.962245]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> >      [  149.962245]  [<ffffffff814934ee>] rest_init+0x72/0x74
> >      [  149.962245]  [<ffffffff81b76b7d>]
start_kernel+0x3ab/0x3b6
> >      [  149.962245]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
> >      [  149.962245]  [<ffffffff81b76140>] ?
early_idt_handlers+0x140/0x140
> >      [  149.962245]  [<ffffffff81b763ca>]
x86_64_start_kernel+0x102/0x111
> >      [  149.962245] ---[ end trace d8786cb7d6a57f8b ]---
> > 
> >      Full guest kernel dmesg attached to this email.
> >      The host is running F16 with Xen 4.1.2 and Linux 3.1.0 dom0
kernel.
> > 
> >      Xen cfgfile for the HVM domain:
> > 
> >      kernel = "hvmloader"
> >      builder=''hvm''
> >      device_model = ''qemu-dm''
> >      name = "f16test64hvm"
> >      memory = 1024
> >      vcpus=1
> >      pae=1
> >      acpi=1
> >      apic=1
> >      vif = [ ''type=ioemu, mac=00:16:3f:03:01:14,
bridge=virbr0'' ]
> >      disk = [ ''phy:/dev/vg_f16/f16test64hvm,hda,w'',
> >     
''file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r''
]
> >      boot=''cd''
> >      xen_platform_pci=0
> >      on_poweroff = ''destroy''
> >      on_reboot   = ''restart''
> >      on_crash    = ''restart''
> >      sdl=0
> >      vnc=1
> >      vncpasswd=''''
> >      stdvga=0
> >      serial=''pty''
> >      tsc_mode=0
> >      usb=1
> >      usbdevice=''tablet''
> >      keymap=''fi''
> > 
> >      Using "model=e1000" instead for the vif works OK.. no
problems with the
> >      emulated intel nic.
> > 
> >      Any ideas what the problem with the emulated realtek nic?
> > 
> >      Thanks,
> > 
> >      -- Pasi
> > 
> >      -----Inline Attachment Follows-----
> > 
> >      _______________________________________________
> >      Xen-devel mailing list
> >      [2]Xen-devel@lists.xensource.com
> >      [3]http://lists.xensource.com/xen-devel
> > 
> > References
> > 
> >    Visible links
> >    1. file:///mc/compose?to=mockbuild@x86-10.phx2.fedoraproject.org
> >    2. file:///mc/compose?to=Xen-devel@lists.xensource.com
> >    3. http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Nov-03 18:07 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Tue, Nov 01, 2011 at 10:56:06PM +0200, Pasi Kärkkäinen
wrote:> On Mon, Oct 31, 2011 at 09:29:24PM +0200, Pasi Kärkkäinen wrote:
> > On Mon, Oct 31, 2011 at 12:24:14PM -0700, Boris Derzhavets wrote:
> > >    Seems to related
> > > 
> > >    https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829
> > > 
> > 
> > Thanks, that seems to be the same bug.
> > 
> > Is the bugfix patch from xen-unstable going to backported to
xen-4.1-testing.hg ?
> > (4.1 backported patch available on ubuntu''s launchpad
above..)
> > 
> 
> So the Ubuntu backport from xen-unstable to Xen 4.1.1 is here:
> https://launchpadlibrarian.net/81948978/xen-pirq-resubmit-irq.patch
> 
> It seems to be shipping in Ubuntu 11.10 xen 4.1.1-2ubuntu4.1 packages.
> 
> Does that patch look suitable to be applied to xen-4.1-testing.hg ? 
> This bug should be fixed for Xen 4.1.3.
>  

Any comments? 

-- Pasi

> 
> > 
> > 
> > >    Boris.
> > > 
> > >    --- On Mon, 10/31/11, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
> > > 
> > >      From: Pasi Kärkkäinen <pasik@iki.fi>
> > >      Subject: [Xen-devel] Xen 4.1.2 HVM guest realtek nic
problems (eth0
> > >      8139cp transmit queue timed out)
> > >      To: xen-devel@lists.xensource.com
> > >      Date: Monday, October 31, 2011, 2:49 PM
> > > 
> > >      Hello,
> > > 
> > >      While testing Xen 4.1.2 and HVM guests I noticed the
following problem
> > >      with Fedora 16 HVM guests (using Linux 3.1.0 kernel in the
VM):
> > > 
> > >      The errors (call trace) happens pretty much immediately when
there''s
> > >      some network traffic going on..
> > > 
> > >      Simple "yum update" in the VM triggers the
problem..
> > > 
> > >      [    0.000000] Linux version 3.1.0-5.fc16.x86_64
> > >      ([1]mockbuild@x86-10.phx2.fedoraproject.org) (gcc version
4.6.1 20111003
> > >      (Red Hat 4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC
2011
> > >      [    0.000000] Command line:
BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
> > >      root=/dev/mapper/vg_f16test64hvm-lv_root ro
> > >      rd.lvm.lv=vg_f16test64hvm/lv_root rd.dm=0
SYSFONT=latarcyrheb-sun16 rhgb
> > >      KEYTABLE=fi rd.md=0 rd.luks=0
rd.lvm.lv=vg_f16test64hvm/lv_swap
> > >      LANG=en_US.UTF-8 console=ttyS0,38400 console=tty0
> > >      <snip>
> > > 
> > >      [   28.998481] 8139cp 0000:00:03.0: eth0: link up, 100Mbps,
full-duplex,
> > >      lpa 0x05E1
> > >      [  149.712071] ------------[ cut here ]------------
> > >      [  149.717216] WARNING: at net/sched/sch_generic.c:255
> > >      dev_watchdog+0xf0/0x150()
> > >      [  149.724709] Hardware name: HVM domU
> > >      [  149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit
queue 0 timed
> > >      out
> > >      [  149.735537] Modules linked in: ip6t_REJECT
nf_conntrack_ipv6
> > >      nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
ip6table_filter xt_state
> > >      ip6_tables nf_conntrack 81
> > >      39too 8139cp ppdev parport_pc mii parport i2c_piix4 i2c_core
joydev
> > >      [last unloaded: scsi_wait_scan]
> > >      [  149.768028] Pid: 0, comm: swapper Not tainted
3.1.0-5.fc16.x86_64 #1
> > >      [  149.774639] Call Trace:
> > >      [  149.777765]  <IRQ>  [<ffffffff81057a56>]
> > >      warn_slowpath_common+0x83/0x9b
> > >      [  149.784024]  [<ffffffff81057b11>]
warn_slowpath_fmt+0x46/0x48
> > >      [  149.790141]  [<ffffffff813ef49d>] ?
netif_tx_lock+0x4a/0x7c
> > >      [  149.799007]  [<ffffffff813ef613>]
dev_watchdog+0xf0/0x150
> > >      [  149.806361]  [<ffffffff81064b51>]
run_timer_softirq+0x19b/0x280
> > >      [  149.814392]  [<ffffffff81014fec>] ?
sched_clock+0x9/0xd
> > >      [  149.821650]  [<ffffffff813ef523>] ?
netif_tx_unlock+0x54/0x54
> > >      [  149.828926]  [<ffffffff8105d6b3>]
__do_softirq+0xc9/0x1b5
> > >      [  149.836803]  [<ffffffff81014fec>] ?
sched_clock+0x9/0xd
> > >      [  149.843422]  [<ffffffff814be5ec>]
call_softirq+0x1c/0x30
> > >      [  149.850067]  [<ffffffff81010b45>]
do_softirq+0x46/0x81
> > >      [  149.856760]  [<ffffffff8105d97b>]
irq_exit+0x57/0xb1
> > >      [  149.863035]  [<ffffffff812a39d3>]
xen_evtchn_do_upcall+0x31/0x3e
> > >      [  149.871144]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
> > >      [  149.879494]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
> > >      [  149.888220]  [<ffffffff81015b7e>]
default_idle+0x4e/0x86
> > >      [  149.894962]  [<ffffffff8100e2ed>]
cpu_idle+0xae/0xe8
> > >      [  149.901461]  [<ffffffff814934ee>]
rest_init+0x72/0x74
> > >      [  149.908949]  [<ffffffff81b76b7d>]
start_kernel+0x3ab/0x3b6
> > >      [  149.916617]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
> > >      [  149.929148]  [<ffffffff81b76140>] ?
early_idt_handlers+0x140/0x140
> > >      [  149.936797]  [<ffffffff81b763ca>]
x86_64_start_kernel+0x102/0x111
> > >      [  149.944336] ---[ end trace d8786cb7d6a57f8a ]---
> > >      [  149.950406] 8139cp 0000:00:03.0: eth0: Transmit timeout,
status
> > >      d   3b   15 80ff
> > >      [  149.961879] ------------[ cut here ]------------
> > >      [  149.962245] WARNING: at kernel/softirq.c:159
> > >      _local_bh_enable_ip+0x44/0x8e()
> > >      [  149.962245] Hardware name: HVM domU
> > >      [  149.962245] Modules linked in: ip6t_REJECT
nf_conntrack_ipv6
> > >      nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
ip6table_filter xt_state
> > >      ip6_tables nf_conntrack 8139too 8139cp ppdev parport_pc mii
parport
> > >      i2c_piix4 i2c_core joydev [last unloaded: scsi_wait_scan]
> > >      [  149.962245] Pid: 0, comm: swapper Tainted: G
> > >      W   3.1.0-5.fc16.x86_64 #1
> > >      [  149.962245] Call Trace:
> > >      [  149.962245]  <IRQ>  [<ffffffff81057a56>]
> > >      warn_slowpath_common+0x83/0x9b
> > >      [  149.962245]  [<ffffffff813ce599>] ?
skb_release_data+0xca/0xcf
> > >      [  149.962245]  [<ffffffff81057a88>]
warn_slowpath_null+0x1a/0x1c
> > >      [  149.962245]  [<ffffffff8105d462>]
_local_bh_enable_ip+0x44/0x8e
> > >      [  149.962245]  [<ffffffff8105d4ba>]
local_bh_enable_ip+0xe/0x10
> > >      [  149.962245]  [<ffffffff814b5db4>]
_raw_spin_unlock_bh+0x15/0x17
> > >      [  149.962245]  [<ffffffffa0053969>]
destroy_conntrack+0x9d/0xdc
> > >      [nf_conntrack]
> > >      [  149.962245]  [<ffffffff813fa343>]
nf_conntrack_destroy+0x19/0x1b
> > >      [  149.962245]  [<ffffffff813ce7ad>]
skb_release_head_state+0xa7/0xef
> > >      [  149.962245]  [<ffffffff813ce5b1>]
__kfree_skb+0x13/0x83
> > >      [  149.962245]  [<ffffffff813ce677>]
consume_skb+0x56/0x6b
> > >      [  149.962245]  [<ffffffffa003c1b9>]
cp_clean_rings+0xb4/0x114 [8139cp]
> > >      [  149.962245]  [<ffffffffa003c371>]
cp_tx_timeout+0x88/0x10e [8139cp]
> > >      [  149.962245]  [<ffffffff813ef627>]
dev_watchdog+0x104/0x150
> > >      [  149.962245]  [<ffffffff81064b51>]
run_timer_softirq+0x19b/0x280
> > >      [  149.962245]  [<ffffffff81014fec>] ?
sched_clock+0x9/0xd
> > >      [  149.962245]  [<ffffffff813ef523>] ?
netif_tx_unlock+0x54/0x54
> > >      [  149.962245]  [<ffffffff8105d6b3>]
__do_softirq+0xc9/0x1b5
> > >      [  149.962245]  [<ffffffff81014fec>] ?
sched_clock+0x9/0xd
> > >      [  149.962245]  [<ffffffff814be5ec>]
call_softirq+0x1c/0x30
> > >      [  149.962245]  [<ffffffff81010b45>]
do_softirq+0x46/0x81
> > >      [  149.962245]  [<ffffffff8105d97b>]
irq_exit+0x57/0xb1
> > >      [  149.962245]  [<ffffffff812a39d3>]
xen_evtchn_do_upcall+0x31/0x3e
> > >      [  149.962245]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
> > >      [  149.962245]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
> > >      [  149.962245]  [<ffffffff81015b7e>]
default_idle+0x4e/0x86
> > >      [  149.962245]  [<ffffffff8100e2ed>]
cpu_idle+0xae/0xe8
> > >      [  149.962245]  [<ffffffff814934ee>]
rest_init+0x72/0x74
> > >      [  149.962245]  [<ffffffff81b76b7d>]
start_kernel+0x3ab/0x3b6
> > >      [  149.962245]  [<ffffffff81b762c4>]
x86_64_start_reservations+0xaf/0xb3
> > >      [  149.962245]  [<ffffffff81b76140>] ?
early_idt_handlers+0x140/0x140
> > >      [  149.962245]  [<ffffffff81b763ca>]
x86_64_start_kernel+0x102/0x111
> > >      [  149.962245] ---[ end trace d8786cb7d6a57f8b ]---
> > > 
> > >      Full guest kernel dmesg attached to this email.
> > >      The host is running F16 with Xen 4.1.2 and Linux 3.1.0 dom0
kernel.
> > > 
> > >      Xen cfgfile for the HVM domain:
> > > 
> > >      kernel = "hvmloader"
> > >      builder=''hvm''
> > >      device_model = ''qemu-dm''
> > >      name = "f16test64hvm"
> > >      memory = 1024
> > >      vcpus=1
> > >      pae=1
> > >      acpi=1
> > >      apic=1
> > >      vif = [ ''type=ioemu, mac=00:16:3f:03:01:14,
bridge=virbr0'' ]
> > >      disk = [
''phy:/dev/vg_f16/f16test64hvm,hda,w'',
> > >     
''file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r''
]
> > >      boot=''cd''
> > >      xen_platform_pci=0
> > >      on_poweroff = ''destroy''
> > >      on_reboot   = ''restart''
> > >      on_crash    = ''restart''
> > >      sdl=0
> > >      vnc=1
> > >      vncpasswd=''''
> > >      stdvga=0
> > >      serial=''pty''
> > >      tsc_mode=0
> > >      usb=1
> > >      usbdevice=''tablet''
> > >      keymap=''fi''
> > > 
> > >      Using "model=e1000" instead for the vif works OK..
no problems with the
> > >      emulated intel nic.
> > > 
> > >      Any ideas what the problem with the emulated realtek nic?
> > > 
> > >      Thanks,
> > > 
> > >      -- Pasi
> > > 
> > >      -----Inline Attachment Follows-----
> > > 
> > >      _______________________________________________
> > >      Xen-devel mailing list
> > >      [2]Xen-devel@lists.xensource.com
> > >      [3]http://lists.xensource.com/xen-devel
> > > 
> > > References
> > > 
> > >    Visible links
> > >    1.
file:///mc/compose?to=mockbuild@x86-10.phx2.fedoraproject.org
> > >    2. file:///mc/compose?to=Xen-devel@lists.xensource.com
> > >    3. http://lists.xensource.com/xen-devel
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2011-Nov-03 18:34 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On 03/11/2011 18:07, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> On Tue, Nov 01, 2011 at 10:56:06PM +0200, Pasi Kärkkäinen wrote:
>> On Mon, Oct 31, 2011 at 09:29:24PM +0200, Pasi Kärkkäinen wrote:
>>> On Mon, Oct 31, 2011 at 12:24:14PM -0700, Boris Derzhavets wrote:
>>>>    Seems to related
>>>> 
>>>>    https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829
>>>> 
>>> 
>>> Thanks, that seems to be the same bug.
>>> 
>>> Is the bugfix patch from xen-unstable going to backported to
>>> xen-4.1-testing.hg ?
>>> (4.1 backported patch available on ubuntu''s launchpad
above..)
>>> 
>> 
>> So the Ubuntu backport from xen-unstable to Xen 4.1.1 is here:
>> https://launchpadlibrarian.net/81948978/xen-pirq-resubmit-irq.patch
>> 
>> It seems to be shipping in Ubuntu 11.10 xen 4.1.1-2ubuntu4.1 packages.
>> 
>> Does that patch look suitable to be applied to xen-4.1-testing.hg ?
>> This bug should be fixed for Xen 4.1.3.
> 
> Any comments? 
This looks like a backport of Stefano''s xen-unstable c/s 24007. I would
like
him to submit/ack the backport, as it is not a trivial backport of the
xen-unstable patch.

 -- Keir
> -- Pasi
> 
> 
>> 
>>> 
>>> 
>>>>    Boris.
>>>> 
>>>>    --- On Mon, 10/31/11, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
>>>> 
>>>>      From: Pasi Kärkkäinen <pasik@iki.fi>
>>>>      Subject: [Xen-devel] Xen 4.1.2 HVM guest realtek nic
problems (eth0
>>>>      8139cp transmit queue timed out)
>>>>      To: xen-devel@lists.xensource.com
>>>>      Date: Monday, October 31, 2011, 2:49 PM
>>>> 
>>>>      Hello,
>>>> 
>>>>      While testing Xen 4.1.2 and HVM guests I noticed the
following problem
>>>>      with Fedora 16 HVM guests (using Linux 3.1.0 kernel in the
VM):
>>>> 
>>>>      The errors (call trace) happens pretty much immediately
when there''s
>>>>      some network traffic going on..
>>>> 
>>>>      Simple "yum update" in the VM triggers the
problem..
>>>> 
>>>>      [    0.000000] Linux version 3.1.0-5.fc16.x86_64
>>>>      ([1]mockbuild@x86-10.phx2.fedoraproject.org) (gcc version
4.6.1
>>>> 20111003
>>>>      (Red Hat 4.6.1-10) (GCC) ) #1 SMP Thu Oct 27 03:46:50 UTC
2011
>>>>      [    0.000000] Command line:
BOOT_IMAGE=/vmlinuz-3.1.0-5.fc16.x86_64
>>>>      root=/dev/mapper/vg_f16test64hvm-lv_root ro
>>>>      rd.lvm.lv=vg_f16test64hvm/lv_root rd.dm=0
SYSFONT=latarcyrheb-sun16
>>>> rhgb
>>>>      KEYTABLE=fi rd.md=0 rd.luks=0
rd.lvm.lv=vg_f16test64hvm/lv_swap
>>>>      LANG=en_US.UTF-8 console=ttyS0,38400 console=tty0
>>>>      <snip>
>>>> 
>>>>      [   28.998481] 8139cp 0000:00:03.0: eth0: link up,
100Mbps,
>>>> full-duplex,
>>>>      lpa 0x05E1
>>>>      [  149.712071] ------------[ cut here ]------------
>>>>      [  149.717216] WARNING: at net/sched/sch_generic.c:255
>>>>      dev_watchdog+0xf0/0x150()
>>>>      [  149.724709] Hardware name: HVM domU
>>>>      [  149.728738] NETDEV WATCHDOG: eth0 (8139cp): transmit
queue 0 timed
>>>>      out
>>>>      [  149.735537] Modules linked in: ip6t_REJECT
nf_conntrack_ipv6
>>>>      nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
ip6table_filter
>>>> xt_state
>>>>      ip6_tables nf_conntrack 81
>>>>      39too 8139cp ppdev parport_pc mii parport i2c_piix4
i2c_core joydev
>>>>      [last unloaded: scsi_wait_scan]
>>>>      [  149.768028] Pid: 0, comm: swapper Not tainted
3.1.0-5.fc16.x86_64
>>>> #1
>>>>      [  149.774639] Call Trace:
>>>>      [  149.777765]  <IRQ>  [<ffffffff81057a56>]
>>>>      warn_slowpath_common+0x83/0x9b
>>>>      [  149.784024]  [<ffffffff81057b11>]
warn_slowpath_fmt+0x46/0x48
>>>>      [  149.790141]  [<ffffffff813ef49d>] ?
netif_tx_lock+0x4a/0x7c
>>>>      [  149.799007]  [<ffffffff813ef613>]
dev_watchdog+0xf0/0x150
>>>>      [  149.806361]  [<ffffffff81064b51>]
run_timer_softirq+0x19b/0x280
>>>>      [  149.814392]  [<ffffffff81014fec>] ?
sched_clock+0x9/0xd
>>>>      [  149.821650]  [<ffffffff813ef523>] ?
netif_tx_unlock+0x54/0x54
>>>>      [  149.828926]  [<ffffffff8105d6b3>]
__do_softirq+0xc9/0x1b5
>>>>      [  149.836803]  [<ffffffff81014fec>] ?
sched_clock+0x9/0xd
>>>>      [  149.843422]  [<ffffffff814be5ec>]
call_softirq+0x1c/0x30
>>>>      [  149.850067]  [<ffffffff81010b45>]
do_softirq+0x46/0x81
>>>>      [  149.856760]  [<ffffffff8105d97b>]
irq_exit+0x57/0xb1
>>>>      [  149.863035]  [<ffffffff812a39d3>]
xen_evtchn_do_upcall+0x31/0x3e
>>>>      [  149.871144]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
>>>>      [  149.879494]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
>>>>      [  149.888220]  [<ffffffff81015b7e>]
default_idle+0x4e/0x86
>>>>      [  149.894962]  [<ffffffff8100e2ed>]
cpu_idle+0xae/0xe8
>>>>      [  149.901461]  [<ffffffff814934ee>]
rest_init+0x72/0x74
>>>>      [  149.908949]  [<ffffffff81b76b7d>]
start_kernel+0x3ab/0x3b6
>>>>      [  149.916617]  [<ffffffff81b762c4>]
>>>> x86_64_start_reservations+0xaf/0xb3
>>>>      [  149.929148]  [<ffffffff81b76140>] ?
early_idt_handlers+0x140/0x140
>>>>      [  149.936797]  [<ffffffff81b763ca>]
x86_64_start_kernel+0x102/0x111
>>>>      [  149.944336] ---[ end trace d8786cb7d6a57f8a ]---
>>>>      [  149.950406] 8139cp 0000:00:03.0: eth0: Transmit
timeout, status
>>>>      d   3b   15 80ff
>>>>      [  149.961879] ------------[ cut here ]------------
>>>>      [  149.962245] WARNING: at kernel/softirq.c:159
>>>>      _local_bh_enable_ip+0x44/0x8e()
>>>>      [  149.962245] Hardware name: HVM domU
>>>>      [  149.962245] Modules linked in: ip6t_REJECT
nf_conntrack_ipv6
>>>>      nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
ip6table_filter
>>>> xt_state
>>>>      ip6_tables nf_conntrack 8139too 8139cp ppdev parport_pc
mii parport
>>>>      i2c_piix4 i2c_core joydev [last unloaded: scsi_wait_scan]
>>>>      [  149.962245] Pid: 0, comm: swapper Tainted: G
>>>>      W   3.1.0-5.fc16.x86_64 #1
>>>>      [  149.962245] Call Trace:
>>>>      [  149.962245]  <IRQ>  [<ffffffff81057a56>]
>>>>      warn_slowpath_common+0x83/0x9b
>>>>      [  149.962245]  [<ffffffff813ce599>] ?
skb_release_data+0xca/0xcf
>>>>      [  149.962245]  [<ffffffff81057a88>]
warn_slowpath_null+0x1a/0x1c
>>>>      [  149.962245]  [<ffffffff8105d462>]
_local_bh_enable_ip+0x44/0x8e
>>>>      [  149.962245]  [<ffffffff8105d4ba>]
local_bh_enable_ip+0xe/0x10
>>>>      [  149.962245]  [<ffffffff814b5db4>]
_raw_spin_unlock_bh+0x15/0x17
>>>>      [  149.962245]  [<ffffffffa0053969>]
destroy_conntrack+0x9d/0xdc
>>>>      [nf_conntrack]
>>>>      [  149.962245]  [<ffffffff813fa343>]
nf_conntrack_destroy+0x19/0x1b
>>>>      [  149.962245]  [<ffffffff813ce7ad>]
skb_release_head_state+0xa7/0xef
>>>>      [  149.962245]  [<ffffffff813ce5b1>]
__kfree_skb+0x13/0x83
>>>>      [  149.962245]  [<ffffffff813ce677>]
consume_skb+0x56/0x6b
>>>>      [  149.962245]  [<ffffffffa003c1b9>]
cp_clean_rings+0xb4/0x114
>>>> [8139cp]
>>>>      [  149.962245]  [<ffffffffa003c371>]
cp_tx_timeout+0x88/0x10e [8139cp]
>>>>      [  149.962245]  [<ffffffff813ef627>]
dev_watchdog+0x104/0x150
>>>>      [  149.962245]  [<ffffffff81064b51>]
run_timer_softirq+0x19b/0x280
>>>>      [  149.962245]  [<ffffffff81014fec>] ?
sched_clock+0x9/0xd
>>>>      [  149.962245]  [<ffffffff813ef523>] ?
netif_tx_unlock+0x54/0x54
>>>>      [  149.962245]  [<ffffffff8105d6b3>]
__do_softirq+0xc9/0x1b5
>>>>      [  149.962245]  [<ffffffff81014fec>] ?
sched_clock+0x9/0xd
>>>>      [  149.962245]  [<ffffffff814be5ec>]
call_softirq+0x1c/0x30
>>>>      [  149.962245]  [<ffffffff81010b45>]
do_softirq+0x46/0x81
>>>>      [  149.962245]  [<ffffffff8105d97b>]
irq_exit+0x57/0xb1
>>>>      [  149.962245]  [<ffffffff812a39d3>]
xen_evtchn_do_upcall+0x31/0x3e
>>>>      [  149.962245]  [<ffffffff814be76e>]
xen_hvm_callback_vector+0x6e/0x80
>>>>      [  149.962245]  <EOI>  [<ffffffff8102f2f1>] ?
native_safe_halt+0xb/0xd
>>>>      [  149.962245]  [<ffffffff81015b7e>]
default_idle+0x4e/0x86
>>>>      [  149.962245]  [<ffffffff8100e2ed>]
cpu_idle+0xae/0xe8
>>>>      [  149.962245]  [<ffffffff814934ee>]
rest_init+0x72/0x74
>>>>      [  149.962245]  [<ffffffff81b76b7d>]
start_kernel+0x3ab/0x3b6
>>>>      [  149.962245]  [<ffffffff81b762c4>]
>>>> x86_64_start_reservations+0xaf/0xb3
>>>>      [  149.962245]  [<ffffffff81b76140>] ?
early_idt_handlers+0x140/0x140
>>>>      [  149.962245]  [<ffffffff81b763ca>]
x86_64_start_kernel+0x102/0x111
>>>>      [  149.962245] ---[ end trace d8786cb7d6a57f8b ]---
>>>> 
>>>>      Full guest kernel dmesg attached to this email.
>>>>      The host is running F16 with Xen 4.1.2 and Linux 3.1.0
dom0 kernel.
>>>> 
>>>>      Xen cfgfile for the HVM domain:
>>>> 
>>>>      kernel = "hvmloader"
>>>>      builder=''hvm''
>>>>      device_model = ''qemu-dm''
>>>>      name = "f16test64hvm"
>>>>      memory = 1024
>>>>      vcpus=1
>>>>      pae=1
>>>>      acpi=1
>>>>      apic=1
>>>>      vif = [ ''type=ioemu, mac=00:16:3f:03:01:14,
bridge=virbr0'' ]
>>>>      disk = [
''phy:/dev/vg_f16/f16test64hvm,hda,w'',
>>>>     
''file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r''
]
>>>>      boot=''cd''
>>>>      xen_platform_pci=0
>>>>      on_poweroff = ''destroy''
>>>>      on_reboot   = ''restart''
>>>>      on_crash    = ''restart''
>>>>      sdl=0
>>>>      vnc=1
>>>>      vncpasswd=''''
>>>>      stdvga=0
>>>>      serial=''pty''
>>>>      tsc_mode=0
>>>>      usb=1
>>>>      usbdevice=''tablet''
>>>>      keymap=''fi''
>>>> 
>>>>      Using "model=e1000" instead for the vif works
OK.. no problems with
>>>> the
>>>>      emulated intel nic.
>>>> 
>>>>      Any ideas what the problem with the emulated realtek nic?
>>>> 
>>>>      Thanks,
>>>> 
>>>>      -- Pasi
>>>> 
>>>>      -----Inline Attachment Follows-----
>>>> 
>>>>      _______________________________________________
>>>>      Xen-devel mailing list
>>>>      [2]Xen-devel@lists.xensource.com
>>>>      [3]http://lists.xensource.com/xen-devel
>>>> 
>>>> References
>>>> 
>>>>    Visible links
>>>>    1.
file:///mc/compose?to=mockbuild@x86-10.phx2.fedoraproject.org
>>>>    2. file:///mc/compose?to=Xen-devel@lists.xensource.com
>>>>    3. http://lists.xensource.com/xen-devel
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2011-Nov-07 12:02 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Thu, 3 Nov 2011, Keir Fraser wrote:> On 03/11/2011 18:07, "Pasi KÃ¤rkkÃ¤inen" <pasik@iki.fi>
wrote:
> 
> > On Tue, Nov 01, 2011 at 10:56:06PM +0200, Pasi KÃ¤rkkÃ¤inen wrote:
> >> On Mon, Oct 31, 2011 at 09:29:24PM +0200, Pasi KÃ¤rkkÃ¤inen wrote:
> >>> On Mon, Oct 31, 2011 at 12:24:14PM -0700, Boris Derzhavets
wrote:
> >>>>    Seems to related
> >>>> 
> >>>>   
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829
> >>>> 
> >>> 
> >>> Thanks, that seems to be the same bug.
> >>> 
> >>> Is the bugfix patch from xen-unstable going to backported to
> >>> xen-4.1-testing.hg ?
> >>> (4.1 backported patch available on ubuntu''s launchpad
above..)
> >>> 
> >> 
> >> So the Ubuntu backport from xen-unstable to Xen 4.1.1 is here:
> >>
https://launchpadlibrarian.net/81948978/xen-pirq-resubmit-irq.patch
> >> 
> >> It seems to be shipping in Ubuntu 11.10 xen 4.1.1-2ubuntu4.1
packages.
> >> 
> >> Does that patch look suitable to be applied to xen-4.1-testing.hg
?
> >> This bug should be fixed for Xen 4.1.3.
> > 
> > Any comments? 
> 
> This looks like a backport of Stefano''s xen-unstable c/s 24007. I
would like
> him to submit/ack the backport, as it is not a trivial backport of the
> xen-unstable patch.
I would rather use the following backport. Compared to the other one it
returns EINVAL in PHYSDEVOP_irq_status_query when the arguments are not
correct.

---

diff -r 8c2d76193eaf xen/arch/x86/physdev.c
--- a/xen/arch/x86/physdev.c	Wed Nov 02 15:02:18 2011 +0000
+++ b/xen/arch/x86/physdev.c	Mon Nov 07 11:58:28 2011 +0000
@@ -261,6 +261,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         ret = -EINVAL;
         if ( eoi.irq >= v->domain->nr_pirqs )
             break;
+        spin_lock(&v->domain->event_lock);
         if ( v->domain->arch.pirq_eoi_map )
             evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]);
         if ( !is_hvm_domain(v->domain) ||
@@ -268,6 +269,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             ret = pirq_guest_eoi(v->domain, eoi.irq);
         else
             ret = 0;
+        if ( is_hvm_domain(v->domain) &&
+                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
+        {
+            struct hvm_irq *hvm_irq =
&v->domain->arch.hvm_domain.irq;
+            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
+
+            /* if this is a level irq and count > 0, send another
+             * notification */ 
+            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */
+                    && hvm_irq->gsi_assert_count[gsi] )
+                send_guest_pirq(v->domain, eoi.irq);
+        }
+        spin_unlock(&v->domain->event_lock);
         break;
     }
 
@@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             break;
         irq_status_query.flags = 0;
         if ( is_hvm_domain(v->domain) &&
-             domain_pirq_to_irq(v->domain, irq) <= 0 )
+                domain_pirq_to_irq(v->domain, irq) <= 0 &&
+                domain_pirq_to_emuirq(v->domain, irq) == IRQ_UNBOUND )
         {
-            ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0;
+            ret = -EINVAL;
             break;
         }
 
--8323329-1721688556-1320667338=:3519
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1721688556-1320667338=:3519--

Pasi Kärkkäinen

2011-Nov-08 11:24 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Mon, Nov 07, 2011 at 12:02:03PM +0000, Stefano Stabellini
wrote:> On Thu, 3 Nov 2011, Keir Fraser wrote:
> > On 03/11/2011 18:07, "Pasi KÃ?rkkÃ?inen"
<pasik@iki.fi> wrote:
> > 
> > > On Tue, Nov 01, 2011 at 10:56:06PM +0200, Pasi KÃ?rkkÃ?inen
wrote:
> > >> On Mon, Oct 31, 2011 at 09:29:24PM +0200, Pasi KÃ?rkkÃ?inen
wrote:
> > >>> On Mon, Oct 31, 2011 at 12:24:14PM -0700, Boris
Derzhavets wrote:
> > >>>>    Seems to related
> > >>>> 
> > >>>>   
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829
> > >>>> 
> > >>> 
> > >>> Thanks, that seems to be the same bug.
> > >>> 
> > >>> Is the bugfix patch from xen-unstable going to backported
to
> > >>> xen-4.1-testing.hg ?
> > >>> (4.1 backported patch available on ubuntu''s
launchpad above..)
> > >>> 
> > >> 
> > >> So the Ubuntu backport from xen-unstable to Xen 4.1.1 is
here:
> > >>
https://launchpadlibrarian.net/81948978/xen-pirq-resubmit-irq.patch
> > >> 
> > >> It seems to be shipping in Ubuntu 11.10 xen 4.1.1-2ubuntu4.1
packages.
> > >> 
> > >> Does that patch look suitable to be applied to
xen-4.1-testing.hg ?
> > >> This bug should be fixed for Xen 4.1.3.
> > > 
> > > Any comments? 
> > 
> > This looks like a backport of Stefano''s xen-unstable c/s
24007. I would like
> > him to submit/ack the backport, as it is not a trivial backport of the
> > xen-unstable patch.
> 
> I would rather use the following backport. Compared to the other one it
> returns EINVAL in PHYSDEVOP_irq_status_query when the arguments are not
> correct.
> 
Thanks! Mayoung added this patch in xen-4.1.2-1.1.fc14.src.rpm,
and binary rpms are built for Fedora 16 here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3495905

So people should test this patch (or the rpms above) and confirm 
that it fixes the emulated realtek/ne2k issues.

Thanks,

-- Pasi

> ---
> 
> diff -r 8c2d76193eaf xen/arch/x86/physdev.c
> --- a/xen/arch/x86/physdev.c	Wed Nov 02 15:02:18 2011 +0000
> +++ b/xen/arch/x86/physdev.c	Mon Nov 07 11:58:28 2011 +0000
> @@ -261,6 +261,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>          ret = -EINVAL;
>          if ( eoi.irq >= v->domain->nr_pirqs )
>              break;
> +        spin_lock(&v->domain->event_lock);
>          if ( v->domain->arch.pirq_eoi_map )
>              evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]);
>          if ( !is_hvm_domain(v->domain) ||
> @@ -268,6 +269,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              ret = pirq_guest_eoi(v->domain, eoi.irq);
>          else
>              ret = 0;
> +        if ( is_hvm_domain(v->domain) &&
> +                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
> +        {
> +            struct hvm_irq *hvm_irq =
&v->domain->arch.hvm_domain.irq;
> +            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
> +
> +            /* if this is a level irq and count > 0, send another
> +             * notification */ 
> +            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */
> +                    && hvm_irq->gsi_assert_count[gsi] )
> +                send_guest_pirq(v->domain, eoi.irq);
> +        }
> +        spin_unlock(&v->domain->event_lock);
>          break;
>      }
>  
> @@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              break;
>          irq_status_query.flags = 0;
>          if ( is_hvm_domain(v->domain) &&
> -             domain_pirq_to_irq(v->domain, irq) <= 0 )
> +                domain_pirq_to_irq(v->domain, irq) <= 0 &&
> +                domain_pirq_to_emuirq(v->domain, irq) == IRQ_UNBOUND )
>          {
> -            ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT :
0;
> +            ret = -EINVAL;
>              break;
>          }
>  
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Nov-11 07:02 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Tue, Nov 08, 2011 at 01:24:21PM +0200, Pasi Kärkkäinen
wrote:> On Mon, Nov 07, 2011 at 12:02:03PM +0000, Stefano Stabellini wrote:
> > On Thu, 3 Nov 2011, Keir Fraser wrote:
> > > On 03/11/2011 18:07, "Pasi KÃ?rkkÃ?inen"
<pasik@iki.fi> wrote:
> > > 
> > > > On Tue, Nov 01, 2011 at 10:56:06PM +0200, Pasi KÃ?rkkÃ?inen
wrote:
> > > >> On Mon, Oct 31, 2011 at 09:29:24PM +0200, Pasi
KÃ?rkkÃ?inen wrote:
> > > >>> On Mon, Oct 31, 2011 at 12:24:14PM -0700, Boris
Derzhavets wrote:
> > > >>>>    Seems to related
> > > >>>> 
> > > >>>>   
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/854829
> > > >>>> 
> > > >>> 
> > > >>> Thanks, that seems to be the same bug.
> > > >>> 
> > > >>> Is the bugfix patch from xen-unstable going to
backported to
> > > >>> xen-4.1-testing.hg ?
> > > >>> (4.1 backported patch available on ubuntu''s
launchpad above..)
> > > >>> 
> > > >> 
> > > >> So the Ubuntu backport from xen-unstable to Xen 4.1.1 is
here:
> > > >>
https://launchpadlibrarian.net/81948978/xen-pirq-resubmit-irq.patch
> > > >> 
> > > >> It seems to be shipping in Ubuntu 11.10 xen
4.1.1-2ubuntu4.1 packages.
> > > >> 
> > > >> Does that patch look suitable to be applied to
xen-4.1-testing.hg ?
> > > >> This bug should be fixed for Xen 4.1.3.
> > > > 
> > > > Any comments? 
> > > 
> > > This looks like a backport of Stefano''s xen-unstable c/s
24007. I would like
> > > him to submit/ack the backport, as it is not a trivial backport
of the
> > > xen-unstable patch.
> > 
> > I would rather use the following backport. Compared to the other one
it
> > returns EINVAL in PHYSDEVOP_irq_status_query when the arguments are
not
> > correct.
> > 
> 
> Thanks! Mayoung added this patch in xen-4.1.2-1.1.fc14.src.rpm,
> and binary rpms are built for Fedora 16 here:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3495905
> 
> So people should test this patch (or the rpms above) and confirm 
> that it fixes the emulated realtek/ne2k issues.
> 
Konrad confirmed the patch works with Xen 4.1.2 and realtek emulated nics.

So please commit the patch to xen-4.1-testing.hg.

-- Pasi

> 
> 
> > ---
> > 
> > diff -r 8c2d76193eaf xen/arch/x86/physdev.c
> > --- a/xen/arch/x86/physdev.c	Wed Nov 02 15:02:18 2011 +0000
> > +++ b/xen/arch/x86/physdev.c	Mon Nov 07 11:58:28 2011 +0000
> > @@ -261,6 +261,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
> >          ret = -EINVAL;
> >          if ( eoi.irq >= v->domain->nr_pirqs )
> >              break;
> > +        spin_lock(&v->domain->event_lock);
> >          if ( v->domain->arch.pirq_eoi_map )
> >              evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]);
> >          if ( !is_hvm_domain(v->domain) ||
> > @@ -268,6 +269,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
> >              ret = pirq_guest_eoi(v->domain, eoi.irq);
> >          else
> >              ret = 0;
> > +        if ( is_hvm_domain(v->domain) &&
> > +                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
> > +        {
> > +            struct hvm_irq *hvm_irq =
&v->domain->arch.hvm_domain.irq;
> > +            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
> > +
> > +            /* if this is a level irq and count > 0, send another
> > +             * notification */ 
> > +            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered
*/
> > +                    && hvm_irq->gsi_assert_count[gsi] )
> > +                send_guest_pirq(v->domain, eoi.irq);
> > +        }
> > +        spin_unlock(&v->domain->event_lock);
> >          break;
> >      }
> >  
> > @@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
> >              break;
> >          irq_status_query.flags = 0;
> >          if ( is_hvm_domain(v->domain) &&
> > -             domain_pirq_to_irq(v->domain, irq) <= 0 )
> > +                domain_pirq_to_irq(v->domain, irq) <= 0
&&
> > +                domain_pirq_to_emuirq(v->domain, irq) ==
IRQ_UNBOUND )
> >          {
> > -            ret = copy_to_guest(arg, &irq_status_query, 1) ?
-EFAULT : 0;
> > +            ret = -EINVAL;
> >              break;
> >          }
> >  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Nov-14 17:39 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Fri, Nov 11, 2011 at 09:02:50AM +0200, Pasi Kärkkäinen
wrote:> > > > >> 
> > > > >> So the Ubuntu backport from xen-unstable to Xen
4.1.1 is here:
> > > > >>
https://launchpadlibrarian.net/81948978/xen-pirq-resubmit-irq.patch
> > > > >> 
> > > > >> It seems to be shipping in Ubuntu 11.10 xen
4.1.1-2ubuntu4.1 packages.
> > > > >> 
> > > > >> Does that patch look suitable to be applied to
xen-4.1-testing.hg ?
> > > > >> This bug should be fixed for Xen 4.1.3.
> > > > > 
> > > > > Any comments? 
> > > > 
> > > > This looks like a backport of Stefano''s
xen-unstable c/s 24007. I would like
> > > > him to submit/ack the backport, as it is not a trivial
backport of the
> > > > xen-unstable patch.
> > > 
> > > I would rather use the following backport. Compared to the other
one it
> > > returns EINVAL in PHYSDEVOP_irq_status_query when the arguments
are not
> > > correct.
> > > 
> > 
> > Thanks! Mayoung added this patch in xen-4.1.2-1.1.fc14.src.rpm,
> > and binary rpms are built for Fedora 16 here:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=3495905
> > 
> > So people should test this patch (or the rpms above) and confirm 
> > that it fixes the emulated realtek/ne2k issues.
> > 
> 
> Konrad confirmed the patch works with Xen 4.1.2 and realtek emulated nics.
> 
> So please commit the patch to xen-4.1-testing.hg.
> 
I also tested Fedora 16 xen-4.1.2-1.2.fc16 rpms,
which includes stefano''s bugfix patch, and it seems to fix 
the emulated realtek nic problems.

So please go ahead and commit the fix to xen-4.1-testing.hg.

-- Pasi

> > 
> > > ---
> > > 
> > > diff -r 8c2d76193eaf xen/arch/x86/physdev.c
> > > --- a/xen/arch/x86/physdev.c	Wed Nov 02 15:02:18 2011 +0000
> > > +++ b/xen/arch/x86/physdev.c	Mon Nov 07 11:58:28 2011 +0000
> > > @@ -261,6 +261,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
> > >          ret = -EINVAL;
> > >          if ( eoi.irq >= v->domain->nr_pirqs )
> > >              break;
> > > +        spin_lock(&v->domain->event_lock);
> > >          if ( v->domain->arch.pirq_eoi_map )
> > >             
evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]);
> > >          if ( !is_hvm_domain(v->domain) ||
> > > @@ -268,6 +269,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
> > >              ret = pirq_guest_eoi(v->domain, eoi.irq);
> > >          else
> > >              ret = 0;
> > > +        if ( is_hvm_domain(v->domain) &&
> > > +                domain_pirq_to_emuirq(v->domain, eoi.irq)
> 0 )
> > > +        {
> > > +            struct hvm_irq *hvm_irq =
&v->domain->arch.hvm_domain.irq;
> > > +            int gsi = domain_pirq_to_emuirq(v->domain,
eoi.irq);
> > > +
> > > +            /* if this is a level irq and count > 0, send
another
> > > +             * notification */ 
> > > +            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge
triggered */
> > > +                    && hvm_irq->gsi_assert_count[gsi]
)
> > > +                send_guest_pirq(v->domain, eoi.irq);
> > > +        }
> > > +        spin_unlock(&v->domain->event_lock);
> > >          break;
> > >      }
> > >  
> > > @@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
> > >              break;
> > >          irq_status_query.flags = 0;
> > >          if ( is_hvm_domain(v->domain) &&
> > > -             domain_pirq_to_irq(v->domain, irq) <= 0 )
> > > +                domain_pirq_to_irq(v->domain, irq) <= 0
&&
> > > +                domain_pirq_to_emuirq(v->domain, irq) ==
IRQ_UNBOUND )
> > >          {
> > > -            ret = copy_to_guest(arg, &irq_status_query, 1) ?
-EFAULT : 0;
> > > +            ret = -EINVAL;
> > >              break;
> > >          }
> > >  
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Jackson

2011-Nov-14 17:47 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Pasi Kärkkäinen writes ("Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest
realtek nic problems (eth0 8139cp transmit queue timed
out)"):> So please go ahead and commit the fix to xen-4.1-testing.hg.
Keir, will you do this ?  If you prefer I can do it, but I need the
blessing of a hypervisor maintainer.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Nov-16 13:33 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Mon, Nov 14, 2011 at 05:47:11PM +0000, Ian Jackson
wrote:> Pasi Kärkkäinen writes ("Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest
realtek nic problems (eth0 8139cp transmit queue timed out)"):
> > So please go ahead and commit the fix to xen-4.1-testing.hg.
> 
> Keir, will you do this ?  If you prefer I can do it, but I need the
> blessing of a hypervisor maintainer.
> 
Ping? 


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2011-Nov-16 15:00 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On 16/11/2011 13:33, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> On Mon, Nov 14, 2011 at 05:47:11PM +0000, Ian Jackson wrote:
>> Pasi Kärkkäinen writes ("Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM
guest realtek
>> nic problems (eth0 8139cp transmit queue timed out)"):
>>> So please go ahead and commit the fix to xen-4.1-testing.hg.
>> 
>> Keir, will you do this ?  If you prefer I can do it, but I need the
>> blessing of a hypervisor maintainer.
>> 
> 
> Ping? 
I responded on 3rd November:

"This looks like a backport of Stefano''s xen-unstable c/s 24007. I
would
like him to submit/ack the backport, as it is not a trivial backport of the
xen-unstable patch."

 -- Keir
> 
> -- Pasi
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Nov-16 15:53 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Wed, Nov 16, 2011 at 03:00:25PM +0000, Keir Fraser
wrote:> On 16/11/2011 13:33, "Pasi Kärkkäinen" <pasik@iki.fi>
wrote:
> 
> > On Mon, Nov 14, 2011 at 05:47:11PM +0000, Ian Jackson wrote:
> >> Pasi Kärkkäinen writes ("Re: [Xen-devel] [PATCH] Xen 4.1.2
HVM guest realtek
> >> nic problems (eth0 8139cp transmit queue timed out)"):
> >>> So please go ahead and commit the fix to xen-4.1-testing.hg.
> >> 
> >> Keir, will you do this ?  If you prefer I can do it, but I need
the
> >> blessing of a hypervisor maintainer.
> >> 
> > 
> > Ping? 
> 
> I responded on 3rd November:
> 
> "This looks like a backport of Stefano''s xen-unstable c/s
24007. I would
> like him to submit/ack the backport, as it is not a trivial backport of the
> xen-unstable patch."
> 
Stefano already submitted a new patch for this..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Nov-16 16:01 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Wed, Nov 16, 2011 at 05:53:47PM +0200, Pasi Kärkkäinen
wrote:> On Wed, Nov 16, 2011 at 03:00:25PM +0000, Keir Fraser wrote:
> > On 16/11/2011 13:33, "Pasi Kärkkäinen" <pasik@iki.fi>
wrote:
> > 
> > > On Mon, Nov 14, 2011 at 05:47:11PM +0000, Ian Jackson wrote:
> > >> Pasi Kärkkäinen writes ("Re: [Xen-devel] [PATCH] Xen
4.1.2 HVM guest realtek
> > >> nic problems (eth0 8139cp transmit queue timed out)"):
> > >>> So please go ahead and commit the fix to
xen-4.1-testing.hg.
> > >> 
> > >> Keir, will you do this ?  If you prefer I can do it, but I
need the
> > >> blessing of a hypervisor maintainer.
> > >> 
> > > 
> > > Ping? 
> > 
> > I responded on 3rd November:
> > 
> > "This looks like a backport of Stefano''s xen-unstable
c/s 24007. I would
> > like him to submit/ack the backport, as it is not a trivial backport
of the
> > xen-unstable patch."
> > 
> 
> Stefano already submitted a new patch for this..
> 
.. which is here (Nov 7th):
http://lists.xensource.com/archives/html/xen-devel/2011-11/msg00321.html

Both Konrad and I tested that patch with Xen 4.1.2, and it fixes the bug.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

M A Young

2011-Nov-16 16:03 UTC

head link

Re: [Fedora-xen] [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Keir Fraser

2011-Nov-16 16:34 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On 16/11/2011 15:53, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> On Wed, Nov 16, 2011 at 03:00:25PM +0000, Keir Fraser wrote:
>> On 16/11/2011 13:33, "Pasi Kärkkäinen" <pasik@iki.fi>
wrote:
>> 
>>> On Mon, Nov 14, 2011 at 05:47:11PM +0000, Ian Jackson wrote:
>>>> Pasi Kärkkäinen writes ("Re: [Xen-devel] [PATCH] Xen 4.1.2
HVM guest
>>>> realtek
>>>> nic problems (eth0 8139cp transmit queue timed out)"):
>>>>> So please go ahead and commit the fix to
xen-4.1-testing.hg.
>>>> 
>>>> Keir, will you do this ?  If you prefer I can do it, but I need
the
>>>> blessing of a hypervisor maintainer.
>>>> 
>>> 
>>> Ping? 
>> 
>> I responded on 3rd November:
>> 
>> "This looks like a backport of Stefano''s xen-unstable c/s
24007. I would
>> like him to submit/ack the backport, as it is not a trivial backport of
the
>> xen-unstable patch."
>> 
> 
> Stefano already submitted a new patch for this..
So he did. I''ve now applied it to xen-4.1-testing.

 -- Keir
> -- Pasi
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2011-Nov-16 16:44 UTC

head link

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

On Wed, Nov 16, 2011 at 04:34:56PM +0000, Keir Fraser
wrote:> On 16/11/2011 15:53, "Pasi Kärkkäinen" <pasik@iki.fi>
wrote:
> 
> > On Wed, Nov 16, 2011 at 03:00:25PM +0000, Keir Fraser wrote:
> >> On 16/11/2011 13:33, "Pasi Kärkkäinen"
<pasik@iki.fi> wrote:
> >> 
> >>> On Mon, Nov 14, 2011 at 05:47:11PM +0000, Ian Jackson wrote:
> >>>> Pasi Kärkkäinen writes ("Re: [Xen-devel] [PATCH] Xen
4.1.2 HVM guest
> >>>> realtek
> >>>> nic problems (eth0 8139cp transmit queue timed
out)"):
> >>>>> So please go ahead and commit the fix to
xen-4.1-testing.hg.
> >>>> 
> >>>> Keir, will you do this ?  If you prefer I can do it, but I
need the
> >>>> blessing of a hypervisor maintainer.
> >>>> 
> >>> 
> >>> Ping? 
> >> 
> >> I responded on 3rd November:
> >> 
> >> "This looks like a backport of Stefano''s
xen-unstable c/s 24007. I would
> >> like him to submit/ack the backport, as it is not a trivial
backport of the
> >> xen-unstable patch."
> >> 
> > 
> > Stefano already submitted a new patch for this..
> 
> So he did. I''ve now applied it to xen-4.1-testing.
> 
Great, thanks!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen devel - Oct 2011 - Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

[Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out) [PATCH]

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Fedora-xen] [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)

Re: [Xen-devel] [PATCH] Xen 4.1.2 HVM guest realtek nic problems (eth0 8139cp transmit queue timed out)