gmane.linux.kernel.firewire.user

Problems in 3.3.x with via VT6315

Lluís Batlle i Rossell — 2012-05-08T10:44:46

Hello,

here we have two computers, both with VT6315, running all x86_64, one is an
intel i7 and the other an amd Phenom II.

The I7 runs 2.6.35 and dc1394 cameras work perfectly in it.
The Phenom II runs 3.3.4 and dc1394 cameras work for a short seconds, and hang.
Then the process hangs too. Killing the process leaves it <defunct> (unrelated
to the parent accepting it or not). Using the same userland software in both
computers.

I can't test 3.3.4 on the I7 easily, but I imagine something could have got
broken for the VT6315 since 2.6.35.

Can anyone confirm that VT6315 works in 3.3.x kernels?

Regards,
Lluís.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

PCIe card recommendation

Carl Karsten — 2012-04-24T19:50:52

I need to buy 20 or so PCIe firewire 400 cards.  (10 machines, 2 cards
each, or 1 card with 2 bus/chips - I need to plug in 2 dv video
devices)

Has anyone shopped around recently?

Are there any I should avoid?

Multiple file descriptors and ISO receive contexts

Chris Wj — 2012-04-06T20:15:12

Hi all. I am currently having a problem with multiple file descriptors
and ISO receive contexts. I'm looking to be notified of data on 2
separate channels using 2 file descriptors and read their data
separately. I'd like to have one event loop that reads both
descriptors but I have had trouble with select(). It looked like
select() would only detect data on the first ISO channel's file
descriptor. I could use the notification on the first to read from
both but I don't like the possibility that my second read could block.
 Is this normal operation?  Can I set the second file descriptor
options to non-blocking or is there a better way to poll the two
descriptors?

Also, we got our hands on PointGrey Firewire cards so we don't have
the problems you mentioned concerning the TI chips.

-Chris
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. T

Multi-channel receive

Chris Wj — 2012-03-29T16:51:49

Hey all. I am trying to figure out the best way to perform a multi-channel
receive using the raw interface. The data is coming from a single device
(custom, not common audio/video), but does not have to be joined together.
The packet size is around 8K as well, so I have to use the new driver so I
am not limited by the kernel pagesize. Basically, I want to listen and read
from 2 channels (0 and 1) and process their data separately. Can I set up 2
threads with 2 distinct handles to read from the same device but different
channels?

I'm  new to Firewire development so apologies if these are simple questions.

Thanks much,
Chris
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

Changes to the FireWire kernel drivers in Linux 3.3

Stefan Richter — 2012-03-20T13:49:51

Hi all,

Linux 3.3 has been released on Sunday.  This time there were only two
small changes to the FireWire drivers.

firewire-ohci:
  - Add workaround for the 1394 part of Creative SoundBlaster Audigy
    in order to fix transaction failures.
  - Fix random malfunctions of Ricoh PCI Express 1394 controllers by
    disabling MSI (message signaled interrupts).

These changes were also backmerged into kernel 3.2.6 and 3.0.21.  In
kernel 3.0.25, two forgotten older fixes from the 3.1 release were
backmerged (fix for recognition of some old camcorders; 32 bit userspace on
64 bit kernel compatibility fix).

Loosely related to FireWire (but also USB, SATA, and other interconnects):
Just last week between 3.3-rc7 and 3.3 final, some fixes for kernel
crashes at hot unplug of storage devices were committed.  E.g. an infamous
bug with card readers has been addressed.  Nevertheless I suspect that the
hunt for hot-unplug related bugs in and around the kernel's block layer is
not yet over.

Since there is so little to s

Unable to access firewire hard drive

Peter Christy — 2012-02-20T16:11:17

System: Slackware64-13.37
Kernel: 3.2.2
Libraw1394 2.0.7

# lspci | grep FireWire
01:06.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 04)

# lsmod | grep firewire
firewire_sbp2          10977  0 
firewire_ohci          26284  0 
firewire_core          41461  2 firewire_sbp2,firewire_ohci
crc_itu_t               1185  2 udf,firewire_core


