melstrom
Member

Posts: 9
|
 |
« on: July 18, 2010, 04:55:15 pm » |
|
Sun 18 Jul 2010 17:55 pdt
Hello VL, I've just bought & installed VL 6.0 Deluxe Standard on a very old ThinkPad 600. I need to have scsi support via my Adaptec 1460B pcmcia adapter, which has served me flawlessly for years. But VL did not recognize it upon installation, and, much to my surprise, the kernel module for it (aha152x_cs) is nowhere to be found on the installation. More surprising, when I ran VL 6.0 Lite live CD on the machine earlier, it did work. GrannyGeek suggested in a post over a year ago that a full new install may be needed, that the installer somehow just hiccuped. That's hard for me to believe; is it true? How / where might I get the module? Gratefully, Mel Strom
|
|
|
|
|
Logged
|
|
|
|
melstrom
Member

Posts: 9
|
 |
« Reply #1 on: July 18, 2010, 06:07:07 pm » |
|
Sun 18 Jul 2010 18:00 pdt
Correction to original post: under VL 6.0 Lite live CD, I do *not* get pcmcia scsi support, and there is no kernel module aha152x_cs. But on a different laptop, running Slackware 13.0, the card work without a hitch. Modprobe correctly inserts aha152x_cs, and the chain works.
==MAS
|
|
|
|
|
Logged
|
|
|
|
|
nightflier
|
 |
« Reply #2 on: July 19, 2010, 11:51:17 am » |
|
Looks like the kernel was not configured with support for this piece of hardware. I checked my system with kernel 2.6.31.8, and it is not either.
You could re-configure your kernel config and build a new kernel for this purpose.
|
|
|
|
|
Logged
|
|
|
|
melstrom
Member

Posts: 9
|
 |
« Reply #3 on: July 22, 2010, 07:51:54 pm » |
|
Looks like the kernel was not configured with support for this piece of hardware. I checked my system with kernel 2.6.31.8, and it is not either.
You could re-configure your kernel config and build a new kernel for this purpose.
Thurs 22 Jul 2010 Thank you for the reply, nightflier. I haven't heard back from the support people yet, so I don't know whether there might be a different answer to the problem. But I did successfully re-complile my kernel, and scsi does indeed now work. Some other tweaks are still needed, but at least now I know I can make this machine work for what I want. ==MAS
|
|
|
|
|
Logged
|
|
|
|
|
bigpaws
|
 |
« Reply #4 on: July 23, 2010, 10:03:22 am » |
|
Hi Melstorm, I haven't heard back from the support people yet I am one of the support persons. I never received a request for support. The only information I see is a purchase. Your solution of recompiling the kernel was the way to go. If you or feel there is a need to pursue this I can email you or you can email here. support@vector.ecosq.comIf you did send a request for help, you can respond here. I will check to see if something got missed. Bigpaws
|
|
|
|
|
Logged
|
|
|
|
melstrom
Member

Posts: 9
|
 |
« Reply #5 on: July 26, 2010, 07:56:09 pm » |
|
Mon 26 Jul 2010 21.00 PDT Hello bigpaws, Thanks very much for your reply. Very curious about my support emails. I've sent two (2), both to the address you give ( support@vector.ecosq.com)... I'm looking at them in my 'sent' mailbox (Thunderbird) now. Those messages - like most of my email - are GNUPG signed (but not encrypted)... that shouldn't have any bearing. Odd where they ended up. But at least I can connect to you via the forum here. Here is the 2d message I sent - a follow-on problem (small) to the same SCSI situation: Sat 24 Jul 2010 23.00 PDT Hello Vector Linux, I never received any response to my email request for installation help (see below). I have, however, managed to resolve in part the problem I described. I have successfully reconfigured and recompiled the kernel. The result is both a working PCMCIA network adapter (Xircom CEM56-100) and a working SCSI bus via PCMCIA Adaptec 1460B. However, I still have a (small?) SCSI problem, and I hope you can give me some guidance. My SCSI scanner, a Microtek X12USL, is now detected on boot up (along with 2 other devices on the bus). But no /dev/ entry gets created for it: lsscsi returns: [2:0:3:0] scanner ScanMaker X12USL 1.30 - Other devices on the bus do get /dev nodes (/dev/sda; /dev/sr0; /dev/sdb). How can I get a /dev node created for the scanner so that sane, scanimage, etc. will find it and work? Thank you, ==Mel Strom Hi Melstorm, I haven't heard back from the support people yet I am one of the support persons. I never received a request for support. The only information I see is a purchase. Your solution of recompiling the kernel was the way to go. If you or feel there is a need to pursue this I can email you or you can email here. support@vector.ecosq.comIf you did send a request for help, you can respond here. I will check to see if something got missed. Bigpaws
|
|
|
|
|
Logged
|
|
|
|
|
bigpaws
|
 |
