Archive for the ‘hardware’ Category

Installing ESXi 4.1 on an AMD Brazos platform

Saturday, April 23rd, 2011

One of my projects this easter was to give my home server an overhaul. The harddrives was running very low on kapacity and the Ubuntu server installation was beginning to be a nightmare to maintain. I choose to upgrade the hardware as well and then thrown in ESXi into the equation as well.

The hardware

The hardware centers around an  ASUS E35M1-M mainboard with an AMD Zarcate APU and a AMD Hudson M1 FCH. The APU has two cores, a TDP of mere 18W and has the AMD-V extensions.

I bought 2 x 4GB of memory for the setup, which is maximum for the board.  Lastly I bought a couple of Samsung F4EG HD204ui drives (low power, low cost, high capacity, resonable performance)

Planning it

Planning the installation revealed that

  • ESXi 4.1 does not support the board; the onboard NIC is not supported.
  • The Samsung drives has a serious firmware bug.
  • The E35M1-1 doesn’t have raid functionality, if you care about (some of) your data.
  • The E35M1-1 board has an EATX 24pin power connector and my oldish antec cabinet/psu only has an ATX 20pin.

All items can either be fixed or worked around, not to worry.

Getting the hardware running.

I put the hardware together in my oldish Antec cabinet. I then used a standard $10 multimeter to verify that the 4 extra pins on the EATX connector on the mainboard (compared to a normal 20 pin ATX connector),  was in fact hardwired/bridged to other pins on the mainboard. This bascially means, that a 20 pin ATX PSU will suffice for this board.

Hardware assembled. Using an normal ATX 20 pins PSU

After that, I obtained the firmware fix for the Samsung drives. It turned out, that I did not need it as drives manufactured later than December 2010 already contains the fix according to this post.

Installing ESXi 4.1 on the E35M1-M

You can download ESXi 4.1 for free. I did that. I burned the .iso file and booted from the CD. It booted the hypervisor, but complained/failed when I pressed F11 for installation. As guessed, it is due to the fact that the NIC, an RealTek 8111E is not supported.

The fix is to include the realtek 8111E driver in the iso file, in two places: One place, used to include support in the installer. An one inside the ddimage, that the installer deploys onto the hardware. It is fairly simple if you know your way around linux. Instructions on how to build ESXi modules is on the net. For the lazy, you can pretty much get it served to you: an oem.tgz (local copy here) and a script called mkesxiaio (local copy here) that combines the oem.tgz and the ESXi installation iso.

Download iso and oem.tgz and script. Run script and burn resulting iso file. Boot that iso and install ESXi 4.1 onto the system. For me it worked flawlessly.

Booting the ESXi 4.1 hypervisor on the ASUS E35M1-M mainboard

The Software side

After that I installed the ESX license key, provisioned an vm, installed debian 6.0 and migrated all my files to the new server.

In the past I used to have a raid setup. The Hudson H1 FCH does not have raid support and neither does ESXi, except on selected raid controllers. Now what?

The trick is to do it in software on the VM side. You provision two VM disks, one from each datastore, and combine them into a mirror/raid device inside the vm. You basically have two options:

  1. md driver
  2. lvm mirror

If you care about performance and the integrity of your data, you should go for the md driver as it respects write barriers.  for my setup I thus ended up with 5 vmdisks

  • One for the OS
  • two combined into an md device for the crucial stuff and that in turn was used in a vg called vgsafe
  • two spanned across that datastores for the the non crucial stuff.  Those disks were just added to a vg called vgspan
edison% mount | egrep -i ‘(mapper|boot)’
/dev/mapper/edison-root on / type ext3 (rw,errors=remount-ro)
/dev/sda1 on /boot type ext2 (rw)
/dev/mapper/edison-tmp on /tmp type ext3 (rw)
/dev/mapper/edison-usr on /usr type ext3 (rw)
/dev/mapper/edison-var on /var type ext3 (rw)
/dev/mapper/vgsafe-lvhome on /home type ext4 (rw)
/dev/mapper/vgspan-software on /home/software type ext4 (rw)
/dev/mapper/vgspan-media on /home/media type xfs (rw)

Utilizing Seagate 7200.12 drives in an MSA20

Wednesday, February 2nd, 2011

About a year ago, I upgraded an MSA20 with non-HP drives. 1TB drives (7200.11 series) made by Seagate to be precise. Here one year later, the first drives start to fail. Looking for replacements we had a hard time finding the 7200.11 series drives. We then bought some 1TB 7200.12 drives.

