Hardware flakiness (Windoze BSOD)

1. You should repost in one of the SCSI forums/groups. Try 'comp.periphs.scsi' for a starting point.
2. Can the home-made cable. These are available commercially and are wired properly and will work correctly. SCSI is not the place to cobble a cable together, it is just too sensitive.
3. No terminator? Crap, no wonder it doesn't work. You need to learn the rules for SCSI and follow them exactly.
4. Win 2K does fine with SCSI. It is your cables, card or device.

That this thing works at all is amazing.

What's the hex number reported on the blue screen. And terminate the chain. Lots of bsods are driver oriented IRQ_DOES_NOT_EQUAL stuff accompanied by a hex cod and the culprit modules.

I used to run SCSI under W2K, using an Adaptec card, on an ASUS P4T board. Never had any problems.

If you want to buy the cable I had made for my scanner (it's a long custom model made by a Redmond cable company), let me know.

(sigh) SayNoMore. SCSI cables need to have controlled impedances. Even at ASYNC speeds, you can get all sorts of reflections that can cause havoc.

And you know it works at DC, right. How do you know it works "at speed"?

I have *7* SCSI busses in my W2K box. I don't see SCSI errors

Yeah, and if you have sex without a condom your lady friend probably

Do you put 66MHz memory on your 133MHz bus? Do you run with your 5V power supply at 4.4V? Do you overclock your CPU?

(sigh) If you want things to work as they are designed to work, then *use* them as they were designed to be used!

SCSI cables can be incredibly finicky. The Standard even describes

Upgrade to SP4. While you can still find it on MS's website.

If there are "BIOS settings" (like the 1542's SCSIselect) try setting the adapter to run ALL targets in ASYNC mode. But, fix the cable and terminator!

Look for bad caps.

On 11/3/2009 6:02 AM Meat Plow spake thus:

Dunno the hex code (maybe I'll write it down next time it happens), but you nailed the error message. Actually, I think the last time it was something like IRQ_LESS_OR EQUAL, but in any case an IRQ level error.

To answer some replies upstream, I don't give enough of a s*it about this to invest anything in a good cable, but thanks for offering. I went for the zero-cost solution, and like I said, it works most of the time. Last night I scanned more than a dozen photos w/no problems.

On 11/3/2009 8:43 AM D Yuniskis spake thus:

Yes, I know all that. I simply wanted to see how far I could tempt the angry SCSI gods.

If you read my post again, you'll see that I've been successful using this cobbled-together cable. Last night I scanned more than a dozen photos with no problems. So I know it works "at speed". (Most of the time, anyhow, with this device.)

The BSOD problem only rears its ugly head occasionally. I know how to solve it (unplug the damn offending cable). I'm simply curious as to why this happens. (Makes this kind of an N. Cook postmortem analysis.)

Isn't the Snapscan internally terminated ? ie only has a single 25 pin data socket.

On 11/3/2009 2:20 PM Baron spake thus:

Nope; it has 2 sockets, and no termination switches that I can see, so I'm ASSuming it's unterminated. (Most SCSI devices like this have two sockets for daisy-chaining.)

With the cable as short as possible and no other devices, that can work acceptably (FSVO "acceptably"). Anything more than a terminated controller at the other end and all bets are off. Add a terminator, preferably active, and it might even be trustworthy.

On 11/3/2009 5:12 PM Warren Block spake thus:

Yes. Pretty sure the Advansys is auto-terminating.

The thing I was *really* hoping to discover--and it may be my fault for not having been more clear in my original message--is why the Blue Screen of Death, even assuming some sort of SCSI error due to my cobbled-up cable? I mean, shouldn't the OS be able to handle a SCSI error without abandoning ship? That's what I meant by "piss-poor SCSI handing". I can't imagine, for example, that a Sun workstation would be brought to its knees by a bad SCSI cable.

I'm just wondering what's going on there in driver-land, or HAL-land, or wherever the problem may be.

You're assuming a driver will behave when the hardware doesn't. If the hardware tugs on the IRQ line at 50KHz, what should the driver do? Should it be encumbered with enough smarts to

Tie the IRQ from your IDE drive to a 50KHz signal and see how

I wouldn't be expecting hardened drivers in an OS (like Windows) that freely allows third parties to write drivers, design hardware, etc.

Agreed, on all the above. The OP needs a commercial cable, & should enable the terminator on one of the drives & put it on the end of the cable. He should also make sure that termination is disabled on the scanner & the other drive.

Which device is one the end of the cable? Whichever it is, it needs to be terminated, & *every* other device *must* be unterminated. If you fail to do that, you will get unreliable operation. (If you've done all that, the traditional trouble-shooting technique is to sacrifice a goat to the SCSI gods. ;^)

The SCSI gods are touchy, & quick to anger.

Simple: You're getting noise on your handshaking lines that's hammering the SCSI I/F, then the OS, which then pukes on it's shoes. Fix the termination & the problem should go away.

Not always. I've seen (and owned) a number of SCSI peripherals hooked to older Macs with no terminators and no problems. Strings up to three or four units long, hot switching power to devices as needed, no problems. Period.

In one case, I had such a setup that worked perfectly for years under OS

I'd guess that if a particular setup works most of the time, the problem is more likely to be software than hardware. Check for better drivers.

Isaac

How old were the Macs? Were they using (ancient) 5380 SCSI HBA's?

My first Windows machines were NT3.5/NT4 servers and workstations and used SCSI peripherals. I dealt for several years with SCSI chains, RAID controllers up to 20 individual discs in Sun servers. Then came faster IDE drives running in UDMA5 and now UDMA6 SATA/II. So I have an extensive background adminstrating equipment that at the time was only available with SCSI disks, tape, etc....

Your LESS_OR_EQUAL and depending on the hex string is more likely a driver stomping on memory space allocated by another program/driver running in the background.

Don't know. Most of the scanners I've owned had a chain port where a terminator would be installed if its the last device.

David Nebenzahl Inscribed thus:

Yes that is what I would go on. Single socket for self terminated and two sockets if un-terminated.