carsten’s blog

Während einiger Wartungsarbeiten und einem damit verbundenen Kernelupdate auf die derzeit
für SLES 11 SP2 aktuelle Kernel Version 3.0.80 bin ich auf einen Fehler in Verbindung mit DRBD gestoßen.

Das Update selbst liefert keine neuen drbd kmp Pakete mit, sondern verwendet weiterhin eine Vorgängerversion (8.4.2_3.0.51_0.7.9-0.6.6.4)

Der Fehler äußert sich direkt beim Laden des drbd Moduls mit folgender Meldung:

[ 154.173134] events: mcg drbd: 3
[ 154.174916] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 154.174927] IP: [] cleanup_module+0xb0/0x150 [drbd]
[ 154.174949] PGD 7927f8067 PUD 7a0a83067 PMD 0
[ 154.174954] Oops: 0000 [#1] SMP
[ 154.174959] CPU 7
[ 154.174960] Modules linked in: drbd(+) crc32c libcrc32c ip6table_filter ip6_tables iptable_filter ip_tables x_tables nbd usbbk netbk blkbk blkback_pagemap blktap xenbus_be gntdev evtchn mpt2sas scsi_transport_sas raid_class mptctl mptbase ipmi_devintf ipmi_si ipmi_msghandler dell_rbu(X) bridge 8021q garp stp llc bonding microcode fuse loop dm_mod joydev bnx2 usbhid hid sg ses enclosure sr_mod 8250_pnp ipv6 ipv6_lib pcspkr tpm_tis tpm tpm_bios i2c_piix4 i2c_core dcdbas(X) k10temp domctl 8250 serial_core rtc_cmos serio_raw button acpi_power_meter ohci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh_emc scsi_dh xenblk cdrom xennet edd ext3 mbcache jbd fan processor ata_generic pata_atiixp ahci libahci libata megaraid_sas scsi_mod thermal thermal_sys hwmon
[ 154.175039] Supported: Yes, External
[ 154.175041]
[ 154.175044] Pid: 12110, comm: modprobe Tainted: G X 3.0.80-0.5-xen #1 Dell Inc. PowerEdge R515/03X0MN
[ 154.175050] RIP: e030:[] [] cleanup_module+0xb0/0x150 [drbd]
[ 154.175064] RSP: e02b:ffff88079e8efef8 EFLAGS: 00010203
[ 154.175066] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 154.175069] RDX: fffffffffffffff8 RSI: ffff88079e8eff0c RDI: ffffffffa04fe600
[ 154.175072] RBP: ffff88079e8eff0c R08: 0000000000000000 R09: 0000000800040008
[ 154.175075] R10: 0000000100030008 R11: 0000001800010006 R12: ffffffffa0508000
[ 154.175078] R13: 0000000000000000 R14: 0000000000623230 R15: 0000000000000000
[ 154.175084] FS: 00007f92fdf3a700(0000) GS:ffff8807c14e0000(0000) knlGS:0000000000000000
[ 154.175088] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 154.175090] CR2: 0000000000000000 CR3: 00000007a793c000 CR4: 0000000000000660
[ 154.175094] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 154.175097] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 154.175100] Process modprobe (pid: 12110, threadinfo ffff88079e8ee000, task ffff880792438580)
[ 154.175103] Stack:
[ 154.175105] 0000000000000000 ffffffffa04d8f05 0000000000000000 00000000fffffff4
[ 154.175110] 0000000000081dd8 ffffffffa0508085 ffffffffa04fe240 ffffffff8000403b
[ 154.175115] 0000000000000000 ffffffffa04fe240 0000000000081dd8 00007f92fdeb7000
[ 154.175121] Call Trace:
[ 154.175158] [] init_module+0x85/0x1000 [drbd]
[ 154.175177] [] do_one_initcall+0x3b/0x190
[ 154.175185] [] sys_init_module+0xcf/0x240
[ 154.175192] [] system_call_fastpath+0x16/0x1b
[ 154.175201] [<00007f92fda9635a>] 0x7f92fda96359
[ 154.175204] Code: 24 14 01 48 89 ee 48 c7 c7 00 e6 4f a0 e8 69 80 d3 df 48 85 c0 48 89 c3 75 b1 48 8b 05 ba 59 02 00 48 8d 50 f8 48 3d 20 e6 4f a0
[ 154.175228] 8b 4a 08 74 5b 48 8d 59 f8 eb 07 0f 1f 40 00 48 89 f3 48 8b
[ 154.175241] RIP [] cleanup_module+0xb0/0x150 [drbd]
[ 154.175253] RSP
[ 154.175255] CR2: 0000000000000000
[ 154.175258] —[ end trace ae9d139fe656969d ]—
[ 171.660668] IPMI System Interface driver.
[ 171.660720] ipmi_si: probing via SMBIOS
[ 171.660724] ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 0
[ 171.660727] ipmi_si: Adding SMBIOS-specified kcs state machine
[ 171.660733] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca8, slave address 0x20, irq 0
[ 172.742032] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x0002a2, prod_id: 0x0100, dev_id: 0x20)
[ 172.742111] ipmi_si ipmi_si.0: IPMI kcs interface initialized

