Highway USB causing some major Bootup Problems

[DegeRandolf]

Installed a Highway USB in my A4000.  Now when it boots, the power led flashes and it reboots itself once, sometimes twice.  About every 3rd or 4th time I'll get a software failure.  I clear that and it finally boots up.

I commented out any additions to the startup-sequence and user-startup so no software is running.  I get the same result.

Any thoughts?

[DegeRandolf]

Now that you mention it, I haven't been feeling to well!  I told my doctor that too!  Actually, that's a good idea.  I'll give them a shout.  I bought the board on ebay and it works great once I'm up and running, just trying to figure out this reboot thing.

[DegeRandolf]

Makes sense.  I have three cards installed.  From bottom to top Picasso IV, highway, xsurfer II.

I did have the highway in the slot above the xsurfer board and swapped them for troubleshooting prior to posting the original message.  No change.  These two cards might not co-exist well together maybe?  I will pull the xsurfer and see if the Highway still causes the problem.

[DegeRandolf]

Thanks for all the input.  Here is what I have been able discover.

It doesn't matter which order I place the cards in the result is the same.  However I booted up without the startup-sequence and no failure.  There are no calls in the startup-sequence to the highway card at all.  I then tried removing all cards but the PIV and still have the same bootup problem.  This leads me to believe one of two things may be occurring.
1.  setpatch is causing the problem for some reason or;

2.  During installation an older 68040 library or something was loaded.  I have a Cyberstorm MkII 060 board installed.

I'll start checking version numbers of the libs first as that I can do something about.  If it's the former problem, I'm at a lose as to which way to tackle that.  I can't do the noscsiupdate option as I have 10 gig harddrive which isn't recognized fully by the boot rom without the patch, nor is my CDROM.

Am I right in assuming that if I don't get the boot failure problem when not using a startup-sequence that I'm looking at a software issue and not hardware?

[DegeRandolf]

Update:

All libs appear to be current.  If I comment out setpatch, the system boots normally except of course for not finding anything but my first partion nor my cdrom.  That part was expected.  This then makes me think something in the setpatch is causing the bootup problems.  I have version 44.38 of setpatch.  Any thoughts on that bit of information?

[DegeRandolf]

The 68040.library I have is actually a dummy library pointing to the 68060.library.  They appear to be the same versions as the ones I loaded from disk.  Besides, I am getting a normal boot (with the problems listed before obviously) when I comment out the setpatch.  The reason I assumed it was the highway usb is the problem started as soon as I installed the software.  Looking at the install though, I don't see anything but classes and a couple of device types.  One lib for poseidon.  Oh, and the usbhighway device and input.device.  I wonder if they might be the problem?  Here's an interesting part of the puzzle as well.  I see my cdrom struggling on startup now.  The power led flashes 3 times, the cdrom tries to spin up, led flashes again, cdrom tries to spin up etc.  Finally a guru  comes up.  I click the mouse and it finally boots up.  Sometimes it will just sit and not do anything.  Other times it will load normally.  And then sometimes when it finally comes up, it has df1, df2 and df3 icons with the behind them.  As if the floppy.device had failed.  Something is definitely not right here

If I just boot with a floppy disk, NONE of this happens.  It boots normally.  I just thought of something, I'll try to boot with the os39 emergency disk when I get home and see if that boots correctly or not.

 

[DegeRandolf]

The problem is solved, sort of.  I inserted the key WAITFOREVALIDATE with setpatch and it boots up normally.  A tiny bit slower to boot than before but not bad. Not sure why it works, but it does.