dma timeout error: status=0x50

[hjdt]

Hallo Zusammen,

eine VM hat zunehmend Probleme mit der virtuellen Festplatte und sie generiert den folgenden Fehler, sie lief aber bis vor 2 Wochen völlig stabil. Alle anderen VMs laufen ohne Probleme und das Storage ist auch OK. Hat jemand eine Idee?

Sep 27 09:38:48 math hda: dma_timer_expiry: dma status == 0x21
Sep 27 09:38:48 math hda: DMA timeout error
Sep 27 09:38:48 math hda: dma timeout error: status=0x50 { DriveReady SeekComplete }
Sep 27 09:40:27 math hda: dma_timer_expiry: dma status == 0x21
Sep 27 09:40:41 math hda: DMA timeout error
Sep 27 09:40:41 math hda: dma timeout error: status=0x50 { DriveReady SeekComplete }

Gruß,
Boris

 

[dcsapak]

hi,

wie sieht denn die vm config (qm config ID), 'pveversion -v' output aus? welches os (version) läuft denn in der vm?
gibt es am host auch irgendwelche meldungen im log/dmesg ?

 

[hjdt]

wie sieht denn die vm config (qm config ID), 'pveversion -v' output aus? welches os (version) läuft denn in der vm?
gibt es am host auch irgendwelche meldungen im log/dmesg ?

Es gibt keinerlei andere Meldungen und das OS ist ein altes Debian. Die VM lässt sich noch anpingen aber kein Dienst ist mehr erreichbar.

Config:
bootdisk: ide0 cores: 2 ide0: proxmox-ha-storage:100/vm-100-disk-1.qcow2,size=122G ide2: none,media=cdrom memory: 2048 name: mail net0: e1000=AE:23:05:33:67:8C,bridge=vmbr0 ostype: l26 sockets: 1

pveversion -v:
proxmox-ve: 5.4-2 (running kernel: 4.15.18-18-pve) pve-manager: 5.4-11 (running version: 5.4-11/6df3d8d0) pve-kernel-4.15: 5.4-6 pve-kernel-4.13: 5.2-2 pve-kernel-4.15.18-18-pve: 4.15.18-44 pve-kernel-4.13.16-4-pve: 4.13.16-51 pve-kernel-4.13.13-6-pve: 4.13.13-42 corosync: 2.4.4-pve1 criu: 2.11.1-1~bpo90 glusterfs-client: 3.8.8-1 ksm-control-daemon: not correctly installed libjs-extjs: 6.0.1-2 libpve-access-control: 5.1-12 libpve-apiclient-perl: 2.0-5 libpve-common-perl: 5.0-53 libpve-guest-common-perl: 2.0-20 libpve-http-server-perl: 2.0-14 libpve-storage-perl: 5.0-44 libqb0: 1.0.3-1~bpo9 lvm2: 2.02.168-pve6 lxc-pve: 3.1.0-3 lxcfs: 3.0.3-pve1 novnc-pve: 1.0.0-3 proxmox-widget-toolkit: 1.0-28 pve-cluster: 5.0-37 pve-container: 2.0-39 pve-docs: 5.4-2 pve-edk2-firmware: 1.20190312-1 pve-firewall: 3.0-22 pve-firmware: 2.0-6 pve-ha-manager: 2.0-9 pve-i18n: 1.1-4 pve-libspice-server1: 0.14.1-2 pve-qemu-kvm: 3.0.1-4 pve-xtermjs: 3.12.0-1 qemu-server: 5.0-54 smartmontools: 6.5+svn4324-1 spiceterm: 3.0-5 vncterm: 1.5-3

 

[dcsapak]

und das OS ist ein altes Debian.

wie alt denn genau? vielleicht mal mit scsi/virtio für die disk versuchen?

vielleicht ist der storage so langsam dass der virtuelle ide controller in ein timeout läuft?

 

[hjdt]

wie alt denn genau? vielleicht mal mit scsi/virtio für die disk versuchen?

Das ist ein Debian Etch mit Kernel 2.6.18. Ich meine mich zu erinnern, dass das virtio erst mit 2.6.26 implementiert wurde. Deshalb wird das wohl nicht gehen.

vielleicht ist der storage so langsam dass der virtuelle ide controller in ein timeout läuft?

Dann würden doch alle anderen VMs dasselbe Problem haben oder nicht?
Hier die Daten vom Storage:
Timing cached reads: 26238 MB in 1.99 seconds = 13165.28 MB/sec
Timing buffered disk reads: 556 MB in 3.01 seconds = 184.95 MB/sec

 

[dcsapak]

Das ist ein Debian Etch mit Kernel 2.6.18. Ich meine mich zu erinnern, dass das virtio erst mit 2.6.26 implementiert wurde. Deshalb wird das wohl nicht gehen.

scsi womöglich aber mit einem nicht virtio scsi controller

Dann würden doch alle anderen VMs dasselbe Problem haben oder nicht?
Hier die Daten vom Storage:
Timing cached reads: 26238 MB in 1.99 seconds = 13165.28 MB/sec
Timing buffered disk reads: 556 MB in 3.01 seconds = 184.95 MB/sec

ja dann ists eher unwahrscheinlicht das es daran liegt