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: Tue, 30 Apr 2002 01:55:54 GMT
References: <200204271534.aa00201@xenitec.xenitec.on.ca> <20020427123740.A15678@mammoth.ca.caldera.com> <c12f3009.0204291043.64d46546@posting.google.com> 

Carl Sopchak wrote:

> I got past the "no root hd".  It appears that OSR is writing 0x08 to
> the Device Control Register (0x03f6), which should be enabling
> interrupts on the hd.  The emulated controller was not enabling them
> on both devices, so the subsequent SEEK was not triggering the
> interrupt, which caused OSR not to see the disk.  Here's part of the
> log:
> 
> 00249399529d[HD   ] IO write to 03f6 = 08
> 00249399529d[HD   ] s[0].controller.control.disable_irq = 02   <== hd DISABLED
> 00249399529d[HD   ] s[1].controller.control.disable_irq = 00   <== CD Enabled
> 00249712652d[HD   ] IO write to 01f3 = 01
> 00249712661d[HD   ] IO write to 01f4 = 00
> 00249712670d[HD   ] IO write to 01f5 = 00
> 00249712682d[HD   ] IO write to 01f6 = a0
> 00249712985d[HD   ] IO write to 01f7 = 70
> 00249712985d[HD   ] write cmd 0x70 executed, EIP=f00138d2
> 00249712985d[HD   ] s[0].controller.control.disable_irq = 02
> 00249712985d[HD   ] s[1].controller.control.disable_irq = 00
> 00249712985d[HD   ] SEEK completed.  error_register = 04
> 00249712985d[HD   ] raise_interrupt called, disable_irq = 02
> 00249712985d[HD   ] Not raising interrupt                      <== not seeing hd
> 00249712985d[HD   ] SEEK interrupt completed
> 
> I changed the code to set both devices' disable_irq based on the value
> written to 03f6.  Bela, do you know if this is the correct behaviour? 

No, and I'm having trouble matching the above actions up to code in the
driver.  This is where I really need the EIP addresses for every action:
if I have all the addresses, I can figure out which parts of the code
correspond to some of the more unique, obvious actions; and from that I
can figure out where all of the actions are coming from.

It would also help to have seen some of the log above the "IO write to
03f6" part.

> (BTW, the prior hd command issued was looking at device 1 [cd], so the
> program was only setting disable_irq for that one device...)
> 
> Oh, yeah, you may have noticed that I found the value of EIP...  (Does
> it look reasonable?)  I can throw it into any debugging statements
> that you'd like it in in the future...  I also fignred out the timing
> issue (the "factor of 2" thing):  There's a bochs configuration
> parameter for # instructions per second to emulate.  It had to be
> tweeked (from 2,000,000 to 700,000).  With the new value, the logs
> showed exactly 300us between the seek attempt and the reset (in a
> version that failed to see the hd)...

Ok, good...

> As far as I know, that clears up ALL of the PRIOR issues!!  Yippie!
> 
> Unfortunately, [I bet you guessed I'd say that <grin>] the install
> only went on a few more screens before bochs panic'ed.  After telling
> the install program to install from CD, I got the bochs error "start
> disc not implemented" (for ATAPI command 0x1b).  I'll look into seeing
> what needs to be done for this, but from the comment in the program,
> it may be a bit more complex than prior issues.  (But then again,
> maybe not.  I'm winging it here!)  Bela, can you give me some insight
> as to what the install program is trying to do here, what it expects
> from the machine, etc.?

I replied to this earlier.

I get the impression from the "wd" driver code that exactly what is
supposed to happen after a write to port 3F6 varies according to what
other I/O has been happening recently -- like that port is supposed to
access several different registers, or something like that.  I'm not
looking at an IDE/ATAPI hardware spec while poking through the code, and
it's pretty bewildering...

>Bela<
 

Buy Take Control of Your Domain Names

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.