Search results

i am able to reproduce this as well (server hangs, nothing in logs) - though it seems it does not happen with every pinged site: Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) filename: /lib/modules/2.6.32-6-pve/kernel/drivers/net/igb/igb.ko version...

similar results with X5650: vcluster1a:~# time scp -c blowfish /var/lib/vz/template/cache/centos-6.0-standard_6.0-1_amd64.tar.gz vcluster1b.int:/tmp centos-6.0-standard_6.0-1_amd64.tar.gz 100% 203MB 40.6MB/s 00:05 real...

instead of benchmarks - some practice for us really looks impressive: (1GBit NIC, L5520 Xeons) time scp -c blowfish /home/data/isos/rhel-server-6.1-x86_64-dvd.iso vcluster1b.int:/tmp rhel-server-6.1-x86_64-dvd.iso 100% 3434MB...

...you might also have a look into zenloadbalancer.com - at least for some HA tasks this imo could be a quick "plug&play" addition for Proxmox. We're currently running some Web- and MySQL services with this. You only need to install 2 Zen instances as VM on 2 Proxmox nodes, connect them to a...

phoronix-test-suite benchmark build-linux-kernel imo gives some sort of overall performance figure; at least you could compare these results with others made in another thread...

...this means that KSM is explicitly stopped because of this code: ... free=`free_memory` committed=`committed_memory` debug committed $committed free $free if [ $[committed + thres] -lt $total -a $free -gt $thres ]; then KSMCTL stop debug "$[committed +...

put into /etc/ksmtuned.conf: LOGFILE=/var/log/ksmtuned DEBUG=1 restart ksmtuned, and watch /var/log/ksmtuned - after a while it'll tell you why it stopped...

though we do not use this type of supermicro board ourselves, i'd have expected that the mpt2sas.ko *should* work in this case (at least with 2.6.32.6)...

...that's not *exactly* the "same error", since i doubt that the command is named "isnmod" on your system... ;-)

that's the RHEL5 driver, you won't get this working with a RHEL6 kernel... i'd try the RHEL6 driver... (though there's no guarantee, since proxmox is a debian-based distri running on a RHHEL6-based kernel...)

what about 'cat /etc/debian_version'? - what does "dmesg" say after trying to load module? - what does "modinfo xxxx.ko" say about the module?

<cite> Driver support in the linux front is as follows: RedHat Enterprise Linux 6.x RedHat Enterprise Linux 5.x CentOS 6.x CentOS 5.x SUSE Linux Enterprise Server (SLES) 11 </cite> ...there've even been former revisions of those drives which have been "windows only"...

i would avoid running SSDs within a RAID configuration (with a RAID controller) - this way the OS does not "know" that it has to deal with "TRIM", and it even could be a problem trying to do this manually. I do not know if meanwhile the 6805 itself does "know" about SSD specifics, the 5805 afaik...

...if you addressed me - our crashes are independent from any VM, we even stopped all vz/kvm processes before running our "bench" on the node, just to be sure... i will have a look into HT - but i am not sure if it can be disabled on that machine by BIOS... (will try kernel option 'noht' if not)

unfortunately no difference - crash after 10-20 secs... we additionally did a BIOS reset on that machine, and also 8 hours stress tests with other software, including memtest - no issues, so we're pretty sure it's not a hardware issue (and it works without a single issue using 2.6.32-5)...

burn a new CD, use another burner, use slower burn speed...

we also did not experience those kernel crashes immediately after update - it turned out that kernel crashes when system is heavily loaded. Meanwhile we're testing using "phoronix-test-suite benchmark build-linux-kernel" - 2.6.32-6 _always_ crashes few seconds after start, 2.6.32-5 successfully...

hm, you're running 2.6.32-47 - which is not "2 months old" - so i guess you probably did change the kernel at some point... Just because we have a very similar situation - you could try to boot into 2.6.32-4 (or -5 if you'd install that before); this eliminates kernel crashes on our testing...

ok, wasn't aware of that - i referred to RHEL6 (which runs 1.2.7/1.2.20 for e1000e)... though it's imo still interesting to know whether physical NIC is affected...

...are you sure that the *physical* NIC (which that 'failing' vmbr is pointing to) still is operable when your VM's NIC failed? It's just because we had some troubles with RHEL6-kernel, which Proxmox is based on with current release. In case your physical NIC is also affected, it may be worth...