> 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)
> > 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...
>>>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,
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!
-- Roberto Zini - r.zini<@AT@>strhold.it --------------------------------------------------------------------- "Has anybody around here seen an aircraft carrier?" (Pete "Maverick" Mitchell - Top Gun)
