Yep, the day has finally arrived. The disturbed concert is tonight. Starts at 8 pm. I believe that I will be as deaf as a door knob tomorrow. Which probably not a bad thing. Means you can’t hear the people at work, hehe. I’ll try get some pictures and report back tomorrow. See ya.
Archive for August, 2008
I’ve got a ASUS P5KPL-CM motherboard I’ve installed into a new server at work that will perform tape backups.
I wanted to install lm_sensors to monitor the temperature of the CPU and System.
I installed the standard Centos 5.2 release of lm_sensors, which at the time of writing was, version 2.10.0-3.1. I found however that due to the “newness” of the board, this version of lm_sensors was too old.
I removed the Centos lm_sensors package and wandered over to the lm_sensors site. I downloaded lm_sensors 3.0.2, here’s the link. http://dl.lm-sensors.org/lm-sensors/releases/lm_sensors-3.0.2.tar.bz2
Happily it compiled and installed fine using the standard install instructions, extract, make, make install. I ran sensors-detect and everything seemed to run ok.
The sensors-detect summary looked like this:
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `w83627ehf’ (should be inserted):
Detects correctly:
* ISA bus, address 0×290
Chip `Winbond W83627DHG Super IO Sensors’ (confidence: 9)
Driver `coretemp’ (should be inserted):
Detects correctly:
* Chip `Intel Core family thermal sensor’ (confidence: 9)
However on running sensors it came back with:
Starting lm_sensors: No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
But… BUT, you said you where happy!
I went looking through the /lib/modules to try and find what it was loading, specifically the w83627ehf module. The specific directory is /lib/modules/<kernel version>/kernel/drivers/hwmon. On running insmod w83627ehf, it returns:
insmod: error inserting ‘w83627ehf.ko’: -1 No such device
After looking through lots of sites, I found this on the lm-sensors mailing-list:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018519.html
Basically, seems Winbond released a revised version of the chip, so even thought the Centos 5.2 w83627ehf.ko module has the right name, the guts of the kernel module don’t support the new revised w83627ehf chip. I’m running 2.6.18-92.1.10.el5 (latest Centos 5 kernel at the moment). Turns out 2.6.21 has the updated w83627ehf kernel module that fixes this problem.
So I went to kernel.org and download the 2.6.21 source. Opened it up and copied out the w83627ehf.c file. You also need the lm75.h header file. I compiled the module and it inserted cleanly into 2.6.18-92.1.10. Ran sensors and bang it worked ![]()
Hows that for kernel hacking…
If you just want the compiled kernel module that works on 2.6.18-92.1.10 X86_64, download this archive: http://www.nodeofcrash.com/download/w83627ehf-centos5.tar.gz
There is also a kit tarball you can use to compile your own module for other Kernels.
Download this archive: http://www.nodeofcrash.com/download/w83627ehf-centos5-kit.tar.gz
I hope this saves someone a headache
I had a situation today where one of the engineers needed me to recover some files he had deleted by accident.
I have a one day old rsync backup on a hard disk as part of the backup system. However turns out the file was removed a week ago… yikes.
Got the tapes out and fired up amanda recover (amrecover).
On running amrecover and issuing the “extract” command, amrecover failed with “unable to open socket : Success”.
I ran amcleanup and then the amrecover again and everything came right. Extracted the files and got a free coffee from the engineer involved
It’s good to know I have Amanda looking after me
Roughly two weeks ago I upgraded my home pc kit.
Bought myself a Core 2 Duo 3.16Ghz, 4 Gb Ram and a Gigabyte P45-DSP3 motherboard.
I was quite surprised to find that after changing from AMD to Intel architecture, Vista actually booted up.
Ubuntu 8.04 Hardy Heron on the other had became completely Foobar. I found that with the newer Intel chipsets you need to run the hard drive controllers in AHCI mode. Just a setting change in the Bios.
However changing to AHCI mode from normal mode messes up Vista.
So I decided it was time to re-install. My Vista was needing a clean anyway. Install went fine and I got everything up and running. Took an image (with Paragon Drive Backup) of the clean installed Vista. It should save time with the next re-install.
With Vista up and running, I got the Ubuntu disk out. Everything looked ok, but after completing the install and rebooting, things got strange. Booting would get as far as the grub screen and on selecting the kernel, complain about being unable to mount the boot partition. I tried reinstalling Ubuntu again, but same problem. Next I got my trusty Knoppix disk out. Booted that up and preformed a re-install of grub. Everything looked ok, but on a reboot, same issue with being unable to mount /boot.
Fiddled with the grub boot parameters but still no joy.
Frustrated, I thought I would try another Distro to see if it had the same issue. I got my Fedora 8 disk out, but decided it might be a bit old for the motherboard and CPU I was using, so I booted the Fedora 9 installer. Unfortunately the Gui installer locks up after selecting the language. Switching between the terminals in anaconda (Alt+F1, Alt+F2 etc) revealed nothing useful.
I’m guessing it’s my graphics card causing the issue. I’ve got a Nvidia 9600GT.
I could have tried the text installer, but I left Fedora 9 alone.
Next tried Fedora 8. After fiddling with the installer kernel options, I got it going,
However it locks up at the same place as Fedora 9 oddly enough.
Lastly out of desperation, I got the OpenSuse 10.1 disk out. Suse came though as the mighty Yast sorted out all my issues.
Booted up Suse, but encountered a problem with the dual Gigabit network cards on the motherboard. They were being detected, however I couldn’t get DHCP to work and static IP addresses didn’t help either. I couldn’t ping anything on my network.
At this point I had to go to sleep so I left my Linux troubles for the time being. A couple of days later I decided my network troubles must be Suse related, so I had another go at getting Ubuntu back up.
After re-installing Ubuntu, I cracked the Grub problem. It appears that what the Bios is reporting as the boot order of the drives it not the same as what Grub is picking up. Changing the root (hd2,0) to root (hd0,0) brought my Ubuntu up.
However Ubuntu seems to suffer from the same network card trouble as Suse ![]()
I guess there is going to be some more work needed to get this sorted….
I Purchased the ASUS P5B-VM SE motherboard, Intel Quad Core processor (2.4Ghz), 4GB of DDR800 RAM and 2 x WD 250GB Sata hard drives. I’m install Centos 5.1 X86_64 on it.
Here are the list of issues I had with this board and how I fixed them.
1.) Can’t read the Centos install DVD or CD.
2.) Strange mmconf and acpi problems at boot. (Before Redhat Nash appears)
3.) Onboard ethernet not detected by Centos 5.1.
4.) Sata hard drives detected as IDE. Drives added under /dev as hda, hdb etc. Should be sda, sdb.
5.) Ultra DMA isn’t working, so the drives transfer speed is awful.
6.) Bios and OS picking up only 3GB of RAM.
1.) Every installer disk I put in (DVD, CD, Centos, Fedora etc) would fail at the ISOLinux screen. Tried three different DVD-ROMS and the problem still occured.
Updating the bios to the latest version resolved this issue.
2.) To get rid of this I added “pci=nommconf” (without quotation marks). Some of the older Centos 5.1 kernels need you to pass “acpi=off” in order to boot. I recommend installing with “acpi=off”, upgrading to a later kernel, then removing “acpi=off” from grub.
3.) The board has a Attansic Technology Corp. L1 Gigabit Ethernet Adapter network chip. This doesn’t seem to be supported natively. Drivers are available on ftp://hogchain.net/pub/linux/attansic/vendor_driver/l1-linux-v1.2.40.2.tar.gz
Follow the instructions, and it’s easy to install.
Remember to yum install kernel-devel. You need the kernel source to compile the driver.
4 and 5.) I found the SATA drives were being detected as IDE drives in Centos. Instead of them coming up as sda, sdb, they were hda and hdb. Using hdparam -tT /dev/hda to do a transfer test showed the drive operating at 4MB/s…. which is very slow. They should be operating at near to 60Mb/s.
hdparam /dev/hda showed that DMA was disabled. Regardless of what I did, I couldn’t enable DMA on the drives.
Option 1: Enable AHCI in the Bios. Centos will then use the AHCI driver and everything detects correctly.
Option 2: Adding the following to the kernel boot parameter, either at the grub boot screen (press a key, goto the current kernel, go down to the entry with the word “kernel” in it and add the next part too the end) or in the /etc/grub.conf
ide0=noprobe ide1=noprobe
The generic libata driver (used for the JMicron JBxxx pata chip) is taking over the SATA drives on the Intel ICH8 Sata controller.
The noprobe statement basically disables the generic libata driver. You end up with the proper Intel Sata driver taking over.
Once you boot the drives will be /dev/sda /dev/sdb etc….
I got 55MB/s with the hdparam test once the correct driver was enabled.
6.) There is a option in the Bios (once you update) to enable a “memory remapping function”. I enabled this and the OS and BIOS picked up 4GB of RAM.
This only works if you run the 64-Bit version of Centos.
For the 32-Bit version, you need to install a PAE-Kernel.
yum install kernel-PAE <and then reboot>.
