So I made up a SCSI cable for the scanner I got off the street
(literally), an Agfa SnapScan 1236. (Had to cobble up the cable since my
SCSI host adapter has a high-density socket but the scanner has the old
25-pin socket.) The cable's a bit ugly, with something of a rat's nest
of wires soldered together in the middle, but it works. Scanner works fine.

But since using the scanner, I've found that sometimes--not always--the
scanner seems to be causing a hardware fault that causes Windows blue
screens. Sometimes I can boot up and do dozens of scans; other times the
BSOD appears some time after booting, or when I access the scanner driver.

At first I wasn't sure whether the blue screens were due to the scanner
itself or the scanner driver, but I'm pretty sure it's the former, as I
never get them when I unplug the scanner.

I'm sure part of the problem can be traced to Windows 2000's rather
****-poor SCSI handling. While it is definitely better than Windows NT,
which *really* sucked in that way, it's still problematic.

And the fact that I don't have a terminator on the scanner might not be
helping, either. But as I said, when it works I can do many scans with
no problems.

I should say that this isn't a critical problem for me. I have another
scanner that works about as well (a Microtek using USB) that works about
as well; the Agfa just happens to be a bit faster and not as annoyingly
noisy. I'm mainly curious why I'm having these problems.

Any guesses? (Educated ones get more points.)

Oh, almost forgot:

o OS: Windows 2000, SP 2
o Advansys SCSI host adapter ("fast/wide"), but I'm using regular old
single-ended SCSI II. The Advansys is basically a clone of the old
Adaptec 1542, but with two adapters (16 SCSI IDs) on one card. There are
two CD-ROM drives (Plextor) on the same bus as the scanner.
o Motherboard is an Asus something-or-other, almost 10 years old


--
Who needs a junta or a dictatorship when you have a Congress
blowing Wall Street, using the media as a condom?

- harvested from Usenet

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

So I made up a SCSI cable for the scanner I got off the street
(literally), an Agfa SnapScan 1236. (Had to cobble up the cable since my
SCSI host adapter has a high-density socket but the scanner has the old
25-pin socket.) The cable's a bit ugly, with something of a rat's nest
of wires soldered together in the middle, but it works. Scanner works fine.

But since using the scanner, I've found that sometimes--not always--the
scanner seems to be causing a hardware fault that causes Windows blue
screens. Sometimes I can boot up and do dozens of scans; other times the
BSOD appears some time after booting, or when I access the scanner driver.

At first I wasn't sure whether the blue screens were due to the scanner
itself or the scanner driver, but I'm pretty sure it's the former, as I
never get them when I unplug the scanner.

I'm sure part of the problem can be traced to Windows 2000's rather
****-poor SCSI handling. While it is definitely better than Windows NT,
which *really* sucked in that way, it's still problematic.

And the fact that I don't have a terminator on the scanner might not be
helping, either. But as I said, when it works I can do many scans with
no problems.

I should say that this isn't a critical problem for me. I have another
scanner that works about as well (a Microtek using USB) that works about
as well; the Agfa just happens to be a bit faster and not as annoyingly
noisy. I'm mainly curious why I'm having these problems.

Any guesses? (Educated ones get more points.)

Oh, almost forgot:

o OS: Windows 2000, SP 2
o Advansys SCSI host adapter ("fast/wide"), but I'm using regular old
single-ended SCSI II. The Advansys is basically a clone of the old
Adaptec 1542, but with two adapters (16 SCSI IDs) on one card. There are
two CD-ROM drives (Plextor) on the same bus as the scanner.
o Motherboard is an Asus something-or-other, almost 10 years old


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.

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.

David Nebenzahl wrote:
So I made up a SCSI cable for the scanner I got off the street

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

(literally), an Agfa SnapScan 1236. (Had to cobble up the cable since my
SCSI host adapter has a high-density socket but the scanner has the old
25-pin socket.) The cable's a bit ugly, with something of a rat's nest
of wires soldered together in the middle, but it works. Scanner works fine.

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

