[Xen-users] Xen not recognizing second SATA Hard Disk or CDROM

["mark mclarnon" <mark.mclarnon@xxxxxxxxx>]

I have encountered a strange situation with Xen 3.1.0 that I cannot seem to resolve. I wonder if  anyone in the community has experienced anything similar. Assume for the moment that I have the proper CPU to be running Xen in the first place. My situation is this:

Operating System: Debian Etch (Linux debian 2.6.18-6-686-bigmem)
Motherboard ASUS P5K
8 GB RAM (hence bigmem kernel)
2 SATA Hard Drive 750 GB
2 SATA DVD Burner

Now I am aware of the problems  with this particular board (P5K) and SATA devices. Although there was no particular reason to choose SATA DVD drives (a decision I now regret), I believe the use of 2 SATA HD was ok. Incidentally, the only way I could get Debian onto the system was using a USB key method.

NOTE: I am running the latest BIOS as downloaded from  ASUS support today 0225/08. Sorry I forget the rev number but its dated from Jan 08.

All 4 devices are connected to the 4 main mother board SATA channels (read ICH9 connectors) and nothing is connected to the JMicron channel in the back of the board. In addition to this, JMicron controller has been disabled in the BIOS. The order of devices is:

1. SATA HD (/dev/sda)
2. SATA CDROM
3. SATA CDROM
4. SATA HD (/dev/sdb)

I follow the instructions to build Xen from source:

# apt-get ..... (long list omitted here)
# make world
# make install
# update-rc.d xend defaults 20 21
# update-rc.d xendomains defaults 21 20

I did not use any custom configuration or build options. Its at this point that things get hairy. I see many google/Xen links that you must build an initrd but the recommended way of doing so differs quite a bit. Some links claim you should use mkinitrd, some claim yaird. Others claim mkinitramfs and still others claim  update-initramfs. Initially I believe I used mkinitramfs as follows:

# depmod 2.6.18-xen
# mkinitramfs -o /boot/initrd.img-2.6.18-xen 2.6.18-xen

The next step was to run:

# update-grub

This automatically adds the following stanza to /etc/grub/menu.lst:

title        Xen 3.1.0 / Debian GNU/Linux, kernel 2.6.18-xen
root        (hd0,0)
kernel        /boot/xen-3.1.0.gz
module        /boot/vmlinuz-2.6.18-xen root=/dev/sda1 ro console=tty0
module        /boot/initrd.img-2.6.18-xen
savedefault

Coincidentally, my existing stanza was:

title        Debian GNU/Linux, kernel 2.6.18-6-686-bigmem
root        (hd0,0)
kernel        /boot/vmlinuz-2.6.18-6-686-bigmem root=/dev/sda1 ro
initrd        /boot/initrd.img-2.6.18-6-686-bigmem
savedefault

Note the root=/dev/sda1 in each case. At this point, I reboot and attempt to start the machine with a Xen kernel. Depending on how I have the P5K BIOS setting "SATA Configuration" (detailed in the P5K user manual section 4.3.5) the machine either fails to boot (when set with the SATA Enhanced setting) or boots successfully (with the SATA IDE setting) but never sees the second SATA HD or second DVD writer. In short, the devices connected to the 3rd and 4th ICH9 SATA connectors don't get recognized.

NOTE: When SATA Configuration is set to IDE, the only way Xen will boot is if I change the root=/dev/sda1 to read root=/dev/hda1.
 
Whats even more interesting (to me at least) is that when booting with the Xen kernel, the boot device that used to be known as /dev/sda is recognized by the kernel as /dev/hda. Yet files such as /etc/fstab still reference /dev/sda1! Does the SCSI subsystem provide a mapping of some type from /dev/sda to /dev/hda? Is it a softlink in the /dev directory?

In desperation, I have tried grub options such as all-generic-ide and irqpoll to get the second drives recognized but the system never seems to boot properly listing errors with "lost interrupt hda" and the like. The second HD and DVD writer seem to show up as /dev/sde and /dev/sdg (if I recall correctly).

My questions are:

1. Is attempting to use a second HD and DVD writer a lost cause?
2. Why does the Xen kernel skip the recognition of the second HD and DVD writer?
3. Why if the boot log reports my boot device was recognized as /dev/hda does my system still boot and reference /dev/sda?
4. Considering #3, why must /etc/grub/menu.lst be changed but not /etc/fstab?
5. Could this entire problem be attributed to the lack of judgment when procuring a Xen compatible motherboard?

Has anyone seen this situation before?

Mark

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users