RE: SCO OS 5.0.7 on Qemu (2nd part)
Rob
[snip]
>
> There's one additional bit of verbosity you can turn on. Boot the
> emulator with:
>
> Boot
> : defbootstr link="invd wd" wd.debug=ui maindebug
>
> You will eventually get a scodb prompt. Enter:
>
> debug> wd_noise=1
> debug> q
>
> Boot now proceeds as normal, but certain "wd" driver messages that are
> normally suppressed will now print.
>
> I suggest you boot a normal physical system this way (use the install
> CD) to see what, if any, extra output this produces on a boot that's
> succeeding. Then do it under Qemu and see if it produces any extra
> failure messages.
Hi Bela.
I'm awfully sorry for this delay in getting back to you but I was
switched to another (more important) task (did I state that I was trying
Qemu for my own amusement at the beginning of this thread? :-)
I followed your directions and booted SCO OS 5.0.7 under Qemu with the
above boot parameters (except for the new "wd" driver which I left -
during this 1st test - out of the picture) and I gave the scodb the
"wd_noise=1" command; here's what I got (manual transcription so more
prone to errors):
WARNING: WD reset controller 0 didn't reset
NOTICE: WD reset error = 01
WARNING: WD reset controller 1 didn't reset
NOTICE: WD reset error = 01
WARNING: hd: no root desk controller was found
hd: a Boot-Time Loadable Driver may be required
NOTICE: wdIssuecmd(1) cmd: A1
Drive 2 Protocol 02, Type 05, Removable Y
DRQ type 02, packet size 00, Serial # [MQ0000 3 ]
Formware Rev = [.0.8]
Model # = []
Next I tried with the new "wd" driver but the above error messages did
not appear any longer; instead, the following (usual) ones did:
wd: PCI bus/dev/func 0/1/1, vend/dev 8086/7010, prog_if 80, BMIBA 0000C001
wd: didn't find any specific known PCI IDE controller, trying by class
wd: PCI bus/dev/func 0/1/1, vend/dev 8086/7010, prog_if 80, BMIBA 0000C001
wd: unknown but possibly usable PCI IDE controller; assuming UDMA 133
wd: if incorrect, add wd.udma=33 (or 66 or 100) to your bootstring.
wd 0/0: IDENTIFY DEVICE: Status 58, Error 00
wd 0/0: non-ATAPI device present
wd: Drive max supported mode = 4, BIOS selected mode = 5
wd: Drive using BIOS selected UDMA mode 5
wd 0/0: Common UDMA Mode 4, Max MBoard mode 6, Max dev supt 4
wd: Possible UDMA timing mismatch, bootstring may be required
wd: add wd.udma=auto for driver attempted auto sense or
wd: wd.udma=off to use Programmed I/O (PIO) instead of UDMA
wd 0/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
wd 1/0: IDENTIFY_DEVICE: Status 41, Error 04
wd 1/0: ATAPI_IDENTIFY: Status 48, Error 00, ATAPI = yes
wd 1/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
%adapter 0x0170-0x177 15 - type=IDE ctlr=secondary dvr=wd
Thanks again for your time!
Best,
Roberto
--
Roberto Zini - r.zini<@AT@>strhold.it
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)
Bela Lubkin
> Bela Lubkin wrote:
>
> [snip]
>
> > There's one additional bit of verbosity you can turn on. Boot the
> > emulator with:
> >
> > Boot
> > : defbootstr link="invd wd" wd.debug=ui maindebug
> >
> > You will eventually get a scodb prompt. Enter:
> >
> > debug> wd_noise=1
> > debug> q
> >
> > Boot now proceeds as normal, but certain "wd" driver messages that are
> > normally suppressed will now print.
> >
> > I suggest you boot a normal physical system this way (use the install
> > CD) to see what, if any, extra output this produces on a boot that's
> > succeeding. Then do it under Qemu and see if it produces any extra
> > failure messages.
> I followed your directions and booted SCO OS 5.0.7 under Qemu with the
> above boot parameters (except for the new "wd" driver which I left -
> during this 1st test - out of the picture) and I gave the scodb the
> "wd_noise=1" command; here's what I got (manual transcription so more
> prone to errors):
>
> WARNING: WD reset controller 0 didn't reset
> NOTICE: WD reset error = 01
> WARNING: WD reset controller 1 didn't reset
> NOTICE: WD reset error = 01
> WARNING: hd: no root desk controller was found
> hd: a Boot-Time Loadable Driver may be required
> NOTICE: wdIssuecmd(1) cmd: A1
> Drive 2 Protocol 02, Type 05, Removable Y
> DRQ type 02, packet size 00, Serial # [MQ0000 3 ]
> Formware Rev = [.0.8]
> Model # = []
We can see that those reset errors don't stop the ATAPI part of the
driver from working. I think they may be the problem for the hard disk
part of the driver.
> Next I tried with the new "wd" driver but the above error messages did
> not appear any longer; instead, the following (usual) ones did:
The latest "wd" driver has a somewhat different initialization order. I
think it actually goes through the code that would show the reset errors
_before_ you get to that first scodb prompt. So you can't turn
"wd_noise" on early enough to see the messages (except by patching the
on-disk image of the kernel you're going to boot).
> wd: PCI bus/dev/func 0/1/1, vend/dev 8086/7010, prog_if 80, BMIBA 0000C001
> wd: didn't find any specific known PCI IDE controller, trying by class
> wd: PCI bus/dev/func 0/1/1, vend/dev 8086/7010, prog_if 80, BMIBA 0000C001
> wd: unknown but possibly usable PCI IDE controller; assuming UDMA 133
> wd: if incorrect, add wd.udma=33 (or 66 or 100) to your bootstring.
> wd 0/0: IDENTIFY DEVICE: Status 58, Error 00
> wd 0/0: non-ATAPI device present
> wd: Drive max supported mode = 4, BIOS selected mode = 5
> wd: Drive using BIOS selected UDMA mode 5
> wd 0/0: Common UDMA Mode 4, Max MBoard mode 6, Max dev supt 4
> wd: Possible UDMA timing mismatch, bootstring may be required
> wd: add wd.udma=auto for driver attempted auto sense or
> wd: wd.udma=off to use Programmed I/O (PIO) instead of UDMA
> wd 0/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
> wd 1/0: IDENTIFY_DEVICE: Status 41, Error 04
> wd 1/0: ATAPI_IDENTIFY: Status 48, Error 00, ATAPI = yes
> wd 1/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
> %adapter 0x0170-0x177 15 - type=IDE ctlr=secondary dvr=wd
So it actually goes through full recognition of everything, but never
acknowledges the hard disk. Not good.
I think this would be trivial to solve with an OSR5 source tree and
build environment, but it's difficult (at best) to do anything with just
object code. Unless you want to get into setting breakpoints and trying
to trace the execution of the initialization code, you should probably
give this up as a bad job...
>Bela<
Rob
Bela,
first of all thank your for your time and your patience.
As I wrote at the beginning of the thread, I was using Qemu to get
acquainted myself with emulators and for my own amusement; I see Qemu
performs quite well with Windows (XP and 2003) and Linux but fails with
SCO OS5/6/UW7.
I think I'll give up on this as well but, since I should have a regular
copy of VmWare around, I'll use it for SCO's OSes.
Thanks and I wish you a pleasant new "life" at VmWare!