And they work just fine……

Same model number, just different firmware as seen from the MSA20 (CC46 vs CC38):

physicaldrive 1:7
Box: 1
Bay: 7
Status: OK
Drive Type: Data Drive
Interface Type: SATA
Size: 1000.2 GB
Firmware Revision: CC46
Serial Number:             9VPB04V3
Model: Seagate ST31000528AS
SATA NCQ Capable: False

physicaldrive 1:8
Box: 1
Bay: 8
Status: OK
Drive Type: Data Drive
Interface Type: SATA
Size: 1000.2 GB
Firmware Revision: CC38
Serial Number:             9VP4D1F1
Model: Seagate ST31000528AS
SATA NCQ Capable: False

Configuring and using the BMC on an IBM eServer 326.

Sunday, October 3rd, 2010

The IBM eServer 326 comes with a fairly minimalistic Baseboard Management Controller (BMC). That is understandable when you look at the form factor (1U) of the eServer 326 as well as the pricetag it had when it was introduced. IBM tried to give the eServer 326 some RAS features without impacting the price. Kudos for that!

It does also however, mean that it is hard to use and configure. A couple of points

  • The BMC piggybacks/shares the first NIC with the system (LAN 1)
  • You have to start the server once before the BMC gets activated. It is not truely a seperate entity of its own
  • When you enter the system BIOS you see a BMC menu option. Clicking that however will not allow you to configure the LAN settings of the BMC, hence this blog post.
  • At times the BMC is unreachable due to the fact that the NIC is a shared NIC.

When you boot the disk/iso, it will normally go through an upgrade cycle before you end up in the lancfg tool. If you only want to configure the BMC, you can break the upgrade during startup (ctrl-c) and start lancfg yourself.

content of the lancfg disk

Inside lancfg you can configure the ip settings of th BMC ….

lancfg – ip settings

… as well as the SNMP settings

snmp settings of the BMC

You can also setup privileges to be used when accessing the BMC. The default BMC username and password for the IBM eServer 326 is USERID/PASSW0RD (with a zero)

After you have installed the tool, you can use it under linux as follows:

edison% ./usr/bin/smbridge -ip 192.168.1.223 sysinfo
DeviceID=       0
DeviceRevision= 1
FirmwareVersion=        1.25
IpmiVersion=    1.5
ManufacturerID= 2
ProductID=      34888
Status= OK
SDRVersion=     1.5
Guid=   171c049f-4ea8-b387-119d-321e09d85fe8

or

edison% ./usr/bin/smbridge -ip 192.168.1.223 power
Status= on

edison% ./usr/bin/smbridge -ip 192.168.1.223 power reset
Error(power,0xa3):Insufficient privilege level.
edison% ./usr/bin/smbridge -ip 192.168.1.223 -u USERID -p PASSW0RD power reset

edison% ./usr/bin/smbridge -ip 192.168.1.223 -u USERID -p PASSW0RD power off

edison% ./usr/bin/smbridge -ip 192.168.1.223 -u USERID -p PASSW0RD power on

edison% ./usr/bin/smbridge -ip 192.168.1.223 -u USERID -p PASSW0RD power cycle

And that is about it. Not enterprise RAS features, but enough to reset a hung machine and stuff like that. Given that the eServer 326 was marketed as a cheap calculation node in a calculation farm, the BMC features fits the bill perfectly, even though it would have been nice with some remote console features as well….

How to use a broken IBM Thinkpad T43 for something useful using puppy linux.

Wednesday, July 21st, 2010

I recently got my hands on a IBM Thinkpad T43. Unfortunately it was broken. More specifically the connector between the mainboard and the harddrive had problems.

IBM T43 connector (broken)

I googled a bit and discovered, that this was a known problem. The laptop worked fine, if I put pressure on the right spot on the case of the Thinkpad. Otherwise it would not detect and/or spin up the harddrive. I tried to fix it by re-soldering the connector and using some two-component glue to fixate the connector. I did not succeed :-/

So then what? Throw out the laptop? Or? … I decided to make a project out of it.

A laptop without storage is useless. Due to the broken connector, I could not use a harddrive. I did not want to use a cdrom as it is a slow medium. That left me with a USB flash drive as the only option. It would be a clumsy solution just to plug a USB flash drive into the laptop and be done with it, so I chose to solder a USB flash directly onto the mainboard.

