SCSI Wizard needed!

[sevendeo]

K8V SE Deluxe
AMD 64-3200 processor
RAM - 2x512

DC-390U3W SCSI not detected

Hi, I'm needing some help with a really weird problem:

I'm "revamping" a sound post-production workstation built around a K8V SE Deluxe mobo.
My project is to speed it up using a bunch of U160 SCSI HDD I have and a Tekram DC-390U3W controller.

The system was working fine with IDE HDD's.

The problem is that the SCSI controller isn't detected by the system during POST (SCSI controller BIOS won't even load!) and so it isn't listed in the boot devices list... and so I can't boot from it!

The controller is OK, since I tested it on another system.

The mobo is stated to be PCI2.2 compliant so it accepts 3.3V or 5V cards (I jumpered the controller card to 33MHz mode, if I didn't screw up since there are several versions according to which manual you look...)
I plugged a Intel SCRU32 (SCSI U160 RAID card) and the mobo detects it...

I tried to plug it on every slot but still nothing (had once a problem with a SCSI card that only worked fine on the first PCI slot...)

Cleared the BIOS... nothing... (still have to update the BIOS but we hadn't a floppy at the office LOLOL! so I'll take one from home...)

I tried every combination but maybe I missed some option on the BIOS...

Anybody out there has an idea???

THX in advance

 

[ddrueding]

Is the card detected in the OS after you boot to an IDE drive?

 

[Will Rickards]

Does the board have an onboard addon IDE controller chip with it's own bios? That might be taking priority or something. Try disabling the IDE controller you aren't using in the bios.

 

[Handruin]

Did you try the card without and cables or devices attached? I vaguely remember having this problem with my 390U3W many years ago but that info has since been lost in the SR database crash.

 

[P5-133XL]

I would argue that this isn't a SCSI issue: The card isn't getting that far, if it can't be detected by the MB during POST. I assume, that it isn't being listed with all the devices on the boot-up screen and that any setup message from the SCSI card does not get displayed, so it is a port, Memory address, IRQ, DMA conflict, either with the MB or a card. If my assumption is false, then you need to specify exactly what you mean by it isn't detected by the MB during POST.

My first suggestion, is simply switch MB slots. In theory, cards and slots are supposed to play nice and share. However, it hasn't always been true and how MB's are supposed to allocate IRQ's are by which slot they are in. So switch the slot and you can change its IRQ.

For your MB, Slot 1 shares its IRQ with the AGP; Slot 2 shares with the Lan, and the onboard RAID; Slot 3 shares with the onboard audio and USB; Slot 4 doesn't share. So given a choice, I would put the card in slot 4. Slot 4 is the farthest from the AGP slot.

Next, I would check the CMOS setup for any peculiarly set PCI settings. Things like latency, or bus speed can prevent a card from being detected. Startup by setting all the CMOS settings to their default. Absolutely No overclocking alowed, at least for now.

I don't know what other cards, are in the machine, but removing them may remove the conflict. Also, disabling all internal MB devices would be reasonable until you can identify the specific conflict. With everything removed and disabled, does the machine detect your SCSI card?

 

[Bozo]

In some MB BIOSs there is a setting to allow add-in cards to display their BIOSs/settings. Is this enabled?

Bozo :joker:

 

[Chewy509]

In some MB BIOSs there is a setting to allow add-in cards to display their BIOSs/settings. Is this enabled?

Don't forget to enable "Hook int19" (or sometimes it's called "Hook 13h").

INT13h is used by the BIOS to detect and work with available drives. If you disable hooking of int13h, SCSI cards are not able to install their BIOS, and thus won't work.

 

[sevendeo]

First of all, thanks for your replies,
Second, thanks for your replies because paying attention to the details can make you always learn something!

Due to the time difference... I get your replies with some delay and eventually I reply while you're sleeping

This morning I read your posts and started all over again and I ended up with a SCSI (no)problem, this is how it goes:

Is the card detected in the OS after you boot to an IDE drive?

I hadn't tried that one but strangely the card is detected by OS, so even if I hadn't access to the card BIOS, it was detected at an hardware level.

disabling all internal MB devices would be reasonable until you can identify the specific conflict

