Bug#607114: Unresponsive Xen's dom0 system after 'general protection fault'
Package: linux-image-2.6-xen-amd64 Version: 2.6.26+17+lenny1 Severity: critical Tags: lenny After execution of xm create command I got messages in attached file. I got this for second time within one week. Not sure what the root cause is. Right now all of commands working with networking just hangs. Looks like it has something to do with 8021q module. All Xen domU's with NATed networks are reachable. -- System Information: Debian Release: 5.0.7 -- Regards, Peter Viskup Dec 14 21:25:17 server2 kernel: [1480447.233563] general protection fault: [1] SMP Dec 14 21:25:17 server2 kernel: [1480447.234227] CPU 0 Dec 14 21:25:17 server2 kernel: [1480447.234508] Modules linked in: ipt_MASQUERADE bonding 8021q iptable_nat nf_nat ext2 xt_physdev tun ext4dev jbd2 crc16 xfs bridge ipv6 xt_multiport ipt_LOG xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables loop ide_pci_generic ide_core ata_generic usbhid hid ff_memless psmouse serio_raw pcspkr sata_svw libata dock container bnx2 ohci_hcd firmware_class ehci_hcd button ipmi_si hpilo ipmi_msghandler uhci_hcd shpchp pci_hotplug i2c_piix4 i2c_core evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod thermal processor fan thermal_sys cciss scsi_mod [last unloaded: bonding] Dec 14 21:25:17 server2 kernel: [1480447.236466] Pid: 39, comm: xenwatch Not tainted 2.6.26-2-xen-amd64 #1 Dec 14 21:25:17 server2 kernel: [1480447.236466] RIP: e030:[] [] :8021q:__vlan_find_group+0x25/0x36 Dec 14 21:25:17 server2 kernel: [1480447.236466] RSP: e02b:88001fde1bc8 EFLAGS: 00010202 Dec 14 21:25:17 server2 kernel: [1480447.236466] RAX: 8800011aae68 RBX: 0005 RCX: a034a760 Dec 14 21:25:17 server2 kernel: [1480447.236466] RDX: 4068 RSI: 0005 RDI: 88001b484000 Dec 14 21:25:17 server2 kernel: [1480447.236466] RBP: 88001b484000 R08: R09: 880006de81d8 Dec 14 21:25:17 server2 kernel: [1480447.236466] R10: 88001b5a9008 R11: 80427778 R12: a01d2c60 Dec 14 21:25:17 server2 kernel: [1480447.236466] R13: 88001b484000 R14: 0005 R15: Dec 14 21:25:17 server2 kernel: [1480447.236466] FS: 7f91e60df6e0() GS:8053a000() knlGS: Dec 14 21:25:17 server2 kernel: [1480447.236466] CS: e033 DS: ES: Dec 14 21:25:17 server2 kernel: [1480447.236466] DR0: DR1: DR2: Dec 14 21:25:17 server2 kernel: [1480447.236466] DR3: DR6: 0ff0 DR7: 0400 Dec 14 21:25:17 server2 kernel: [1480447.236466] Process xenwatch (pid: 39, threadinfo 88001fde, task 88001fdd82c0) Dec 14 21:25:17 server2 kernel: [1480447.236466] Stack: a0346545 0010 803cfc0d Dec 14 21:25:17 server2 kernel: [1480447.236466] fff1 a01d2c60 88001b484000 Dec 14 21:25:17 server2 kernel: [1480447.236466] 0005 80242a24 88001b484000 Dec 14 21:25:17 server2 kernel: [1480447.236466] Call Trace: Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? :8021q:vlan_device_event+0x80/0x3a8 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? rtmsg_ifinfo+0xa1/0xd1 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? notifier_call_chain+0x29/0x4c Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? register_netdevice+0x28a/0x2ca Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? netif_alloc+0x16d/0x193 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? backend_create_netif+0x4e/0x8f Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? netback_probe+0x15e/0x1cf Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? read_otherend_details+0x7a/0xae Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? xenbus_dev_probe+0x77/0xee Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? driver_probe_device+0xd0/0x14d Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? __device_attach+0x0/0x5 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? bus_for_each_drv+0x43/0x72 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? down+0xe/0x36 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? device_attach+0x59/0x6a Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? bus_attach_device+0x27/0x5b Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? device_add+0x3a6/0x526 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? xenbus_probe_node+0x11e/0x19f Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? xenbus_dev_changed+0x154/0x170 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? xenbus_read_driver_state+0x26/0x3b Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? xenwatch_thread+0x0/0x186 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? xenwatch_handle_callback+0x15/0x48 Dec 14 21:25:17 server2 kernel: [1480447.236466] [] ? xenwatch_t
Bug#607114: Same error on second server
I got similar messages some days ago on different hardware (see attached file). Both servers are - running the same version of kernel and Debian - inter-connected with two Ethernet cross-cables in bond (balance-rr) with bridge and two vlans with MTU 9000 on top of it - totally different on hardware - server1 is Xeon 3210 based with all Intel Ethernet cards - server2 is Opteron 2431 based with Broadcom Ethernet cards -- Peter Viskup Dec 5 23:10:31 server1 kernel: [350429.816318] BUG: unable to handle kernel paging request at 004817f0 Dec 5 23:10:31 server1 kernel: [350429.816356] IP: [] :8021q:__vlan_find_group+0x25/0x36 Dec 5 23:10:31 server1 kernel: [350429.816390] PGD 11cbf067 PUD 1ebb5067 PMD 11cfc067 PTE 0 Dec 5 23:10:31 server1 kernel: [350429.816429] Oops: [1] SMP Dec 5 23:10:31 server1 kernel: [350429.816479] CPU 0 Dec 5 23:10:31 server1 kernel: [350429.816522] Modules linked in: xt_physdev ipt_MASQUERADE ipt_LOG xt_state iptable_mangle xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_filter ip_tables x_tables bridge ipv6 dm_crypt crypto_blkcipher 8021q coretemp ipmi_poweroff ipmi_watchdog ipmi_si ipmi_devintf ipmi_msghandler bonding loop serio_raw psmouse i2c_i801 pcspkr i2c_core button shpchp pci_hotplug evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod sd_mod floppy ahci libata scsi_mod dock e1000 ehci_hcd uhci_hcd e1000e thermal processor fan thermal_sys [last unloaded: scsi_wait_scan] Dec 5 23:10:31 server1 kernel: [350429.817142] Pid: 7066, comm: vconfig Not tainted 2.6.26-2-xen-amd64 #1 Dec 5 23:10:31 server1 kernel: [350429.817197] RIP: e030:[] [] :8021q:__vlan_find_group+0x25/0x36 Dec 5 23:10:31 server1 kernel: [350429.817292] RSP: e02b:880011de3e10 EFLAGS: 00010206 Dec 5 23:10:31 server1 kernel: [350429.817343] RAX: 88001ed4c4c0 RBX: 000a RCX: 000a Dec 5 23:10:31 server1 kernel: [350429.817427] RDX: 00481800 RSI: 000a RDI: 88001d896000 Dec 5 23:10:31 server1 kernel: [350429.817510] RBP: ffde R08: 7f31b6a02440 R09: Dec 5 23:10:31 server1 kernel: [350429.817594] R10: R11: 802e3c42 R12: 88001ded76a0 Dec 5 23:10:31 server1 kernel: [350429.817677] R13: 88001d896000 R14: 000a R15: 7fffeec1 Dec 5 23:10:31 server1 kernel: [350429.817762] FS: 7f31b6e5d6e0() GS:8053a000() knlGS: Dec 5 23:10:31 server1 kernel: [350429.817849] CS: e033 DS: ES: Dec 5 23:10:31 server1 kernel: [350429.817895] DR0: DR1: DR2: Dec 5 23:10:31 server1 kernel: [350429.817979] DR3: DR6: 0ff0 DR7: 0400 Dec 5 23:10:31 server1 kernel: [350429.818063] Process vconfig (pid: 7066, threadinfo 880011de2000, task 88001da65100) Dec 5 23:10:31 server1 kernel: [350429.818150] Stack: a01e511a 000a a01e51c9 ffbf Dec 5 23:10:31 server1 kernel: [350429.818253] a01e5a36 646e6f62 0031 Dec 5 23:10:31 server1 kernel: [350429.818351] 000a Dec 5 23:10:31 server1 kernel: [350429.818418] Call Trace: Dec 5 23:10:31 server1 kernel: [350429.818493] [] ? :8021q:__find_vlan_dev+0x8/0x36 Dec 5 23:10:31 server1 kernel: [350429.818550] [] ? :8021q:vlan_check_real_dev+0x81/0x8e Dec 5 23:10:31 server1 kernel: [350429.818608] [] ? :8021q:vlan_ioctl_handler+0x1c9/0x363 Dec 5 23:10:31 server1 kernel: [350429.818669] [] ? handle_mm_fault+0x5f8/0xc46 Dec 5 23:10:31 server1 kernel: [350429.818724] [] ? sk_prot_alloc+0x46/0xa4 Dec 5 23:10:31 server1 kernel: [350429.818778] [] ? sock_ioctl+0x171/0x1f8 Dec 5 23:10:31 server1 kernel: [350429.818831] [] ? vfs_ioctl+0x21/0x6b Dec 5 23:10:31 server1 kernel: [350429.818883] [] ? do_vfs_ioctl+0x248/0x261 Dec 5 23:10:31 server1 kernel: [350429.818937] [] ? sys_ioctl+0x51/0x70 Dec 5 23:10:31 server1 kernel: [350429.818990] [] ? system_call+0x68/0x6d Dec 5 23:10:31 server1 kernel: [350429.819043] [] ? system_call+0x0/0x6d Dec 5 23:10:31 server1 kernel: [350429.819095] Dec 5 23:10:31 server1 kernel: [350429.819132] Dec 5 23:10:31 server1 kernel: [350429.819169] Code: 89 e8 5d 41 5c c3 8b 97 80 00 00 00 89 d0 c1 e8 05 31 d0 83 e0 1f 48 8b 14 c5 a0 aa 1e a0 eb 03 48 8b 12 48 85 d2 75 03 31 c0 c3 <48> 39 7a f0 48 8b 02 0f 18 08 48 8d 42 f0 75 e5 c3 53 89 f3 e8 Dec 5 23:10:31 server1 kernel: [350429.819220] RIP [] :8021q:__vlan_find_group+0x25/0x36 Dec 5 23:10:31 server1 kernel: [350429.819220] RSP Dec 5 23:10:31 server1 kernel: [350429.819220] CR2: 004817f0 Dec 5 23:10:31 server1 kernel: [350429.820373] ---[ end trace 2455feeb7fc5a643 ]---
Bug#607114: Unresponsive Xen's dom0 system after 'general protection fault'
On 12/14/2010 10:27 PM, Bastian Blank wrote: On Tue, Dec 14, 2010 at 11:06:28PM +0200, Timo Juhani Lindfors wrote: Can you try linux-image-2.6.32-5-xen-amd64 2.6.32-29 from debian squeeze? You probably should be able to install it to a lenny system without upgrading the system otherwise. Install, yes. Use, no. It needs Xen 4.0. Bastian Hello Bastian and Timo, thank you for your quick responses. I want to run official Debian stable versions. Just find there is backports version linux-image-2.6.32-bpo.5-xen-amd64 available. I need to know what the bug is if the move to this backports kernel will help - just before I will install it. I am running production servers and cannot just test that. -- Peter Viskup -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d07e4f0.4080...@gmail.com
Bug#607141: xm block-attach failed on domU
Package: linux-image-2.6-xen-amd64 Version: 2.6.26-26lenny1 Severity: critical Tags: lenny Execution of xm block-attach to PV domU failed and I have got Ooops kernel messages in attachment. After that domU wasn't manageable from dom0 - all xm commands were not successful and I had to shutdown the domU from the pty (ssh) console. Both dom0 and domU were running same kernel version. -- Peter Viskup Dec 13 16:29:04 tis kernel: [83118.676876] BUG: unable to handle kernel NULL pointer dereference at Dec 13 16:29:04 tis kernel: [83118.676898] IP: [] backend_changed+0x1bf/0x23a Dec 13 16:29:04 tis kernel: [83118.676920] PGD 1e82f067 PUD 1f1a8067 PMD 0 Dec 13 16:29:04 tis kernel: [83118.676933] Oops: [1] SMP Dec 13 16:29:04 tis kernel: [83118.676941] CPU 0 Dec 13 16:29:04 tis kernel: [83118.676948] Modules linked in: iptable_filter ip_tables x_tables ipv6 xfs evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod thermal_sys cciss scsi_mod Dec 13 16:29:04 tis kernel: [83118.676991] Pid: 19, comm: xenwatch Not tainted 2.6.26-2-xen-amd64 #1 Dec 13 16:29:04 tis kernel: [83118.677000] RIP: e030:[] [] backend_changed+0x1bf/0x23a Dec 13 16:29:04 tis kernel: [83118.677015] RSP: e02b:88001fd11e60 EFLAGS: 00010246 Dec 13 16:29:04 tis kernel: [83118.677023] RAX: RBX: 880006dec000 RCX: Dec 13 16:29:04 tis kernel: [83118.677032] RDX: 88001fd11de8 RSI: 0005 RDI: 88001f12c400 Dec 13 16:29:04 tis kernel: [83118.677041] RBP: 8038327f R08: 0005 R09: Dec 13 16:29:04 tis kernel: [83118.677050] R10: 8800850bb000 R11: 8038cf45 R12: 88001f12c400 Dec 13 16:29:04 tis kernel: [83118.677059] R13: 8057c580 R14: 8057d1c0 R15: Dec 13 16:29:04 tis kernel: [83118.677070] FS: 7f53a5d766e0() GS:8053a000() knlGS: Dec 13 16:29:04 tis kernel: [83118.677080] CS: e033 DS: ES: Dec 13 16:29:04 tis kernel: [83118.677087] DR0: DR1: DR2: Dec 13 16:29:04 tis kernel: [83118.677097] DR3: DR6: 0ff0 DR7: 0400 Dec 13 16:29:04 tis kernel: [83118.677106] Process xenwatch (pid: 19, threadinfo 88001fd1, task 88001fd08140) Dec 13 16:29:04 tis kernel: [83118.677116] Stack: 8057c580 80383a01 88001f059c40 88001f12c400 Dec 13 16:29:04 tis kernel: [83118.677133] 8052a968 8057c580 8057d1c0 80381c19 Dec 13 16:29:04 tis kernel: [83118.677148] 00058038327f 88001f1f2d80 Dec 13 16:29:04 tis kernel: [83118.677161] Call Trace: Dec 13 16:29:04 tis kernel: [83118.677172] [] ? xenbus_device_find+0x28/0x31 Dec 13 16:29:04 tis kernel: [83118.677184] [] ? xenbus_read_driver_state+0x26/0x3b Dec 13 16:29:04 tis kernel: [83118.677195] [] ? xenwatch_thread+0x0/0x186 Dec 13 16:29:04 tis kernel: [83118.677206] [] ? xenwatch_handle_callback+0x15/0x48 Dec 13 16:29:04 tis kernel: [83118.677216] [] ? xenwatch_thread+0x16d/0x186 Dec 13 16:29:04 tis kernel: [83118.677227] [] ? autoremove_wake_function+0x0/0x2e Dec 13 16:29:04 tis kernel: [83118.677237] [] ? kthread+0x47/0x74 Dec 13 16:29:04 tis kernel: [83118.677247] [] ? schedule_tail+0x27/0x5c Dec 13 16:29:04 tis kernel: [83118.677257] [] ? child_rip+0xa/0x12 Dec 13 16:29:04 tis kernel: [83118.677268] [] ? kthread+0x0/0x74 Dec 13 16:29:04 tis kernel: [83118.677276] [] ? child_rip+0x0/0x12 Dec 13 16:29:04 tis kernel: [83118.677283] Dec 13 16:29:04 tis kernel: [83118.677287] Dec 13 16:29:04 tis kernel: [83118.677291] Code: 23 3e 17 00 c6 40 01 00 80 38 00 74 05 e8 f1 00 ff ff 48 8b 7b 08 e8 56 8e f7 ff c7 83 9c 1a 00 00 01 00 00 00 eb 74 48 8b 43 08 <8b> 38 c1 e7 14 0b 78 04 e8 10 40 f2 ff 48 85 c0 48 89 c5 75 16 Dec 13 16:29:04 tis kernel: [83118.677391] RIP [] backend_changed+0x1bf/0x23a Dec 13 16:29:04 tis kernel: [83118.677402] RSP Dec 13 16:29:04 tis kernel: [83118.677408] CR2: Dec 13 16:29:04 tis kernel: [83118.677419] ---[ end trace 75e2ecdeadd46e28 ]---
Bug#607114: Unresponsive Xen's dom0 system after 'general protection fault'
On 12/15/2010 03:13 AM, Ben Hutchings wrote: Do you create or modify VLAN devices when creating a new domain? No I don't create nor modify VLAN interfaces. I just add them to the bridge named 'xenin'. My config is like this: # bond over cross-cabling auto bond1 iface bond1 inet static pre-up modprobe bond1 slaves eth1 eth3 address 10.0.0.253 netmask 255.255.255.0 bond_mode balance-rr bond_updelay 400 bond_downdelay 400 bond_miimon 100 mtu 9000 auto vlan10 iface vlan10 inet static address 10.10.1.253 netmask 255.255.255.0 mtu 9000 vlan-raw-device bond1 auto vlan192 iface vlan192 inet static mtu 9000 address 192.168.190.253 netmask 255.255.255.0 vlan-raw-device bond1 auto xenin iface xenin inet static bridge_ports bond1 bridge_stp no address 192.168.0.253 netmask 255.255.255.0 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d085a83.4020...@gmail.com
Bug#607141: xm block-attach failed on domU
Hello Timo, for some reason I didn't received your question and I found it just now on bugs.debian.org pages. I didn't record my previous commands but I used standard xm block-attach syntax from vhost config like: 'xm block-attach phy:data/disk /dev/xvda6 w' I am mapping LVM LV's from VG named 'data' to my vhosts. -- Peter Viskup -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2a392c.3030...@gmail.com
Bug#949505: NFS client nfs4_reclaim_open_state: unhandled error -521
Package: linux-image-amd64 Version: 4.19+105 During logrotation of files residing on NFS share the NFS client report error "nfs4_reclaim_open_state: unhandled error -521". After that all the listings of the directory were hanging on IO. Only the subdirectory is affected, files and other directories out of the affected path are accessible with no issues. Mounted with: data.isil01.domain:/locofwd/fwd01 on /var/log/remotelogs type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.x.y.z,local_lock=none,addr=10.a.b.c) Storage does not support NFS4.1, thus vers=4 used. Following list of additional messages: Jan 19 00:45:04 hostname kernel: [4443714.789252] NFS: nfs4_reclaim_open_state: unhandled error -521 Jan 19 00:45:04 hostname kernel: [4443715.201988] NFS: nfs4_reclaim_open_state: unhandled error -521 Jan 19 00:45:07 hostname nfsidmap[783]: nss_getpwnam: name 'root@localdomain' does not map into domain 'domain' Jan 19 00:48:44 hostname kernel: [4443935.440497] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:48:44 hostname kernel: [4443935.440524] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:50:45 hostname kernel: [056.252424] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:50:45 hostname kernel: [056.252447] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:52:46 hostname kernel: [177.080276] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:52:46 hostname kernel: [177.080299] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:54:47 hostname kernel: [297.908274] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:54:47 hostname kernel: [297.908299] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:56:48 hostname kernel: [418.740935] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:56:48 hostname kernel: [418.740962] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:58:48 hostname kernel: [539.568271] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:58:48 hostname kernel: [539.568294] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 01:00:49 hostname kernel: [660.392945] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 01:00:49 hostname kernel: [660.392993] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 01:02:50 hostname kernel: [781.221763] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 01:02:50 hostname kernel: [781.221785] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 01:04:51 hostname kernel: [902.050367] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 01:04:51 hostname kernel: [902.050393] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 01:06:52 hostname kernel: [4445022.877976] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 01:06:52 hostname kernel: [4445022.878000] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 20 00:00:12 hostname nfsidmap[7278]: nss_getpwnam: name 'root@localdomain' does not map into domain 'domain' Peter
Bug#689861: Issues with Xen when all CPUs are available to dom0
Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-45 I am experiencing issues with Xen once all CPUs are available to dom0. There is high "steal time" shown once I do not set one CPU available for dom0 (doesn't matter what way is used - xend-config, Linux or Xen hypervisor boot argument). If all CPUs are available to dom0 all tries to start domU fail with timeouts. More detailed description is in xen-utils bugreport opened by me in July 2012 [1] with no response till today. It is reproducible on two different servers running Xen (one Intel Xeon and second AMD Opteron). Please consider if it is related to kernel or not. Anyway - we just jump into situation where no dynamic domU's configuration change is possible and this is causing us serious manageability and serviceability issues. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683170 Best regards, -- Peter Viskup -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50715f04.3050...@gmail.com
Bug#689861: Issues with Xen when all CPUs are available to dom0
xplains the CPU Affinity and where the issue is coming from. Anyway this was working before (don't know when exactly this issue raised). Could it be related to move to pv_ops kernels? Best regards, -- Peter Viskup -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50733822.10...@gmail.com
Bug#693851: Xen domU dynamic memory extension not working
Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-5 The dynamic memory extension is not working on PV domU kernel linux-image-2.6.32-5-xen-amd64 nor linux-image-2.6.32-5-amd64, but it's working once the domU is booting with linux-image-2.6.26-2-xen-amd64. During the investigation we discovered that the 'target' is updated correctly on dom0 and also /sys/devices/system/xen_memory/xen_memory0/target_kb file is correctly updated on domU - the only issue is that domU kernel do not make this memory 'change' effective. The shrink of memory is working well - only the increase above the initial memory value is not working - the same as expected on HVM guests. dom0 is booting linux-image-2.6.32-5-xen-amd64 and Debian's Xen 4.0.1 is installed on the system. There is long discussion [1] on the xen-users mailing list with no root cause found. Attached are domU and dom0 dmesg outputs. [1] http://lists.xen.org/archives/html/xen-users/2012-11/msg00104.html Best regards, -- Peter Viskup (XEN) Xen version 4.0.1 (Debian 4.0.1-5.4) (ultrot...@debian.org) (gcc version 4.4.5 (Debian 4.4.5-8) ) Sat Sep 8 19:15:46 UTC 2012 (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=756M numa=off loglvl=all guest_loglvl=all (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 6 MBR signatures (XEN) Found 6 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 00098000 (usable) (XEN) 00098000 - 0010 (reserved) (XEN) 0010 - dfcf (usable) (XEN) dfcf - dfd96000 (ACPI NVS) (XEN) dfd96000 - dfdfd000 (usable) (XEN) dfdfd000 - dfe5f000 (reserved) (XEN) dfe5f000 - dfe6a000 (usable) (XEN) dfe6a000 - dfedf000 (ACPI NVS) (XEN) dfedf000 - dfee7000 (usable) (XEN) dfee7000 - dfeff000 (ACPI data) (XEN) dfeff000 - dff0 (usable) (XEN) dff0 - e000 (reserved) (XEN) f000 - f400 (reserved) (XEN) fff8 - fff8c000 (reserved) (XEN) 0001 - 00022000 (usable) (XEN) ACPI: RSDP 000F03C0, 0024 (r2 INTEL ) (XEN) ACPI: XSDT DFEFE120, 009C (r1 INTEL S3200SHX0 INTL 113) (XEN) ACPI: FACP DFEFB000, 00F4 (r3 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: DSDT DFEF5000, 579C (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: FACS DFE6A000, 0040 (XEN) ACPI: APIC DFEF4000, 0090 (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: WDDT DFEF3000, 0040 (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: MCFG DFEF2000, 003C (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: SPCR DFEF1000, 0050 (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: DMAR DFEF, 0110 (r1 INTEL S3200SHX1 MSFT 113) (XEN) ACPI: SSDT DFEEF000, 0175 (r1 INTEL Cpu0Ist 10 MSFT 113) (XEN) ACPI: SSDT DFEEE000, 0175 (r1 INTEL Cpu1Ist 10 MSFT 113) (XEN) ACPI: SSDT DFEED000, 0175 (r1 INTEL Cpu2Ist 10 MSFT 113) (XEN) ACPI: SSDT DFEEC000, 0175 (r1 INTEL Cpu3Ist 10 MSFT 113) (XEN) ACPI: SSDT DFEEB000, 01BC (r1 INTEL CpuPm 10 MSFT 113) (XEN) ACPI: HEST DFEEA000, 00A8 (r1 INTEL S3200SHX1 INTL1) (XEN) ACPI: BERT DFEE9000, 0030 (r1 INTEL S3200SHX1 INTL1) (XEN) ACPI: ERST DFEE8000, 0230 (r1 INTEL S3200SHX1 INTL1) (XEN) ACPI: EINJ DFEE7000, 0130 (r1 INTEL S3200SHX1 INTL1) (XEN) System RAM: 8189MB (8385548kB) (XEN) NUMA turned off (XEN) Faking a node at -00022000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000fd1f0 (XEN) DMI 2.5 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0] (XEN) ACPI: wakeup_vec[dfe6a00c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee0 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 6:15 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) Processor #2 6:15 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) (XEN) Processor #1 6:15 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) (XEN) Processor #3 6:15 APIC version 20 (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1]) (XEN) ACPI: IOAPIC (id[0x05] address[0xfec0] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 5, version 32, address 0xfec0, GSI 0-23 (XEN)
Bug#693851: Xen domU dynamic memory extension not working
On 11/21/2012 09:38 AM, Ian Campbell wrote: On Wed, 2012-11-21 at 00:32 +0100, Peter Viskup wrote: dom0 is booting linux-image-2.6.32-5-xen-amd64 and Debian's Xen 4.0.1 is installed on the system. There is long discussion [1] on the xen-users mailing list with no root cause found. I'm afraid that the advice here remains the same as it was in that thread. The suggestions in <1353431265.13542.83.ca...@zakaz.uk.xensource.com> and <1353433383.13542.91.ca...@zakaz.uk.xensource.com> remain relevant and useful to try. Ian. Not sure what suggestions you really mean - as the links are somehow broken. Anyway the upgrade to wheezy's kernel is not an option for me at this time as I will run the Squeeze at least for next upcoming months. Would be great to have it fixed or inform users on the Debian's Xen wiki at least/worst. -- Peter -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50acbf5b.3020...@gmail.com
Bug#693851: Xen domU dynamic memory extension not working
On 11/21/2012 01:11 PM, Ben Hutchings wrote: On Wed, 2012-11-21 at 12:47 +0100, Peter Viskup wrote: On 11/21/2012 09:38 AM, Ian Campbell wrote: On Wed, 2012-11-21 at 00:32 +0100, Peter Viskup wrote: dom0 is booting linux-image-2.6.32-5-xen-amd64 and Debian's Xen 4.0.1 is installed on the system. There is long discussion [1] on the xen-users mailing list with no root cause found. I'm afraid that the advice here remains the same as it was in that thread. The suggestions in <1353431265.13542.83.ca...@zakaz.uk.xensource.com> and <1353433383.13542.91.ca...@zakaz.uk.xensource.com> remain relevant and useful to try. Ian. Not sure what suggestions you really mean - as the links are somehow broken. [...] Those are message IDs; look them up on http://lists.debian.org/msgid-search/ and you'll get to: http://article.gmane.org/gmane.comp.emulators.xen.user/76514 http://article.gmane.org/gmane.comp.emulators.xen.user/76516 Ben. Hi all, could anybody comment this sentence from older xen-users discussions [1]? "AFAIK, the new pv_ops kernel does not support adding memory online yet (only balloon down and back). With older xenified-kernels (like Redhat's kernel-xen), it should work with newer updates." Isn't this the case of this 2.6.32 kernel too? [1] http://lists.xen.org/archives/html/xen-users/2009-03/msg00795.html -- Peter -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50ad6161.60...@gmail.com
Bug#693851: Xen domU dynamic memory extension not working
On 11/28/2012 12:24 AM, Peter Viskup wrote: Test if it is working for wheezy at least and let us know. I just found email [1] from Alexandre where he stated he tested the Wheezy version already and it is working. My issues with backported kernel could be related to hypervisor version 4.0 as on wheezy there is 4.1 already. This could be documented somewhere. [1] http://lists.xen.org/archives/html/xen-users/2012-11/msg00176.html -- Peter Viskup -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50b5ff9b.9040...@gmail.com
Bug#607114: Unresponsive Xen's dom0 system after 'general protection fault'
Hello Jonathan, unfortunately I upgraded that server to Squeeze already. The good news is that on Squeeze I already used xm block-attach many times without any issue. I have one last box with Lenny with some production systems, but cannot test that on this box. Best regards, -- Peter Viskup On 02/18/2012 02:38 AM, Jonathan Nieder wrote: Hi Peter, Peter Viskup wrote: After execution of xm create command I got messages in attached file. I got this for second time within one week. Not sure what the root cause is. Right now all of commands working with networking just hangs. Looks like it has something to do with 8021q module. All Xen domU's with NATed networks are reachable. Sorry for the long silence. Are these the same machines as bug#607141? If the problem is still present, please attach kernel messages from booting (they might be in "dmesg" or might be somewhere in /var/log/dmesg* if they scrolled away) and a more recent trace. If it is no longer present, do you remember when it went away? Curious, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f3f88ac.5080...@gmail.com
Bug#908647: CPU hog during fcheck task
Package: linux-latest Version: 4.9.110-3+deb9u4 Severity: important After kernel update on Debian9 system from 4.9.65-3+deb9u1 to 4.9.110-3+deb9u4 the fcheck cron job run +45000 seconds instead of original +8500 seconds (tested twice with same results). Tested with command $ perf stat -B -o fcheck.perf.stat nocache nice ionice -c3 /usr/sbin/fcheck -asxrf /etc/fcheck/fcheck.cfg >/var/run/fcheck.out 2>&1 $ grep "time elapsed" fcheck.perf.stat* fcheck.perf.stat:8573.851887243 seconds time elapsed fcheck.perf.stat2:8544.105864343 seconds time elapsed fcheck.perf.stat3: 45450.729247342 seconds time elapsed fcheck.perf.stat4: 45808.049670206 seconds time elapsed -- Peter