But since using the scanner, I've found that sometimes--not always--the
scanner seems to be causing a hardware fault that causes Windows blue
screens. Sometimes I can boot up and do dozens of scans; other times the
BSOD appears some time after booting, or when I access the scanner driver.

At first I wasn't sure whether the blue screens were due to the scanner
itself or the scanner driver, but I'm pretty sure it's the former, as I
never get them when I unplug the scanner.

I'm sure part of the problem can be traced to Windows 2000's rather
****-poor SCSI handling. While it is definitely better than Windows NT,
which *really* sucked in that way, it's still problematic.

I have *7* SCSI busses in my W2K box. I don't see SCSI errors
*or* hangs. I'm currently running W2KS SP4 but have run W2K SP4
in the past with comparable performance.

And the fact that I don't have a terminator on the scanner might not be
helping, either. But as I said, when it works I can do many scans with
no problems.

Yeah, and if you have sex without a condom your lady friend probably
*won't* get pregnant -- MOST of the time. :-/

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
*where* certain signals should be located *within* the cable
itself for optimum performance. I don't think this is a case
of picking nits just because there was nothing on TV that
afternoon... (i.e., if they went to this length to codify the
standard's requirements, there is a bonfide reason for doing so!)

I should say that this isn't a critical problem for me. I have another
scanner that works about as well (a Microtek using USB) that works about
as well; the Agfa just happens to be a bit faster and not as annoyingly
noisy. I'm mainly curious why I'm having these problems.

Any guesses? (Educated ones get more points.)

Oh, almost forgot:

o OS: Windows 2000, SP 2

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

o Advansys SCSI host adapter ("fast/wide"), but I'm using regular old
single-ended SCSI II. The Advansys is basically a clone of the old
Adaptec 1542, but with two adapters (16 SCSI IDs) on one card. There are
two CD-ROM drives (Plextor) on the same bus as the scanner.

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!

o Motherboard is an Asus something-or-other, almost 10 years old

Look for bad caps.

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

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.

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 **** 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.


--
Who needs a junta or a dictatorship when you have a Congress
blowing Wall Street, using the media as a condom?

- harvested from Usenet

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

David Nebenzahl wrote:

So I made up a SCSI cable for the scanner I got off the street

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

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

(literally), an Agfa SnapScan 1236. (Had to cobble up the cable since my
SCSI host adapter has a high-density socket but the scanner has the old
25-pin socket.) The cable's a bit ugly, with something of a rat's nest
of wires soldered together in the middle, but it works. Scanner works fine.

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

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.)


--
Who needs a junta or a dictatorship when you have a Congress
blowing Wall Street, using the media as a condom?

- harvested from Usenet

Meat Plow wrote:

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

So I made up a SCSI cable for the scanner I got off the street
(literally), an Agfa SnapScan 1236. (Had to cobble up the cable since
my SCSI host adapter has a high-density socket but the scanner has the
old 25-pin socket.) The cable's a bit ugly, with something of a rat's
nest of wires soldered together in the middle, but it works. Scanner
works fine.

But since using the scanner, I've found that sometimes--not
always--the scanner seems to be causing a hardware fault that causes
Windows blue screens. Sometimes I can boot up and do dozens of scans;
other times the BSOD appears some time after booting, or when I access
the scanner driver.

At first I wasn't sure whether the blue screens were due to the
scanner itself or the scanner driver, but I'm pretty sure it's the
former, as I never get them when I unplug the scanner.

I'm sure part of the problem can be traced to Windows 2000's rather
****-poor SCSI handling. While it is definitely better than Windows
NT, which *really* sucked in that way, it's still problematic.

And the fact that I don't have a terminator on the scanner might not
be helping, either. But as I said, when it works I can do many scans
with no problems.

I should say that this isn't a critical problem for me. I have another
scanner that works about as well (a Microtek using USB) that works
about as well; the Agfa just happens to be a bit faster and not as
annoyingly noisy. I'm mainly curious why I'm having these problems.

Any guesses? (Educated ones get more points.)

Oh, almost forgot:

o OS: Windows 2000, SP 2
o Advansys SCSI host adapter ("fast/wide"), but I'm using regular old
single-ended SCSI II. The Advansys is basically a clone of the old
Adaptec 1542, but with two adapters (16 SCSI IDs) on one card. There
are two CD-ROM drives (Plextor) on the same bus as the scanner.
o Motherboard is an Asus something-or-other, almost 10 years old

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.

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

--
Best Regards:
Baron.

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

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

And the fact that I don't have a terminator on the scanner might
not be helping, either. But as I said, when it works I can do
many scans with no problems.

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

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.)


--
Who needs a junta or a dictatorship when you have a Congress
blowing Wall Street, using the media as a condom?

- harvested from Usenet

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

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

And the fact that I don't have a terminator on the scanner might
not be helping, either. But as I said, when it works I can do
many scans with no problems.

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

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.

--
Warren Block * Rapid City, South Dakota * USA

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

David Nebenzahl wrote:

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

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

And the fact that I don't have a terminator on the scanner might
not be helping, either. But as I said, when it works I can do
many scans with no problems.

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

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.

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 "****-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.


--
Who needs a junta or a dictatorship when you have a Congress
blowing Wall Street, using the media as a condom?

- harvested from Usenet

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

David Nebenzahl wrote:

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

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

And the fact that I don't have a terminator on the scanner might
not be helping, either. But as I said, when it works I can do
many scans with no problems.

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

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.

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 "****-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
*measure* that rate and "diagnose" the problem? Or, should it
just "/* CAN'T HAPPEN */" and crash?

Tie the IRQ from your IDE drive to a 50KHz signal and see how
*it* responds. You can do the same in a Sun box and see how
it (mis)behaves.

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

In article ,
D Yuniskis wrote:

David Nebenzahl wrote:
So I made up a SCSI cable for the scanner I got off the street

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

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
9, but failed totally when I migrated to OS X; fixed it by adding a
terminator, but I believe the problem was still software (SCSI timing
was faster with OS X and the lack of terminator became an issue solely
because reflections didn't have time to die out).

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

isw wrote:
In article ,
D Yuniskis wrote:

David Nebenzahl wrote:
So I made up a SCSI cable for the scanner I got off the street
(sigh) SayNoMore. SCSI cables need to have controlled impedances.
Even at ASYNC speeds, you can get all sorts of reflections that
can cause havoc.

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

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

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
9, but failed totally when I migrated to OS X; fixed it by adding a
terminator, but I believe the problem was still software (SCSI timing
was faster with OS X and the lack of terminator became an issue solely
because reflections didn't have time to die out).

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.

David Nebenzahl Inscribed thus:

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

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

And the fact that I don't have a terminator on the scanner might
not be helping, either. But as I said, when it works I can do
many scans with no problems.

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

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.)


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

--
Best Regards:
Baron.

Meat Plow Inscribed thus:

On Tue, 03 Nov 2009 22:20:47 +0000, Baron
wrote:

Meat Plow wrote:

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

So I made up a SCSI cable for the scanner I got off the street
(literally), an Agfa SnapScan 1236. (Had to cobble up the cable
since my SCSI host adapter has a high-density socket but the scanner
has the old 25-pin socket.) The cable's a bit ugly, with something
of a rat's nest of wires soldered together in the middle, but it
works. Scanner works fine.

But since using the scanner, I've found that sometimes--not
always--the scanner seems to be causing a hardware fault that causes
Windows blue screens. Sometimes I can boot up and do dozens of
scans; other times the BSOD appears some time after booting, or when
I access the scanner driver.

At first I wasn't sure whether the blue screens were due to the
scanner itself or the scanner driver, but I'm pretty sure it's the
former, as I never get them when I unplug the scanner.

I'm sure part of the problem can be traced to Windows 2000's rather
****-poor SCSI handling. While it is definitely better than Windows
NT, which *really* sucked in that way, it's still problematic.

And the fact that I don't have a terminator on the scanner might not
be helping, either. But as I said, when it works I can do many scans
with no problems.

I should say that this isn't a critical problem for me. I have
another scanner that works about as well (a Microtek using USB) that
works about as well; the Agfa just happens to be a bit faster and
not as annoyingly noisy. I'm mainly curious why I'm having these
problems.

Any guesses? (Educated ones get more points.)

Oh, almost forgot:

o OS: Windows 2000, SP 2
o Advansys SCSI host adapter ("fast/wide"), but I'm using regular
old single-ended SCSI II. The Advansys is basically a clone of the
old Adaptec 1542, but with two adapters (16 SCSI IDs) on one card.
There are two CD-ROM drives (Plextor) on the same bus as the
scanner. o Motherboard is an Asus something-or-other, almost 10
years old

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.

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

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.

I've used both. Usually if its a 25 pin or single socket on the
scanner, its internally terminated. If there are two sockets, its
probably not and requires terminating.

--
Best Regards:
Baron.

On Tue, 3 Nov 2009 06:59:18 -0800, "William Sommerwerck"
wrote:

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.


Yep, any true SCSI fan has a big box of cables and adapters for every
possible combination! Someday I'll toss 'em...

On Tue, 03 Nov 2009 17:25:13 -0800, David Nebenzahl
wrote:

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

David Nebenzahl wrote:

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

On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
wrote:

And the fact that I don't have a terminator on the scanner might
not be helping, either. But as I said, when it works I can do
many scans with no problems.

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

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.

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?

Corrupted data including an invalid length, causing overwriting of the
buffers. First step is terminat the scanner, terminators should be
easy to find and probably free if you ask nicely. Try a local computer
repair shop that has been in business for over 10 years, likely they
have abox of 'em and don't know what to do with it. Pay shipping and
I'll send you one. Without termination (and probably without a good
cable) it will continue to be spastic...