#dmesg
firewire_core: created device fw1: GUID 0050770e00071002, S400, 3 config ROM 
retries
firewire_core: phy config: card 0, new root=ffc0, gap_count=5
scsi5 : SBP-2 IEEE-1394
firewire_sbp2: Workarounds for fw1.0: 0x20 (firmware_revision 0x012804, model_id 
0x000001)
firewire_sbp2: fw1.0: logged in to LUN 0000 (0 retries)
scsi 5:0:0:0: Direct-Access-RBC ST316002 2ACE                  PQ: 0 ANSI: 4
sd 5:0:0:0: Attached scsi generic sg4 type 14
sd 5:0:0:0: [sdd] 312558593 512-byte logical blocks: (160 GB/149 GiB)
sd 5:0:0:0: [sdd] Write Protect is off
sd 5:0:0:0: [sdd] Mode Sense: 11 00 00 00
sd 5:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't suppo

Problem using raw1394_iso_recv_init() - the irq_interval parameter

Alexander Neundorf — 2012-01-08T21:54:27

Hi,

I seem to have a strange problem with the irq_interval parameter of 
raw1394_iso_recv_init().
It seems to have an upper limit of 512. Is that possible ?

If I set it to higher values than that, I still get the callback after 512 
packets have arrived.

This is on a Slackware 13.37, kernel 2.6.37.6, 32bit x86, juju stack, OHCI 
driver.

Before I was using much smaller values, so I'm not sure whether this is 
something new or not.

Thanks
Alex

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Problem using raw1394_iso_recv_init() - the irq_interval parameter

Alexander Neundorf — 2012-01-08T21:54:27

Hi,

I seem to have a strange problem with the irq_interval parameter of 
raw1394_iso_recv_init().
It seems to have an upper limit of 512. Is that possible ?

If I set it to higher values than that, I still get the callback after 512 
packets have arrived.

This is on a Slackware 13.37, kernel 2.6.37.6, 32bit x86, juju stack, OHCI 
driver.

Before I was using much smaller values, so I'm not sure whether this is 
something new or not.

Thanks
Alex

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Problem using raw1394_iso_recv_init() - the irq_interval parameter

Alexander Neundorf — 2012-01-08T21:54:27

Hi,

I seem to have a strange problem with the irq_interval parameter of 
raw1394_iso_recv_init().
It seems to have an upper limit of 512. Is that possible ?

If I set it to higher values than that, I still get the callback after 512 
packets have arrived.

This is on a Slackware 13.37, kernel 2.6.37.6, 32bit x86, juju stack, OHCI 
driver.

Before I was using much smaller values, so I'm not sure whether this is 
something new or not.

Thanks
Alex

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

libraw1394 and libiec61883 tarballs back on kernel.org

Stefan Richter — 2012-01-03T21:29:07

Hi all,

it took longer than necessary, but now the source release tarballs of
libraw1394 v0.5...v2.0.7 and libiec61883 v1.0.0...v1.2.0 are finally
available at their former place at kernel.org again:

    ftp://ftp.kernel.org/pub/linux/libs/ieee1394/
    http://www.kernel.org/pub/linux/libs/ieee1394/
    https://www.kernel.org/pub/linux/libs/ieee1394/

There is a general change of policies and processes at kernel.org:
Uploaded files are no longer gpg-signed by a daemon at kernel.org but by
the person who uploaded them.  Only signatures for the original *.tar files
are installed at kernel.org.  This means that you first need to uncompress
a downloaded file before you can verify its authenticity, e.g.:

    $ wget ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libiec61883-1.2.0.tar.{xz,sign}
    $ xz -d libiec61883-1.2.0.tar.xz
    $ gpg --verify libiec61883-1.2.0.tar.sign

The tarballs at above URLs are the same as the ones that were there before
the kernel.org break-in last year, i.e. I did not generate new o

fw drive in 11.10

Carl Karsten — 2012-01-02T03:50:21

