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: Sat, 27 Apr 2002 19:37:40 GMT
References: <200204271534.aa00201@xenitec.xenitec.on.ca> 

Carl Sopchak wrote:

> Now that I know why the SEEK "action" is irrevelant, I can remove that
> part.  Is this the same for an ATAPI CD?

I can take this question several ways, and I don't really know the
answer to any of the possible questions...  If you're asking: does
OSR5's "wd" driver require an ATAPI CD to respond to IDE SEEK commands
in order to be recognized; I _think_ the answer is "no".

If you're asking whether any sort of SEEK command for an ATAPI CD would
be irrelevant, I would guess "yes".  The answer to that boils down to
a question: does the device's READ/WRITE command interface specify the
coordinates in those commands?  Both IDE and SCSI READ/WRITE commands
include the coordinates (cyl/head/sec or LBA); I would expect ATAPI to
be the same.  So all a SEEK could do is test media size, and (possibly)
give some performance benefit.  Oh, and possibly set the heads in the
"right" position for a shutdown.

> > > The bochs log file has (does this help?):
> > > 00290159500d[HD   ] IO write to 01f3 = 01
> > > 00290159509d[HD   ] IO write to 01f4 = 00
> > > 00290159518d[HD   ] IO write to 01f5 = 00
> > > 00290159530d[HD   ] IO write to 01f6 = a0
> > > 00290159833d[HD   ] IO write to 01f7 = 70
> > > 00290159833d[HD   ] write cmd 0x70 executed  <== my debug stmt
> > > 00290159833d[HD   ] concat_image_t.lseek(0)
> > > 00290159833d[HD   ] SEEK completed           <== my debug stmt
> > > 00292142586d[HD   ] IO write to 03f6 = 04
> > > 00292142586d[HD   ] hard drive: RESET
> > > 00292143282d[HD   ] IO write to 03f6 = 00
> > > 00292143282d[HD   ] Reset complete {DISK}
> > > 00293833375d[HD   ] 8-bit read from 03f6 = 50 {DISK}
> > > 00293833390d[HD   ] 8-bit read from 01f1 = 01 {DISK}
> > > 00378278000p[XGUI ] >>PANIC<< POWER button turned off.
> > > (the last line is where I hit the virtual "Big Red Switch")
> > 
> > Help me with the log format -- what are the digits and 'd' or 'p' before
> > each entry -- time in microseconds?  What's the letter?  And what does
> > the panic / "I hit the switch" stuff mean?  Do you mean: nothing seemed
> > to be happening, so you gave up and hit reset?
> 
> I believe the number is microseconds.  the letter is (d)ebug, (i)nfo,
> (e)rror, or (p)anic.  After the kernel reports that the hd was not
> found, it shows "press any key to continue".  Since I know the install
> will fail w/o a hd, I press the virtual power button, which causes the
> last panic.

Ok...

> > It might help if the log included the program counter address (EIP) from
> > which each I/O was done.
> 
> Being *very* new to programming bochs (about an hour under my belt), I
> don't know how big of a deal this mught be.  I'll spend a little time
> looking into that...

Good.  I wouldn't expect it to be too difficult -- it obviously has
control at the moment when an I/O is being done, or it wouldn't be able
to print those messages.  (And it wouldn't be able to emulate
hardware...)  All that's needed is to dredge up the EIP.  There's a good
chance it'll already have it in some bochs-specific variable or
structure; if not, it'll be on the stack somewhere that'll be relatively
easy to access.

> > ... OK, if I assume that the numbers are 1uS timestamps, that gives us
> > just under 2 sec between the SEEK and the RESET.  The driver sets a
> > watchdog timer, then issues the SEEK and expects a completion interrupt.
> > The timer is supposed to be 1 second, but I'm sure a bunch of factors
> > could cause it to be off by a factor of 2 in an emulated environment.
> > 
> > So it looks like it's hitting its timeout code because it never got the
> > completion interrupt.  That causes it to see no disk.
> > 
> > You need to go back to the IDE READ implementation from which you
> > derived the SEEK; remove the parts that have anything to do with
> > actually "seeking" since they're irrelevant; add in whatever causes it
> > to generate a virtual completion interrupt.
> 
> The "SEEK completed" message in the log file is written just before I
> call the completion interrupt routine.  Perhaps this is not the right
> SEEK to be looking at??  (Working with other people's code,
> particularly something as complex as this emulation is, can be
> frustrating!)

I think we're making pretty good progress.  It _is_ complex and
difficult, it _will_ take time, but as long as forward progress is made,
I am encouraged.

Can you add a message _after_ you've sent the completion interrupt?

"wd" only does two SEEKs (remember, it's mostly an irrelevant action) --
the one we're working around, to detect drives; and one in its shutdown
code, to "park" the heads.  We can't be hitting the "park" instance
because it wouldn't be doing that unless it thought it had successfully
detected a hard disk...

Looking at wdintr(), the interrupt handler, it looks like you should
have seen several I/O reads in the interrupt routine.  Since those
aren't present, I'm pretty sure it never saw the interrupt.  The
recovery path for not seeing the interrupt involves timing out after 1
second, then sending a RESET to the controller/drive coordinates that
were under test; which is what we see (except it takes 2 seconds).

Also, in this reset code:

> > > 00292142586d[HD   ] IO write to 03f6 = 04
> > > 00292142586d[HD   ] hard drive: RESET
> > > 00292143282d[HD   ] IO write to 03f6 = 00

The corresponding source looks like:

        iooutb(wdcbase[ctlr] + WDSCTRL, 0x04);  /* RESET */
        suspend(300);                           /* 300us */
        iooutb(wdcbase[ctlr] + WDSCTRL, 0x00);  /* re-enable controller */

The time stamps show that the two happened 696us apart, which again
makes me think there's a factor of 2 happening somewhere in bochs'
timing.  (Just a side issue...)

>Bela<
 

Take Control of Your iPhone Apps

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.