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: Wed, 1 May 2002 07:36:08 GMT
References: <200204271534.aa00201@xenitec.xenitec.on.ca> <20020427123740.A15678@mammoth.ca.caldera.com> <c12f3009.0204301135.5db9cbc0@posting.google.com> 

Carl Sopchak wrote:

> First, some info to help based on your last two posts:
> 
> bochs implements ATA-2 for the hd, and ATAPI-4 for the CD.  The specs
> for these can be found at http://www.t13.org (page down some...).  The
> ATA-2 spec is actually a draft (never to be completed), so you can
> just download it from that page.  ATAPI-4 is completed, so it costs
> $$, but you can download the ATAPI-6 draft...  Also, you can get the
> ATAPI CD-ROM Packet extension info at
> http://akrip.sourceforge.net/8020r26.pdf.  This describes the
> "subcommands" of the ATA Packet command (basically SCSI commands
> embedded in the ATA spec).  As the ATA-2 spec states, writes to port
> 0x3f6 is the Device Control Register, and reads from 0x3f6 is the
> Alternate Status Register, so, yes, how it is used is *very much*
> dependant on prior I/O to the drive.  After looking at the specs
> briefly, I can see why the code could be quite bewildering -
> especially if it wasn't *very* well commented!

The code is very old, patched hundreds of times for various reasons,
commented as to why, but the layering of comments, fixes, etc. makes it
hard to follow...

> Here's what I've done so far:
> 
> - I added EIP to the general log entry format.  Future logs will show
> this...
> - I changed the panic for the start disk & read TOC command to a nop,
> although I think, to "meet the spec", I should have implemented a read
> of the TOC on the disk...  However, SCO didn't seem to mind not
> getting the TOC.  Maybe I'll get to that some day (when necessary
> <grin>)...
> 
> 
> Now, where we're at:
> 
> During the install, I got the message "WARNING: wd0: timeout on fixed
> disk dev 1/0" several times.  Since it is referring to the second IDE
> controller, which doesn't exist, I guess it's safe to ignore...  (Why
> does it keep trying to do anything with it?  The kernel never
> recognised a second controller at startup...)

You're misunderstanding the message.  "1/0" is the major and minor
number of the device that's having the problem.  1 is the major number
of the "hd" driver.  Minor number 0 of that driver means "0th drive,
entire disk".  So it's complaining about a timeout on the 0th drive,
which in your case is (virtual) IDE primary/master.

> Later in the install (just before and during the Installation Progress
> screen [with progress bar]), I also got a whole lot of "WARNING: wd0:
> timeout on fixed disk dev 1/42" messages.  I'm hoping that SCO does a
> retry on these...  Got any clue as to what I should look for in order
> to get rid of these?

It's got to be another case of virtual interrupts not being received.

Dev 1/42 is minor #42 of the hd drive; minor 42 is "0th drive, active
partition, division #2".  By convention, that's where the install puts
your root filesystem.

> The install also seems to be running VERY slow!  It's been running for
> almost 5 hours now, and still only at 5% installed (acording to the
> progress bar)!  The messages (particularly "copying file" messages) do
> seem to update fairly regularly on the Installation Status line, so I
> know work is being done.  I imagine that the timeouts ain't helping in
> this regard.

No, they wouldn't be helping.  Looks like there is a 60-second timeout
after it decides the disk is "dead" (and issues the timeout message),
before it will try the disk again.

It's normal for the install to peg at "5%" for a long time: the
percentages displayed are _really_ crude.  It's always seemed to me that
it displays "5%" for about 70% of the install.

> Other than that, it is running, with no other issues!!!  (Apparently,
> the "lock unit" was already implemented...)  Now, I just need to wait
> for it to complete!
> 
> I am going to let it run overnight.  I'll post back tomorrow as soon
> as it finishes...

Ok, great.

I'm worried that there will be corruption due to all the timeouts.  The
timeouts you're hitting are accompanied by a log comment which I will
include here (edited to fix context):

  - [problem] when power was removed from a drive: the whole driver
    would hang!
  - When issuing a command, set a timeout of 'wdcmdtime' seconds (or
    'wdprmtime' seconds for a SET_PARM command) during which time all
    commands are expected to complete.  If no interrupt occurs within
    this time assume that either the disk has hung, or that there is no
    disk to respond (it was never there, or it has gone away.)
  - Reset the controller and try a SET_PARM command: if this succeeds
    carry on as usual (assume a temporary disk hang); if it fails assume
    that the disk has gone west.  Fail all further commands to this disk
    during the next 'wdchktime' seconds, then try further commands in
    the same way to allow for the possibility of it springing into life
    again.
  - The value of 'wdcmdtime' must be carefully chosen to allow for disks
    which spin-down to save power during periods of inactivity, or which
    self-calibrate.  Likewise 'wdprmtime' should be "long enough", but
    as short as possible to prevent the driver sleeping too long when
    probing (probably) dead disks.
  - Timeout values are tunable in (new) space.c

Unfortunately you can't easily patch those timeout values since you
aren't linking a new kernel, but using a premade one from the boot CD.

After further code reading, I think it fully retries all of these
timeouts.  So your install is incredibly slow, but may be successful.
This gives you an opportunity to play around with some of these
parameters once the install is done.

First, either at the start of your next install attempt or when booting
the new completed install from the "hard disk", try disabling UDMA.
Boot with:

  Boot
  : defbootstr wd.udma=off

I say this because I was trying to figure out how you might be getting
these timeouts, and one code path that looked suspicious had to do with
UDMA.  So it would be interesting to see whether the timeouts go away if
you don't try to use it.  (Unfortunately, I would expect the performance
benefit of emulated UDMA over emulated PIO to be much higher than the
benefit of real UDMA over real PIO... -- you'll take a bad performance
hit for this.)

Second, if you've installed successfully, edit
/etc/conf/pack.d/wd/space.c and reduce wdcmdtime, wdrsttime, wdprmtime,
wdchktime.  Though that's a bit silly -- we should figure out what part
of the hardware emulation isn't meeting the driver's expectations, and
fix one or the other.

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