I disabled all onboard devices, all but one... (I forgot the onboard LAN! Dumb me!!) and as soon as I disabled the LAN... voilá! the card shows up!
In the end it was a BIOS problem because since I updated it to the most recent version I can have the LAN on.

BTW, thanks P5-133XL for your checklist... I had done the testing "by the book" but with your post I managed to check I didn't forget nothing

What I meant earlier when I said the controller didn't showed up is that I should see it booting and be able to access it's BIOS...
Being able (now) to access the controller BIOS I still have a problem (that's why I started saying it ended up being a (no)problem...

The intended workstation setup is:

DC-390U3W (finally up and going)
1x36Gb HDD - for OS, sound editing software and a local sound library (the main library is in a file server)
1x18Gb HDD - for swap, OS temp files and sound software project files
Intel SAF-TE enclosure with 5x18Gb HDD - sound editing software temp files and renders
no IDE HDD, just a DVD burner

This setup allows me to upgrade the HDD's that are in the enclosure in a easy way according to the availability of larger HDD's.

The problem is that I should be able to choose which is the boot drive I want in the device menu of the controller BIOS menu... (I remember that I had this problem when I first used this controller for the first time (almost 10 years ago... and it has been sitting on a shelf for long...)
As requested by the manual, I did set the adapter/channel in which the HDD's are, as boot order 0 (in the controller's boot menu) but the fact is that in the MB BIOS, instead of having the controller as a boot choice I have one of the HDD's connected to the controller (the 0 ID HDD or the next if the 0 ID is missing)... and this is the real issue:

If I use the 0 ID HDD in the enclosure for the system I end up with 4 upgradeable disks (minus one that I should have)

Of course to solve this issue in a practical manner and because we need the workstation operational, I did installed the OS in the 0 ID drive... 'cause in the end I won't have in the next few days a bunch of 5 36 or 73 Gigs HDD...
The bottom line is that since I'm curious (and a bit stubborn by nature) I'm trying to find an answer to this problem!

Cheers to all!

 

[blakerwry]

I'm not sure I understand the current problem...


Typically you'd set your motherboard to boot SCSI or boot SCSI ID 0, your scsi controller would be set to boot ID 0, and your boot drive (or backplane position if you are using 80pin drives) would also be set to 0.

This sounds like what you've done... and it sounds like it's working for you... so what's the problem? Are you trying to multiboot? if so, maybe using a bootloader will work better for you.

 

[sevendeo]

Ok, I was long but not necessarily clear...

Fact - The SAF-TE enclosure (backplane) sets automatically the HDD ID from 0 to 4 plus 6 to itself
Fact - The ID of the other HDD on the chain are set by jumper to an ID other than 0...4, 6 or 7
Fact - The controller BIOS can set which is the boot driver (it can be other than 0)

Fact - "usually" (and I say usually since it's what I always saw until now), if your controller is detected by your system BIOS (the motherboard), "usually" you have the choice of the boot devices like floppy, 1st HDD, yada yada and SCSI DEVICE.
Fact - in this case, when you choose the SCSI device, the system will boot from the drive you've chosen in the controller BIOS (eventually not the ID0)

What's happening now:

1. Instead of having SCSI DEVICE as boot choice I have always the HDD ID 0 (or another if I unplug the HDD ID 0)
2. In the controller BIOS I'm not able to chose which drive I want to be the boot drive...

Question:
Is there a workaround? Something I missed?
Does it have to do with the centralized BIOS Boot Services (BBS) that Modern system BIOS provides?
Is there another reason?

 

[blakerwry]

This sounds like the perceived problem: "In the controller BIOS I'm not able to chose which drive I want to be the boot drive..." because ..."Instead of having SCSI DEVICE as boot choice I have always the HDD ID 0"

My question is why would you want to boot to anything other than SCSI ID 0?

Understanding the reasons behind what you are trying to accomplish will allow others to suggest better solutions to a given problem.

 

[blakerwry]

Also, does your motherboard BIOS simply state HDD-0, or does it specifically state SCSI. Lots of BIOSes equate HDD-0 with IDE primary master.

If it doesn't state SCSI specifically or mention your drives by make/model, I'd assume it isn't referring to your add-in scsi card.

 

[sevendeo]

As I stated earlier when I described the intended config, I want to boot from an internal drive, leaving the five HDD in the backplane available to an upgrade.

The system BIOS doesn't state HDD-0 but identifies the the actual physical HDD and it's SCSI ID (make/model/ID).
As said, if you remove the ID 0 drive you'll find in it's place the next drive (following the SCSI device priority)

 

[blakerwry]

Can you set your enclosure/backplane to use higher SCSI ID's, leaving the low IDs free for the internal drives?

Does putting the internal drives on one channel and the external drives on a different channel allow you to select the internal drives as boot drives(google listed this SCSI card as possibly having 2 channels)


Does your motherboard BIOS have a 'Boot other' or 'Try other devices' boot option?

 

[P5-133XL]

Your SCSI controller is dual-channel. Correct? If so, may I suggest that you put the enclosure on the second channel (LUN 1) and the internal HD that you want to boot from on the first channel (LUN 0). That way, the internal HD can have a SCSI ID of 0 (LUN 0) and the enclosure can also have also SCSI ID of 0 (LUN 1). Your motherboard will no doubtably prefer booting off LUN 0 or your internal SCSI drive.

The only negative that I can think of is the requirement that you get a second terminator.

 

[blakerwry]

Also, most backplanes are either jumpered or hard wired with an ID for each slot... On those that are hard wired, leaving the first slot blank will free up ID 0 in most cases.

I've never heard of one that automatically detects the drives and then sets the ID's accordingly, starting at 0.

 

[blakerwry]

You and I are on the same page with that one Mark. However, I know some controllers stick two connectors on the same channel.

Not knowing if the enclosure uses an internal or external connection, it's hard to know if doing what you describe is possible. ie: enclosure is external... controller's external port is on channel 0, while one internal port is also on channel 0 and the other is on channel 1.

... actually... The manual for this adapter confirms that the external connector and the internal connector closest to it are both on channel A... LUN0. So if the enclosure is external, this solution would not be an option with the current hardware configuration.

 

[sevendeo]

Since the enclosure is "intelligent", "she" decides to use the ID 0 to 4 plus 6. There's nothing I can do about it (yes I have another enclosure where you can set the ID by DIP switch, it's not the case...).
What I managed to find out a few year ago when I bought it it's that if you use it in an intel server you can connect at least two of them toghether with the server board and they'll talk through with the SCSI controller what ID's to set.
BTW, SAF-TE stands for SCSI Accessed Fault Tolerant Enclosure, in this case using an embedded controller card (PBA A42862-110) and used in the Intel Server Chassis SC5200 products.

Then another thing, if you check the 390U3W specs, you'll see it's dual channel BUT, one is LVD and the other is SE so... since I'm running U160 drives I have to connect them all to the LVD channel as you may understand...
It's correct that channel A (which is the LVD) has an internal and an external connector but it doesn't change nothing connecting the enclosure to one or another... it still gives the same ID's.

You suggest to leave the slot where the ID 0 will be blank I'll have the ID 0 free... but what's the point? Since you should be able to decide from which HDD to boot, the purpose would be to boot with an internal drive and leave the ones in the enclosure free for an eventual upgrade... so if you leave the slot blank, yes you can boot from an internal drive with ID 0 but then you have a free slot... so what's the point?

The options on the system BIOS are only those stated and even if there's a list of the connected drives (where I can see all drives - make/model/ID) in the boot selection I have only the one connected to the highest priority SCSI ID (as I stated above)

 

[blakerwry]

You suggest to leave the slot where the ID 0 will be blank I'll have the ID 0 free... but what's the point? Since you should be able to decide from which HDD to boot, the purpose would be to boot with an internal drive and leave the ones in the enclosure free for an eventual upgrade... so if you leave the slot blank, yes you can boot from an internal drive with ID 0 but then you have a free slot... so what's the point?

I was trying to offer an option within the current listed hardware configuration. However, if this is option not amenable then perhaps you could purchase a second SCSI controller to get the second LVD scsi channel you'd need to fully utilize both the internal drives and the drives/enclosure.

The downside of this is that a SCSI card will likely cost ~ $50 + any additional cabling