Re: bug: firewire_sbp2 - timing out command
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2013-06-01 14:45:23
|
On Jun 01 Renan Calliari wrote: > Hi people, > > I've never got firewire_sbp2 module working with my Scanner Umax > Powerlook 1000. Instead I used sbp2 module and the scanner works well. > So I decided upgrade from Fedora 12 (ieee1394 kmdl driver) to Fedora 18. Was Fedora 12 the most recent system which you tried successfully with this scanner? > The scanner was recognized, the module send some commands to scanner and > then stop work. > > Additional information > > $ uname -r > 3.9.4-200.fc18.i686.PAE > > $ lsmod | grep -e 1394 -e firewire > firewire_sbp2 18112 0 > firewire_ohci 35451 0 > firewire_core 55929 2 firewire_ohci,firewire_sbp2 > crc_itu_t 12549 1 firewire_core > > $ lspci -vvv > 02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 > [Fire II(M)] IEEE 1394 OHCI Controller (rev 80) (prog-if 10 [OHCI]) > Subsystem: ASUSTeK Computer Inc. A8V/A8N/P4P800 series motherboard > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- > ParErr- Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 64 (8000ns max), Cache Line Size: 16 bytes > Interrupt: pin A routed to IRQ 20 > Region 0: Memory at feaff800 (32-bit, non-prefetchable) [size=2K] > Region 1: I/O ports at dc00 [size=128] > Capabilities: <access denied> > Kernel driver in use: firewire_ohci > > $ dmesg > [ 529.809589] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 > [ 560.384101] firewire_core 0000:02:03.0: giving up on node ffc0: reading config rom failed: send error > [ 701.744212] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 > [ 702.246920] firewire_core 0000:02:03.0: created device fw1: GUID 00102b104100007b, S400 > [ 702.309449] scsi4 : SBP-2 IEEE-1394 > [ 702.514744] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > [ 702.535186] scsi 4:0:0:0: Scanner UMAX PowerLook 1000 V1.3 PQ: 0 ANSI: 2 > [ 702.537121] scsi 4:0:0:0: Attached scsi generic sg4 type 6 > [ 986.535423] scsi 4:0:0:0: timing out command, waited 120s > [ 1107.153430] scsi 4:0:0:0: timing out command, waited 120s > [ 1228.376368] scsi 4:0:0:0: timing out command, waited 120s I would be interested to learn which SCSI request timed out, or which sequence of SCSI requests lead up to the time-out. But right now I don't have a quick recipe how to enable SCSI command logging. At a higher level, can you describe which actions lead up to such timeout events? Do they happen even without running any image acquisition application, or is it happening only after you actually do run such an application and start a scan? If the latter, does it happen at each and every scan, or only randomly? (You can watch for the timeout events for example with a console window, running "sudo tail -f /var/log/messages" in it. Or at least this is the log file which most distributions seem to use to store kernel messages.) > I tried blacklist the modules and the scanner was not recognized > blacklist firewire-ohci > blacklist firewire-sbp2 > blacklist firewire-net This disable FireWire support entirely --- except if FireWire drivers are already loaded in initrd (initial RAM disk), in which such blacklist directives would have to be brought into the initrd itself in order to be effective. This does not bring back FireWire support through the older ohci1394 + ieee1394 + sbp2 drivers because these are not present anymore in kernels 2.6.37 or newer. [...] > I tried this option in modprobe.d directory without success > options sbp2 long_ieee1394_id=y This only affects how /dev/disk/by_id/* symlinks to FireWire HDDs and ODDs are named if you still had the old sbp2 driver. It is immaterial to scanners or/ and to the newer firewire-sbp2 driver. [...] > Is there a source package for the old sbp2 module? I am currently not aware of anybody maintaining such a forward port. There was a guy who kept porting some of the iee1394 drivers to kernels newer than 2.6.36 in order to use them with FireWire audio devices, but I do not remember who it was, how long he kept it up or is keeping it up, and whether he provided sbp2 among those forward ports. Note that it is not obvious yet whether the current behaviour of the scanner under Fedora 18 is caused by the FireWire kernel drivers or the SCSI kernel drivers above it or by a userland component (udev or some low-level desktop integration component or something along these lines) or even by the scanning software itself. Anyhow; while I don't have a scanner among my set of FireWire test devices, I will try to get my hands on one of them and see how it will behave (depending on available spare time). I will keep you posted on my progress, if any. -- Stefan Richter -=====-===-= -==- ----= http://arcgraph.de/sr/ |