First I stripped a standard 1GB USB Flash from its case and detached the PCB from the USB connector using a soldering iron

Stripped USB flash

After that I soldered 5 wires onto the PCB of the laptop and used one of the holes in the PCB used for assembly as a pass through hole. I initially used 4 wires as the USB connector only had 4 pins, but that was not enough. More on that later.

Wires soldered onto mainboard

Having soldered the wires onto to the mainboard, I now needed to solder the other ends onto to the PCB of the USB flash. That went fairly smoothly

Wires soldered onto flash

Before powering on anything, I used a multimeter to check for bad solderjoins and shorts. I found neither.

Checking for shorts using digital multimeter

Luckily I had a Linux based rescue distribution installed on the USB flash drive, so I just booted that to see if the operation on the T43 was a success. As can be seen below it worked just fine. Well, sort of fine, but more on that in a moment.

Testbooting the flashdrive

Almost done now. I just needed to assemble the laptop again, leaving the USB Flash inside.

Ready to wrap up

Closing the lid on the laptop, securing all the screws I had myself a working IBM Thinkpad T43. Or so I thought. When I tested the laptop thoroughly I discovered that the kernel ring buffer was filled with

hub 2-0:1.0: over-current change on port 1
hub 2-0:1.0: over-current change on port 2

That cryptic message just states that the USB device is drawing more power than it is allowed to by the USB specification. Or more precisely that the port on the USB hub inside the laptop is delivering more power than it was supposed to. It first that puzzled me. Then I read about the USB connector and realized my fail. The 4 wires of the USB connector consists of  VCC, GND, Data+ and Data –. Given both VCC and GND was part of the 4 pins I only soldered 4 pins. After seeing the problems above, I investigated the matter and found a reference to OverCurrent (OC) protection on the header itself. I thus soldered the 5th pin and the problem went away.

I now had a working IBM Thinkpad T43 with 1GB of flash storage. What should I use it for? I decided to use it for puppy linux. Primarily for two reasons.

  1. It appeared to be tailor made for small harddrives
  2. I had never tried it before

I downloaded the 106MB large iso file and burned it onto a CDrom. Now I faced the problem of installing puppy linux onto my flash without using a cdrom drive (as I found the laptop without one). Puppy linux made it quite easy. Using another computer I booted the cdrom. Installed puppy onto a spare flash drive. Booted that flash drive in my IBM Thinkpad T43 and pressed “install” once more, installing it onto the “internal” flash drive.

Booted into puppy linux

All done. Actually it takes quite some time to boot the machine, but that is primarily due to the bios insisting on searching for a harddrive. Unfortunately the IBM BIOS lacks the option to stop it from doing that. After the system is loaded however, it is lightning fast. Way faster than my IBM Thinkpad T400. This is due to the fact that puppy linux loads everything into a ramdisk, so starting program does not require any moving parts to be ready. Programs starts instantaneously. The whole experience just proves (once more), that the computers of today is severely I/O limited, but hopefully SSD will change that real soon now(tm)

Updating system firmware on an IBM Thinkpad T43 using pxeboot

Friday, April 30th, 2010

Recently I got my hands on an IBM Thinkpad T43 without disk drive and cdrom (perfectly OK machine thrown out, apparently for no reason). I decided to update the firmware to the newest version before considering buying replacement parts for it.

So how do you update the firmware on an IBM Thinkpad without floppy or cdrom? You netboot it ofcourse. Needless to say these instructions might also work for other models. And finally: If you break your Thinkpad following these instructions I have no liability and you get to thank yourself and keep both parts!

With the standard disclaimer out of the way, lets start.

First I went to the excelent site thinkwiki.org where I located the latest bios. I then downloaded bios version 1.29 from Lenovo (Notice that two versions of the T43 exists and they are incompatible!)

I turned my attention to my linux server (ubuntu) and configured the dhcpd, tftpd and inetd to allow me to netboot using pxe. First off I installed the four needed utilities.

sudo apt-get install openbsd-inetd tftpd-hpa  dhcp3-server cabextract

When PXE booting a computer, it broadcasts for a lease from a DHCP server on the net. I configured my dhcpd server with the following besides the normal dhcpd options.

sudo vi /etc/dhcp3/dhcpd.conf
...
...
       host t43 {
                hardware ethernet 00:11:25:d6:ef:4b;
                fixed-address 192.168.1.35;
                filename "pxelinux.0";
      }
