Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[melstrom]

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

[melstrom]

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

[nightflier]

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.

[melstrom]

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

[bigpaws]

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

If you did send a request for help, you can respond here. I will check
to see if something got missed.

Bigpaws

[melstrom]

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

If you did send a request for help, you can respond here. I will check
to see if something got missed.

Bigpaws

[bigpaws]

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

[melstrom]

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

[bigpaws]

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

[melstrom]

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

[bigpaws]

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

[melstrom]

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

[melstrom]

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

[bigpaws]

Check lsmod

and  modinfo sg

Bigpaws

[melstrom]

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