when I plug in a firewire drive, this is all I see in dmesg:

[10518.283056] firewire_core: phy config: card 0, new root=ffc1, gap_count=5
[10518.807684] firewire_core: created device fw1: GUID 00203702003442f7, S400

If I boot the same box a live 10.04 all is fine.

If I boot 11.10, plug in dv cam, kino, camera stream shows fine.


-
Carl K

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Firewire drive sbp2_scsi_abort issue

Keith Smith — 2011-12-28T19:04:44

Hi guys,

I'm hoping you can help me out here, or point me in the direction of somewhere better.  I've had a quick look at the list archive but didn't see my exact problem, but apologies in advance if I missed something.

I recently upgraded an old laptop I use for file and print (Sony Viao PCG-GR215SP(DE) Pentium IIIm 1.2GHz) from Ubuntu 8 to 11.4 and now I am having real problems with firewire connected disks.

In short, after several hours of good operation "something" causes the bus to sbp2_scsi_abort, usually during a write operation, triggering a cascade failure where the drive winds up remounted read-only and reliable (an umount in this state will sometimes hang).

Here is a typical log of events:
http://pastebin.ca/2097049

Linux version 2.6.38-13-generic-pae (buildd< at >roseapple) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #53-Ubuntu SMP Mon Nov 28 19:41:58 UTC 2011

firewire_ohci          31504  0 
firewire_core          56138  1 firewire_ohci
crc_itu_t              12627  1 firewire_core

00:

node not destroyed on unplug

Carl Karsten — 2011-12-20T15:41:35

