Re: bug: firewire_sbp2 - timing out command
Brought to you by:
aeb,
bencollins
Menu
▾
▴
Re: bug: firewire_sbp2 - timing out command
|
From: Jesús P. P. <jes...@gm...> - 2013-06-02 04:28:49
|
Hello everyone, Please, first undestand that I am not fully experienced on firewire as I have started using it just recently, and also I have only worked on Ubuntu distributions. Thus I am not sure whether my feedback can be usable for you. I do believe that the sbp2 part of the old firewire stack is the module that you need to make your sensor work, but I am not 100% sure. Recently, I had to put to work two old firewire cameras which drivers do not work well with the new firewire stack (firewire_ohci, firewire_sbp2, firewire_core). After a long time surfing the web for an answer to my issue I came accross de following GitHub repository: https://github.com/veltzer/ieee1394 This repository currently provided the old firewire modules code for Ubuntu 11.x. The code can be compiled to obtain the firewire modules and install them on such Ubuntu version. After contacting the author of the above mentioned repository, he made some changes to the code on the repository to make it the modules be compilable and installable on Ubuntu 12.04. However he warned me that having a full reliable compatibility of the old firewire modules to Ubuntu 12.04 was something not to be expected due to several changes in recent versions of Ubuntu (sorry, but I cannot elaborate on the details since my knowledge of low level Ubuntu drivers is limited). I must say that the code from the repository has allowed me to work with this cameras without problem on Ubuntu 12.04, on a machine with an Intel dual core processor (64bits). I have decided not to apply any Ubuntu 12.04 updates on this machine. Sometimes I need to restart the old firewire modules because my software fails to initialize the cameras. I believe this is probably a bug on my software, which I have decided to ignore for my current work. My point is, this repository might be a solution to your problem, Jesus Pestana 2013/6/1 Stefan Richter <st...@s5...> > 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/ > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user > |