Best of the Newsgroups: vmware emulation, wd drivers

Main Index

Path: border1.nntp.dca.giganews.com!nntp.giganews.com!nf3.bellglobal.com!news.ca.mci.com!news.uunet.ca!enigma.xenitec.ca!jpradley.jpr.com!via-email
From: Bela Lubkin 
Newsgroups: comp.unix.sco.misc
Subject: Re: SCO OS 5.0.7 on Qemu
Date: 7 Jan 2006 05:01:28 -0500
Lines: 158
Sender: nouser@jpradley.jpr.com
Message-ID: <200601070201.aa18884@deepthought.armory.com>
References: 
NNTP-Posting-Host: jpradley.jpr.com
X-Trace: jpradley.jpr.com 1136628088 26076 (None) 198.207.210.2
X-Complaints-To: news@jpradley.jpr.com
X-Mailer: Mail User's Shell (7.2.6 beta(5) 1998-10-07 + patches)
Xref: number1.nntp.dca.giganews.com comp.unix.sco.misc:168068

Roberto Zini wrote:

> This time of the year allows me to experiment with things that otherwyse
> I woulnd't have the time play with; during the last few days I gave Qemu
>  0.8.0 + kqemu (running on SuSE Linux 10) a try. I was able to install
> and successfully use Windows XP and I wanted to give SCO OS 5.0.7 a run.
> 
> I started with a 300MB memory allocation and by creating a virtual disk
> of 2GB; when I booted from the CD, I was able to get to the boot: prompt
> but, after depicting the usual dots, I ended up having a blank screen
> instead of the "laundry list" of devices.
> 
> Qemu is able to emulate an old Cirrus Logic board and, since
> I was aware of the OSS653A patch (the initial VGA recognition
> supplement) so I tried to add it as a BTLD driver (which worked fine)
> but again I ended up with a blank screen.
> 
> So I gave OSS661A a try and I was able to get to the laundry list but I
> had a "WARNING: hd: no root disk controller was found".
> 
> This is strange since Qemu is able to emulate a simple IDE/EIDE
> controller; the CD-ROM interface the installed detect is the real
> /dev/cdrom device under Linux and the HD is an ATA-2 2GB HD configured
> as ata0/master.

This is much the same problem that OSR5 has previously had with VMware
and then with MS Virtual PC.  The OSR5 "wd" IDE driver has code in it to
work around the quirks of _ancient_ "wd" family disk controllers.  I'm
talking about things like the Western Digital WD1003 (16-bit ISA
controller used in PC/AT class machines), and even older relatives.
These workarounds have been conditioned over the years to work correctly
with _real_ MFM/RLL/ESDI/IDE/ATA/etc controllers, but they tend to
trigger oddities in emulators.

The driver is partly at fault (for pushing the "hardware" in weird,
unexpected directions); and the emulator is partly at fault (for not
emulating every quirk of the real hardware it's supposed to represent).

> I tried with "defbootstr Sdsk=wd(0,0,0) link=invd prompt" but that gave
> me a panic during the hd_config stage.

Although "wd" has a SCSI interface, that is only used for ATAPI devices
(mostly CD/DVD drives, also tapes and a few other oddball items).  IDE
hard disks are _not_ in any way seen as SCSI under OSR5.  Here you told
the kernel to look for a SCSI disk on a "wd" HBA.  This is a valid
formulation to access an ATAPI device that represents itself as a hard
disk, e.g. an ATAPI Zip.  It goes nowhere with a true IDE hard disk.

> So I downloaded the WD supplement from SCO's FTP site and tried to use
> it using the
> 
> 	link="invd wd"
> 
> bootstring. The loader correctly prompted me to replace the existing
> "wd" driver but, again, I ended up having a "no root disk controller was
> found".
> 
> The laundry list reported
> 
> 	adaptec 0x0170-0x0177 15 - type=IDE ctlr=secondary drv=wd
> 
> which is the secondary IDE controller but failed to report the primary
> (which is/should be at 0x1F0 - IRQ 14). I tried again by telling the
> loader to search for a "wd" adapter here:
> 
> 	adapter=wd(0x1F0,14,0)
> 
> but unsuccessfully.

"wd", in its role as a pseudo-SCSI HBA, announces "%adapter" lines for
controllers on which it finds ATAPI devices.  Your primary controller
has only a hard disk (which it isn't going to see as SCSI), so it
doesn't announce the HBA.  If the hard disk itself is found, you get a
"%disk" line that announces the same I/O addresses etc.

No "adapter=", "Sdsk=" or any other OSR5 SCSI subsystem-related
bootstrings are going to help here.  What you need is to get the IDE
controller and hard disk detection over the hump.

> I'm pretty sure that (again - and he will be more than welcome :-) Bela
> will jump ip, scare me to death and provide a simple solution...

Hmmm, well, let's scare you with this: I'm starting a new job Monday, at
VMware.  I suspect that I should not do a whole lot of very visible
support work on open source products that compete directly with my
employer.  But what the heck, at the moment this falls under "learning
about emulation" -- it will make me more effective at my job.

Next step I recommend:

  Boot
  : defbootstr link=invd wd.debug=ugi

This makes the "wd" driver print as much debug output as it can; which
isn't very much, but should give us a vague sense of how far it's
getting.

The sequence of operations that happen is, very crudely, something like
this:

  wd_ctlrpres():
    see if a ST506/IDE controller is present
    /* if we got this far, the driver does think a controller exists,
       but it also wants to know if it's one of the ancient weird ones
       that it knows won't work, so: */
    subject it to several weird tests
    return false if those weird tests fail

  wd_drivepres():
    see if a ST506/IDE hard disk is present
    /* same deal */
    subject it to several weird tests
    return false if those weird tests fail

You're going to get some debug output that may or may not clarify this.
If you're lucky, debug output will suggest an easy workaround.  If not,
the next step will be to boot with "defbootstr link=invd maindebug".
That invokes scodb (kernel debugger) early in the kernel's life, then
you can set breakpoints inside "wd" and trace the recognition code, see
where it goes wrong.

BTW, are you sure it's "invd" and not "ivga"?  "invd" works around a
fairly specific nVidia BIOS behavior; "ivga" is much more generic.  (The
issues are completely different and could possibly both occur on the
same system, though I've never heard of that.)  "ivga" works around a
far more common BIOS problem: incorrect setting of the CMOS video type
value.  In fact, I see that Qemu uses the Bochs video BIOS, and that
this very bug was fixed in version 0.5c of that BIOS.  See
http://www.nongnu.org/vgabios/.  That page has compiled BIOS images; you
should be able to download a newer one into your Qemu/bios directory.
(Update both vgabios.bin and vgabios-cirrus.bin, I'm not sure how to
tell which one Qemu will use on your machine.)  Then you shouldn't need
"ivga".

On further examination, I suspect that Qemu's BIOS may have both issues!
So you may really mean you are using "invd".  Why would it not need
"ivga"?  Because it gets lucky -- the wrong value that it leaves in CMOS
isn't wrong enough to bother OSR5.

But you said "oss653a", which is the "ivga" supplement, so in the end my
guess is that you're using "ivga" and just typed "invd" into your post
by mistake.

=============================================================================

I've been running OSR5 under VMware Workstation for several years now.
There were some problems at first.  These days I have great success with
it.  VMware now makes a "player" available for free, lets you run
previously built virtual machines.  You could probably install OSR5 onto
that, giving you another free virtual machine that can run OSR5 (without
all these issues).  But without source -- so if your real goal here was
to study the emulation mechanics themselves, that won't do.

There, is that scary enough?  ;-}

>Bela<
 

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.