Welches Modul/Treiber für welche Hardware, Kernel compilieren...
-
Bowser
- Beiträge: 60
- Registriert: 17.02.2006 18:35:08
Beitrag
von Bowser » 20.04.2009 17:07:48
Ich arbeite hier auf einem Dell PowerEdge 2950 mit Debian Lenny auf dem neuesten Stand (also 5.0.1) drauf. Das System ist im Prinzip nur dazu da einige VMs (auch Lenny) mit KVM/libvirt zu hosten. Im Normalfall laufen die VMs auch ganz gut, nur alle paar Tage wenn die Last einmal höher ist bekomm ich einen tollen Fehler in der VM. Ein auszug aus messages:
Code: Alles auswählen
Apr 20 11:58:46 hohetauern kernel: [396953.358202] Modules linked in: binfmt_misc rfcomm l2cap bluetooth ppdev parport_pc lp parport ipv6 nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc fuse loop serio_raw virtio_net psmouse button pcspkr i2c_piix4 i2c_core evdev ext3 jbd mbcache ide_cd_mod cdrom ide_pci_generic virtio_blk floppy piix ide_core virtio_pci virtio_ring virtio ata_generic libata uhci_hcd scsi_mod dock thermal processor fan thermal_sys
Apr 20 11:58:46 hohetauern kernel: [396953.358202] CPU 0:
Apr 20 11:58:46 hohetauern kernel: [396953.358202] Modules linked in: binfmt_misc rfcomm l2cap bluetooth ppdev parport_pc lp parport ipv6 nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc fuse loop serio_raw virtio_net psmouse button pcspkr i2c_piix4 i2c_core evdev ext3 jbd mbcache ide_cd_mod cdrom ide_pci_generic virtio_blk floppy piix ide_core virtio_pci virtio_ring virtio ata_generic libata uhci_hcd scsi_mod dock thermal processor fan thermal_sys
Apr 20 11:58:46 hohetauern kernel: [396953.358202] Pid: 0, comm: swapper Not tainted 2.6.26-2-amd64 #1
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RIP: 0010:[<ffffffff8021eb68>] [<ffffffff8021eb68>] native_safe_halt+0x2/0x3
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RSP: 0018:ffffffff80573f38 EFLAGS: 00000246
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RAX: ffffffff80573fd8 RBX: 0000000000000000 RCX: 0000000000000000
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff804fae70
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RBP: 000000000b18fdba R08: ffff8100010356a0 R09: ffff81026acf9830
Apr 20 11:58:46 hohetauern kernel: [396953.358202] R10: ffff810281c49928 R11: ffff81026acf9830 R12: ffffffff80573ed8
Apr 20 11:58:46 hohetauern kernel: [396953.358202] R13: 0000000000000000 R14: ffffffff8023cec0 R15: 00013752d6207d52
Apr 20 11:58:46 hohetauern kernel: [396953.358202] FS: 0000000000000000(0000) GS:ffffffff8053b000(0000) knlGS:0000000000000000
Apr 20 11:58:46 hohetauern kernel: [396953.358202] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Apr 20 11:58:46 hohetauern kernel: [396953.358202] CR2: 0000000003b117a8 CR3: 000000029a9a5000 CR4: 00000000000006e0
Apr 20 11:58:46 hohetauern kernel: [396953.358202] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 20 11:58:46 hohetauern kernel: [396953.358202] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 20 11:58:46 hohetauern kernel: [396953.358202]
Apr 20 11:58:46 hohetauern kernel: [396953.358202] Call Trace:
Apr 20 11:58:46 hohetauern kernel: [396953.358202] [<ffffffff8020b0cd>] ? default_idle+0x2a/0x49
Apr 20 11:58:46 hohetauern kernel: [396953.358202] [<ffffffff8020ac79>] ? cpu_idle+0x89/0xb3
Apr 20 11:58:46 hohetauern kernel: [396953.358202]
Und im Terminal direkt (von der VM wieder) stehen tolle messages ala "CPU stuck for XYZ seconds". Die VM ist dann ziemlich komplett tot und nur noch über VNC bzw. eben virt-viewer ansprechbar. Befehler ausführen funkt überhaupt nichtmehr, auch kein halt, reboot etc. Ich bin mir jetzt nichteinmal sicher ob die logs was mit dem Fehler zu tun haben aber bis jetzt ist es fast der einzige Ansatz. Im Host System rennt noch alles und htop zeigt eine CPU von den 8 auf 100% Auslastung.
Hat irgendjemand von euch eine Idee/Ansatz wie man das beheben könnte. Das ganze soll ja stabil rennen und so bringt mir das nicht viel. Danke schonmal...
-
storm
- Beiträge: 1581
- Registriert: 01.05.2004 13:21:26
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DE
Beitrag
von storm » 21.04.2009 07:26:41
Es wäre natürlich hilfreich, wenn du das vollständige oops zitieren würdest. In deinem Auszug fehlt die Kopfzeile und der Rest vom call trace. Da ist die Suche vergleichsweise erfolglos. Ist das Lenny ein 32 oder 64 Bit?
ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */
-
Bowser
- Beiträge: 60
- Registriert: 17.02.2006 18:35:08
Beitrag
von Bowser » 21.04.2009 08:59:29
Ok, sorry. Also, das ganze ist auf 64 bit (Client und Host Seite). In der kern.log hab ich jetzt auch den genauen Wortlaut gefunden:
Code: Alles auswählen
Apr 20 11:58:46 hohetauern kernel: [396953.358202] BUG: soft lockup - CPU#0 stuck for 4096s! [swapper:0]
Apr 20 11:58:46 hohetauern kernel: [396953.358202] Modules linked in: binfmt_misc rfcomm l2cap bluetooth ppdev parport_pc lp parport ipv6 nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc fuse loop serio_ra
w virtio_net psmouse button pcspkr i2c_piix4 i2c_core evdev ext3 jbd mbcache ide_cd_mod cdrom ide_pci_generic virtio_blk floppy piix ide_core virtio_pci virtio_ring virtio ata_generic libata uhci_hcd scsi_mo
d dock thermal processor fan thermal_sys
Apr 20 11:58:46 hohetauern kernel: [396953.358202] CPU 0:
Apr 20 11:58:46 hohetauern kernel: [396953.358202] Modules linked in: binfmt_misc rfcomm l2cap bluetooth ppdev parport_pc lp parport ipv6 nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc fuse loop serio_ra
w virtio_net psmouse button pcspkr i2c_piix4 i2c_core evdev ext3 jbd mbcache ide_cd_mod cdrom ide_pci_generic virtio_blk floppy piix ide_core virtio_pci virtio_ring virtio ata_generic libata uhci_hcd scsi_mo
d dock thermal processor fan thermal_sys
Apr 20 11:58:46 hohetauern kernel: [396953.358202] Pid: 0, comm: swapper Not tainted 2.6.26-2-amd64 #1
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RIP: 0010:[<ffffffff8021eb68>] [<ffffffff8021eb68>] native_safe_halt+0x2/0x3
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RSP: 0018:ffffffff80573f38 EFLAGS: 00000246
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RAX: ffffffff80573fd8 RBX: 0000000000000000 RCX: 0000000000000000
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff804fae70
Apr 20 11:58:46 hohetauern kernel: [396953.358202] RBP: 000000000b18fdba R08: ffff8100010356a0 R09: ffff81026acf9830
Apr 20 11:58:46 hohetauern kernel: [396953.358202] R10: ffff810281c49928 R11: ffff81026acf9830 R12: ffffffff80573ed8
Apr 20 11:58:46 hohetauern kernel: [396953.358202] R13: 0000000000000000 R14: ffffffff8023cec0 R15: 00013752d6207d52
Apr 20 11:58:46 hohetauern kernel: [396953.358202] FS: 0000000000000000(0000) GS:ffffffff8053b000(0000) knlGS:0000000000000000
Apr 20 11:58:46 hohetauern kernel: [396953.358202] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Apr 20 11:58:46 hohetauern kernel: [396953.358202] CR2: 0000000003b117a8 CR3: 000000029a9a5000 CR4: 00000000000006e0
Apr 20 11:58:46 hohetauern kernel: [396953.358202] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 20 11:58:46 hohetauern kernel: [396953.358202] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 20 11:58:46 hohetauern kernel: [396953.358202]
Apr 20 11:58:46 hohetauern kernel: [396953.358202] Call Trace:
Apr 20 11:58:46 hohetauern kernel: [396953.358202] [<ffffffff8020b0cd>] ? default_idle+0x2a/0x49
Apr 20 11:58:46 hohetauern kernel: [396953.358202] [<ffffffff8020ac79>] ? cpu_idle+0x89/0xb3
Apr 20 11:58:46 hohetauern kernel: [396953.358202]
Und das ganze in vielfacher Ausführung mit etwas unterschiedlichen Sekunden anzahlen.
-
storm
- Beiträge: 1581
- Registriert: 01.05.2004 13:21:26
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DE
Beitrag
von storm » 21.04.2009 17:49:18
Diese "stuck for ..."-Bugs sind ja doch recht häufig, allerdings verwundern die 4096s etwas. Laut diesem
Posting sollte das in 2.6.26-4 gefixt worden sein. Besser ist wohl gleich ein update auf > 2.6.27.
ciao, storm
edit: der entsprechende Eintrag aus dem debian-bugtracker:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496917 - Neben dem kernel solltest du dir vllt. auch mal die kvm-Version und mögliche updates anschauen.
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */
-
Bowser
- Beiträge: 60
- Registriert: 17.02.2006 18:35:08
Beitrag
von Bowser » 22.04.2009 09:02:49
Hmm, weiter unten steht dann schon, dass auch der 2.6.27 den Bug hat. Irgendwie gibts anscheinend leider noch keine Konkrete Lösung, aber ich werd upgrades von KVM und Kernel mal probieren.
thx fürs erste einmal
-
Bowser
- Beiträge: 60
- Registriert: 17.02.2006 18:35:08
Beitrag
von Bowser » 13.05.2009 17:30:06
Hmm, hat irgendwie nix gebracht. Ich krieg von Zeit zu Zeit, aber seltener, immer noch "soft lockups", diesmal aber wesentlich kürzer (<400s). KVM ist jetzt aus Experimental, der Rest am neuesten Stand von Lenny. Wenns von Debian einen neueren Kernel gäbe würd ich den gern probieren, aber der 2.6.29 aus sid hat merkwürdige Probleme mit firware Geschichten.
Strangerweise passiert mir das auch nur bei der einen VM die und höherer Last steht. Die anderen die vor sich "hingammeln" funktionieren einwandfrei.
Hat jemand von euch vielleicht noch Tipps?
-
Bowser
- Beiträge: 60
- Registriert: 17.02.2006 18:35:08
Beitrag
von Bowser » 18.05.2009 16:31:15
Also Kernel selber bauen möcht ich eigentlich möglichst nicht, weil ich hier in der Firma die IT Struktur gerade auf Fordermann bring und das möglichst einfach halten möchte. Irgendwann will man das ganze ja hoffentlich übergeben und dann ist eine wenig bis garnicht gehackte Standardinstallation leichter zu handhaben als eine auf der sich eigentlich schon lang niemand mehr auskennt. Als letzte Lösung halt ich es mir aber parat, danke.
Die kvm sources waren aus experimental, ja, aber da hats inzwischen ein update auf die 85 gegeben. Sobald kvm dann auch auf der 85er für amd64 draußen is werd ich updaten und mich dann hier wieder melden.
-
Bowser
- Beiträge: 60
- Registriert: 17.02.2006 18:35:08
Beitrag
von Bowser » 23.07.2009 11:09:20
So, nur um das auch zu lösen: Das Problem tritt nicht mehr auf wenn man einen neueren Kernel beim Guest nimmt. Also einfach einen Kernel auf Experimental oder so installieren oder selber bauen oder, oder oder..., hauptsache neuer (getestet hat ichs mit 29 und 30 und beide funken.