vmware bochs osr5 under linux

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.com>
Subject: Re: INT13 function FAh during boot?
Date: Fri, 26 Apr 2002 10:18:46 GMT
References: <c12f3009.0204221242.29c063c4@posting.google.com> <c12f3009.0204251312.3993b1bc@posting.google.com> 

Carl Sopchak wrote:

> I've got the install CD booting, I've disabled the fdi and dptr
> drivers, but now I get "WARNING: hd: no root disk controller found".
> 
> The emulated bios shows "IDE0-0: Generic 1234 ATA-2 Hard-Disk device"
> for the disk image that it uses, so I know OSR should be using the wd
> driver (right??).
> 
> Using biosgeom shows the disk as 1014/16/63; the program that I used
> to create the disk image stated _1015_/16/63.  I'm assuming that the
> difference in cylinders is one's counting from 0, the other from 1. 
> (I'll try to confirm this...)

That's probably the issue.  Not a real problem anyway.  (If they truly
disagreed and the OS was _higher_ then it would eventually -- when the
"disk" was >99% full -- attempt to write past the end of the image, get
some sort of failure, and behave weirdly since it wouldn't expect that
-- but since the OS is coming in lower, at worst it'll just miss out on
one cyl's worth of storage.)

> I've tried the following boot string options (appended to "defbootstr
> disable=fdi,dptr"):
> 
> - Result is "WARNING: hd: no root disk controller found"
>   Sdsk=wd(0,0,0)
>   Sdsk=wdha(0,0,0)  {later found this doesn't make sense}

Neither does "Sdsk=wd(0,0,0)".  OSR5 does _not_ see IDE disks as any
sort of SCSI device.  They are their own thing, unrelated to SCSI and
not using any part of the OSR5 SCSI driver framework.  This confusion
comes about partly because OSR5 _does_ see other IDE devices as SCSI
(anything "ATAPI").  ATAPI is basically a slightly braindamaged version
of SCSI, hidden behind a translation layer.  OSR5 retranslates that back
to SCSI so that you can use the OSR5 SCSI peripheral drives with ATAPI
devices.

>   pci.bios

I'm not familiar with this one.

>   phoenix486

I was the cause of this -- had an old 486 machine with a buggy Phoenix
BIOS, and since I was in a position to influence the development
process, I was able to get a workaround in.  I'm sure no current machine
or even an emulator BIOS could possibly duplicate the stupid bug that
BIOS had.

>   scsi.noscan
>   wd.noscan         {this doesn't seem to make much sense, either...}

These control what sorts of SCSI or SCSI-like probing is done on the
buses.  Shouldn't affect IDE hard disks, which aren't even vaguely SCSI.

>   wd.udma=off       {never know...}

That might help, or (apparently) not.

>   wd.geom=[x]
>     where [x] is one of "physical", "logical", "translate",
> "1014,16,63",
>     "1015,16,63"

This doesn't seem like a geometry issue.  (Might have those next, if you
can get past the recognition issue.)

>   wd.debug[=x]
>     where [=x] is one of "" (no parm), "=udma", "=all"
> - Result is "Test Open Failed "hd=wd", No Root Disk Controller"

That's too bad.  "wd" really needs more debugging output in paths other
than UDMA setup.

>   hd=wd
>   hd=Sdsk Sdsk=wd(0,0,0)  {except "hd=Sdsk" replaced "hd=wd"}
> 
> These last two might give me a clue.  Upon looking at the log file
> created by bochs (with all sorts of messaging options turned on), I
> found "write cmd 0x70 (SEEK) not supported".  Is this how OSR
> determines if a disk is present??

"hd=wd" is what you want.  It also should make no difference -- you are
only forcing what's supposed to be determined automatically by whether
the various hard disk drivers (primarily "wd" for IDE and "Sdsk" for
SCSI disks) actually found any disks.  So if "wd" recognition succeeded,
you wouldn't need "hd=wd", and if it failed, "hd=wd" wouldn't help.

But, anyway, _yes_, this is part of how "wd" detects hard disks.  It
does a "seek 0" and if it succeeds, goes on to some other tests.  If it
fails then there is definitely no hard disk.

So, to get past this hurdle, bochs needs to support the IDE SEEK
command.  Which should be quite simple.  For OSR5's purposes, it should
return success if there is a(n emulated) _hard disk_ drive (not an
emulated ATAPI CD/tape/whatever) at the given controller/drive
coordinates, and the requested track is within its range.  Besides
success/failure, it doesn't actually have to _do_ anything.  IDE SEEK is
just supposed to position the head -- the OS is supposed to know what
it's doing, e.g. optimizing performance by moving the head near where
it's anticipated the next I/O will be done.  If the actual location was
known then it would just issue a READ or WRITE.  Since there's no "head"
with an emulated drive, any SEEK that's within range just "succeeds".

> If that's not the case, are there other boot parameters (in particular
> for the wd driver) that might tell OSR exactly where to look?

Unfortunately, no.  You would like an override that tells it "look you
idiot, there _is_ an IDE drive at primary/master, don't do any of this
silly voodoo trying to detect it".  That override doesn't exist.

See if you can get IDE SEEK support in bochs, then we'll bounce off the
next hurdle...

>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.