Troubleshooting Nikon Super Coolscan 4000 ED
I posted my first calls for help on the Linux Mint forum (Nikon Super Coolscan 4000 ED) but came away disappointed by the limited amount of help I received. It may have been my fault for overwhelming them with a Wall of Text (aka WoT) - so I will be careful not to make the same mistake here. Finally, today, someone on that forum suggested that I should have posted my questions to "...a more generic forum" and suggested this one. So here I am.
If you would like to see the full details of my situation, please follow the above link to see them. It includes very-detailed - hopefully comprehensive - information. I'll net out my current situation here (also summarized in the very-last post on that forum): In "Some notes on failure diagnostics / troubleshooting the Nikon 4000 and 5000 scanners" I found this description in the Symptom/Problem/Solution table that very-closely matches what I have been seeing: "The scanner passes power-up initialization fine (no fast blinking), and is recognized by a computer (in Windows - Device Manager), BUT - Nikon Scan does NOT see it." The notes say: In every case (that I saw), it was caused by a failed SAA7356HL, with the following additional information: Replace SAA7356HL. Yep, this may be hardware problem. And I have found a very-nice man, with countless happy customers, who will fix it for me: Alex Ketzner (abstudios@live.com). The basic servicing on an LS-4000 is $190. And he no longer replaces individual chips, so I'd need to replace the whole motherboard for an additional $350. Needless to say, I am more than a little reluctant to spend $540 (plus shipping costs) on a 17-year-old scanner. :-) One of my key motivations for trying to make this scanner work with Linux was for its presumably greater openness and better diagnostic capabilities. So, PLEASE, someone help me here: If a hardware problem, failing IEEE-1394 (Firewire) controller, is my hypothesis, how can I prove (or disprove) it with Linux? Is there a UDEV debug mode that I could turn on in order to see exactly what Linux is seeing from the scanner? Thanks. BobLx |
I do not have experience with SCSI-connected scanners or this particular model, but it might still be useful to show us how you have configured coolscan.conf, and I assume that you have linked the appropriate /dev/sg* device node to /dev/scanner (as per the suggestions in sane-scsi)?
Quote:
Code:
ls -l /dev/sg* |
I note that both the coolscan2 and coolscan3 backends claim to support this model?
Code:
linux-kgxs:/etc/sane.d # cat /usr/share/sane/descriptions/coolscan2.desc|grep 4000 |
Dear Ferrari,
Thank you for both of your replies. While I've been experimenting with Linux for a few weeks now, I am still pretty much a newbie with it. I've also tried many things including installing both the coolscan2 and coolscan3 backends. It never occurred to me that they might conflict with each other (as you are suggesting commenting out the unneeded one). So I just now opened up /etc/sane.d/dll.conf to see what I could see and, much to my surprise, it appears that coolscan2 is commented out already. I do not think I did it. Maybe coolscan2 was commented out by the installation of coolscan3? Code:
# The next line enables the network backend; comment it out if you don't need Code:
scsi Nikon * Scanner Regarding the permissions, here is where things are aat this moment: Code:
bob@bob-ThinkPad-T520 ~ $ lsscsi -g Code:
bob@bob-ThinkPad-T520 ~ $ sudo chgrp scanner /dev/sg2 Now, of course, I'd rather not have to do the chgrp and chmod every time I want to use the scanner but I don't know what config to change in order to get it to come up right in the first place. Of course, this is all back on the assumption that something is wrong with my software and/or configuration (which could well be the case), but my latest hypothesis is that this is indeed a hardware problem with the scanner. I've arrived at that conclusion based upon a very, very helpful web site where I found a pretty accurate description of what I am seeing with the scanner: Some notes on failure diagnostics / troubleshooting the Nikon 4000 and 5000 scanners Because I am seeing "The scanner passes power-up initialization fine (no fast blinking), and is recognized by a computer (in Windows - Device Manager), BUT - Nikon Scan does NOT see it." He says: "In every case (that I saw), it was caused by a failed SAA7356HL." (That's the IEEE 1394 controller chip.) Which brings me back around to my opening question in this thread: Can you - or anyone - suggest any way I might be able to test and either prove or disprove the hypothesis that my problem is indeed a hardware problem? (Some sort of debug feature somewhere - and knowing what bytes to look at??) I'm still happy to experiment with software and configurations if anyone has any suggestions of things I might try. but, given my inexperience, you'll need to be pretty prescriptive about what I need to do. ;-) Thanks, BobLx |
@OP, OK, if it is the interface chip, your not going to confirm it using software, except by the most indirect method, i.e. knowing what certain symptoms indicate. It looks like you can purchase a working scanner of that model for 420.00 or so all day long on eBay.
If it needs the repair in the link you gave, it's a pretty tough repair to do with soldering tools. So, you'll probably look for a while until you find someone willing to replace the IC. |
Quote:
Quote:
Code:
crw-rw---- 1 root scanner 21, 2 Mar 15 22:09 /dev/sg2 Code:
ls -l /dev/scanner |
Thanks for hanging with me, and my ignorance!
Thanks for your thoughts AwesomeMachine and thanks again Ferrari,
If you guys knew how long I've been messing with this scanner, you'd laugh out loud (my family already is)! Between my brother, his wife, myself, my wife, and one of our two sons, we have five Computer Science degrees (two from UVA, two from VA Tech, and one from UNC). Here's the thing (and probably more than you'd like to know):
With that all said, I am an old networking guy and, back in the day, we could trouble shoot problems by turning on traces and watching what goes over the wire. I'm not really interested in tracing the IEEE 1394 interface but what about the software (is it called a driver in Linux) that handles that interface, and what about the software that figures out this is a Nikon Scanner (is that UDEV?)? Looking at the output from my lsscsi -g, it appears that Linux think my scanner is a disk drive. That can't be good. ;-) Ferrari: Thanks for suggesting that I look at coolscan3.conf. Here's what it looks like: Code:
# coolscan3.conf: sample configuration file for coolscan3 backend Also, here's the output from the ls -l /dev/scanner: Code:
bob@bob-ThinkPad-T520 ~ $ ls -l /dev/scanner Thanks again for hanging with me on this and trying to help. BobLx |
Your coolscan3.conf file currently contains the following entry...
Code:
# For a SCSI scanner, uncomment and edit the following line: Code:
scsi:/dev/sg2 Now try the scanner function again. |
Returning to your earlier comments about the attached device being seen as a disk, it would be useful to see the scanner device attributes reported by udev. Check that the LS-4000 ED is still using the same device node (it might change after a reboot for example).
Code:
lsscsi -g Code:
udevadm info -a -p /sys/class/scsi_generic/sg2 |
Quote:
Code:
bob@bob-ThinkPad-T520 /etc/sane.d $ lsscsi -g As I look down the udevadm output, I can see: ATTRS{model}==" LS-4000 ED " --- which gives me confidence that we're getting something from the scanner I can also see: ATTRS{vendor_name}=="Nikon" -- so now Linux should know that it is a Nikon scanner This is what keeps me coming back and messing with settings. It seems like I am so close to getting it working. And does this really look like a hardware problem to you? Thanks again. BobLx |
Well at a scsci-level the communications is working as expected. Let's see if a udev rule can help with getting the device recognised as a scanner and set appropriate permissions etc...
For example, a custom rule like this /etc/udev/rules.d/60-coolscan.rules containing Code:
KERNEL=="sg[0-9]*", ATTRS{model}=="LS-4000 ED", MODE="0664", GROUP="scanner", SYMLINK="scanner", ENV{libsane_matched}="yes" |
No joy so far, but hey, I'm learning stuff :-)
Quote:
I did that with the scanner turned off and then turned it on but no joy. Then I completely rebooted my system just to see if that might help and still nothing new. Code:
bob@bob-ThinkPad-T520 ~ $ lsscsi -g Code:
bob@bob-ThinkPad-T520 ~ $ ls -l /dev/sg* Code:
bob@bob-ThinkPad-T520 ~ $ udevadm info -a -p /sys/class/scsi_generic/sg2 From the looks of it, I can't see where the UDEV rule made any difference. Any thoughts on what I might have done wrong? I know this is getting to be a hassle for you. (Imagine that I've been messing with this stuff since January - first with Windows 10, then I briefly tried to set up an XP system, then on to Linux Mint.) It is fun to have someone who is knowledgeable trying to help me. Thanks. BobLx |
There was no need to run 'udevadm info...' again. The attributes are what is enumerated by the device via the kernel itself. The udev rule used two of those attributes for matching. However, group 'disk' is still assigned to /dev/sg2 which means that some other udev rule is matching and overrides the custom one. I'll have to ponder over that further.
Meanwhile at least check that the firewire_sbp2 module is loaded as expected... Code:
lsmod|grep firewire |
Quote:
Code:
bob@bob-ThinkPad-T520 ~ $ lsmod | grep firewire Code:
Mar 16 22:19:40 bob-ThinkPad-T520 kernel: [ 2341.872149] scsi host6: SBP-2 IEEE-1394 BobLx |
The lsmod output is as expected. The syslog output does confirm that this peripheral is incorrectly being treating as a block device.
The 'sd' (sd_mod kernel module) should not be bound to this parent device... Code:
looking at parent device '/devices/pci0000:00/0000:00:1c.4/0000:0d:00.3/fw1/fw1.0/host6/target6:0:0/6:0:0:0': Code:
ATTRS{type}=="3" Code:
ATTRS{type}=="0" Code:
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="0", GROUP="disk" This may be due to a bug that that needs to be reported. I'm not convinced that there is a hardware issue here. |
All times are GMT -5. The time now is 07:04 AM. |