...
...

You ofcourse have to change the hardware ethernet to the mac address of your Thinkpads ethernetcard. I saved the file and restarted dhcpd with

/etc/init.d/dhcp3-server restart

Next I configured inetd:

vi /etc/inetd.conf
tftp  dgram  udp  wait  root  /usr/sbin/in.tftpd -v -v -v -s /usr/lib/syslinux

Saved and restarted inetd

sudo /etc/init.d/openbsd-inetd

I then configured pxe with a config file that pxelinux.0 expects (your mac address will vary ofcourse) .

mkdir -p /usr/lib/syslinux/pxelinux.cfg
vi /usr/lib/syslinux/pxelinux.cfg/01-00-11-25-d6-ef-4b
DEFAULT t43firmware
LABEL t43firmware
        kernel memdisk
        append vga=normal initrd=flash/t43/70UJ29US.IMG --
PROMPT 1
TIMEOUT 0

Almost there. Next up, get the flash image ready

mkdir -p /usr/lib/syslinux/flash/t43
cd /usr/lib/syslinux/pxelinux.cfg
wget http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/70uj29us.exe

That got you an windows cabinetfile. Extract the firmware from that

cabextract -F 70UJ29US.IMG 70uj29us.exe
Extracting cabinet: 70uj29us.exe
  extracting 70UJ29US.IMG
All done, no errors.

I then powered up the T43. It booted over PXE

I pressed return and the flash program started:

I accepted the (many) warnings and disclaimers….. and

…. nothing happened! It just hung. I thought I had fried my newly aquired Thinkpad. I powered it off and on again just to see that it still worked, and that I was on the same BIOS level. Hmm, now what? It nearly worked, but still no cigar. I decided to take it one level further, doing it all by hand:

Mount the image file by hand using the loop driver:

sudo mkdir /floppy
sudo mkdir /floppy1
sudo mount -o loop /usr/lib/syslinux/flash/t43/70UJ29US.IMG /floppy

Get a standalone freedos boot image (called balder) from the nice guys at freedos.org:

cd /usr/lib/syslinux/flash/t43/
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/\\
     unofficial/balder/balder10.img
sudo mount -o loop /usr/lib/syslinux/flash/t43/balder10.img /floppy1

Remove a lot of files from balder10.img and copy files over from the IBM flash disk.

sudo rm /floppy1/{display.exe,edit.exe,dosfsck.exe,zip.exe,unzip.exe,\\
                  defrag.exe,fdisk.exe,chkdsk.exe,cwsdpmi.exe,keyboard.sys,\\
                  format.exe,subst.exe,edit.hlp,country.sys,keybrd2.sys,\\
                  diskcopy.exe,edlin.exe,replace.exe,fdiskpt.ini,debug.com,\\
                  mode.com,shrdrv86.exe,xcopy.exe,move.exe,keyb.exe,tree.com,\\
                  fdisk.ini,diskcomp.com,ctmouse.exe,more.exe,shsucdx.com}
sudo cp /floppy/{\$0199000.fl1,06d*,chkbmp.exe,flash2.exe,lcreflsh.bat,logo.bat,\\
                 logo.scr,phlash16.exe,prepare.exe,prod.da*,qkflash.exe,\\
                 readme.txt,tpchks.exe,updtflsh.exe,updtmn.exe,userint.exe,\\
                 utilinfo.exe} /floppy1

# rename the flash file
sudo mv \$0199000.fl1 flash.img

# unmount floppy
sudo umount /floppy1/

Edit the pxe config file (your mac address will vary ofcourse) to use the balder/freedos image file instead of the Lenovo flash disk.

vi /usr/lib/syslinux/pxelinux.cfg/01-00-11-25-d6-ef-4b
DEFAULT t43firmware
LABEL t43firmware
        kernel memdisk
        append vga=normal initrd=flash/t43/balder10.img --
PROMPT 1
TIMEOUT 0

Reboot the T43 machine. Boot over PXE, single step (F8) the freedos start. Make sure you do NOT use EMS or HIMEM. After a brief period of time you should find yourself in an dos prompt, where you run

A:\phlash16.exe flash.img

The system should flash nicely and you should be all done within a minute:

Not for the faint of hearted, but I never promised that ;-)

Firewall in an ZynOS based xDSL router (ie. zyxel P660R-D1)

Tuesday, April 13th, 2010