I mean, shouldn't the OS be able to handle a SCSI
error without abandoning ship? That's what I meant by "****-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.

On 11/4/2009 3:14 AM Meat Plow spake thus:

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.

It puked again and I wrote down the offending module, which was
asc3550.sys. Looked at this file (with Notepad) and found it was the
Windoze SCSI handler. So now I know *where* it's ****ing up, anyhow.


--
Who needs a junta or a dictatorship when you have a Congress
blowing Wall Street, using the media as a condom?

- harvested from Usenet

On 11/4/2009 5:38 AM PeterD spake thus:

On Tue, 3 Nov 2009 06:59:18 -0800, "William Sommerwerck"
wrote:

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.

Yep, any true SCSI fan has a big box of cables and adapters for every
possible combination! Someday I'll toss 'em...

I was hoping to be able to find one at my favorite recycled-goods store
(Urban Ore in Berkeley), which has a *ton* of all kinds of cables, kind
of a snake pit all tossed together. I sorted through it and *almost*
found what I needed (50-pin high-density to 25-pin D), but no go. I was
surprised, as there are so many oddball cables in there.

I'm not sweating it. I just unplug the damn scanner when I'm not using
it. That's the $0 solution here.


--
Who needs a junta or a dictatorship when you have a Congress
blowing Wall Street, using the media as a condom?

- harvested from Usenet

On Wed, 04 Nov 2009 11:23:47 -0800, David Nebenzahl
wrote:

On 11/4/2009 3:14 AM Meat Plow spake thus:

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.

It puked again and I wrote down the offending module, which was
asc3550.sys. Looked at this file (with Notepad) and found it was the
Windoze SCSI handler. So now I know *where* it's ****ing up, anyhow.

Not exactly. That's the AdvanSys Ultra-Wide PCI driver, not the SCSI
drivers that come with W2K.

There's really not enough info yet to properly assign the blame. Try
putting a SCSI terminator on the end of your do it thyself cable and
see if it blue screens the same way. Also, try the terminator at the
AdvanSys card. It's not a definitive test, but it might give a clue.

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

In article ,
D Yuniskis wrote:

isw wrote:
In article ,
D Yuniskis wrote:

David Nebenzahl wrote:
So I made up a SCSI cable for the scanner I got off the street
(sigh) SayNoMore. SCSI cables need to have controlled impedances.
Even at ASYNC speeds, you can get all sorts of reflections that
can cause havoc.

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

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

