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.

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

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”;
}