Welcome to Vogons 😀

More details of your overall setup might help determine the problem...

...what devices do you have connected to the SCSI bus - I'm assuming possibly just a single SCSI boot drive.

...are you certain you have both the SCSI device IDs & termination set correctly for your setup.

...do you have other devices connected to IDE, and if so have you tried a SCSI boot without those.

...what BIOS version are you running (although I don't see anything related to SCSI issues online)

PC Hoarder Patrol wrote on 2021-08-29, 00:21:

Welcome to Vogons 😀

More details of your overall setup might help determine the problem...

Sorry about that. I should know better.

I kept the setup very bare. Just a P3 700 cpu, a stick of RAM with 256MB and a graphics card. The harddrive is a Maxtor Atlas 137GB which may be too large for the onboard controller. At some point I tried a PCI SCSI controller as well that I know supports the disk. An adaptec 19160.

And I connected a floppy drive and an IDE CD-ROM.

...what devices do you have connected to the SCSI bus - I'm assuming possibly just a single SCSI boot drive.

Yes, just a single boot drive.

...are you certain you have both the SCSI device IDs & termination set correctly for your setup.

As default as it can get. Controller at 7 and boot drive at 0. Also the bios of the controller is set to boot from device 0. Termination is done.

...do you have other devices connected to IDE, and if so have you tried a SCSI boot without those.

Only an IDE CD-ROM for the installation media. After installation I tested if disabling the IDE controller would help but that didn’t make any difference. And it shouldn’t. On my AX6BC the same setup and devices fly and there is no wait.

...what BIOS version are you running (although I don't see anything related to SCSI issues online)

I looked into that and it is running the latest version that was released by Aopen.

As briefly mentioned I did a test with an AX6BC as well and then I don’t have the issue. Test was with the exact same setup.

To be clear, the setup does boot eventually and when it does it behaves normally. The only issue is the wait time before it initiates the boot.

I'm probably wrong here but could it have something to do with suboptimal Coppermine compatibility on this board?

Well, I suppose I could test with a P3 450 but if this is the problem then shouldn’t I have more performance issues as well?

Sounds crazy but I'm thinking for whatever reason it doesn't like the hard drive. Maybe too big idk. Maybe you have resource conflicts. Does it hang when the IDE and floppy cables are disconnected?

Suppose it could be a cpu issue...

Version R2.35 - "No longer shows 'B' or 'E' for Katmai/Cuppermine CPU frequency over 600MHz"

The fact that it 'works' eventually (are you getting expected full speed / capacity from the Atlas?) still might suggest some odd negotiation problem between the AIC7880 and the drive (speed or termination?)

I do see this note appear in both the SCSI Device & SCSI OS Installation Compatibility Test Reports for the board...

"Special Note :

On board Adaptec SCSI AIC7880 UW chip(version B) is not so smart as 2940UW Adapter SCSI card AIC7880 UW chip (version A). When we install multi hard drives and setup terminator must match standard configuration because scsi bios can not auto detect all hard terminator."

If the onboard controller is a little bit odd, then why do I still have the issue with the 19160 controller? That one works great on the AX6BC that have, but it waits on my AX6B+

I will test with a Katmai cpu to see if it makes a difference.

The onboard controller doesn’t play nice with the disk for sure, but the 19160 should fly and it just doesn’t.

It makes no sense. Still, it’s a computer so there must be a logical reason for this behaviour.

Don't you have a normal IDE hard drive just to test with. If it boots with a normal HDD than its not a CPU issue. It would take a lot of the guessing out of the equation also. That would of been the very 1st thing I ever did. Then I can say for sure its only related to scsi not anything else not cpu, not motherboard.

mandm_nl wrote on 2021-08-29, 08:32:

Well, I suppose I could test with a P3 450 but if this is the problem then shouldn’t I have more performance issues as well?

I'm not really convinced either but if you have a Klamath PIII or earlier you can rule out a compatibility issue. Sometimes there's something weird in BIOS code that only affects a certain combination of hardware. Again, not too convinced but it was my first idea to start troubleshooting.
That being said, what boot options do you have configured? Is it possible the BIOS is trying to boot off another device that isn't present for a long time before eventually giving up and choosing SCSI?
Or is it possible the SCSI controllers both expect some sort of RAID to boot off for some reason before eventually giving up and booting a single drive?

check SCSI Termination and may replace the cable

Doornkaat wrote on 2021-08-29, 12:38:

I'm not really convinced either but if you have a Klamath PIII or earlier you can rule out a compatibility issue. Sometimes ther […]
Show full quote

mandm_nl wrote on 2021-08-29, 08:32:

Well, I suppose I could test with a P3 450 but if this is the problem then shouldn’t I have more performance issues as well?

I'm not really convinced either but if you have a Klamath PIII or earlier you can rule out a compatibility issue. Sometimes there's something weird in BIOS code that only affects a certain combination of hardware. Again, not too convinced but it was my first idea to start troubleshooting.
That being said, what boot options do you have configured? Is it possible the BIOS is trying to boot off another device that isn't present for a long time before eventually giving up and choosing SCSI?
Or is it possible the SCSI controllers both expect some sort of RAID to boot off for some reason before eventually giving up and booting a single drive?

Well I tested with a Klamath and the wait was gone. That moment I thought “ok, didn’t really expect that, let’s switch back to the 700” and now there the wait is also gone. So the plot thickens.

The OS that is on the disk was installed when I was using the AX6BC though and with thát board I had to provide the drivers during the Win2k installation at the F6 step. So just maybe it has to do with that procedure.

On the AX6B+ I didn’t need drivers for some reason. The disks were available in the installer anyway. On the AX6BC however it didn’t work that way. Without the drivers the installer wouldn’t detect any disk.

This result is with the 19160 controller and not the onboard. The onboard is now disabled.

So later tonight I’m going to perform more tests focussing on the onboard controller. Maybe the wait is coming specifically from there.

I will update with my findings!

Update:
I have narrowed it down to the combination of the onboard controller, the cable with terminator and the drive.

As soon as I connect the drive the wait time is back. So it must be something in the negotiation I guess. Sadly I don’t have a different drive or cable at the moment so I can’t test any further.

I will see if I can find other drives and cables to check if those work better.

Ok I solved the issue with some help. The problem was in the termination. My cable has a LVD/SE termination at the end and the controller was set to terminate as well. This conflicted resulting in the long wait. By disabling the host termination the issue was solved.

Cool! Thanks for the update/conclusion! 😃👍