Thread: bug: firewire_sbp2 - timing out command
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-user
|
From: Renan C. <ren...@te...> - 2013-06-01 13:10:56
|
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.
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 tried blacklist the modules and the scanner was not recognized
blacklist firewire-ohci
blacklist firewire-sbp2
blacklist firewire-net
[ 423.766103] firewire_core 0000:02:03.0: phy config: new root=ffc1,
gap_count=5
[ 454.344054] firewire_core 0000:02:03.0: giving up on node ffc0:
reading config rom failed: send error
[ 608.274940] firewire_core 0000:02:03.0: phy config: new root=ffc1,
gap_count=5
[ 608.776140] firewire_core 0000:02:03.0: created device fw1: GUID
00102b104100007b, S400
I tried this option in modprobe.d directory without success
options sbp2 long_ieee1394_id=y
[ 365.753414] firewire_core 0000:02:03.0: phy config: new root=ffc1,
gap_count=5
[ 396.368071] firewire_core 0000:02:03.0: giving up on node ffc0:
reading config rom failed: send error
[ 537.562657] firewire_core 0000:02:03.0: phy config: new root=ffc1,
gap_count=5
[ 538.065346] firewire_core 0000:02:03.0: created device fw1: GUID
00102b104100007b, S400
[ 538.208760] scsi4 : SBP-2 IEEE-1394
[ 538.413848] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries)
[ 538.434161] scsi 4:0:0:0: Scanner UMAX PowerLook 1000
V1.3 PQ: 0 ANSI: 2
[ 538.436127] scsi 4:0:0:0: Attached scsi generic sg4 type 6
[ 758.903434] scsi 4:0:0:0: timing out command, waited 120s
Is there a source package for the old sbp2 module?
Renan Calliari
|
|
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/ |
|
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 > |
|
From: Stefan R. <st...@s5...> - 2013-06-02 14:46:09
|
On Jun 01 Jesús Pestana Puerta wrote: > 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 [...] > 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. [...] What camera models do you have? And which 1394 controller? (E.g. "lspci -nn | grep 1394".) Is the software a standard IEEE 1394 based software like coriander, dvgrab, kino or the likes, or is it a generic software like skype etc., or is it a custom software written by yourself? Is the software accessing the kernel through a library or framework (libraw1394, libdc1394, gstreamer, dv4l, ...)? -- Stefan Richter -=====-===-= -==- ---=- http://arcgraph.de/sr/ |
|
From: Clemens L. <cl...@la...> - 2013-06-02 19:03:42
|
Jesús Pestana Puerta wrote: >> And which 1394 controller? > > These are the modules ... Which controller chip? (see lspci) Regards, Clemens |
|
From: Jesús P. P. <jes...@gm...> - 2013-06-02 19:22:25
|
Hello, Unfortunately I cannot answer that now (I do not have the computer here). I will answer this during the week. Sorry! Jesús 2013/6/2 Clemens Ladisch <cl...@la...> > Jesús Pestana Puerta wrote: > >> And which 1394 controller? > > > > These are the modules ... > > Which controller chip? (see lspci) > > > Regards, > Clemens > |
|
From: Jesús P. P. <jes...@gm...> - 2013-06-07 01:38:41
|
Actually I don't have access to that computer [the one with the firewire cameras] until next week [the security on the building where I work is enforced by id cards...]. I will meet with this person next week, I will send you the information as soon as possible, sorry for the delay... Regards, Jesus 2013/6/2 Clemens Ladisch <cl...@la...> > Jesús Pestana Puerta wrote: > >> And which 1394 controller? > > > > These are the modules ... > > Which controller chip? (see lspci) > > > Regards, > Clemens > |
|
From: Stefan R. <st...@s5...> - 2013-06-06 16:57:06
|
On Jun 01 Stefan Richter wrote: > 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. I now got an Epson Perfection 2450 Photo and did a first quick test with it, using a Texas Instruments TSB43AB22A based controller card, kernel 3.9, Gentoo Linux, sane-backends 1.0.23, skanlite 1.0. First I tested it on USB as a baseline, then switch it off, connected to FireWire, switched it back on, and tested again. It behaved the same on both interfaces. (The only thing was that I had to load the "sg" kernel module manually in order to make the scanner accessible via FireWire.) Here is the syslog from the FireWire session: [as root, to enable selfID logging: echo 2 > /sys/module/firewire_ohci/parameters/debug] Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: 2 selfIDs, generation 3, local node ID ffc1 Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: selfID 0: 807f8092, phy 0 [p-.] S400 gc=63 +0W Li Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: selfID 0: 817f8cd0, phy 1 [c-.] S400 gc=63 -3W Lc Jun 6 18:19:16 stein kernel: firewire_core 0000:0d:00.0: rediscovered device fw7 Jun 6 18:19:16 stein kernel: firewire_core 0000:0d:00.0: phy config: new root=ffc1, gap_count=5 Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: 2 selfIDs, generation 4, local node ID ffc1 Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: selfID 0: 80458090, phy 0 [p-.] S400 gc=5 +0W L Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: selfID 0: 81458cd2, phy 1 [c-.] S400 gc=5 -3W Lci Jun 6 18:19:19 stein kernel: scsi122 : SBP-2 IEEE-1394 Jun 6 18:19:19 stein kernel: firewire_sbp2 fw8.0: 127s mgt_ORB_timeout limited to 40s Jun 6 18:19:19 stein kernel: firewire_core 0000:0d:00.0: created device fw8: GUID 000048000005943d, S400 Jun 6 18:19:20 stein kernel: firewire_sbp2 fw8.0: logged in to LUN 0000 (0 retries) Jun 6 18:19:20 stein kernel: scsi 122:0:0:0: Processor EPSON GT-9700 1.05 PQ: 0 ANSI: 4 [as root: modprobe sg] Jun 6 18:26:22 stein kernel: scsi 122:0:0:0: Attached scsi generic sg7 type 3 (Embarrassingly, it took me a whole 7 minutes to figure out that sg's absence was the reason for skanlite's not finding the scanner right away.) Later this month I will probably get the opportunity to test a UMAX PowerLook 1100 Pro, which is hopefully close enough to your PowerLook 1000. -- Stefan Richter -=====-===-= -==- --==- http://arcgraph.de/sr/ |
|
From: Stefan R. <st...@s5...> - 2013-06-07 13:26:25
|
Here are two messages for the mailinglist, for now without further comment from me. On Jun 06 Renan Calliari wrote: > Thanks for your answer, > > I'll try build the old stack. > If interest you, VueScan has a log in hex mode. It was one of the ways I > helped Ed Hamrick to develop VueScan for Umax scanners. > VueScan for linux ( http://www.hamrick.com/ ) does not recognize > PowerLook 1000 scanner under USB interface too. Just in firewire mode. > According VueScan's developer Umax scanners, for this generation, has > the same way to work. Renan Calliari wrote: > Stefan Richter, > I will try answer your questions: > > Was Fedora 12 the most recent system which you tried successfully with > this scanner? > > Yes,this is the most recent distro because this scanner is installed in my > office and I need the system working, but I knew the firewire problems around > my scanner under firewire_sbp2 module. > > 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? > > I use VueScan software without problems with sbp2 module. Firewire_sbp2 module > in kernel 3.9 recognize the Scanner, in older versions (FC8, FC10, FC12) it > not happened. > Every time I try use the scanner with Vuescan software "timeout events" occur. > Looks like the scann task will take a lot of hours. > It just happens if I try a scan an image. > > For SCSI log method read the following links, it can help to you understand > what I can't comprehend. > > http://www.novell.com/support/kb/doc.php?id=7007138 > http://www.kolbu.com/2008/03/18/excessive-scsi-logging-under-ubuntu/ > > 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. > > > I hope it help you! No image was acquired in this process. It just represent > VuesScan software trying to scann. for some minutes. > > [renan@localhost ~]$ su > Senha: > [root@localhost renan]# sysctl -w dev.scsi.logging_level=0x180000F1 dev.scsi.logging_level = 0x180000F1 > [root@localhost renan]# tail -f /var/log/messages > Jun 4 15:44:16 localhost dbus-daemon[434]: dbus[434]: [system] Successfully activated service 'net.reactivated.Fprint' > Jun 4 15:44:16 localhost dbus[434]: [system] Successfully activated service 'net.reactivated.Fprint' > Jun 4 15:44:16 localhost dbus-daemon[434]: Launching FprintObject > Jun 4 15:44:16 localhost dbus-daemon[434]: ** Message: D-Bus service launched with name: net.reactivated.Fprint > Jun 4 15:44:16 localhost dbus-daemon[434]: ** Message: entering main loop > Jun 4 15:44:46 localhost dbus-daemon[434]: ** Message: No devices in use, exit > Jun 4 15:45:56 localhost dbus-daemon[434]: dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 15:45:56 localhost dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 15:45:56 localhost dbus-daemon[434]: dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 15:45:56 localhost dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 15:46:04 localhost kernel: [ 1160.287709] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 > Jun 4 15:46:35 localhost kernel: [ 1190.864068] firewire_core 0000:02:03.0: giving up on node ffc0: reading config rom failed: send error > Jun 4 15:48:12 localhost kernel: [ 1288.050791] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.057341] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.057493] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.057880] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.059275] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.349390] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.351179] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.351327] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.372120] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:48:12 localhost kernel: [ 1288.397937] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:48:44 localhost kernel: [ 1319.534211] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 > Jun 4 15:48:44 localhost kernel: [ 1320.036251] firewire_core 0000:02:03.0: created device fw1: GUID 00102b104100007b, S400 > Jun 4 15:48:44 localhost kernel: [ 1320.093824] scsi5 : SBP-2 IEEE-1394 > Jun 4 15:48:44 localhost kernel: [ 1320.298844] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > Jun 4 15:48:44 localhost kernel: [ 1320.319294] scsi 5:0:0:0: Scanner UMAX PowerLook 1000 V1.3 PQ: 0 ANSI: 2 > Jun 4 15:48:44 localhost kernel: [ 1320.319508] sg_alloc: dev=4 > Jun 4 15:48:44 localhost kernel: [ 1320.319603] scsi 5:0:0:0: Attached scsi generic sg4 type 6 > Jun 4 15:48:59 localhost kernel: [ 1335.471782] sg_open: dev=1, flags=0x8800 > Jun 4 15:48:59 localhost kernel: [ 1335.471799] sg_add_sfp: sfp=0xf2cbf000 > Jun 4 15:48:59 localhost kernel: [ 1335.471803] sg_build_reserve: req_size=32768 > Jun 4 15:48:59 localhost kernel: [ 1335.471807] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:48:59 localhost kernel: [ 1335.471832] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:48:59 localhost kernel: [ 1335.471835] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:48:59 localhost kernel: [ 1335.471838] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:48:59 localhost kernel: [ 1335.471849] sg_release: sg1 > Jun 4 15:48:59 localhost kernel: [ 1335.471867] sg_remove_scat: k_use_sg=1 > Jun 4 15:48:59 localhost kernel: [ 1335.471871] sg_remove_scat: k=0, pg=0xf522d900 > Jun 4 15:48:59 localhost kernel: [ 1335.473545] sg_open: dev=4, flags=0x8800 > Jun 4 15:48:59 localhost kernel: [ 1335.473560] sg_add_sfp: sfp=0xf2cb8000 > Jun 4 15:48:59 localhost kernel: [ 1335.473564] sg_build_reserve: req_size=32768 > Jun 4 15:48:59 localhost kernel: [ 1335.473567] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:48:59 localhost kernel: [ 1335.473600] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:48:59 localhost kernel: [ 1335.473602] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:48:59 localhost kernel: [ 1335.473605] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:48:59 localhost kernel: [ 1335.473615] sg_release: sg4 > Jun 4 15:48:59 localhost kernel: [ 1335.473631] sg_remove_scat: k_use_sg=1 > Jun 4 15:48:59 localhost kernel: [ 1335.473635] sg_remove_scat: k=0, pg=0xf522df00 > Jun 4 15:49:00 localhost kernel: [ 1336.069753] sg_open: dev=1, flags=0x802 > Jun 4 15:49:00 localhost kernel: [ 1336.069772] sg_add_sfp: sfp=0xf2cbf000 > Jun 4 15:49:00 localhost kernel: [ 1336.069776] sg_build_reserve: req_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.069779] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.069820] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.069823] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.069825] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.069832] sg_release: sg1 > Jun 4 15:49:00 localhost kernel: [ 1336.069864] sg_remove_scat: k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.069868] sg_remove_scat: k=0, pg=0xf522d900 > Jun 4 15:49:00 localhost kernel: [ 1336.069897] sg_open: dev=1, flags=0x802 > Jun 4 15:49:00 localhost kernel: [ 1336.069906] sg_add_sfp: sfp=0xf2cb8000 > Jun 4 15:49:00 localhost kernel: [ 1336.069909] sg_build_reserve: req_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.069912] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.069953] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.069955] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.069957] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.069974] sg_ioctl: sg1, cmd=0x2276 > Jun 4 15:49:00 localhost kernel: [ 1336.069979] sg_release: sg1 > Jun 4 15:49:00 localhost kernel: [ 1336.069989] sg_remove_scat: k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.069992] sg_remove_scat: k=0, pg=0xf522df00 > Jun 4 15:49:00 localhost kernel: [ 1336.073003] sg_open: dev=4, flags=0x802 > Jun 4 15:49:00 localhost kernel: [ 1336.073715] sg_add_sfp: sfp=0xf2cbf000 > Jun 4 15:49:00 localhost kernel: [ 1336.073723] sg_build_reserve: req_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.073726] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.073762] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.073765] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.073767] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.073783] sg_ioctl: sg4, cmd=0x2276 > Jun 4 15:49:00 localhost kernel: [ 1336.073792] sg_release: sg4 > Jun 4 15:49:00 localhost kernel: [ 1336.073808] sg_remove_scat: k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.073811] sg_remove_scat: k=0, pg=0xf522d900 > Jun 4 15:49:00 localhost kernel: [ 1336.073838] sg_open: dev=4, flags=0x2 > Jun 4 15:49:00 localhost kernel: [ 1336.073848] sg_add_sfp: sfp=0xf2cb8000 > Jun 4 15:49:00 localhost kernel: [ 1336.073851] sg_build_reserve: req_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.073853] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.073894] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.073897] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.073899] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.073908] sg_ioctl: sg4, cmd=0x2275 > Jun 4 15:49:00 localhost kernel: [ 1336.073911] sg_remove_scat: k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.073913] sg_remove_scat: k=0, pg=0xf522df00 > Jun 4 15:49:00 localhost kernel: [ 1336.073917] sg_build_reserve: req_size=131072 > Jun 4 15:49:00 localhost kernel: [ 1336.073919] sg_build_indirect: buff_size=131072, blk_size=131072 > Jun 4 15:49:00 localhost kernel: [ 1336.073953] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.073981] sg_build_indirect: k=1, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.074000] sg_build_indirect: k=2, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.074237] sg_build_indirect: k=3, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.074242] sg_build_indirect: k_use_sg=4, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.077830] sg_ioctl: sg4, cmd=0x2272 > Jun 4 15:49:00 localhost kernel: [ 1336.077844] sg_release: sg4 > Jun 4 15:49:00 localhost kernel: [ 1336.077865] sg_remove_scat: k_use_sg=4 > Jun 4 15:49:00 localhost kernel: [ 1336.077869] sg_remove_scat: k=0, pg=0xf522d900 > Jun 4 15:49:00 localhost kernel: [ 1336.077875] sg_remove_scat: k=1, pg=0xf522df00 > Jun 4 15:49:00 localhost kernel: [ 1336.077878] sg_remove_scat: k=2, pg=0xf522b400 > Jun 4 15:49:00 localhost kernel: [ 1336.077882] sg_remove_scat: k=3, pg=0xf522b500 > Jun 4 15:49:00 localhost kernel: [ 1336.080673] sg_open: dev=1, flags=0x882 > Jun 4 15:49:00 localhost kernel: [ 1336.080688] sg_add_sfp: sfp=0xf2cbf000 > Jun 4 15:49:00 localhost kernel: [ 1336.080692] sg_build_reserve: req_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.080695] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.080727] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.080729] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.080732] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.080740] sg_ioctl: sg1, cmd=0x2201 > Jun 4 15:49:00 localhost kernel: [ 1336.080746] sg_ioctl: sg1, cmd=0x2282 > Jun 4 15:49:00 localhost kernel: [ 1336.080749] sg_ioctl: sg1, cmd=0x2276 > Jun 4 15:49:00 localhost kernel: [ 1336.080754] sg_release: sg1 > Jun 4 15:49:00 localhost kernel: [ 1336.080774] sg_remove_scat: k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.080778] sg_remove_scat: k=0, pg=0xf522d900 > Jun 4 15:49:00 localhost kernel: [ 1336.083339] sg_open: dev=4, flags=0x882 > Jun 4 15:49:00 localhost kernel: [ 1336.083355] sg_add_sfp: sfp=0xf2cb8000 > Jun 4 15:49:00 localhost kernel: [ 1336.083359] sg_build_reserve: req_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.083362] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.083395] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.083398] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.083401] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.083411] sg_ioctl: sg4, cmd=0x2201 > Jun 4 15:49:00 localhost kernel: [ 1336.083417] sg_ioctl: sg4, cmd=0x2282 > Jun 4 15:49:00 localhost kernel: [ 1336.083421] sg_ioctl: sg4, cmd=0x2276 > Jun 4 15:49:00 localhost kernel: [ 1336.083424] sg_ioctl: sg4, cmd=0x2275 > Jun 4 15:49:00 localhost kernel: [ 1336.083427] sg_remove_scat: k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.083429] sg_remove_scat: k=0, pg=0xf522df00 > Jun 4 15:49:00 localhost kernel: [ 1336.083434] sg_build_reserve: req_size=131072 > Jun 4 15:49:00 localhost kernel: [ 1336.083437] sg_build_indirect: buff_size=131072, blk_size=131072 > Jun 4 15:49:00 localhost kernel: [ 1336.083476] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.083507] sg_build_indirect: k=1, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.083527] sg_build_indirect: k=2, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.083566] sg_build_indirect: k=3, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.083568] sg_build_indirect: k_use_sg=4, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.083572] sg_ioctl: sg4, cmd=0x2272 > Jun 4 15:49:00 localhost kernel: [ 1336.083576] sg_ioctl: sg4, cmd=0x2276 > Jun 4 15:49:00 localhost kernel: [ 1336.083579] sg_ioctl: sg4, cmd=0x2271 > Jun 4 15:49:00 localhost kernel: [ 1336.083661] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:00 localhost kernel: [ 1336.083669] sg_common_write: scsi opcode=0x12, cmd_size=6 > Jun 4 15:49:00 localhost kernel: [ 1336.083672] sg_start_req: dxfer_len=36 > Jun 4 15:49:00 localhost kernel: [ 1336.083679] sg_link_reserve: size=36 > Jun 4 15:49:00 localhost kernel: [ 1336.090565] sg_cmd_done: sg4, pack_id=0, res=0x0 > Jun 4 15:49:00 localhost kernel: [ 1336.091218] sg_finish_rem_req: res_used=1 > Jun 4 15:49:00 localhost kernel: [ 1336.091232] sg_unlink_reserve: req->k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.193095] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:00 localhost kernel: [ 1336.193107] sg_common_write: scsi opcode=0x16, cmd_size=6 > Jun 4 15:49:00 localhost kernel: [ 1336.193110] sg_start_req: dxfer_len=0 > Jun 4 15:49:00 localhost kernel: [ 1336.196498] sg_cmd_done: sg4, pack_id=1, res=0x8000002 > Jun 4 15:49:00 localhost kernel: [ 1336.196874] sg_finish_rem_req: res_used=0 > Jun 4 15:49:00 localhost kernel: [ 1336.196883] sg_remove_scat: k_use_sg=0 > Jun 4 15:49:00 localhost kernel: [ 1336.298716] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:00 localhost kernel: [ 1336.298727] sg_common_write: scsi opcode=0x12, cmd_size=6 > Jun 4 15:49:00 localhost kernel: [ 1336.298730] sg_start_req: dxfer_len=157 > Jun 4 15:49:00 localhost kernel: [ 1336.298741] sg_link_reserve: size=157 > Jun 4 15:49:00 localhost kernel: [ 1336.311716] sg_cmd_done: sg4, pack_id=2, res=0x0 > Jun 4 15:49:00 localhost kernel: [ 1336.311771] sg_finish_rem_req: res_used=1 > Jun 4 15:49:00 localhost kernel: [ 1336.311784] sg_unlink_reserve: req->k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.413941] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:00 localhost kernel: [ 1336.413953] sg_common_write: scsi opcode=0x17, cmd_size=6 > Jun 4 15:49:00 localhost kernel: [ 1336.413956] sg_start_req: dxfer_len=0 > Jun 4 15:49:00 localhost kernel: [ 1336.417326] sg_cmd_done: sg4, pack_id=3, res=0x0 > Jun 4 15:49:00 localhost kernel: [ 1336.417694] sg_finish_rem_req: res_used=0 > Jun 4 15:49:00 localhost kernel: [ 1336.417703] sg_remove_scat: k_use_sg=0 > Jun 4 15:49:00 localhost kernel: [ 1336.417815] sg_release: sg4 > Jun 4 15:49:00 localhost kernel: [ 1336.417830] sg_remove_scat: k_use_sg=4 > Jun 4 15:49:00 localhost kernel: [ 1336.417834] sg_remove_scat: k=0, pg=0xf522d900 > Jun 4 15:49:00 localhost kernel: [ 1336.417842] sg_remove_scat: k=1, pg=0xf522df00 > Jun 4 15:49:00 localhost kernel: [ 1336.417845] sg_remove_scat: k=2, pg=0xf522b400 > Jun 4 15:49:00 localhost kernel: [ 1336.417849] sg_remove_scat: k=3, pg=0xf522b500 > Jun 4 15:49:00 localhost kernel: [ 1336.425832] sg_open: dev=4, flags=0x882 > Jun 4 15:49:00 localhost kernel: [ 1336.425849] sg_add_sfp: sfp=0xf2cbf000 > Jun 4 15:49:00 localhost kernel: [ 1336.425853] sg_build_reserve: req_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.425856] sg_build_indirect: buff_size=32768, blk_size=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.425886] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.425889] sg_build_indirect: k_use_sg=1, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.425891] sg_add_sfp: bufflen=32768, k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.425901] sg_ioctl: sg4, cmd=0x2201 > Jun 4 15:49:00 localhost kernel: [ 1336.425906] sg_ioctl: sg4, cmd=0x2282 > Jun 4 15:49:00 localhost kernel: [ 1336.425910] sg_ioctl: sg4, cmd=0x2276 > Jun 4 15:49:00 localhost kernel: [ 1336.425913] sg_ioctl: sg4, cmd=0x2275 > Jun 4 15:49:00 localhost kernel: [ 1336.425916] sg_remove_scat: k_use_sg=1 > Jun 4 15:49:00 localhost kernel: [ 1336.425919] sg_remove_scat: k=0, pg=0xf522d900 > Jun 4 15:49:00 localhost kernel: [ 1336.425923] sg_build_reserve: req_size=131072 > Jun 4 15:49:00 localhost kernel: [ 1336.425926] sg_build_indirect: buff_size=131072, blk_size=131072 > Jun 4 15:49:00 localhost kernel: [ 1336.425963] sg_build_indirect: k=0, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.425994] sg_build_indirect: k=1, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.426054] sg_build_indirect: k=2, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.426096] sg_build_indirect: k=3, num=32768, ret_sz=32768 > Jun 4 15:49:00 localhost kernel: [ 1336.426098] sg_build_indirect: k_use_sg=4, rem_sz=0 > Jun 4 15:49:00 localhost kernel: [ 1336.428884] sg_ioctl: sg4, cmd=0x2272 > Jun 4 15:49:00 localhost kernel: [ 1336.428894] sg_ioctl: sg4, cmd=0x2276 > Jun 4 15:49:00 localhost kernel: [ 1336.428898] sg_ioctl: sg4, cmd=0x2271 > Jun 4 15:49:00 localhost kernel: [ 1336.428954] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:00 localhost kernel: [ 1336.428961] sg_common_write: scsi opcode=0x12, cmd_size=6 > Jun 4 15:49:00 localhost kernel: [ 1336.428964] sg_start_req: dxfer_len=36 > Jun 4 15:49:00 localhost kernel: [ 1336.428973] sg_link_reserve: size=36 > Jun 4 15:49:00 localhost kernel: [ 1336.435519] sg_cmd_done: sg4, pack_id=4, res=0x0 > Jun 4 15:49:00 localhost kernel: [ 1336.435909] sg_finish_rem_req: res_used=1 > Jun 4 15:49:00 localhost kernel: [ 1336.435921] sg_unlink_reserve: req->k_use_sg=1 > Jun 4 15:49:01 localhost kernel: [ 1336.537708] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:01 localhost kernel: [ 1336.537719] sg_common_write: scsi opcode=0x16, cmd_size=6 > Jun 4 15:49:01 localhost kernel: [ 1336.537722] sg_start_req: dxfer_len=0 > Jun 4 15:49:01 localhost kernel: [ 1336.541095] sg_cmd_done: sg4, pack_id=5, res=0x0 > Jun 4 15:49:01 localhost kernel: [ 1336.541596] sg_finish_rem_req: res_used=0 > Jun 4 15:49:01 localhost kernel: [ 1336.541606] sg_remove_scat: k_use_sg=0 > Jun 4 15:49:03 localhost kernel: [ 1338.971913] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:03 localhost kernel: [ 1338.971923] sg_common_write: scsi opcode=0x17, cmd_size=6 > Jun 4 15:49:03 localhost kernel: [ 1338.971926] sg_start_req: dxfer_len=0 > Jun 4 15:49:03 localhost kernel: [ 1338.975389] sg_cmd_done: sg4, pack_id=6, res=0x0 > Jun 4 15:49:03 localhost kernel: [ 1338.976055] sg_finish_rem_req: res_used=0 > Jun 4 15:49:03 localhost kernel: [ 1338.976066] sg_remove_scat: k_use_sg=0 > Jun 4 15:49:03 localhost kernel: [ 1338.976367] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:03 localhost kernel: [ 1338.976375] sg_common_write: scsi opcode=0x12, cmd_size=6 > Jun 4 15:49:03 localhost kernel: [ 1338.976378] sg_start_req: dxfer_len=36 > Jun 4 15:49:03 localhost kernel: [ 1338.976385] sg_link_reserve: size=36 > Jun 4 15:49:03 localhost kernel: [ 1338.982860] sg_cmd_done: sg4, pack_id=7, res=0x0 > Jun 4 15:49:03 localhost kernel: [ 1338.983494] sg_finish_rem_req: res_used=1 > Jun 4 15:49:03 localhost kernel: [ 1338.983508] sg_unlink_reserve: req->k_use_sg=1 > Jun 4 15:49:03 localhost kernel: [ 1339.084923] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:03 localhost kernel: [ 1339.084934] sg_common_write: scsi opcode=0x16, cmd_size=6 > Jun 4 15:49:03 localhost kernel: [ 1339.084937] sg_start_req: dxfer_len=0 > Jun 4 15:49:03 localhost kernel: [ 1339.088310] sg_cmd_done: sg4, pack_id=8, res=0x0 > Jun 4 15:49:03 localhost kernel: [ 1339.088706] sg_finish_rem_req: res_used=0 > Jun 4 15:49:03 localhost kernel: [ 1339.088715] sg_remove_scat: k_use_sg=0 > Jun 4 15:49:14 localhost kernel: [ 1350.317295] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:14 localhost kernel: [ 1350.317306] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 15:49:14 localhost kernel: [ 1350.317309] sg_start_req: dxfer_len=0 > Jun 4 15:49:14 localhost kernel: [ 1350.320674] sg_cmd_done: sg4, pack_id=9, res=0x0 > Jun 4 15:49:14 localhost kernel: [ 1350.321374] sg_finish_rem_req: res_used=0 > Jun 4 15:49:14 localhost kernel: [ 1350.321385] sg_remove_scat: k_use_sg=0 > Jun 4 15:49:14 localhost kernel: [ 1350.425124] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:14 localhost kernel: [ 1350.425136] sg_common_write: scsi opcode=0x2a, cmd_size=10 > Jun 4 15:49:14 localhost kernel: [ 1350.425139] sg_start_req: dxfer_len=32774 > Jun 4 15:49:14 localhost kernel: [ 1350.425148] sg_link_reserve: size=32774 > Jun 4 15:49:14 localhost kernel: [ 1350.440354] sg_cmd_done: sg4, pack_id=10, res=0x0 > Jun 4 15:49:14 localhost kernel: [ 1350.440398] sg_finish_rem_req: res_used=1 > Jun 4 15:49:14 localhost kernel: [ 1350.440409] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 15:49:15 localhost kernel: [ 1350.542111] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:15 localhost kernel: [ 1350.542121] sg_common_write: scsi opcode=0x2a, cmd_size=10 > Jun 4 15:49:15 localhost kernel: [ 1350.542124] sg_start_req: dxfer_len=32774 > Jun 4 15:49:15 localhost kernel: [ 1350.542133] sg_link_reserve: size=32774 > Jun 4 15:49:15 localhost kernel: [ 1350.573176] sg_cmd_done: sg4, pack_id=11, res=0x0 > Jun 4 15:49:15 localhost kernel: [ 1350.573234] sg_finish_rem_req: res_used=1 > Jun 4 15:49:15 localhost kernel: [ 1350.573245] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 15:49:15 localhost kernel: [ 1350.674730] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:15 localhost kernel: [ 1350.674741] sg_common_write: scsi opcode=0x2a, cmd_size=10 > Jun 4 15:49:15 localhost kernel: [ 1350.674745] sg_start_req: dxfer_len=32774 > Jun 4 15:49:15 localhost kernel: [ 1350.674754] sg_link_reserve: size=32774 > Jun 4 15:49:15 localhost kernel: [ 1350.694138] sg_cmd_done: sg4, pack_id=12, res=0x0 > Jun 4 15:49:15 localhost kernel: [ 1350.694176] sg_finish_rem_req: res_used=1 > Jun 4 15:49:15 localhost kernel: [ 1350.694186] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 15:49:15 localhost kernel: [ 1350.795528] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:15 localhost kernel: [ 1350.795538] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 15:49:15 localhost kernel: [ 1350.795542] sg_start_req: dxfer_len=0 > Jun 4 15:49:15 localhost kernel: [ 1350.798914] sg_cmd_done: sg4, pack_id=13, res=0x0 > Jun 4 15:49:15 localhost kernel: [ 1350.799347] sg_finish_rem_req: res_used=0 > Jun 4 15:49:15 localhost kernel: [ 1350.799356] sg_remove_scat: k_use_sg=0 > Jun 4 15:49:15 localhost kernel: [ 1350.900598] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:15 localhost kernel: [ 1350.900610] sg_common_write: scsi opcode=0x24, cmd_size=10 > Jun 4 15:49:15 localhost kernel: [ 1350.900613] sg_start_req: dxfer_len=254 > Jun 4 15:49:15 localhost kernel: [ 1350.900622] sg_link_reserve: size=254 > Jun 4 15:49:15 localhost kernel: [ 1351.237697] sg_cmd_done: sg4, pack_id=14, res=0x0 > Jun 4 15:49:15 localhost kernel: [ 1351.238313] sg_finish_rem_req: res_used=1 > Jun 4 15:49:15 localhost kernel: [ 1351.238327] sg_unlink_reserve: req->k_use_sg=1 > Jun 4 15:49:15 localhost kernel: [ 1351.341260] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:49:15 localhost kernel: [ 1351.341272] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 15:49:15 localhost kernel: [ 1351.341275] sg_start_req: dxfer_len=0 > Jun 4 15:51:15 localhost kernel: [ 1471.350384] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 15:51:15 localhost kernel: [ 1471.350414] sg_cmd_done: sg4, pack_id=15, res=0x8000008 > Jun 4 15:51:15 localhost kernel: [ 1471.350439] sg_finish_rem_req: res_used=0 > Jun 4 15:51:15 localhost kernel: [ 1471.350446] sg_remove_scat: k_use_sg=0 > Jun 4 15:51:16 localhost kernel: [ 1471.960526] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:51:16 localhost kernel: [ 1471.960537] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 15:51:16 localhost kernel: [ 1471.960540] sg_start_req: dxfer_len=0 > Jun 4 15:51:56 localhost dbus-daemon[434]: dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 15:51:56 localhost dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 15:51:56 localhost dbus-daemon[434]: dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 15:51:56 localhost dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 15:53:16 localhost kernel: [ 1591.962403] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 15:53:16 localhost kernel: [ 1591.962438] sg_cmd_done: sg4, pack_id=16, res=0x8000008 > Jun 4 15:53:16 localhost kernel: [ 1591.963344] sg_finish_rem_req: res_used=0 > Jun 4 15:53:16 localhost kernel: [ 1591.963355] sg_remove_scat: k_use_sg=0 > Jun 4 15:53:16 localhost kernel: [ 1592.064587] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:53:16 localhost kernel: [ 1592.064597] sg_common_write: scsi opcode=0x1b, cmd_size=6 > Jun 4 15:53:16 localhost kernel: [ 1592.064600] sg_start_req: dxfer_len=0 > Jun 4 15:53:16 localhost kernel: [ 1592.090477] sg_cmd_done: sg4, pack_id=17, res=0x0 > Jun 4 15:53:16 localhost kernel: [ 1592.090893] sg_finish_rem_req: res_used=0 > Jun 4 15:53:16 localhost kernel: [ 1592.090903] sg_remove_scat: k_use_sg=0 > Jun 4 15:53:17 localhost kernel: [ 1593.193163] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:53:17 localhost kernel: [ 1593.193174] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 15:53:17 localhost kernel: [ 1593.193177] sg_start_req: dxfer_len=0 > Jun 4 15:55:17 localhost kernel: [ 1713.194440] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 15:55:17 localhost kernel: [ 1713.194471] sg_cmd_done: sg4, pack_id=18, res=0x8000008 > Jun 4 15:55:17 localhost kernel: [ 1713.195309] sg_finish_rem_req: res_used=0 > Jun 4 15:55:17 localhost kernel: [ 1713.195320] sg_remove_scat: k_use_sg=0 > Jun 4 15:55:18 localhost kernel: [ 1713.797700] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:55:18 localhost kernel: [ 1713.797710] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 15:55:18 localhost kernel: [ 1713.797713] sg_start_req: dxfer_len=0 > Jun 4 15:57:14 localhost kernel: [ 1829.742020] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:57:14 localhost kernel: [ 1829.742165] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:57:14 localhost kernel: [ 1829.792917] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:57:14 localhost kernel: [ 1829.819153] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:57:14 localhost kernel: [ 1829.819315] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:57:14 localhost smartd[427]: Device: /dev/sdc [SAT], FAILED SMART self-check. BACK UP DATA NOW! > Jun 4 15:57:14 localhost kernel: [ 1829.821296] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:57:14 localhost smartd[427]: Device: /dev/sdc [SAT], 31 Currently unreadable (pending) sectors > Jun 4 15:57:18 localhost kernel: [ 1833.800384] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 15:57:18 localhost kernel: [ 1833.800418] sg_cmd_done: sg4, pack_id=19, res=0x8000008 > Jun 4 15:57:18 localhost kernel: [ 1833.801235] sg_finish_rem_req: res_used=0 > Jun 4 15:57:18 localhost kernel: [ 1833.801246] sg_remove_scat: k_use_sg=0 > Jun 4 15:57:18 localhost kernel: [ 1833.912156] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:57:18 localhost kernel: [ 1833.912168] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 15:57:18 localhost kernel: [ 1833.912171] sg_start_req: dxfer_len=0 > Jun 4 15:57:56 localhost dbus-daemon[434]: dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 15:57:56 localhost dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 15:57:56 localhost dbus-daemon[434]: dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 15:57:56 localhost dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 15:58:12 localhost kernel: [ 1888.095641] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.102179] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.102332] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.102718] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.104215] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.411856] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.413338] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.413489] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.431244] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:58:12 localhost kernel: [ 1888.457211] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 15:59:18 localhost kernel: [ 1953.914405] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 15:59:18 localhost kernel: [ 1953.914438] sg_cmd_done: sg4, pack_id=20, res=0x8000008 > Jun 4 15:59:18 localhost kernel: [ 1953.915460] sg_finish_rem_req: res_used=0 > Jun 4 15:59:18 localhost kernel: [ 1953.915472] sg_remove_scat: k_use_sg=0 > Jun 4 15:59:18 localhost kernel: [ 1953.915610] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:59:18 localhost kernel: [ 1953.915616] sg_common_write: scsi opcode=0x28, cmd_size=10 > Jun 4 15:59:18 localhost kernel: [ 1953.915619] sg_start_req: dxfer_len=59520 > Jun 4 15:59:18 localhost kernel: [ 1953.915626] sg_link_reserve: size=59520 > Jun 4 15:59:18 localhost kernel: [ 1953.933354] sg_cmd_done: sg4, pack_id=21, res=0x0 > Jun 4 15:59:18 localhost kernel: [ 1953.933391] sg_finish_rem_req: res_used=1 > Jun 4 15:59:18 localhost kernel: [ 1953.933489] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 15:59:18 localhost kernel: [ 1954.035909] sg_ioctl: sg4, cmd=0x2285 > Jun 4 15:59:18 localhost kernel: [ 1954.035920] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 15:59:18 localhost kernel: [ 1954.035923] sg_start_req: dxfer_len=0 > Jun 4 16:01:18 localhost kernel: [ 2074.037420] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 16:01:18 localhost kernel: [ 2074.037454] sg_cmd_done: sg4, pack_id=22, res=0x8000008 > Jun 4 16:01:18 localhost kernel: [ 2074.038339] sg_finish_rem_req: res_used=0 > Jun 4 16:01:18 localhost kernel: [ 2074.038351] sg_remove_scat: k_use_sg=0 > Jun 4 16:01:18 localhost kernel: [ 2074.038525] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:01:18 localhost kernel: [ 2074.038532] sg_common_write: scsi opcode=0x28, cmd_size=10 > Jun 4 16:01:18 localhost kernel: [ 2074.038534] sg_start_req: dxfer_len=59520 > Jun 4 16:01:18 localhost kernel: [ 2074.038541] sg_link_reserve: size=59520 > Jun 4 16:01:18 localhost kernel: [ 2074.056409] sg_cmd_done: sg4, pack_id=23, res=0x0 > Jun 4 16:01:18 localhost kernel: [ 2074.056436] sg_finish_rem_req: res_used=1 > Jun 4 16:01:18 localhost kernel: [ 2074.056537] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 16:01:18 localhost kernel: [ 2074.159050] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:01:18 localhost kernel: [ 2074.159060] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 16:01:18 localhost kernel: [ 2074.159063] sg_start_req: dxfer_len=0 > Jun 4 16:03:18 localhost kernel: [ 2194.165399] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 16:03:18 localhost kernel: [ 2194.165433] sg_cmd_done: sg4, pack_id=24, res=0x8000008 > Jun 4 16:03:18 localhost kernel: [ 2194.166389] sg_finish_rem_req: res_used=0 > Jun 4 16:03:18 localhost kernel: [ 2194.166400] sg_remove_scat: k_use_sg=0 > Jun 4 16:03:18 localhost kernel: [ 2194.166566] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:03:18 localhost kernel: [ 2194.166573] sg_common_write: scsi opcode=0x28, cmd_size=10 > Jun 4 16:03:18 localhost kernel: [ 2194.166576] sg_start_req: dxfer_len=59520 > Jun 4 16:03:18 localhost kernel: [ 2194.166583] sg_link_reserve: size=59520 > Jun 4 16:03:18 localhost kernel: [ 2194.184490] sg_cmd_done: sg4, pack_id=25, res=0x0 > Jun 4 16:03:18 localhost kernel: [ 2194.184518] sg_finish_rem_req: res_used=1 > Jun 4 16:03:18 localhost kernel: [ 2194.184623] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 16:03:18 localhost kernel: [ 2194.287573] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:03:18 localhost kernel: [ 2194.287584] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 16:03:18 localhost kernel: [ 2194.287587] sg_start_req: dxfer_len=0 > Jun 4 16:03:56 localhost dbus-daemon[434]: dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 16:03:56 localhost dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 16:03:56 localhost dbus-daemon[434]: dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 16:03:56 localhost dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 16:05:18 localhost kernel: [ 2314.294494] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 16:05:18 localhost kernel: [ 2314.294513] sg_cmd_done: sg4, pack_id=26, res=0x8000008 > Jun 4 16:05:18 localhost kernel: [ 2314.294545] sg_finish_rem_req: res_used=0 > Jun 4 16:05:18 localhost kernel: [ 2314.294552] sg_remove_scat: k_use_sg=0 > Jun 4 16:05:18 localhost kernel: [ 2314.294773] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:05:18 localhost kernel: [ 2314.294780] sg_common_write: scsi opcode=0x28, cmd_size=10 > Jun 4 16:05:18 localhost kernel: [ 2314.294783] sg_start_req: dxfer_len=59520 > Jun 4 16:05:18 localhost kernel: [ 2314.294789] sg_link_reserve: size=59520 > Jun 4 16:05:18 localhost kernel: [ 2314.312715] sg_cmd_done: sg4, pack_id=27, res=0x0 > Jun 4 16:05:18 localhost kernel: [ 2314.312759] sg_finish_rem_req: res_used=1 > Jun 4 16:05:18 localhost kernel: [ 2314.312864] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 16:05:18 localhost kernel: [ 2314.418083] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:05:18 localhost kernel: [ 2314.418097] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 16:05:18 localhost kernel: [ 2314.418100] sg_start_req: dxfer_len=0 > Jun 4 16:05:21 localhost dbus-daemon[434]: dbus[434]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) > Jun 4 16:05:21 localhost dbus[434]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) > Jun 4 16:05:21 localhost dbus-daemon[434]: no kernel backlight interface found > Jun 4 16:05:21 localhost dbus-daemon[434]: dbus[434]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' > Jun 4 16:05:21 localhost dbus[434]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' > Jun 4 16:06:21 localhost dbus-daemon[434]: dbus[434]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) > Jun 4 16:06:21 localhost dbus[434]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) > Jun 4 16:06:21 localhost dbus-daemon[434]: no kernel backlight interface found > Jun 4 16:06:21 localhost dbus-daemon[434]: dbus[434]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' > Jun 4 16:06:21 localhost dbus[434]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' > Jun 4 16:07:18 localhost kernel: [ 2434.422542] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 16:07:18 localhost kernel: [ 2434.422575] sg_cmd_done: sg4, pack_id=28, res=0x8000008 > Jun 4 16:07:18 localhost kernel: [ 2434.423397] sg_finish_rem_req: res_used=0 > Jun 4 16:07:18 localhost kernel: [ 2434.423409] sg_remove_scat: k_use_sg=0 > Jun 4 16:07:18 localhost kernel: [ 2434.423579] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:07:18 localhost kernel: [ 2434.423586] sg_common_write: scsi opcode=0x28, cmd_size=10 > Jun 4 16:07:18 localhost kernel: [ 2434.423588] sg_start_req: dxfer_len=59520 > Jun 4 16:07:18 localhost kernel: [ 2434.423595] sg_link_reserve: size=59520 > Jun 4 16:07:18 localhost kernel: [ 2434.441448] sg_cmd_done: sg4, pack_id=29, res=0x0 > Jun 4 16:07:18 localhost kernel: [ 2434.441475] sg_finish_rem_req: res_used=1 > Jun 4 16:07:18 localhost kernel: [ 2434.441574] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 16:07:19 localhost kernel: [ 2434.543927] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:07:19 localhost kernel: [ 2434.543938] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 16:07:19 localhost kernel: [ 2434.543941] sg_start_req: dxfer_len=0 > Jun 4 16:08:12 localhost kernel: [ 2488.095731] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 16:08:12 localhost kernel: [ 2488.102271] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 16:08:12 localhost kernel: [ 2488.102423] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 16:08:12 localhost kernel: [ 2488.102806] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 16:08:12 localhost kernel: [ 2488.104628] sd 2:0:0:0: [sdc] sd_ioctl: disk=sdc, cmd=0x2285 > Jun 4 16:08:12 localhost kernel: [ 2488.439880] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 16:08:12 localhost kernel: [ 2488.441245] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 16:08:12 localhost kernel: [ 2488.441395] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 16:08:12 localhost kernel: [ 2488.466442] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 16:08:13 localhost kernel: [ 2488.492046] sd 0:0:0:0: [sda] sd_ioctl: disk=sda, cmd=0x2285 > Jun 4 16:09:19 localhost kernel: [ 2554.544412] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 16:09:19 localhost kernel: [ 2554.544446] sg_cmd_done: sg4, pack_id=30, res=0x8000008 > Jun 4 16:09:19 localhost kernel: [ 2554.545320] sg_finish_rem_req: res_used=0 > Jun 4 16:09:19 localhost kernel: [ 2554.545331] sg_remove_scat: k_use_sg=0 > Jun 4 16:09:19 localhost kernel: [ 2554.545501] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:09:19 localhost kernel: [ 2554.545507] sg_common_write: scsi opcode=0x28, cmd_size=10 > Jun 4 16:09:19 localhost kernel: [ 2554.545510] sg_start_req: dxfer_len=59520 > Jun 4 16:09:19 localhost kernel: [ 2554.545516] sg_link_reserve: size=59520 > Jun 4 16:09:19 localhost kernel: [ 2554.563431] sg_cmd_done: sg4, pack_id=31, res=0x0 > Jun 4 16:09:19 localhost kernel: [ 2554.563468] sg_finish_rem_req: res_used=1 > Jun 4 16:09:19 localhost kernel: [ 2554.563569] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 16:09:19 localhost kernel: [ 2554.666206] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:09:19 localhost kernel: [ 2554.666222] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 16:09:19 localhost kernel: [ 2554.666226] sg_start_req: dxfer_len=0 > Jun 4 16:09:56 localhost dbus-daemon[434]: dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 16:09:56 localhost dbus[434]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) > Jun 4 16:09:56 localhost dbus-daemon[434]: dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 16:09:56 localhost dbus[434]: [system] Successfully activated service 'org.freedesktop.PackageKit' > Jun 4 16:11:19 localhost kernel: [ 2674.672414] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 16:11:19 localhost kernel: [ 2674.672447] sg_cmd_done: sg4, pack_id=32, res=0x8000008 > Jun 4 16:11:19 localhost kernel: [ 2674.673305] sg_finish_rem_req: res_used=0 > Jun 4 16:11:19 localhost kernel: [ 2674.673316] sg_remove_scat: k_use_sg=0 > Jun 4 16:11:19 localhost kernel: [ 2674.673485] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:11:19 localhost kernel: [ 2674.673492] sg_common_write: scsi opcode=0x28, cmd_size=10 > Jun 4 16:11:19 localhost kernel: [ 2674.673495] sg_start_req: dxfer_len=59520 > Jun 4 16:11:19 localhost kernel: [ 2674.673502] sg_link_reserve: size=59520 > Jun 4 16:11:19 localhost kernel: [ 2674.691319] sg_cmd_done: sg4, pack_id=33, res=0x0 > Jun 4 16:11:19 localhost kernel: [ 2674.691361] sg_finish_rem_req: res_used=1 > Jun 4 16:11:19 localhost kernel: [ 2674.691471] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 16:11:19 localhost kernel: [ 2674.793989] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:11:19 localhost kernel: [ 2674.794000] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 16:11:19 localhost kernel: [ 2674.794036] sg_start_req: dxfer_len=0 > Jun 4 16:13:19 localhost kernel: [ 2794.799417] scsi 5:0:0:0: timing out command, waited 120s > Jun 4 16:13:19 localhost kernel: [ 2794.799451] sg_cmd_done: sg4, pack_id=34, res=0x8000008 > Jun 4 16:13:19 localhost kernel: [ 2794.800506] sg_finish_rem_req: res_used=0 > Jun 4 16:13:19 localhost kernel: [ 2794.800518] sg_remove_scat: k_use_sg=0 > Jun 4 16:13:19 localhost kernel: [ 2794.800685] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:13:19 localhost kernel: [ 2794.800692] sg_common_write: scsi opcode=0x28, cmd_size=10 > Jun 4 16:13:19 localhost kernel: [ 2794.800695] sg_start_req: dxfer_len=59520 > Jun 4 16:13:19 localhost kernel: [ 2794.800701] sg_link_reserve: size=59520 > Jun 4 16:13:19 localhost kernel: [ 2794.818502] sg_cmd_done: sg4, pack_id=35, res=0x0 > Jun 4 16:13:19 localhost kernel: [ 2794.818539] sg_finish_rem_req: res_used=1 > Jun 4 16:13:19 localhost kernel: [ 2794.818645] sg_unlink_reserve: req->k_use_sg=2 > Jun 4 16:13:19 localhost kernel: [ 2794.921037] sg_ioctl: sg4, cmd=0x2285 > Jun 4 16:13:19 localhost kernel: [ 2794.921048] sg_common_write: scsi opcode=0x00, cmd_size=6 > Jun 4 16:13:19 localhost kernel: [ 2794.921051] sg_start_req: dxfer_len=0 > ^C > [root@localhost renan]# sysctl -w dev.scsi.logging_level=0 > dev.scsi.logging_level = 0 > [root@localhost renan]# > > > -- Stefan Richter -=====-===-= -==- --=== http://arcgraph.de/sr/ |
|
From: Jesús P. P. <jes...@gm...> - 2013-06-02 18:28:46
|
> What camera models do you have? I have two cameras from a company called "Videre Design". This company has stopped updating the drivers for their cameras. I believe that the company closed before the new firewire stack was released. The cameras I have do not even appear in their website as they have a resolution of 640x480 pixels and there are no such camera models in their website right now. So it is useless to try to ascertain which model I exactly have. My cameras worked badly with the new firewire stack. Even using just coriander the image transmission would stop working every now and then (meaning, it would probably stop working in less than 5 minutes). With the old firewire stack, only specific missuse of my software would trigger this problem. > And which 1394 controller? The are the modules I remove: sudo rmmod firewire_ohci sudo rmmod firewire_core These are the modules that I insert before starting my software: sudo insmod ieee1394.ko sudo insmod ohci1394.ko sudo insmod raw1394.ko sudo insmod video1394.ko > Is the software a standard IEEE 1394 based software like coriander, dvgrab, kino or the likes, or is it a generic software like skype etc., or is it a custom software written by yourself? I use coriander to test the cameras sometimes before running my software. Right now I almost never use coriander, as I have been able to debug the software enough to serve my needs. > Is the software accessing the kernel through a library or framework (libraw1394, libdc1394, gstreamer, dv4l, ...)? In order to acquire images I use only libdc1394 . All the interactions with the hardware are performed using libdc1394 function calls. The configuration, acquisition and releasing the cameras code is based on the example "grab_gray_image.c" of the libdc1394 library (libdc1394/libdc1394/examples/grab_gray_image.c). On the image processing stage of my software I use basically OpenCV and other open source libraries that are based on OpenCV. Please, do not hesitate in asking for more information, I hope this helped, Jesús Pestana 2013/6/2 Stefan Richter <st...@s5...> > On Jun 01 Jesús Pestana Puerta wrote: > > 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 > [...] > > 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. > [...] > > What camera models do you have? And which 1394 controller? (E.g. > "lspci -nn | grep 1394".) Is the software a standard IEEE 1394 based > software like coriander, dvgrab, kino or the likes, or is it a generic > software like skype etc., or is it a custom software written by yourself? > Is the software accessing the kernel through a library or framework > (libraw1394, libdc1394, gstreamer, dv4l, ...)? > -- > Stefan Richter > -=====-===-= -==- ---=- > http://arcgraph.de/sr/ > |
|
From: Stefan R. <st...@s5...> - 2013-06-26 17:11:58
|
Hi Renan,
about a week ago I received a UMAX PowerLook 1100, with transparency
option even. I didn't get around to actually start testing it until today.
My first results:
a) The PowerLook 1100 works OK with VueScan 9.0.96 on OS X 10.4.
b) My other FireWire scanner, the Epson Perfection 2450 Photo, works OK
with VueScan 9.2.21 x64 on Gentoo Linux AMD64, kernel 3.9.
c) Latter system and software, but UMAX PowerLook 1100, gets this far:
- PowerLook 1100 is detected properly by kernel and VueScan.
- Starting a preview in VueScan results in two messages
"kernel: scsi 184:0:0:0: timing out command, waited 120s"
but eventually succeeds.
The scanner isn't particularly fast to begin with, but having to
wait four extra minutes is a bit much of course... ;-/
- After that, starting a scan sets the scanner immediately into action
and goes through the entire scan just fine, without command timeout.
d) After that I tried skanlite 1.0 + sane-backends 1.0.23-r1 on the same
Gentoo Linux box. It discovered the PowerLook but crashed immediately
when I initiated the preview. However, SANE's UMAX SCSI backend does
not have official support for PowerLook 1100 yet, so nobody is to blame.
So in this single first test on Linux, VueScan + PowerLook 1100 did
actually work for me, but there were command timeouts which prolonged the
preview. Warm-up doesn't take so long; this is about 25 seconds or so on
OS X, judging from the time between pressing the preview buttun and the
moment when the scanner starts to blink its LED and to make noises.
I don't have a precise idea which step to take next, but one thing which
comes to my mind is to look at firewire-sbp2's way to align the commands
in memory.
--
Stefan Richter
-=====-===-= -==- ==-=-
http://arcgraph.de/sr/
|
|
From: Stefan R. <st...@s5...> - 2013-08-24 10:17:30
|
On Jun 26 Stefan Richter wrote: > Hi Renan, > > about a week ago I received a UMAX PowerLook 1100, with transparency > option even. I didn't get around to actually start testing it until today. > > My first results: > > a) The PowerLook 1100 works OK with VueScan 9.0.96 on OS X 10.4. > > b) My other FireWire scanner, the Epson Perfection 2450 Photo, works OK > with VueScan 9.2.21 x64 on Gentoo Linux AMD64, kernel 3.9. > > c) Latter system and software, but UMAX PowerLook 1100, gets this far: > - PowerLook 1100 is detected properly by kernel and VueScan. > - Starting a preview in VueScan results in two messages > "kernel: scsi 184:0:0:0: timing out command, waited 120s" > but eventually succeeds. > The scanner isn't particularly fast to begin with, but having to > wait four extra minutes is a bit much of course... ;-/ > - After that, starting a scan sets the scanner immediately into action > and goes through the entire scan just fine, without command timeout. > > d) After that I tried skanlite 1.0 + sane-backends 1.0.23-r1 on the same > Gentoo Linux box. It discovered the PowerLook but crashed immediately > when I initiated the preview. However, SANE's UMAX SCSI backend does > not have official support for PowerLook 1100 yet, so nobody is to blame. > > So in this single first test on Linux, VueScan + PowerLook 1100 did > actually work for me, but there were command timeouts which prolonged the > preview. Warm-up doesn't take so long; this is about 25 seconds or so on > OS X, judging from the time between pressing the preview buttun and the > moment when the scanner starts to blink its LED and to make noises. > > I don't have a precise idea which step to take next, but one thing which > comes to my mind is to look at firewire-sbp2's way to align the commands > in memory. Argh, two months went by and I haven't done anything with this issue. And this despite of the PL1100 sitting prominently n my living room, displacing quite a bit of air there, and thereby reminding me to look into the issue. I will eventually get to it, but at the moment paid work keeps me both busy and distracted. -- Stefan Richter -=====-===-= =--- ==--- http://arcgraph.de/sr/ |
|
From: Renan C. <ren...@te...> - 2014-04-01 22:19:45
|
Hi Stefan, Any progress in firewire SBP2 module? I tried o make my scanner work with the latest kernel from fedora 20 without success. Renan Stefan Richter escreveu: > Hi Renan, > > about a week ago I received a UMAX PowerLook 1100, with transparency > option even. I didn't get around to actually start testing it until today. > > My first results: > > a) The PowerLook 1100 works OK with VueScan 9.0.96 on OS X 10.4. > > b) My other FireWire scanner, the Epson Perfection 2450 Photo, works OK > with VueScan 9.2.21 x64 on Gentoo Linux AMD64, kernel 3.9. > > c) Latter system and software, but UMAX PowerLook 1100, gets this far: > - PowerLook 1100 is detected properly by kernel and VueScan. > - Starting a preview in VueScan results in two messages > "kernel: scsi 184:0:0:0: timing out command, waited 120s" > but eventually succeeds. > The scanner isn't particularly fast to begin with, but having to > wait four extra minutes is a bit much of course... ;-/ > - After that, starting a scan sets the scanner immediately into action > and goes through the entire scan just fine, without command timeout. > > d) After that I tried skanlite 1.0 + sane-backends 1.0.23-r1 on the same > Gentoo Linux box. It discovered the PowerLook but crashed immediately > when I initiated the preview. However, SANE's UMAX SCSI backend does > not have official support for PowerLook 1100 yet, so nobody is to blame. > > So in this single first test on Linux, VueScan + PowerLook 1100 did > actually work for me, but there were command timeouts which prolonged the > preview. Warm-up doesn't take so long; this is about 25 seconds or so on > OS X, judging from the time between pressing the preview buttun and the > moment when the scanner starts to blink its LED and to make noises. > > I don't have a precise idea which step to take next, but one thing which > comes to my mind is to look at firewire-sbp2's way to align the commands > in memory. |
|
From: Stefan R. <st...@s5...> - 2014-05-09 22:03:50
|
On Apr 01 Renan Calliari wrote:
> Any progress in firewire SBP2 module?
> I tried o make my scanner work with the latest kernel from fedora 20
> without success.
Sorry for remaining quiet for so long. I have been looking into some very
simple aspects (Config ROM parameters; the various existing firewire-sbp2
quirks that you already checked without success IIRC, and things like
that). I didn't learn anything useful so far, unfortunately. I have
been planning to check some more points, notably:
- Does the PowerLook perhaps expect ORB addresses to be aligned at
more even addresses, e.g. ORB size aligned?
- Does it perhaps require simple buffers instead of scatter-gather
buffers?
- Another option that I could pursue would be to log the packet traffic
with VueScan on OS X (using a PCILynx card for packet capture),
compare that with that of VueScan on Linux, and hopefully find some
significant difference there.
While the third option could be quite time-consuming, the first two would
presumably involve just a moderate amount of kernel manipulation and
testing. I am chronically short of spare time though...
--
Stefan Richter
-=====-====- -=-= -=--=
http://arcgraph.de/sr/
|
|
From: Stefan R. <st...@s5...> - 2014-05-09 22:10:15
|
> Stefan Richter escreveu: > > a) The PowerLook 1100 works OK with VueScan 9.0.96 on OS X 10.4. > > > > b) My other FireWire scanner, the Epson Perfection 2450 Photo, works OK > > with VueScan 9.2.21 x64 on Gentoo Linux AMD64, kernel 3.9. > > > > c) Latter system and software, but UMAX PowerLook 1100, gets this far: > > - PowerLook 1100 is detected properly by kernel and VueScan. > > - Starting a preview in VueScan results in two messages > > "kernel: scsi 184:0:0:0: timing out command, waited 120s" > > but eventually succeeds. > > The scanner isn't particularly fast to begin with, but having to > > wait four extra minutes is a bit much of course... ;-/ > > - After that, starting a scan sets the scanner immediately into action > > and goes through the entire scan just fine, without command timeout. PS: More tests revealed that it is more likely for setup "c" to get stuck very early at a scan, or to produce an incomplete and garbled scan (perhaps with mostly random junk of uninitialized buffer memory). The kind of delayed but in the end successful scanning like in the earliest few tests is more an exception then the rule. In other words, my further results came closer to what you are getting. -- Stefan Richter -=====-====- -=-= -=-=- http://arcgraph.de/sr/ |
Thanks for helping keep SourceForge clean.
X