un/re-plugging the cable. waiting a few seconds between each (but not
watching syslog, so maybe didn't wait long enough...)  - 3 or 4 worked
fine, fw2,3 created/destroyed as expected, then I unplug, and fw2
doesn't destroy:

juser< at >pc8:~$ ls /dev/fw?
/dev/fw0  /dev/fw1  /dev/fw2

and syslog has a ton of
Dec 20 09:08:22 pc8 kernel: [ 2325.059013] firewire_ohci: AR
evt_bus_reset, generation 0
.... 0-255
loop that 25 times.

Dec 20 09:08:08 pc8 kernel: [ 2310.108394] firewire_ohci: AR
evt_bus_reset, generation 4
Dec 20 09:08:08 pc8 kernel: [ 2310.108482] firewire_ohci: isochronous
cycle too long
Dec 20 09:08:08 pc8 kernel: [ 2310.108614] firewire_ohci: AR
evt_bus_reset, generation 5
Dec 20 09:08:08 pc8 kernel: [ 2310.108786] firewire_ohci: AR
evt_bus_reset, generation 6
Dec 20 09:08:08 pc8 kernel: [ 2310.108993] firewire_ohci: 1 selfIDs,
generation 6, local node ID ffc0
Dec 20 09:08:08 pc8 kernel: [ 2310.109004] firewire_ohci: selfID 0:
807f8842, phy 0 [-..] S400 gc=63 +
0W Lci
Dec 20 09:08:08 pc8 kernel: [ 2310

cable woe

Carl Karsten — 2011-12-19T19:29:47

I have been using 2 cables to test with.  both 4-6
#1 6'
#2 15'

I boot box, plug in #1, both ends are detected.
try #2, no ends.
try #1, both ends.
try #2, no ends

seems like a bad cable.
so I plug #2 into a dv cam, cam gets fw2, dv plays in kino just fine.
un plug cam, plug back into laptop, no ends.
back into cam, dv2.
back into laptop,no ends.

I have about 100 firewire cables, probably 10 the same as #2: 4-6,
15', same manufacture.
I also have other boxes I could use to help figure out what is going on.

But I am hesitant to start introducing more hardware without some
guidence.  any suggestions?

half a loop

Carl Karsten — 2011-12-18T00:23:24

same hardware, but new flavor of problem:  2 controllers in one box,
cable looped from one to the other.  (it is the 2m cable that seems to
cause the "isochronous cycle inconsistent" in the other thread.

juser< at >pc8:~$ ls /dev/fw?
/dev/fw0  /dev/fw1  /dev/fw2

juser< at >pc8:~$ uname -a
Linux pc8 3.2.0-4-generic #10-Ubuntu SMP Sat Dec 10 17:46:09 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux

juser< at >pc8:~$ dmesg |grep fire

[    1.935578] firewire_ohci 0000:02:05.0: PCI INT A -> Link[LNK1] ->
GSI 5 (level, low) -> IRQ 5
[    1.988295] firewire_ohci: Added fw-ohci device 0000:02:05.0, OHCI
v1.10, 4 IR + 4 IT contexts, quirks 0x1
[    1.988453] firewire_ohci: isochronous cycle inconsistent
[    1.993092] firewire_ohci 0000:04:00.0: PCI INT A -> Link[LK1E] ->
GSI 16 (level, low) -> IRQ 16
[    1.993098] firewire_ohci 0000:04:00.0: setting latency timer to 64
[    2.051121] firewire_ohci: Added fw-ohci device 0000:04:00.0, OHCI
v1.10, 8 IR + 8 IT contexts, quirks 0x10
[    2.051204] firewire_ohci: isochronous cycle inconsist

isochronous cycle inconsistent

Carl Karsten — 2011-12-16T05:10:25

laptop with onboard and pcie slot.

2 test suggest this only happens when i plug the card in after boot.
if it is plugged in when the kernel boots, no problem (and no need for
the acpiphp module)  So maybe it is a hot plug problem.

boot with no card, load acpiphp

plugged in a fw pcie card:

[  107.481212] pci 0000:04:00.0: [11c1:5901] type 0 class 0x000c00
[  107.481252] pci 0000:04:00.0: reg 10: [mem 0x00000000-0x00000fff 64bit]
[  107.481342] pci 0000:04:00.0: supports D1 D2
[  107.481349] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[  107.481359] pci 0000:04:00.0: PME# disabled
[  107.488468] pci 0000:04:00.0: BAR 0: assigned [mem
0xf2000000-0xf2000fff 64bit]
[  107.488488] pci 0000:04:00.0: BAR 0: set to [mem
0xf2000000-0xf2000fff 64bit] (PCI address [0xf2000000-0xf2000fff])
[  107.488519] pci 0000:04:00.0: no hotplug settings from platform
[  107.494034] firewire_ohci 0000:04:00.0: enabling device (0000 -> 0002)
[  107.494595] ACPI: PCI Interrupt Link [LK1E] enabled at IRQ 16
[  107.49

basler camera on firewire

Robert Lemmen — 2011-11-01T23:44:02

hi everyone,

not sure how to approach this, don't know much about linux firewire
support/ any pointers welcome:

I have a basler a601f firewire camera, and a debian squeeze machine that
I would like to use the camera with. kernel is a 2.6.32-5-amd64, lspci
lists my firewire card:

03:01.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 61)

lsmod | grep firew reports:

firewire_ohci          19676  0 
firewire_core          36848  2 firewire_sbp2,firewire_ohci
crc_itu_t               1307  1 firewire_core

i tail /var/log/kern.log and modprobe firewire_ohci debug=7 (after
removing it first of course):

Nov  1 23:40:08 sandbender kernel: [54557.082719] firewire_ohci
0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Nov  1 23:40:08 sandbender kernel: [54557.152008] firewire_ohci: Added
fw-ohci device 0000:03:01.0, OHCI version 1.0
Nov  1 23:40:08 sandbender kernel: [54557.152014] firewire_ohci: IRQ
00000010 AR_req
Nov  1 23:40:08 sandbender kernel: [54557.152020] firewire_ohci: AR
evt_bus_reset, gen

ioctl get_info: Bad address

Carl Karsten — 2011-08-09T14:22:21

new box, used it for a weekend of video, no problem. getting back to
making tests:

(veyepar)juser< at >cnt2:~$ sudo async-test receive 001e8c00004166f5
/dev/fw0: Success
001e8c00004166f5
001e8c00004166f5 65472 65472
ioctl get_info: Bad address

https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c

(veyepar)juser< at >cnt2:~$ lspci|grep 1394
04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series
Firewire Controller (rev 01)
08:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev 46)

plug in cable, new dmesg:
[  258.595688] irq_handler: 6 callbacks suppressed
[  258.595692] firewire_ohci: isochronous cycle inconsistent
[  258.595752] firewire_core: phy config: card 0, new root=ffc1, gap_count=5
[  259.091178] firewire_core: created device fw2: GUID 0011066600000566, S400
[  259.091295] firewire_core: created device fw3: GUID 001e8c00004166f5, S400

Raw reads from TI XIO2200(A) fail between 1800 and 2048 with RCODE 17

Mike Auty — 2011-08-01T19:58:50

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

I've been using libforensic1394 to carry our raw reads of windows memory
using firewire from a linux system.  The setup is a linux box with a
built-in firewire adaptor:

 03:00.4 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd Device [1180:e832]
(rev 03)

And the windows box has had an expresscard inserted to ensure firewire
support.  The card used shows up as follows under linux:

05:00.0 PCI bridge [0604]: Texas Instruments XIO2000(A)/XIO2200(A) PCI
Express-to-PCI Bridge [104c:8231] (rev 03)
06:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2200(A)
IEEE-1394a-2000 Controller (PHY/Link) [104c:8235] (rev 01)

When running the code, the request_size is returned as 2048 (as
expected), but when carrying out reads of various sizes, the results are
consistent and valid up until 1800 bytes (exactly) and then 1801 - 1805
sometimes work and sometimes don't, and beyond that they almost always
fail.  Above 2048, the error returned is a request_size too big er

fw1 not created for dv-camera

René Fritz — 2011-07-30T17:13:22

Hi

My mini-dv camcorder is not detected.

The same hardware once worked, I guess with ohci1394 but I can't say 
definitely. I have a firewire scanner which works fine, but the camcorder not.

I already searched the web for a solution but couldn't find one. At least none 
that helped me.

As I understand the problem is that the device /dev/fw1 will no be created due 
to some problems I don't understand :-)

Any help is much appreciated
René



Here are the facts:

kubuntu 11.04 natty
kernel 2.6.38-11 and I tried 3.0.0 too

camcoder Grundig Scenos (old one but works fine for me :-)


# lspci | grep 1394
03:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 
Controller (PHY/Link)

(onboard controller)


# lsmod | grep firewire
firewire_sbp2          23099  0 
firewire_ohci          40832  0 
firewire_core          64614  2 firewire_sbp2,firewire_ohci
crc_itu_t              12707  1 firewire_core


# ls /dev/fw*
/dev/fw0


# dmesg (with debug=7)
[12018.315369] firewire_ohci: IRQ 00000010 AR

came makes bus angry

Carl Karsten — 2011-07-29T03:39:41

ASUS motherboard, one on board firewire, one pci card.

plug camera into card, all works fine.  plug into on board and things fail

(veyepar)juser< at >cnt2:~$ lspci |grep 13
04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series
Firewire Controller (rev 01)
08:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev 46)

(veyepar)juser< at >cnt2:~$ dvgrab
Error: no camera exists

[ 1106.523403] firewire_core: skipped bus generations, destroying all nodes
[ 1107.020284] firewire_core: rediscovered device fw0
[ 1561.141043] firewire_core: skipped bus generations, destroying all nodes
[ 1561.638991] firewire_core: rediscovered device fw0
[ 1561.638999] firewire_core: giving up on config rom for node id ffc0
[ 1572.087990] firewire_ohci: isochronous cycle inconsistent
[ 1572.798527] firewire_core: created device fw2: GUID 008045821097902b, S100
[ 1572.798534] firewire_core: phy config: card 1, new root=ffc1, gap_count=5
[ 1572.799208] firewire_core: IRM is not 1