I recently got xDSL from one of the major danish ISPs. I was very satisfied until I discovered that port 80 was closed. I looked high and low for a solution. Eventually I gave up and contacted the support, which confirmed my suspicion: the router had an firewall which blocked port 80.

The solution is actually quite straight forward:

wan node index 1
wan node filter incoming tcpip 256 256 256 256
wan node filter outgoing tcpip 256 256 256 256
wan node save

And now my blog is accessible for the outside world again.

Non-HP harddrives in an HP MSA20

Thursday, March 11th, 2010

A customer asked me if it was possible to use non-hp drives in an HP MSA20 as they costed a lot less than HPs own drives. I honestly said that it would require a POF. The customer accepted the initial expense of single 1TB SATA drive.  I fired up hpacucli to figure out what was up and down on this

=> ctrl ch="mirror" show config detail
....
....
physicaldrive 1:1
Box: 1
Bay: 1
Status: OK
Drive Type: Data Drive
Interface Type: SATA
Size: 1000.2 GB
Firmware Revision: HPG1
Serial Number: 9QJ2B4GD
Model: HP GB1000EAFJL
SATA NCQ Capable: False

As HP does not make harddrives, but uses OEM drives with custom firmware I had to figure out what types of drives was in there. The easiest solution would be to shut the box down and pull out a drive to inspect. Having dealt with HP quite a lot, I know that they also remark the drives, so I would probably not be able to see what types of drives was in there, leaving me with guessing if I choose to go that route.

Instead I opted for figuring out what type of drive it was likely to be based on the firmware.  I googled a bit and found that the MSA20 could support up to 1TB disks. A bit more googling yielded this advisory from HP about upgrading firmware on Seagate drives to HPG6. Based on the age of the MSA20 in question, the age of the 1TB HP disks we already had in them, I decided it was most likely to be Baracuda 7200.11 drives that HP utilized for this and thus we ordered one of those.
Drive arrived. We put it in. Rescanned and lo and behold:

physicaldrive 1:6
Box: 1
Bay: 6
Status: OK
Drive Type: Data Drive
Interface Type: SATA
Size: 1000.2 GB
Firmware Revision: CC38
Serial Number:             9VP4D0ZA
Model: Seagate ST31000528AS
SATA NCQ Capable: False

A non-HP drive working. We have now placed an order for 19 x 1TB Seagate drives.

Your millage may wary if you try this. It is also worth mentioning that it would be an option to test non-seagate disks and/or bigger disks. Beware of the heat and power requirements though! HP themselves only sells the MSA20 with upto 1TB disks.

Finally for the record, it should be state that this was on an MSA20 with this firmware level:

MSA20 in mirror
 Bus Interface: SCSI
 Serial Number: PAAAC0PMQTR7V0
 Chassis Serial Number: E01RMLJ17M
 Chassis Name: mirror
 RAID 6 (ADG) Status: Enabled
 Controller Status: OK
 Chassis Slot: 2
 Hardware Revision: Rev A
 Firmware Version: 2.08
 Rebuild Priority: Medium
 Expand Priority: Medium
 Surface Scan Delay: 3 secs
 Cache Board Present: True
 Cache Status: OK
 Accelerator Ratio: 50% Read / 50% Write
 Drive Write Cache: Disabled
 Read Cache Size: 56 MB
 Write Cache Size: 56 MB
 Total Cache Size: 112 MB
 Chassis Slot 2 Battery Info
 Battery Pack Count: 2
 Battery Status: OK
 Host Bus Adapter Slot: Slot Unknown
 Host Bus Adapter Port: 1
 SATA NCQ Supported: False

Linux (ubuntu Karmic Koala) on HP Elitebook 2530p

Saturday, October 24th, 2009

Finally got my new laptop (the old one served me well), an HP elitebook 2530p. I had my doubts on the ability to be able to get suppport for every piece of hardware in this laptop under Linux, but it was doable. Not without issues, but still fairly easy.

I opted for the latest ubuntu, Karmic Koala (9.10), which on the time of writting was release candidate. The installation went smoothly. The windows partition got resized without issues and after a few clicks on the next button the system was up and running. With encrypted ext4 filesystem and all.

Working without a hitch:

  • acpi (suspend, fan control, speedstep)
  • sound
  • graphic
  • wired network

