Model MT-M 8485-E7Y.
Currently I'm running my IBM box with Debian GNU/Linux Testing (Lenny) and Linux kernel 2.6.21.
|Feature||Description||Linux kernel options|
|CPU||Intel(R) Pentium(R) 4 CPU 3.20GHz||
|Ethernet||Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express||
|IDE controller||Intel Corporation 82801G (ICH7 Family)||
|SATA controller||Intel Corporation 82801GB/GR/GH (ICH7 Family)||
|Parallel port||PNP0400 Standard LPT printer port||
00:00.0 Host bridge: Intel Corporation E7230 Memory Controller Hub (rev 81) 00:01.0 PCI bridge: Intel Corporation E7230 PCI Express Root Port (rev 81) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11) 0a:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 01)
00:00 PNP0a03 PCI bus 00:01 PNP0c02 Motherboard resources 00:02 PNP0200 AT DMA controller 00:03 PNP0c04 Math coprocessor 00:04 PNP0b00 AT real-time clock 00:05 PNP0800 AT speaker 00:06 INT0800 (unknown) 00:07 PNP0501 16550A-compatible serial port 00:08 PNP0501 16550A-compatible serial port 00:09 PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support) 00:0a PNP0f13 PS/2 port for PS/2-style mice 00:0b PNP0400 Standard LPT printer port
I have two serial ATA disk drives NOT hot-swappable, but simple-swappable, this means that I can pull out the drives from the bay (with power turned off) while signal and power cables remains attached to a drive backplane.
If you don't want proprietary software on your computer, disable SATA HostRAID and use Linux kernel software RAID instead.
SATA HostRAID is the name of the feature offering RAID level-0 or level-1 on serial ATA disks. The SATA HostRAID feature is disabled by default, you must enable it in the BIOS Configuration/Setup utility (press F1 on system boot to enter it):
There is a program in the BIOS called Adaptec RAID Configuration Utility to configure the RAID volumes; to enter it press Ctrl+A on boot when the prompt Press <CTRL><A> for Adaptec RAID Configuration Utility appears. In Linux you need also the proprietary device drivers found on ServeRAID-7e (Adaptec HostRAID) Support CD.
I have a new IBM xSeries 206m with two SATA drives, I installed a Debian Testing (Etch) and configured a software RAID level-1. I experience this problem: whenever a volume is reconstructing (syncing), the system stops responding. The machine is alive, because it responds to the ping, the console is responsive but I cannot pass the login prompt. It seems that every disk activity is delayed and blocking.
Q: Sometimes when a RAID volume is resyncing, the system seems to locks-up: every disk activity is blocked until resync is done.
A: This is not strictly related to Linux RAID, this is a problem related to the Linux kernel and the disk subsytem: in no circumstances a process should get all the disk resources preventing others to access them.
You can control the max speed at which RAID reconstruction is done by setting it, say at 5 Mb/s:
echo 5000 > /proc/sys/dev/raid/speed_limit_max
This is just a workaround, you have to determine the max speed that does not lock your system by trial and error and you cannot predict what will be the disk load in the future when the RAID will be resyncing for some reason.
Starting from version 2.6, Linux kernel has several choices about the I/O scheduler to be used. The default is the anticipatory scheduler, which seems to be sub-optimal on resync high load. If your kernel has the CFQ scheduler compiled in, use it during resync.
From the command line you can see which schedulers are supported and change it on the fly (remember to do it for each RAID disk):
# cat /sys/block/hda/queue/scheduler noop [anticipatory] deadline cfq # echo cfq > /sys/block/hda/queue/scheduler
You can also pass the
elevator=cfq boot parameter to the kernel, using your boot loader.
Otherwise you can recompile your kernel and set CFQ as the default I/O scheduler (CONFIG_DEFAULT_CFQ=y in Block layer, IO Schedulers, Default I/O scheduler).
The problem does not occurr always, sometimes the second SATA disk is not detected by the kernel (look at the
SATA port has no device message):
ata_piix 0000:00:1f.2: version 1.05 ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 233 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x30C8 ctl 0x30BE bmdma 0x3090 irq 233 ata2: SATA max UDMA/133 cmd 0x30C0 ctl 0x30BA bmdma 0x3098 irq 233 ata1: dev 0 cfg 49:2f00 82:346b 83:7fe9 84:4773 85:3469 86:3c01 87:4763 88:207f ata1: dev 0 ATA-7, max UDMA/133, 156312576 sectors: LBA48 ata1: dev 0 configured for UDMA/133 scsi0 : ata_piix ata2: SATA port has no device. scsi1 : ata_piix Vendor: ATA Model: HDS728080PLA380 Rev: PF2O Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 156312576 512-byte hdwr sectors (80032 MB) SCSI device sda: drive cache: write back SCSI device sda: 156312576 512-byte hdwr sectors (80032 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 < sda5 sda6 sda7 > sd 0:0:0:0: Attached scsi disk sda
It turned out to be a kernel 2.6.16 problem, upgrading to 2.6.17 solved it. As kindly suggested by Tejun Heo: ata_piix probing received some updates during 2.6.16 devel cycle and some fixes during .17, thanks!
WARNING: Using IPMI instead of lm_sensors to read the system sensors proved to be a more mature solution, see below .
Currently (may 2006) there is a kernel module named smsc47m192 (not yet included in the official 2.6.17 tree) that can read some of the sensors. Unfortunately the Debian lm-sensors package must be patched to cope with this new kernel module. See this posting.
Add the following lines to
# Support modules for lm-sensors # I2C adapters. i2c_isa # IBM motherboard. i2c_i801 smsc47m192
As you can see, not all the senrsors can be read:
# sensors smsc47m192-i2c-0-2c Adapter: SMBus I801 adapter at 3060 in0: +2.50 V (min = +0.00 V, max = +3.32 V) in1: +0.00 V (min = +0.00 V, max = +2.99 V) ALARM in2: +3.32 V (min = +0.00 V, max = +4.38 V) in3: +5.10 V (min = +0.00 V, max = +6.64 V) in4: +12.12 V (min = +0.00 V, max = +15.94 V) in5: +3.32 V (min = +0.00 V, max = +4.38 V) in6: +1.51 V (min = +0.00 V, max = +1.99 V) in7: +1.80 V (min = +0.00 V, max = +2.39 V) temp1: +35.0°C (low = -128°C, high = +127°C) temp2: -128.0°C (low = -128°C, high = +127°C) FAULT temp3: -128.0°C (low = -128°C, high = +127°C) FAULT vid: +1.062 V (VRM Version 10.0)
In the IBM xSeries 206m there is a BMC (Baseboard Management Controller), i.e. a microcontroller embedded in the motherboard. This little computer uses its own firmware, which is independent from the system BIOS. It is connected to the main PC via the KCS interface, to all of the hardware sensors, to the network controller (to be verified). Fortunately we can talk to this controller via the KCS interface using a Linux kernel module.
Read this interesting article: IPMI on Debian.
Installed the Debian package openipmi, loaded the kernel modules ipmi_devintf and ipmi_si. It seems that the hardware is detected (from
ipmi message handler version 39.0 ipmi device interface IPMI System Interface driver. ipmi_si: Trying SMBIOS-specified KCS state machine at I/O address 0xca8, slave address 0x20, irq 0 ipmi: Found new BMC (man_id: 0x000002, prod_id: 0x0025, dev_id: 0x20) IPMI KCS interface initialized
Now we can run ipmish, an interactive shell to talk with IPMI subsystem:
> domain open paros smi 0 > sensor list Entity Name: paros(29.1) Sensors Name: paros(29.1).CPU FAN Entity Name: paros(3.1) Sensors Name: paros(3.1).CPU VCore Name: paros(3.1).CPU 1 Status0 Name: paros(3.1).CPU 1 Prochot0 Name: paros(3.1).CPU 1 Temp Entity Name: paros(29.3) Sensors Name: paros(29.3).System Fan ... > sensor get paros(29.3) > Sensor Name: paros(29.1).CPU FAN Event Messages Enabled: true Sensor Scanning Enabled: true Initial Update In Progress: false Value: 1.950000e+03 Raw Value: 0xd Threshold Name: lower critical Out Of Range: false
A more advanced interface is offered by
ipmitool, from the homonymous Debian package:
# ipmitool -I open sensor Ambient Temp | 37.000 | degrees C | ok | na | na | na | 70.000 | na | 80.000 CPU FAN | 1800.000 | RPM | ok | na | 1050.000 | na | na | na | na DASD Fan | 0.000 | RPM | ok | 28800.000 | na | 9600.000 | 0.000 | na | na CPU 1 Temp | 41.000 | degrees C | ok | na | na | na | 85.000 | na | 95.000 Sys Pwr Monitor | 0x0 | discrete | 0x0080| na | na | na | na | na | na Watchdog | 0x0 | discrete | 0x0080| na | na | na | na | na | na 1.5V Sense | 1.550 | Volts | ok | na | 1.340 | na | na | 1.670 | na 1.8V Sense | 1.850 | Volts | ok | na | 1.650 | na | na | 1.960 | na 3.3V Stby Sense | 3.420 | Volts | ok | na | 3.060 | na | na | 3.580 | na 12V Sense | 12.240 | Volts | ok | na | 11.016 | na | na | 13.248 | na 5V Sense | 5.250 | Volts | ok | na | 4.560 | na | na | 6.090 | na CPU 1 Prochot | 0x0 | discrete | 0x0080| na | na | na | na | na | na CPU 1 Status | 0x0 | discrete | 0x0080| na | na | na | na | na | na VRM 1 Status | 0x0 | discrete | 0x0080| na | na | na | na | na | na CPU Vtt Sense | 1.220 | Volts | ok | na | 1.100 | na | na | 1.300 | na NMI State | 0x0 | discrete | 0x0080| na | na | na | na | na | na SEL Fullness | 7.000 | messages | ok | na | na | na | 75.000 | 90.000 | 100.000 3.3V Sense | 3.420 | Volts | ok | na | 3.060 | na | na | 3.580 | na Login Violation | 0x0 | discrete | 0x0080| na | na | na | na | na | na Memory | na | discrete | na | na | na | na | na | na | na PEF Action | na | discrete | na | na | na | na | na | na | na System Fan | 1200.000 | RPM | ok | na | 600.000 | na | na | na | na PCI Bus | na | discrete | na | na | na | na | na | na | na POST Firmware | na | discrete | na | na | na | na | na | na | na CPU VCore | 1.357 | Volts | ok | 2.246 | na | 2.246 | 0.000 | na | na
Debian assigns a default permission of 0660 to
/dev/impi0, some programs may be not able to read it (e.g.
snmpd which runs under unprivileged user). To let the device a different mode, you can create a file
/etc/udev/rules.d/z99_local.rules with a line like this:
The parallel port is a PNP0400 Standard LPT printer port. To use it as a printer port you need the kernel modules parport, parport_pc and lp. The hardware is driven by the parport_pc module, but simply loading the module is not sufficient to enable the port. This is the kernel error message displayed by
pnp: Device 00:0b activated. pnp: Device 00:0b disabled. parport_pc: probe of 00:0b failed with error -22
This is beacuse the hardware is a Plug and Play device and we need to activate it. Linux support for PnP devices is granted via the old interface
/proc/bus/pnp/… or via the new interface
/sys/bus/pnp/devices/…. Activate the following options into the kernel configuration: CONFIG_PNP, CONFIG_PNPBIOS, CONFIG_PNPACPI and CONFIG_PNPBIOS_PROC_FS. Note that ACPI is expected to supersede PNPBIOS some day, currently it co-exists nicely.
Use the lspnp command to discover the ID of the device (00:0b in this case), after boot the device is disabled:
cat '/sys/bus/pnp/devices/00:0b/resources' state = disabled io disabled irq 7
Then enable it with:
echo auto > '/sys/bus/pnp/devices/00:0b/resources' echo activate > '/sys/bus/pnp/devices/00:0b/resources' cat '/sys/bus/pnp/devices/00:0b/resources' state = active io 0x378-0x37b irq 7
See the pnp.txt help file supplied with the kernel for more info. This time the kernel modules load and work as expected:
pnp: Device 00:0b activated. parport: PnPBIOS parport detected. parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP] lp0: using parport0 (interrupt-driven).
Unfortunatelly the port settings will not survive the reboot. As explained in man modprobe.conf(5), you can execute automatically the previous commands before loading the kernel module adding the following lines into a file
# Activate the PnP parellel port before loading the kernel module. install parport_pc \ echo auto > '/sys/bus/pnp/devices/00:0b/resources'; \ echo activate > '/sys/bus/pnp/devices/00:0b/resources'; \ /sbin/modprobe --ignore-install parport_pc $CMDLINE_OPTS
Burn the ibm_fw_bios_pae137a_anyos_i386.iso image onto a CD-ROM and reboot from it, follow the instructions. In the picture the boot screen after the update.
I downloaded the 1.43 version too, but not flashed yet: ibm_xseries_bios_udate_pae143a.tgz.
2007-09-15 Added 1 Gb of memory installing two RAM modules: