I came across two bizarre issues last week while installing VMWare server on a Fedora Core 6 desktop. The first issue occurred when the vmware-config.pl script attempted to build the vmmon kernel module:
$ vmware-config.pl
Making sure services for VMware Server are stopped.
Stopping VMware services:
Virtual machine monitor [ OK ]
Configuring fallback GTK+ 2.4 libraries.
In which directory do you want to install the mime type icons?
[/usr/share/icons]
What directory contains your desktop menu entry files? These files have a
.desktop file extension. [/usr/share/applications]
In which directory do you want to install the application's icon?
[/usr/share/pixmaps]
Trying to find a suitable vmmon module for your running kernel.
None of the pre-built vmmon modules for VMware Server is suitable for your
running kernel. Do you want this program to try to build the vmmon module for
your system (you need to have a C compiler installed on your system)? [yes]
Using compiler "/usr/bin/gcc". Use environment variable CC to override.
What is the location of the directory of C header files that match your running
kernel? [/usr/src/kernels/2.6.18-1.2869.fc6-i686/include]
Extracting the sources of the vmmon module.
Building the vmmon module.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config0/vmmon-only'
make -C /usr/src/kernels/2.6.18-1.2869.fc6-i686/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. mo
dules
make[1]: Entering directory `/usr/src/kernels/2.6.18-1.2869.fc6-i686'
CC [M] /tmp/vmware-config0/vmmon-only/linux/driver.o
CC [M] /tmp/vmware-config0/vmmon-only/linux/hostif.o
CC [M] /tmp/vmware-config0/vmmon-only/common/cpuid.o
CC [M] /tmp/vmware-config0/vmmon-only/common/hash.o
CC [M] /tmp/vmware-config0/vmmon-only/common/memtrack.o
CC [M] /tmp/vmware-config0/vmmon-only/common/phystrack.o
CC [M] /tmp/vmware-config0/vmmon-only/common/task.o
CC [M] /tmp/vmware-config0/vmmon-only/common/vmx86.o
CC [M] /tmp/vmware-config0/vmmon-only/vmcore/moduleloop.o
LD [M] /tmp/vmware-config0/vmmon-only/vmmon.o
Building modules, stage 2.
MODPOST
CC /tmp/vmware-config0/vmmon-only/vmmon.mod.o
LD [M] /tmp/vmware-config0/vmmon-only/vmmon.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.18-1.2869.fc6-i686'
cp -f vmmon.ko ./../vmmon.o
make: Leaving directory `/tmp/vmware-config0/vmmon-only'
Unable to make a vmmon module that can be loaded in the running kernel:
insmod: error inserting '/tmp/vmware-config0/vmmon.o': -1 Invalid module format
There is probably a slight difference in the kernel configuration between the
set of C header files you specified and your running kernel. You may want to
rebuild a kernel based on that directory, or specify another directory.
For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".
Execution aborted.
After a bit of poking around in /tmp/vmware-config0/vmmon-only, I figured out that I didn’t have the correct architecture of the redhat kernel source installed (my system had the i686 kernel development package instead of the i586 kernel development package). Once I removed the kernel-devel-i686 package and added the kernel-devel-i586 package, the kernel module built fine, but the vmnet module failed to build:
$ vmware-config.pl
< ..... >
Building the vmnet module.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config1/vmnet-only'
make -C /lib/modules/2.6.18-1.2869.fc6/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modul
es
make[1]: Entering directory `/usr/src/kernels/2.6.18-1.2869.fc6-i586'
CC [M] /tmp/vmware-config1/vmnet-only/driver.o
CC [M] /tmp/vmware-config1/vmnet-only/hub.o
CC [M] /tmp/vmware-config1/vmnet-only/userif.o
CC [M] /tmp/vmware-config1/vmnet-only/netif.o
CC [M] /tmp/vmware-config1/vmnet-only/bridge.o
CC [M] /tmp/vmware-config1/vmnet-only/procfs.o
/tmp/vmware-config1/vmnet-only/procfs.c:33:26: error: linux/config.h: No such file or dir
ectory
make[2]: [/tmp/vmware-config1/vmnet-only/procfs.o] Error 1
make[1]: [_module_/tmp/vmware-config1/vmnet-only] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.18-1.2869.fc6-i586'
make: [vmnet.ko] Error 2
make: Leaving directory `/tmp/vmware-config1/vmnet-only'
Unable to build the vmnet module.
For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".
Execution aborted.
After a bit of googling, it turns out that one of the headers is reliant on a deprecated configuration header. To fix this issue, I had to run vmware-config.pl again after touching config.h in the include directory of the kernel source that matched my running kernel (in this case, 2.6.18-1.2869.fc6-i586):
$ cd /usr/src/kernels/2.6.18-1.2869.fc6-i586/include/linux
$ touch config.h
Once I addressed these two issues, VMWare server ran perfectly!
Periodically I need to identify the vendor and model of a PCI card installed in a x86 Linux or Solaris host. To retrieve this information on Solaris hosts, I typically use the scanpci utility (prtdiag also provides some incredibly useful information):
$ scanpci -v
pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0xaaaa device 0x1121
Device unknown
STATUS 0x0280 COMMAND 0x0007
CLASS 0x03 0x00 0x00 REVISION 0x00
BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00
BASE0 0x0000ff01 addr 0x0000ff00 I/O
BASE1 0xc0000000 addr 0xc0000000 MEM
BASEROM 0x000c0001 addr 0x000c0000 decode-enabled
MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x00 INT_LINE 0xff
pci bus 0x0000 cardnum 0x03 function 0x00: vendor 0xaaaa device 0x1112
Device unknown
STATUS 0x0280 COMMAND 0x000f
CLASS 0x06 0x80 0x00 REVISION 0x00
BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00
BASE0 0x00001041 addr 0x00001040 I/O
MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x09
pci bus 0x0000 cardnum 0x05 function 0x00: vendor 0x10ec device 0x8029
Realtek Semiconductor Co., Ltd. RTL-8029(AS)
STATUS 0x0000 COMMAND 0x0007
CLASS 0x02 0x00 0x00 REVISION 0x00
BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00
BASE0 0x00001081 addr 0x00001080 I/O
MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0a
pci bus 0x0000 cardnum 0x1e function 0x00: vendor 0x8086 device 0x1130
Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub
CardVendor 0x8086 card 0x4541 (Intel Corporation, Card unknown)
STATUS 0x0090 COMMAND 0x0007
CLASS 0x06 0x00 0x00 REVISION 0x02
BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00
BASE0 0x84000008 addr 0x84000000 MEM PREFETCHABLE
MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x00 INT_LINE 0xff
pci bus 0x0000 cardnum 0x1f function 0x00: vendor 0x8086 device 0x2440
Intel Corporation 82801BA ISA Bridge (LPC)
CardVendor 0x8086 card 0x4541 (Intel Corporation, Card unknown)
STATUS 0x0280 COMMAND 0x000f
CLASS 0x06 0x01 0x00 REVISION 0x08
BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00
BASE0 0x000010c0 addr 0x000010c0 MEM
BASE1 0x00001400 addr 0x00001400 MEM
BASE2 0x00001440 addr 0x00001440 MEM
BASE3 0x00001480 addr 0x00001480 MEM
BASE4 0x000014c0 addr 0x000014c0 MEM
BASE5 0x00001800 addr 0x00001800 MEM
MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x00 INT_LINE 0xff
BYTE_0 0x01 BYTE_1 0x10 BYTE_2 0x00 BYTE_3 0x00
pci bus 0x0000 cardnum 0x1f function 0x01: vendor 0x8086 device 0x244b
Intel Corporation 82801BA IDE U100
CardVendor 0x8086 card 0x4541 (Intel Corporation, Card unknown)
STATUS 0x0280 COMMAND 0x0007
CLASS 0x01 0x01 0x80 REVISION 0x00
BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00
BASE4 0x00001841 addr 0x00001840 I/O
MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x00 INT_LINE 0xff
BYTE_0 0xff BYTE_1 0xe3 BYTE_2 0xff BYTE_3 0xe3
For Linux hosts, lspci provides similar information:
$ lspci -v
00:02.0 VGA compatible controller: Unknown device aaaa:1121 (prog-if 00 [VGA])
Flags: bus master, medium devsel, latency 0
I/O ports at ff00 [size=64]
Memory at c0000000 (32-bit, non-prefetchable) [size=1024M]
Expansion ROM at
00:03.0 Bridge: Unknown device aaaa:1112
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at 10a0 [size=32]
00:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
Subsystem: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
Flags: bus master, fast devsel, latency 0, IRQ 10
I/O ports at 1080 [size=32]
00:1e.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controlle
r Hub (rev 02)
Subsystem: Intel Corporation: Unknown device 4541
Flags: bus master, fast devsel, latency 0
Memory at 84000000 (32-bit, prefetchable) [size=64M]
Capabilities: [88] Vendor Specific Information
Capabilities: [a0] AGP version 2.0
00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 08)
Subsystem: Intel Corporation: Unknown device 4541
Flags: bus master, medium devsel, latency 0
Memory at (32-bit, non-prefetchable)
Memory at (32-bit, non-prefetchable)
Memory at (32-bit, non-prefetchable)
Memory at (32-bit, non-prefetchable)
Memory at (32-bit, non-prefetchable)
Memory at (32-bit, non-prefetchable)
00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (prog-if 80 [Master])
Subsystem: Intel Corporation: Unknown device 4541
Flags: bus master, medium devsel, latency 0
I/O ports at 1840 [size=16]
00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio (rev 02)
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at 1c00 [size=256]
I/O ports at 2000 [size=64]
These are invaluable commands, and can come in handy!
Most modern drives support DMA, and the Linux IDE driver will use DMA if a device supports it. To check if a device is using DMA on a Linux host, you can cat /proc/ide/piix:
$ cat /proc/ide/piix
Controller: 0
Intel PIIX4 Ultra 100 Chipset.
--------------- Primary Channel ---------------- Secondary Channel -------------
enabled enabled
--------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------
DMA enabled: yes yes yes yes
UDMA enabled: yes yes yes yes
UDMA enabled: 5 5 5 5
UDMA
DMA
PIO
The output contains a “yes” or “no” to indicate if DMA is enabled, and a line to indicate which DMA mode is in use. If for some reason DMA isn’t being used with a device, you can use hdparm to enable it.
This week I was trying to determine the cache size of an IDE disk drive. While poking around /proc/ide, I came across a number of super useful entries:
IDE driver versions:
$ cat /proc/ide/drivers
ide-floppy version 0.99.newide ide-cdrom version 4.61 ide-disk version 1.18
IDE drive cache size:
$ cat /proc/ide/ide0/hda/cache
2048
IDE drive capacity:
$ cat /proc/ide/ide0/hda/capacity
16778160
IDE drive geometry:
$ cat /proc/ide/ide0/hda/geometry
physical 16645/16/63
logical 16645/16/63
Model of IDE device:
$ cat /proc/ide/ide0/hda/model
Virtual HDD [0]
IDE driver configuration settings:
$ cat /proc/ide/ide0/hda/settings
name value min max mode
acoustic 0 0 254 rw address 0 0 2 rw bios_cyl 16645 0 65535 rw bios_head 16 0 255 rw bios_sect 63 0 63 rw bswap 0 0 1 r current_speed 69 0 70 rw failures 0 0 65535 rw init_speed 69 0 70 rw io_32bit 0 0 3 rw keepsettings 0 0 1 rw lun 0 0 7 rw max_failures 1 0 65535 rw multcount 128 0 128 rw nice1 1 0 1 rw nowerr 0 0 1 rw number 0 0 3 rw pio_mode write-only 0 255 w unmaskirq 0 0 1 rw using_dma 1 0 1 rw wcache 1 0 1 rw
Each time I dig through /proc, I always seem to turn up some interesting
One of the Redhat Enterprise Linux 4 update 3 servers I support had several LUNs added to it this week. The server was using Qlogic 2340 HBAs, which allowed me to use the ql-dynamic-tgt-lun-disc.sh script from the Qlogic support site to dynamically discover the new LUNs:
$ ql-dynamic-tgt-lun-disc.sh
Scanning HOST: host1
....
Scanning HOST: host2
.............
Scanning HOST: host3
....
Found
1:0:0:6
1:0:0:8
1:0:1:6
1:0:1:8
3:0:0:6
3:0:0:8
3:0:1:6
3:0:1:8
After the script completed device discovery, two devices were visible for each LUN (there are multiple paths to the disk storage) in the output of fdisk. To allow use to take advantage of both paths, we needed to create an EMC power device (we are using EMC powerpth instead of dm-mulipath). This was accomplished by running powermt with the “config” option:
$ powermt config
Once the config operation completed, the power device was visible:
$ powermt display dev=emcpoweri
Pseudo name=emcpoweri
CLARiiON ID=APM [Foo]
Logical device ID=0987 [LUN 80 - DS Foo]
state=alive; policy=CLAROpt; priority=0; queued-IOs=0
Owner: default=SP A, current=SP B
< ..... >
And available for general purpose use. I have bumped into numerous kernel bugs in the past that prevented me from dynamically discovering storage, so this was a welcome change. Having used both Qlogic and Emulex adaptors on Solaris and Linux hosts, I think I still prefer Emulex adaptors over Qlogic adaptors.