linux1394-user Mailing List for IEEE 1394 for Linux (Page 9)
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...> - 2012-07-29 10:47:07
|
Hi all, a new minor release of libraw1394 is now available. libraw1394 is the Linux legacy programming interface to low-level IEEE 1394 I/O. Although new application development is encouraged to prefer the <linux/firewire-cdev.h> ABI over libraw1394, this time we did add a few new APIs to libraw1394. Behavior changes of the backend to firewire-core: - The isochronous reception buffer is now mapped read/writable rather than read-only. The raw1394 backend already maps the buffer read/writable too. Note that writing into the buffer will go wrong on architectures without cache-coherent DMA if the CPU and the OHCI write within the same cacheline region, so use this feature with caution. - Decrease memory footprint of IR and IT buffers by avoiding some internal rounding up of the buffer size. New APIs in <libraw1394/raw1394.h>: - raw1394_add_config_rom_descriptor(): Add contents to the Configuration ROM of the local node(s). At runtime, this API is only available if running on top of firewire-core. It could probably also be implemented with the raw1394 kernel driver if anybody cared. - raw1394_remove_config_rom_descriptor(): Counterpart to raw1394_add_config_rom_descriptor(). - raw1394_read_cycle_timer_and_clock(): Like the existing raw1394_read_cycle_timer(), but lets the caller choose between CLOCK_REALTIME (which the former call is always using), CLOCK_MONOTONIC, or CLOCK_MONOTONIC_RAW. For example, this enables libffado's audio streaming to run undisturbed by resets of CLOCK_REALTIME. At runtime, this call requires firewire-core underneath. - raw1394_get_speed(): Returns the speed code of the maximum possible transmission speed between a given node and the local node. This takes maximum speeds of all participating PHYs and the two links into account. This can be used to configure the speed of isochronous streams. At runtime, this call requires firewire-core underneath. - enum raw1394_iso_speed was extended by RAW1394_ISO_SPEED_800, _1600, and _3200. New APIs in <libraw1394/ieee1394.h>: - Added preprocessor constants L1394_SPEED_BETA, L1394_SPEED_800, _1600, and _3200. testlibraw1394: Added unit tests of the new APIs. ------------------------------------------------------------------------ Gitweb: https://git.kernel.org/?p=libs/ieee1394/libraw1394.git Git clone: git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git https://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git Tarball: https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.0.tar.bz2 https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.0.tar.gz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.0.tar.xz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.0.tar.sign ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.0.tar.bz2 ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.0.tar.gz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.0.tar.xz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.0.tar.sign To verify a downloaded tarball, first uncompress from one of the *.tar.{bz2,gz,xz} to *.tar, then run "gpg --verify libraw1394-2.1.0.tar.sign". ------------------------------------------------------------------------ Shortlog and diffstat from v2.0.9 to v2.1.0: B.J. Buchalter (1): Add raw1394_add_config_rom_descriptor() and raw1394_remove_config_rom_descriptor() API Igor Kuzmin (2): Enable write access to isochronous reception buffer Disable power-of-2 alignment of isochronous I/O buffers Stefan Richter (10): Tweak raw1394_add_config_rom_descriptor() API, add documentation and test case Add raw1394_read_cycle_timer_and_clock() API Increase libtool version to 2.1.0 Remove now unused code Fix documentation of raw1394_iso_multichannel_recv_init() Add 1394b speed codes to <libraw1394/{ieee,raw}1394.h> Trivial whitespace normalization in ieee1394.h and raw1394.h Add raw1394_get_speed() API testlibraw: Fix printing of card name Changelog, NEWS: update to version 2.1.0 ChangeLog | 40 +++++++ NEWS | 40 +++++++ configure.ac | 8 +- src/dispatch.c | 61 +++++++++++ src/fw-iso.c | 49 ++++----- src/fw.c | 62 +++++++++++ src/fw.h | 11 +- src/ieee1394.h | 11 +- src/raw1394.h | 413 ++++++++++++++++++++++++++++++++++++++++++++--------------------------- tools/testlibraw.c | 104 ++++++++++++++++-- 10 files changed, 593 insertions(+), 206 deletions(-) -- Stefan Richter -=====-===-- -=== ===-= http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-07-29 10:37:00
|
Hi everybody, as you certainly noticed, Linux kernel 3.5 has been released 8 days ago. It brings the following IEEE 1394 related changes: firewire-core: - Fix mismatch between DMA mapping direction and DMA synchronization direction of isochronous reception buffers of userspace drivers if vma-mapped for R/W access. Depending on IOMMU properties of the hardware, this bug could have caused e.g. failures to capture video through libdc1394. - more consistent retry stategy in device discovery/ rediscovery, and improved failure diagnostics sbp-target: - New driver written by Chris Boot: Adds SCSI target functionality over FireWire. This enables a Linux node to act as SBP-2/ SCSI device to other nodes on the FireWire bus, for example as hard disk — similar to FireWire Target Disk mode of the firmware of many Apple computers. Any SCSI command set supported by the Linux target core, multiple logical units on the target node, and concurrent login by initiators are supported by sbp-target. In the kernel configuration menu, the sbp-target option resides under "Device Drivers/ Generic Target Core Mod (TCM) and ConfigFS Infrastructure/ FireWire SBP-2 fabric module". sbp-target thus takes the place of the older SBP-2 target implementation, "Endpoint" from Oracle. Endpoint is a userspace implementation and requires libraw1394 plus the old raw1394 kernel driver (but could be ported to libraw1394 v2.1.0 and the current firewire-core driver). Furthermore, Endpoint so far only supports the RBC command set. Some brief getting-started instructions have been collected at https://ieee1394.wiki.kernel.org/index.php/Sbp-target . -- Stefan Richter -=====-===-- -=== ===-= http://arcgraph.de/sr/ |
From: D M <sk...@gm...> - 2012-06-11 23:57:33
|
Hi Stefan, thanks for your prompt reply! I`ve got the debug messages you asked for. Please find attached two files with the top and the bottom of the relevant dmesg-es. Best, Skaumo 2012/6/11 Stefan Richter <st...@s5...>: > On Jun 11 D M wrote: >> I recently upgraded my PC, except for the old lovely Firewire adapter >> I had for a long time. >> As you can imagine, the reason why I`m writing is that I can`t seem to >> get it working any more, with Juju, and a 3.4 kernel. >> >> I`ve seen a number of forums discussing the same issue I have. Namely >> the below one best describes my problems, except that I`m a Gentoo >> user. >> >> http://ubuntuforums.org/showthread.php?p=8542962 > > These are unrelated problems. > >> This thread has been opened in 2008, and people are still posting on >> it. Is it possible for anyone to give some help fixing this? >> >> >> Some dmessages I get (while manually and randomly adding and removing modules): >> >> >> firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc1 >> firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 >> firewire_core 0000:03:07.0: rediscovered device fw0 >> firewire_core 0000:03:07.0: rediscovered device fw0 >> firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 >> firewire_core 0000:03:07.0: rediscovered device fw0 >> firewire_core 0000:03:07.0: created device fw1: GUID 0080880305904d96, S100 >> firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 >> firewire_core 0000:03:07.0: rediscovered device fw0 >> firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc1 >> firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 >> firewire_core 0000:03:07.0: rediscovered device fw0 >> firewire_core 0000:03:07.0: rediscovered device fw0 >> firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 >> firewire_core 0000:03:07.0: rediscovered device fw0 >> firewire_core 0000:03:07.0: created device fw1: GUID 0080880305904d96, S100 >> firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 >> net firewire0: IPv4 over IEEE 1394 on card 0000:03:07.0 >> firewire_core 0000:03:07.0: created device fw2: GUID 00004c020001afb5, S400 >> firewire_core 0000:03:07.0: rediscovered device fw1 >> firewire_core 0000:03:07.0: rediscovered device fw2 >> firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 >> firewire_core 0000:03:07.0: rediscovered device fw2 >> firewire_core 0000:03:07.0: created device fw0: GUID 0080880305904d96, S100 >> firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 > > Looks like hardware problems. > > Disconnect the camcorder, run "modprobe -r firewire-ohci", then "modprobe > firewire-ohci debug=-1", connect the camcorder, and post the resulting > kernel log. > > PS, > /dev/raw1394 no longer exists and is no longer needed. > -- > Stefan Richter > -=====-===-- -==- -=-== > http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-06-11 21:18:11
|
On Jun 11 D M wrote: > I recently upgraded my PC, except for the old lovely Firewire adapter > I had for a long time. > As you can imagine, the reason why I`m writing is that I can`t seem to > get it working any more, with Juju, and a 3.4 kernel. > > I`ve seen a number of forums discussing the same issue I have. Namely > the below one best describes my problems, except that I`m a Gentoo > user. > > http://ubuntuforums.org/showthread.php?p=8542962 These are unrelated problems. > This thread has been opened in 2008, and people are still posting on > it. Is it possible for anyone to give some help fixing this? > > > Some dmessages I get (while manually and randomly adding and removing modules): > > > firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc1 > firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 > firewire_core 0000:03:07.0: rediscovered device fw0 > firewire_core 0000:03:07.0: rediscovered device fw0 > firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 > firewire_core 0000:03:07.0: rediscovered device fw0 > firewire_core 0000:03:07.0: created device fw1: GUID 0080880305904d96, S100 > firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 > firewire_core 0000:03:07.0: rediscovered device fw0 > firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc1 > firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 > firewire_core 0000:03:07.0: rediscovered device fw0 > firewire_core 0000:03:07.0: rediscovered device fw0 > firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 > firewire_core 0000:03:07.0: rediscovered device fw0 > firewire_core 0000:03:07.0: created device fw1: GUID 0080880305904d96, S100 > firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 > net firewire0: IPv4 over IEEE 1394 on card 0000:03:07.0 > firewire_core 0000:03:07.0: created device fw2: GUID 00004c020001afb5, S400 > firewire_core 0000:03:07.0: rediscovered device fw1 > firewire_core 0000:03:07.0: rediscovered device fw2 > firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 > firewire_core 0000:03:07.0: rediscovered device fw2 > firewire_core 0000:03:07.0: created device fw0: GUID 0080880305904d96, S100 > firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 Looks like hardware problems. Disconnect the camcorder, run "modprobe -r firewire-ohci", then "modprobe firewire-ohci debug=-1", connect the camcorder, and post the resulting kernel log. PS, /dev/raw1394 no longer exists and is no longer needed. -- Stefan Richter -=====-===-- -==- -=-== http://arcgraph.de/sr/ |
From: D M <sk...@gm...> - 2012-06-11 19:22:01
|
Greetings, I recently upgraded my PC, except for the old lovely Firewire adapter I had for a long time. As you can imagine, the reason why I`m writing is that I can`t seem to get it working any more, with Juju, and a 3.4 kernel. I`ve seen a number of forums discussing the same issue I have. Namely the below one best describes my problems, except that I`m a Gentoo user. http://ubuntuforums.org/showthread.php?p=8542962 This thread has been opened in 2008, and people are still posting on it. Is it possible for anyone to give some help fixing this? Some dmessages I get (while manually and randomly adding and removing modules): firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc1 firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 firewire_core 0000:03:07.0: rediscovered device fw0 firewire_core 0000:03:07.0: rediscovered device fw0 firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:03:07.0: rediscovered device fw0 firewire_core 0000:03:07.0: created device fw1: GUID 0080880305904d96, S100 firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 firewire_core 0000:03:07.0: rediscovered device fw0 firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc1 firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 firewire_core 0000:03:07.0: rediscovered device fw0 firewire_core 0000:03:07.0: rediscovered device fw0 firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:03:07.0: rediscovered device fw0 firewire_core 0000:03:07.0: created device fw1: GUID 0080880305904d96, S100 firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 net firewire0: IPv4 over IEEE 1394 on card 0000:03:07.0 firewire_core 0000:03:07.0: created device fw2: GUID 00004c020001afb5, S400 firewire_core 0000:03:07.0: rediscovered device fw1 firewire_core 0000:03:07.0: rediscovered device fw2 firewire_core 0000:03:07.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:03:07.0: rediscovered device fw2 firewire_core 0000:03:07.0: created device fw0: GUID 0080880305904d96, S100 firewire_core 0000:03:07.0: giving up on Config ROM for node id ffc0 testlibraw successfully got handle current generation number: 0 1 card found card 0, name: /dev/fw2 1 nodes on bus, local ID is 0, IRM is 0 - doing transactions with custom tag handler read from node 0... completed with value 0x7bff0404 - using standard tag handler and synchronous calls read from node 0... completed with value 0x7bff0404 - testing FCP monitoring on local node got fcp command from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef lspci says: 03:07.0 FireWire (IEEE 1394): NEC Corporation uPD72873 IEEE1394 OHCI 1.1 2-port Host Controller (rev 01) Really hope somebody over here can help, as I haven`t found any solution on the forums around :( Best regards, Skaumo |
From: Clemens L. <cl...@la...> - 2012-06-11 19:17:18
|
Alexandre Prokoudine wrote: > I've run into a really annoying issue on Ubuntu 12.04: the FireWire > device files are not created, even though the device is attached and > is powered from the FireWire cable. > > $ lspci > 05:00.0 FireWire (IEEE 1394): Reply Group Device 3044 (rev 46) "Reply Group" = 1006 "VIA Technologies" = 1106 1106:3044 would be the VT6306 controller. One of the PCI data lines is broken. I'm sure this has nothing to do with the Ubuntu version. Regards, Clemens |
From: Alexandre P. <ale...@gm...> - 2012-06-11 14:03:25
|
Hi, I've run into a really annoying issue on Ubuntu 12.04: the FireWire device files are not created, even though the device is attached and is powered from the FireWire cable. The device is Focusrite Saffire PRO24. $ uname -a Linux darkroom 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux $ lspci -k 05:00.0 FireWire (IEEE 1394): Reply Group Device 3044 (rev 46) Subsystem: Reply Group Device 3044 Kernel modules: firewire-ohci $ lsmod | grep -e 1394 -e firewire firewire_ohci 40172 0 firewire_core 56906 1 firewire_ohci crc_itu_t 12627 1 firewire_core However $ ls -l /dev/fw* already says there are no such files or directories, and same for $ grep . /sys/bus/firewire/devices/fw*/*_name Also, $ grep -e 1394 -e firewire /proc/interrupts is silent too I've absolutely no idea whatsoever what could be wrong. The same configuration used to work on the previous version of Ubuntu with a slightly older kernel (not sure about older/newer stack, though). Complete output from ffado-diag is here: http://pastebin.com/iT0cW4bd Alexandre Prokoudine http://libregraphicsworld.org |
From: Stefan R. <st...@s5...> - 2012-06-02 15:53:11
|
Dear all, another stable sub-release of libraw1394 (the Linux legacy programming interface to low-level IEEE 1394 I/O) is now available. The changes: - Fix that raw1394_iso_recv_flush() did not have any effect when running on firewire-core alias juju kernel drivers. Requires kernel 3.4 or later. - Remove build-time dependency on linux-headers. Before, if too old kernel headers were present on the build system, features and fixes would be silently omitted from the build. - Remove --with-fw-dir configure switch which is no longer useful. - Janitorial fixes. Gitweb: https://git.kernel.org/?p=libs/ieee1394/libraw1394.git Git clone: git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git https://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git Tarball: https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.9.tar.bz2 https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.9.tar.gz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.9.tar.xz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.9.tar.sign ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.9.tar.bz2 ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.9.tar.gz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.9.tar.xz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.9.tar.sign To verify a downloaded tarball, first uncompress from one of the *.tar.{bz2,gz,xz} to *.tar, then run "gpg --verify libraw1394-2.0.9.tar.sign". Shortlog and diffstat from v2.0.8 to v2.0.9: Clemens Ladisch (1): Implement raw1394_iso_recv_flush() on Juju Guus Sliepen (2): Remove UTF-8 whitespace. Fix incorrect use of == instead of =. Stefan Richter (4): Add firewire-{cdev,constants}.h from Linux v3.4 Include local firewire-*.h instead of system-wide <linux/firewire-*.h> Remove unused code configure.ac, Changelog, NEWS etc.: update to version 2.0.9 ChangeLog | 18 ++ NEWS | 10 + configure.ac | 9 +- src/Makefile.am | 11 +- src/firewire-cdev.h | 1038 ++++++++++++++++++++++++++++++++++++++++++++++ src/firewire-constants.h | 92 ++++++ src/fw-iso.c | 10 +- src/fw.c | 66 +---- src/fw.h | 4 +- src/readwrite.c | 2 +- 10 files changed, 1177 insertions(+), 83 deletions(-) create mode 100644 src/firewire-cdev.h create mode 100644 src/firewire-constants.h -- Stefan Richter -=====-===-- -==- ---=- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-06-02 09:55:21
|
About a week ago I noticed silent data corruptions of files on FireWire disks: Mount disk, read lots of data and e.g. compute their md5sum, unmount disk, mount disk again, read and md5sum the same files again -> MD5s may differ. Defects in files that were written in May hint that not only reading from but also writing to FireWire disks resulted in corrupt data. This was silent corruption without any error messages from the PCI, firewire, SCSI, block, or filesystem subsystems. Affected: - kernel 3.4 - kernel 3.4-rc5 Not affected: - kernel 3.3.1 (which I have been running now for the last 6 days) I used these three kernels with the same patchlevel of FireWire drivers, namely circa those which are about to be released in 3.5-rc1. FireWire disks with different 1394-to-SATA or -IDE bridge chips are affected. I noticed the problem at first on an Agere FW643e PCIe 1394 controller which sits behind a PLX PEX 8505 PCIe switch. MPEG2TS video reception through the same 1394 controller and PCIe switch did never show a noticable sign of corruption. I did not have time yet to systematically test - whether all of my FireWire controllers are affected, - whether SATA or USB disks are affected (SATA probably not, USB not used yet), - whether my secondary Linux PC is affected. Kernel 3.4 and 3.4-rc5 exhibited another (seemingly harmless but suspicious) issue on my primary PC: frequent transmit queue time-outs of an RTL8111/8168B Ethernet interface, http://www.spinics.net/lists/netdev/msg197032.html Being busy at work lately and not having Linux available at work, I will be slow to look further into it. With enough spare time, it should be possible to identify the regression by bisection between kernel 3.3 and 3.4-rc but I have no estimate when I will be able to spend that time. -- Stefan Richter -=====-===-- -==- ---=- http://arcgraph.de/sr/ |
From: A&M A. <new...@am...> - 2012-05-29 02:25:41
|
: http://list.mlgngo.com/track/click?u=8ae5780d22688d976ebce9d8fb3db81c&id=376d822e&e=ec48533c 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.mlgngo.com/unsubscribe?u=8ae5780d22688d976ebce9d8fb3db81c&id=0f55a446&e=ec48533c&c=c693dd37&ln=en A&M Architects, in...@am..., Athens, Attica, 11257, Greece Email Marketing by www.mailigen.com |
From: Stefan R. <st...@s5...> - 2012-05-24 20:44:58
|
Hi all, Linux kernel 3.4 has been released last Sunday. These are the IEEE 1394 related changes: <linux/firewire-cdev.h> API: - Added FW_CDEV_IOC_FLUSH_ISO ioctl which lets an application get any currently completed isochronous packets reported. A corresponding libraw1394 update to use this ioctl in raw1394_iso_recv_flush() has been committed to libraw1394.git too and will show up in the next libraw1394 release. firewire-core, -net, -ohci, -sbp2: - All messages to the kernel log are now consistently prefixed by driver name and device name or number. firewire-ohci: - Fix premature completion of multichannel isochronous reception DMA. Also fixed in kernel 3.3.1, 3.2.14, 3.0.27. - Fix missing completion notification in isochronous I/O in case of big intervals between interrupt packets or with big packet headers. firewire-sbp2: - If the target's unit directory contains a Unit_Unique_ID entry, use it instead of the node unique ID as the target's GUID in the ieee1394_id sysfs attribute and consequently in udev's /dev/disk/by-id symbolic links. - Do not try to log into targets on the local node. I/O to such targets is not yet implemented, and local targets are probably meant to be accessed by remote initiators anyway. - Fix handling of SCSI sense data (deferred errors, Valid, Filemark, EOM, ILI). -- Stefan Richter -=====-===-- -=-= ==--- http://arcgraph.de/sr/ |
From: Lluís B. i R. <vi...@vi...> - 2012-05-11 17:48:52
|
On Fri, May 11, 2012 at 07:47:12PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > lspci fails, after hang. > > # lspci -s 2:0 -vvv > > 02:00.0 ... (rev ff) (prog-if ff) > > All reads fail (I guess -x instead of -vvv will show all ff's). > This means the chip doesn't react at all, as if it were unplugged. > > This looks like a plain hardware error. Oh. Bad luck. This motherboard also hangs from time to time. Very annoying. Thank you for all your time! |
From: Clemens L. <cl...@la...> - 2012-05-11 17:47:36
|
Lluís Batlle i Rossell wrote: > lspci fails, after hang. > # lspci -s 2:0 -vvv > 02:00.0 ... (rev ff) (prog-if ff) All reads fail (I guess -x instead of -vvv will show all ff's). This means the chip doesn't react at all, as if it were unplugged. This looks like a plain hardware error. Regards, Clemens |
From: Lluís B. i R. <vi...@vi...> - 2012-05-11 15:55:59
|
On Fri, May 11, 2012 at 04:13:03PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > On Thu, May 10, 2012 at 03:50:15PM +0200, Clemens Ladisch wrote: > >> Please show the output of "lspci -s 2:0 -vvv" after a cold boot and > >> after a suspend/resume. > > > > Here they are. Only 'RollOver' has a difference, watching on vimdiff. Not that I > > know what is it about. > > A "reply number rollover" happens when the device failed four times to > send a PCIe packet. This is automatically handled by retraining the > link and retrying again. This might be a consequence of the suspend. > > What I actually wanted to ask: Is there any difference in the lspci > output before and during a hang? Ah, ok. Yes, very different - lspci fails, after hang. # lspci -s 2:0 -vvv 02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: firewire_ohci Does it tell anything good? Thank you, Lluís. |
From: Clemens L. <cl...@la...> - 2012-05-11 14:09:19
|
Lluís Batlle i Rossell wrote: > On Thu, May 10, 2012 at 03:50:15PM +0200, Clemens Ladisch wrote: >> Please show the output of "lspci -s 2:0 -vvv" after a cold boot and >> after a suspend/resume. > > Here they are. Only 'RollOver' has a difference, watching on vimdiff. Not that I > know what is it about. A "reply number rollover" happens when the device failed four times to send a PCIe packet. This is automatically handled by retraining the link and retrying again. This might be a consequence of the suspend. What I actually wanted to ask: Is there any difference in the lspci output before and during a hang? Regards, Clemens |
From: Lluís B. i R. <vi...@vi...> - 2012-05-10 20:32:26
|
On Thu, May 10, 2012 at 03:50:15PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > Yes, the interrupt count increases, the usb works fine. > > So the problem is not with IRQ 19 itself but with the routing of the PCI > interrupt line from the controller to IRQ19. Ah ok. I'm glad someone understands a bit how that works. It's not my case. I only know until the 8259, two cascaded at most. :) > Please show the output of "lspci -s 2:0 -vvv" after a cold boot and > after a suspend/resume. Here they are. Only 'RollOver' has a difference, watching on vimdiff. Not that I know what is it about. Just to avoid confusion, the firewire hangs either if it just rebooted or it came back from suspend. No difference. Thank you, Lluís. |
From: Clemens L. <cl...@la...> - 2012-05-10 13:46:31
|
Lluís Batlle i Rossell wrote: > # lsfirewirephy > bus 0, node 1: 001163:306001 VIA Technologies VT630x Many thanks. As excpected, no changes from the VT6308. > On Thu, May 10, 2012 at 03:29:17PM +0200, Clemens Ladisch wrote: >> Lluís Batlle i Rossell wrote: >>> 19: 7 0 1 533 IO-APIC-fasteoi ehci_hcd:usb2, firewire_ohci >> >> Could you check whether this EHCI controller that shares the same >> interrupt works in this situation, i.e., if high-speed USB devices >> work on these ports? (Check whether there are USB ports where these >> interrupt counts increase when you plug something in.) > > Yes, the interrupt count increases, the usb works fine. So the problem is not with IRQ 19 itself but with the routing of the PCI interrupt line from the controller to IRQ19. Please show the output of "lspci -s 2:0 -vvv" after a cold boot and after a suspend/resume. Regards, Clemens |
From: Lluís B. i R. <vi...@vi...> - 2012-05-10 13:29:12
|
On Thu, May 10, 2012 at 03:29:17PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > On Wed, May 09, 2012 at 08:21:29AM +0200, Clemens Ladisch wrote: > >> Lluís Batlle i Rossell wrote: > >>> # lsfirewirephy > >>> timeout > >>> timeout > >> > >> (This should work directly after booting, before any hang.) > > > > Yes, they work fine. > > And what _is_ the output? :) Sorry. Now with camera: # lsfirewirephy bus 0, node 0: 080028:424296 Texas Instruments TSB41AB1/2 bus 0, node 1: 001163:306001 VIA Technologies VT630x > > 19: 7 0 1 533 IO-APIC-fasteoi ehci_hcd:usb2, firewire_ohci > > Could you check whether this EHCI controller that shares the same > interrupt works in this situation, i.e., if high-speed USB devices > work on these ports? (Check whether there are USB ports where these > interrupt counts increase when you plug something in.) Yes, the interrupt count increases, the usb works fine. Thank you a lot, Lluís. |
From: Clemens L. <cl...@la...> - 2012-05-10 13:25:33
|
Lluís Batlle i Rossell wrote: > On Wed, May 09, 2012 at 08:21:29AM +0200, Clemens Ladisch wrote: >> Lluís Batlle i Rossell wrote: >>> # lsfirewirephy >>> timeout >>> timeout >> >> (This should work directly after booting, before any hang.) > > Yes, they work fine. And what _is_ the output? :) >> What is the entire output of dmesg immediately after booting? What are the >> outputs of "cat /proc/interrupt" and "dmesg | tail" when it hangs? > > I attach the dmesg, but it does not have the firewire camera connected now. > [33793.225644] [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu > [33793.225644] perf: IBS APIC setup failed on cpu #1 > [33793.227208] [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu > [33793.227208] perf: IBS APIC setup failed on cpu #2 > [33793.228639] [Firmware Bug]: cpu 3, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu > [33793.228639] perf: IBS APIC setup failed on cpu #3 These errors should not affect you, and it appears are normal with the BIOSes for certain CPU family. There's nothing else relevant in the log. > 19: 7 0 1 533 IO-APIC-fasteoi ehci_hcd:usb2, firewire_ohci Could you check whether this EHCI controller that shares the same interrupt works in this situation, i.e., if high-speed USB devices work on these ports? (Check whether there are USB ports where these interrupt counts increase when you plug something in.) Regards, Clemens |
From: Lluís B. i R. <vi...@vi...> - 2012-05-09 21:28:38
|
On Wed, May 09, 2012 at 08:21:29AM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > # lsfirewirephy > > timeout > > timeout > > (This should work directly after booting, before any hang.) Yes, they work fine. > All these symptoms indicate that the FireWire interrupt just isn't reported > anymore. Ok. > > I updated the i7 machine to 3.3.5 too, and there it does not hang. Same chipset, > > same kernel, but in the phenomII it hangs (any of the two cameras we have, > > colour and mono), and in the i7 not. > > So this is probably not related with the VT6315 itself but with the system's > interrupt routing. Sometimes, this is caused by ACPI problems; try updating > the BIOS, if possible. I run the latest BIOS available two weeks ago. I wanted to get k8-powernow, and hence updated the bios. But I really did not notice any change other than the 'nicer' bios configuration and boot screens. I also run the latest microcode in the cpu. :) > What is the entire output of dmesg immediately after booting? What are the > outputs of "cat /proc/interrupt" and "dmesg | tail" when it hangs? I attach the dmesg, but it does not have the firewire camera connected now. 'dmesg | tail' when it hangs does not have any additional line. I attach the full dmesg (after a pm-suspend and awake), and the /proc/interrupts. Now gzipped. Regards, Lluís. |
From: Clemens L. <cl...@la...> - 2012-05-09 06:17:37
|
Lluís Batlle i Rossell wrote: > I notice that, let's say, my /usr/include/linux is from 2.6.35, and I've all > built with those headers. Is the public API of the kernel changed at 3.3.x, for > firewire? There were some additions in 2.6.36, but none of them affect your applications. > # lsfirewirephy > timeout > timeout (This should work directly after booting, before any hang.) All these symptoms indicate that the FireWire interrupt just isn't reported anymore. > I updated the i7 machine to 3.3.5 too, and there it does not hang. Same chipset, > same kernel, but in the phenomII it hangs (any of the two cameras we have, > colour and mono), and in the i7 not. So this is probably not related with the VT6315 itself but with the system's interrupt routing. Sometimes, this is caused by ACPI problems; try updating the BIOS, if possible. What is the entire output of dmesg immediately after booting? What are the outputs of "cat /proc/interrupt" and "dmesg | tail" when it hangs? Regards, Clemens |
From: Stefan R. <st...@s5...> - 2012-05-08 19:20:30
|
On May 08 Stefan Richter wrote: > One potential cause for never timing out would be if the controller never > gives us an AT-req IRQ ('asynchronous request transmitted' interrupt). > That would be a chip bug against which our drivers are currently not > protected. JMicron JMB38x is known to behave that way; I have particularly > observed it with Coriander (IIDC capture application). However, I have not > yet heard of VIA VT6315 behaving this way. > > (The old driver stack would time out even after missing AT-req IRQ, as > would earlier versions of the newer driver stack --- at the risk of races > with transaction completion though.) > > I'm not saying that this is what happens, just suggesting it as a > possibility. PS, I forgot: A bus reset would flush such stuck requests out (hence Clemens' suggestion to test a bus reset...). But that only works if the controller's self-ID-complete DMA and interrupts still work. Alas, if the controller stopped issuing AT-req IRQs due to whatever fault, chances are limited that it would still issue self-ID-complete IRQs. -- Stefan Richter -=====-===-- -=-= -=--- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-05-08 18:28:59
|
On May 08 Lluís Batlle i Rossell wrote: > On Tue, May 08, 2012 at 06:31:36PM +0200, Lluís Batlle i Rossell wrote: > > On Tue, May 08, 2012 at 06:28:50PM +0200, Lluís Batlle i Rossell wrote: > > > On Tue, May 08, 2012 at 05:30:34PM +0200, Clemens Ladisch wrote: > > > > Lluís Batlle i Rossell wrote: > > > > > SysRq : Show Blocked State > > > > > task PC stack pid father > > > > > cc1394 D ffffffff81407520 0 5918 5880 0x00000005 > > > > > Call Trace: > > > > > [<ffffffff813c8baf>] schedule+0x3f/0x60 > > > > > [<ffffffffa0106fcd>] fw_device_op_release+0x18d/0x250 [firewire_core] One potential cause for never timing out would be if the controller never gives us an AT-req IRQ ('asynchronous request transmitted' interrupt). That would be a chip bug against which our drivers are currently not protected. JMicron JMB38x is known to behave that way; I have particularly observed it with Coriander (IIDC capture application). However, I have not yet heard of VIA VT6315 behaving this way. (The old driver stack would time out even after missing AT-req IRQ, as would earlier versions of the newer driver stack --- at the risk of races with transaction completion though.) I'm not saying that this is what happens, just suggesting it as a possibility. After # echo 2 > /sys/module/firewire_ohci/parameters/debug the driver will log all AT and AR events that do happen; alas it won't reveal a case when upper layers inserted a request but the controller did not raise AT-req. To detect that, we would have to modify the driver to log request insertion too. > Sorry, but before I told you the phenomII was running 3.3.4, but it is running > 3.3.5. > > I updated the i7 machine to 3.3.5 too, and there it does not hang. Same chipset, > same kernel, but in the phenomII it hangs (any of the two cameras we have, > colour and mono), and in the i7 not. > > Annoying... Any idea from this confusion? :) That's curious. Maybe these are two different chip revisions? lspci would possibly still show them with same revision number; a look at the actual chip may or may not tell more. Are these PCIe cards which you could swap between the two PCs? -- Stefan Richter -=====-===-- -=-= -=--- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-05-08 18:13:56
|
On May 08 Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > Another thing I could not find anywhere is that in the 2.6.35 computer, I get > > /dev/raw1394 and /dev/video1394-0. In the 3.3.x computer, I don't get any such > > device node, and I don't have any modules named raw1394 or video1394. > > The FireWire stack was completely rewritten. Check that your libraw1394 package > is recent enough (current is 2.0.8, but 2.0.6 or newer should work). In any > case, this library could not cause the kernel to lock up. On the older kernel stack, libdc1394 per default uses direct video1394 accesses for video capture but raw1394 accesses via libraw1394 for discovery, control and status I/O. (It also had a mode in which it used libraw1394 + raw1394 also for video capture, but support for that mode was removed in kernel 2.6.23 and libraw1394 2.0. I don't know if it was removed from the libdc1394 v2 codebase too; could be.) On the newer kernel stack, libdc1394 uses /dev/fw* for everything, without assistance by libraw1394. libdc1394 v2.1.2 (06/2009) is recommended as the minimum version to use together with the newer kernel stack; v2.2.0 (03/2012) is current. I don't know if the libdc1394 version could have an impact on the kind of behavior here, nor am I familiar with how well the VT6315 works for IIDC applications. I only have a VT6306 and two low-end IIDC cameras; it's been a while that I tested the VT6306 with these cameras. However, VT6306 is known to behave differently from (buggier than) VT6307/08/15. -- Stefan Richter -=====-===-- -=-= -=--- http://arcgraph.de/sr/ |
From: Lluís B. i R. <vi...@vi...> - 2012-05-08 16:37:17
|
On Tue, May 08, 2012 at 06:31:36PM +0200, Lluís Batlle i Rossell wrote: > On Tue, May 08, 2012 at 06:28:50PM +0200, Lluís Batlle i Rossell wrote: > > On Tue, May 08, 2012 at 05:30:34PM +0200, Clemens Ladisch wrote: > > > Lluís Batlle i Rossell wrote: > > > > SysRq : Show Blocked State > > > > task PC stack pid father > > > > cc1394 D ffffffff81407520 0 5918 5880 0x00000005 > > > > Call Trace: > > > > [<ffffffff813c8baf>] schedule+0x3f/0x60 > > > > [<ffffffffa0106fcd>] fw_device_op_release+0x18d/0x250 [firewire_core] Sorry, but before I told you the phenomII was running 3.3.4, but it is running 3.3.5. I updated the i7 machine to 3.3.5 too, and there it does not hang. Same chipset, same kernel, but in the phenomII it hangs (any of the two cameras we have, colour and mono), and in the i7 not. Annoying... Any idea from this confusion? :) |