New 2.6.32 Kernel with stable OpenVZ (pvetest)
- Thread starter martin
- Start date
Greetings to all. I have now something to report.
1. After upgrading my HP 380DL G5 Server to the new kernel 2.6.32-43, I can see the next issue in my syslog and on the console:
I have a network adapter based on 82571EB chip installed (e1000e):
I have found something similiar here. As this is my test machine, I could not encounter any negative consequences of such behaviour. But I'm afraid to migrate real production load onto this box to avoid troubles.
2. I have noticed that bridged interfaces vmbr+ now go up much slower than before. So, my samba shares mentioned in /etc/fstab, cannot be mounted automatically during boot process. Before 2.6.32-6-pve I has not met such a trouble.
3. I don't know if this is a bug. But Debian's udev 164-3 is now incompatible with kernel or lvm. Boot process terminates abnormally during initramfs initialization stage, attempting to find and mount LVM volumes. At the same time udev 125-7 works well. I try to perform further tests now.
1. After upgrading my HP 380DL G5 Server to the new kernel 2.6.32-43, I can see the next issue in my syslog and on the console:
Code:
Sep 25 20:34:13 bond kernel: e1000e 0000:10:00.1: eth4: Detected Hardware Unit Hang:
Sep 25 20:34:13 bond kernel: TDH <18>
Sep 25 20:34:13 bond kernel: TDT <19>
Sep 25 20:34:13 bond kernel: next_to_use <19>
Sep 25 20:34:13 bond kernel: next_to_clean <18>
Sep 25 20:34:13 bond kernel: buffer_info[next_to_clean]:
Sep 25 20:34:13 bond kernel: time_stamp <10ac83994>
Sep 25 20:34:13 bond kernel: next_to_watch <18>
Sep 25 20:34:13 bond kernel: jiffies <10ac83e00>
Sep 25 20:34:13 bond kernel: next_to_watch.status <0>
Sep 25 20:34:13 bond kernel: MAC Status <80387>
Sep 25 20:34:13 bond kernel: PHY Status <792d>
Sep 25 20:34:13 bond kernel: PHY 1000BASE-T Status <3800>
Sep 25 20:34:13 bond kernel: PHY Extended Status <3000>
Sep 25 20:34:13 bond kernel: PCI Status <10>I have a network adapter based on 82571EB chip installed (e1000e):
Code:
bond:/var/log# lspci | grep Ethernet
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
10:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
10:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
11:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
11:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
Code:
bond:/var/log# modinfo e1000e
filename: /lib/modules/2.6.32-6-pve/kernel/drivers/net/e1000e/e1000e.ko
version: 1.5.1-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: 2EE586A2A1672B0452748CD
Code:
bond:/var/log# pveversion -v
pve-manager: 1.9-24 (pve-manager/1.9/6542)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.9-43
pve-kernel-2.6.32-6-pve: 2.6.32-43
qemu-server: 1.1-32
pve-firmware: 1.0-13
libpve-storage-perl: 1.0-19
vncterm: 0.9-2
vzctl: 3.0.28-1pve5
vzdump: 1.2.6-1
vzprocps: 2.0.11-2
vzquota: 3.0.12-3
pve-qemu-kvm: 0.15.0-1
ksm-control-daemon: 1.0-6I have found something similiar here. As this is my test machine, I could not encounter any negative consequences of such behaviour. But I'm afraid to migrate real production load onto this box to avoid troubles.
2. I have noticed that bridged interfaces vmbr+ now go up much slower than before. So, my samba shares mentioned in /etc/fstab, cannot be mounted automatically during boot process. Before 2.6.32-6-pve I has not met such a trouble.
3. I don't know if this is a bug. But Debian's udev 164-3 is now incompatible with kernel or lvm. Boot process terminates abnormally during initramfs initialization stage, attempting to find and mount LVM volumes. At the same time udev 125-7 works well. I try to perform further tests now.
pls try the latest kernel from pvetest (pve-kernel-2.6.32-6-pve: 2.6.32-47), includes the latest e1000e from http://sourceforge.net/projects/e1000/files/e1000e stable/
Code:
modinfo e1000e
filename: /lib/modules/2.6.32-6-pve/kernel/drivers/net/e1000e/e1000e.ko
version: 1.6.2-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: E4B90BE4DC230817DCFB165OK, I have tried it. The same effect exists, nothing changed.
Code:
bond:~# modinfo e1000e
filename: /lib/modules/2.6.32-6-pve/kernel/drivers/net/e1000e/e1000e.ko
version: 1.6.2-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: E4B90BE4DC230817DCFB165
Code:
bond:~# pveversion -v
pve-manager: 1.9-24 (pve-manager/1.9/6542)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.9-47
pve-kernel-2.6.32-6-pve: 2.6.32-47
qemu-server: 1.1-32
pve-firmware: 1.0-14
libpve-storage-perl: 1.0-19
vncterm: 0.9-2
vzctl: 3.0.29-2pve1
vzdump: 1.2.6-1
vzprocps: 2.0.11-2
vzquota: 3.0.12-3
pve-qemu-kvm: 0.15.0-1
ksm-control-daemon: 1.0-6Some more things to report.
1. I have discovered, that magic spell "pcie_aspm=off" resolves my trouble with "Detected Hardware Unit Hang" on e1000e NIC (pve-kernel-2.6.32-6-pve: 2.6.32-47). I advise to add this unit into FAQ to avoid similiar issues in the future. But the only thing I cant understand is why everything worked well in older debian-built kernels.
2. The issue with too slow bridge initialization and CIFS I have resolved in a way like this:
I do know, that it is not the best approach. And I would like to find a more robust solution.
3. The issue with udev seems to be my own mistake. Occasionally I have removed "/lib/udev/rules.d/55-dm.rules" and forgotten about this.
1. I have discovered, that magic spell "pcie_aspm=off" resolves my trouble with "Detected Hardware Unit Hang" on e1000e NIC (pve-kernel-2.6.32-6-pve: 2.6.32-47). I advise to add this unit into FAQ to avoid similiar issues in the future. But the only thing I cant understand is why everything worked well in older debian-built kernels.
2. The issue with too slow bridge initialization and CIFS I have resolved in a way like this:
Code:
#!/bin/sh
BRNAME="vmbr0"
sleep 30
# Let's bring up shares from fstab if not yet mounted
for share in $(/usr/bin/awk '$1 ~ /^\t*\/\// {print $2}' /etc/fstab)
do
grep "$share" /proc/mounts > /dev/null || /bin/mount "$share"
done
exit 0I do know, that it is not the best approach. And I would like to find a more robust solution.
3. The issue with udev seems to be my own mistake. Occasionally I have removed "/lib/udev/rules.d/55-dm.rules" and forgotten about this.
Another strange thing, that I have noticed in the new ".47" kernel.
And, at she same time on the same system, just after boot:
Can someone explain this?
Code:
~# dmesg | grep pcie
Command line: BOOT_IMAGE=/vmlinuz-2.6.32-6-pve root=UUID=020c4296-7c73-488c-b88c-7eb8d7f115d8 ro elevator=noop pcie_aspm=off
Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-6-pve root=UUID=020c4296-7c73-488c-b88c-7eb8d7f115d8 ro elevator=noop pcie_aspm=offAnd, at she same time on the same system, just after boot:
Code:
~# cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersaveCan someone explain this?
Dietmar, please see the first quote. I have copypasted dmesg output "as is". No grub configuration changes performed.