Everything from the venerable Mac II to Blue & White G3s (well, not
*everything*, but a pretty good sample). Disk and tape drives (several
brands), scanners, film printers, couple of weird things I don't recall,
but *all* of it worked, with no terminators (well, just the one inside
the Mac). I just never had a problem, and after I found accidentally
that it worked, I'd hot-swap peripherals whenever I needed to -- just
make sure the disks were unmounted.

And then... Didn't change anything except to install OS X 10.3 on the
Blue & White, and the SCSI chain just vanished -- the Mac couldn't find
it at all. Stuck a terminator on the far end, and it all worked again.

Granted, my experience is with Macs, but in that context, in nearly 20
years, I never found SCSI to be very mysterious or tempermental, much
less felt the need to go looking for a goat...

Isaac

Hi!

(Had to cobble up the cable since my SCSI host adapter has a high-density
socket but the scanner has the old 25-pin socket.)

Twenty five pin SCSI cabling is, ah, not the most desireable thing to have.
It's a Macintosh thing and thankfully not very common elsewhere.

The cable's a bit ugly, with something of a rat's nest of wires soldered
together in the middle, but it works. Scanner works fine.

You can often get away with some truly impressive stuff on lower speed SCSI
setups. I've seen an IBM PS/2 Model 65 that came to me with termination
enabled on both hard drives and it *worked* when I got it. I suspect it
worked for many years, as it was a Netware server well into the late 90s and
quite possibly the early 2000s.

I cleaned the large amount of dust out and it stopped working with SCSI
related errors at POST. Fixing the double termination solved it. The errors
were baffling until I examined the drives and said "there is no way that can
be right".

But if you can, don't use a hacked up, homemade SCSI cable. Cables exist to
do what you want and they can still even be found. Price might be an issue,
but if you can wait and shop around...it will be less of one.

The following old discussion (short link)
http://lnk.nu/groups.google.com/12aa is probably mostly humorous in nature,
but it does point out one truth in dealing with SCSI, credited to a John
Woods:

"SCSI is *NOT* magic. There are *fundamental technical reasons* why it is
necessary to sacrifice a young goat to your SCSI chain now and then."

I'm sure part of the problem can be traced to Windows 2000's rather
****-poor SCSI handling. While it is definitely better than Windows NT,
which *really* sucked in that way, it's still problematic.

I've never noticed a particularly serious problem with either. But then
again, I've always run brand name equipment from Adaptec, BusLogic, LSI
Logic, IBM and Mylex. The few times I've run into less well known SCSI
adapters, I have found something that was troublesome.

Well, CD burning was an adventure, but I think it had more to do with what
hardware revision of a given IBM MCA SCSI adapter was expected by the
Windows NT driver.

o OS: Windows 2000, SP 2

Some reason why you're not using the latest service pack and post SP4
rollup? You probably should be, unless some situation with software
precludes your doing so.

o Advansys SCSI host adapter ("fast/wide"), but I'm using regular old
single-ended SCSI II. The Advansys is basically a clone of the old Adaptec
1542, but with two adapters (16 SCSI IDs) on one card.

I guess I'd question how good of a clone it really is. After you fix the
cable, that is. The nature of the card (as you describe it) sounds very odd
to me.

There are two CD-ROM drives (Plextor) on the same bus as the
scanner.

Is termination set properly? Don't rely on autotermination to get it
right--set it yourself! The devices at each end of the SCSI chain should be
terminated. In most cases, the SCSI adapter is electrically in the middle of
the internal and external buses. So, you'd terminate the last device on the
internal cable and the scanner, leaving the host adapter unterminated.

William

Hi!

Yes. Pretty sure the Advansys is auto-terminating.

Set it manually if you can. With a mix of internal and external devices, the
adapter should *not* be terminating in most cases.

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 "****-poor SCSI handing". I can't
imagine, for example, that a Sun workstation would be brought to its knees
by a bad SCSI cable.

Heh. :-)

When SCSI screws up, it *really* screws up. Some host adapters take it
better than do others, but I guarantee you that it is possible to knock over
almost any SCSI setup when certain things happen.

William