carsten’s blog

Bei einem Kernelupdate eines SLES 10 SP3 Gastsystems auf einem SLES 11 SP1 XEN Host
kam es bei mir, während der letzten Kernelupdates in den DomUs vor,
das ich erst von PV auf HVM und nun wieder auf PV wechseln mußte
damit die virtuellen Maschinen wieder booten konnten.

Das erste Update war von 2.6.16.60-0.62.1 auf 2.6.16.60-0.66.1
und dann kam das heutige auf die Version 2.6.16.60-0.67.1

Nach dem einspielen des letzten Updates kamen meine DomUs nicht mehr hoch.
Ein ‘xm list’ zeigte einen normalen status. Ein Versuch die Console der VM
zu öffnen mittels ‘xm console <domain>’ wurde mit folgendem Fehler abgebrochen:

xenconsole: Could not read tty from store: No such file or directory

Ein neustart des xend und auch ein reboot des gesamten Hostsystems hat
nicht geholfen, da mein erster Verdacht in Richtung xenconsoled ging hatte
ich dies zuerst versucht. Leider bis hierher vergebens.

Dann erinnerte ich mich das ich beim Kernelupdate davor auf HVM wechseln
mußte damit meine DomUs wieder hoch kamen. Also war der nächste Schritt
diese Umstellung rückgängig zu machen.
Das ganze klappte auf Anhieb und alle VMs laufen nun wieder paravirtualisiert.

Anfang dieser Woche ist mir nach der Neuinstallation einer Workstation bzw. beim updaten vorhandener Systeme ein Kernel BUG im CIFS Treiber untergekommen.

Bei gemounteten Freigaben unseres Samba Servers kommt es beim Lesen oder Schreiben (Verzeichnislisting funktionert – “ls -al”) auf die Freigabe zu einem Lockup, welcher sich im Systemlog wie folgt darstellt.

Aug 10 12:26:03 linux-l4nm kernel: [  213.425273] BUG: Bad page state in process cp  pfn:694cc
Aug 10 12:26:03 linux-l4nm kernel: [  213.425276] page:ffffea0001708ca0 flags:0020000000000010 count:0 mapcount:0 mapping:ffff880069c62ea8 index:e
Aug 10 12:26:03 linux-l4nm kernel: [  213.425279] Pid: 3289, comm: cp Tainted: G    B   W  X 2.6.32.13-0.5-default #1
Aug 10 12:26:03 linux-l4nm kernel: [  213.425281] Call Trace:
Aug 10 12:26:03 linux-l4nm kernel: [  213.425286]  [<ffffffff810061dc>] dump_trace+0x6c/0x2d0
Aug 10 12:26:03 linux-l4nm kernel: [  213.425291]  [<ffffffff81394848>] dump_stack+0x69/0x71
Aug 10 12:26:03 linux-l4nm kernel: [  213.425296]  [<ffffffff810b9343>] bad_page+0xe3/0x170
Aug 10 12:26:03 linux-l4nm kernel: [  213.425300]  [<ffffffff810bc729>] __pagevec_free+0x39/0x50
Aug 10 12:26:04 linux-l4nm kernel: [  213.425305]  [<ffffffff810bf65a>] release_pages+0x1fa/0x250
Aug 10 12:26:04 linux-l4nm kernel: [  213.425311]  [<ffffffff810bf890>] ____pagevec_lru_add+0x1e0/0x200
Aug 10 12:26:04 linux-l4nm kernel: [  213.425320]  [<ffffffffa04c06fc>] cifs_readpages+0x3dc/0x4d0 [cifs]
Aug 10 12:26:04 linux-l4nm kernel: [  213.425335]  [<ffffffff810be83a>] __do_page_cache_readahead+0x14a/0x220
Aug 10 12:26:04 linux-l4nm kernel: [  213.425340]  [<ffffffff810be92c>] ra_submit+0x1c/0x30
Aug 10 12:26:04 linux-l4nm kernel: [  213.425345]  [<ffffffff810b5a5e>] do_generic_file_read+0x33e/0x460
Aug 10 12:26:04 linux-l4nm kernel: [  213.425350]  [<ffffffff810b6296>] generic_file_aio_read+0xd6/0x1f0
Aug 10 12:26:04 linux-l4nm kernel: [  213.425355]  [<ffffffff810fc7e3>] do_sync_read+0xe3/0x130
Aug 10 12:26:04 linux-l4nm kernel: [  213.425360]  [<ffffffff810fcf87>] vfs_read+0xc7/0x130
Aug 10 12:26:04 linux-l4nm kernel: [  213.425365]  [<ffffffff810fd0f3>] sys_read+0x53/0xa0
Aug 10 12:26:04 linux-l4nm kernel: [  213.425370]  [<ffffffff81002f7b>] system_call_fastpath+0x16/0x1b
Aug 10 12:26:04 linux-l4nm kernel: [  213.425376]  [<00007f05e409df30>] 0x7f05e409df30

