linux1394-user Mailing List for IEEE 1394 for Linux (Page 6)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(29) |
Nov
(36) |
Dec
(46) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(60) |
Feb
(82) |
Mar
(46) |
Apr
(50) |
May
(89) |
Jun
(60) |
Jul
(80) |
Aug
(130) |
Sep
(104) |
Oct
(105) |
Nov
(123) |
Dec
(107) |
2002 |
Jan
(142) |
Feb
(105) |
Mar
(63) |
Apr
(117) |
May
(136) |
Jun
(75) |
Jul
(105) |
Aug
(103) |
Sep
(149) |
Oct
(149) |
Nov
(98) |
Dec
(144) |
2003 |
Jan
(161) |
Feb
(100) |
Mar
(118) |
Apr
(126) |
May
(157) |
Jun
(173) |
Jul
(156) |
Aug
(89) |
Sep
(83) |
Oct
(106) |
Nov
(84) |
Dec
(69) |
2004 |
Jan
(119) |
Feb
(233) |
Mar
(232) |
Apr
(104) |
May
(113) |
Jun
(132) |
Jul
(87) |
Aug
(129) |
Sep
(186) |
Oct
(88) |
Nov
(148) |
Dec
(180) |
2005 |
Jan
(223) |
Feb
(176) |
Mar
(148) |
Apr
(193) |
May
(188) |
Jun
(236) |
Jul
(144) |
Aug
(89) |
Sep
(44) |
Oct
(86) |
Nov
(114) |
Dec
(89) |
2006 |
Jan
(94) |
Feb
(97) |
Mar
(57) |
Apr
(117) |
May
(46) |
Jun
(63) |
Jul
(51) |
Aug
(72) |
Sep
(50) |
Oct
(142) |
Nov
(70) |
Dec
(52) |
2007 |
Jan
(60) |
Feb
(67) |
Mar
(80) |
Apr
(81) |
May
(78) |
Jun
(52) |
Jul
(64) |
Aug
(55) |
Sep
(40) |
Oct
(87) |
Nov
(70) |
Dec
(44) |
2008 |
Jan
(80) |
Feb
(12) |
Mar
(82) |
Apr
(64) |
May
(33) |
Jun
(53) |
Jul
(41) |
Aug
(26) |
Sep
(35) |
Oct
(21) |
Nov
(30) |
Dec
(42) |
2009 |
Jan
(17) |
Feb
(32) |
Mar
(10) |
Apr
(19) |
May
(19) |
Jun
(28) |
Jul
(41) |
Aug
(14) |
Sep
(5) |
Oct
(46) |
Nov
(23) |
Dec
(20) |
2010 |
Jan
(46) |
Feb
(13) |
Mar
(9) |
Apr
(2) |
May
(19) |
Jun
(28) |
Jul
(37) |
Aug
(23) |
Sep
(5) |
Oct
(32) |
Nov
(19) |
Dec
(18) |
2011 |
Jan
(23) |
Feb
(9) |
Mar
(19) |
Apr
(38) |
May
(83) |
Jun
(30) |
Jul
(46) |
Aug
(32) |
Sep
(6) |
Oct
(3) |
Nov
(25) |
Dec
(31) |
2012 |
Jan
(21) |
Feb
(12) |
Mar
(19) |
Apr
(7) |
May
(27) |
Jun
(7) |
Jul
(2) |
Aug
(15) |
Sep
(8) |
Oct
(11) |
Nov
|
Dec
(3) |
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(14) |
Jul
(1) |
Aug
(3) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
|
2014 |
Jan
(14) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(5) |
Dec
(18) |
2015 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(11) |
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stefan R. <st...@s5...> - 2014-01-18 20:53:45
|
On Jan 15 pho...@ya... wrote: > > I still do have the problems with my new Freecom Hard Drive on its > > firewire port. Anyway, I thought I might try a new kernel to see if the > > problems would go away. However the errors are still coming. [...] Thanks for testing the most recent kernel. Overall it looks like a hardware problem to me, for example due to a poorly designed circuit board in the Freecom Quattro. Some customer reviews of the Freecom Quattro 3.0 at amazon.co.uk report unreliable operation via FireWire (in contrast to USB or eSATA), especially when daisy-chained with more FireWire devices, but also when attached alone. Some questions: You wrote earlier that you used older disks successfully. Did you use them at the very same laptop? Please send the file /sys/bus/firewire/devices/fw?/config_rom which corresponds with the Freecom Quattro. This is a binary file; if you want you can transform it into a human-readable text before posting by means of the script "crpp" from http://me.in-berlin.de/~s5r6/linux1394/utils/. Also, please generate a more verbose kernel log from a session with these I/O errors, by running sudo dd of=/sys/module/firewire_ohci/parameters/debug <<< 2 before you attach the Freecom Quattro, then reproduce the I/O errors. Lastly, if you have the means to compile C programs on this laptop, it would interesting to see the output of the program lsfirewirephy from https://code.google.com/p/jujuutils/. -- Stefan Richter -=====-====- ---= =--=- http://arcgraph.de/sr/ |
From: A&M A. <new...@am...> - 2014-01-16 12:03:34
|
: http://www.am-architects.gr/en/home?utm_source=email+marketing&utm_campaign=A%26M+News+%7C+January+2014&utm_medium=email You are receiving this email because you subscribed to am-architects.gr mailing list to receive news and updates for upcoming events. If you no longer wish to receive emails from in...@am... please unsubscribe. ---------------------------------------- This email was sent from A&M Architects to lin...@li.... Click here to unsubscribe http://list.mlgn2eu.com/unsubscribe?u=8ae5780d22688d976ebce9d8fb3db81c&id=0f55a446&e=ec48533c&c=9058b6fd&ln=en A&M Architects, in...@am..., Athens, 11257, Greece Email Marketing by Mailigen |
From: <pho...@ya...> - 2014-01-15 21:42:39
|
[ 9479.962832] firewire_sbp2 fw1.0: status write for unknown ORB [ 9507.242920] firewire_sbp2 fw1.0: status write for unknown ORB [ 9516.771148] firewire_sbp2 fw1.0: status write for unknown ORB [ 9526.468622] firewire_sbp2 fw1.0: status write for unknown ORB [ 9536.401621] firewire_sbp2 fw1.0: status write for unknown ORB [ 9548.284219] firewire_sbp2 fw1.0: status write for unknown ORB [ 9558.161014] firewire_sbp2 fw1.0: status write for unknown ORB [ 9569.873588] firewire_sbp2 fw1.0: status write for unknown ORB [ 9580.387676] firewire_sbp2 fw1.0: status write for unknown ORB [ 9601.481144] firewire_sbp2 fw1.0: status write for unknown ORB [ 9611.816042] firewire_sbp2 fw1.0: status write for unknown ORB [ 9621.470940] firewire_sbp2 fw1.0: status write for unknown ORB [ 9631.515208] firewire_sbp2 fw1.0: status write for unknown ORB [ 9642.887931] firewire_sbp2 fw1.0: status write for unknown ORB [ 9714.282519] firewire_sbp2 fw1.0: status write for unknown ORB [ 9739.550211] firewire_sbp2 fw1.0: status write for unknown ORB [ 9766.211506] firewire_sbp2 fw1.0: status write for unknown ORB [ 9786.250357] firewire_sbp2 fw1.0: status write for unknown ORB [ 9795.777075] firewire_sbp2 fw1.0: status write for unknown ORB [ 9805.536467] firewire_sbp2 fw1.0: status write for unknown ORB [ 9824.852129] firewire_sbp2 fw1.0: status write for unknown ORB [ 9834.522667] firewire_sbp2 fw1.0: status write for unknown ORB [ 9844.223044] firewire_sbp2 fw1.0: status write for unknown ORB [ 9854.082187] firewire_sbp2 fw1.0: status write for unknown ORB [ 9864.267172] firewire_sbp2 fw1.0: status write for unknown ORB [ 9873.993240] firewire_sbp2 fw1.0: status write for unknown ORB [ 9883.731921] firewire_sbp2 fw1.0: status write for unknown ORB [ 9898.453387] firewire_sbp2 fw1.0: status write for unknown ORB [ 9933.909223] firewire_sbp2 fw1.0: status write for unknown ORB [ 9973.925368] firewire_sbp2 fw1.0: status write for unknown ORB [ 9983.467125] firewire_sbp2 fw1.0: status write for unknown ORB [10003.996977] firewire_sbp2 fw1.0: status write for unknown ORB [10019.291551] firewire_sbp2 fw1.0: status write for unknown ORB [10029.879373] firewire_core 0000:03:01.4: phy config: new root=ffc0, gap_count=63 [10030.776064] firewire_ohci 0000:03:01.4: failed to read phy reg 5 [10030.776075] CPU: 0 PID: 9634 Comm: kworker/0:0 Tainted: GF O 3.13.0-031300rc8-generic #201401120535 [10030.776079] Hardware name: Dell Inc. Latitude D630 / , BIOS A19 06/04/2013 [10030.776109] Workqueue: events bm_work [firewire_core] [10030.776114] 0000000000000067 ffff8801ea6e5cb8 ffffffff81733572 0000000000000000 [10030.776121] ffff880210506000 ffff8801ea6e5ce8 ffffffffa004dbec ffff8801ea6e5d28 [10030.776128] 0000000000000005 ffff880210506000 0000000000000000 ffff8801ea6e5d18 [10030.776134] Call Trace: [10030.776146] [<ffffffff81733572>] dump_stack+0x46/0x58 [10030.776159] [<ffffffffa004dbec>] read_phy_reg+0x8c/0xd0 [firewire_ohci] [10030.776170] [<ffffffffa004dc5d>] update_phy_reg+0x2d/0x70 [firewire_ohci] [10030.776180] [<ffffffffa004dced>] ohci_update_phy_reg+0x4d/0x80 [firewire_ohci] [10030.776192] [<ffffffffa003312c>] bm_work+0x50c/0x650 [firewire_core] [10030.776200] [<ffffffff8108442f>] process_one_work+0x17f/0x4c0 [10030.776210] [<ffffffff8108565b>] worker_thread+0x11b/0x3d0 [10030.776213] [<ffffffff81085540>] ? manage_workers.isra.21+0x190/0x190 [10030.776216] [<ffffffff8108c5b9>] kthread+0xc9/0xe0 [10030.776219] [<ffffffff8108c4f0>] ? flush_kthread_worker+0xb0/0xb0 [10030.776222] [<ffffffff817489bc>] ret_from_fork+0x7c/0xb0 [10030.776224] [<ffffffff8108c4f0>] ? flush_kthread_worker+0xb0/0xb0 [10031.876070] firewire_sbp2 fw2.0: ORB reply timed out, rcode 0x00 [10031.876081] firewire_sbp2 fw2.0: failed to reconnect [10031.876103] firewire_sbp2 fw1.0: ORB reply timed out, rcode 0x00 [10031.876109] firewire_sbp2 fw1.0: failed to reconnect [10034.076070] firewire_sbp2 fw2.0: ORB reply timed out, rcode 0x00 [10034.076094] firewire_sbp2 fw1.0: ORB reply timed out, rcode 0x00 [10039.097216] firewire_core 0000:03:01.4: unsolicited response (source ffc1, tlabel 24) [10039.098072] firewire_core 0000:03:01.4: unsolicited response (source ffc1, tlabel 26) [10039.116062] firewire_sbp2 fw1.0: status write for unknown ORB [10039.118160] firewire_sbp2 fw2.0: status write for unknown ORB [10039.120480] firewire_sbp2 fw2.0: status write for unknown ORB [10040.102529] firewire_sbp2 fw1.0: status write for unknown ORB [10040.121964] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) [10064.076076] firewire_sbp2 fw2.0: ORB reply timed out, rcode 0x11 [10064.276659] firewire_core 0000:03:01.4: unsolicited response (source ffc1, tlabel 27) [10064.278349] firewire_sbp2 fw2.0: error status: 0:10 [10064.279086] firewire_core 0000:03:01.4: unsolicited response (source ffc1, tlabel 28) [10064.310995] firewire_sbp2 fw2.0: logged in to LUN 0000 (1 retries) [10064.311684] firewire_core 0000:03:01.4: unsolicited response (source ffc1, tlabel 29) > > Hello, > > I still do have the problems with my new Freecom Hard Drive on its > firewire port. Anyway, I thought I might try a new kernel to see if the > problems would go away. However the errors are still coming. > > This is what I get from dmesg: > > [ 9479.962832] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9507.242920] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9516.771148] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9526.468622] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9536.401621] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9548.284219] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9558.161014] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9569.873588] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9580.387676] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9601.481144] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9611.816042] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9621.470940] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9631.515208] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9642.887931] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9714.282519] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9739.550211] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9766.211506] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9786.250357] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9795.777075] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9805.536467] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9824.852129] firewire_sbp2 fw1.0: status write for unknown ORB > [ 9834.522667] firewire_sbp2 fw1.0: status write for unknown ORB > > $> uname -a > Linux tuxtux 3.13.0-031300rc8-generic #201401120535 SMP Sun Jan 12 > 10:36:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > Any ideas, hints what I could try to make this work ? > > BR > P. > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user > |
From: <pho...@ya...> - 2014-01-15 21:11:22
|
Hello, I still do have the problems with my new Freecom Hard Drive on its firewire port. Anyway, I thought I might try a new kernel to see if the problems would go away. However the errors are still coming. This is what I get from dmesg: [ 9479.962832] firewire_sbp2 fw1.0: status write for unknown ORB [ 9507.242920] firewire_sbp2 fw1.0: status write for unknown ORB [ 9516.771148] firewire_sbp2 fw1.0: status write for unknown ORB [ 9526.468622] firewire_sbp2 fw1.0: status write for unknown ORB [ 9536.401621] firewire_sbp2 fw1.0: status write for unknown ORB [ 9548.284219] firewire_sbp2 fw1.0: status write for unknown ORB [ 9558.161014] firewire_sbp2 fw1.0: status write for unknown ORB [ 9569.873588] firewire_sbp2 fw1.0: status write for unknown ORB [ 9580.387676] firewire_sbp2 fw1.0: status write for unknown ORB [ 9601.481144] firewire_sbp2 fw1.0: status write for unknown ORB [ 9611.816042] firewire_sbp2 fw1.0: status write for unknown ORB [ 9621.470940] firewire_sbp2 fw1.0: status write for unknown ORB [ 9631.515208] firewire_sbp2 fw1.0: status write for unknown ORB [ 9642.887931] firewire_sbp2 fw1.0: status write for unknown ORB [ 9714.282519] firewire_sbp2 fw1.0: status write for unknown ORB [ 9739.550211] firewire_sbp2 fw1.0: status write for unknown ORB [ 9766.211506] firewire_sbp2 fw1.0: status write for unknown ORB [ 9786.250357] firewire_sbp2 fw1.0: status write for unknown ORB [ 9795.777075] firewire_sbp2 fw1.0: status write for unknown ORB [ 9805.536467] firewire_sbp2 fw1.0: status write for unknown ORB [ 9824.852129] firewire_sbp2 fw1.0: status write for unknown ORB [ 9834.522667] firewire_sbp2 fw1.0: status write for unknown ORB $> uname -a Linux tuxtux 3.13.0-031300rc8-generic #201401120535 SMP Sun Jan 12 10:36:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Any ideas, hints what I could try to make this work ? BR P. |
From: <pho...@ya...> - 2014-01-15 15:20:27
|
Hello List, I asked for help or pointers on 10.01.2014 an have not seen any reply yet. Is the list alive ? BR P. |
From: <pho...@ya...> - 2014-01-10 13:20:23
|
Hello, I forgot to add my kernel version: uname -a Linux tuxtux 3.11.0-031100-generic #201309021735 SMP Mon Sep 2 21:36:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux This is a linux mint 13 maya 64 bit with a kernel from the kernel ppa repository. BR P. > > Hello List, > > I have run into problems with an external firewire disk. It is a new > "Freecom Hard Drive Quattro USB 3.0 TB", P/N: 056068-71, Model Code > SACCAA. The drive works fine over usb 2.0 and usb 3.0 on another laptop. > I don't have an esata port, so I could not test esata. > > I spoke with Freecom's tech support on the phone, they did send me a > firmware upgrader for windows my email, which I ran. However my drive > already had that current fireware version. Freecom does not offer > support for linux, so I did not get any further help. > > The firewire port on my linux laptop is a 4pin firewire 400 port. The > port on the freecom is a 9pin firewire 800 port. The cables work fine > with another freecom 1TB and another freecom 2TB "Freecom Hard Drive > Quattro 2.0" drives over firewire. I also tested another different 4pin > to 8pin firewire 400 cable and another two 4pin to 9pin firewire 800 > cable. They all work with the other two older drives, but not with the > new drive. > > When I connect the new drive, I can then create some small files, i.e. > in the lower megabyte range, browse directories, write some text files, > etc. The problem/errors start once I start a backup to save my data onto > the external freecom disk. > > Is there something I can do to make this new freecom drive work ? > > fsck -pf of the filesystem returns no errors. > > Filesystem is ext4 inside a truecrypt container which uses all of the > drive's first partition /dev/sdb1 > > The firewire controller inside the laptop is this one: > 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev > 02) (prog-if 10 [OHCI]) > Subsystem: Dell Device 01f9 > Flags: bus master, medium devsel, latency 64, IRQ 19 > Memory at f1dff000 (32-bit, non-prefetchable) [size=4K] > Memory at f1dfe800 (32-bit, non-prefetchable) [size=2K] > Capabilities: [60] Power Management version 2 > Kernel driver in use: firewire_ohci > Kernel modules: firewire-ohci > > This is the dmesg output when I connect the drive: > [38407.928194] scsi15 : SBP-2 IEEE-1394 > [38407.928365] firewire_core 0000:03:01.4: created device fw1: GUID > 0001db9200188188, S400 > [38407.928378] firewire_core 0000:03:01.4: phy config: new root=ffc0, > gap_count=5 > [38408.146794] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > [38408.147879] scsi 15:0:0:0: Direct-Access ST3000DM 001-1CH166 > PQ: 0 ANSI: 5 > [38408.152234] sd 15:0:0:0: Attached scsi generic sg2 type 0 > [38408.165642] sd 15:0:0:0: [sdb] 5860533152 512-byte logical blocks: > (3.00 TB/2.72 TiB) > [38408.180978] sd 15:0:0:0: [sdb] Write Protect is off > [38408.180991] sd 15:0:0:0: [sdb] Mode Sense: 10 00 00 00 > [38408.210982] sd 15:0:0:0: [sdb] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [38408.293556] Alternate GPT is invalid, using primary GPT. > [38408.293570] sdb: sdb1 > [38408.357721] sd 15:0:0:0: [sdb] Attached SCSI disk > > This is the dmesg output when I mount the truecrypt partition on the freecom > [38408.357721] sd 15:0:0:0: [sdb] Attached SCSI disk > [38479.499458] bio: create slab <bio-1> at 1 > [38479.897130] EXT4-fs (dm-0): mounted filesystem with ordered data > mode. Opts: (null) > > This is the dmesg output after I start rsync to do the backup. > [38835.735813] firewire_sbp2 fw1.0: status write for unknown ORB > [38854.379707] firewire_sbp2 fw1.0: status write for unknown ORB > [38864.309201] firewire_sbp2 fw1.0: status write for unknown ORB > [38874.273059] firewire_sbp2 fw1.0: status write for unknown ORB > [38883.707197] firewire_sbp2 fw1.0: status write for unknown ORB > [38892.932137] sd 15:0:0:0: [sdb] Unhandled error code > [38892.932149] sd 15:0:0:0: [sdb] > [38892.932152] Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK > [38892.932156] sd 15:0:0:0: [sdb] CDB: > [38892.932158] Write(16): 8a 00 00 00 00 00 10 60 89 00 00 00 04 00 00 00 > [38892.932174] end_request: I/O error, dev sdb, sector 274761984 > [38892.932220] EXT4-fs warning (device dm-0): ext4_end_bio:332: I/O > error writing to inode 115343986 (offset 8388608 size 8388608 starting > block 34344960) > [38892.932225] buffer_io_error: 99624 callbacks suppressed > [38892.932227] Buffer I/O error on device dm-0, logical block 34344960 > [38892.932233] Buffer I/O error on device dm-0, logical block 34344961 > [38892.932237] Buffer I/O error on device dm-0, logical block 34344962 > [38892.932240] Buffer I/O error on device dm-0, logical block 34344963 > [38892.932243] Buffer I/O error on device dm-0, logical block 34344964 > [38892.932246] Buffer I/O error on device dm-0, logical block 34344965 > [38892.932249] Buffer I/O error on device dm-0, logical block 34344966 > [38892.932252] Buffer I/O error on device dm-0, logical block 34344967 > [38892.932256] Buffer I/O error on device dm-0, logical block 34344968 > [38892.932259] Buffer I/O error on device dm-0, logical block 34344969 > [38893.116359] firewire_core 0000:03:01.4: phy config: new root=ffc1, > gap_count=5 > [38894.016023] firewire_ohci 0000:03:01.4: failed to read phy reg 5 > [38894.016031] CPU: 0 PID: 22770 Comm: kworker/0:2 Tainted: GF > O 3.11.0-031100-generic #201309021735 > [38894.016033] Hardware name: Dell Inc. Latitude D630 > / , BIOS A18 12/06/2011 > [38894.016058] Workqueue: events bm_work [firewire_core] > [38894.016060] 0000000000000067 ffff88018d695cb8 ffffffff81720fca > 0000000000000000 > [38894.016064] ffff88020f858000 ffff88018d695ce8 ffffffffa0084cbc > ffffffffa0075420 > [38894.016067] 0000000000000005 ffff88020f858000 0000000000000000 > ffff88018d695d18 > [38894.016070] Call Trace: > [38894.016076] [<ffffffff81720fca>] dump_stack+0x46/0x58 > [38894.016083] [<ffffffffa0084cbc>] read_phy_reg+0x8c/0xd0 [firewire_ohci] > [38894.016089] [<ffffffffa0084d2d>] update_phy_reg+0x2d/0x70 > [firewire_ohci] > [38894.016094] [<ffffffffa0084dbd>] ohci_update_phy_reg+0x4d/0x80 > [firewire_ohci] > [38894.016100] [<ffffffffa006b054>] bm_work+0x464/0x500 [firewire_core] > [38894.016106] [<ffffffffa006e700>] ? fw_device_update+0x40/0x40 > [firewire_core] > [38894.016111] [<ffffffff81081060>] process_one_work+0x170/0x4a0 > [38894.016114] [<ffffffff81082121>] worker_thread+0x121/0x390 > [38894.016118] [<ffffffff81082000>] ? manage_workers.isra.20+0x170/0x170 > [38894.016121] [<ffffffff81088fe0>] kthread+0xc0/0xd0 > [38894.016124] [<ffffffff81088f20>] ? flush_kthread_worker+0xb0/0xb0 > [38894.016127] [<ffffffff81735a2c>] ret_from_fork+0x7c/0xb0 > [38894.016130] [<ffffffff81088f20>] ? flush_kthread_worker+0xb0/0xb0 > [38895.116039] firewire_sbp2 fw1.0: ORB reply timed out, rcode 0x00 > [38895.116046] firewire_sbp2 fw1.0: failed to reconnect > [38897.316035] firewire_sbp2 fw1.0: ORB reply timed out, rcode 0x00 > [38902.334389] firewire_sbp2 fw1.0: status write for unknown ORB > [38902.535616] firewire_sbp2 fw1.0: status write for unknown ORB > [38903.359639] firewire_sbp2 fw1.0: status write for unknown ORB > [38903.378997] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > > Best regards > P. > |
From: <pho...@ya...> - 2014-01-10 09:56:30
|
Hello List, I have run into problems with an external firewire disk. It is a new "Freecom Hard Drive Quattro USB 3.0 TB", P/N: 056068-71, Model Code SACCAA. The drive works fine over usb 2.0 and usb 3.0 on another laptop. I don't have an esata port, so I could not test esata. I spoke with Freecom's tech support on the phone, they did send me a firmware upgrader for windows my email, which I ran. However my drive already had that current fireware version. Freecom does not offer support for linux, so I did not get any further help. The firewire port on my linux laptop is a 4pin firewire 400 port. The port on the freecom is a 9pin firewire 800 port. The cables work fine with another freecom 1TB and another freecom 2TB "Freecom Hard Drive Quattro 2.0" drives over firewire. I also tested another different 4pin to 8pin firewire 400 cable and another two 4pin to 9pin firewire 800 cable. They all work with the other two older drives, but not with the new drive. When I connect the new drive, I can then create some small files, i.e. in the lower megabyte range, browse directories, write some text files, etc. The problem/errors start once I start a backup to save my data onto the external freecom disk. Is there something I can do to make this new freecom drive work ? fsck -pf of the filesystem returns no errors. Filesystem is ext4 inside a truecrypt container which uses all of the drive's first partition /dev/sdb1 The firewire controller inside the laptop is this one: 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) (prog-if 10 [OHCI]) Subsystem: Dell Device 01f9 Flags: bus master, medium devsel, latency 64, IRQ 19 Memory at f1dff000 (32-bit, non-prefetchable) [size=4K] Memory at f1dfe800 (32-bit, non-prefetchable) [size=2K] Capabilities: [60] Power Management version 2 Kernel driver in use: firewire_ohci Kernel modules: firewire-ohci This is the dmesg output when I connect the drive: [38407.928194] scsi15 : SBP-2 IEEE-1394 [38407.928365] firewire_core 0000:03:01.4: created device fw1: GUID 0001db9200188188, S400 [38407.928378] firewire_core 0000:03:01.4: phy config: new root=ffc0, gap_count=5 [38408.146794] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) [38408.147879] scsi 15:0:0:0: Direct-Access ST3000DM 001-1CH166 PQ: 0 ANSI: 5 [38408.152234] sd 15:0:0:0: Attached scsi generic sg2 type 0 [38408.165642] sd 15:0:0:0: [sdb] 5860533152 512-byte logical blocks: (3.00 TB/2.72 TiB) [38408.180978] sd 15:0:0:0: [sdb] Write Protect is off [38408.180991] sd 15:0:0:0: [sdb] Mode Sense: 10 00 00 00 [38408.210982] sd 15:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [38408.293556] Alternate GPT is invalid, using primary GPT. [38408.293570] sdb: sdb1 [38408.357721] sd 15:0:0:0: [sdb] Attached SCSI disk This is the dmesg output when I mount the truecrypt partition on the freecom [38408.357721] sd 15:0:0:0: [sdb] Attached SCSI disk [38479.499458] bio: create slab <bio-1> at 1 [38479.897130] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) This is the dmesg output after I start rsync to do the backup. [38835.735813] firewire_sbp2 fw1.0: status write for unknown ORB [38854.379707] firewire_sbp2 fw1.0: status write for unknown ORB [38864.309201] firewire_sbp2 fw1.0: status write for unknown ORB [38874.273059] firewire_sbp2 fw1.0: status write for unknown ORB [38883.707197] firewire_sbp2 fw1.0: status write for unknown ORB [38892.932137] sd 15:0:0:0: [sdb] Unhandled error code [38892.932149] sd 15:0:0:0: [sdb] [38892.932152] Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK [38892.932156] sd 15:0:0:0: [sdb] CDB: [38892.932158] Write(16): 8a 00 00 00 00 00 10 60 89 00 00 00 04 00 00 00 [38892.932174] end_request: I/O error, dev sdb, sector 274761984 [38892.932220] EXT4-fs warning (device dm-0): ext4_end_bio:332: I/O error writing to inode 115343986 (offset 8388608 size 8388608 starting block 34344960) [38892.932225] buffer_io_error: 99624 callbacks suppressed [38892.932227] Buffer I/O error on device dm-0, logical block 34344960 [38892.932233] Buffer I/O error on device dm-0, logical block 34344961 [38892.932237] Buffer I/O error on device dm-0, logical block 34344962 [38892.932240] Buffer I/O error on device dm-0, logical block 34344963 [38892.932243] Buffer I/O error on device dm-0, logical block 34344964 [38892.932246] Buffer I/O error on device dm-0, logical block 34344965 [38892.932249] Buffer I/O error on device dm-0, logical block 34344966 [38892.932252] Buffer I/O error on device dm-0, logical block 34344967 [38892.932256] Buffer I/O error on device dm-0, logical block 34344968 [38892.932259] Buffer I/O error on device dm-0, logical block 34344969 [38893.116359] firewire_core 0000:03:01.4: phy config: new root=ffc1, gap_count=5 [38894.016023] firewire_ohci 0000:03:01.4: failed to read phy reg 5 [38894.016031] CPU: 0 PID: 22770 Comm: kworker/0:2 Tainted: GF O 3.11.0-031100-generic #201309021735 [38894.016033] Hardware name: Dell Inc. Latitude D630 / , BIOS A18 12/06/2011 [38894.016058] Workqueue: events bm_work [firewire_core] [38894.016060] 0000000000000067 ffff88018d695cb8 ffffffff81720fca 0000000000000000 [38894.016064] ffff88020f858000 ffff88018d695ce8 ffffffffa0084cbc ffffffffa0075420 [38894.016067] 0000000000000005 ffff88020f858000 0000000000000000 ffff88018d695d18 [38894.016070] Call Trace: [38894.016076] [<ffffffff81720fca>] dump_stack+0x46/0x58 [38894.016083] [<ffffffffa0084cbc>] read_phy_reg+0x8c/0xd0 [firewire_ohci] [38894.016089] [<ffffffffa0084d2d>] update_phy_reg+0x2d/0x70 [firewire_ohci] [38894.016094] [<ffffffffa0084dbd>] ohci_update_phy_reg+0x4d/0x80 [firewire_ohci] [38894.016100] [<ffffffffa006b054>] bm_work+0x464/0x500 [firewire_core] [38894.016106] [<ffffffffa006e700>] ? fw_device_update+0x40/0x40 [firewire_core] [38894.016111] [<ffffffff81081060>] process_one_work+0x170/0x4a0 [38894.016114] [<ffffffff81082121>] worker_thread+0x121/0x390 [38894.016118] [<ffffffff81082000>] ? manage_workers.isra.20+0x170/0x170 [38894.016121] [<ffffffff81088fe0>] kthread+0xc0/0xd0 [38894.016124] [<ffffffff81088f20>] ? flush_kthread_worker+0xb0/0xb0 [38894.016127] [<ffffffff81735a2c>] ret_from_fork+0x7c/0xb0 [38894.016130] [<ffffffff81088f20>] ? flush_kthread_worker+0xb0/0xb0 [38895.116039] firewire_sbp2 fw1.0: ORB reply timed out, rcode 0x00 [38895.116046] firewire_sbp2 fw1.0: failed to reconnect [38897.316035] firewire_sbp2 fw1.0: ORB reply timed out, rcode 0x00 [38902.334389] firewire_sbp2 fw1.0: status write for unknown ORB [38902.535616] firewire_sbp2 fw1.0: status write for unknown ORB [38903.359639] firewire_sbp2 fw1.0: status write for unknown ORB [38903.378997] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) Best regards P. |
From: Stefan R. <st...@s5...> - 2013-10-29 22:43:33
|
On Oct 29 kdag wrote: [...] > when I try to open it with applications live dvgrab with or > without the -guid i get a: > > $ sudo dvgrab -guid 0007480022606895 > libiec61883 warning: Transmission node has no plugs online! > Established connection over channel 63 > Waiting for DV... > ^C"" 0.00 MiB 0 frames > Capture Stopped > Error: no DV > > And that makes sense cause is not a DV stream what the device is > supposed to be sending. Indeed; dvgrab expects a DV stream or an MPEG2-TS, whereas DFG 1394-1e transmits uncompressed video. On the other hand, DFG 1394-1e does apparently not support IIDC either, as far as I understand. (IIDC would suit capture applications like coriander.) > With Guvcview, that is supposed to be based on unicap, I can only open > my usb internal webcam. My guess is that your installed unicap version is a moderately old version which doesn't have a backend for the /dev/fw* kernel ABI yet. If so, you may need to rebuild unicap from current sourcecode. -- Stefan Richter -=====-===-= =-=- ===-= http://arcgraph.de/sr/ |
From: kdag <fu...@gm...> - 2013-10-29 21:14:15
|
Hi all, I've got one "old" video to firewire converter from ImagingSource, they don't do this anymore and "Linux" support was supposed to be there via unicap. I've managed to load the device: $ lsfirewire fw0: Linux Firewire Juju fw1: Video to 1394 Converter Rev2 $ lsfirewirephy bus 0, node 0: 006037:422001 (unknown) bus 0, node 1: 080028:424729 Texas Instruments XIO2200A Please check this web page for updated PHY IDs: http://code.google.com/p/jujuutils/wiki/PhyIds acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 acpiphp: Slot [1] registered firewire_ohci 0000:06:00.0: isochronous cycle inconsistent firewire_core 0000:06:00.0: rediscovered device fw0 firewire_core 0000:06:00.0: created device fw1: GUID 0007480022606895, S400 firewire_core 0000:06:00.0: phy config: new root=ffc1, gap_count=5 hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. firewire_core 0000:06:00.0: giving up on node ffc0: reading config rom failed: bus reset firewire_core 0000:06:00.0: rediscovered device fw0 firewire_core 0000:06:00.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:06:00.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:06:00.0: created device fw1: GUID 000a270004069d6d, S400 firewire_core 0000:06:00.0: rediscovered device fw0 firewire_core 0000:06:00.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:06:00.0: created device fw1: GUID 0007480022606895, S400 $ firewire-request /dev/fw1 -D address length name fffff0000000 4 state_clear fffff0000004 4 state_set fffff0000008 4 node_ids fffff000000c 4 reset_start fffff0000018 8 split_timeout[_hi|_lo] fffff0000080 40 message_request fffff00000c0 40 message_response fffff0000200 4 cycle_time fffff0000204 4 bus_time fffff0000210 4 busy_timeout fffff0000218 4 priority_budget fffff000021c 4 bus_manager_id fffff0000220 4 bandwidth_available fffff0000224 8 channels_available[_hi|_lo] fffff0000230 4 maint_utility fffff0000234 4 broadcast_channel fffff0000400 400 config_rom fffff0000900 4 output_master_plug fffff0000904 4 output_plug0 fffff000097c 4 output_plug30 fffff0000980 4 input_master_plug fffff0000984 4 input_plug0 fffff00009fc 4 input_plug30 fffff0000b00 200 fcp_command fffff0000d00 200 fcp_response fffff0001000 400 topology_map But when I try to open it with applications live dvgrab with or without the -guid i get a: $ sudo dvgrab -guid 0007480022606895 libiec61883 warning: Transmission node has no plugs online! Established connection over channel 63 Waiting for DV... ^C"" 0.00 MiB 0 frames Capture Stopped Error: no DV And that makes sense cause is not a DV stream what the device is supposed to be sending. With Guvcview, that is supposed to be based on unicap, I can only open my usb internal webcam. Could someone here help me out to understand if there's a chance to use this device under contemporary kernels like: Linux Debian 3.6.0-9.dmz.1-liquorix-amd64 #1 ZEN SMP PREEMPT In advance thanks for any kind of hint! |
From: Colin P. <Col...@io...> - 2013-10-23 13:49:19
|
Hi, I'm struggling to get an external FW hard drive to work with a Dell Precision 2900, using a Belkin F5U503 3Port Fire wire adapter. The same drive does work when I replace the Belkin card with a SUNIX card. I can also get the Belkin Card and External Drive to play ball in a different PC running the same OS and kernel version. So this seems to be something specific to the combination in the PowerEdge 2900. Thanks OS Redhat 6.2 - 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux Belkin F5u503 3 port FW 400, with Texas Instrument Chipset. Running the firewire-ohci, firewire-sbp2, firewire-core driver modules External Drive is a Toughtech MiniQ Drive enclosure, though other models of external FW drive are also not working. Extract from var log messages (grep for firewire) with debug=-1 option to ohci module: Oct 22 20:01:42 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 Oct 22 20:01:42 sst11 kernel: firewire_ohci: failed to set phy reg bits. Oct 22 20:01:42 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A disabled Oct 22 20:01:42 sst11 kernel: firewire_ohci: probe of 0000:09:02.0 failed with error -5 Oct 22 20:38:31 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 Oct 22 20:38:31 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 20:38:31 sst11 kernel: firewire_ohci: Added fw-ohci device 0000:09:02.0, OHCI version 1.10 Oct 22 20:38:50 sst11 kernel: firewire_ohci: failed to set phy reg bits. Oct 22 20:38:50 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A disabled Oct 22 20:38:50 sst11 kernel: firewire_ohci: Removed fw-ohci device. Oct 22 21:04:43 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 Oct 22 21:04:43 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:04:43 sst11 kernel: firewire_ohci: Added fw-ohci device 0000:09:02.0, OHCI version 1.10 Oct 22 21:05:02 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A disabled Oct 22 21:05:02 sst11 kernel: firewire_ohci: Removed fw-ohci device. Oct 22 21:07:35 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:07:35 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:07:35 sst11 kernel: firewire_ohci: Added fw-ohci device 0000:09:02.0, OHCI version 1.10 Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00020010 AR_req busReset Oct 22 21:07:35 sst11 kernel: firewire_ohci: AR evt_bus_reset, generation 1 Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00030000 selfID busReset Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:07:35 sst11 kernel: firewire_ohci: 2 selfIDs, generation 1, local node ID ffc0 Oct 22 21:07:35 sst11 kernel: firewire_ohci: selfID 0: 807f8c5a, phy 0 [--p] S400 gc=63 -3W Lci Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:07:35 sst11 kernel: firewire_ohci: selfID 0: 817fc474, phy 1 [-c-] beta gc=63 -3W L Oct 22 21:07:35 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:07:35 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:07:35 sst11 kernel: firewire_core: created device fw0: GUID 00d0035600a977c2, S400 Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00000001 AT_req Oct 22 21:07:35 sst11 kernel: firewire_ohci: AT spd 0 tl 18, ffc0 -> ffc1, ack_pending , QR req, fffff0000400 Oct 22 21:07:35 sst11 kernel: firewire_ohci: IRQ 00000020 AR_resp Oct 22 21:07:35 sst11 kernel: firewire_ohci: AR spd 0 tl 18, ffc1 -> ffc0, ack_complete, QR resp = 0404254f Oct 22 21:07:35 sst11 kernel: firewire_ohci: AT spd 0 tl 19, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000404 Oct 22 21:07:38 sst11 kernel: firewire_ohci: IRQ 00000001 AT_req Oct 22 21:07:38 sst11 kernel: firewire_ohci: IRQ 00000020 AR_resp Oct 22 21:07:38 sst11 kernel: firewire_ohci: AR spd 0 tl 19, ffc1 -> ffc0, ack_complete, QR resp = 31333934 Oct 22 21:07:38 sst11 kernel: firewire_core: Unsolicited response (source ffc1, tlabel 19) Oct 22 21:07:38 sst11 kernel: firewire_ohci: AT spd 0 tl 1a, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:07:41 sst11 kernel: firewire_ohci: IRQ 00000001 AT_req Oct 22 21:07:41 sst11 kernel: firewire_ohci: IRQ 00000020 AR_resp Oct 22 21:07:41 sst11 kernel: firewire_ohci: AR spd 0 tl 1a, ffc1 -> ffc0, ack_complete, QR resp = 0404254f Oct 22 21:07:41 sst11 kernel: firewire_core: Unsolicited response (source ffc1, tlabel 1a) Oct 22 21:07:41 sst11 kernel: firewire_ohci: AT spd 0 tl 1b, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:07:44 sst11 kernel: firewire_ohci: IRQ 00000001 AT_req Oct 22 21:07:44 sst11 kernel: firewire_ohci: IRQ 00000020 AR_resp Oct 22 21:07:44 sst11 kernel: firewire_ohci: AR spd 0 tl 1b, ffc1 -> ffc0, ack_complete, QR resp = 0404254f Oct 22 21:07:44 sst11 kernel: firewire_core: Unsolicited response (source ffc1, tlabel 1b) Oct 22 21:07:45 sst11 kernel: firewire_ohci: AT spd 0 tl 1c, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:07:48 sst11 kernel: firewire_ohci: IRQ 00000001 AT_req Oct 22 21:07:48 sst11 kernel: firewire_ohci: IRQ 00000020 AR_resp Oct 22 21:07:48 sst11 kernel: firewire_ohci: AR spd 0 tl 1c, ffc1 -> ffc0, ack_complete, QR resp = 0404254f Oct 22 21:07:48 sst11 kernel: firewire_core: Unsolicited response (source ffc1, tlabel 1c) Oct 22 21:07:48 sst11 kernel: firewire_ohci: AT spd 0 tl 1d, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:07:51 sst11 kernel: firewire_ohci: IRQ 00000001 AT_req Oct 22 21:07:51 sst11 kernel: firewire_ohci: IRQ 00000020 AR_resp Oct 22 21:07:51 sst11 kernel: firewire_ohci: AR spd 0 tl 1d, ffc1 -> ffc0, ack_complete, QR resp = 0404254f Oct 22 21:07:51 sst11 kernel: firewire_core: Unsolicited response (source ffc1, tlabel 1d) Oct 22 21:07:51 sst11 kernel: firewire_ohci: AT spd 0 tl 1e, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:07:54 sst11 kernel: firewire_ohci: AT spd 0 tl 1f, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:07:57 sst11 kernel: firewire_ohci: AT spd 0 tl 20, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:08:00 sst11 kernel: firewire_ohci: AT spd 0 tl 21, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:08:03 sst11 kernel: firewire_ohci: AT spd 0 tl 22, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:08:06 sst11 kernel: firewire_ohci: AT spd 0 tl 23, ffc0 -> ffc1, pending/cancelled, QR req, fffff0000400 Oct 22 21:08:06 sst11 kernel: firewire_core: giving up on config rom for node id ffc1 Oct 22 21:08:06 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:08:06 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:08:39 sst11 kernel: firewire_ohci: IRQ 00200000 cycle64Seconds Oct 22 21:09:43 sst11 kernel: firewire_ohci: IRQ 00200000 cycle64Seconds Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020010 AR_req busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: AR evt_bus_reset, generation 2 Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00030000 selfID busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:10:15 sst11 kernel: firewire_ohci: Error: DMA context still active (0x00000412) Oct 22 21:10:15 sst11 kernel: firewire_ohci: 1 selfIDs, generation 2, local node ID ffc0 Oct 22 21:10:15 sst11 kernel: firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci Oct 22 21:12:30 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 Oct 22 21:12:30 sst11 kernel: firewire_ohci: failed to set phy reg bits. Oct 22 21:12:30 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A disabled Oct 22 21:12:30 sst11 kernel: firewire_ohci: probe of 0000:09:02.0 failed with error -5 Oct 22 21:24:20 sst11 kernel: firewire_ohci 0000:09:02.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 Oct 22 21:24:20 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:24:20 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:24:20 sst11 kernel: firewire_ohci: Added fw-ohci device 0000:09:02.0, OHCI version 1.10 Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020010 AR_req busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: AR evt_bus_reset, generation 1 Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00030000 selfID busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00020000 busReset Oct 22 21:25:05 sst11 kernel: firewire_ohci: 1 selfIDs, generation 1, local node ID ffc0 Oct 22 21:25:05 sst11 kernel: firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:25:05 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:25:05 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:25:05 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:25:05 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Oct 22 21:25:06 sst11 kernel: firewire_core: created device fw0: GUID 00d0035600a977c2, S400 Oct 22 21:25:06 sst11 kernel: firewire_ohci: IRQ 00040000 regAccessFail Oct 22 21:25:06 sst11 kernel: firewire_ohci: Register access failure - please notify lin...@li... Colin ________________________________ This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. |
From: Carl K. <ca...@pe...> - 2013-10-09 22:43:28
|
On Wed, Oct 9, 2013 at 4:58 PM, Rogan Dawes <ro...@da...> wrote: > I simply got a blank screen when I tried to > transfer using dvgrab. blank screen seems like an odd result of dvgrab. carl@dc10:~$ dvgrab -debug all Error: no camera exists -- Carl K |
From: Rogan D. <ro...@da...> - 2013-10-09 22:14:13
|
Hi folks, I'm relatively new to Firewire on Linux. Well, I tried to get it working several years ago, but was unsuccessful. My aim is to transfer a bunch of videos that I recorded using an old Canon MV550i. Those that I recorded in the standard SP mode can be transferred OK, and this is not a problem for me. However, the camera also offered extended recording modes where the camera could record up to 3 times the nominal recording time on a standard tape. Like a fool, I thought this was a good idea, and some of the footage is recorded in this mode. When I tried this last time, I simply got a blank screen when I tried to transfer using dvgrab. I also note the following warning in the manual: "You cannot transfer images recorded in SP or LP mode to a PC (as of January 2002)." I was wondering if there was any solution to getting this video onto the computer, other than using an analogue capture card? Is it possible to transfer the raw bytes of the recorded video, and then try to decode them after the fact? Thanks for any suggestions. Regards, Rogan |
From: Adair <Ane...@gm...> - 2013-09-10 18:01:14
|
watches in our boutique - http://qps.ru/dXK89 |
From: Stefan R. <st...@s5...> - 2013-09-09 07:24:35
|
On Sep 08 Lee Cewd wrote: > Hello, > > Two weeks ago, I post a message about a memory leak problem on mailing > lists. > > The following result is that I use valgrind to check this problem. > > 3067120 (3066560 direct, 560 indirect) bytes in 10952 blocks are > definitely lost in loss record 36 of 36 at 0x4029F6F : malloc () > by 0x405B1B5 : ??? (in usr/lib/libraw1394.so.11.0.1) > by 0x405B492 : ??? (in usr/lib/libraw1394.so.11.0.1) > by 0x405BF24 : fw_loop_iterate (in usr/lib/libraw1394.so.11.0.1) > by 0x405C197 : ??? (in usr/lib/libraw1394.so.11.0.1) > by 0x405D6F8 : fw_write (in usr/lib/libraw1394.so.11.0.1) > by 0x405A292 : raw1394_write (in usr/lib/libraw1394.so.11.0.1) > by 0x805A0F2 : main (main.cpp:121) > > Recently, I modify libraw1394-2.1.0 source code. > > fw.c: > > static int > handle_arm_request(raw1394handle_t handle, struct address_closure *ac, > int tcode, unsigned long long offset, int source_node_id, > int card, unsigned kernel_handle, size_t length, void *data) > { > ...... > - return fwhandle->arm_tag_handler(handle, allocation->tag, type,length, &rrb->request_response); > + int retval; > + retval = fwhandle->arm_tag_handler(handle, allocation->tag, type, length, &rrb->request_response); > + free(rrb); > + return retval; > } > > This way can solve my problem. > > Best Regards, > > Cewd Thank you very much for the earlier report and for this patch. Looks good to me. I will try to test it with a few libraw1394 based applications as soon as I can, and get it released. -- Stefan Richter -=====-===-= =--= -=--= http://arcgraph.de/sr/ |
From: Lee C. <cha...@ho...> - 2013-09-08 12:49:49
|
Hello, Two weeks ago, I post a message about a memory leak problem on mailing lists. The following result is that I use valgrind to check this problem. 3067120 (3066560 direct, 560 indirect) bytes in 10952 blocks are definitely lost in loss record 36 of 36at 0x4029F6F : malloc ()by 0x405B1B5 : ??? (in usr/lib/libraw1394.so.11.0.1)by 0x405B492 : ??? (in usr/lib/libraw1394.so.11.0.1)by 0x405BF24 : fw_loop_iterate (in usr/lib/libraw1394.so.11.0.1)by 0x405C197 : ??? (in usr/lib/libraw1394.so.11.0.1)by 0x405D6F8 : fw_write (in usr/lib/libraw1394.so.11.0.1)by 0x405A292 : raw1394_write (in usr/lib/libraw1394.so.11.0.1)by 0x805A0F2 : main (main.cpp:121) Recently, I modify libraw1394-2.1.0 source code. fw.c: static inthandle_arm_request(raw1394handle_t handle, struct address_closure *ac, int tcode, unsigned long long offset, int source_node_id, int card, unsigned kernel_handle, size_t length, void *data){ ......- return fwhandle->arm_tag_handler(handle, allocation->tag, type,length, &rrb->request_response);+ int retval;+ retval = fwhandle->arm_tag_handler(handle, allocation->tag, type, length, &rrb->request_response);+ free(rrb);+ return retval;} This way can solve my problem. Best Regards, Cewd |
From: Daniel M. <dan...@go...> - 2013-09-05 16:38:15
|
Hello list. I try to capture video from a miniDV camera via my firewire port. But I get errors and segfaults on every combination of kernel and dvgrab software I have tried. On the latest Debian 7.1 I get at least the message "Found AV/C device" but then segfaults. Any idea what's the problem here and how to make it work? For debugging I'll attach - syslog when plugging in camera - output of `dvgrab` - syslog when running `dvgrab` - lsmod - lspci - partial lspci -vvv - output of `aptitude show dvgrab` - full `dmesg`, due to message size limit here: https://gist.github.com/vlt/6452548 - full `lspci -vvv`, here: https://gist.github.com/vlt/6452592 == syslog when plugging in camera == Sep 5 06:11:37 imitator kernel: [ 29.149240] firewire_core: skipped bus generations, destroying all nodes Sep 5 06:11:38 imitator kernel: [ 29.648035] firewire_core: rediscovered device fw0 Sep 5 06:11:38 imitator kernel: [ 29.648078] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Sep 5 06:11:38 imitator kernel: [ 29.648287] firewire_core: skipped bus generations, destroying all nodes Sep 5 06:11:38 imitator kernel: [ 30.148032] firewire_core: rediscovered device fw0 Sep 5 06:11:39 imitator kernel: [ 31.037495] firewire_core: created device fw1: GUID 008045802058247f, S100 Sep 5 06:11:40 imitator kernel: [ 31.652015] firewire_core: giving up on config rom for node id ffc0 == output of `dvgrab` == root@imitator:~# dvgrab Found AV/C device with GUID 0x008045802058247f Waiting for DV... Speicherzugriffsfehler == syslog when running `dvgrab` == Sep 5 06:13:06 imitator kernel: [ 118.071816] dvgrab[1998]: segfault at a206081e ip 0806b673 sp b0138090 error 4 in dvgrab[8048000+3e000] == lsmod == root@imitator:~# lsmod Module Size Used by snd_hda_codec_realtek 142274 1 snd_hda_intel 21786 0 snd_hda_codec 63477 2 snd_hda_codec_realtek,snd_hda_intel snd_hwdep 12943 1 snd_hda_codec snd_pcm 53461 2 snd_hda_codec,snd_hda_intel snd_page_alloc 12867 2 snd_pcm,snd_hda_intel evdev 17225 0 psmouse 59609 0 pcspkr 12515 0 serio_raw 12803 0 snd_timer 22356 1 snd_pcm snd 42722 6 snd_timer,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_codec_realtek,snd_hda_intel soundcore 12921 1 snd i2c_i801 12670 0 acpi_cpufreq 12807 0 mperf 12421 1 acpi_cpufreq iTCO_wdt 16945 0 coretemp 12770 0 processor 27565 3 acpi_cpufreq button 12817 0 i2c_core 19116 1 i2c_i801 iTCO_vendor_support 12632 1 iTCO_wdt thermal_sys 17752 1 processor ext4 306996 1 crc16 12327 1 ext4 jbd2 52330 1 ext4 mbcache 12938 1 ext4 dm_mod 57362 2 sg 21476 0 sd_mod 35425 3 crc_t10dif 12332 1 sd_mod ahci 24917 2 ata_generic 12439 0 firewire_ohci 26784 0 libahci 18308 1 ahci uhci_hcd 22337 0 pata_jmicron 12432 0 firewire_core 38753 1 firewire_ohci crc_itu_t 12331 1 firewire_core ehci_hcd 35509 0 r8169 41802 0 libata 125014 4 pata_jmicron,libahci,ata_generic,ahci mii 12595 1 r8169 scsi_mod 135037 3 libata,sd_mod,sg usbcore 104555 3 ehci_hcd,uhci_hcd usb_common 12338 1 usbcore == lspci == root@imitator:~# lspci 00:00.0 Host bridge: Intel Corporation 4 Series Chipset DRAM Controller (rev 02) 00:1a.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 00:1a.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 00:1a.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller 00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 00:1c.3 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 4 00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 5 00:1c.5 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 6 00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90) 00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller 00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller 02:00.0 IDE interface: JMicron Technology Corp. JMB368 IDE controller 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) 05:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 264VT [Mach64 VT] (rev 40) 05:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) == partial lspci -vvv == 05:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology GA-EP45-DS5/GA-EG45M-DS2H 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: 32 (500ns min, 1000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 23 Region 0: Memory at f5004000 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at f5000000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+ Kernel driver in use: firewire_ohci == aptitude show dvgrab == root@imitator:~# aptitude show dvgrab Package: dvgrab State: installed Automatically installed: yes Version: 3.5-2 Priority: extra Section: video Maintainer: Erik Schanze <er...@de...> Architecture: i386 Uncompressed Size: 338 k Depends: libavc1394-0 (>= 0.5.3), libc6 (>= 2.3.6-6~), libdv4, libgcc1 (>= 1:4.1.1), libiec61883-0 (>= 1.2.0), libjpeg8 (>= 8c), libquicktime2 (>= 2:1.2.2), libraw1394-11, libstdc++6 (>= 4.4.0), zlib1g (>= 1:1.1.4) Description: grab digital video data via IEEE1394 and USB links dvgrab receives audio and video data from a digital camcorder via an IEEE1394 (widely known as FireWire) or USB link and stores them into one of several file formats. It features autosplit of long video sequences, and supports saving the data as raw frames, AVI type 1, AVI type 2, Quicktime DV, a series of JPEG stills or MPEG2-TS. Homepage: http://www.kinodv.org/ |
From: Stefan R. <st...@s5...> - 2013-08-29 20:58:28
|
Hi all, Linux kernel 3.11 is due to be released soon. It contains the following changes to the IEEE 134 subsystem: Userspace API: Fix corrupted video capture, seen with IIDC/DCAM applications and certain buffer settings. This fixes a regression since kernel 3.4 inclusive. The fix has also been released in kernels 3.10.5, 3.8.13.7, 3.5.7.19, and 3.4.56. Kernelspace API: The kernel-internal programming interface between firewire-core and protocol drivers was slightly changed to better support drivers which need to apply device-specific parameters or routines. Out-of-tree developers who maintain a stable history can git pull git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git fw_driver-api-transition to receive mainline commit 94a87157cde9. A transition to the current programming interface can be based on this commit in a bisectable manner. -- 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: 李 英瑋 <cha...@ho...> - 2013-08-22 10:44:45
|
Hi all, I use raw1394 to transmit my data through Address Range Mapping. The raw1394 work, but a memory leak problem will happen when program call raw1394 function. The following result is that I use valgrind to check this problem. ...19572 bytes in 1 blocks are still reachable in loss record 32 of 36at 0x4029F6F : malloc (vg_replace_malloc.c : 270)by 0x405C250: fw_new_handle (in usr/lib/libraw1394.so.11.0.1)by 0x40595AC : raw1394_new_handle (in usr/lib/libraw1394.so.11.0.1)by 0x805A0F2 : main (main.cpp : 121)...3067120 (3066560 direct, 560 indirect) bytes in 10952 blocks are definitely lost in loss record 36 of 36at 0x4029F6F : malloc ()by 0x405B1B5 : ??? (in usr/lib/libraw1394.so.11.0.1)by 0x405B492 : ??? (in usr/lib/libraw1394.so.11.0.1)by 0x405BF24 : fw_loop_iterate (in usr/lib/libraw1394.so.11.0.1)by 0x405C197 : ??? (in usr/lib/libraw1394.so.11.0.1)by 0x405D6F8 : fw_write (in usr/lib/libraw1394.so.11.0.1)by 0x405A292 : raw1394_write (in usr/lib/libraw1394.so.11.0.1)by 0x805A0F2 : main (main.cpp:121) I've try libraw1394-2.0.7 and libraw1394-2.1.0. $lsmodModule Size Used byfirewire_ohci 39592 0 firewire_core 55074 1 firewire_ohcicrc_itu_t 12523 1 firewire_core $lspci ...FireWire (IEEE 1394) : VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) Please help me. Best Regards, Cewd |
From: Stefan R. <st...@s5...> - 2013-07-20 08:31:39
|
Hi all, about three weeks ago, Linux kernel 3.10 has been released with the following changes to the IEEE 1394 subsystem: firewire-net: - added support for IPv6-over-1394 compliant with RFC 3146 (final implementation by YOSHIFUJI Hideaki, initial work and further verifications by Stephan Gatzka) - release isochronous reception DMA context at ifdown - fix small memory leak at shutdown firewire-ohci: - fix the longstanding failure to receive video on VIA VT6306 with gstreamer, MythTV, and maybe dv4l (debugged and fixed by Andy Leiserson) - fix a startup issue with Agere/LSI FW643-e2 (debugged and fixed by Peter Hurley) - fix controller removal when controller is in suspended state - improved error logging The VT 6306 and FW643-e2 fixes should apparently also be backported into 3.x-longterm kernel series. This hasn't happened yet partially due to a current shortage of spare time on my part, partially because I prefer to give these changes some more time of exposure in the current stable 3.10.x and main 3.11 series. -- Stefan Richter -=====-===-= -=== =-=-- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2013-06-27 19:19:48
|
Max wrote: > 00:02.0 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03) > 00:06.0 Multimedia audio controller: ULi Electronics Inc. M5451 PCI AC-Link Controller Audio Device (rev 02) > 00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge [Aladdin IV/V/V+] > 00:08.0 Modem: ULi Electronics Inc. M5457 AC'97 Modem Controller > 00:10.0 IDE interface: ULi Electronics Inc. M5229 IDE (rev c4) > 00:11.0 Bridge: ULi Electronics Inc. M7101 Power Management Controller [PMU] That is the M1535D+ southbridge of the ALi MAGiK 1 chipset. Some random review I found on the net has this to say: <http://www.tomshardware.com/print/a-real-nail,reviews-319.html> | Overall, the poor success to overclock the test candidates reflects | the questionable quality of the ALi chipset. [...] ALi has still got | a chance for success once the quality problems have been eliminated. | Right now however, the only thing ALi Magik 1 has going for it is its | low price. It's no wonder that Compaq decided to replace the northbridge with one from AMD. You can be happy that there is some setting where it works at all. If the problem is the frequency switching, the "powersave" governor might work, too. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2013-06-26 20:04:15
|
Max wrote: > When the cpu is "on demand" mode (ie cpu clock can vary) and I try to write data to my harddrive connected via firewire, I get very quickly an I/O error. > On the other hand, when I fix my cpu clock (I use the max speed), there is no I/O error and the access read or write through the firewire never fails. I vaguely remember some older chipsets having problems with PowerNow. What is your southbridge chip (see lspci)? Regards, Clemens |
From: Max <dos...@ya...> - 2013-06-26 18:46:30
|
Hello, I am reporting here a bug with the use of my firewire harddisk enclosure on my linux system. My laptop has an athlon XP cpu with the "mobile" technology, this means that the clock of my cpu can vary depending on the demand. When the cpu is "on demand" mode (ie cpu clock can vary) and I try to write data to my harddrive connected via firewire, I get very quickly an I/O error. On the other hand, when I fix my cpu clock (I use the max speed), there is no I/O error and the access read or write through the firewire never fails. This problem was already exisiting with the "old" spb2 driver and still exists with the new driver. Some more info about my config: - kernel: 3.7.10-gentoo - distri: gentoo - my computer: Compaq presario 2120EU - my firewire device is an IDE to firewire enclosure for 3,5' harddrives. The chip labeling is "PL3507 LF06018A". - my firewire controller: lspci | grep Fire 00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) As said, I can circonvent this problem easily, by setting my CPU to max speed, then plug my hardware enclosure and enjoy. Additional information: -1- This enclosure was initialy not recognized when I was plugging it in. This problem was solved by changing the /lib/udev/scsi_id file permission from rwxr_xr_x to rw_r__r__ as reported in a previous post (post initially started by Peter Christy on 2012-02-20). -2- My enclosure requires a "workarounds" option which reduces the firewire speed. Before I plug the firewire cable, the module is started as follow : modprobe firewire_ohci && modprobe firewire_sbp2 workarounds=0x1 Feel free to ask for more details if needed. Best |
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-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/ |