linux1394-user Mailing List for IEEE 1394 for Linux (Page 2)
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: Takashi S. <o-t...@sa...> - 2016-10-09 12:13:20
|
Hi Stefan, On Oct 9 2016 19:32, Stefan Richter wrote: > Thanks for the explanations. I edited the changelog at > ieee1394.wiki.kernel.org accordingly. Thanks for the updates. And I realized that IEC 61883-6 packet streaming driver project in GSoC 2009. Is this an initial work for current IEC 61883-1/6 packet streaming engine in ALSA? https://www.google-melange.com/archive/gsoc/2009/orgs/linux_foundation/projects/mircea.html Well, in this year 1394TA disclosed the most of their specifications in below page. I think it good to add an article about it in the wiki. http://1394ta.org/specifications/ Regards Takashi Sakamoto |
From: Stefan R. <st...@s5...> - 2016-10-09 10:32:41
|
On Sep 23 Takashi Sakamoto wrote: > On Sep 22 2016 22:05, Stefan Richter wrote: > > Linux 4.4 (10 January 2016) [...] > > snd-firewire-lib > > - numerous changes for additional device driver support > > - Handle "unexpected protocol" error with some BeBoB devices, e.g. > > M-Audio FireWire 1814. > > This is for a regression which comes from a series of work to > restructure firewire-lib. So it's not newly added. > > The restructuring is done by an idea to split 'data block processing' > layer from 'isochronous packet processing' layer. This is needed to > integrate firewire-digi00x/firewire-tascam because models which > supported by these new drivers are not compliant to IEC 61883-6. > > You can see information about a part of protocols which the models use > in below web-pages: > http://subversion.ffado.org/wiki/digi003rack > http://subversion.ffado.org/wiki/Tascam/FW-1804 > > This is aim of the 'numerous changes'. Thanks for the explanations. I edited the changelog at ieee1394.wiki.kernel.org accordingly. -- Stefan Richter -======----- =-=- -=--= http://arcgraph.de/sr/ |
From: Takashi S. <o-t...@sa...> - 2016-09-22 23:21:16
|
On Sep 22 2016 22:05, Stefan Richter wrote: > Hi all, > > it's been almost a year since I last posted release notes for the IEEE 1394 > kernel drivers. Since then, changes were made mostly in the audio drivers > by Takashi Sakamoto. Minor changes presumably without practical impact are > not mentioned here. > > > Linux 4.8 (tentative, as per v4.8-rc7) > -------------------------------------- > > snd-firewire-tascam, snd-fireworks > - Fix possible deadlock in hwdep interface. Also fixed in v4.4.21 and > v4.7.4. > > > Linux 4.7 (24 July 2016) > ------------------------ > > snd-dice > - Add support for M-Audio Profire 610, and perhaps for Profire 2626. > > snd-firewire-lib > - Add tracepoints to dump a part of isochronous packet data in order to > support debugging of device quirks and of kernel-internal packet > processing. The patch changelog describes how to use this feature: > https://git.kernel.org/linus/0c95c1d6197f > A subsequent commit expands the dump format: > https://git.kernel.org/linus/a9c4284bf5a9 > > snd-firewire-lib, snd-bebob, snd-firewire-tascam, snd-fireworks > - Remove matching of SYT fields of the outbound stream to those of the > inbound stream since it proves to be unnecessary in practice. The > same was already done in snd-dice in Linux v4.6. This simplifies the > kernel code and allows for finer-grained tasklet scheduling. > > snd-firewire-lib, snd-bebob, snd-firewire-digi00x, snd-firewire-tascam, > snd-fireworks, snd-oxfw > - Perform sound card registration at least 2 seconds after the last IEEE > 1394 bus reset. This was already implemented for snd-dice in Linux > v4.5 and is now adopted by the other FireWire audio drivers. It > ensures that the bus and device firmware settle into a ready state > before userspace initiate I/O to the device. > > > Linux 4.6 (15 May 2016) > ----------------------- > > snd-bebob > - internal rework related to streaming recovery after bus reset > > snd-dice > - Change how the dependency between number of available PCM and MIDI > channels versus sampling rate is handled. Also affects the hw_params > ioctl interface. Userspace should set the desired sampling rate > before starting PCM I/O. > - Change how phase lock is ensured and how lock status is detected. > - Remove matching of SYT fields of the outbound stream to those of the > inbound stream. This synchronization happened when the device was > configured for internal clock. It required a startup delay of the > outbound stream, which caused DICE II based devices to remain silent > at the first attempt to start streaming. > - Add support for previously unavailable higher PCM channels on certain > devices with high channel count, notably Focusrite Saffire PRO 40, > Focusrite Liquid Saffire 56, and TC Electronic Studio Konnekt 48. > These devices spread the PCM and MIDI channels across 2 tx + 2 rx IEEE > 1394 channels instead of just 1 tx + 1 rx IEEE 1394 channel, as most > other devices do. > > snd-oxfw > - improvements to MIDI I/O > > > Linux 4.5 (13 March 2016) > ------------------------- > > snd-dice > - Improved handling of DICE II firmware bootstrapping during device > start-up. > - Avoid time-out when PCM streaming is started. > > snd-firewire-tascam > - Add support for TASCAM FW-1804. > > snd-scs1x > - The functionality of this driver was moved to the snd-oxfw driver, and > the now obsolete snd-scs1x module has been removed. > > > Linux 4.4 (10 January 2016) > --------------------------- > > firewire-ohci > - Work around JMicron JMB38x initialization quirk. Affected isochronous > transmission, e.g. audio via FFADO or ALSA. Also fixed in v4.3.3, > v4.2.8, v4.1.15, v3.14.59, v3.12.52, v3.10.95, 3.2.74. > > snd-bebob > - Fix device identifier of Mackie Onyx 1220/1620/1640 FireWire I/O card. > > snd-dice > - Fix device identifier of Mackie Onyx Blackbird and Onyx-i series. > > snd-firewire-digi00x > - New driver for Digidesign audio interfaces: Digi 002 Console, Digi 002 > Rack, Digi 003 Console, Digi 003 Rack, Digi 003 Rack+. Written by > Takashi Sakamoto. > > snd-firewire-lib > - numerous changes for additional device driver support > - Handle "unexpected protocol" error with some BeBoB devices, e.g. > M-Audio FireWire 1814. This is for a regression which comes from a series of work to restructure firewire-lib. So it's not newly added. The restructuring is done by an idea to split 'data block processing' layer from 'isochronous packet processing' layer. This is needed to integrate firewire-digi00x/firewire-tascam because models which supported by these new drivers are not compliant to IEC 61883-6. You can see information about a part of protocols which the models use in below web-pages: http://subversion.ffado.org/wiki/digi003rack http://subversion.ffado.org/wiki/Tascam/FW-1804 This is aim of the 'numerous changes'. > snd-firewire-tascam > - New driver for TASCAM audio interfaces: FW-1082, FW-1884. Written by > Takashi Sakamoto. > > snd-oxfw > - Fix Mackie Onyx Satellite packet discontinuity when device is used in > base station mode. > - Add support for TASCAM FireOne. > - Fix calculation of MIDI ports. > - Fix for statically linked (i.e. non-modular) builds. Regards Takashi Sakamoto |
From: Stefan R. <st...@s5...> - 2016-09-22 13:05:30
|
Hi all, it's been almost a year since I last posted release notes for the IEEE 1394 kernel drivers. Since then, changes were made mostly in the audio drivers by Takashi Sakamoto. Minor changes presumably without practical impact are not mentioned here. Linux 4.8 (tentative, as per v4.8-rc7) -------------------------------------- snd-firewire-tascam, snd-fireworks - Fix possible deadlock in hwdep interface. Also fixed in v4.4.21 and v4.7.4. Linux 4.7 (24 July 2016) ------------------------ snd-dice - Add support for M-Audio Profire 610, and perhaps for Profire 2626. snd-firewire-lib - Add tracepoints to dump a part of isochronous packet data in order to support debugging of device quirks and of kernel-internal packet processing. The patch changelog describes how to use this feature: https://git.kernel.org/linus/0c95c1d6197f A subsequent commit expands the dump format: https://git.kernel.org/linus/a9c4284bf5a9 snd-firewire-lib, snd-bebob, snd-firewire-tascam, snd-fireworks - Remove matching of SYT fields of the outbound stream to those of the inbound stream since it proves to be unnecessary in practice. The same was already done in snd-dice in Linux v4.6. This simplifies the kernel code and allows for finer-grained tasklet scheduling. snd-firewire-lib, snd-bebob, snd-firewire-digi00x, snd-firewire-tascam, snd-fireworks, snd-oxfw - Perform sound card registration at least 2 seconds after the last IEEE 1394 bus reset. This was already implemented for snd-dice in Linux v4.5 and is now adopted by the other FireWire audio drivers. It ensures that the bus and device firmware settle into a ready state before userspace initiate I/O to the device. Linux 4.6 (15 May 2016) ----------------------- snd-bebob - internal rework related to streaming recovery after bus reset snd-dice - Change how the dependency between number of available PCM and MIDI channels versus sampling rate is handled. Also affects the hw_params ioctl interface. Userspace should set the desired sampling rate before starting PCM I/O. - Change how phase lock is ensured and how lock status is detected. - Remove matching of SYT fields of the outbound stream to those of the inbound stream. This synchronization happened when the device was configured for internal clock. It required a startup delay of the outbound stream, which caused DICE II based devices to remain silent at the first attempt to start streaming. - Add support for previously unavailable higher PCM channels on certain devices with high channel count, notably Focusrite Saffire PRO 40, Focusrite Liquid Saffire 56, and TC Electronic Studio Konnekt 48. These devices spread the PCM and MIDI channels across 2 tx + 2 rx IEEE 1394 channels instead of just 1 tx + 1 rx IEEE 1394 channel, as most other devices do. snd-oxfw - improvements to MIDI I/O Linux 4.5 (13 March 2016) ------------------------- snd-dice - Improved handling of DICE II firmware bootstrapping during device start-up. - Avoid time-out when PCM streaming is started. snd-firewire-tascam - Add support for TASCAM FW-1804. snd-scs1x - The functionality of this driver was moved to the snd-oxfw driver, and the now obsolete snd-scs1x module has been removed. Linux 4.4 (10 January 2016) --------------------------- firewire-ohci - Work around JMicron JMB38x initialization quirk. Affected isochronous transmission, e.g. audio via FFADO or ALSA. Also fixed in v4.3.3, v4.2.8, v4.1.15, v3.14.59, v3.12.52, v3.10.95, 3.2.74. snd-bebob - Fix device identifier of Mackie Onyx 1220/1620/1640 FireWire I/O card. snd-dice - Fix device identifier of Mackie Onyx Blackbird and Onyx-i series. snd-firewire-digi00x - New driver for Digidesign audio interfaces: Digi 002 Console, Digi 002 Rack, Digi 003 Console, Digi 003 Rack, Digi 003 Rack+. Written by Takashi Sakamoto. snd-firewire-lib - numerous changes for additional device driver support - Handle "unexpected protocol" error with some BeBoB devices, e.g. M-Audio FireWire 1814. snd-firewire-tascam - New driver for TASCAM audio interfaces: FW-1082, FW-1884. Written by Takashi Sakamoto. snd-oxfw - Fix Mackie Onyx Satellite packet discontinuity when device is used in base station mode. - Add support for TASCAM FireOne. - Fix calculation of MIDI ports. - Fix for statically linked (i.e. non-modular) builds. -- Stefan Richter -======----- =--= =-==- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2016-08-15 19:56:20
|
On Jul 09 Adam Goldman wrote: > I'm trying to capture video from a Sony DCR-TRV120. When I turn it on, I > get a continuous loop of the following messages on the console: > > Jun 24 19:00:06 starship kernel: [ 845.491993] firewire_ohci 0000:09:00.0: node ID not valid, new bus reset in progress > Jun 24 19:00:07 starship kernel: [ 846.632134] firewire_core 0000:09:00.0: rediscovered device fw0 > Jun 24 19:00:07 starship kernel: [ 846.718717] firewire_core 0000:09:00.0: rediscovered device fw1 > Jun 24 19:00:07 starship kernel: [ 846.718799] firewire_core 0000:09:00.0: phy config: new root=ffc1, gap_count=5 > Jun 24 19:00:07 starship kernel: [ 846.718950] firewire_ohci 0000:09:00.0: node ID not valid, new bus reset in progress > Jun 24 19:00:08 starship kernel: [ 847.860130] firewire_core 0000:09:00.0: rediscovered device fw0 > Jun 24 19:00:08 starship kernel: [ 847.946744] firewire_core 0000:09:00.0: rediscovered device fw1 > Jun 24 19:00:08 starship kernel: [ 847.946834] firewire_core 0000:09:00.0: phy config: new root=ffc1, gap_count=5 > > This is with a fresh Debian 8.5 install and the vendor kernel. uname > output is: > > Linux starship 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 Linux > > I'm using an IBM 19K5680 (FRU 19K5686) CardBus host adapter with PCI ID > 104c:8019 and the following lspci output: > > 09:00.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller This link layer controller is quite old. Alas I am not in possession of an errata document for this model. (There is TI literature slls312: TSB12LV22 errata; perhaps some of them have been fixed in TSB12LV23.) Could you install linux-firewire-utils and run lsfirewirephy to read out the chip ID of the physical layer device of the card? With a bit of luck, you may even be able to run lsfirewirephy while the camcorder is attached, and collect the camcorder's phy identifiers too. > This camcorder worked OK with the old drivers and a TI-based PCI card 10 > years ago. I confirmed that its FireWire port is still functional and > that this host adapter works with other video devices. > > Any suggestions? Have you had a chance to test this camcorder on a different machine recently? (Different host adapter, or/and different OS.) I am undecided whether your kernel log above is showing a problem with software/firmware interaction, or a problem at the physical layer. You get very brief intervals in which firewire-core can read something on the bus before the next reset occurs, so maybe a software/firmware problem is more likely. If you can, please collect a more verbose log by entering # echo 7 > /sys/module/firewire_ohci/parameters/debug or $ sudo dd > /sys/module/firewire_ohci/parameters/debug <<< 7 then plug in/ switch on the camcorder. After you got the kernel log from a few bus reset loops, you can switch verbose logging off again by writing 0 instead of 7. -- Stefan Richter -======----- =--- -==== http://arcgraph.de/sr/ |
From: Adam G. <ad...@po...> - 2016-07-10 02:57:38
|
Hi, I'm trying to capture video from a Sony DCR-TRV120. When I turn it on, I get a continuous loop of the following messages on the console: Jun 24 19:00:06 starship kernel: [ 845.491993] firewire_ohci 0000:09:00.0: node ID not valid, new bus reset in progress Jun 24 19:00:07 starship kernel: [ 846.632134] firewire_core 0000:09:00.0: rediscovered device fw0 Jun 24 19:00:07 starship kernel: [ 846.718717] firewire_core 0000:09:00.0: rediscovered device fw1 Jun 24 19:00:07 starship kernel: [ 846.718799] firewire_core 0000:09:00.0: phy config: new root=ffc1, gap_count=5 Jun 24 19:00:07 starship kernel: [ 846.718950] firewire_ohci 0000:09:00.0: node ID not valid, new bus reset in progress Jun 24 19:00:08 starship kernel: [ 847.860130] firewire_core 0000:09:00.0: rediscovered device fw0 Jun 24 19:00:08 starship kernel: [ 847.946744] firewire_core 0000:09:00.0: rediscovered device fw1 Jun 24 19:00:08 starship kernel: [ 847.946834] firewire_core 0000:09:00.0: phy config: new root=ffc1, gap_count=5 This is with a fresh Debian 8.5 install and the vendor kernel. uname output is: Linux starship 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 Linux I'm using an IBM 19K5680 (FRU 19K5686) CardBus host adapter with PCI ID 104c:8019 and the following lspci output: 09:00.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller This camcorder worked OK with the old drivers and a TI-based PCI card 10 years ago. I confirmed that its FireWire port is still functional and that this host adapter works with other video devices. Any suggestions? -- Adam |
From: John C. <joh...@gm...> - 2016-06-26 05:52:27
|
I am having an unresolved issue with the MIDI transport control section of the Behringer UFX series mixer. [UFX1204] This device is equipped with two interfaces. Firewire and USB. It is both an audio interface and a MIDI control surface. I am using the most recent kernel: --- Linux w530 4.6.2-hz1000-rt3 #3 SMP PREEMPT RT Thu Jun 23 11:41:06 CEST 2016 x86_64 GNU/Linux Accessing the device uses the following modules: --- snd_firewire_lib 32768 1 snd_bebob snd_rawmidi 32768 4 snd_firewire_lib,snd_bebob,snd_usbmidi_lib,snd_seq_midi snd_pcm 106496 9 snd_firewire_lib,snd_pcm_oss,snd_usb_audio,snd_bebob,snd_hda_codec,snd_hda_intel,snd_hda_core firewire_ohci 40960 0 firewire_core 65536 3 snd_firewire_lib,snd_bebob,firewire_ohci crc_itu_t 16384 1 firewire_core USB MIDI interface to-and-from the transport section of the device works flawlessly. >From the same application software Firewire MIDI communication to the device drops messages. I have read that MIDI section of the linux Firewire stack is not respecting the protocol rate limit. ref: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-April/075912.html --- 2.Data rate for MIDI substream With current implementation, the maximum data rate for MIDI substream in out-stream is one eighth of sampling rate. For example, at 48.0kHz, it's 6,000 bytes. This is excess over standard MIDI data rate, 3,125 bits per second. So a few devices can have buffer over flow when receiving much MIDI messages. For example, M-Audio Firewire 1814 transmits packets with discontinuity in this case. I guess that Fireworks based devices and some BeBoB based devices ignore MIDI messages in more than 8 data blocks of packets and this is vendor's effort for this issue. Drivers need a throttle for this issue but this is for future work. --- Conversely, the Firewire release notes say: https://ieee1394.wiki.kernel.org/index.php/Release_Notes/3.x#Linux_3.19 --- snd-firewire-lib . Limit MIDI transmission rate as per specification to prevent loss of messages. --- So I'm left to wonder what the actual status of the Firewire MIDI substream protocol is, as the behavior I see, dropped packets sent to the UFX1204, is consistent with data overruns. I am assuming that the message content is correct as the MIDI transport functions correctly when accessed via the USB interface. Should I expect this to work, or is this a known open issue? Thanks jCandlish . This inquiry was originally posted here: https://linuxmusicians.com/viewtopic.php?f=6&p=72314#p72314 |
From: Fab S. <fab...@gm...> - 2016-06-14 07:05:53
|
(sent again from another email because rejected from linux-scsi) Thanks for your detailed answer Le mardi 7 juin 2016 15:15:54, vous avez écrit : > One example would be that userland sends another INQUIRY request. Which > would be perfectly standards conforming but is highly dangerous for > PL-3507. > > The 36 bytes offset which you observed happens to be the same number of > bytes as the length of a typical INQUIRY response buffer. Coincidence? > > So, > - the SCSI layer and block layer of the Linux kerne could issue commands > which the PL-3507's firmware cannot handle, but this can be influenced > to some degree by specifying quirk flags to SCSI core. (I don't > remember right now how to do that precisely.) > - Or Linux userland could issue commands which crash the firmware. > > To investigate the latter possibility, you could boot into a minimal > single-user command line and try to use the disk from there. Consult your > distribution's documentation on how to get into single-user mode. If that > works, then there is some sort of device probing going on in your regular > userland which upsets the firmware. E.g. the mentioned double INQUIRY. For single-user I booted on recovery-mode in debian (having the "single" option on the kernel line). The problem is the same. However, based on you explanations I tried a few things and noticed this behaviour : * If I run "sg_readcap /deb/sdb" then, the offset doesn't exist anymore and when I run cfdisk /dev/sdb the partition table is correctly displayed. However, after closure of cfdisk, the offset is there again and cfdisk doesn't display the partition table anymore. * If I run "sg_readcap" followed by "sg_inq", sg_inq makes the offset appear again. * If I run "sdparm /dev/sdb", there isn't an offset anymore and cfdisk displays the partition table * If I run "sdparm -i /dev/sdb" the offset appears again So it seems "cfdisk", "sg_inq" and "sdparm -i" send a command that makes the offset appear again, while "sdparm" and "sg_readcap" 'fix' the offset issue. Output of "sdparm -i /dev/sdb" /dev/sdb: SAMSUNG SP0842N [simplified direct access device] malformed VPD response, VPD pages probably not supported Output of "sdparm -a /dev/sdb" is attached (and displays also a few warings) > > * relevant messages from dmesg > > [66693.391283] firewire_core 0000:02:00.0: phy config: new root=ffc1, > > gap_count=5 [66697.227221] firewire_core 0000:02:00.0: phy config: new > > root=ffc1, gap_count=5 [66697.666381] firewire_core 0000:02:00.0: created > > device fw1: GUID 0000190e0000026e, S400 [66697.844315] scsi host5: SBP-2 > > IEEE-1394 > > [66697.844445] firewire_sbp2 fw1.0: workarounds 0x20 (firmware_revision > > 0x012804, model_id 0x000001) [66698.044800] firewire_sbp2 fw1.0: logged > > in to LUN 0000 (0 retries) [66698.045542] scsi 5:0:0:0: Direct-Access-RBC > > SAMSUNG SP0842N PQ: 0 ANSI: 4 [66698.045892] sd 5:0:0:0: > > Attached scsi generic sg3 type 14 > > [66698.046476] sd 5:0:0:0: [sdc] 156301488 512-byte logical blocks: (80.0 > > GB/74.5 GiB) [66698.046591] sd 5:0:0:0: [sdc] Write Protect is off > > [66698.046596] sd 5:0:0:0: [sdc] Mode Sense: 11 00 00 00 > > [66698.046868] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: > > enabled, doesn't support DPO or FUA [66698.055440] sd 5:0:0:0: [sdc] > > Attached SCSI disk > > Are there no further messages from the SCSI drivers or block layer drivers? No, there are no further messages -- Fab |
From: Fab S. <fab...@ya...> - 2016-06-14 06:58:01
|
Thanks for your detailed answer Le mardi 7 juin 2016 15:15:54, vous avez écrit : > One example would be that userland sends another INQUIRY request. Which > would be perfectly standards conforming but is highly dangerous for > PL-3507. > > The 36 bytes offset which you observed happens to be the same number of > bytes as the length of a typical INQUIRY response buffer. Coincidence? > > So, > - the SCSI layer and block layer of the Linux kerne could issue commands > which the PL-3507's firmware cannot handle, but this can be influenced > to some degree by specifying quirk flags to SCSI core. (I don't > remember right now how to do that precisely.) > - Or Linux userland could issue commands which crash the firmware. > > To investigate the latter possibility, you could boot into a minimal > single-user command line and try to use the disk from there. Consult your > distribution's documentation on how to get into single-user mode. If that > works, then there is some sort of device probing going on in your regular > userland which upsets the firmware. E.g. the mentioned double INQUIRY. For single-user I booted on recovery-mode in debian (having the "single" option on the kernel line). The problem is the same. However, based on you explanations I tried a few things and noticed this behaviour : * If I run "sg_readcap /deb/sdb" then, the offset doesn't exist anymore and when I run cfdisk /dev/sdb the partition table is correctly displayed. However, after closure of cfdisk, the offset is there again and cfdisk doesn't display the partition table anymore. * If I run "sg_readcap" followed by "sg_inq", sg_inq makes the offset appear again. * If I run "sdparm /dev/sdb", there isn't an offset anymore and cfdisk displays the partition table * If I run "sdparm -i /dev/sdb" the offset appears again So it seems "cfdisk", "sg_inq" and "sdparm -i" send a command that makes the offset appear again, while "sdparm" and "sg_readcap" 'fix' the offset issue. Output of "sdparm -i /dev/sdb" /dev/sdb: SAMSUNG SP0842N [simplified direct access device] malformed VPD response, VPD pages probably not supported Output of "sdparm -a /dev/sdb" is attached (and displays also a few warings) > > * relevant messages from dmesg > > [66693.391283] firewire_core 0000:02:00.0: phy config: new root=ffc1, > > gap_count=5 [66697.227221] firewire_core 0000:02:00.0: phy config: new > > root=ffc1, gap_count=5 [66697.666381] firewire_core 0000:02:00.0: created > > device fw1: GUID 0000190e0000026e, S400 [66697.844315] scsi host5: SBP-2 > > IEEE-1394 > > [66697.844445] firewire_sbp2 fw1.0: workarounds 0x20 (firmware_revision > > 0x012804, model_id 0x000001) [66698.044800] firewire_sbp2 fw1.0: logged > > in to LUN 0000 (0 retries) [66698.045542] scsi 5:0:0:0: Direct-Access-RBC > > SAMSUNG SP0842N PQ: 0 ANSI: 4 [66698.045892] sd 5:0:0:0: > > Attached scsi generic sg3 type 14 > > [66698.046476] sd 5:0:0:0: [sdc] 156301488 512-byte logical blocks: (80.0 > > GB/74.5 GiB) [66698.046591] sd 5:0:0:0: [sdc] Write Protect is off > > [66698.046596] sd 5:0:0:0: [sdc] Mode Sense: 11 00 00 00 > > [66698.046868] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: > > enabled, doesn't support DPO or FUA [66698.055440] sd 5:0:0:0: [sdc] > > Attached SCSI disk > > Are there no further messages from the SCSI drivers or block layer drivers? No, there are no further messages -- Fab |
From: Stefan R. <st...@s5...> - 2016-06-07 13:16:03
|
Adding Cc: lsml, quoting your message in full. On Jun 02 Fab Stz wrote at linux1394-user: > Hello > > I have a external hard drive box (brand SQP : www.sqp.fr, more details > below) with USB & Firewire support. The chipset is a PL-3507. > > On MaxOS X or windows (eg win10), if I connect through USB or FW, my > partitions are displayed and the disk is well detected. In Linux (kernel > 4.5.3) with USB, disk and partitions are well detected. However when > connected through firewire, the disk is well detected but not the > partitions. > > By investigating the issue I came to that thread > [ https://sourceforge.net/p/linux1394/mailman/message/13218958/ ] which > I read carefuly. I also have an offset when running dd on the disk. > There are 36 additional bytes (value : 0x00) at the begining of the disk > when connected through FW compared to USB. That may explain the fact > that the partitions are not found. BTW, it is a GUID Partition Table in > my case. > > I checked the firmware, it is dated 2004/Oct/06. According to the > release notes of the firmware, there was a fix in firmware 2004/Mar/24 > labeled " Fixed cannot mount HDD in Linux RedHat. Must use kernel > v2.4.20 and above. [1394] ". So I supposed upgrading wouldn't bring > anything. Nevertheless, I tried upgrading the firmware to a more recent > one [2004/Nov/09 or even 2006/Apr/20], but upgrade was rejected. The > above thread mentioned that some boards have a zero resistor preventing > upgrade. I searched for the zero resistance R72 > (http://club.cdfreaks.com/showthread.php?p=957178), but on my board > there isn't any. So I don't see how to upgrade the firmware. > > My questions are : > - could it be a bug in linux driver ? > - is it that my device is not well detected ? Or is there any workaround > in the kernel for buggy devices which doesn't match my particular > device ? It's vendor/device id are when connected as USB idVendor=0025, > idProduct=3507 (usualy for prolific it is idVendor=067b, idProduct=3507) > - do you have any other clue to make it work, or upgrade the firmware, > or determine which zero resistor has to be removed ? > - is there some way to tell linux to start reading the disk with an > offset of 36 bytes or ignore these 36 bytes? > > You can find below all technical details. > > Thank you First a few theoretical thoughts on why the device works under Windows and OS X but not under Linux: The first SCSI request which the Linux kernel issues contains the INQUIRY command. You are seeing results from INQUIRY in the dmesg portion below. There is for example a quirk parameter which control how the kernel reads the INQUIRY response, but it seems to me that this is not relevant here. (BLIST_INQUIRY_36 from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/scsi/scsi_devinfo.h) Next you are also seeing results from a command which the kernel sent subsequently, MODE SENSE. MODE SENSE can request various so-called mode pages. Most of them are optional, and some buggy firmwares react badly when asked for a mode page that they don't know about. There are some quirk flags which relate to that sort of device bugs (BLIST_MS_SKIP_PAGE_08, BLIST_MS_SKIP_PAGE_3F, BLIST_USE_10_BYTE_MS, BLIST_MS_192_BYTES_FOR_3F) but I doubt that you need any of those. Next, the sd driver should issue READ_CAPACITY to determine medium size (or maybe this happened already before MODE SENSE, I would have to look that up in drivers/scsi/sd.c). Then the block layer(?) should issue a READ command of some sort in order to fetch the partition table. If the Linux kernel performs anything of the above in only the tiniest different way than Windows does it, a buggy firmware like the typical firmwares of the FireWire portion of PL-3507, the firmware will start sending malformed results or flat out freeze. AFAIR this series of commands which the kernel issues, the subsequent commands come from userland. And again, if Linux userland sends commands which Windows kernel or Windows userland do not send (or do not send with such and such parameters or in this or that particular order of sequence), PL-3507 firmwares will take offense and go belly-up. One example would be that userland sends another INQUIRY request. Which would be perfectly standards conforming but is highly dangerous for PL-3507. The 36 bytes offset which you observed happens to be the same number of bytes as the length of a typical INQUIRY response buffer. Coincidence? So, - the SCSI layer and block layer of the Linux kerne could issue commands which the PL-3507's firmware cannot handle, but this can be influenced to some degree by specifying quirk flags to SCSI core. (I don't remember right now how to do that precisely.) - Or Linux userland could issue commands which crash the firmware. To investigate the latter possibility, you could boot into a minimal single-user command line and try to use the disk from there. Consult your distribution's documentation on how to get into single-user mode. If that works, then there is some sort of device probing going on in your regular userland which upsets the firmware. E.g. the mentioned double INQUIRY. Back to your questions, in particular the one about handling the 36 byte offset: I do not know of a readily usable quirk flag for this. Furthermore, I think it would be hard to implement. The kernel would need to detect the moment from which on the devise starts to add that offset to its responses. Perhaps this moment can be easily and reliably detected, or perhaps not. > > > * kernel version : Linux debian 4.5.0-0.bpo.2-amd64 #1 SMP Debian 4.5.3-2~bpo8+1 (2016-05-13) x86_64 GNU/Linux > > * which kernel drivers you are using (lsmod | grep -e 1394 -e firewire) > firewire_sbp2 24576 0 > scsi_mod 229376 7 sg,uas,usb_storage,libata,sd_mod,sr_mod,firewire_sbp2 > firewire_ohci 40960 0 > firewire_core 65536 2 firewire_ohci,firewire_sbp2 > crc_itu_t 16384 1 firewire_core > > > * relevant messages from dmesg > [66693.391283] firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 > [66697.227221] firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 > [66697.666381] firewire_core 0000:02:00.0: created device fw1: GUID 0000190e0000026e, S400 > [66697.844315] scsi host5: SBP-2 IEEE-1394 > [66697.844445] firewire_sbp2 fw1.0: workarounds 0x20 (firmware_revision 0x012804, model_id 0x000001) > [66698.044800] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > [66698.045542] scsi 5:0:0:0: Direct-Access-RBC SAMSUNG SP0842N PQ: 0 ANSI: 4 > [66698.045892] sd 5:0:0:0: Attached scsi generic sg3 type 14 > [66698.046476] sd 5:0:0:0: [sdc] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) > [66698.046591] sd 5:0:0:0: [sdc] Write Protect is off > [66698.046596] sd 5:0:0:0: [sdc] Mode Sense: 11 00 00 00 > [66698.046868] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > [66698.055440] sd 5:0:0:0: [sdc] Attached SCSI disk Are there no further messages from the SCSI drivers or block layer drivers? > * make and model of FireWire peripheral : SQP BOIT-XPCOMPO > > * adapter card model and/or OHCI chipset > 02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) (prog-if 10 [OHCI]) > Subsystem: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller > Flags: bus master, stepping, medium devsel, latency 64, IRQ 16 > Memory at fdcff000 (32-bit, non-prefetchable) [size=2K] > I/O ports at ef00 [size=128] > Capabilities: <access denied> > Kernel driver in use: firewire_ohci > > * output of lspci > 00:00.0 Host bridge: Intel Corporation 82946GZ/PL/GL Memory Controller Hub (rev 02) > 00:01.0 PCI bridge: Intel Corporation 82946GZ/PL/GL PCI Express Root Port (rev 02) > 00:02.0 VGA compatible controller: Intel Corporation 82946GZ/GL Integrated Graphics Controller (rev 02) > 00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01) > 00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01) > 00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01) > 00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01) > 00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01) > 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) > 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) > 00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01) > 00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01) > 02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) > 02:08.0 Ethernet controller: Intel Corporation NM10/ICH7 Family LAN Controller (rev 01) Of these devices, the VIA controller is of course involved (and this model, the VIA VT6306, is a very common one, and there are no known unhandled issues related to VT6306 and SBP-2 usage), and one of the PCI bridges. I don't know whether there are potential issues with these bridges, but to me your problem looks like it happens on a lot higher level (i.e. transport protocol and how the buggy PL-3507 firmware handles it). > > * versions of libraries (libraw1394...), application or utility (if applicable) > libraw1394 : v2.1.0 > libraw1394 is not involved in accesses to SBP-2/SBP-3 devices. The software stack basically looks like this: firewire-ohci firewire-core firewire-sbp2 SCSI core sd block layer userland -- Stefan Richter -======----- -==- --=== http://arcgraph.de/sr/ |
From: Fab S. <fab...@ya...> - 2016-06-02 12:13:10
|
Hello I have a external hard drive box (brand SQP : www.sqp.fr, more details below) with USB & Firewire support. The chipset is a PL-3507. On MaxOS X or windows (eg win10), if I connect through USB or FW, my partitions are displayed and the disk is well detected. In Linux (kernel 4.5.3) with USB, disk and partitions are well detected. However when connected through firewire, the disk is well detected but not the partitions. By investigating the issue I came to that thread [ https://sourceforge.net/p/linux1394/mailman/message/13218958/ ] which I read carefuly. I also have an offset when running dd on the disk. There are 36 additional bytes (value : 0x00) at the begining of the disk when connected through FW compared to USB. That may explain the fact that the partitions are not found. BTW, it is a GUID Partition Table in my case. I checked the firmware, it is dated 2004/Oct/06. According to the release notes of the firmware, there was a fix in firmware 2004/Mar/24 labeled " Fixed cannot mount HDD in Linux RedHat. Must use kernel v2.4.20 and above. [1394] ". So I supposed upgrading wouldn't bring anything. Nevertheless, I tried upgrading the firmware to a more recent one [2004/Nov/09 or even 2006/Apr/20], but upgrade was rejected. The above thread mentioned that some boards have a zero resistor preventing upgrade. I searched for the zero resistance R72 (http://club.cdfreaks.com/showthread.php?p=957178), but on my board there isn't any. So I don't see how to upgrade the firmware. My questions are : - could it be a bug in linux driver ? - is it that my device is not well detected ? Or is there any workaround in the kernel for buggy devices which doesn't match my particular device ? It's vendor/device id are when connected as USB idVendor=0025, idProduct=3507 (usualy for prolific it is idVendor=067b, idProduct=3507) - do you have any other clue to make it work, or upgrade the firmware, or determine which zero resistor has to be removed ? - is there some way to tell linux to start reading the disk with an offset of 36 bytes or ignore these 36 bytes? You can find below all technical details. Thank you * kernel version : Linux debian 4.5.0-0.bpo.2-amd64 #1 SMP Debian 4.5.3-2~bpo8+1 (2016-05-13) x86_64 GNU/Linux * which kernel drivers you are using (lsmod | grep -e 1394 -e firewire) firewire_sbp2 24576 0 scsi_mod 229376 7 sg,uas,usb_storage,libata,sd_mod,sr_mod,firewire_sbp2 firewire_ohci 40960 0 firewire_core 65536 2 firewire_ohci,firewire_sbp2 crc_itu_t 16384 1 firewire_core * relevant messages from dmesg [66693.391283] firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 [66697.227221] firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 [66697.666381] firewire_core 0000:02:00.0: created device fw1: GUID 0000190e0000026e, S400 [66697.844315] scsi host5: SBP-2 IEEE-1394 [66697.844445] firewire_sbp2 fw1.0: workarounds 0x20 (firmware_revision 0x012804, model_id 0x000001) [66698.044800] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) [66698.045542] scsi 5:0:0:0: Direct-Access-RBC SAMSUNG SP0842N PQ: 0 ANSI: 4 [66698.045892] sd 5:0:0:0: Attached scsi generic sg3 type 14 [66698.046476] sd 5:0:0:0: [sdc] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [66698.046591] sd 5:0:0:0: [sdc] Write Protect is off [66698.046596] sd 5:0:0:0: [sdc] Mode Sense: 11 00 00 00 [66698.046868] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [66698.055440] sd 5:0:0:0: [sdc] Attached SCSI disk * make and model of FireWire peripheral : SQP BOIT-XPCOMPO * adapter card model and/or OHCI chipset 02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller Flags: bus master, stepping, medium devsel, latency 64, IRQ 16 Memory at fdcff000 (32-bit, non-prefetchable) [size=2K] I/O ports at ef00 [size=128] Capabilities: <access denied> Kernel driver in use: firewire_ohci * output of lspci 00:00.0 Host bridge: Intel Corporation 82946GZ/PL/GL Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 82946GZ/PL/GL PCI Express Root Port (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82946GZ/GL Integrated Graphics Controller (rev 02) 00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01) 00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01) 00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01) 00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01) 00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01) 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01) 00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01) 02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) 02:08.0 Ethernet controller: Intel Corporation NM10/ICH7 Family LAN Controller (rev 01) * versions of libraries (libraw1394...), application or utility (if applicable) libraw1394 : v2.1.0 |
From: Stefan R. <st...@s5...> - 2016-04-03 15:14:52
|
Hi all, a new maintenance release of libraw1394, the legacy programming interface to low-level IEEE 1394 I/O on Linux, has been pushed to kernel.org now. Building with some alternative C libraries and with some older build environments has been fixed. If you did not encounter build failures with libraw1394 v2.1.1, you do not need to upgrade to v2.1.2. ------------------------------------------------------------------------ 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.2.tar.gz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.2.tar.xz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.2.tar.sign ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.2.tar.gz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.2.tar.xz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.2.tar.sign To verify a downloaded tarball, first uncompress from *.tar.gz or *.tar.xz to *.tar, then run "gpg --verify libraw1394-2.1.2.tar.sign". ------------------------------------------------------------------------ Shortlog and diffstat from v2.1.1 to v2.1.2: Stefan Richter (1): configure.ac, Changelog, NEWS: update to version 2.1.2 Thomas Petazzoni (2): Use <stdint.h> types instead of non-standard types testlibraw: build the CLOCK_MONOTONIC_RAW test conditionally ChangeLog | 12 ++++++++++++ NEWS | 4 ++++ configure.ac | 2 +- src/fw-iso.c | 2 +- src/fw.c | 6 +++--- src/fw.h | 3 ++- tools/testlibraw.c | 2 ++ 7 files changed, 25 insertions(+), 6 deletions(-) ------------------------------------------------------------------------ The commands to build from tarball are typically: $ tar xfvJ libraw1394-2.1.2.tar.xz $ cd libraw1394-2.1.2 $ ./configure $ make $ sudo make install Commands to clone and build from the git repo: $ git clone git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git $ cd libraw1394/ $ autoreconf -fi $ ./configure $ make $ sudo make install Note, this installs by default to /usr/local/{lib,include,bin}. If you need to install it elsewhere, use the --prefix option to ./configure. -- Stefan Richter -======----- -=-- ---== http://arcgraph.de/sr/ |
From: Justin S. <jus...@gm...> - 2015-11-03 00:53:56
|
Hi Stefan, You're right about both: the WD has two 800 ports and the iMac has one 800 and one 400. I've tried using both 800 ports on the WD, and I tried buying a new 9 pin-9 pin cable to make sure the cable wasn't the issue. You're also right that I'm unable to boot into any other OS. I rant the tests you mentioned. The key results are summarized below summarized: Nov 2 18:42:42 justinsnow-iMac wpa_supplicant[1189]: message repeated 8 times: [ wlan0: CTRL-EVENT-SCAN-STARTED ] Nov 2 18:42:51 justinsnow-iMac wpa_supplicant[1189]: wlan0: WPA: Group rekeying completed with 04:1e:64:99:5b:7f [GTK=CCMP] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772064] firewire_ohci 0000:03:00.0: failed to read phy reg 4 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772079] CPU: 0 PID: 3407 Comm: modprobe Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772084] Hardware name: Apple Inc. iMac7,1/Mac-F4238CC8, BIOS IM71.88Z.007A.B03.0803051705 03/05/08 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772090] ffff8801378ba000 ffff8800a52b7cb8 ffffffff8176534f 0000000000000067 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772101] ffff8800a52b7ce0 ffffffffc02f114b 0000000000000004 ffff8801378ba000 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772110] 00000000000000c0 ffff8800a52b7d10 ffffffffc02f1180 ffff8801378ba628 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772119] Call Trace: Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772136] [<ffffffff8176534f>] dump_stack+0x45/0x56 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772148] [<ffffffffc02f114b>] read_phy_reg+0x9b/0xb0 [firewire_ohci] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772158] [<ffffffffc02f1180>] update_phy_reg+0x20/0x50 [firewire_ohci] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772168] [<ffffffffc02f11ee>] ohci_update_phy_reg+0x3e/0x60 [firewire_ohci] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772182] [<ffffffffc0906490>] fw_core_remove_card+0xa0/0x170 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772210] [<ffffffffc0906000>] ? 0xffffffffc0905fff Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772222] [<ffffffffc0906010>] ? dummy_read_phy_reg+0x10/0x10 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772235] [<ffffffffc0906020>] ? dummy_update_phy_reg+0x10/0x10 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772247] [<ffffffffc0906040>] ? dummy_send_request+0x20/0x20 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772258] [<ffffffffc0906060>] ? dummy_send_response+0x20/0x20 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772269] [<ffffffffc0906070>] ? dummy_cancel_packet+0x10/0x10 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772281] [<ffffffffc0906080>] ? dummy_enable_phys_dma+0x10/0x10 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772293] [<ffffffffc09060a0>] ? dummy_allocate_iso_context+0x20/0x20 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772304] [<ffffffffc09060b0>] ? dummy_start_iso+0x10/0x10 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772315] [<ffffffffc09060c0>] ? dummy_set_iso_channels+0x10/0x10 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772326] [<ffffffffc09060d0>] ? dummy_queue_iso+0x10/0x10 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772337] [<ffffffffc09060e0>] ? dummy_flush_queue_iso+0x10/0x10 [firewire_core] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772346] [<ffffffffc02f3786>] pci_remove+0x56/0x210 [firewire_ohci] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772356] [<ffffffff813d063b>] pci_device_remove+0x3b/0xb0 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772367] [<ffffffff814ba06f>] __device_release_driver+0x7f/0xf0 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772375] [<ffffffff814baa38>] driver_detach+0xb8/0xc0 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772383] [<ffffffff814b9d25>] bus_remove_driver+0x55/0xd0 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772391] [<ffffffff814bb20c>] driver_unregister+0x2c/0x50 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772399] [<ffffffff813cf199>] pci_unregister_driver+0x29/0x90 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772409] [<ffffffffc02f5e66>] fw_ohci_cleanup+0x10/0x1aa [firewire_ohci] Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772420] [<ffffffff810eb962>] SyS_delete_module+0x162/0x200 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772430] [<ffffffff81013057>] ? do_notify_resume+0x97/0xb0 Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772440] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f Nov 2 18:43:33 justinsnow-iMac kernel: [ 865.772675] firewire_ohci 0000:03:00.0: removed fw-ohci device Nov 2 18:43:47 justinsnow-iMac kernel: [ 879.996092] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x10, physUB Nov 2 18:43:47 justinsnow-iMac kernel: [ 879.996495] firewire_ohci 0000:03:00.0: AR evt_bus_reset, generation 4 Nov 2 18:43:47 justinsnow-iMac kernel: [ 879.998032] firewire_ohci 0000:03:00.0: 1 selfIDs, generation 4, local node ID ffc0 Nov 2 18:43:47 justinsnow-iMac kernel: [ 879.998040] firewire_ohci 0000:03:00.0: selfID 0: 807fc856, phy 0 [---] beta gc=63 +0W Lci Nov 2 18:43:48 justinsnow-iMac kernel: [ 880.496312] firewire_core 0000:03:00.0: created device fw0: GUID 001f5bfffe0919bc, S800 Nov 2 18:43:55 justinsnow-iMac justinsnow: connecting disk Nov 2 18:44:40 justinsnow-iMac justinsnow: disconnected, connecting once more Nov 2 18:44:42 justinsnow-iMac wpa_supplicant[1189]: wlan0: CTRL-EVENT-SCAN-STARTED Nov 2 18:45:25 justinsnow-iMac justinsnow: switched off disk, connecting macbook Nov 2 18:49:07 justinsnow-iMac dbus[713]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper) Nov 2 18:49:07 justinsnow-iMac kernel: [ 1199.347309] systemd-hostnamed[3510]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname! Nov 2 18:49:07 justinsnow-iMac dbus[713]: [system] Successfully activated service 'org.freedesktop.hostname1' Nov 2 18:49:39 justinsnow-iMac kernel: [ 1231.943454] perf interrupt took too long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 Nov 2 18:48:42 justinsnow-iMac wpa_supplicant[1189]: message repeated 2 times: [ wlan0: CTRL-EVENT-SCAN-STARTED ] Nov 2 18:49:55 justinsnow-iMac wpa_supplicant[1189]: wlan0: WPA: Group rekeying completed with 04:1e:64:99:5b:7f [GTK=CCMP] Nov 2 18:50:42 justinsnow-iMac wpa_supplicant[1189]: wlan0: CTRL-EVENT-SCAN-STARTED Not totally sure what those results mean. Looks like the port might be dead, judging by the fact that not much happened even when I attached my MacBook. But maybe "Nov 2 18:49:07 justinsnow-iMac dbus[713]: [system] Successfully activated service 'org.freedesktop.hostname1'" means that it did connect? I'm not sure. I'd definitely appreciate additional insight if you have any. I've been thinking of getting a NAS that I'd hardwire via Ethernet to the iMac anyway, so maybe this is just the catalyst I need. Thanks for your help! Justin On Sun, Nov 1, 2015 at 6:44 AM, Stefan Richter <st...@s5...> wrote: > On Oct 22 Justin Snow wrote: > > I forgot to mention two important things. 1. The drive connects perfectly > > when using USB. 2. The drive connects perfectly to my MacBook via > FireWire > > (and USB). > [...] > > > Computer: iMac MA876LL / iMac7,1 > > This one has a FireWire 400 port (6-pin) and FireWire 800 port (9-pin), > whereas the WD My Book has got two FireWire 800 ports, right? > > Do you only have a 9-pin to 9-pin cable, or also a 9-pin to 6-pin cable > that > you could test? > > I take it that you cannot dualboot into OS X on the iMac, do you? > Otherwise you certainly would have tested whether or not OS X discovers the > drive. > > > > Processor: Intel Core 2 Duo, T7300 @ 2.00 GHz x 2 > > > OS: Linux Mint 17.2 Cinnamon 64-bit > > > Kernel: 3.13.0-38-generic > [...] > > > Make: WD (My Book Studio) > [...] > > > $ dmesg | grep -e 1394 -e firewire > > > [ 0.116545] ACPI: SSDT 0xFFFF8801394A4840 000085 (v01 APPLE > Cpu1Cst 00003000 INTL 20061109) > > > [ 2.244113] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as > card 0, 8 IR + 8 IT contexts, quirks 0x10, physUB > > > [ 2.744192] firewire_core 0000:03:00.0: created device fw0: GUID > 001f5bfffe0919bc, S800 > > > [ 367.700992] firewire_ohci 0000:03:00.0: removed fw-ohci device > > > [ 456.312119] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as > card 0, 8 IR + 8 IT contexts, quirks 0x10, physUB > > > [ 456.812335] firewire_core 0000:03:00.0: created device fw0: GUID > 001f5bfffe0919bc, S800 > > > > > > $ lspci > [...] > > > 03:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe > 1394b Controller (rev 06) > [...] > > There were problem reports about iMacs with FW643 rev 06 in the past, but > these issues have supposedly been fixed by adding the "quirks 0x10" bit in > firewire-ohci for these controllers. > > Please run the following commands: > $ sudo modprobe -r firewire-ohci > $ sudo modprobe firewire-ohci debug=3 > $ logger "connecting disk" > (now switch on and connect the disk) > (wait a minute) > (disconnect and switch off the disk) > $ logger "disconnected, connecting once more" > (connect the disk, then switch it on) > (wait a minute) > (switch off the disk, disconnect it) > $ logger "switched off disk, connecting macbook" > (connect the MacBook to the iMac via FireWire while the MacBook is > running Linux or OS X) > (wait a minute) > (disconnect the MacBook) > $ sudo cat /var/log/messages > messages_copy.txt > > This assumes that Mint 17.2 is configured such that kernel messages are > logged into /var/log/messages. If it isn't, then just inspect the output > of "dmesg" instead. "dmesg" does not contain the user messages from the > "logger" command though. > > While you have the MacBook attached to the iMac, also look out for kernel > messages on the MacBook where it discovers the iMac as a FireWire node > (or shows it in OS X's system profiler). > > In the worst case you don't get any messages at all, which would mean that > the iMac's FireWire port is dead. > -- > Stefan Richter > -=====-===== =-== ----= > http://arcgraph.de/sr/ > -- Justin Snow Anti-Gravity Bunny http://antigravitybunny.com http://twitter.com/justinsnow |
From: Stefan R. <st...@s5...> - 2015-11-01 11:44:52
|
On Oct 22 Justin Snow wrote: > I forgot to mention two important things. 1. The drive connects perfectly > when using USB. 2. The drive connects perfectly to my MacBook via FireWire > (and USB). [...] > > Computer: iMac MA876LL / iMac7,1 This one has a FireWire 400 port (6-pin) and FireWire 800 port (9-pin), whereas the WD My Book has got two FireWire 800 ports, right? Do you only have a 9-pin to 9-pin cable, or also a 9-pin to 6-pin cable that you could test? I take it that you cannot dualboot into OS X on the iMac, do you? Otherwise you certainly would have tested whether or not OS X discovers the drive. > > Processor: Intel Core 2 Duo, T7300 @ 2.00 GHz x 2 > > OS: Linux Mint 17.2 Cinnamon 64-bit > > Kernel: 3.13.0-38-generic [...] > > Make: WD (My Book Studio) [...] > > $ dmesg | grep -e 1394 -e firewire > > [ 0.116545] ACPI: SSDT 0xFFFF8801394A4840 000085 (v01 APPLE Cpu1Cst 00003000 INTL 20061109) > > [ 2.244113] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x10, physUB > > [ 2.744192] firewire_core 0000:03:00.0: created device fw0: GUID 001f5bfffe0919bc, S800 > > [ 367.700992] firewire_ohci 0000:03:00.0: removed fw-ohci device > > [ 456.312119] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x10, physUB > > [ 456.812335] firewire_core 0000:03:00.0: created device fw0: GUID 001f5bfffe0919bc, S800 > > > > $ lspci [...] > > 03:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 06) [...] There were problem reports about iMacs with FW643 rev 06 in the past, but these issues have supposedly been fixed by adding the "quirks 0x10" bit in firewire-ohci for these controllers. Please run the following commands: $ sudo modprobe -r firewire-ohci $ sudo modprobe firewire-ohci debug=3 $ logger "connecting disk" (now switch on and connect the disk) (wait a minute) (disconnect and switch off the disk) $ logger "disconnected, connecting once more" (connect the disk, then switch it on) (wait a minute) (switch off the disk, disconnect it) $ logger "switched off disk, connecting macbook" (connect the MacBook to the iMac via FireWire while the MacBook is running Linux or OS X) (wait a minute) (disconnect the MacBook) $ sudo cat /var/log/messages > messages_copy.txt This assumes that Mint 17.2 is configured such that kernel messages are logged into /var/log/messages. If it isn't, then just inspect the output of "dmesg" instead. "dmesg" does not contain the user messages from the "logger" command though. While you have the MacBook attached to the iMac, also look out for kernel messages on the MacBook where it discovers the iMac as a FireWire node (or shows it in OS X's system profiler). In the worst case you don't get any messages at all, which would mean that the iMac's FireWire port is dead. -- Stefan Richter -=====-===== =-== ----= http://arcgraph.de/sr/ |
From: Justin S. <jus...@gm...> - 2015-10-23 01:10:16
|
I forgot to mention two important things. 1. The drive connects perfectly when using USB. 2. The drive connects perfectly to my MacBook via FireWire (and USB). > I'm completely new to Linux, so please bear with me. I feel like I've tried > pretty much everything to get my desktop to even recognize (let alone > mount) my WD hard drive. I've crawled every site, posted to the Ubuntu and > Linux Mint forums, followed the directions in the "My FireWire > hardisk/CD-ROM/DVD-Recorder is not recognized. Now what?" section of the > wiki... Now I turn to you for help. All the details requested are below. > Please let me know if you'd like any additional info from me. Thanks in > advance for any suggestions you might have. > Also, I'm kind of hoping it's some crazy weird problem that is > almost-but-not-quite unfixable instead of a stupidly simple thing that I've > overlooked, otherwise I'll just feel like an idiot. > Computer: iMac MA876LL / iMac7,1 > Processor: Intel Core 2 Duo, T7300 @ 2.00 GHz x 2 > OS: Linux Mint 17.2 Cinnamon 64-bit > Kernel: 3.13.0-38-generic > Library: libraw1394-11: amd64, i386 > FireWire unit info: > Make: WD (My Book Studio) > Model: 0x111D > Unit software version: 0x10483 > Unit spec ID: 0x609E > Firmware revision: 0x1049 > Product revision level: 1049 > Capacity: 3 TB > $ lsmod | grep -e 1394 -e firewire > firewire_sbp2 22680 0 > firewire_ohci 40551 0 > firewire_core 68769 2 firewire_ohci,firewire_sbp2 > crc_itu_t 12707 1 firewire_core > $ dmesg | grep -e 1394 -e firewire > [ 0.116545] ACPI: SSDT 0xFFFF8801394A4840 000085 (v01 APPLE Cpu1Cst > 00003000 INTL 20061109) > [ 2.244113] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card > 0, 8 IR + 8 IT contexts, quirks 0x10, physUB > [ 2.744192] firewire_core 0000:03:00.0: created device fw0: GUID > 001f5bfffe0919bc, S800 > [ 367.700992] firewire_ohci 0000:03:00.0: removed fw-ohci device > [ 456.312119] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card > 0, 8 IR + 8 IT contexts, quirks 0x10, physUB > [ 456.812335] firewire_core 0000:03:00.0: created device fw0: GUID > 001f5bfffe0919bc, S800 > $ lspci > 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory > Controller Hub (rev 03) > 00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express > Root Port (rev 03) > 00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI > Controller #4 (rev 03) > 00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI > Controller #5 (rev 03) > 00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI > Controller #2 (rev 03) > 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio > Controller (rev 03) > 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port > 1 (rev 03) > 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port > 4 (rev 03) > 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port > 5 (rev 03) > 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port > 6 (rev 03) > 00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI > Controller #1 (rev 03) > 00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI > Controller #2 (rev 03) > 00:1d.2 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI > Controller #3 (rev 03) > 00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI > Controller #1 (rev 03) > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3) > 00:1f.0 ISA bridge: Intel Corporation 82801HM (ICH8M) LPC Interface > Controller (rev 03) > 00:1f.1 IDE interface: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE > Controller (rev 03) > 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA > Controller [AHCI mode] (rev 03) > 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev > 03) > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > RV610/M74 [Mobility Radeon HD 2400 XT] > 03:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b > Controller (rev 06) > 04:00.0 Network controller: Broadcom Corporation BCM4321 802.11a/b/g/n (rev > 03) > 05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8058 PCI-E > Gigabit Ethernet Controller (rev 13) |
From: Justin S. <jus...@gm...> - 2015-10-22 22:22:11
|
I'm completely new to Linux, so please bear with me. I feel like I've tried pretty much everything to get my desktop to even recognize (let alone mount) my WD hard drive. I've crawled every site, posted to the Ubuntu and Linux Mint forums, followed the directions in the "My FireWire hardisk/CD-ROM/DVD-Recorder is not recognized. Now what?" section of the wiki... Now I turn to you for help. All the details requested are below. Please let me know if you'd like any additional info from me. Thanks in advance for any suggestions you might have. Also, I'm kind of hoping it's some crazy weird problem that is almost-but-not-quite unfixable instead of a stupidly simple thing that I've overlooked, otherwise I'll just feel like an idiot. Computer: iMac MA876LL / iMac7,1 Processor: Intel Core 2 Duo, T7300 @ 2.00 GHz x 2 OS: Linux Mint 17.2 Cinnamon 64-bit Kernel: 3.13.0-38-generic Library: libraw1394-11: amd64, i386 FireWire unit info: Make: WD (My Book Studio) Model: 0x111D Unit software version: 0x10483 Unit spec ID: 0x609E Firmware revision: 0x1049 Product revision level: 1049 Capacity: 3 TB $ lsmod | grep -e 1394 -e firewire firewire_sbp2 22680 0 firewire_ohci 40551 0 firewire_core 68769 2 firewire_ohci,firewire_sbp2 crc_itu_t 12707 1 firewire_core $ dmesg | grep -e 1394 -e firewire [ 0.116545] ACPI: SSDT 0xFFFF8801394A4840 000085 (v01 APPLE Cpu1Cst 00003000 INTL 20061109) [ 2.244113] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x10, physUB [ 2.744192] firewire_core 0000:03:00.0: created device fw0: GUID 001f5bfffe0919bc, S800 [ 367.700992] firewire_ohci 0000:03:00.0: removed fw-ohci device [ 456.312119] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x10, physUB [ 456.812335] firewire_core 0000:03:00.0: created device fw0: GUID 001f5bfffe0919bc, S800 $ lspci 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 03) 00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 03) 00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3) 00:1f.0 ISA bridge: Intel Corporation 82801HM (ICH8M) LPC Interface Controller (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 03) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV610/M74 [Mobility Radeon HD 2400 XT] 03:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 06) 04:00.0 Network controller: Broadcom Corporation BCM4321 802.11a/b/g/n (rev 03) 05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8058 PCI-E Gigabit Ethernet Controller (rev 13) |
From: Stefan R. <st...@s5...> - 2015-10-19 07:01:35
|
On Oct 12 David wrote: > On 12/10/15 17:35, Stefan Richter wrote: > > What do you get in the kernel log if you run > > sudo modprobe -r firewire-ohci > > sleep 1 > > sudo modprobe firewire-ohci debug=2 > > while the camcorder is plugged in and switched on? > > > > And after this, what do you get if you leave firewire-ohci this way and > > unplug and replug the camcorder? > > > > (Please carefully note which kernel messages follow from what action.) > plugging and unplugging the device resulted in nothing in the log :( > > The camcorder is definitely getting a signal of some sort because it > displays "HDV/DV IN" on it's screen. This stays on during reboot, so I > guess it's just some power thing. > > The camera is definitely working OK because (I hate to say it) it > connects to an Apple OK > > david@david:/var/log$ tail -f -n0 kern.log > Oct 12 23:02:48 david kernel: [ 675.823166] firewire_ohci 0000:08:06.0: PCI INT A disabled > Oct 12 23:02:48 david kernel: [ 675.823171] firewire_ohci: Removed fw-ohci device. > Oct 12 23:02:48 david kernel: [ 675.830928] firewire_ohci 0000:08:01.0: PCI INT A disabled > Oct 12 23:02:48 david kernel: [ 675.830933] firewire_ohci: Removed fw-ohci device. This is from "modprobe -r", and it shows shutdown messages from two OHCI link layer controllers. As you mentioned in today's post, you actually have two controllers. > Oct 12 23:03:03 david kernel: [ 690.683053] firewire_ohci 0000:08:01.0: Refused to change power state, currently in D3 > Oct 12 23:03:03 david kernel: [ 690.683067] firewire_ohci 0000:08:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > Oct 12 23:03:03 david kernel: [ 690.683126] firewire_ohci: Failed to reset ohci card. > Oct 12 23:03:03 david kernel: [ 690.683144] firewire_ohci 0000:08:01.0: PCI INT A disabled > Oct 12 23:03:03 david kernel: [ 690.683153] firewire_ohci: probe of 0000:08:01.0 failed with error -16 One of the last steps to initialize the first controller failed. It is not clear why that happened. > Oct 12 23:03:03 david kernel: [ 690.683171] firewire_ohci 0000:08:06.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > Oct 12 23:03:03 david kernel: [ 690.738942] firewire_ohci: Added fw-ohci device 0000:08:06.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 > Oct 12 23:03:03 david kernel: [ 690.739165] firewire_ohci: 1 selfIDs, generation 1, local node ID ffc0 > Oct 12 23:03:03 david kernel: [ 690.739172] firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci > Oct 12 23:03:04 david kernel: [ 691.238374] firewire_core: created device fw0: GUID 00cc13240000241d, S400 The second controller is initialized seemingly fine. From your lspci listing: > 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a5) This bridge implements a PCI bus, on which the following devices are located (if I read the listing correctly): > 08:06.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] > 08:07.0 IDE interface [0101]: Integrated Technology Express, Inc. IT8213 IDE Controller [1283:8213] The device 08:01.0 is notably absent from the lspci listing. Maybe the contact is loose, as Carl suggested among else. I also note that the "dmesg -T | grep firewire" results which you posted in your initial message were all from device 08:06.0, and none were from 08:01.0. -- Stefan Richter -=====-===== =-=- =--== http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2015-10-19 06:41:23
|
On Oct 18 Carl Karsten wrote: > On Sun, Oct 18, 2015 at 7:14 PM, David <da...@ke...> wrote: > > Hi > > > > I've discovered the problem. The motherboard has an on-board firewire of > > which I was unaware. If I plug into the motherboard everything works as > > advertised. It seems that the PCI board is being ignored. Since I only > > have one firewire device I'm not sure what would happen if I plug a > > second device into the card. Would it get recognised? > > If I understand your question, No. > > it sounds like a faulty card, or it isn't seated, or something of bad hardware. Or a bad PCIe-to-PCI bridge. Though the bad controller card and the good onboard controller apparently sit both behind the same bridge, which would be 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a5) according to the posting on October 12, so the bridge works at least for the onboard controller. > pull it out, run lspci >lspci.1.txt > add it back, lspci >lspci.2.txt > > diff lspci.1.txt lspci.2.txt > > If you don't see a new entry... um... you don't have a card ;) > > if you do see a 2nd firewire card, you should see > /dev/fw0 > /dev/fw1 > > and when you plug in your dv camera to either card: > /dev/fw2 > > > > > > I can't find any way to turn off the on-board firewire to try this. You don't need to turn off one FireWire controller in order to use another. Arbitrary many cards in the same system are supported. -- Stefan Richter -=====-===== =-=- =--== http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2015-10-19 04:28:12
|
On Sun, Oct 18, 2015 at 7:14 PM, David <da...@ke...> wrote: > Hi > > I've discovered the problem. The motherboard has an on-board firewire of > which I was unaware. If I plug into the motherboard everything works as > advertised. It seems that the PCI board is being ignored. Since I only > have one firewire device I'm not sure what would happen if I plug a > second device into the card. Would it get recognised? If I understand your question, No. it sounds like a faulty card, or it isn't seated, or something of bad hardware. pull it out, run lspci >lspci.1.txt add it back, lspci >lspci.2.txt diff lspci.1.txtlspci.2.txt If you don't see a new entry... um... you don't have a card ;) if you do see a 2nd firewire card, you should see /dev/fw0 /dev/fw1 and when you plug in your dv camera to either card: /dev/fw2 > > I can't find any way to turn off the on-board firewire to try this. > > Meantime, thanks for your encouragement and help. > > On 13/10/15 01:09, Stefan Richter wrote: >> On Oct 12 David wrote: >>> On 12/10/15 17:35, Stefan Richter wrote: >>>> On Oct 12 David wrote: >>>>> david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules >>>>> KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" >>>>> SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" >>>>> SUBSYSTEM=="firewire", GROUP="video" >>>> This is unnecessary; stock udev already contains proper rules for almost >>>> all FireWire applications, including (H)DV capture. >>> I removed this file. Should there be a rule for firewire in /etc/udev? >>> david@david:/etc/udev$ grep -ri firewire . >>> david@david:/etc/udev$ <nothing> >> $ grep -r firewire /lib/udev/ >> should turn up a few hits. >> >> I am following up on the rest later. > > -- > David McQuire > 0418 310312 > > > ------------------------------------------------------------------------------ > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user -- Carl K |
From: David <da...@ke...> - 2015-10-19 00:14:38
|
Hi I've discovered the problem. The motherboard has an on-board firewire of which I was unaware. If I plug into the motherboard everything works as advertised. It seems that the PCI board is being ignored. Since I only have one firewire device I'm not sure what would happen if I plug a second device into the card. Would it get recognised? I can't find any way to turn off the on-board firewire to try this. Meantime, thanks for your encouragement and help. On 13/10/15 01:09, Stefan Richter wrote: > On Oct 12 David wrote: >> On 12/10/15 17:35, Stefan Richter wrote: >>> On Oct 12 David wrote: >>>> david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules >>>> KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" >>>> SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" >>>> SUBSYSTEM=="firewire", GROUP="video" >>> This is unnecessary; stock udev already contains proper rules for almost >>> all FireWire applications, including (H)DV capture. >> I removed this file. Should there be a rule for firewire in /etc/udev? >> david@david:/etc/udev$ grep -ri firewire . >> david@david:/etc/udev$ <nothing> > $ grep -r firewire /lib/udev/ > should turn up a few hits. > > I am following up on the rest later. -- David McQuire 0418 310312 |
From: Stefan R. <st...@s5...> - 2015-10-12 14:10:08
|
On Oct 12 David wrote: > On 12/10/15 17:35, Stefan Richter wrote: > > On Oct 12 David wrote: > >> david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules > >> KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" > >> SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" > >> SUBSYSTEM=="firewire", GROUP="video" > > This is unnecessary; stock udev already contains proper rules for almost > > all FireWire applications, including (H)DV capture. > > I removed this file. Should there be a rule for firewire in /etc/udev? > david@david:/etc/udev$ grep -ri firewire . > david@david:/etc/udev$ <nothing> $ grep -r firewire /lib/udev/ should turn up a few hits. I am following up on the rest later. -- Stefan Richter -=====-===== =-=- -==-- http://arcgraph.de/sr/ |
From: David <da...@ke...> - 2015-10-12 12:26:54
|
00:00.0 Host bridge [0600]: Intel Corporation Core Processor DMI [8086:d131] (rev 11) 00:03.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express Root Port 1 [8086:d138] (rev 11) 00:05.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express Root Port 3 [8086:d13a] (rev 11) 00:08.0 System peripheral [0880]: Intel Corporation Core Processor System Management Registers [8086:d155] (rev 11) 00:08.1 System peripheral [0880]: Intel Corporation Core Processor Semaphore and Scratchpad Registers [8086:d156] (rev 11) 00:08.2 System peripheral [0880]: Intel Corporation Core Processor System Control and Status Registers [8086:d157] (rev 11) 00:08.3 System peripheral [0880]: Intel Corporation Core Processor Miscellaneous Registers [8086:d158] (rev 11) 00:10.0 System peripheral [0880]: Intel Corporation Core Processor QPI Link [8086:d150] (rev 11) 00:10.1 System peripheral [0880]: Intel Corporation Core Processor QPI Routing and Protocol Registers [8086:d151] (rev 11) 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b3b] (rev 05) 00:1a.1 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b3e] (rev 05) 00:1a.2 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b3f] (rev 05) 00:1a.7 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 05) 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 05) 00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 05) 00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 [8086:3b44] (rev 05) 00:1c.2 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 [8086:3b46] (rev 05) 00:1c.3 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 [8086:3b48] (rev 05) 00:1c.6 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 7 [8086:3b4e] (rev 05) 00:1d.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b36] (rev 05) 00:1d.1 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b37] (rev 05) 00:1d.2 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b38] (rev 05) 00:1d.3 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b39] (rev 05) 00:1d.7 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 05) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a5) 00:1f.0 ISA bridge [0601]: Intel Corporation 5 Series Chipset LPC Interface Controller [8086:3b02] (rev 05) 00:1f.2 IDE interface [0101]: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA IDE Controller [8086:3b20] (rev 05) 00:1f.3 SMBus [0c05]: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller [8086:3b30] (rev 05) 00:1f.5 IDE interface [0101]: Intel Corporation 5 Series/3400 Series Chipset 2 port SATA IDE Controller [8086:3b26] (rev 05) 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 8600 GT] [10de:0402] (rev a1) 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 03) 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 03) 05:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 03) 06:00.0 IDE interface [0101]: Marvell Technology Group Ltd. Device [1b4b:91a3] (rev 11) 07:00.0 SATA controller [0106]: JMicron Technology Corp. JMB363 SATA/IDE Controller [197b:2363] (rev 03) 07:00.1 IDE interface [0101]: JMicron Technology Corp. JMB363 SATA/IDE Controller [197b:2363] (rev 03) 08:06.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] 08:07.0 IDE interface [0101]: Integrated Technology Express, Inc. IT8213 IDE Controller [1283:8213] 3f:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture Generic Non-Core Registers [8086:2c51] (rev 04) 3f:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture System Address Decoder [8086:2c81] (rev 04) 3f:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 [8086:2c90] (rev 04) 3f:02.1 Host bridge [0600]: Intel Corporation Core Processor QPI Physical 0 [8086:2c91] (rev 04) 3f:03.0 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller [8086:2c98] (rev 04) 3f:03.1 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Target Address Decoder [8086:2c99] (rev 04) 3f:03.4 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Test Registers [8086:2c9c] (rev 04) 3f:04.0 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Control Registers [8086:2ca0] (rev 04) 3f:04.1 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Address Registers [8086:2ca1] (rev 04) 3f:04.2 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Rank Registers [8086:2ca2] (rev 04) 3f:04.3 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Thermal Control Registers [8086:2ca3] (rev 04) 3f:05.0 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Control Registers [8086:2ca8] (rev 04) 3f:05.1 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Address Registers [8086:2ca9] (rev 04) 3f:05.2 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Rank Registers [8086:2caa] (rev 04) 3f:05.3 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Thermal Control Registers [8086:2cab] (rev 04) |
From: Stefan R. <st...@s5...> - 2015-10-12 06:36:06
|
On Oct 12 David wrote: > There are lots of posts on the net that look like my problem below, but > no solutions that I have been able to find. Is DV capture over firewire > unavailable now? DV works just fine. > Any help would be greatly appreciated. > > Ubuntu 12.04 > david@david:~$ uname -a > Linux david 3.2.0-91-generic #129-Ubuntu SMP Wed Sep 9 10:56:06 UTC 2015 > x86_64 x86_64 x86_64 GNU/Linux This kernel should be OK. > Canon XHA1 camcorder A HDV (MPEG-2) camcorder; AFAIU capture from this is supported by dvgrab. > When I plug in the firewire, the camera's screen reports: > "HDV/DV IN" > > david@david:~$ lspci | grep -i firewire > 08:06.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 > IEEE-1394a-2000 Controller (PHY/Link) This controller type is well supported. Please post the entire output of "lspci -nn" though, so that we see all other PCI(e) devices too and their numeric IDs. > david@david:~$ lsmod | grep -e 1394 -e firewire > firewire_ohci 41000 0 > firewire_core 63600 1 firewire_ohci > crc_itu_t 12707 1 firewire_core OK. > david@david:~$ ls -l /dev/raw1394 /dev/fw0 > crw-rw-rw- 1 root video 251, 0 Oct 11 15:54 /dev/fw0 > lrwxrwxrwx 1 root root 8 Oct 11 16:59 /dev/raw1394 -> /dev/fw0 This symlink is total nonsense. The /dev/raw1394 ABI is entirely different from the /dev/fw* ABI. Since after kernel 2.6.36, a file with the name /dev/raw1394 will simply do nothing. However, what's missing here is a second /dev/fw* file. There is one such file created on-the-fly for each present FireWire node, including each so-called local node = link layer controller. So, normally you would get crw------- 1 root root 250, 0 * /dev/fw0 for the controller after boot, and crw-rw---- 1 root video 250, 1 * /dev/fw1 for the camcorder as soon as it is plugged in/ switched on. Missing /dev/fw1 (or a higher number on systems with more than two FireWire nodes, e.g. with multiple FireWire controllers) means that the kernel did not discover any other FireWire node. > david@david:~$ sudo dvgrab -i > Error: no camera exists This is a consequence of the camera node not being detected. > david@david:~$ dvgrab -v > dvgrab 3.5 OK > I created the link for /dev/raw1394 because of this page: > https://help.ubuntu.com/community/FireWire/DigitalVideo Which is wrong. It does nothing, neither good nor harm. > I also did this (and then rebooted): > https://kdenlive.org/user-manual/troubleshooting-and-common-problems/troubleshooting-firewire-capture > > > david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules > KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" > SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" > SUBSYSTEM=="firewire", GROUP="video" This is unnecessary; stock udev already contains proper rules for almost all FireWire applications, including (H)DV capture. > david@david:~$ dmesg -T | grep firewire > [Sun Oct 11 15:53:52 2015] firewire_ohci 0000:08:06.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > [Sun Oct 11 15:53:52 2015] firewire_ohci: Added fw-ohci device 0000:08:06.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 > [Sun Oct 11 15:53:52 2015] firewire_core: created device fw0: GUID 00cc13240000241d, S400 OK. > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0xf (was 0x4020100, writing 0x4020105) > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x5 (was 0x0, writing 0xfb8f8000) > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xfb8ff000) > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x3 (was 0x0, writing 0x2010) > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006) > [Sun Oct 11 20:29:47 2015] firewire_core: skipped bus generations, destroying all nodes > [Sun Oct 11 20:29:47 2015] firewire_core: rediscovered device fw0 Not sure what that means. Maybe this is from a power management suspend--resume cycle. Messages about an fw1 are notably absent. What do you get in the kernel log if you run sudo modprobe -r firewire-ohci sleep 1 sudo modprobe firewire-ohci debug=2 while the camcorder is plugged in and switched on? And after this, what do you get if you leave firewire-ohci this way and unplug and replug the camcorder? (Please carefully note which kernel messages follow from what action.) -- Stefan Richter -=====-===== =-=- -==-- http://arcgraph.de/sr/ |
From: David <da...@ke...> - 2015-10-12 04:42:24
|
There are lots of posts on the net that look like my problem below, but no solutions that I have been able to find. Is DV capture over firewire unavailable now? Any help would be greatly appreciated. Ubuntu 12.04 david@david:~$ uname -a Linux david 3.2.0-91-generic #129-Ubuntu SMP Wed Sep 9 10:56:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Canon XHA1 camcorder When I plug in the firewire, the camera's screen reports: "HDV/DV IN" david@david:~$ lspci | grep -i firewire 08:06.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) david@david:~$ lsmod | grep -e 1394 -e firewire firewire_ohci 41000 0 firewire_core 63600 1 firewire_ohci crc_itu_t 12707 1 firewire_core david@david:~$ ls -l /dev/raw1394 /dev/fw0 crw-rw-rw- 1 root video 251, 0 Oct 11 15:54 /dev/fw0 lrwxrwxrwx 1 root root 8 Oct 11 16:59 /dev/raw1394 -> /dev/fw0 david@david:~$ sudo dvgrab -i Error: no camera exists david@david:~$ dvgrab -v dvgrab 3.5 I created the link for /dev/raw1394 because of this page: https://help.ubuntu.com/community/FireWire/DigitalVideo I also did this (and then rebooted): https://kdenlive.org/user-manual/troubleshooting-and-common-problems/troubleshooting-firewire-capture david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" SUBSYSTEM=="firewire", GROUP="video" david@david:~$ dmesg -T | grep firewire [Sun Oct 11 15:53:52 2015] firewire_ohci 0000:08:06.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [Sun Oct 11 15:53:52 2015] firewire_ohci: Added fw-ohci device 0000:08:06.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 [Sun Oct 11 15:53:52 2015] firewire_core: created device fw0: GUID 00cc13240000241d, S400 [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0xf (was 0x4020100, writing 0x4020105) [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x5 (was 0x0, writing 0xfb8f8000) [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xfb8ff000) [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x3 (was 0x0, writing 0x2010) [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006) [Sun Oct 11 20:29:47 2015] firewire_core: skipped bus generations, destroying all nodes [Sun Oct 11 20:29:47 2015] firewire_core: rediscovered device fw0 -- David McQuire 0418 310312 |
From: Stefan R. <st...@s5...> - 2015-10-09 10:30:12
|
Hi, it is more than a year ago that I last posted release notes for the IEEE 1394 kernel drivers. Here is a list of changes in the subsequent kernel releases. The by far largest volume of changes was developed by Takashi Sakamoto, especially his new support for many FireWire audio devices based on DICE and on OxSemi chipsets (released in kernel 3.19) and continued improvements for BeBoB and Fireworks based devices. Linux 4.3 (tentative release notes as per v4.3-rc4) --------------------------------------------------- No functional changes to the FireWire subsystem. Linux 4.2 (30 August 2015) -------------------------- snd-bebob - Add support for Digidesign Mbox 2 Pro Behringer FCA610, FCA1616 - Improve BeBoB v3 support (PrismSound Orpheus, Behringer UFX1604, Behringer FCA610). - Improved clock source detection. Add SYT-Match support. snd-firewire-lib - Internal changes related to packet handling. snd-fireworks - Fix packet discontinuity with newer firmwares. Also fixed in v4.1.6 and v3.18.21. Linux 4.1 (21 June 2015) ------------------------ No functional changes to the FireWire subsystem. Linux 4.0 (12 April 2015) ------------------------- firewire-core The vendor ID and model ID in the Configuration ROM root directory of Linux hosts was changed from 0xd00d1e:0x000001 to 0x001f11:0x023901. This change makes firewire-core's local Configuration ROM comply with IEEE's OUI assignment rules. This has been made possible by Openmoko's granting a range of IDs to the Linux IEEE 1394 subsystem. See https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments for additional information. This change cannot have negative impact on any standard protocols, but developers of private protocols may need to adapt if they relied on these root directory entries instead of their own unit directory entries. snd-bebob - Fix initialization of some M-Audio devices with Linux on big-endian CPUs. Also fixed in v3.19.5 and v3.18.13. snd-firewire-lib, snd-bebob, snd-dice, snd-fireworks - Fix device reference counting and shutdown. Also fixed in v3.19.2. Linux 3.19 (8 February 2015) ---------------------------- firewire-ohci, firewire-sbp2 - small internal changes without functional change snd-dice - Large rework by Takashi Sakamoto in order to support PCM capture and MIDI I/O. (Before, only PCM playback was implemented.) This adds support for a wide range of DICE based audio devices. snd-firewire-lib - Limit MIDI transmission rate as per specification to prevent loss of messages. snd-oxfw - Driver was renamed from snd-firewire-speakers to snd-oxfw in order to reflect upcoming support for more audio devices based on OXFW970/971 based devices. - Large rework by Takashi Sakamoto in order to support PCM capture and MIDI I/O. (Before, only PCM playback was implemented.) - Additional device support implemented by Takashi Sakamoto: Behringer F-Control Audio 202 Mackie(Loud) Onyx-i series (former models) Mackie(Loud) Onyx Satellite Mackie(Loud) Tapco Link.Firewire Mackie(Loud) d.2 pro/d.4 pro Mackie(Loud) U.420/U.420d Linux 3.18 (7 December 2014) ---------------------------- firedtv - Fix potential overflow of operands for Conditional Access. firewire-core - Prevent kernel stack leaking into ioctl arguments. Also fixed in v3.17.4, v3.14.25, v3.12.34, v3.10.61, v3.4.106, v3.2.65. snd-bebob - Fix Terratec Phase 88 clock source detection. Also fixed in v3.17.2 and v3.16.7. - Fix Terratec Phase 88 Rack FW clock source detection. - Fix Saffire Pro clock source detection. Also fixed in v3.17.3. Linux 3.17 (5 October 2014) --------------------------- snd-dice - Fix regression at 176.4 and 192.0 kHz sample rate. Also fixed in v3.16.4. -- Stefan Richter -=====-===== =-=- -=--= http://arcgraph.de/sr/ |