Ich habe dazu bei Novell einen Service Request geöffnet welcher, derzeit vom Engineering bearbeitet wird und vorraussichtlich mit einem neuen Kernelupdate gefixt wird.

Gestern hat Novell das Service Pack 1 für SUSE Linux Enterprise 11 offiziell zugänglich gemacht. Sowohl neue ISO Images als auch die nötigen Updatepakete werden verteilt.

Die neue Version bringt neben XEN 4.0 nun auch KVM mit und läuft mit einem aktualisierten Kernel 2.6.32.

Die wichtigsten Links im Netz:
Novell Announcement
How to update

In fast jeder VMware ESX Umgebung habe ich den folgenden Softlockup auf CentOS 5 Gastsystemen gesehen. Allerdings nur mit installierten VMware-Tools. Auf Nachfrage beim Support hat sich herrausgestellt, das dieses Verhalten dadurch zustande kommt, das die jeweilige CPU kurzzeitig nicht zur Verfügung steht weil Sie z.B. von einer anderen virtuellen Maschine benutzt wird. Der Fehler tritt besonders häufig auf wenn die VM vier CPU Cores zugeweisen bekommt.

Auf einem Dual Quad Core Host mit zwei VMs mit je vier Cores ist es also leicht reproduzierbar, da auf dem ersten Core ja zusätzlich noch die Serviceconsole von VMware ESX läuft.  Den Virtuellen Systemen sind also mehr Cores zugeweisen als eigentlich verfügbar. Im Normalfall ist das kein Problem solang die VMs nicht unter hoher Last laufen, bei extremer Auslastung der einzelnen Cores in den VMs kann dieses Verhalten dann ausgelöst werden. Vorbeugend kann man die VMs nur auf zwei Cores heruntersetzen.

BUG: soft lockup – CPU#1 stuck for 10s! [sh:2723]
CPU 1:
Modules linked in: xt_tcpudp iptable_nat ip_nat ip_conntrack nfnetlink ip_tables x_tables ipv6 xfrm_nalgo crypto_api nfsd exportfs lockd nfs_acl auth_rpcgss vmmemctl(U) sunrpc vmhgfs(U) dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec button battery asus_acpi acpi_memhotplug ac lp sg i2c_piix4 ide_cd shpchp floppy i2c_core cdrom e1000 pcspkr parport_pc serio_raw parport ata_piix libata mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Pid: 2723, comm: sh Tainted: G      2.6.18-92.1.22.el5 #1
RIP: 0010:[<ffffffff80064af8>]  [<ffffffff80064af8>] _spin_unlock_irqrestore+0x8/0x9
RSP: 0018:ffff810227b39d50  EFLAGS: 00000296
RAX: ffff8102feb27b30 RBX: ffff8102feb27ac0 RCX: 000000000000003b
RDX: ffff810100000000 RSI: 0000000000000296 RDI: ffff8102feb27b2c
RBP: 000000000048c04e R08: ffff8102feb27ac0 R09: ffff81010d29e800
R10: 0000000000000008 R11: 000000d000000001 R12: 0000000000000008
R13: 000000d000000001 R14: ffffffff800093b2 R15: 0000000000000018
FS:  00002aec39b81dc0(0000) GS:ffff81010d30c840(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000048c04e CR3: 000000022ddbd000 CR4: 00000000000006e0

Call Trace:
[<ffffffff800668a2>] do_page_fault+0x4fe/0x830
[<ffffffff80013388>] filemap_nopage+0x188/0x322
[<ffffffff8005dde9>] error_exit+0x0/0x84
[<ffffffff8003688b>] __strncpy_from_user+0x28/0x41
[<ffffffff8003687a>] __strncpy_from_user+0x17/0x41
[<ffffffff80012336>] getname+0x15b/0x1c1
[<ffffffff8001976e>] do_sys_open+0x17/0xbe
[<ffffffff8005d116>] system_call+0x7e/0x83