Working with some debugging

  • Initially the wireless would not work with my wrt54g. It worked with other wifi hotspots. Symptoms were that the laptop could not a dhcplease from the router. Tried to flash the router with dd-wrt firmware instead of the tomato firmware. Did not help. Breakthrough came when I reset the router settings to “Default”. Then it worked with dd-wrt. I reflashed it with tomato and it still worked. So it is possible to enable “some setting” in the wrt54g router that cause problems with this laptop. My other laptops did not inhibit these issues. But then again. The laptop can not really be blamed.
  • My external Huawai E180 did not work. After some googling, it turned out to be a bug introduced in a specific kernel release.  The solution was to downgrade the kernel to a previous version. The only one available was 2.6.31-9-rt, which I choose and that works just fine.
  • The built-in Qualcomm Gobi 1000 3G module requires a firmware and a firmware loader to function. The firmware loader can be found here. It is just a little .c program and a set of udev rules. After that you will need the firmware. That can be obtained from your windows partition. If you do not have the driver for the windows environment it can be obtained from hp. The Gobi chipset is a fullblown arm cpu which can function as a 3G modem for various types of 3G nets. Different firmwares allows access to different networks. This piece of information gives an overiew. For my part I needed the 6. th version of the firmware as I live in Europe/Denmark.

All in all a couple of minor issues. I am really satisfied with this latop and the way Linux works on it. Will hopefully be a good laptop for me in the next couple of years.

New server again again – based upon an Intel D945gclf2 – dual core Atom 330

Sunday, May 24th, 2009

Well. More time used on my server. More downtime. More annoyance towards my wife (who have come to be dependent on the mailsetup).

My previous server simply consumed too much power. I basically just plugged it in and it ran. It is a nice little board for around 500dkk:

edison% cat /proc/cpuinfo
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 28
model name    : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping    : 2
cpu MHz        : 1595.997
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 2
apicid        : 0
initial apicid    : 0
fdiv_bug    : no
hlt_bug        : no
f00f_bug    : no
coma_bug    : no
fpu        : yes
fpu_exception    : yes
cpuid level    : 10
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips    : 3191.99
clflush size    : 64
power management:

processor    : 1
vendor_id    : GenuineIntel
cpu family    : 6
model        : 28
model name    : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping    : 2
cpu MHz        : 1595.997
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 1
cpu cores    : 2
apicid        : 2
initial apicid    : 2
fdiv_bug    : no
hlt_bug        : no
f00f_bug    : no
coma_bug    : no
fpu        : yes
fpu_exception    : yes
cpuid level    : 10
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips    : 3191.98
clflush size    : 64
power management:

processor    : 2
vendor_id    : GenuineIntel
cpu family    : 6
model        : 28
model name    : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping    : 2
cpu MHz        : 1595.997
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 2
apicid        : 1
initial apicid    : 1
fdiv_bug    : no
hlt_bug        : no
f00f_bug    : no
coma_bug    : no
fpu        : yes
fpu_exception    : yes
cpuid level    : 10
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips    : 3127.96
clflush size    : 64
power management:

processor    : 3
vendor_id    : GenuineIntel
cpu family    : 6
model        : 28
model name    : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping    : 2
cpu MHz        : 1595.997
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 1
cpu cores    : 2
apicid        : 3
initial apicid    : 3
fdiv_bug    : no
hlt_bug        : no
f00f_bug    : no
coma_bug    : no
fpu        : yes
fpu_exception    : yes
cpuid level    : 10
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips    : 3191.95
clflush size    : 64
power management

New server ….

Monday, April 13th, 2009

… well, almost. To let one of my boys use the nVidia 7900 GT graphics card I bought for them, I had to move some hardware around. My Aopen i915gmm-hfs motherboard was taken out of my server and put into Benjamins computer. Instead my server got his ASUS A8N-VM CSM motherboard. To keep power consumption of my server down, I decided to enable cool’n’quiet, use a 2.5″ diskdrive for the root partition and use powertop to minimize the number of interrupts. Tomorrow I have to get rid of the built in nvidia NIC (it generates 100 ints/sec) and use an intel pro100 or pro1000

In any case this is only temporary, until I can get an atom or arm based mainboard with 4 sata connectors without having to shell out millions of dollars on it :-)

Ohh yeah, also “upgraded” from Debian to Ubuntu. Ran into some anoyances with regards to /var/run and /var/lock combined with a seperate /var partition. Ubuntu is not really server quality yet if you can not move /var to a seperate partition without problems. Sorry, but it really is not!