« Reply #6 on: July 26, 2010, 08:34:32 pm » |
|
Have you checked lsusb?
From the information you supplied this is a USB scanner. Also note that the last information I currently find is that this scanner may not work.
I am looking into the lack of email from sqi.
Bigpaws
|
|
|
|
|
Logged
|
|
|
|
melstrom
Member

Posts: 9
|
 |
« Reply #7 on: July 27, 2010, 07:57:01 am » |
|
Have you checked lsusb?
From the information you supplied this is a USB scanner. Also note that the last information I currently find is that this scanner may not work.
I am looking into the lack of email from sqi.
Bigpaws
Tu 27 Jul 2010 08.45 pdt Hello Bigpaws, That scanner has both USB and SCSI interfaces (that's why I bought it). But the SANE package(s) don't work for it when connected via USB. Connected to one of my Macs via USB, everything works instantly, automagically (VueScan), but my objective is to have it as a local network scanner -- hence my interest in using this old laptop plus SANE via SCSI. Not incidentally, under an earlier Slackware system (9.0 or earlier?) on a now-inop hard disk, on this same ThinkPad, the SANE networking of the scanner worked fine. So once I get a /dev node for the scanner under VL 6, I expect things will work. Thanks again for your attention and help. ==MAS
|
|
|
|
|
Logged
|
|
|
|
|
bigpaws
|
 |
« Reply #8 on: July 27, 2010, 09:28:28 am » |
|
My guesss is that HAL or udev are the problem.
Try this commands and post back the results.
udevtrigger --verbose --subsystem-match=block --attr-match=removable=1
udevadm trigger --verbose --subsystem-match=block --attr-match=removable=1
Please try submitting another support request to test it. We can continue this problem here.
Bigpaws
|
|
|
|
|
Logged
|
|
|
|
melstrom
Member

Posts: 9
|
 |
« Reply #9 on: July 27, 2010, 10:33:35 pm » |
|
My guesss is that HAL or udev are the problem.
Try this commands and post back the results.
udevtrigger --verbose --subsystem-match=block --attr-match=removable=1
udevadm trigger --verbose --subsystem-match=block --attr-match=removable=1
Please try submitting another support request to test it. We can continue this problem here. Bigpaws
Tu 27 Jul 2010 23.30 PDT Hello Bigpaws, Here is the output from those udev commands: root:# lsscsi [2:0:1:0] optical FUJITSU MCF3064SS 0040 /dev/sda [2:0:2:0] cd/dvd PLEXTOR CD-R PX-W1210S 1.04 /dev/sr0 [2:0:3:0] scanner ScanMaker X12USL 1.30 - tp600://home/melstrom root:# udevtrigger --verbose --subsystem-match=block --attr-match=removable=1 /block/fd0 /block/hdc /block/sda /block/sr0 tp600://home/melstrom root:# udevadm trigger --verbose --subsystem-match=block --attr-match=removable=1 /block/fd0 /block/hdc /block/sda /block/sr0 tp600://home/melstrom Pretty clearly, the scanner isn't known to udev, though the scsi bus knows it's there (and dmesg after boot up clearly shows it's there). I've only begun learning a bit about udev configurations. But I'd have thought that once the device was identified at boot, right away a /dev node would be created for it, as are the nodes for the M-O drive and the CD-ROM on the scsi bus. Thanks again, ==MAS
|
|
|
|
|
Logged
|
|
|
|
|
bigpaws
|
 |
« Reply #10 on: July 28, 2010, 06:17:22 am » |
|
This maybe the solution.
add the following udev rule, which I put in /etc/udev/rules.d/10-custom.rules
BUS="scsi", SYSFS{vendor}="Microtek*", SYSFS{model}="X12USL*", SYMLINK="scanner%n"
You may need to edit this.
According to what I understand this should make your /dev
Bigpaws
|
|
|
|
|
Logged
|
|
|
|
melstrom
Member

Posts: 9
|
 |
« Reply #11 on: July 28, 2010, 06:41:11 am » |
|
This maybe the solution.
add the following udev rule, which I put in /etc/udev/rules.d/10-custom.rules
BUS="scsi", SYSFS{vendor}="Microtek*", SYSFS{model}="X12USL*", SYMLINK="scanner%n"
You may need to edit this.
According to what I understand this should make your /dev
Bigpaws
Wed 28 Jul 2010 07.45 PDT Thanks again, Bigpaws. I shall give this (or an edited) udev rule a try later today; I'll report back as soon as I have some sort of result. ==MAS
|
|
|
|
|
Logged
|
|
|
|
melstrom
Member

Posts: 9
|
 |
« Reply #12 on: July 29, 2010, 09:29:49 pm » |
|
This maybe the solution.
add the following udev rule, which I put in /etc/udev/rules.d/10-custom.rules
BUS="scsi", SYSFS{vendor}="Microtek*", SYSFS{model}="X12USL*", SYMLINK="scanner%n"
You may need to edit this.
According to what I understand this should make your /dev
Bigpaws
Th 29 Jul 2010 22.15 PDT Hello Bigpaws, I did figure out a working udev rule to add the /dev/scanner%n node. Using udevadm, I retrieved key values that worked: SUBSYSTEMS=="scsi", ATTRS{model}=="*X12USL*", SYMLINK="scanner%n" That rule does produce a symlink /dev/scanner2 -> /dev/sg2 And that result has led me to a different thought on where the problem may lie: It seems the node /dev/sg2 has been there all along... the only difference now is a new symlink to it. But /dev/sg2 seems to be a disk node (it is owned by root:disk); moreover, sane-find-scanner still fails to find and scsi scanner attached. But the output from udevtrigger --verbose |grep driver shows only 2 scsi drivers: /bus/scsi/drivers/sd and /bus/scsi/drivers/sr That made me think that the sg driver is not present. I had thought that that driver was essential for a scsi scanner, and I remember trying to ensure it was getting compiled in when I reconfigured my kernel.... but I also sort of remember not really seeing any specific line or question under menuconfig for the sg driver. Does this guess sound plausible? Could I have missed or overlooked the inclusion of the sg driver and thereby leaving my scanner adrift without a driver? ==MAS
|
|
|
|
|
Logged
|
|
|
|
|
bigpaws
|
 |
« Reply #13 on: July 30, 2010, 04:53:24 am » |
|
Check lsmod
and modinfo sg
Bigpaws
|
|
|
|
|
Logged
|
|
|
|
melstrom
Member

Posts: 9
|
 |
« Reply #14 on: July 31, 2010, 06:28:30 pm » |
|
Th 29 Jul 2010 22.15 PDT
Hello Bigpaws, I did figure out a working udev rule to add the /dev/scanner%n node. Using udevadm, I retrieved key values that worked:
SUBSYSTEMS=="scsi", ATTRS{model}=="*X12USL*", SYMLINK="scanner%n"
That rule does produce a symlink /dev/scanner2 -> /dev/sg2
And that result has led me to a different thought on where the problem may lie: It seems the node /dev/sg2 has been there all along... the only difference now is a new symlink to it. But /dev/sg2 seems to be a disk node (it is owned by root:disk); moreover, sane-find-scanner still fails to find and scsi scanner attached. But the output from udevtrigger --verbose |grep driver shows only 2 scsi drivers: /bus/scsi/drivers/sd and /bus/scsi/drivers/sr
That made me think that the sg driver is not present. I had thought that that driver was essential for a scsi scanner, and I remember trying to ensure it was getting compiled in when I reconfigured my kernel.... but I also sort of remember not really seeing any specific line or question under menuconfig for the sg driver. Does this guess sound plausible? Could I have missed or overlooked the inclusion of the sg driver and thereby leaving my scanner adrift without a driver?
==MAS Sat 31 Jul 2010 19.30 PDT Hello VL, Bigpaws, After a day or two away, I believe I've just now resolve the scsi scanner problem. The short version of the resolution: permissions. I happened to be sudo-ed to root for some editing when I ran "sane-find-scanner." It immediately returned a positive identification of the ScanMaker; scanimage -L did the same. I thought perhaps it was a hotplugging matter, as I had had the scanner disconnected from the ThinkPad for work on another machine. Perhaps, I thought, on reconnection everything got detected. Reboots and mutiple reconnections fo the scanner proved that notion wrong: 'sane-find-scanner' and 'scanimage -L' (as normal user) returned blanks. sudo-ing to root gave positive results, though. The /dev/sg2 node is owned by root:disk, with 640 permissions. I had made myself a member of lots of groups (wheel, disk, scanner, adm, etc. etc.), and on other systems in the past that had been enough. I don't know why it comes up with group 'disk.' I amended my udev rule (see earlier post) to add MODE="0660" and GROUP="scanner". It worked immediately upon reboot, and I can find the scanner as my normal user. Thanks again very much for your help, in jumpstarting me with udev. ==MAS
|
|
|
|
|
Logged
|
|
|
|
|