Ich habe den Fehler dann direkt (19.06.2013) als Servicerequest bei Novell gemeldet, heute am 21.06.2013 wurde mir ein PTF bereit gestellt der das Problem behebt.
Zwischenzeitlich hatte ich ein Kerneldowngrade auf die Version 3.0.74-0.6.10.1 durchgeführt, damit meine Systeme wieder einwandfrei arbeiten.

Ursache des ganzen war folgendes:

It is because of a silent change in KABI for xen.
Which requires the drbd module to be re-compiled against the actual
kernel. Also we have found and fixed the NULL pointer dereference possibility
in drbd code.

Öffentlich soll der Fix im laufe der KW26 werden, sofern nichts größeres dazwischen kommt.

Update 25.06.2013:
Der Vorabfix wurde heute von SUSE zurück gezogen und ein komplettes Kernel Update angekündigt, da die KABI
Änderungen wohl umfangreicher ausfallen. Nach dem Update soll das alte drbd Kernel Modul wieder kompatibel sein.

Update 05.07.2013:
Ein neues Kernelupdate (SUSE-SU-2013:1151-1 / Version 3.0.80-0.7.1) wurde released, welches das Problem nun final löst.

Eine neue Version von stresslinux basierend auf openSUSE 11.4 steht zum download bereit. Neben den Neuerungen der Basisdistribution sind auch wieder einige

zusätzliche Pakete aktualisiert worden, dazu gehören:

• busybox 1.18.4
• iperf 2.0.5
• lm_sensors 3.3.0
• lshw B.02.15
• memtest86 4.0
• memtest86+ 4.20
• mprime 2.6.5
• smartmontools 5.40.3314
• x86info 1.29
• y-cruncher 0.5.5.9179

Wie immer gibt es  ISO, USB und VMware Images zum download.

Viel Spaß beim Testen!

Die erste Version von stresslinux basierend auf openSUSE 11.3 steht zum download bereit. Neben den Neuerungen der Basisdistribution (von 11.2 auf 11.3) sind auch einige

zusätzliche Pakete aktualisiert worden, dazu gehören:

• bandwidth 0.23a
• busybox 1.17.2
• memtester 4.2.0
• stressapptest 1.0.3
• x86info 1.27

Leider gibt es seitens SUSESTUDIO noch keine Möglichkeit PXE Versionen zu erstellen, daher sind weiterhin nur ISO, USB und VMware Images verfügbar.

Viel Spaß beim Testen!

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.

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

Vor einiger Zeit habe ich eine DHCP Konfiguration für XEN VMs benötigt um diese per PXE installieren zu können. Die im Beispiel angegebenen IP Adressen sind in meiner tatsächlichen Konfiguration anders, der rest ist identisch.

# dhcp config for xen & vmware virtual machines (with pxelinux support)
default-lease-time 600;
max-lease-time 7200;

ddns-update-style none; ddns-updates off;
authoritative;
log-facility local7;

allow booting;
allow bootp;

class “xensource” {
match if (substring(hardware,1,3)=00:16:3e);
}
class “vmware” {
match if (
(substring(hardware,1,3)=00:0c:29) or
(substring(hardware,1,3)=00:05:69) or
(substring(hardware,1,3)=00:1c:14) or
(substring(hardware,1,3)=00:50:56)
);
}
class “virtualbox” {
match if (substring(hardware,1,3)=08:00:27);
}
subnet 10.72.0.0 netmask 255.255.255.0 {
pool {
allow members of “xensource”;
allow members of “vmware”;
allow members of “virtualbox”;
range 10.72.0.100 10.72.0.254;
}
option broadcast-address 10.72.0.255;
option domain-name “vms.domain.tld”;
option routers 10.72.0.1;
option domain-name-servers 10.72.0.2, 10.72.0.3;
option tftp-server-name “10.72.0.5”;
next-server 10.72.0.5;
filename “/pxelinux.0”;
}