carsten’s blog

Gestern habe ich von Novell einen aktualisierten Kernel bekommen in dem der CIFS Bug
behoben ist. Der Kernel hat, zumindesst vorübergehend (bis zum finalen release),
die Version 2.6.32.13-0.5.1.1726.0.PTF-default.

Im changelog findet sich folgender Eintrag:

- patches.fixes/cifs-fix-vfs-busy-inode-errors: Revert the commit that fixes
page refcount leak which is not required but causes hangs (bnc#627518).

Der neue Kernel ist noch nicht öffentlich verfügbar, die Änderung wird
aber aller vorrausicht nacht so in den Hauptkernel und somit das nächste
Update einfließen.

Update (13.09.2010 21:13):

Das offizielle Update des Kernels wurde heute frei geben, neben diversen Sicherheitsfixes wurden auch einige Bugs beseitigt.

Details dazu gibt es hier

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+0×69/0×71
Aug 10 12:26:03 linux-l4nm kernel: [  213.425296]  [<ffffffff810b9343>] bad_page+0xe3/0×170
Aug 10 12:26:03 linux-l4nm kernel: [  213.425300]  [<ffffffff810bc729>] __pagevec_free+0×39/0×50
Aug 10 12:26:04 linux-l4nm kernel: [  213.425305]  [<ffffffff810bf65a>] release_pages+0x1fa/0×250
Aug 10 12:26:04 linux-l4nm kernel: [  213.425311]  [<ffffffff810bf890>] ____pagevec_lru_add+0x1e0/0×200
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/0×220
Aug 10 12:26:04 linux-l4nm kernel: [  213.425340]  [<ffffffff810be92c>] ra_submit+0x1c/0×30
Aug 10 12:26:04 linux-l4nm kernel: [  213.425345]  [<ffffffff810b5a5e>] do_generic_file_read+0x33e/0×460
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/0×130
Aug 10 12:26:04 linux-l4nm kernel: [  213.425360]  [<ffffffff810fcf87>] vfs_read+0xc7/0×130
Aug 10 12:26:04 linux-l4nm kernel: [  213.425365]  [<ffffffff810fd0f3>] sys_read+0×53/0xa0
Aug 10 12:26:04 linux-l4nm kernel: [  213.425370]  [<ffffffff81002f7b>] system_call_fastpath+0×16/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

Seit etwa einer Woche bin ich im Besitz eines HTC Hero von T-Mobile. Heut erst ist mir aufgefallen das ich eine eingehende MMS Nachricht nicht korrekt empfangen konnte.

Es wurde nur ein Hinweis angezeigt das die Nachricht heruntergeladen werden könne, was allerdings während eines Telefonats direkt fehlschlägt.
Sobald nicht telefoniert wird dauert es einige Sekunden bis der Vorgang mit der Meldung “Nachricht kann nicht herunter geladen werden” abgebrochen wird.

Ich habe dann die T-Mobile Hotline mit meinem Problem konfrontiert, scheinbar war der Fehler dort noch nicht in Zusammenhang mit diesem Gerät bekannt. Nach etwa 20 Minuten habe ich dann zu Testzwecken einfach mal WiFI am Handy deaktiviert …. TADA schon gings. Nach Aussage des Supportmitarbeiters von T-Mobile ist das auch beim iPhone so. Er hatte zum Testen nur ein G1 zur Hand, dort war es aber scheinbar das gleiche Problem.

Bei meinem Nokia E61i hatte ich dieses Problem nie, aber da war man auch nicht “always on” mit dem WLAN.

HTC Hero

Hardware lebt nicht ewig, aber das Shuttle SN41g2 hat mir sechs Jahre lang gute Dienste geleistet und das sogar 24×7
Nun beulen sich so langsam einige Kondensatoren wodurch das System extrem instabil und somit mehr oder weniger unbrauchbar wurde.

Die letzte Hardwarekonfiguration sah wie folgt aus:

• Shuttle SN41g2 + Athlon XP 2800+
• 2x 1GB DDR 400
• AOPEN NVIDIA Geforce 6800GT (Single Slot)
• Maxtor 250GB IDE HDD

Das ganze wurde vom passenden Shuttle Netzteil (250W) getrieben was ich aufgrund der Grafikkarte nachgerüstet hatte.

Das Gehäuse und Netzteil konnten von meinem Bruder für sein Athlon64 Shuttle sogar noch als Ersatzteile verwendet werden, ganz begraben
muß ich das System also nicht.

Als neues Ersatzsystem habe ich mir nun ein Intel Core i7 2,66GHz mit folgender Ausstattung zugelegt:

• ASUS P6T Motherboard
• Corsair 3x 2GB DDR3 1333
• Corsair 550W Netzteil
• Sparkle NVIDIA Geforce 9800GT (passiv gekühlt)
• WD 500GB 32MB Caviar Black SATA HDD
• Coolermaster Elite 333 Gehäuse

Nach wie vor läuft auf meinem Desktop ein openSUSE 11.1 nun allerdings mit KDE 4.3. Im Zusammenspiel mit der neuen Grafikkarte laufen meine beiden SAMSUNG 24″ LCD Monitore nun in Full HD Auflösung. Bei der Auswahl der Komponenten habe ich großen Wert auf ein leises System gelegt
was sehr gut gelungen ist. Im Netzteil steckt ein 12cm Lüfter, ebenso im Gehäuse welcher vom Mainboard gesteuert wird. Der CPU Lüfter
ist ein Boxed Kühler von Intel, ebenso vom Board geregelt.

Vor einigen Tagen hatte ich mir Askozia als mögliche PBX für eine kleine
VoIP Umstellung angesehen. Dabei viel mir positiv die Backupfunktion in der Weboberfläche auf.

Nach kurzer Überlegung war mir klar das die Backups automatisiert durchgeführt werden müssen um immer
ein aktuelles Backup parat zu haben. Daraus ist dann in wenigen Minuten mein askozia-backup.sh Script entstanden.

Für die qmailadmin Version 1.2.12 habe ich heute einen ergänzenden Patch erstellt der es ermöglicht, das bei deaktivierter Spamerkennung eines Postfachs eine alternative Maildropkonfiguration aufgerufen werden kann. Dies stellt auch sicher das maildrop in jedem Fall in das Postfach zustellen kann und es nicht zu dem Fehler kommt  “/usr/bin/maildrop:_Home_directory_owned_by_wrong_user”. Diese Meldung kann durch eine nicht existierende Standardmaildropkonfigurationsdatei entstehen (~/.mailfilter).

qmailadmin-1.2.12-nospam_cmd.patch

Dieser Patch fügt die configure option ‘–enable-nospam-command’ hinzu, mit der ein alternativer Befehl definiert werden kann.

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+0×8/0×9
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/0×830
[<ffffffff80013388>] filemap_nopage+0×188/0×322
[<ffffffff8005dde9>] error_exit+0×0/0×84
[<ffffffff8003688b>] __strncpy_from_user+0×28/0×41
[<ffffffff8003687a>] __strncpy_from_user+0×17/0×41
[<ffffffff80012336>] getname+0x15b/0x1c1
[<ffffffff8001976e>] do_sys_open+0×17/0xbe
[<ffffffff8005d116>] system_call+0x7e/0×83

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