linux1394-user Mailing List for IEEE 1394 for Linux (Page 3)
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: Eric L. <ela...@te...> - 2015-09-10 00:16:21
|
On Thu, 2015-07-23 at 23:39 +0200, Stefan Richter wrote: > On Jul 23 Eric Lamphear wrote: > > On Thu, 2015-07-23 at 20:22 +0200, Stefan Richter wrote: > > > Long series of bus reset events, more so ones without following > > > selfIDcomplete events, mean that the bus is electrically unstable (i.e. > > > too much noise on the bus). I.e. the hardware is defect. > > > > > > Another possible cause of many bus resets which prevent normal access to > > > the bus would be the presence of several Texas Instruments TSB81BA3 phys > > > which have a long list of errata (up to chip revision C inclusive). > > > However, in my experience the TSB81BA3 errata cause bus resets with many > > > selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata > > > can be worked around by adding a 1394a-only phy to the bus. > > > > Stefan, Thank you for the reply... > > I am not entirely sure that the hardware is faulty... If I place the > > same PCI card into my host machine (i686 running Fedora 19), and use the > > same hard drive and cable, I am able to connect without any issues. So > > unless the problem is in the PCI link to the 1394 controller it may have > > something to do with the ARM Cortex-A9 processor (Freescale i.MX6) on my > > target hardware. > > Insufficient power supply of the card could be another cause for such > symptoms. Or EMI from the host board, or EMI from elsewhere combined with > lacking shielding. Or some sort of issue with the grounding. (Note, I am > not an electrical engineer.) > > > Or, possibly any changes made between the 3.10.17 > > kernel on my target and the 3.14.17 kernel on my host machine. > > The issue is at the physical layer. Driver software does not cause such > behavior, except with some exotic controllers which currently do not work > alright with Linux (notably some ALi based cards and with the > Fujitsu-derived controller of Pinnacle MovieBoard). But your card > contains a good link & phy chip which works very well under Linux. > > > I don't know if I have a TSB81BA3 phy... Unless this is contained within > > the XIO2213B (3 port phy) controller that is on the PCI card. > > The integrated phy of XIO2213B possibly inherits some genes from the older > TSB81BA3. The TSB81BA3 errata which I alluded to had been fixed in > TSB81BA3D and are not present in XIO2213B. (My own experience with > several chips from all three generations backs this up.) > > BTW, I am having an errata sheet for XIO2213B here (SCPZ007A, issued May > 2010, revised June 2010). It lists two issues which concern the PCIe > bridge part of the chip: > "Errata #1: UR Bit Incorrectly Set in the Uncorrectable Error Status > Register When the ANFES Bit Is Set" > (no proposed workaround documented in this sheet) > "Errata #2: File Transfer Fails When L1 is Enabled" > (proposed workaround: do not enable L1) > > XIO2213B is three chips in one: A PCIe to PCI bridge (with the two > mentioned errata), an OHCI1394 link, and a 1394b phy. I am not sure > whether there is any connection between L1 low power state of the PCIe > bridge and possible low power states of the phy. At least the XIO2213B > data manual (SCPS210D, issued October 2008, revised July 2009) section 3.10 > does not indicate any such connection. > > > Also, Is it possible to force the controller to connect as 1394a on the > > 1394b port? > > Yes; see descriptions of the terminals DS0, DS1, and LKON/DS2_P in table > 2-9 and section 10 of SCPS210D. > > > I guess I will try to upgrade my kernel to 3.14.28 first to see if the > > problem goes away... If that doesn't work, I will look into the ARM > > Errata selections in the Kernel Config. > > Yes, please try the newest kernel that you possibly can; maybe there is an > unexpected interaction between ARM specific platform code and the 1394 > physical layer. (Unexpected to me at least...) In an effort to start debugging my issues connecting to the drive, I turned on CONFIG_LOCK_STAT in my kernel configuration. After doing this I have not been able replicate the issue. The drive is now discovered and able to be mounted on boot as well as when it is hot-plugged. Enabling CONFIG_LOCK_STAT also changed some other items in my .config file... the following is a diff from my old .config to my new .config (I removed the irrelevant extra lines)... This caused the issue "go away", although I am sure that this only masked the problem. -# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_ALL=y -CONFIG_INLINE_SPIN_UNLOCK_IRQ=y -CONFIG_INLINE_READ_UNLOCK=y -CONFIG_INLINE_READ_UNLOCK_IRQ=y -CONFIG_INLINE_WRITE_UNLOCK=y -CONFIG_INLINE_WRITE_UNLOCK_IRQ=y -CONFIG_MUTEX_SPIN_ON_OWNER=y +CONFIG_UNINLINE_SPIN_UNLOCK=y -CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_SPLIT_PTLOCK_CPUS=999999 -# CONFIG_DEBUG_SPINLOCK is not set -# CONFIG_DEBUG_MUTEXES is not set -# CONFIG_DEBUG_LOCK_ALLOC is not set +CONFIG_DEBUG_SPINLOCK=y +CONFIG_DEBUG_MUTEXES=y +CONFIG_DEBUG_LOCK_ALLOC=y -# CONFIG_LOCK_STAT is not set +CONFIG_LOCKDEP=y +CONFIG_LOCK_STAT=y +# CONFIG_DEBUG_LOCKDEP is not set +CONFIG_STACKTRACE=y |
From: Eric L. <ela...@te...> - 2015-09-02 02:13:06
|
On Thu, 2015-07-23 at 23:39 +0200, Stefan Richter wrote: > On Jul 23 Eric Lamphear wrote: > > On Thu, 2015-07-23 at 20:22 +0200, Stefan Richter wrote: > > > Long series of bus reset events, more so ones without following > > > selfIDcomplete events, mean that the bus is electrically unstable (i.e. > > > too much noise on the bus). I.e. the hardware is defect. > > > > > > Another possible cause of many bus resets which prevent normal access to > > > the bus would be the presence of several Texas Instruments TSB81BA3 phys > > > which have a long list of errata (up to chip revision C inclusive). > > > However, in my experience the TSB81BA3 errata cause bus resets with many > > > selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata > > > can be worked around by adding a 1394a-only phy to the bus. > > > > Stefan, Thank you for the reply... > > I am not entirely sure that the hardware is faulty... If I place the > > same PCI card into my host machine (i686 running Fedora 19), and use the > > same hard drive and cable, I am able to connect without any issues. So > > unless the problem is in the PCI link to the 1394 controller it may have > > something to do with the ARM Cortex-A9 processor (Freescale i.MX6) on my > > target hardware. > > Insufficient power supply of the card could be another cause for such > symptoms. Or EMI from the host board, or EMI from elsewhere combined with > lacking shielding. Or some sort of issue with the grounding. (Note, I am > not an electrical engineer.) > > > Or, possibly any changes made between the 3.10.17 > > kernel on my target and the 3.14.17 kernel on my host machine. > > The issue is at the physical layer. Driver software does not cause such > behavior, except with some exotic controllers which currently do not work > alright with Linux (notably some ALi based cards and with the > Fujitsu-derived controller of Pinnacle MovieBoard). But your card > contains a good link & phy chip which works very well under Linux. > > > I don't know if I have a TSB81BA3 phy... Unless this is contained within > > the XIO2213B (3 port phy) controller that is on the PCI card. > > The integrated phy of XIO2213B possibly inherits some genes from the older > TSB81BA3. The TSB81BA3 errata which I alluded to had been fixed in > TSB81BA3D and are not present in XIO2213B. (My own experience with > several chips from all three generations backs this up.) > > BTW, I am having an errata sheet for XIO2213B here (SCPZ007A, issued May > 2010, revised June 2010). It lists two issues which concern the PCIe > bridge part of the chip: > "Errata #1: UR Bit Incorrectly Set in the Uncorrectable Error Status > Register When the ANFES Bit Is Set" > (no proposed workaround documented in this sheet) > "Errata #2: File Transfer Fails When L1 is Enabled" > (proposed workaround: do not enable L1) > > XIO2213B is three chips in one: A PCIe to PCI bridge (with the two > mentioned errata), an OHCI1394 link, and a 1394b phy. I am not sure > whether there is any connection between L1 low power state of the PCIe > bridge and possible low power states of the phy. At least the XIO2213B > data manual (SCPS210D, issued October 2008, revised July 2009) section 3.10 > does not indicate any such connection. > > > Also, Is it possible to force the controller to connect as 1394a on the > > 1394b port? > > Yes; see descriptions of the terminals DS0, DS1, and LKON/DS2_P in table > 2-9 and section 10 of SCPS210D. > > > I guess I will try to upgrade my kernel to 3.14.28 first to see if the > > problem goes away... If that doesn't work, I will look into the ARM > > Errata selections in the Kernel Config. > > Yes, please try the newest kernel that you possibly can; maybe there is an > unexpected interaction between ARM specific platform code and the 1394 > physical layer. (Unexpected to me at least...) One more clue... I decided to try to limit my processor to 1 cpu by adding maxcpus=1 to my kernel command line in u-boot. After doing this I am able to reliably connect to my drive as long as it is connected prior to booting. If I connec, or disconnect/reconnect the drive after the system is up, the behavior is the same as before. Is it possible that there is a data race or some kind of synchronization problem when running on the ARM Cortex A9 processor? |
From: Stefan R. <st...@s5...> - 2015-07-23 21:39:20
|
On Jul 23 Eric Lamphear wrote: > On Thu, 2015-07-23 at 20:22 +0200, Stefan Richter wrote: > > Long series of bus reset events, more so ones without following > > selfIDcomplete events, mean that the bus is electrically unstable (i.e. > > too much noise on the bus). I.e. the hardware is defect. > > > > Another possible cause of many bus resets which prevent normal access to > > the bus would be the presence of several Texas Instruments TSB81BA3 phys > > which have a long list of errata (up to chip revision C inclusive). > > However, in my experience the TSB81BA3 errata cause bus resets with many > > selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata > > can be worked around by adding a 1394a-only phy to the bus. > > Stefan, Thank you for the reply... > I am not entirely sure that the hardware is faulty... If I place the > same PCI card into my host machine (i686 running Fedora 19), and use the > same hard drive and cable, I am able to connect without any issues. So > unless the problem is in the PCI link to the 1394 controller it may have > something to do with the ARM Cortex-A9 processor (Freescale i.MX6) on my > target hardware. Insufficient power supply of the card could be another cause for such symptoms. Or EMI from the host board, or EMI from elsewhere combined with lacking shielding. Or some sort of issue with the grounding. (Note, I am not an electrical engineer.) > Or, possibly any changes made between the 3.10.17 > kernel on my target and the 3.14.17 kernel on my host machine. The issue is at the physical layer. Driver software does not cause such behavior, except with some exotic controllers which currently do not work alright with Linux (notably some ALi based cards and with the Fujitsu-derived controller of Pinnacle MovieBoard). But your card contains a good link & phy chip which works very well under Linux. > I don't know if I have a TSB81BA3 phy... Unless this is contained within > the XIO2213B (3 port phy) controller that is on the PCI card. The integrated phy of XIO2213B possibly inherits some genes from the older TSB81BA3. The TSB81BA3 errata which I alluded to had been fixed in TSB81BA3D and are not present in XIO2213B. (My own experience with several chips from all three generations backs this up.) BTW, I am having an errata sheet for XIO2213B here (SCPZ007A, issued May 2010, revised June 2010). It lists two issues which concern the PCIe bridge part of the chip: "Errata #1: UR Bit Incorrectly Set in the Uncorrectable Error Status Register When the ANFES Bit Is Set" (no proposed workaround documented in this sheet) "Errata #2: File Transfer Fails When L1 is Enabled" (proposed workaround: do not enable L1) XIO2213B is three chips in one: A PCIe to PCI bridge (with the two mentioned errata), an OHCI1394 link, and a 1394b phy. I am not sure whether there is any connection between L1 low power state of the PCIe bridge and possible low power states of the phy. At least the XIO2213B data manual (SCPS210D, issued October 2008, revised July 2009) section 3.10 does not indicate any such connection. > Also, Is it possible to force the controller to connect as 1394a on the > 1394b port? Yes; see descriptions of the terminals DS0, DS1, and LKON/DS2_P in table 2-9 and section 10 of SCPS210D. > I guess I will try to upgrade my kernel to 3.14.28 first to see if the > problem goes away... If that doesn't work, I will look into the ARM > Errata selections in the Kernel Config. Yes, please try the newest kernel that you possibly can; maybe there is an unexpected interaction between ARM specific platform code and the 1394 physical layer. (Unexpected to me at least...) -- Stefan Richter -=====-===== -=== =-=== http://arcgraph.de/sr/ |
From: Eric L. <ela...@te...> - 2015-07-23 19:24:37
|
On Thu, 2015-07-23 at 20:22 +0200, Stefan Richter wrote: > On Jul 22 Eric Lamphear wrote: > > On Thu, 2015-06-25 at 20:10 -0500, Eric Lamphear wrote: > [...] > > > firewire_ohci 0000:02:00.0: IRQ 00030010 selfID AR_req busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > root@tads_nitrogen6x:~# firewire_ohci 0000:02:00.0: IRQ 00020000 > > > busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > [...] > > OK, not sure why this is being ignored, but I really do need help to get > > this resolved? I am not familiar with Linux drivers or kernel > > development, so I am afraid that I will make things worse if I start > > hacking around looking for a fix (which I already have by adding the > > printk statements in the patch mentioned above)... > > if anyone is willing to help, I can, at the very least, provide the > > hardware. > > Long series of bus reset events, more so ones without following > selfIDcomplete events, mean that the bus is electrically unstable (i.e. > too much noise on the bus). I.e. the hardware is defect. > > Another possible cause of many bus resets which prevent normal access to > the bus would be the presence of several Texas Instruments TSB81BA3 phys > which have a long list of errata (up to chip revision C inclusive). > However, in my experience the TSB81BA3 errata cause bus resets with many > selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata > can be worked around by adding a 1394a-only phy to the bus. Stefan, Thank you for the reply... I am not entirely sure that the hardware is faulty... If I place the same PCI card into my host machine (i686 running Fedora 19), and use the same hard drive and cable, I am able to connect without any issues. So unless the problem is in the PCI link to the 1394 controller it may have something to do with the ARM Cortex-A9 processor (Freescale i.MX6) on my target hardware. Or, possibly any changes made between the 3.10.17 kernel on my target and the 3.14.17 kernel on my host machine. I don't know if I have a TSB81BA3 phy... Unless this is contained within the XIO2213B (3 port phy) controller that is on the PCI card. Also, Is it possible to force the controller to connect as 1394a on the 1394b port? I guess I will try to upgrade my kernel to 3.14.28 first to see if the problem goes away... If that doesn't work, I will look into the ARM Errata selections in the Kernel Config. |
From: Stefan R. <st...@s5...> - 2015-07-23 18:22:58
|
On Jul 22 Eric Lamphear wrote: > On Thu, 2015-06-25 at 20:10 -0500, Eric Lamphear wrote: [...] > > firewire_ohci 0000:02:00.0: IRQ 00030010 selfID AR_req busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > root@tads_nitrogen6x:~# firewire_ohci 0000:02:00.0: IRQ 00020000 > > busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset [...] > OK, not sure why this is being ignored, but I really do need help to get > this resolved? I am not familiar with Linux drivers or kernel > development, so I am afraid that I will make things worse if I start > hacking around looking for a fix (which I already have by adding the > printk statements in the patch mentioned above)... > if anyone is willing to help, I can, at the very least, provide the > hardware. Long series of bus reset events, more so ones without following selfIDcomplete events, mean that the bus is electrically unstable (i.e. too much noise on the bus). I.e. the hardware is defect. Another possible cause of many bus resets which prevent normal access to the bus would be the presence of several Texas Instruments TSB81BA3 phys which have a long list of errata (up to chip revision C inclusive). However, in my experience the TSB81BA3 errata cause bus resets with many selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata can be worked around by adding a 1394a-only phy to the bus. -- Stefan Richter -=====-===== -=== =-=== http://arcgraph.de/sr/ |
From: Eric L. <ela...@te...> - 2015-07-22 19:16:46
|
On Thu, 2015-06-25 at 20:10 -0500, Eric Lamphear wrote: > > Sorry about the repeated message... I believe that I posted to the > incorrect list... > > I am working with Magnus La on the issue that he reported a while > back: > We are still trying to get this to work... > http://sourceforge.net/p/linux1394/mailman/message/33270726/ > > I am using the same hardware (nitrogen6x, with a Freescale iMX6q > processor) and the same PCI card (which works flawlessly on my desktop > running Fedora 19) > for the nitrogen6x board, we are using the following kernel sources: > git://github.com/boundarydevices/linux-imx6.git > branch: boundary-imx_3.10.17_1.0.2_ga > revision/commit: fdf3d06333f2c4ae8aa8bac9bca2e5c15041f22e > > As far as I can tell, the firewire driver appears to be unmodified > from the mainline 3.10.17 sources. > > From there, I added a few printk statements to help see what was going > on... the patch is here: > http://pastebin.com/Ney1WfiQ > > on bootup (or if I remove and reinstall the firewire_ohci module) I > get the following: > > root@nitrogen6x:~# dmesg | grep -e firewire -e sbp2 -e scsi -e > pcie > imx6q-pcie 1ffc000.pcie: Link up, Gen=1 > imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00 > scsi0 : ahci_platform > firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + > 8 IT contexts, quirks 0x2 > firewire_core 0000:02:00.0: created device fw0: GUID 0001b713000039db, > S800 > firewire_core 0000:02:00.0: created device fw1: GUID 0014520300501763, > S800 > firewire_core 0000:02:00.0: phy config: new root=ffc0, gap_count=5 > scsi1 : SBP-2 IEEE-1394 > firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > sbp2_login: command_block_agent_address is 281470681743360, generation > is 2 > sbp2_set_busy_timeout returned rcode 0x0 (no error) > sbp2_agent_reset: command_block_agent_address is 281470681743360, > generation is 2 > sbp2_agent_reset returned rcode 0x7 (address error) > scsi_probe_and_add_lun: scsi_device_lookup_by_target(0xD268AC00, 0x0) > returned sdev of 0x0 > sbp2-complete_transaction: complete_transaction() sending NULL status > due to rcode != RCODE_COMPLETE > sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL > sbp2-complete_transaction: complete_transaction() sending NULL status > due to rcode != RCODE_COMPLETE > sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL > sbp2-complete_transaction: complete_transaction() sending NULL status > due to rcode != RCODE_COMPLETE > sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL > sbp2-complete_transaction: complete_transaction() sending NULL status > due to rcode != RCODE_COMPLETE > sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL > scsi_probe_and_add_lun: scsi_probe_lun returned non 0! > __scsi_add_device: scsi_probe_add_lun returned 0(0x0): sdev = -19 > (0xFFFFFFED) > sbp2_login: scsi sdev = -19(0xFFFFFFED) > sbp2_login: IS_ERR(sdev) is true... attempt logout_login > sbp2_login: out_logout_login: sending SBP2_LOGOUT_REQUEST. > sbp2_login: out_logout_login: rescheduling login. > > after this there are no more messages... > > If I remove the firewire_sbp2 and firewire_ohci modules and re-install > the firewire_ohci using "modprobe firewire_ohci debug=8", I get the > following: > root@nitrogen6x:~# modprobe firewire_ohci > debug=8 > firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + > 8 IT contexts, quirks 0x2 > > firewire_ohci 0000:02:00.0: IRQ 00030010 selfID AR_req busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > root@tads_nitrogen6x:~# firewire_ohci 0000:02:00.0: IRQ 00020000 > busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > ... > the last line repeats very rapidly until the kernel eventually crashes > (using a serial port, my guess is that this message is overflowing the > output). > Either way, once I start with debug=8 I cannot do anything else. > > it looks to me like the bus resets are not allowing the sbp2_login > function to complete (in fact the rescheduled login never happens). > I have also tried this using a Lacie portable firewire hard drive with > the exact same results. > > I am stuck at this point... any help or pointers would be greatly > appreciated. > > Eric OK, not sure why this is being ignored, but I really do need help to get this resolved? I am not familiar with Linux drivers or kernel development, so I am afraid that I will make things worse if I start hacking around looking for a fix (which I already have by adding the printk statements in the patch mentioned above)... if anyone is willing to help, I can, at the very least, provide the hardware. |
From: Eric L. <ela...@te...> - 2015-06-26 01:10:48
|
Sorry about the repeated message... I believe that I posted to the incorrect list... I am working with Magnus La on the issue that he reported a while back: We are still trying to get this to work... http://sourceforge.net/p/linux1394/mailman/message/33270726/ I am using the same hardware (nitrogen6x, with a Freescale iMX6q processor) and the same PCI card (which works flawlessly on my desktop running Fedora 19) for the nitrogen6x board, we are using the following kernel sources: git://github.com/boundarydevices/linux-imx6.git branch: boundary-imx_3.10.17_1.0.2_ga revision/commit: fdf3d06333f2c4ae8aa8bac9bca2e5c15041f22e As far as I can tell, the firewire driver appears to be unmodified from the mainline 3.10.17 sources. From there, I added a few printk statements to help see what was going on... the patch is here: http://pastebin.com/Ney1WfiQ on bootup (or if I remove and reinstall the firewire_ohci module) I get the following: root@nitrogen6x<mailto:root@nitrogen6x>:~# dmesg | grep -e firewire -e sbp2 -e scsi -e pcie imx6q-pcie 1ffc000.pcie: Link up, Gen=1 imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00 scsi0 : ahci_platform firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x2 firewire_core 0000:02:00.0: created device fw0: GUID 0001b713000039db, S800 firewire_core 0000:02:00.0: created device fw1: GUID 0014520300501763, S800 firewire_core 0000:02:00.0: phy config: new root=ffc0, gap_count=5 scsi1 : SBP-2 IEEE-1394 firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) sbp2_login: command_block_agent_address is 281470681743360, generation is 2 sbp2_set_busy_timeout returned rcode 0x0 (no error) sbp2_agent_reset: command_block_agent_address is 281470681743360, generation is 2 sbp2_agent_reset returned rcode 0x7 (address error) scsi_probe_and_add_lun: scsi_device_lookup_by_target(0xD268AC00, 0x0) returned sdev of 0x0 sbp2-complete_transaction: complete_transaction() sending NULL status due to rcode != RCODE_COMPLETE sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL sbp2-complete_transaction: complete_transaction() sending NULL status due to rcode != RCODE_COMPLETE sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL sbp2-complete_transaction: complete_transaction() sending NULL status due to rcode != RCODE_COMPLETE sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL sbp2-complete_transaction: complete_transaction() sending NULL status due to rcode != RCODE_COMPLETE sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL scsi_probe_and_add_lun: scsi_probe_lun returned non 0! __scsi_add_device: scsi_probe_add_lun returned 0(0x0): sdev = -19 (0xFFFFFFED) sbp2_login: scsi sdev = -19(0xFFFFFFED) sbp2_login: IS_ERR(sdev) is true... attempt logout_login sbp2_login: out_logout_login: sending SBP2_LOGOUT_REQUEST. sbp2_login: out_logout_login: rescheduling login. after this there are no more messages... If I remove the firewire_sbp2 and firewire_ohci modules and re-install the firewire_ohci using "modprobe firewire_ohci debug=8", I get the following: root@nitrogen6x<mailto:root@tads_nitrogen6x>:~# modprobe firewire_ohci debug=8 firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x2 firewire_ohci 0000:02:00.0: IRQ 00030010 selfID AR_req busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset root@tads_nitrogen6x<mailto:root@tads_nitrogen6x>:~# firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset ... the last line repeats very rapidly until the kernel eventually crashes (using a serial port, my guess is that this message is overflowing the output). Either way, once I start with debug=8 I cannot do anything else. it looks to me like the bus resets are not allowing the sbp2_login function to complete (in fact the rescheduled login never happens). I have also tried this using a Lacie portable firewire hard drive with the exact same results. I am stuck at this point... any help or pointers would be greatly appreciated. Eric |
From: Stefan R. <st...@s5...> - 2015-04-28 21:57:55
|
Hi all, it has been too long a wait, but a new bugfix release of libraw1394, the legacy programming interface to low-level IEEE 1394 I/O on Linux, is available at last. The changes: - Fix backwards moving cycle timer in isochronous transmit. The problem has been observed with audio I/O on different systems. - Fix crash with SIGBUS on SPARC and similar architectures. - Fix memory leak in address range mapping response handler. - Fix errno reporting to applications which relied on behavior of libraw1394 1.x. - Fix errno checking in the dumpiso and sendiso example programs. - Minor documentation improvement. ------------------------------------------------------------------------ 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.1.tar.gz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.1.tar.xz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.1.tar.sign ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.1.tar.gz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.1.tar.xz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.1.1.tar.sign To verify a downloaded tarball, first uncompress from *.tar.gz or *.tar.xz to *.tar, then run "gpg --verify libraw1394-2.1.1.tar.sign". ------------------------------------------------------------------------ Shortlog and diffstat from v2.1.0 to v2.1.1: Aaro Koskinen (1): Align fw_handle buffer for 64-bit access Jonathan Woithe (1): Prevent requests for previously provided iso tx packets Lee Cewd (1): Fix memory leak in response handler Stefan Richter (4): Documentation improvement: return code of raw1394_read_cycle_timer{,_and_clock} tools: Fix startup of dumpiso and sendiso on juju Save and restore errno in raw1394_new_handle{,_on_port} for legacy applications configure.ac, Changelog, NEWS: update to version 2.1.1 ChangeLog | 26 ++++++++++++++++++++++++++ NEWS | 10 ++++++++++ configure.ac | 2 +- src/dispatch.c | 10 ++++++++++ src/fw-iso.c | 4 ++-- src/fw.c | 8 +++++--- src/fw.h | 2 +- src/raw1394.h | 2 +- tools/dumpiso.c | 8 ++++---- tools/sendiso.c | 7 ++++--- 10 files changed, 64 insertions(+), 15 deletions(-) -- Stefan Richter -=====-===== -=-- ===-- http://arcgraph.de/sr/ |
From: Allan D. <al...@fa...> - 2015-04-10 05:24:33
|
On 10/04/15 05:35, Ларионов Даниил wrote: > Hello Stefan. > > You seem to know a lot about IEEE1394 hardware, not only software. Could you please tell me whether it is possible to burn a FireWire device by not connecting its housing to the host's? > I have a ScanControl surface analyzer from MicroEpsilon. It is essentially a DCAM camera with IEEE1394 interface. > I soldered my own cable, because I needed a special one (not fracturing at extremely low temperatures etc.) Since the scanner has a separate power port, I soldered only 4 wires (TPA+, TPB+, TPA-, TPB-). > I also connected the connector ground to the cable shield at only one end of the wire. I asked the manufacturer employee and he said that's ok. > The scanner worked fine for a while, but then it just suddenly broke. I sent it back to the manufacturer and they sent me these photos: > > https://yadi.sk/d/nlIi62iXf9dEE > > and recommended to buy their own cable. I did that, and it seems that the only difference between my cable and theirs (besides the absence of power wires) was that the shield was connected to the connectors at both ends. > Did you have similar cases in your experience? > Thanks in advance. > Contrary to the advice you got, the earth/shield coonection to both ends is critically important - without it the device at each end can float to large relative voltages, well beyond the Common Mode voltage range of the input electronics. You are lucky it only killed the analyzer. If both devices have explicit, and common, ground connections then only one end need be shielded, and not having either end connected may also work fine. Most plug-pack power sources have floating outputs. |
From: Ларионов Д. <lar...@ya...> - 2015-04-09 19:35:45
|
Hello Stefan. You seem to know a lot about IEEE1394 hardware, not only software. Could you please tell me whether it is possible to burn a FireWire device by not connecting its housing to the host's? I have a ScanControl surface analyzer from MicroEpsilon. It is essentially a DCAM camera with IEEE1394 interface. I soldered my own cable, because I needed a special one (not fracturing at extremely low temperatures etc.) Since the scanner has a separate power port, I soldered only 4 wires (TPA+, TPB+, TPA-, TPB-). I also connected the connector ground to the cable shield at only one end of the wire. I asked the manufacturer employee and he said that's ok. The scanner worked fine for a while, but then it just suddenly broke. I sent it back to the manufacturer and they sent me these photos: https://yadi.sk/d/nlIi62iXf9dEE and recommended to buy their own cable. I did that, and it seems that the only difference between my cable and theirs (besides the absence of power wires) was that the shield was connected to the connectors at both ends. Did you have similar cases in your experience? Thanks in advance. -- Даниил Ларионов 09.04.2015, 21:45, "Stefan Richter" <st...@s5...>: > On Apr 09 Elias Aarnio wrote: >> 02.03.2015, 22:25, Stefan Richter kirjoitti: >>> You however get a never ending series of bus resets. These could be >>> caused by a hardware defect --- e.g. burnt out port or loose port at the >>> camcorder; worn out plug at the cable or broken wire or bad shielding of >>> the cable; worn out or desoldered port at the card; etc.. >> This was the reason. The cable was damaged so that in some positions it >> stopped working. > > For this reason I like the following cables with mere 3 mm outer diameter, > hence less weight and stiffness pulling on the plug: > http://www.partsdata.co.uk/firewire-cables-ieee-1394-accessories/firewire-400-cables-adapters/firewire-cable-46-white-flexible/ > (This vendor is based in Germany. Shipping costs to Scandinavia seem to be > quite high if all you need is just one cable.) > > Sony, who originally came up with the 4-pin plug, used to make cables > which were almost as thin but even more flexible. Maybe you can find a > used Sony cable for cheap. > > About half a year ago I got 4 mm thin and still quite flexible cables via > this page: http://www.amazon.de/gp/product/B00L8ZRQ0S > But one can never be sure what cable material one gets when buying noname. > The cables which I received from there have a different mold of the plug > casings than the cable on the amazon photo. > -- > Stefan Richter > -=====-===== -=-- -=--= > http://arcgraph.de/sr/ > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user |
From: Stefan R. <st...@s5...> - 2015-04-09 18:45:00
|
On Apr 09 Elias Aarnio wrote: > 02.03.2015, 22:25, Stefan Richter kirjoitti: > > You however get a never ending series of bus resets. These could be > > caused by a hardware defect --- e.g. burnt out port or loose port at the > > camcorder; worn out plug at the cable or broken wire or bad shielding of > > the cable; worn out or desoldered port at the card; etc.. > > This was the reason. The cable was damaged so that in some positions it > stopped working. For this reason I like the following cables with mere 3 mm outer diameter, hence less weight and stiffness pulling on the plug: http://www.partsdata.co.uk/firewire-cables-ieee-1394-accessories/firewire-400-cables-adapters/firewire-cable-46-white-flexible/ (This vendor is based in Germany. Shipping costs to Scandinavia seem to be quite high if all you need is just one cable.) Sony, who originally came up with the 4-pin plug, used to make cables which were almost as thin but even more flexible. Maybe you can find a used Sony cable for cheap. About half a year ago I got 4 mm thin and still quite flexible cables via this page: http://www.amazon.de/gp/product/B00L8ZRQ0S But one can never be sure what cable material one gets when buying noname. The cables which I received from there have a different mold of the plug casings than the cable on the amazon photo. -- Stefan Richter -=====-===== -=-- -=--= http://arcgraph.de/sr/ |
From: Elias A. <eli...@ik...> - 2015-04-09 15:58:05
|
Hello, 02.03.2015, 22:25, Stefan Richter kirjoitti: > You however get a never ending series of bus resets. These could be > caused by a hardware defect --- e.g. burnt out port or loose port at the > camcorder; worn out plug at the cable or broken wire or bad shielding of > the cable; worn out or desoldered port at the card; etc.. This was the reason. The cable was damaged so that in some positions it stopped working. Thank you really much for your help! -- Elias Aarnio |
From: Stefan R. <st...@s5...> - 2015-03-02 20:25:23
|
On Mar 02 Elias Aarnio wrote: > After booting the machine with the PCMCIA card installed, removed it, > plugged it in again: > > Syslog: > > Mar 2 12:14:19 nakka-ThinkPad-T60 kernel: [ 322.780636] firewire_ohci 0000:16:00.0: removed fw-ohci device > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952178] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952218] pci 0000:16:00.0: [1106:3044] type 00 class 0x0c0010 > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952258] pci 0000:16:00.0: reg 0x10: [mem 0x00000000-0x000007ff] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952278] pci 0000:16:00.0: reg 0x14: [io 0x0000-0x007f] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952297] pci 0000:16:00.0: reg 0x18: [mem 0x00000000-0x000000ff] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952415] pci 0000:16:00.0: supports D2 > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952422] pci 0000:16:00.0: PME# supported from D2 D3hot D3cold > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952660] pci 0000:16:00.0: BAR 0: assigned [mem 0x84000000-0x840007ff] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952675] pci 0000:16:00.0: BAR 2: assigned [mem 0x84000800-0x840008ff] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952689] pci 0000:16:00.0: BAR 1: assigned [io 0xa000-0xa07f] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952829] firewire_ohci 0000:16:00.0: enabling device (0080 -> 0083) > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 326.016152] firewire_ohci 0000:16:00.0: added OHCI v1.10 device as card 4, 4 IR + 8 IT contexts, quirks 0x41 > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 326.516427] firewire_core 0000:16:00.0: created device fw0: GUID 00111666123403bc, S400 This appears to be the VT6306 card. (I have a VT6306 based CardBus Card too but it is configured to OHCI 1.0 mode by the card manufacturer. However OHCI 1.1 versus 1.0 is not of importance to the matter at hand.) > Then I plugged in the camera cable and switched camera on: > > Mar 2 12:14:46 nakka-ThinkPad-T60 kernel: [ 349.240209] firewire_core 0000:16:00.0: rediscovered device fw0 > Mar 2 12:14:47 nakka-ThinkPad-T60 kernel: [ 350.556151] firewire_core 0000:16:00.0: rediscovered device fw0 > Mar 2 12:14:48 nakka-ThinkPad-T60 kernel: [ 351.864169] firewire_core 0000:16:00.0: rediscovered device fw0 > > This last line keeps getting repeated once in a second, endlessly. > > Any thoughts? Normally, when a device is plugged in/ switched on, there are two or three bus resets or so and then the bus becomes operational, firewire-core queries the node for its type, and then higher-level software can take over. You however get a never ending series of bus resets. These could be caused by a hardware defect --- e.g. burnt out port or loose port at the camcorder; worn out plug at the cable or broken wire or bad shielding of the cable; worn out or desoldered port at the card; etc.. Or it could be firmware fighting against core driver: firewire-core assumes certain bus management duties, and these involve software-initiated bus resets. We had cases in the past where device firmware undid the bus configurations that firewire-core attempted to establish, and device and firewire-core repeatedly reset the bus. In order to learn more whether it could be a firmware <-> driver issue, please attempt again with some event logging switched on in firewire-ohci: When firewire-ohci is already loaded, but before the camcorder is plugged in/ switched on, issue the following command: sudo dd of=/sys/module/firewire_ohci/parameters/debug <<< 3 The plug in/ switch on the camcorder (shouldn't matter whether you first plug it in and then switch it on, or the other way around; but you can of course try both sequences), watch what is being logged in the kernel log, and post the log here. You can tell firewire-ohci to stop the debug logging any time by the same command as above but with 0 as parameter. -- Stefan Richter -=====-===== --== ---=- http://arcgraph.de/sr/ |
From: Elias A. <eli...@ik...> - 2015-03-02 10:29:24
|
After booting the machine with the PCMCIA card installed, removed it, plugged it in again: Syslog: Mar 2 12:14:19 nakka-ThinkPad-T60 kernel: [ 322.780636] firewire_ohci 0000:16:00.0: removed fw-ohci device Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952178] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952218] pci 0000:16:00.0: [1106:3044] type 00 class 0x0c0010 Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952258] pci 0000:16:00.0: reg 0x10: [mem 0x00000000-0x000007ff] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952278] pci 0000:16:00.0: reg 0x14: [io 0x0000-0x007f] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952297] pci 0000:16:00.0: reg 0x18: [mem 0x00000000-0x000000ff] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952415] pci 0000:16:00.0: supports D2 Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952422] pci 0000:16:00.0: PME# supported from D2 D3hot D3cold Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952660] pci 0000:16:00.0: BAR 0: assigned [mem 0x84000000-0x840007ff] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952675] pci 0000:16:00.0: BAR 2: assigned [mem 0x84000800-0x840008ff] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952689] pci 0000:16:00.0: BAR 1: assigned [io 0xa000-0xa07f] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952829] firewire_ohci 0000:16:00.0: enabling device (0080 -> 0083) Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 326.016152] firewire_ohci 0000:16:00.0: added OHCI v1.10 device as card 4, 4 IR + 8 IT contexts, quirks 0x41 Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 326.516427] firewire_core 0000:16:00.0: created device fw0: GUID 00111666123403bc, S400 Then I plugged in the camera cable and switched camera on: Mar 2 12:14:46 nakka-ThinkPad-T60 kernel: [ 349.240209] firewire_core 0000:16:00.0: rediscovered device fw0 Mar 2 12:14:47 nakka-ThinkPad-T60 kernel: [ 350.556151] firewire_core 0000:16:00.0: rediscovered device fw0 Mar 2 12:14:48 nakka-ThinkPad-T60 kernel: [ 351.864169] firewire_core 0000:16:00.0: rediscovered device fw0 This last line keeps getting repeated once in a second, endlessly. Any thoughts? |
From: Elias A. <eli...@ik...> - 2015-03-02 09:15:26
|
Hi, I am trying to get dvgrab to work in Ubuntu 14.10 running kernel 3.16.0-31. The distro has the "new" FW stack and I have done the tricks described here: https://kdenlive.org/user-manual/troubleshooting-and-common-problems/troubleshooting-firewire-capture I have tested two PCIMCIA adapters: 16:00.0 FireWire (IEEE 1394):16:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) and 16:00.0 FireWire (IEEE 1394): NEC Corporation uPD72874 [Firewarden] IEEE1394a OHCI 1.1 Link/3-port PHY Controller (rev 01) When I plug in the VIA card, syslog says: Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744121] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744155] pci 0000:16:00.0: [1106:3044] type 00 class 0x0c0010 Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744202] pci 0000:16:00.0: reg 0x14: [mem 0x82100090-0x8210009f] Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744234] pci 0000:16:00.0: reg 0x1c: [mem 0x00000010-0x0000001f] Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744513] pci 0000:16:00.0: BAR 1: assigned [mem 0x84000000-0x8400000f] Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744527] pci 0000:16:00.0: BAR 1: error updating (0x84000000 != 0x3100010) Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744537] pci 0000:16:00.0: BAR 3: assigned [mem 0x84000010-0x8400001f] Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744550] pci 0000:16:00.0: BAR 3: error updating (0x84000010 != 0x000010) Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744570] pci 0000:16:00.0: cache line size of 64 is not supported Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744675] firewire_ohci 0000:16:00.0: enabling device (0000 -> 0002) Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744811] firewire_ohci 0000:16:00.0: invalid MMIO resource The last row looks like it is a no go so let's try the NEC one. Syslog: Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.548123] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554732] pci 0000:16:00.0: [1033:00f2] type 00 class 0x0c0010 Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554775] pci 0000:16:00.0: reg 0x10: [mem 0x00000000-0x00000fff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554799] pci 0000:16:00.0: reg 0x14: [mem 0x00000000-0x000000ff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554818] pci 0000:16:00.0: reg 0x18: [mem 0x00000000-0x000000ff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554936] pci 0000:16:00.0: supports D1 D2 Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554942] pci 0000:16:00.0: PME# supported from D0 D1 D2 D3hot Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.556428] pci 0000:16:00.0: BAR 0: assigned [mem 0x84000000-0x84000fff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.556445] pci 0000:16:00.0: BAR 1: assigned [mem 0x84001000-0x840010ff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.556459] pci 0000:16:00.0: BAR 2: assigned [mem 0x84001100-0x840011ff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.556598] firewire_ohci 0000:16:00.0: enabling device (0000 -> 0002) Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.612169] firewire_ohci 0000:16:00.0: added OHCI v1.10 device as card 6, 4 IR + 4 IT contexts, quirks 0x1 Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1401.112354] firewire_core 0000:16:00.0: created device fw0: GUID 0000000000000000, S400 So far so good. Now let's plug in Canon HV30 and switch it on. dvgrab -i Error: no camera exists Let's try Ubuntu studio control to enable raw 1394 access. Still no camera. Eject & replug the PCMCIA card - oops... no changes shown in syslog anymore.... What should I try next? |
From: Stefan R. <st...@s5...> - 2015-02-03 22:13:33
|
On Jan 26 Magnus La wrote: [...] > I've collected three logs: > > * The actual serial output of the serial console (the verbose firewire+scsi logs are printed to stdout so they there are present here as well). > http://pastebin.com/E91YHVww > > * The output of dmesg (very similar to the log above, but included if I've missed something). > http://pastebin.com/2UVufJnu > > * The contents of /var/log/messages (not much different from dmesg, but with timestamps and what not) > http://pastebin.com/1L69V9yJ > > > What the logs describe: > A system boot followed by theese commands to enable verbose logging: > # echo -1 > /proc/sys/dev/scsi/logging_level > # echo -1 > /sys/module/firewire_ohci/parameters/debug > Then I attach a firewire hard-drive. > > One of the very last lines (present in all logs above) seems to be of interest: > "scsi scan: INQUIRY failed with code 0x20000" > though I can't find that error code (but I'm not sure where to look either). Thanks. I have yet to examine these logs in detail. For now, I am noting the following to bits of info: - It's a 32bits ARM host, hence PAGE_SIZE is 4k. (We had an open issue with hosts with larger page size, https://bugzilla.kernel.org/show_bug.cgi?id=12725, but this is from the looks of it unrelated to your issue.) - From your pastebin 1L69V9yJ, I gathered the following contents of the FireWire HDD's Configuration ROM register. There is nothing suspicious sticking out. It seems to be an OXFW900 based device, although one cannot be totally sure just from looking at what the firmware puts into Configuration ROM. ROM header and bus information block ----------------------------------------------------------------- 400 043a33e8 bus_info_length 4, crc_length 58, crc 13288 (should be 53453) 404 31333934 bus_name "1394" 408 00ff5000 irmc 0, cmc 0, isc 0, bmc 0, cyc_clk_acc 255, max_rec 5 (64) 40c 0030e0f5 company_id 0030e0 | OXFORD SEMICONDUCTOR LTD. 410 e0100a94 device_id f5e0100a94 | EUI-64 0030e0f5e0100a94 root directory ----------------------------------------------------------------- 414 0006496e directory_length 6, crc 18798 418 0c0083c0 node capabilities per IEEE 1394 41c 030030e0 vendor: OXFORD SEMICONDUCTOR LTD. 420 81000014 --> descriptor leaf at 470 424 0400f900 hardware version 428 8100001d --> descriptor leaf at 49c 42c d1000001 --> unit directory at 430 unit directory at 430 ----------------------------------------------------------------- 430 000cf19a directory_length 12, crc 61850 434 1200609e specifier id: INCITS 438 13010483 version: SBP-2 43c 3c000137 SBP-2 firmware revision 000137 440 5400c000 --> SBP-2 management agent CSR at fffff0030000 444 3a003c08 SBP-2 unit char.: mgt_ORB_timeout 30s, ORB_size 8 quadlets 448 3800609e SBP-2 command set spec id: INCITS 44c 390104d8 SBP-2 command set: SCSI Primary Commands 2 and related standards 450 3b000000 SBP-2 command set revision 454 3d000003 SBP-2 reconnect timeout: max_reconnect_hold 4s 458 144e0000 SBP-2 logical unit number: ordered 1, type RBC, lun 0000 45c 17000001 model 460 81000015 --> descriptor leaf at 4b4 descriptor leaf at 470 ----------------------------------------------------------------- 470 000aadc5 leaf_length 10, crc 44485 474 00000000 textual descriptor 478 00000000 minimal ASCII 47c 4f78666f "Oxfo" 480 72642053 "rd S" 484 656d6963 "emic" 488 6f6e6475 "ondu" 48c 63746f72 "ctor" 490 204c7464 " Ltd" 494 2e202020 ". " 498 00000000 descriptor leaf at 49c ----------------------------------------------------------------- 49c 0005a08c leaf_length 5, crc 41100 4a0 00000000 textual descriptor 4a4 00000000 minimal ASCII 4a8 4f584657 "OXFW" 4ac 39303020 "900 " 4b0 00000000 descriptor leaf at 4b4 ----------------------------------------------------------------- 4b4 00090d79 leaf_length 9, crc 3449 4b8 00000000 textual descriptor 4bc 00000000 minimal ASCII 4c0 4f58464f "OXFO" 4c4 52442049 "RD I" 4c8 44452044 "DE D" 4cc 65766963 "evic" 4d0 65204c55 "e LU" 4d4 4e203020 "N 0 " 4d8 00000000 -- Stefan Richter -=====-===== --=- ---== http://arcgraph.de/sr/ |
From: Magnus La <mag...@in...> - 2015-01-26 19:24:12
|
Thanks! > However, I wonder why there is no message from the SCSI subsystem, not > even anything about failed SCSI requests. Did you filter the log through > grep or something like that? If so, please provide a full log with > messages from any and all kernel subsystems, even if they seem totally > unrelated. Best would be a kernel log beginning from actual boot. Don't > remove anything, except lines which you can't expose for privacy reasons. They were unfiltered but I hadn't explicitly enabled SCSI logging which might explain the lack of SCSI messages... This time I enabled it with "echo -1 > /proc/sys/dev/scsi/logging_level". As for other logs: # ls /var/log/ Xorg.0.log messages Xsession.log wtmp boot xinput_calibrator.pointercal.log dmesg The only logs in /var/log that seems of interest is messages and dmesg, but the dmesg file contains only about the first half of what executing dmesg actually returns so I'm not sure what its use is. Hope I haven't missed anything. I've collected three logs: * The actual serial output of the serial console (the verbose firewire+scsi logs are printed to stdout so they there are present here as well). http://pastebin.com/E91YHVww * The output of dmesg (very similar to the log above, but included if I've missed something). http://pastebin.com/2UVufJnu * The contents of /var/log/messages (not much different from dmesg, but with timestamps and what not) http://pastebin.com/1L69V9yJ What the logs describe: A system boot followed by theese commands to enable verbose logging: # echo -1 > /proc/sys/dev/scsi/logging_level # echo -1 > /sys/module/firewire_ohci/parameters/debug Then I attach a firewire hard-drive. One of the very last lines (present in all logs above) seems to be of interest: "scsi scan: INQUIRY failed with code 0x20000" though I can't find that error code (but I'm not sure where to look either). Regards, Magnus ____________________________________________________________ FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more! |
From: Stefan R. <st...@s5...> - 2015-01-24 21:18:32
|
On Jan 23 Magnus La wrote: > The system itself is a ARM board running the Dizzy release of Yocto linux. I suppose you discovered a bug of the 1394 + scsi stack of drivers in conjunction with that ARM platform. > The PCI-e firewire controller seems to be this card (PCI-E, firewire 800, TI chipset): http://www.syba.com/index.php?controller=Product&action=Info&Id=995 > > Linux nitrogen6x 3.10.17-1.0.2_ga+yocto+g0d7db21 #1 SMP Tue Dec 9 15:15:03 CET 2014 armv7l GNU/Linux > > # lspci > 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) > 01:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] (rev 01) > 02:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) XIO2213A/B are generally rather good for SBP-2 I/O. > # lspci -vv | grep firewire > Kernel driver in use: firewire_ohci > > When a firewire drive (I've tried several with the same results) is connected the following information is logged: > firewire_core 0000:02:00.0: rediscovered device fw0 > firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 > firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 > scsi1 : SBP-2 IEEE-1394 > firewire_core 0000:02:00.0: created device fw1: GUID 0030e0f5e0100a94, S400 > firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > > (I tried the same but when enabling debug output via "echo -1 > /sys/module/firewire_ohci/parameters/debug", the log is a bit verbose so I posted it here: http://pastebin.com/skm6ZBYw) [...] The stock kernel log shows that Self-ID reception DMA, request transmit DMA, response reception DMA (which are needed to get the disk probed by firewire-core), physical response DMA, and request reception DMA (which together with the former DMAs are need for firewire-sbp2 to perform SBP-2 transactions work as they are intended to work. The verbose kernel log additionally shows a few more SBP-2 transactions happening after the log in management transaction succeeded. Those subsequent transactions should be ones issued by scsi core, notably SCSI Inquiry, and then read requests to discover the medium size and the contents of the partition table (if present). However, I wonder why there is no message from the SCSI subsystem, not even anything about failed SCSI requests. Did you filter the log through grep or something like that? If so, please provide a full log with messages from any and all kernel subsystems, even if they seem totally unrelated. Best would be a kernel log beginning from actual boot. Don't remove anything, except lines which you can't expose for privacy reasons. -- Stefan Richter -=====-===== ---= ==--- http://arcgraph.de/sr/ |
From: Magnus La <mag...@in...> - 2015-01-23 11:13:29
|
Hi, I'm having issues with recognizing firewire harddrives properly and especially when adding them post-boot. Some background: The system itself is a ARM board running the Dizzy release of Yocto linux. The PCI-e firewire controller seems to be this card (PCI-E, firewire 800, TI chipset): http://www.syba.com/index.php?controller=Product&action=Info&Id=995 # uname -a Linux nitrogen6x 3.10.17-1.0.2_ga+yocto+g0d7db21 #1 SMP Tue Dec 9 15:15:03 CET 2014 armv7l GNU/Linux # lspci 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) 01:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] (rev 01) 02:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) # lspci -vv | grep firewire Kernel driver in use: firewire_ohci When a firewire drive (I've tried several with the same results) is connected the following information is logged: firewire_core 0000:02:00.0: rediscovered device fw0 firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 scsi1 : SBP-2 IEEE-1394 firewire_core 0000:02:00.0: created device fw1: GUID 0030e0f5e0100a94, S400 firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) (I tried the same but when enabling debug output via "echo -1 > /sys/module/firewire_ohci/parameters/debug", the log is a bit verbose so I posted it here: http://pastebin.com/skm6ZBYw) This is consistent and always "works", but I'm unable/unsure how to actually use the drive in this state. My end goal is getting hot-swap to work but if I boot the system with a drive connected it will, sometimes (usually anything up to twenty reboots are required before it succeeds), get properly connected. It shows up as a /dev/sdX device and I can read/write to it as usual. When that succeeds the following is logged: # dmesg | grep -e firewire -e 1394 -e sda -e scsi [ 1.791842] scsi0 : ahci_platform [ 1.873718] firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x2 [ 2.373746] firewire_core 0000:02:00.0: created device fw0: GUID 7856341200000178, S800 [ 2.373835] firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 [ 5.394598] scsi1 : SBP-2 IEEE-1394 [ 5.397122] firewire_core 0000:02:00.0: created device fw1: GUID 0030e0f5e0100a94, S400 [ 5.596918] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) [ 5.613294] scsi 1:0:0:0: Direct-Access-RBC WDC WD80 0BB-00FRA0 PQ: 0 ANSI: 4 [ 5.638077] sd 1:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [ 5.638478] sd 1:0:0:0: [sda] Write Protect is off [ 5.638485] sd 1:0:0:0: [sda] Mode Sense: 11 00 00 00 [ 5.640037] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.671205] sda: unknown partition table [ 5.687840] sd 1:0:0:0: [sda] Attached SCSI disk (the unknown partition table message is expected, since there is none on this particular drive) Only once have I been able to get a drive properly connected using hot-swap and that was when I was adding a second drive, then the first drive that was added much earlier suddenly got recognized. Though this is not something that I've been able to replicate despite many attempts. Also the number of reboots required to get it to work when the drive is connected during the boot process is of course also quite unsettling. To verify that the controller card wasn't damaged I've tried it on a x86_64 PC with a live USB stick running ubuntu 12.04 LTS and it worked right of the box with hot-swap and everything. Perhaps a timing issue but I really have no clue how to proceed from this. Any pointers are greatly appreciated. ____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium |
From: Daniel R. <dro...@fu...> - 2014-12-18 19:59:25
|
On Thu, Dec 18, 2014 at 7:13 AM, Clemens Ladisch <cl...@la...> wrote: > The following would duplicate the channels to both pairs, which, in > theory, should then work with both PCM and DSD: > > pcm.dup2 { > type route > slave.pcm "hw:1" > ttable [ > [ 1 0 1 0 ] > [ 0 1 0 1 ] > ] > } The first snippet, when added to /root/.asoundrc, causes aplay -L to fail with: *** Error in `aplay': free(): invalid pointer: 0x000000000191a7b0 *** I am not sure how to use these devices with mpd for testing. Let me know what to do. -Daniel |
From: Clemens L. <cl...@la...> - 2014-12-18 14:13:59
|
(sorry for the delay) Daniel Robbins wrote: > On Fri, Dec 12, 2014 at 2:53 PM, Clemens Ladisch <cl...@la...> wrote: >> What are the contents of /proc/asound/card1/dice? > > After attempting to play a DOP file (was previously successfully > playing a 24/96 PCM file), it looks like this: > > # cat /proc/asound/card1/dice > ... > clock select: arx1 176400 The device was told to synchronize to the stream from the PC, ... > status: unlocked 96000 ... but no stream was actually sent, so it is still at 96 kHz. > rx 0: > audio channels: 4 > names: ANALOG L\ANALOG R\DSD1281\DSD1282\\ At 96 kHz (and 88.2 kHz), it wants exactly four channels. And these channel names look somewhat suspicious. Try playing DSD to the following device, which routes its two channels to the last two channels of the device: pcm.last2 { type route slave.pcm "hw:1" ttable [ [ 0 0 1 0 ] [ 0 0 0 1 ] ] } The following would duplicate the channels to both pairs, which, in theory, should then work with both PCM and DSD: pcm.dup2 { type route slave.pcm "hw:1" ttable [ [ 1 0 1 0 ] [ 0 1 0 1 ] ] } Regards, Clemens |
From: Happy M. <ha...@pe...> - 2014-12-17 11:33:48
|
:-) |
From: Daniel R. <dro...@fu...> - 2014-12-12 22:02:19
|
On Fri, Dec 12, 2014 at 2:53 PM, Clemens Ladisch <cl...@la...> wrote: > What are the contents of /proc/asound/card1/dice? After attempting to play a DOP file (was previously successfully playing a 24/96 PCM file), it looks like this: node ~ # cat /proc/asound/card1/dice sections: global: offset 10, size 95 tx: offset 105, size 142 rx: offset 247, size 282 ext_sync: offset 529, size 4 unused2: offset 0, size 0 global: owner: ffc1:000100000000 notification: 00000050 nick name: Stereo192-DSD DAC clock select: arx1 176400 enable: 0 status: unlocked 96000 ext status: 00000000 sample rate: 96000 version: 1.0.12.0 clock caps: 44100 48000 88200 96000 176400 192000 aes2 aes3 aes4 adat wc arx1 clock source names: Unused\AES\TOSLINK\SPDIF\Unused\ADAT\Unused\Stereo192DAC\Unused\Unused\Unused\Unused\Unused\\ tx 0: iso channel: -1 audio channels: 8 midi ports: 0 speed: S400 names: AES L\AES R\TOSLINK L\TOSLINK R\SPDIF L\SPDIF R\ADAT0\ADAT1\\ ac3 caps: 00000000 ac3 enable: 00000000 rx 0: iso channel: -1 sequence start: 0 audio channels: 4 midi ports: 0 names: ANALOG L\ANALOG R\DSD1281\DSD1282\\ ac3 caps: 00000000 ac3 enable: 00000000 ext status: clock source: arx1 locked: 1 rate: 96000 adat user data: - Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-12 21:54:15
|
Daniel Robbins wrote: > On Fri, Dec 12, 2014 at 12:46 PM, Clemens Ladisch <cl...@la...> wrote: >> And you DoP stuff uses two channels? That would be the problem then. > > Yes, it's a two-channel DAC. This "works": > > # aplay -D plughw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero > Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 176400 Hz, Stereo > > This appears to be the relevant code in mpd relating to setting up > alsa for DOP. It appears that it is trying to use S24_P32 rather than > S32 -- could this be the issue? No, S32 is explicitly allowed. The issue is that the number of channels changes. What are the contents of /proc/asound/card1/dice? Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-12 20:33:13
|
On Fri, Dec 12, 2014 at 12:46 PM, Clemens Ladisch <cl...@la...> wrote: > And you DoP stuff uses two channels? That would be the problem then. Yes, it's a two-channel DAC. This "works": node ~ # aplay -D plughw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 176400 Hz, Stereo ^CAborted by signal Interrupt... aplay: pcm_write:1939: write error: Interrupted system call node ~ # This appears to be the relevant code in mpd relating to setting up alsa for DOP. It appears that it is trying to use S24_P32 rather than S32 -- could this be the issue? alsa_setup_dop(AlsaOutput *ad, const AudioFormat audio_format, bool *shift8_r, bool *packed_r, bool *reverse_endian_r, Error &error) { assert(ad->dop); assert(audio_format.format == SampleFormat::DSD); /* pass 24 bit to alsa_setup() */ AudioFormat dop_format = audio_format; dop_format.format = SampleFormat::S24_P32; dop_format.sample_rate /= 2; const AudioFormat check = dop_format; if (!alsa_setup(ad, dop_format, packed_r, reverse_endian_r, error)) return false; /* if the device allows only 32 bit, shift all DoP samples left by 8 bit and leave the lower 8 bit cleared; the DSD-over-USB documentation does not specify whether this is legal, but there is anecdotical evidence that this is possible (and the only option for some devices) */ *shift8_r = dop_format.format == SampleFormat::S32; if (dop_format.format == SampleFormat::S32) dop_format.format = SampleFormat::S24_P32; if (dop_format != check) { /* no bit-perfect playback, which is required for DSD over USB */ error.Format(alsa_output_domain, "Failed to configure DSD-over-PCM on ALSA device \"%s\"", alsa_device(ad)); delete[] ad->silence; return false; } return true; } Regards, Daniel |