[Bug 618678] New: blkback thread hangs after unsuccessful xen domU start
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c0 Summary: blkback thread hangs after unsuccessful xen domU start Classification: openSUSE Product: openSUSE 11.3 Version: Factory Platform: x86-64 OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Xen AssignedTo: jdouglas@novell.com ReportedBy: koenig@linux.de QAContact: qa@suse.de Found By: --- Blocker: --- one of my xen domUs did not start up as expected, which uses 2 iscsi disks. now, trying to start again I get # xm cre -c os-centos4u4 Using config file "./os-centos4u4". Error: Device /dev/xvdp (51952, vbd) is already connected. those two disks still show up with "lsscsi" # lsscsi -t [0:0:0:0] disk sata: /dev/sda [1:0:0:0] disk sata: /dev/sdb [6:0:1:0] cd/dvd ata: /dev/sr0 [35:0:0:0] disk iqn.2010-04.de.science-computing:os-centos4u4-builddisk-flat.vmdk,t,0x1 /dev/sdt [36:0:0:0] disk iqn.2010-04.de.science-computing:os-centos4u4-flat.vmdk,t,0x1 /dev/sdu and there are two kernel threads for "domU id #13" which does not exist (highest domU id running is 10): root 12345 0.0 0.0 0 0 ? S 13:42 0:00 [blkback.13.hda] root 12346 0.0 0.0 0 0 ? S 13:42 0:00 [blkback.13.hdb] I don't see any mappings with dmsetup or losetup # dmsetup ls No devices found # losetup -a iscsi logout does not do anything, and login throws an "not found" error, but it's shown in the list of available disks: # /sbin/iscsiadm -m node -T iscsi:iqn.2010-04.de.science-computing:os-centos4u4-flat.vmdk --logout # /sbin/iscsiadm -m node -T iscsi:iqn.2010-04.de.science-computing:os-centos4u4-flat.vmdk --login iscsiadm: no records found! # /sbin/iscsiadm -m node | grep os-centos4u4 192.168.178.4:3260,1 iqn.2010-04.de.science-computing:os-centos4u4-flat.vmdk 192.168.178.4:3260,1 iqn.2010-04.de.science-computing:os-centos4u4-builddisk-flat.vmdk # after shuttig down *all* domUs things changed a bit, but still very bad: now "lsscsi" does not show any virtual/iscsi disks anymore, but still *all* blkback threads exist # ps uax | grep blk root 4289 0.0 0.1 117332 7268 ? Ssl 12:00 0:00 blktapctrl root 4818 0.0 0.0 0 0 ? S 12:00 0:00 [blkback.1.hda] root 4819 0.0 0.0 0 0 ? S 12:00 0:00 [blkback.1.hdb] root 5296 0.0 0.0 0 0 ? S 12:00 0:00 [blkback.3.hda] root 5736 0.0 0.0 0 0 ? S 12:01 0:00 [blkback.4.hda] root 5737 0.0 0.0 0 0 ? S 12:01 0:00 [blkback.4.hdb] root 6188 0.0 0.0 0 0 ? S 12:01 0:00 [blkback.5.hda] root 6189 0.0 0.0 0 0 ? S 12:01 0:00 [blkback.5.hdb] root 6666 0.0 0.0 0 0 ? S 12:01 0:00 [blkback.6.hda] root 6667 0.0 0.0 0 0 ? S 12:01 0:00 [blkback.6.hdb] root 7637 0.0 0.0 0 0 ? S 12:02 0:00 [blkback.8.hda] root 7638 0.0 0.0 0 0 ? S 12:02 0:00 [blkback.8.hdb] root 8151 0.0 0.0 0 0 ? S 12:03 0:00 [blkback.9.hda] root 8152 0.0 0.0 0 0 ? S 12:03 0:00 [blkback.9.hdb] root 8690 0.0 0.0 0 0 ? S 12:03 0:00 [blkback.10.hda] root 8691 0.0 0.0 0 0 ? S 12:03 0:00 [blkback.10.hdb] root 12345 0.0 0.0 0 0 ? S 13:42 0:00 [blkback.13.hda] root 12346 0.0 0.0 0 0 ? S 13:42 0:00 [blkback.13.hdb] now I'll reboot, but any suggestion how to correctly clean up such a mess next time, or which other information are important for further debugging ? how can I get rid of those blkback.* threads ? even after stopping iscsi, there are 17 blkback threads, and the iscsi_tcp kernel module has a usage cound of 17, so it's not possible to completely reload/restart without reboot: # ps uax | grep iscsi iscsi_tcp 11666 17 libiscsi_tcp 18437 1 iscsi_tcp libiscsi 50884 2 iscsi_tcp,libiscsi_tcp scsi_transport_iscsi 41815 2 iscsi_tcp,libiscsi scsi_mod 191208 7 iscsi_tcp,libiscsi,scsi_transport_iscsi,sr_mod,sg,sd_mod,libata some rpm versions: # rpm -qa xen kernel-xen \*iscsi\*| sort iscsitarget-1.4.19-2.31.x86_64 iscsitarget-kmp-default-1.4.19_k2.6.34.0_12-2.31.x86_64 iscsitarget-kmp-xen-1.4.19_k2.6.34.0_12-2.31.x86_64 kernel-xen-2.6.34-12.1.x86_64 open-iscsi-2.0.870-31.8.x86_64 xen-4.0.0_21091_05-6.3.x86_64 yast2-iscsi-client-2.19.5-1.4.noarch yast2-iscsi-server-2.19.0-1.5.noarch here are the kernel msgs from that last startup Jun 30 13:41:57 os4 kernel: [ 6131.884391] blkback: ring-ref 8, event-channel 80, protocol 1 (x86_64-abi) Jun 30 13:41:57 os4 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 Jun 30 13:41:57 os4 logger: /etc/xen/scripts/block-iscsi: add XENBUS_PATH=backend/vbd/0/51952 Jun 30 13:41:57 os4 kernel: [ 6131.988562] blkback: ring-ref 8, event-channel 80, protocol 1 (x86_64-abi) Jun 30 13:41:57 os4 kernel: [ 6132.377246] scsi34 : iSCSI Initiator over TCP/IP Jun 30 13:41:57 os4 kernel: [ 6132.630238] scsi 34:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4 Jun 30 13:41:57 os4 kernel: [ 6132.630451] sd 34:0:0:0: Attached scsi generic sg3 type 0 Jun 30 13:41:57 os4 kernel: [ 6132.630867] sd 34:0:0:0: [sdt] 23068672 512-byte logical blocks: (11.8 GB/11.0 GiB) Jun 30 13:41:57 os4 kernel: [ 6132.631006] sd 34:0:0:0: [sdt] Write Protect is off Jun 30 13:41:57 os4 kernel: [ 6132.631010] sd 34:0:0:0: [sdt] Mode Sense: 77 00 00 08 Jun 30 13:41:57 os4 kernel: [ 6132.631596] sd 34:0:0:0: [sdt] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Jun 30 13:41:57 os4 kernel: [ 6132.632709] sdt: sdt1 sdt2 Jun 30 13:41:57 os4 kernel: [ 6132.642926] sd 34:0:0:0: [sdt] Attached SCSI disk Jun 30 13:41:58 os4 iscsid: connection27:0 is operational now Jun 30 13:42:01 os4 logger: /etc/xen/scripts/block-iscsi: Writing backend/vbd/0/51952/physical-device 41:30 to xenstore. Jun 30 13:42:01 os4 logger: /etc/xen/scripts/block-iscsi: Writing backend/vbd/0/51952/hotplug-status connected to xenstore. Jun 30 13:42:01 os4 kernel: [ 6136.654486] (cdrom_add_media_watch() file=/usr/src/packages/BUILD/kernel-xen-2.6.34/linux-2.6.34/drivers/xen/blkback/cdrom.c, line=108) nodename :backend/vbd/0/51952 Jun 30 13:42:01 os4 kernel: [ 6136.654491] (cdrom_is_type() file=/usr/src/packages/BUILD/kernel-xen-2.6.34/linux-2.6.34/drivers/xen/blkback/cdrom.c, line=95) type:0 Jun 30 13:42:01 os4 kernel: [ 6136.669605] blkfront: xvdp: barriers enabled Jun 30 13:42:01 os4 kernel: [ 6136.669934] xvdp: xvdp1 xvdp2 Jun 30 13:42:02 os4 kernel: [ 6137.665224] kjournald starting. Commit interval 15 seconds Jun 30 13:42:02 os4 kernel: [ 6137.665243] EXT3-fs (dm-0): mounted filesystem with ordered data mode Jun 30 13:42:03 os4 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/0/51952 Jun 30 13:42:03 os4 logger: /etc/xen/scripts/block-iscsi: remove XENBUS_PATH=backend/vbd/0/51952 Jun 30 13:42:03 os4 kernel: [ 6138.703708] connection27:0: detected conn error (1020) Jun 30 13:42:04 os4 logger: /etc/xen/scripts/block: Writing backend/vbd/0/51952/hotplug-error /etc/xen/scripts/block failed; error detected. backend/vbd/0/51952/hotplug-status error to xenstore. Jun 30 13:42:04 os4 logger: /etc/xen/scripts/block: /etc/xen/scripts/block failed; error detected. Jun 30 13:42:04 os4 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/0/51952 Jun 30 13:42:08 os4 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/13/768 Jun 30 13:42:08 os4 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/13/832 Jun 30 13:42:08 os4 logger: /etc/xen/scripts/block-iscsi: add XENBUS_PATH=backend/vbd/13/768 Jun 30 13:42:08 os4 logger: /etc/xen/scripts/block-iscsi: add XENBUS_PATH=backend/vbd/13/832 Jun 30 13:42:08 os4 logger: /etc/xen/scripts/vif-bridge: online XENBUS_PATH=backend/vif/13/0 Jun 30 13:42:08 os4 kernel: [ 6143.055984] device vif13.0 entered promiscuous mode Jun 30 13:42:08 os4 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif13.0, bridge br0. Jun 30 13:42:08 os4 kernel: [ 6143.060799] br0: port 11(vif13.0) entering forwarding state Jun 30 13:42:08 os4 logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/13/0/hotplug-status connected to xenstore. Jun 30 13:42:08 os4 kernel: [ 6143.576594] scsi35 : iSCSI Initiator over TCP/IP Jun 30 13:42:08 os4 kernel: [ 6143.578691] scsi36 : iSCSI Initiator over TCP/IP Jun 30 13:42:09 os4 kernel: [ 6143.832288] scsi 35:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4 Jun 30 13:42:09 os4 kernel: [ 6143.832500] sd 35:0:0:0: Attached scsi generic sg3 type 0 Jun 30 13:42:09 os4 kernel: [ 6143.833215] scsi 36:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4 Jun 30 13:42:09 os4 kernel: [ 6143.834392] sd 36:0:0:0: Attached scsi generic sg4 type 0 Jun 30 13:42:09 os4 kernel: [ 6143.837179] sd 35:0:0:0: [sdt] 41943040 512-byte logical blocks: (21.4 GB/20.0 GiB) Jun 30 13:42:09 os4 kernel: [ 6143.837238] sd 35:0:0:0: [sdt] Write Protect is off Jun 30 13:42:09 os4 kernel: [ 6143.837240] sd 35:0:0:0: [sdt] Mode Sense: 77 00 00 08 Jun 30 13:42:09 os4 kernel: [ 6143.837344] sd 35:0:0:0: [sdt] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Jun 30 13:42:09 os4 kernel: [ 6143.841716] sd 36:0:0:0: [sdu] 23068672 512-byte logical blocks: (11.8 GB/11.0 GiB) Jun 30 13:42:09 os4 kernel: [ 6143.841800] sd 36:0:0:0: [sdu] Write Protect is off Jun 30 13:42:09 os4 kernel: [ 6143.841803] sd 36:0:0:0: [sdu] Mode Sense: 77 00 00 08 Jun 30 13:42:09 os4 kernel: [ 6143.841944] sd 36:0:0:0: [sdu] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Jun 30 13:42:09 os4 kernel: [ 6143.842426] sdu: sdu1 sdu2 Jun 30 13:42:09 os4 kernel: [ 6143.843052] sdt: Jun 30 13:42:09 os4 kernel: [ 6143.843582] sd 36:0:0:0: [sdu] Attached SCSI disk Jun 30 13:42:09 os4 kernel: [ 6143.850831] sdt1 Jun 30 13:42:09 os4 kernel: [ 6143.851797] sd 35:0:0:0: [sdt] Attached SCSI disk Jun 30 13:42:09 os4 iscsid: connection28:0 is operational now Jun 30 13:42:09 os4 iscsid: connection29:0 is operational now Jun 30 13:42:10 os4 avahi-daemon[3835]: Registering new address record for fe80::fcff:ffff:feff:ffff on vif13.0.*. Jun 30 13:42:13 os4 logger: /etc/xen/scripts/block-iscsi: Writing backend/vbd/13/832/physical-device 41:30 to xenstore. Jun 30 13:42:13 os4 logger: /etc/xen/scripts/block-iscsi: Writing backend/vbd/13/832/hotplug-status connected to xenstore. Jun 30 13:42:13 os4 kernel: [ 6147.857183] (cdrom_add_media_watch() file=/usr/src/packages/BUILD/kernel-xen-2.6.34/linux-2.6.34/drivers/xen/blkback/cdrom.c, line=108) nodename:backend/vbd/13/832 Jun 30 13:42:13 os4 kernel: [ 6147.857188] (cdrom_is_type() file=/usr/src/packages/BUILD/kernel-xen-2.6.34/linux-2.6.34/drivers/xen/blkback/cdrom.c, line=95) type:0 Jun 30 13:42:13 os4 logger: /etc/xen/scripts/block-iscsi: Writing backend/vbd/13/768/physical-device 41:40 to xenstore. Jun 30 13:42:13 os4 logger: /etc/xen/scripts/block-iscsi: Writing backend/vbd/13/768/hotplug-status connected to xenstore. Jun 30 13:42:13 os4 kernel: [ 6147.868988] (cdrom_add_media_watch() file=/usr/src/packages/BUILD/kernel-xen-2.6.34/linux-2.6.34/drivers/xen/blkback/cdrom.c, line=108) nodename:backend/vbd/13/768 Jun 30 13:42:13 os4 kernel: [ 6147.868994] (cdrom_is_type() file=/usr/src/packages/BUILD/kernel-xen-2.6.34/linux-2.6.34/drivers/xen/blkback/cdrom.c, line=95) type:0 Jun 30 13:42:16 os4 kernel: [ 6151.780136] blkback: ring-ref 8, event-channel 15, protocol 2 (x86_32-abi) Jun 30 13:42:17 os4 kernel: [ 6151.880532] alloc irq_desc for 902 on node 0 Jun 30 13:42:17 os4 kernel: [ 6151.880535] alloc kstat_irqs on node 0 Jun 30 13:42:17 os4 kernel: [ 6151.884791] blkback: ring-ref 9, event-channel 16, protocol 2 (x86_32-abi) Jun 30 13:42:17 os4 kernel: [ 6151.992027] alloc irq_desc for 903 on node 0 Jun 30 13:42:17 os4 kernel: [ 6151.992031] alloc kstat_irqs on node 0 Jun 30 13:42:17 os4 kernel: [ 6152.128027] alloc irq_desc for 904 on node 0 Jun 30 13:42:17 os4 kernel: [ 6152.128030] alloc kstat_irqs on node 0 Jun 30 13:42:19 os4 kernel: [ 6153.980512] vif13.0: no IPv6 routers present thanks for any idea! -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c Jason Douglas <jdouglas@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cyliu@novell.com, | |jbeulich@novell.com, | |jdouglas@novell.com, | |jsong@novell.com AssignedTo|jdouglas@novell.com |jfehlig@novell.com -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c1 Jan Beulich <jbeulich@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|NEW |NEEDINFO Found By|--- |Community User InfoProvider| |koenig@linux.de --- Comment #1 from Jan Beulich <jbeulich@novell.com> 2010-07-01 09:07:13 UTC --- Getting xenstore's view (utility xenstore-ls) on both the corresponding frontends' and backends' states would possibly shed some light on this - the driver terminates those threads when the devices get disconnected (hinting at some failure path [in tools or kernel] doing insufficient cleanup). The kernel side code didn't change in quite a while - did you observe similar problems with earlier versions? I'm afraid it'll be difficult for us to do anything if the issue doesn't re-occur for you. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c2 Harald Koenig <koenig@linux.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|koenig@linux.de | --- Comment #2 from Harald Koenig <koenig@linux.de> 2010-07-01 16:27:50 UTC --- (In reply to comment #1)
Getting xenstore's view (utility xenstore-ls) on both the corresponding frontends' and backends' states would possibly shed some light on this - the
I have one full xenstore dump which I took after all domUs have been shut down. only dom0 was still running, but xenstore showed all the machines which have been running before. one note about xenstore: I'm not using xenstore myself (no "xm new foo"), all domUs are started via config file either in /etc/init.d/xendomains or with "xm create foo", so I'm a bit surprised to find all the domU info in xenstore *after* all those domUs are shut down ?! I'll attach that dump..
driver terminates those threads when the devices get disconnected (hinting at some failure path [in tools or kernel] doing insufficient cleanup).
The kernel side code didn't change in quite a while - did you observe similar problems with earlier versions?
I'm afraid it'll be difficult for us to do anything if the issue doesn't re-occur for you.
it does reoccur 100% for me, right now xen 4.0 with 11.3 is more or less unusable: whenever the first domU gets shut down or crases it's not possible anymore to start any new domU -- so far I only can reboot the dom0 :-( now I did a new test: no iscsi but one single PVM domU being started with one disk image as local file. start and shutdown workds fine, and the "blkback" kernel thread vanished. but still it's not possible to start a new domU! with identical config file I get # time xm cre -c os-centos5 Using config file "./os-centos5". # Error: Device 0 (vif) could not be connected. Hotplug scripts not working. so I again commented out the "vif=..." def only to get this (both times after 100 secs timeout) # xm cre -c os-centos5 Using config file "./os-centos5". # Error: Device 768 (vbd) could not be connected. Hotplug scripts not working. so I have to reboot again... -- next/last "single domU" test will use a 64bit suse 11.1 domU instead of cenots, just in case you want to argue... -- so stay tuned;-) now I'm no longer sure if the remaining blkback threads are the real problem, or just one more symtom of a even bigger problem:-( -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c3 --- Comment #3 from Harald Koenig <koenig@linux.de> 2010-07-01 16:28:55 UTC --- Created an attachment (id=373287) --> (http://bugzilla.novell.com/attachment.cgi?id=373287) full xenstore dump with only dom0 running -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c4 --- Comment #4 from Harald Koenig <koenig@linux.de> 2010-07-01 18:46:50 UTC --- (In reply to comment #2)
so I have to reboot again... -- next/last "single domU" test will use a 64bit suse 11.1 domU instead of cenots, just in case you want to argue... -- so stay tuned;-)
uh, oh! I've now tried to start/stop/start/stop other VMs and surprise: the problem does not get triggered by suse 11.1, sles 11 and centos 5 (both 32 and 64 bit PVMs). some of them have been changed to use disk images as local files, others still use iscsi disks (as I was lacy to change all configs;), so at least it's not an iscsi issue;) right now it looks like the problem is related to using vmlinuz-2.6.9-55.0.12.ELxenU or vmlinuz-2.6.9-89.0.23.ELxenU kernels form centos 4u5 and 4u8, again both 32 and 64 bit domU seem to trigger the problem! next update -- even more obfuscation:-( I replaced that vmlinuz-2.6.9* kernel in a centos4u4 domU by a 2.6.18-8.el5xen kernel (32bit for 1st test) from centos 5u0 (which I use successfully for a centos 5u0 domU), the initrd was directly copied from that working 5u0 domU. using that 5u0 kernel/initrd the 4u4 did not come up correctly, it crashed before it could access the rootfs (because the real 5u0 uses a plain rootfs partition while the 4u4 has rootfs in LVM -- console log of the crash below). BUT even if it only used the same kernel/initrd, this domU start again triggers that problem which blocks any further domU start:-( there is no additional output from "xm dmesg" when starting/stopping such a problematic domU, sono additional clue from that channel:-( right no I do not understand - why centos 5u0 works fine while booting 5u0 kernel with 4u4 kernel triggers further problems after crashing at end of initrd - how to get the centos4 machines working in 11.3/xen4 :-( just to state again: these PVMs run just fine with 11.1 (xen 3.3) and 11.2 (xen 3.4). are there known issues in xen 4.0 with older xen kernel versions in domU ? or any specific issues with centos 4u5/4u8 in xen4 ? this is the diff between the config files of centos 4u4 and 5u0: ------------------------------------------------------------------------------- < name="os-centos4u4" < bootargs="--entry=hda1:/boot/vmlinuz-2.6.18-8.el5xen,/boot/initrd-2.6.18-8.el5xen.img.c5" < disk=[ diskroot + 'os-centos4u4-flat.vmdk,hda,w' , diskroot + 'os-centos4u4-builddisk-flat.vmdk,hdb,w' ] < extra="root=/dev/mapper/VolGroup00-LogVol01" < vif=[ 'mac=00:0c:29:18:4b:5a,bridge=br0,model=rtl8139', ] -------------------------------------------------------------------------------
name="os-centos5" bootargs="--entry=hda1:/boot/vmlinuz-2.6.18-8.el5xen,/boot/initrd-2.6.18-8.el5xen.img" disk=[ diskroot + 'os-centos5-flat.vmdk,hda,w' ] extra="root=/dev/hda1" vif=[ 'mac=00:0c:29:4a:bf:fc,bridge=br0,model=rtl8139', ]
so there is no significant difference... "expected" (now that I see it;) panic when booting 4u4 disk with 5u0 kernel/initrd: Started domain os-centos4u4 (id=1) Linux version 2.6.18-8.el5xen (mockbuild@builder4.centos.org) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Thu Mar 15 21:02:53 EDT 2007 BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000007d800000 (usable) 1280MB HIGHMEM available. 727MB LOWMEM available. NX (Execute Disable) protection: active ACPI in unprivileged domain disabled Built 1 zonelists. Total pages: 514048 Kernel command line: root=/dev/mapper/VolGroup00-LogVol01 [...] Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! Error: Domain 'os-centos4u4' does not exist. Error: Domain 'os-centos4u4' does not exist. and here is the full xen config file for the centos4u4 vm -- still hoping that there will be some bells ringing when you see some "unimportant" bits of information ;-) --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< --- name="os-centos4u4" memory=1000 maxmem=2000 vcpus=4 on_poweroff="destroy" on_reboot="restart" on_crash="restart" localtime=0 extra="root=/dev/mapper/VolGroup00-LogVol01" bootloader="/usr/lib/xen/boot/domUloader.py" builder="linux" #bootargs="--entry=hda1:/boot/vmlinuz-2.6.9-55.0.12.ELxenU,/boot/initrd-2.6.9-55.0.12.ELxenU.img" #bootargs="--entry=hda1:/boot/vmlinuz-2.6.9-89.0.23.ELxenU,/boot/initrd-2.6.9-89.0.23.ELxenU.img" #bootargs="--entry=hda1:/boot/vmlinuz-2.6.9-89.0.15.plus.c4xenU,/boot/initrd-2.6.9-89.0.15.plus.c4xenU.img" bootargs="--entry=hda1:/boot/vmlinuz-2.6.18-8.el5xen,/boot/initrd-2.6.18-8.el5xen.img.c5" diskroot='file:/etc/xen/images/' #iskroot='iscsi:iqn.2010-04.de.science-computing:' disk=[ diskroot + 'os-centos4u4-flat.vmdk,hda,w' , diskroot + 'os-centos4u4-builddisk-flat.vmdk,hdb,w' ] vif=[ 'mac=00:0c:29:18:4b:5a,bridge=br0,model=rtl8139', ] nographic=1 apic=1 acpi=1 pae=1 # serial="pty" --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< --- so, enough for today, I'm running out of ideas for now:-( -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c5 --- Comment #5 from James Fehlig <jfehlig@novell.com> 2010-07-01 19:43:14 UTC --- (In reply to comment #2)
one note about xenstore: I'm not using xenstore myself (no "xm new foo"), all domUs are started via config file either in /etc/init.d/xendomains or with "xm create foo", so I'm a bit surprised to find all the domU info in xenstore *after* all those domUs are shut down ?!
I think you are confusing xenstore with xend's internal domU configuration database. The latter is where managed domU config is stored (/var/lib/xen/domains/<domU-uuid>/config.sxp), e.g. when doing 'xm new domU-config'. xenstore is where information is stored for _running_ domUs. Front and backend drivers rendezvous there, the various tools (xend, qemu-dm, etc.) read, write, and watch state in xenstore, etc. It is a database for active domUs. That said, all xenstore information pertaining to an active domU should be removed once the domU has powered down. Lots of conditions can cause orphaned entries in the store however. E.g. if blkbk does not fully cleanup the vbd, udev is never triggered, hotplug scripts aren't invoked, and xenstore entries are not removed. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c6 --- Comment #6 from James Fehlig <jfehlig@novell.com> 2010-07-01 19:47:58 UTC --- (In reply to comment #4)
name="os-centos4u4"
memory=1000 maxmem=2000
Any luck if you set memory = maxmem? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c7 --- Comment #7 from Harald Koenig <koenig@linux.de> 2010-07-01 21:31:03 UTC --- (In reply to comment #6)
(In reply to comment #4)
name="os-centos4u4"
memory=1000 maxmem=2000
Any luck if you set memory = maxmem?
I can try tomorrow, but almost all domUs are configured with the same memory setup (some old/small ones with memory=500, and the centos4u4 before was an exception with 3000/4000 for some larger build jobs, but reverting to 1000/2000 didn't help either... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c8 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |coolo@novell.com, | |ksrinivasan@novell.com --- Comment #8 from James Fehlig <jfehlig@novell.com> 2010-07-02 00:52:27 UTC --- I've been doing some testing with RC2 and haven't had any problems with doing start/stop sequences. However, when I do a save operation the vif device is not removed. /sys/devices/xen-backend/vif-X-Y still exists and there was no udev event was triggered for the tools. Ky, this seems like the tiresome problem we've encountered in the past. netbk does not cleanup the device properly on domU shutdown and won't respond to xenstore events for new devices. xen75 is currently in this state. This bug is quite serious IMO and it would be nice to have a resolution for 11.3 GM. I might find time later tonight to build netbk with debug messages enabled and see if it reports anything interesting. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c Jan Beulich <jbeulich@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #373287|application/octet-stream |text/plain mime type| | -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
From the xenstore dump I conclude that when you took it all backends were in 'closing' state. Unfortunately you didn't provide matched information about left over blkback threads: The driver switches a device to 'closing' only after having initiated termination of the respective thread, so (minus eventual bugs)
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c9 Jan Beulich <jbeulich@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |koenig@linux.de --- Comment #9 from Jan Beulich <jbeulich@novell.com> 2010-07-02 08:34:59 UTC --- the threads should be gone for all backend devices that are in this state. If that isn't the case, try turning on some debug messages (module parameter "debug_lvl") and/or printing of statistics (module parameter "log_stats"). Both parameters can be turned on via sysfs after the module was already loaded. If that doesn't get us further, we may need to sprinkle further debug messages around the blkback sources - would you be able to rebuild an eventual test kernel for yourself? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c10 Harald Koenig <koenig@linux.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|koenig@linux.de | --- Comment #10 from Harald Koenig <koenig@linux.de> 2010-07-02 15:03:01 UTC --- ok, more tests and details;) my currect guess: there is some problem when shutting down a xen domain, either due to problems in old xen kernels (2.6.9) or due to unexpected crash in domU. I've created a very small disk image based on centos-4u4 with both 2.6.9 and 2.6.18 (centos5) kernels which you can find here, together with a small xen config file for testing: ftp://ftp.science-computing.de/outgoing/koenig/xen4/ in the config file there are two bootargs variants: #bootargs="--entry=hda1:/boot/vmlinuz-2.6.9-89.0.23.ELxenU,/boot/initrd-2.6.9-89.0.23.ELxenU.img" bootargs="--entry=hda1:/boot/vmlinuz-2.6.18-8.el5xen,/boot/initrd-2.6.18-8.el5xen.img" 1) with the 4u4 2.6.9 kernel (commented out by default) it will boot and run init=/bin/bash and you have a very limited number of tools (e.g. "mount -n /proc ; ps uax" works;). when I leave this init shell with exit, the kernel will panic due to pid 1 exiting. with xen4 this will terminate the domU (in 11.2 xen3.4 the domU will remain and I have to "xm destroy ..." it). after this single start/crash I can no longer start any domU without reboot of dom0. 2) the 2.6.18 kernel/initrd is a copy of a domU running centos5 -- this centos5 domU does not trigger any problems! BUT: in this example system, it can't mount the rootfs (see before: root partition vs. LVM), so the kernel panics and domU terminates. this is the default setting, because for my 11.3/xen4 server this is enough (as domU id 1) to trigger the problem and block any further startup of can you reproduce that either (1) or (2) will lock you dom0 too ? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c11 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |koenig@linux.de --- Comment #11 from James Fehlig <jfehlig@novell.com> 2010-07-02 17:20:58 UTC --- (In reply to comment #10)
can you reproduce that either (1) or (2) will lock you dom0 too ?
In each of these cases do you have a vif device that has not been released by netbk? I.e. do you have a /sys/devices/xen-backend/vif-X-Y? I think you are just hitting failure cases (different bugs) that cause netbk to not cleanup properly. Once netbk is in this state, further domUs cannot be started until a dom0 reboot. As mentioned in comment #8, I'm able to get netbk in this state by doing 'xm save' or 'xm destroy' on a domU. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c12 --- Comment #12 from James Fehlig <jfehlig@novell.com> 2010-07-02 18:04:52 UTC --- I built a debug netbk by defining DPRINTK as printk("JWF (%s:%d) " fmt ".\n", __FUNCTION__, __LINE__, ##args) in netback/common.h. When doing a normal shutdown I get the following messages Jul 2 11:46:56 xen48 kernel: [ 1172.813625] JWF (frontend_changed:220) Closed. When doing 'xm destroy' I get Jul 2 11:49:25 xen48 kernel: [ 1321.655682] JWF (frontend_changed:220) Unknown. In both cases, xend has invoked destoryDevice on the vif {2010-07-02 11:49:25 3453] DEBUG (XendDomainInfo:1289) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 which writes 'online=0' and 'state=Closing' (Closing = 5) to vif backend node in xenstore. In fact, the vif backend path still exists and contains the expected state xen48:~ # xenstore-ls /local/domain/0/backend/vif 2 = "" 0 = "" bridge = "br0" domain = "os11.3" handle = "0" uuid = "6a2ba18b-6fd9-1765-4c85-dbf8017fed5e" script = "/etc/xen/scripts/vif-bridge" state = "5" frontend = "/local/domain/2/device/vif/0" mac = "00:16:3e:5b:ad:25" online = "0" frontend-id = "2" feature-sg = "1" feature-gso-tcpv4 = "1" feature-rx-copy = "1" feature-rx-flip = "0" hotplug-status = "connected" I'm not sure why netbk reads state 'Unknown' instead of 'Closing'. Oh, one final note. netbk dumps a lot of the following messages once it gets in this state Jul 2 11:51:01 xen48 kernel: [ 1417.987320] JWF (netbk_check_gop:529) Bad status -1 from copy to DOM2. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c13 --- Comment #13 from James Fehlig <jfehlig@novell.com> 2010-07-02 19:24:05 UTC --- Same "Unknown" change event when doing xm save Jul 2 13:19:36 xen48 kernel: [ 657.280667] JWF (frontend_changed:220) Unknown. Jul 2 13:19:36 xen48 kernel: [ 657.280806] JWF (netback_uevent:162) .. Jul 2 13:19:38 xen48 kernel: [ 659.424781] JWF (netbk_check_gop:529) Bad status -1 from copy to DOM1. Jul 2 13:19:40 xen48 kernel: [ 661.383212] JWF (netbk_check_gop:529) Bad status -1 from copy to DOM1. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c14 --- Comment #14 from Kattiganehalli srinivasan <ksrinivasan@novell.com> 2010-07-02 21:24:28 UTC --- In all the previous instances we have seen vifs hanging around it was related to references that were acquired on the interface under heavy network traffic that would take a long time (sometime hours) to drain out. In this case though (on xen75), I have been seeing this problem under absolutely no network load. netif_disconnect() is the function that does the final teardown of the VIF. In the case of a normal guest shutdown, this function gets called from the xenwatch thread as part of handling the guest state change (XenbusStateClosing). The xm destroy case is little different in the sense that we kill the guest without involving the guest. In this case we will receive the XenbusStateUnknown and the cleanup path is via netback_remove. In this version of netback, a new r/w semaphore has been introduced (teardown_sem) which is the root cause of the problem. Given that we have only one watch thread and all this code gets executed in the context of the watch thread, not clear why we need this semaphore. However, what is happening is that we are acquiring this semaphore in the write mode is netback_remove() and while still holding this semaphore we attempt to acquire this semaphore in the read mode in the function netback_uevent(). This is what causes the xenbus watch thread to get itself wedged even before cleaning up the vif - even if the vif were cleaned up it would not matter since we have lost the xenwatch thread! For what it is worth we did not have this teardown_sem in sles11 sp1. After the (July 4th) I will look at why this semaphore was introduced. For what it is worth, I got rid of this semaphore on xen75 and things are working - both destroy and save/restore. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c15 --- Comment #15 from Jan Beulich <jbeulich@novell.com> 2010-07-05 09:56:32 UTC --- The semaphore is required to avoid races between user mode access through sysfs (calling netback_uevent()) and teardown of a backend (see the email thread surrounding http://lists.xensource.com/archives/html/xen-devel/2010-05/msg01570.html). It does look like the locking I added was indeed too aggressive - I just wonder how that got through all sorts of testing during the minimally 5 weeks that this has been in place. Apparently the write lock ought to be acquired only after calling kobject_uevent(). With that adjustment I hope we can get back to the problem originally reported here... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c17 --- Comment #17 from Jan Beulich <jbeulich@novell.com> 2010-07-05 11:37:30 UTC --- (In reply to comment #12)
Oh, one final note. netbk dumps a lot of the following messages once it gets in this state
Jul 2 11:51:01 xen48 kernel: [ 1417.987320] JWF (netbk_check_gop:529) Bad status -1 from copy to DOM2.
The vast majority of the paths where this error (GNTST_general_error) gets returned has an accompanying guest warning message - did you check whether you got any, so (assuming this has nothing to do with the problem explained earlier) we could get an understanding what's going on (of course, this status would get routinely returned for domains that are dying from the hypervisor's perspective, so this particular case would likely not need further investigation). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c18 --- Comment #18 from James Fehlig <jfehlig@novell.com> 2010-07-05 15:54:25 UTC --- Ok, with the following change I'm not seeing orphaned vif devices when saving or destroying a domU. --- xenbus.c.orig 2010-07-05 09:29:49.179644945 -0600 +++ xenbus.c 2010-07-05 09:36:20.651635720 -0600 @@ -41,9 +41,12 @@ netback_remove_accelerators(be, dev); + if (be->netif) + kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE); + down_write(&teardown_sem); + if (be->netif) { - kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE); netif_disconnect(be->netif); be->netif = NULL; } Harold, it should fix your latest issues so we can return to the originally reported problem :-). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c22 --- Comment #22 from James Fehlig <jfehlig@novell.com> 2010-07-05 16:14:05 UTC --- Stephan, is it still possible to make fixes for 11.3? It would be nice to have the fix referenced in #18 since certain types of domU start failures, saving a domU, destroying a domU, etc. will leave netback in a state that requires reboot of entire host. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c23 --- Comment #23 from Harald Koenig <koenig@linux.de> 2010-07-06 13:48:12 UTC --- (In reply to comment #18)
Harold, it should fix your latest issues so we can return to the originally reported problem :-).
where/when can I et a rpm for testing ? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c24 --- Comment #24 from Jan Beulich <jbeulich@novell.com> 2010-07-06 14:59:51 UTC --- ftp://ftp.suse.com/pub/projects/kernel/kotd/openSUSE-11.3/ should have one pretty soon (within a day or so). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c25 --- Comment #25 from Stephan Kulow <coolo@novell.com> 2010-07-07 06:28:15 CEST --- I don't want a new kernel at this point, but from what I understand we can easily include it in a kernel maintenance update. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c29 Harald Koenig <koenig@linux.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|koenig@linux.de | --- Comment #29 from Harald Koenig <koenig@linux.de> 2010-07-19 14:04:13 UTC --- (In reply to comment #24)
ftp://ftp.suse.com/pub/projects/kernel/kotd/openSUSE-11.3/ should have one pretty soon (within a day or so).
oops, forgot to give feedback, sorry! kernel-xen-2.6.34.1-0.0.6.82d7a13.x86_64 fixed the problem, all domUs now start and stop fine (and multiple times;). one drawback: there was no iscsitarget-kmp-xen rpm for that kernel, so my iscsi server on that dom0 broke "silently" :-( any ETA for a 11.3 update kernel with this issue fixed, pleeeease.... ? ;-) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c30 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |meissner@novell.com --- Comment #30 from James Fehlig <jfehlig@novell.com> 2010-07-19 14:19:04 UTC --- (In reply to comment #29)
any ETA for a 11.3 update kernel with this issue fixed, pleeeease.... ? ;-)
Marcus, the xen kernel problem affecting SLE11 SP1 also affects 11.3 (actually the problem was found in 11.3 first). When can users expect an 11.3 kernel update? Thanks! -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c31 Marcus Meissner <meissner@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|meissner@novell.com | --- Comment #31 from Marcus Meissner <meissner@novell.com> 2010-07-19 14:28:48 UTC --- I would probably wait 2 -3 weeks to collect issues for the first update. the kernel of the day could be used in the meantime. Btw, can you (Jan) please also add the bnc#618678 to the SLE11 SP1 and 11.3 changelogs? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c33 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |koenig@linux.de --- Comment #33 from James Fehlig <jfehlig@novell.com> 2010-07-19 21:29:45 UTC --- Harald, Just to clarify, do you have any remaining issues after installing the fixed kernel? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c34 Harald Koenig <koenig@linux.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|koenig@linux.de | --- Comment #34 from Harald Koenig <koenig@linux.de> 2010-07-20 08:13:59 UTC --- (In reply to comment #33)
Harald,
Just to clarify, do you have any remaining issues after installing the fixed kernel?
no, I don't see any problems right now. that 11.3 dom0 server now runs for 12 days with 10 domUs (4 CPUs each and sometimes quite busy;) with no more issues so far. other than some missing *-kmp-* packages for that testing kernel (missing the typical suse/obs comfort;) which I had to build myself... there might one more iscsi raise condition problem in 11.3 (similar to #623470 for 11.2, but much more unlikely if still present at all) but I can't test this one with the production server anymore and my next test server isn't fully setup yet due to other tasks. if there are any iscsi/xen problems left, I'll open a new ticket... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c35 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #35 from James Fehlig <jfehlig@novell.com> 2010-07-20 14:03:04 UTC --- Ok, I'll close this one now. Thanks for the report and testing the fix. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=618678 http://bugzilla.novell.com/show_bug.cgi?id=618678#c36 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nice@titanic.nyme.hu --- Comment #36 from James Fehlig <jfehlig@novell.com> 2010-08-02 15:59:27 UTC --- *** Bug 626856 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=626856 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=618678 https://bugzilla.novell.com/show_bug.cgi?id=618678#c37 Swamp Workflow Management <swamp@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard| |maint:running:35398:moderat | |e --- Comment #37 from Swamp Workflow Management <swamp@suse.com> 2010-08-24 15:23:17 UTC --- The SWAMPID for this issue is 35398. This issue was rated as moderate. Please submit fixed packages until 2010-09-07. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=618678 https://bugzilla.novell.com/show_bug.cgi?id=618678#c38 Swamp Workflow Management <swamp@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard|maint:running:35398:moderat |maint:running:35398:moderat |e |e maint:released:11.3:35403 --- Comment #38 from Swamp Workflow Management <swamp@suse.com> 2010-09-08 13:08:43 UTC --- Update released for: kernel-debug, kernel-debug-base, kernel-debug-base-debuginfo, kernel-debug-debuginfo, kernel-debug-debugsource, kernel-debug-devel, kernel-debug-devel-debuginfo, kernel-default, kernel-default-base, kernel-default-base-debuginfo, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-desktop, kernel-desktop-base, kernel-desktop-base-debuginfo, kernel-desktop-debuginfo, kernel-desktop-debugsource, kernel-desktop-devel, kernel-desktop-devel-debuginfo, kernel-devel, kernel-ec2-devel, kernel-pae, kernel-pae-base, kernel-pae-base-debuginfo, kernel-pae-debuginfo, kernel-pae-debugsource, kernel-pae-devel, kernel-pae-devel-debuginfo, kernel-source, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-base-debuginfo, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-vanilla, kernel-vanilla-base, kernel-vanilla-base-debuginfo, kernel-vanilla-debuginfo, kernel-vanilla-debugsource, kernel-vanilla-devel, kernel-vanilla-devel-debuginfo, kernel-vmi-devel, kernel-xen, kernel-xen-base, kernel-xen-base-debuginfo, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, preload-kmp-default, preload-kmp-desktop Products: openSUSE 11.3 (debug, i586, x86_64) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=618678 https://bugzilla.novell.com/show_bug.cgi?id=618678#c Swamp Workflow Management <swamp@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard|maint:running:35398:moderat |maint:released:11.3:35403 |e maint:released:11.3:35403 | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com