* vif backend configuration times out
@ 2012-08-06 17:39 Olaf Hering
2012-08-07 5:42 ` Ian Campbell
0 siblings, 1 reply; 12+ messages in thread
From: Olaf Hering @ 2012-08-06 17:39 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
With current xen-unstable 25733:353bc0801b11 the attached hvm.cfg does
not start anymore with a SLES11SP2 dom0 kernel, but it starts if I run a
3.5 pvops dom0 kernel. I have no modifications other than the stubdom -j
patch.
The output from this command is attached:
xl -vvvv create -d -f /root/xenpaging/sles11sp2_full_xenpaging_local.cfg 2>&1 | tee xl-create-`uname -r`.txt &
Any ideas how to fix this timeout error?
Olaf
...
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x62bf88 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:600:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 still waiting state 1
libxl: debug: libxl_event.c:614:devstate_timeout: backend /local/domain/0/backend/vif/2/0/state wanted state 2 timed out
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x62bf88 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: deregister slotnum=3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x62bf88: deregister unregistered
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vif/2/0
libxl: error: libxl_create.c:1070:domcreate_attach_pci: unable to add nic devices
...
[-- Attachment #2: xl-create-3.0.34-0.7-xen.txt --]
[-- Type: text/plain, Size: 12865 bytes --]
WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware
WARNING: ignoring device_model directive.
WARNING: Use "device_model_override" instead if you really want a non-default device_model
Parsing config from /root/xenpaging/sles11sp2_full_xenpaging_local.cfg
{
"domid": null,
"config": {
"c_info": {
"type": "hvm",
"hap": "<default>",
"oos": "<default>",
"ssidref": 0,
"name": "sles11sp2_full_xenpaging_local",
"uuid": "f0311246-c8e4-4685-8549-321cd34c8f14",
"xsdata": {
},
"platformdata": {
},
"poolid": 0,
"run_hotplug_scripts": "True"
},
"b_info": {
"max_vcpus": 4,
"avail_vcpus": [
0,
1,
2,
3
],
"cpumap": [
],
"numa_placement": "<default>",
"tsc_mode": "default",
"max_memkb": 1048576,
"target_memkb": 1048576,
"video_memkb": -1,
"shadow_memkb": 12288,
"rtc_timeoffset": 0,
"localtime": "False",
"disable_migrate": "<default>",
"cpuid": [
],
"blkdev_start": null,
"device_model_version": null,
"device_model_stubdomain": "<default>",
"device_model": null,
"device_model_ssidref": 0,
"extra": [
],
"extra_pv": [
],
"extra_hvm": [
],
"sched_params": {
"sched": "unknown",
"weight": -1,
"cap": -1,
"period": -1,
"slice": -1,
"latency": -1,
"extratime": -1
},
"u": {
"firmware": null,
"bios": null,
"pae": "True",
"apic": "<default>",
"acpi": "True",
"acpi_s3": "<default>",
"acpi_s4": "<default>",
"nx": "<default>",
"viridian": "<default>",
"timeoffset": null,
"hpet": "<default>",
"vpt_align": "<default>",
"timer_mode": null,
"nested_hvm": "<default>",
"incr_generationid": "False",
"nographic": "<default>",
"vga": {
"kind": "cirrus"
},
"vnc": {
"enable": "True",
"listen": null,
"passwd": null,
"display": 0,
"findunused": "True"
},
"keymap": "de",
"sdl": {
"enable": "<default>",
"opengl": "<default>",
"display": null,
"xauthority": null
},
"spice": {
"enable": "<default>",
"port": 0,
"tls_port": 0,
"host": null,
"disable_ticketing": "<default>",
"passwd": null,
"agent_mouse": "<default>"
},
"gfx_passthru": "<default>",
"serial": "pty",
"boot": "d",
"usb": "<default>",
"usbdevice": null,
"soundhw": null,
"xen_platform_pci": "<default>"
}
},
"disks": [
{
"backend_domid": 0,
"pdev_path": "/vmimages/vdisk-sles11sp2_full_xenpaging_local-disk0",
"vdev": "hda",
"backend": "unknown",
"format": "raw",
"script": null,
"removable": 0,
"readwrite": 1,
"is_cdrom": 0
},
{
"backend_domid": 0,
"pdev_path": "/bax.arch.suse.de-olaf_xenimages/olaf/bax-olaf_xenimages/olaf_xenimages/SLES-11-SP2-DVD-x86_64-GMC-DVD1.iso",
"vdev": "hdc",
"backend": "unknown",
"format": "raw",
"script": null,
"removable": 1,
"readwrite": 0,
"is_cdrom": 1
}
],
"nics": [
{
"backend_domid": 0,
"devid": 0,
"mtu": 0,
"model": null,
"mac": "00:00:00:00:00:00",
"ip": null,
"bridge": "br0",
"ifname": null,
"script": null,
"nictype": null,
"rate_bytes_per_interval": 0,
"rate_interval_usecs": 0
}
],
"pcidevs": [
],
"vfbs": [
],
"vkbs": [
],
"on_poweroff": "destroy",
"on_reboot": "restart",
"on_watchdog": "destroy",
"on_crash": "destroy"
}
}
libxl: debug: libxl_create.c:1147:do_domain_create: ao 0x623820: create: how=(nil) callback=(nil) poller=0x629010
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, backend tap unsuitable because blktap not available
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend qdisk
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdc, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hdc, backend tap unsuitable because blktap not available
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hdc, using backend qdisk
libxl: debug: libxl_create.c:678:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x627330: deregister unregistered
libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=2, nr_cpus=24, nr_vcpus=28, free_memkb=1522
libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 2 nodes, 24 cpus and 1522 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9c324
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19c324
xc: info: VIRTUAL MEMORY ARRANGEMENT:
Loader: 0000000000100000->000000000019c324
TOTAL: 0000000000000000->000000003f800000
ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
4KB PAGES: 0x0000000000000200
2MB PAGES: 0x00000000000001fb
1GB PAGES: 0x0000000000000000
xc: detail: elf_load_binary: phdr 0 at 0x0x7fa70f484000 -> 0x0x7fa70f517194
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=qdisk
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=qdisk
libxl: debug: libxl_dm.c:1142:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-dm with arguments:
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: /usr/lib/xen/bin/qemu-dm
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -d
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 2
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -domain-name
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: sles11sp2_full_xenpaging_local
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vnc
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 127.0.0.1:0
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vncunused
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -k
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: de
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -serial
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: pty
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -videoram
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 8
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -boot
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: d
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -acpi
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vcpus
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 4
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vcpu_avail
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 0x0f
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -net
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: nic,vlan=0,macaddr=00:16:3e:10:dd:52,model=rtl8139
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -net
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: tap,vlan=0,ifname=vif2.0-emu,bridge=br0,script=no,downscript=no
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -M
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: xenfv
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x627568 wpath=/local/domain/0/device-model/2/state token=3/0: register slotnum=3
libxl: debug: libxl_create.c:1160:do_domain_create: ao 0x623820: inprogress: poller=0x629010, flags=i
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x627568 wpath=/local/domain/0/device-model/2/state token=3/0: event epath=/local/domain/0/device-model/2/state
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x627568 wpath=/local/domain/0/device-model/2/state token=3/0: event epath=/local/domain/0/device-model/2/state
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x627568 wpath=/local/domain/0/device-model/2/state token=3/0: deregister slotnum=3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x627568: deregister unregistered
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x62bf88 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: register slotnum=3
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x62bf88 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:600:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 still waiting state 1
libxl: debug: libxl_event.c:614:devstate_timeout: backend /local/domain/0/backend/vif/2/0/state wanted state 2 timed out
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x62bf88 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: deregister slotnum=3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x62bf88: deregister unregistered
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vif/2/0
libxl: error: libxl_create.c:1070:domcreate_attach_pci: unable to add nic devices
libxl: debug: libxl_dm.c:1248:libxl__destroy_device_model: Device Model signaled
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x62d218 wpath=/local/domain/0/backend/vif/2/0/state token=3/2: register slotnum=3
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x62d218 wpath=/local/domain/0/backend/vif/2/0/state token=3/2: event epath=/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:600:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 6 still waiting state 5
libxl: debug: libxl_event.c:614:devstate_timeout: backend /local/domain/0/backend/vif/2/0/state wanted state 6 timed out
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x62d218 wpath=/local/domain/0/backend/vif/2/0/state token=3/2: deregister slotnum=3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x62d218: deregister unregistered
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vif/2/0
libxl: error: libxl.c:1463:devices_destroy_cb: libxl__devices_destroy failed for 2
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623820: complete, rc=-3
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623820: destroy
xc: debug: hypercall buffer: total allocations:680 total releases:680
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:672 misses:4 toobig:4
[-- Attachment #3: xl-create-3.5.0-3.home_olh_kernel_sles11sp1.1-kernel-linux-3_5.txt --]
[-- Type: text/plain, Size: 12029 bytes --]
WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware
WARNING: ignoring device_model directive.
WARNING: Use "device_model_override" instead if you really want a non-default device_model
Parsing config from /root/xenpaging/sles11sp2_full_xenpaging_local.cfg
{
"domid": null,
"config": {
"c_info": {
"type": "hvm",
"hap": "<default>",
"oos": "<default>",
"ssidref": 0,
"name": "sles11sp2_full_xenpaging_local",
"uuid": "f0311246-c8e4-4685-8549-321cd34c8f14",
"xsdata": {
},
"platformdata": {
},
"poolid": 0,
"run_hotplug_scripts": "True"
},
"b_info": {
"max_vcpus": 4,
"avail_vcpus": [
0,
1,
2,
3
],
"cpumap": [
],
"numa_placement": "<default>",
"tsc_mode": "default",
"max_memkb": 1048576,
"target_memkb": 1048576,
"video_memkb": -1,
"shadow_memkb": 12288,
"rtc_timeoffset": 0,
"localtime": "False",
"disable_migrate": "<default>",
"cpuid": [
],
"blkdev_start": null,
"device_model_version": null,
"device_model_stubdomain": "<default>",
"device_model": null,
"device_model_ssidref": 0,
"extra": [
],
"extra_pv": [
],
"extra_hvm": [
],
"sched_params": {
"sched": "unknown",
"weight": -1,
"cap": -1,
"period": -1,
"slice": -1,
"latency": -1,
"extratime": -1
},
"u": {
"firmware": null,
"bios": null,
"pae": "True",
"apic": "<default>",
"acpi": "True",
"acpi_s3": "<default>",
"acpi_s4": "<default>",
"nx": "<default>",
"viridian": "<default>",
"timeoffset": null,
"hpet": "<default>",
"vpt_align": "<default>",
"timer_mode": null,
"nested_hvm": "<default>",
"incr_generationid": "False",
"nographic": "<default>",
"vga": {
"kind": "cirrus"
},
"vnc": {
"enable": "True",
"listen": null,
"passwd": null,
"display": 0,
"findunused": "True"
},
"keymap": "de",
"sdl": {
"enable": "<default>",
"opengl": "<default>",
"display": null,
"xauthority": null
},
"spice": {
"enable": "<default>",
"port": 0,
"tls_port": 0,
"host": null,
"disable_ticketing": "<default>",
"passwd": null,
"agent_mouse": "<default>"
},
"gfx_passthru": "<default>",
"serial": "pty",
"boot": "d",
"usb": "<default>",
"usbdevice": null,
"soundhw": null,
"xen_platform_pci": "<default>"
}
},
"disks": [
{
"backend_domid": 0,
"pdev_path": "/vmimages/vdisk-sles11sp2_full_xenpaging_local-disk0",
"vdev": "hda",
"backend": "unknown",
"format": "raw",
"script": null,
"removable": 0,
"readwrite": 1,
"is_cdrom": 0
},
{
"backend_domid": 0,
"pdev_path": "/bax.arch.suse.de-olaf_xenimages/olaf/bax-olaf_xenimages/olaf_xenimages/SLES-11-SP2-DVD-x86_64-GMC-DVD1.iso",
"vdev": "hdc",
"backend": "unknown",
"format": "raw",
"script": null,
"removable": 1,
"readwrite": 0,
"is_cdrom": 1
}
],
"nics": [
{
"backend_domid": 0,
"devid": 0,
"mtu": 0,
"model": null,
"mac": "00:00:00:00:00:00",
"ip": null,
"bridge": "br0",
"ifname": null,
"script": null,
"nictype": null,
"rate_bytes_per_interval": 0,
"rate_interval_usecs": 0
}
],
"pcidevs": [
],
"vfbs": [
],
"vkbs": [
],
"on_poweroff": "destroy",
"on_reboot": "restart",
"on_watchdog": "destroy",
"on_crash": "destroy"
}
}
libxl: debug: libxl_create.c:1147:do_domain_create: ao 0x623820: create: how=(nil) callback=(nil) poller=0x629010
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, backend tap unsuitable because blktap not available
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend qdisk
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdc, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hdc, backend tap unsuitable because blktap not available
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hdc, using backend qdisk
libxl: debug: libxl_create.c:678:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x627330: deregister unregistered
libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=2, nr_cpus=24, nr_vcpus=28, free_memkb=1490
libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 2 nodes, 24 cpus and 1490 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9c324
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19c324
xc: info: VIRTUAL MEMORY ARRANGEMENT:
Loader: 0000000000100000->000000000019c324
TOTAL: 0000000000000000->000000003f800000
ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
4KB PAGES: 0x0000000000000200
2MB PAGES: 0x00000000000001fb
1GB PAGES: 0x0000000000000000
xc: detail: elf_load_binary: phdr 0 at 0x0x7f739b580000 -> 0x0x7f739b613194
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=qdisk
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=qdisk
libxl: debug: libxl_dm.c:1142:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-dm with arguments:
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: /usr/lib/xen/bin/qemu-dm
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -d
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 2
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -domain-name
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: sles11sp2_full_xenpaging_local
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vnc
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 127.0.0.1:0
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vncunused
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -k
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: de
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -serial
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: pty
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -videoram
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 8
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -boot
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: d
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -acpi
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vcpus
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 4
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vcpu_avail
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 0x0f
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -net
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: nic,vlan=0,macaddr=00:16:3e:0f:f7:4c,model=rtl8139
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -net
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: tap,vlan=0,ifname=vif2.0-emu,bridge=br0,script=no,downscript=no
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -M
libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: xenfv
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x627568 wpath=/local/domain/0/device-model/2/state token=3/0: register slotnum=3
libxl: debug: libxl_create.c:1160:do_domain_create: ao 0x623820: inprogress: poller=0x629010, flags=i
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x627568 wpath=/local/domain/0/device-model/2/state token=3/0: event epath=/local/domain/0/device-model/2/state
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x627568 wpath=/local/domain/0/device-model/2/state token=3/0: event epath=/local/domain/0/device-model/2/state
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x627568 wpath=/local/domain/0/device-model/2/state token=3/0: deregister slotnum=3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x627568: deregister unregistered
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x62c658 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: register slotnum=3
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x62c658 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:600:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 still waiting state 1
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x62c658 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 ok
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x62c658 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: deregister slotnum=3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x62c658: deregister unregistered
libxl: debug: libxl_device.c:916:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online
libxl: debug: libxl_device.c:916:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge add
libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao 0x623820: progress report: ignored
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623820: complete, rc=0
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623820: destroy
xc: debug: hypercall buffer: total allocations:582 total releases:582
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:574 misses:4 toobig:4
Daemon running with PID 5091
[-- Attachment #4: sles11sp2_full_xenpaging_local.cfg --]
[-- Type: text/plain, Size: 695 bytes --]
name="sles11sp2_full_xenpaging_local"
description="None"
uuid="f0311246-c8e4-4685-8549-321cd34c8f14"
memory=1024
vcpus=4
actmem=234
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=0
keymap="de"
vif=[ 'bridge=br0' ]
# HVM
builder="hvm"
device_model="/usr/lib/xen/bin/qemu-dm"
kernel="/usr/lib/xen/boot/hvmloader"
boot="d"
disk=[ 'file:/vmimages/vdisk-sles11sp2_full_xenpaging_local-disk0,hda,w', 'file:/bax.arch.suse.de-olaf_xenimages/olaf/bax-olaf_xenimages/olaf_xenimages/SLES-11-SP2-DVD-x86_64-GMC-DVD1.iso,hdc:cdrom,r', ]
stdvga=0
vnc=1
vncunused=1
extid=0
acpi=1
pae=1
serial="pty"
xenpaging_extra=[ '-f', '/dev/shm/pagefile-sles11sp2_full_xenpaging_local', '-v' ]
[-- Attachment #5: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-06 17:39 vif backend configuration times out Olaf Hering
@ 2012-08-07 5:42 ` Ian Campbell
2012-08-07 15:25 ` Olaf Hering
0 siblings, 1 reply; 12+ messages in thread
From: Ian Campbell @ 2012-08-07 5:42 UTC (permalink / raw)
To: Olaf Hering; +Cc: xen-devel@lists.xen.org
On Mon, 2012-08-06 at 18:39 +0100, Olaf Hering wrote:
> With current xen-unstable 25733:353bc0801b11 the attached hvm.cfg does
> not start anymore with a SLES11SP2 dom0 kernel, but it starts if I run a
> 3.5 pvops dom0 kernel. I have no modifications other than the stubdom -j
> patch.
>
> The output from this command is attached:
> xl -vvvv create -d -f /root/xenpaging/sles11sp2_full_xenpaging_local.cfg 2>&1 | tee xl-create-`uname -r`.txt &
>
> Any ideas how to fix this timeout error?
The tools are waiting for the backend to move from state 1
(XenbusStateInitialising) to state 2 (XenbusStateInitWait). A backend
driver typically makes that transition at the end of its probe function
-- what is the SLES11SP2 netback waiting for? Or is it failing to init,
in which case perhaps there is an error node in XS?
>
> Olaf
>
> ...
> libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x62bf88 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state
> libxl: debug: libxl_event.c:600:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 still waiting state 1
> libxl: debug: libxl_event.c:614:devstate_timeout: backend /local/domain/0/backend/vif/2/0/state wanted state 2 timed out
> libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x62bf88 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: deregister slotnum=3
> libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x62bf88: deregister unregistered
> libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vif/2/0
> libxl: error: libxl_create.c:1070:domcreate_attach_pci: unable to add nic devices
> ...
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-07 5:42 ` Ian Campbell
@ 2012-08-07 15:25 ` Olaf Hering
2012-08-07 15:33 ` Ian Campbell
0 siblings, 1 reply; 12+ messages in thread
From: Olaf Hering @ 2012-08-07 15:25 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xen.org
On Tue, Aug 07, Ian Campbell wrote:
> On Mon, 2012-08-06 at 18:39 +0100, Olaf Hering wrote:
> > With current xen-unstable 25733:353bc0801b11 the attached hvm.cfg does
> > not start anymore with a SLES11SP2 dom0 kernel, but it starts if I run a
> > 3.5 pvops dom0 kernel. I have no modifications other than the stubdom -j
> > patch.
> >
> > The output from this command is attached:
> > xl -vvvv create -d -f /root/xenpaging/sles11sp2_full_xenpaging_local.cfg 2>&1 | tee xl-create-`uname -r`.txt &
> >
> > Any ideas how to fix this timeout error?
>
> The tools are waiting for the backend to move from state 1
> (XenbusStateInitialising) to state 2 (XenbusStateInitWait). A backend
> driver typically makes that transition at the end of its probe function
> -- what is the SLES11SP2 netback waiting for? Or is it failing to init,
> in which case perhaps there is an error node in XS?
I think there is a difference between the two kernels. The pvops kernel
goes into state 2 right away (I cant tell from repeated xenstore-ls runs
if it had also state 1).
The sles11 kernel remains in state 1. Did the expectations of libxl
change recently? xl create used to work not too long ago.
xm does not work either, so the change is most likely in the scripts.
Olaf
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-07 15:25 ` Olaf Hering
@ 2012-08-07 15:33 ` Ian Campbell
2012-08-08 17:28 ` Olaf Hering
0 siblings, 1 reply; 12+ messages in thread
From: Ian Campbell @ 2012-08-07 15:33 UTC (permalink / raw)
To: Olaf Hering; +Cc: xen-devel@lists.xen.org
On Tue, 2012-08-07 at 16:25 +0100, Olaf Hering wrote:
> On Tue, Aug 07, Ian Campbell wrote:
>
> > On Mon, 2012-08-06 at 18:39 +0100, Olaf Hering wrote:
> > > With current xen-unstable 25733:353bc0801b11 the attached hvm.cfg does
> > > not start anymore with a SLES11SP2 dom0 kernel, but it starts if I run a
> > > 3.5 pvops dom0 kernel. I have no modifications other than the stubdom -j
> > > patch.
> > >
> > > The output from this command is attached:
> > > xl -vvvv create -d -f /root/xenpaging/sles11sp2_full_xenpaging_local.cfg 2>&1 | tee xl-create-`uname -r`.txt &
> > >
> > > Any ideas how to fix this timeout error?
> >
> > The tools are waiting for the backend to move from state 1
> > (XenbusStateInitialising) to state 2 (XenbusStateInitWait). A backend
> > driver typically makes that transition at the end of its probe function
> > -- what is the SLES11SP2 netback waiting for? Or is it failing to init,
> > in which case perhaps there is an error node in XS?
>
> I think there is a difference between the two kernels. The pvops kernel
> goes into state 2 right away (I cant tell from repeated xenstore-ls runs
> if it had also state 1).
> The sles11 kernel remains in state 1.
What is it waiting for?
> Did the expectations of libxl
> change recently? xl create used to work not too long ago.
I don't think the expectation has changed but the implementation is
probably more picky since Roger's hotplug patches.
> xm does not work either, so the change is most likely in the scripts.
If you are switching from xl to xm then you should either reboot or
remove libxl/disable_udev in xenstore manually.
Other than that nor much has changed in the scripts either. Are you sure
it isn't the kernel which has changed?
Ian.
>
> Olaf
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-07 15:33 ` Ian Campbell
@ 2012-08-08 17:28 ` Olaf Hering
2012-08-09 8:32 ` Ian Campbell
0 siblings, 1 reply; 12+ messages in thread
From: Olaf Hering @ 2012-08-08 17:28 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xen.org
On Tue, Aug 07, Ian Campbell wrote:
> On Tue, 2012-08-07 at 16:25 +0100, Olaf Hering wrote:
> > On Tue, Aug 07, Ian Campbell wrote:
> >
> > > On Mon, 2012-08-06 at 18:39 +0100, Olaf Hering wrote:
> > > > With current xen-unstable 25733:353bc0801b11 the attached hvm.cfg does
> > > > not start anymore with a SLES11SP2 dom0 kernel, but it starts if I run a
> > > > 3.5 pvops dom0 kernel. I have no modifications other than the stubdom -j
> > > > patch.
> > > >
> > > > The output from this command is attached:
> > > > xl -vvvv create -d -f /root/xenpaging/sles11sp2_full_xenpaging_local.cfg 2>&1 | tee xl-create-`uname -r`.txt &
> > > >
> > > > Any ideas how to fix this timeout error?
> > >
> > > The tools are waiting for the backend to move from state 1
> > > (XenbusStateInitialising) to state 2 (XenbusStateInitWait). A backend
> > > driver typically makes that transition at the end of its probe function
> > > -- what is the SLES11SP2 netback waiting for? Or is it failing to init,
> > > in which case perhaps there is an error node in XS?
> >
> > I think there is a difference between the two kernels. The pvops kernel
> > goes into state 2 right away (I cant tell from repeated xenstore-ls runs
> > if it had also state 1).
> > The sles11 kernel remains in state 1.
>
> What is it waiting for?
I have no idea, have to browse code debug it.
A quick test with plain sles11sp2+xend and xm start -p shows that
/local/domain/0/backend/vif/1/0/state finally gets into state 2.
Looks like something to fix before 4.2.
> > Did the expectations of libxl
> > change recently? xl create used to work not too long ago.
>
> I don't think the expectation has changed but the implementation is
> probably more picky since Roger's hotplug patches.
>
> > xm does not work either, so the change is most likely in the scripts.
>
> If you are switching from xl to xm then you should either reboot or
> remove libxl/disable_udev in xenstore manually.
>
> Other than that nor much has changed in the scripts either. Are you sure
> it isn't the kernel which has changed?
The kernel is ok.
Olaf
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-08 17:28 ` Olaf Hering
@ 2012-08-09 8:32 ` Ian Campbell
2012-08-09 14:34 ` Olaf Hering
0 siblings, 1 reply; 12+ messages in thread
From: Ian Campbell @ 2012-08-09 8:32 UTC (permalink / raw)
To: Olaf Hering; +Cc: xen-devel@lists.xen.org
On Wed, 2012-08-08 at 18:28 +0100, Olaf Hering wrote:
> On Tue, Aug 07, Ian Campbell wrote:
>
> > On Tue, 2012-08-07 at 16:25 +0100, Olaf Hering wrote:
> > > On Tue, Aug 07, Ian Campbell wrote:
> > >
> > > > On Mon, 2012-08-06 at 18:39 +0100, Olaf Hering wrote:
> > > > > With current xen-unstable 25733:353bc0801b11 the attached hvm.cfg does
> > > > > not start anymore with a SLES11SP2 dom0 kernel, but it starts if I run a
> > > > > 3.5 pvops dom0 kernel. I have no modifications other than the stubdom -j
> > > > > patch.
> > > > >
> > > > > The output from this command is attached:
> > > > > xl -vvvv create -d -f /root/xenpaging/sles11sp2_full_xenpaging_local.cfg 2>&1 | tee xl-create-`uname -r`.txt &
> > > > >
> > > > > Any ideas how to fix this timeout error?
> > > >
> > > > The tools are waiting for the backend to move from state 1
> > > > (XenbusStateInitialising) to state 2 (XenbusStateInitWait). A backend
> > > > driver typically makes that transition at the end of its probe function
> > > > -- what is the SLES11SP2 netback waiting for? Or is it failing to init,
> > > > in which case perhaps there is an error node in XS?
> > >
> > > I think there is a difference between the two kernels. The pvops kernel
> > > goes into state 2 right away (I cant tell from repeated xenstore-ls runs
> > > if it had also state 1).
> > > The sles11 kernel remains in state 1.
> >
> > What is it waiting for?
>
> I have no idea, have to browse code debug it.
> A quick test with plain sles11sp2+xend and xm start -p shows that
> /local/domain/0/backend/vif/1/0/state finally gets into state 2.
When you say "finally" do you mean that it takes an unusually long time?
> Looks like something to fix before 4.2.
>
>
> > > Did the expectations of libxl
> > > change recently? xl create used to work not too long ago.
> >
> > I don't think the expectation has changed but the implementation is
> > probably more picky since Roger's hotplug patches.
> >
> > > xm does not work either, so the change is most likely in the scripts.
> >
> > If you are switching from xl to xm then you should either reboot or
> > remove libxl/disable_udev in xenstore manually.
> >
> > Other than that nor much has changed in the scripts either. Are you sure
> > it isn't the kernel which has changed?
>
> The kernel is ok.
I think there is at least the posibility that this kernel has a latent
bug exposed by recent changes to libxl, or at least we should consider
the possibility.
Is this kernel tree available somewhere convenient (i.e. which doesn't
involves unpacking .src.rpms and applying patches etc).
I checked netback_probe in the linux-2.6.18-xen.hg tree (which I believe
relates at least somewhat to the SLES kernel) and it switches to
XenbusStateInitWait just before calling the function which triggers the
hotplug script -- so libxl's behaviour of waiting for
XenbusStateInitWait before running the hotplug scripts would seem to be
correct. I couldn't find anything before this point which would cause
the driver to block. So if your observation is that your kernel is
blocking in state 1 or taking an inordinate amount of time to get to
state 2 then that is what you need to dig into.
Have you reinstalled your udev rules etc? They changed recently and I
suspect they need to be up to date to work with the latest scripts.
Although you don't appear to be getting to that point so I don't think
it would matter (yet).
You didn't answer my question about error nodes in xenstore.
You could, experimentally, try increasing LIBXL_INIT_TIMEOUT to some
enormous time.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-09 8:32 ` Ian Campbell
@ 2012-08-09 14:34 ` Olaf Hering
2012-08-10 7:41 ` Olaf Hering
0 siblings, 1 reply; 12+ messages in thread
From: Olaf Hering @ 2012-08-09 14:34 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xen.org
On Thu, Aug 09, Ian Campbell wrote:
> > I have no idea, have to browse code debug it.
> > A quick test with plain sles11sp2+xend and xm start -p shows that
> > /local/domain/0/backend/vif/1/0/state finally gets into state 2.
>
> When you say "finally" do you mean that it takes an unusually long time?
'finally' is wrongly worded. It gets into state 2, I notice no delay.
> Is this kernel tree available somewhere convenient (i.e. which doesn't
> involves unpacking .src.rpms and applying patches etc).
Its available via git, see http://kernel.opensuse.org/git
The webui is here:
http://kernel.opensuse.org/cgit/kernel/tree/?h=SLE11-SP2
> I checked netback_probe in the linux-2.6.18-xen.hg tree (which I believe
> relates at least somewhat to the SLES kernel) and it switches to
> XenbusStateInitWait just before calling the function which triggers the
> hotplug script -- so libxl's behaviour of waiting for
> XenbusStateInitWait before running the hotplug scripts would seem to be
> correct. I couldn't find anything before this point which would cause
> the driver to block. So if your observation is that your kernel is
> blocking in state 1 or taking an inordinate amount of time to get to
> state 2 then that is what you need to dig into.
Indeed, netback_probe is appearently never called in my case. I will
check why that happens.
> Have you reinstalled your udev rules etc? They changed recently and I
> suspect they need to be up to date to work with the latest scripts.
> Although you don't appear to be getting to that point so I don't think
> it would matter (yet).
Its all coming from xen*.rpm packages, no manual install. The rules are
from xen-unstable.
> You didn't answer my question about error nodes in xenstore.
I dont see any error nodes in xenstore.
> You could, experimentally, try increasing LIBXL_INIT_TIMEOUT to some
> enormous time.
Thanks for the hint. I will see what I find.
Olaf
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-09 14:34 ` Olaf Hering
@ 2012-08-10 7:41 ` Olaf Hering
2012-08-10 12:59 ` Olaf Hering
0 siblings, 1 reply; 12+ messages in thread
From: Olaf Hering @ 2012-08-10 7:41 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xen.org
On Thu, Aug 09, Olaf Hering wrote:
> Indeed, netback_probe is appearently never called in my case. I will
> check why that happens.
What I have seen so far is that in 4.2+xl the vif driver is not
registered, while in 4.1+xm there is a vif driver registered. Thats so
far the difference I could spot.
I will post more results why that happens later.
Olaf
root@satriani:~ # grep xen-backend xl-dmesg-3.0.34-sles11sp2_olh-xen.txt
[ 0.149879] bus: 'xen-backend': registered
[ 0.149879] device: 'xen-backend': device_add
[ 0.149879] PM: Adding info for No Bus:xen-backend
[ 90.055240] bus: 'xen-backend': add device qdisk-1-768
[ 90.055252] PM: Adding info for xen-backend:qdisk-1-768
[ 90.064575] bus: 'xen-backend': add device qdisk-1-5632
[ 90.064584] PM: Adding info for xen-backend:qdisk-1-5632
[ 90.073196] bus: 'xen-backend': add device console-1-0
[ 90.073205] PM: Adding info for xen-backend:console-1-0
[ 90.081771] bus: 'xen-backend': add device vkbd-1-0
[ 90.081776] PM: Adding info for xen-backend:vkbd-1-0
[ 90.378494] bus: 'xen-backend': add device vif-1-0
[ 90.378504] PM: Adding info for xen-backend:vif-1-0
[ 100.401586] PM: Removing info for xen-backend:console-1-0
[ 100.401596] bus: 'xen-backend': remove device console-1-0
[ 102.400202] PM: Removing info for xen-backend:qdisk-1-768
[ 102.400212] bus: 'xen-backend': remove device qdisk-1-768
[ 102.406016] PM: Removing info for xen-backend:qdisk-1-5632
[ 102.406025] bus: 'xen-backend': remove device qdisk-1-5632
[ 102.411464] PM: Removing info for xen-backend:vkbd-1-0
[ 102.411473] bus: 'xen-backend': remove device vkbd-1-0
[ 110.410600] PM: Removing info for xen-backend:vif-1-0
[ 110.410610] bus: 'xen-backend': remove device vif-1-0
root@satriani:~ # grep xen-backend xm-dmesg-3.0.34-sles11sp2_olh-xen.txt
[ 0.150119] bus: 'xen-backend': registered
[ 0.150119] device: 'xen-backend': device_add
[ 0.150119] PM: Adding info for No Bus:xen-backend
[ 44.319441] bus: 'xen-backend': add driver tap
[ 44.338383] bus: 'xen-backend': add driver vbd
[ 44.367501] bus: 'xen-backend': add driver vif
[ 44.378095] bus: 'xen-backend': add driver vusb
[ 204.002506] bus: 'xen-backend': add device vfb-1-0
[ 204.002514] PM: Adding info for xen-backend:vfb-1-0
[ 204.017641] bus: 'xen-backend': add device vbd-1-768
[ 204.017650] PM: Adding info for xen-backend:vbd-1-768
[ 204.017663] bus: 'xen-backend': driver_probe_device: matched device vbd-1-768 with driver vbd
[ 204.017667] bus: 'xen-backend': really_probe: probing driver vbd with device vbd-1-768
[ 204.018903] bus: 'xen-backend': really_probe: bound device vbd-1-768 to driver vbd
[ 204.032488] bus: 'xen-backend': add device vbd-1-5632
[ 204.032494] PM: Adding info for xen-backend:vbd-1-5632
[ 204.032502] bus: 'xen-backend': driver_probe_device: matched device vbd-1-5632 with driver vbd
[ 204.032504] bus: 'xen-backend': really_probe: probing driver vbd with device vbd-1-5632
[ 204.033534] bus: 'xen-backend': really_probe: bound device vbd-1-5632 to driver vbd
[ 204.043973] bus: 'xen-backend': add device vif-1-0
[ 204.043980] PM: Adding info for xen-backend:vif-1-0
[ 204.043988] bus: 'xen-backend': driver_probe_device: matched device vif-1-0 with driver vif
[ 204.043990] bus: 'xen-backend': really_probe: probing driver vif with device vif-1-0
[ 204.049398] bus: 'xen-backend': really_probe: bound device vif-1-0 to driver vif
[ 204.739981] bus: 'xen-backend': add device console-1-0
[ 204.739993] PM: Adding info for xen-backend:console-1-0
[ 340.548887] PM: Removing info for xen-backend:console-1-0
[ 340.548902] bus: 'xen-backend': remove device console-1-0
[ 340.570464] PM: Removing info for xen-backend:vfb-1-0
[ 340.570470] bus: 'xen-backend': remove device vfb-1-0
[ 340.577394] PM: Removing info for xen-backend:vbd-1-768
[ 340.577403] bus: 'xen-backend': remove device vbd-1-768
[ 340.578784] PM: Removing info for xen-backend:vbd-1-5632
[ 340.578791] bus: 'xen-backend': remove device vbd-1-5632
[ 340.581006] PM: Removing info for xen-backend:vif-1-0
[ 340.581014] bus: 'xen-backend': remove device vif-1-0
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-10 7:41 ` Olaf Hering
@ 2012-08-10 12:59 ` Olaf Hering
2012-08-14 10:18 ` Ian Campbell
0 siblings, 1 reply; 12+ messages in thread
From: Olaf Hering @ 2012-08-10 12:59 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xen.org
On Fri, Aug 10, Olaf Hering wrote:
> On Thu, Aug 09, Olaf Hering wrote:
>
> > Indeed, netback_probe is appearently never called in my case. I will
> > check why that happens.
>
> What I have seen so far is that in 4.2+xl the vif driver is not
> registered, while in 4.1+xm there is a vif driver registered. Thats so
> far the difference I could spot.
Argh, I was expecting that required kernel drivers are loaded when
needed. But thats not the case. There is a workaround or fix for pvops
in 25728:a6edbc39fc84. But this changeset misses at least netbk and
blkbk.
Any idea why that changeset is now needed?
Why did it work for everyone before?
Olaf
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-10 12:59 ` Olaf Hering
@ 2012-08-14 10:18 ` Ian Campbell
2012-08-14 11:30 ` Olaf Hering
0 siblings, 1 reply; 12+ messages in thread
From: Ian Campbell @ 2012-08-14 10:18 UTC (permalink / raw)
To: Olaf Hering; +Cc: xen-devel@lists.xen.org
On Fri, 2012-08-10 at 13:59 +0100, Olaf Hering wrote:
> On Fri, Aug 10, Olaf Hering wrote:
>
> > On Thu, Aug 09, Olaf Hering wrote:
> >
> > > Indeed, netback_probe is appearently never called in my case. I will
> > > check why that happens.
> >
> > What I have seen so far is that in 4.2+xl the vif driver is not
> > registered, while in 4.1+xm there is a vif driver registered. Thats so
> > far the difference I could spot.
>
> Argh, I was expecting that required kernel drivers are loaded when
> needed. But thats not the case. There is a workaround or fix for pvops
> in 25728:a6edbc39fc84. But this changeset misses at least netbk and
> blkbk.
>
> Any idea why that changeset is now needed?
> Why did it work for everyone before?
Backend driver autoloading is relatively new in pvops kernels at least
(I don't know if it was ever a feature of the older kernels). Perhaps
the SLES kernels used to build those drivers into the kernel statically?
(that was quite common in the classic-Xen kernel days, but now with
pvops modular is becoming more common)
None of which answers your questions as to why it used to work for you
though.
I think we would accept an update to 25728:a6edbc39fc84 to add some new
aliases, it was discussed at the time but I think it petered out after a
short discussion about what the correct names were.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-14 10:18 ` Ian Campbell
@ 2012-08-14 11:30 ` Olaf Hering
2012-08-14 13:04 ` Ian Campbell
0 siblings, 1 reply; 12+ messages in thread
From: Olaf Hering @ 2012-08-14 11:30 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xen.org
On Tue, Aug 14, Ian Campbell wrote:
> I think we would accept an update to 25728:a6edbc39fc84 to add some new
> aliases, it was discussed at the time but I think it petered out after a
> short discussion about what the correct names were.
Perhaps the kernel should do a request_module(xen-backend:$type), but
that does not solve it for older kernels.
Olaf
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: vif backend configuration times out
2012-08-14 11:30 ` Olaf Hering
@ 2012-08-14 13:04 ` Ian Campbell
0 siblings, 0 replies; 12+ messages in thread
From: Ian Campbell @ 2012-08-14 13:04 UTC (permalink / raw)
To: Olaf Hering; +Cc: xen-devel@lists.xen.org
On Tue, 2012-08-14 at 12:30 +0100, Olaf Hering wrote:
> On Tue, Aug 14, Ian Campbell wrote:
>
> > I think we would accept an update to 25728:a6edbc39fc84 to add some new
> > aliases, it was discussed at the time but I think it petered out after a
> > short discussion about what the correct names were.
>
> Perhaps the kernel should do a request_module(xen-backend:$type), but
> that does not solve it for older kernels.
Modern kernels already do (effectively) that. That's the "Backend driver
autoloading is relatively new in pvops kernels" I referred to is.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-08-14 13:04 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-06 17:39 vif backend configuration times out Olaf Hering
2012-08-07 5:42 ` Ian Campbell
2012-08-07 15:25 ` Olaf Hering
2012-08-07 15:33 ` Ian Campbell
2012-08-08 17:28 ` Olaf Hering
2012-08-09 8:32 ` Ian Campbell
2012-08-09 14:34 ` Olaf Hering
2012-08-10 7:41 ` Olaf Hering
2012-08-10 12:59 ` Olaf Hering
2012-08-14 10:18 ` Ian Campbell
2012-08-14 11:30 ` Olaf Hering
2012-08-14 13:04 ` Ian Campbell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).