Hardware flakiness (Windoze BSOD)
David Nebenzahl
(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
piss-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
PeterD
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.
William Sommerwerck
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.
D Yuniskis
> 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
> piss-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.
David Nebenzahl
> 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 shit 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.
David Nebenzahl
> 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.)
Baron
> On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
> <nob...@but.us.chickens>wrote:
>
> 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.
David Nebenzahl
>> On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
>> <nob...@but.us.chickens>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.)
Warren Block
> On 11/3/2009 2:20 PM Baron spake thus:
>
>>> On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
>>> <nob...@but.us.chickens>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
David Nebenzahl
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.
D Yuniskis
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.
Bob Larter
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.
--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
Bob Larter
> On 11/3/2009 2:20 PM Baron spake thus:
>
>>> On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
>>> <nob...@but.us.chickens>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.)
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. ;^)
Bob Larter
> 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.
The SCSI gods are touchy, & quick to anger.
>> 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.
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.
isw
D Yuniskis <not.goi...@seen.com> 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
D Yuniskis
> In article <hcpm6p$ofd$1...@aioe.org>,
> D Yuniskis <not.goi...@seen.com> 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?
baron
> On 11/3/2009 2:20 PM Baron spake thus:
>
>>> On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
>>> <nob...@but.us.chickens>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.
baron
> On Tue, 03 Nov 2009 22:20:47 +0000, Baron
> <baron....@linuxmaniac.nospam.net>wrote:
> 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.
PeterD
Yep, any true SCSI fan has a big box of cables and adapters for every
possible combination! Someday I'll toss 'em...
PeterD
<nob...@but.us.chickens> wrote:
>On 11/3/2009 5:12 PM Warren Block spake thus:
>
>> David Nebenzahl <nob...@but.us.chickens> wrote:
> >
>>> On 11/3/2009 2:20 PM Baron spake thus:
>>>
>>>>> On Tue, 03 Nov 2009 00:27:20 -0800, David Nebenzahl
>>>>> <nob...@but.us.chickens>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...
David Nebenzahl
> 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 fucking up, anyhow.
David Nebenzahl
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.
Jeff Liebermann
<nob...@but.us.chickens> 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 fucking 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 je...@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
isw
D Yuniskis <not.goi...@seen.com> wrote:
> isw wrote:
> > In article <hcpm6p$ofd$1...@aioe.org>,
> > D Yuniskis <not.goi...@seen.com> 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
William R. Walsh
> (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
> piss-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
William R. Walsh
> 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 "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.
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