[sane-devel] saned does not work with 2.6.23-rc9
Hi,
today I updated the kernel on my Debian stable box to vanilla 2.6.23-rc9 and
now, saned (version 1.0.14-2) is unable to find my scanner. Here is the
strace output of sane-find-scanner:
open(/proc/scsi/scsi, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f52000
read(3, Attached devices:\nHost: scsi0 Ch..., 1024) = 976
read(3, , 1024) = 0
close(3)= 0
munmap(0xb7f52000, 4096)= 0
open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbf84a834)= 0
ioctl(3, SG_GET_VERSION_NUM, 0x8062524) = 0
ioctl(3, SG_GET_SCSI_ID, 0xbf84a7f0)= -1 ENOTTY (Inappropriate ioctl for
device)
close(3)= 0
Is there a patch available to fix sane?
regards,
J?rg
--
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605
[sane-devel] saned does not work with 2.6.23-rc9
Am Mittwoch, 3. Oktober 2007 schrieb Joerg Platte:
Hi,
this is the output of the same command invoked on 2.6.22.6 and with this
kernel the scanner is found.
open(/proc/scsi/scsi, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f69000
read(3, Attached devices:\nHost: scsi0 Ch..., 1024) = 976
read(3, , 1024) = 0
close(3)= 0
munmap(0xb7f69000, 4096)= 0
open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0
ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0
ioctl(3, SG_SET_RESERVED_SIZE, 0xbfe4066c) = 0
ioctl(3, SG_GET_RESERVED_SIZE, 0xbfe40620) = 0
ioctl(3, SG_GET_SCSI_ID, 0xbfe40600)= 0
ioctl(3, SG_SET_COMMAND_Q, 0xbfe40624) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
ioctl(3, SG_IO, 0x8066178) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
ioctl(3, SG_IO, 0x8066178) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, found SCSI scanner \SCANNER 2.0..., 51found SCSI scanner SCANNER
2.02 at /dev/scanner
) = 51
close(3)= 0
regards,
J?rg
--
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605
[sane-devel] saned does not work with 2.6.23-rc9
On 03.10.2007 10:27, Joerg Platte wrote:
Hi,
today I updated the kernel on my Debian stable box to vanilla 2.6.23-rc9 and
now, saned (version 1.0.14-2) is unable to find my scanner. Here is the
strace output of sane-find-scanner:
open(/proc/scsi/scsi, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f52000
read(3, Attached devices:\nHost: scsi0 Ch..., 1024) = 976
read(3, , 1024) = 0
close(3)= 0
munmap(0xb7f52000, 4096)= 0
open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbf84a834)= 0
ioctl(3, SG_GET_VERSION_NUM, 0x8062524) = 0
ioctl(3, SG_GET_SCSI_ID, 0xbf84a7f0)= -1 ENOTTY (Inappropriate ioctl for
device)
close(3)= 0
Is there a patch available to fix sane?
It is very weird that the SG_GET_SCSI_ID ioctl does not work: Could you
check, if /dev/scanner -- should be a symlink -- indeed points to a
device file of some SCSI device (ideally, to the scanner's device file)?
And if so, do you see any suspicious output in /var/log/messages?
Finally, can you run sane-find-scaner with SANE_DEBUG_SANEI_SCSI=255 and
send us the output?
And which SCSI adapter and which adapter driver are you using?
Abel
[sane-devel] saned does not work with 2.6.23-rc9
Am Mittwoch, 3. Oktober 2007 schrieb abel deuring:
Hi,
It is very weird that the SG_GET_SCSI_ID ioctl does not work: Could you
check, if /dev/scanner -- should be a symlink -- indeed points to a
device file of some SCSI device (ideally, to the scanner's device file)?
I wrote this udev rule to create /dev/scanner:
SUBSYSTEMS==scsi, SYSFS{vendor}==SCANNER , OWNER=saned, GROUP=jplatte,
MODE=660, NAME=scanner
root at jako:~ ls -la /dev/scanner
crw-rw 1 saned jplatte 254, 5 2007-10-03 14:37 /dev/scanner
And if so, do you see any suspicious output in /var/log/messages?
No.
Finally, can you run sane-find-scaner with SANE_DEBUG_SANEI_SCSI=255 and
send us the output?
Here it is:
root at jako:~ SANE_DEBUG_SANEI_SCSI=255 sane-find-scanner
# sane-find-scanner will now attempt to detect your scanner. If the
# result is different from what you expected, first make sure your
# scanner is powered up and properly connected to your computer.
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_find_devices: vendor=(null) model=(null) type=Scanner
bus=0 chan=0 id=6 lun=0 num=5
[sanei_scsi] lx_chk_id: 0,0 0,0 6,4 0,0
[sanei_scsi] lx_scan_sg: k=0, exclude=5, missed=0
[sanei_scsi] lx_chk_id: 0,0 0,0 6,4 0,0
[sanei_scsi] lx_scan_sg: k=1, exclude=5, missed=1
[sanei_scsi] lx_chk_id: 0,1 0,0 6,0 0,0
[sanei_scsi] lx_scan_sg: k=2, exclude=5, missed=1
[sanei_scsi] lx_chk_id: 0,1 0,0 6,1 0,0
[sanei_scsi] lx_scan_sg: k=3, exclude=5, missed=1
[sanei_scsi] lx_chk_id: 0,2 0,0 6,0 0,0
[sanei_scsi] lx_scan_sg: k=4, exclude=5, missed=1
[sanei_scsi] lx_chk_id: 0,2 0,0 6,1 0,0
[sanei_scsi] lx_scan_sg: k=5, exclude=5, missed=1
[sanei_scsi] lx_scan_sg: k=6, exclude=5, missed=1
[sanei_scsi] lx_scan_sg: k=7, exclude=5, missed=2
[sanei_scsi] lx_scan_sg: k=8, exclude=5, missed=3
[sanei_scsi] lx_scan_sg: k=9, exclude=5, missed=4
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: sanei_scsi_max_request_size=131072 bytes
[sanei_scsi] sanei_scsi_open: SG driver version: 30527
[sanei_scsi] sanei_scsi_open: The device found for /dev/scanner does not look
like a scanner
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: SG driver version: 30534
[sanei_scsi] sanei_scsi_open: The device found for /dev/sg0 does not look like
a scanner
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: SG driver version: 30534
[sanei_scsi] sanei_scsi_open: The device found for /dev/sg1 does not look like
a scanner
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: SG driver version: 30534
[sanei_scsi] sanei_scsi_open: The device found for /dev/sg2 does not look like
a scanner
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: SG driver version: 30534
[sanei_scsi] sanei_scsi_open: The device found for /dev/sg3 does not look like
a scanner
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: SG driver version: 30534
[sanei_scsi] sanei_scsi_open: The device found for /dev/sg4 does not look like
a scanner
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sg5' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sg6' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sg7' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sg8' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sg9' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sga' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sgb' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sgc' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sgd' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sge' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sgf' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: open of `/dev/sgg' failed: No such file or
directory
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open:
[sane-devel] saned does not work with 2.6.23-rc9
On 03.10.2007 14:46, Joerg Platte wrote:
Am Mittwoch, 3. Oktober 2007 schrieb abel deuring:
Hi,
It is very weird that the SG_GET_SCSI_ID ioctl does not work: Could you
check, if /dev/scanner -- should be a symlink -- indeed points to a
device file of some SCSI device (ideally, to the scanner's device file)?
I wrote this udev rule to create /dev/scanner:
SUBSYSTEMS==scsi, SYSFS{vendor}==SCANNER , OWNER=saned,
GROUP=jplatte,
MODE=660, NAME=scanner
root at jako:~ ls -la /dev/scanner
crw-rw 1 saned jplatte 254, 5 2007-10-03 14:37 /dev/scanner
And if so, do you see any suspicious output in /var/log/messages?
No.
Finally, can you run sane-find-scaner with SANE_DEBUG_SANEI_SCSI=255 and
send us the output?
Here it is:
root at jako:~ SANE_DEBUG_SANEI_SCSI=255 sane-find-scanner
# sane-find-scanner will now attempt to detect your scanner. If the
# result is different from what you expected, first make sure your
# scanner is powered up and properly connected to your computer.
[sanei_debug] Setting debug level of sanei_scsi to 255.
did not give me any clue, but you already found the cause of the problem
:) And since the host adapter driver did not see any devices, we can't
expect to get useful output.
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_find_devices: vendor=(null) model=(null) type=Scanner
bus=0 chan=0 id=6 lun=0 num=5
[...]
And which SCSI adapter and which adapter driver are you using?
An old Symbios based card
02:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 26)
with this driver:
sym53c8xx 66964 0
scsi_transport_spi 20864 1 sym53c8xx
scsi_mod 122124 8
sg,sr_mod,st,sd_mod,osst,sym53c8xx,scsi_transport_spi,libata
Both driver and adapter are generally very reliable.
After some reboots I discovered, that the scanner is recognized by
sane-add-scanner if it is turned on during system boot. It is not detected
after executing the following script to rescan all SCSI busses (I'm using
ata_piix, hence there is more than one SCSI bus):
for device in /sys/class/scsi_host/host*/scan ; do
echo 0 - - $device
done
Yes, if the scanner is not known to its host adapter driver, no
application will find it :) But it is nevertheless very weird that
_some_ SCSI related IOCTLs worked, but SG_GET_SCSI_ID failed, probably
for a stale device file.
With this script the kernel detects the scanner according to /proc/scsi/scsi
and the device node is created:
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: SCANNER Model: Rev: 2.02
Type: Scanner ANSI SCSI revision: 01 CCS
but then sane-add-scanner is not able to find it. Looks more like a kernel
bug, because this script worked fine with older kernels.
right.
Abel
[sane-devel] saned does not work with 2.6.23-rc9
Am Mittwoch, 3. Oktober 2007 schrieb abel deuring: # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. [sanei_debug] Setting debug level of sanei_scsi to 255. did not give me any clue, but you already found the cause of the problem :) And since the host adapter driver did not see any devices, we can't expect to get useful output. But at tis point Linux found the scanner and created the device node and an entry in /proc/scsi/scsi and the scanner is turned on and connected. With previous kernels this was sufficient to actually use the scanner. Yes, if the scanner is not known to its host adapter driver, no application will find it :) But it is nevertheless very weird that _some_ SCSI related IOCTLs worked, but SG_GET_SCSI_ID failed, probably for a stale device file. I don't think it is stale, looks more like it is not fully initialized. But maybe the SCSI implementation of the scanner is buggy and recent kernels trigger a bug. The scanner is a Mustek ScanExpress 12SP and I don't think it is 100% SCSI compatible... right. Hope, this bug will be fixed soon... I usually turn my scanner on when I need it and not during system boot. Thank you for your help! regards, J?rg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605
[sane-devel] saned does not work with 2.6.23-rc9
do you have anything else on the scsi bus? if not, have you tried rmmod/insmod the scsi driver after you turn on the device? allan On 10/3/07, Joerg Platte lists at naasa.net wrote: Am Mittwoch, 3. Oktober 2007 schrieb abel deuring: # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. [sanei_debug] Setting debug level of sanei_scsi to 255. did not give me any clue, but you already found the cause of the problem :) And since the host adapter driver did not see any devices, we can't expect to get useful output. But at tis point Linux found the scanner and created the device node and an entry in /proc/scsi/scsi and the scanner is turned on and connected. With previous kernels this was sufficient to actually use the scanner. Yes, if the scanner is not known to its host adapter driver, no application will find it :) But it is nevertheless very weird that _some_ SCSI related IOCTLs worked, but SG_GET_SCSI_ID failed, probably for a stale device file. I don't think it is stale, looks more like it is not fully initialized. But maybe the SCSI implementation of the scanner is buggy and recent kernels trigger a bug. The scanner is a Mustek ScanExpress 12SP and I don't think it is 100% SCSI compatible... right. Hope, this bug will be fixed soon... I usually turn my scanner on when I need it and not during system boot. Thank you for your help! regards, J?rg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin
[sane-devel] saned does not work with 2.6.23-rc9
On 03.10.2007 17:26, Joerg Platte wrote: Am Mittwoch, 3. Oktober 2007 schrieb abel deuring: # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. [sanei_debug] Setting debug level of sanei_scsi to 255. did not give me any clue, but you already found the cause of the problem :) And since the host adapter driver did not see any devices, we can't expect to get useful output. But at tis point Linux found the scanner and created the device node and an entry in /proc/scsi/scsi and the scanner is turned on and connected. With previous kernels this was sufficient to actually use the scanner. OK, I misunderstood you. Yes, if the scanner is not known to its host adapter driver, no application will find it :) But it is nevertheless very weird that _some_ SCSI related IOCTLs worked, but SG_GET_SCSI_ID failed, probably for a stale device file. I don't think it is stale, looks more like it is not fully initialized. But maybe the SCSI implementation of the scanner is buggy and recent kernels trigger a bug. The scanner is a Mustek ScanExpress 12SP and I don't think it is 100% SCSI compatible... Well, this scanner might have some compatibility issues, but the SG_GET_SCSI_ID ioctl asks basically for the same data as you can see in /proc/scsi/scsi. Hence this ioctl should work, if the scanner is listed in /proc/scsi/scsi. Looks more like a new bug in the SCSI system of the Linux kernel. right. Hope, this bug will be fixed soon... I usually turn my scanner on when I need it and not during system boot. As Allan already wrote, it might help to rmmod and modprobe the sym53c8xx driver. Only a workaround, but after all, SCSI devices are not detected automatically, so you need to invoke one or the other helper program anyway, if your scanner is not powered on at boot time (which is absolutely reasonable :). Thank you for your help! you're welcome! Abel
