Re: Harddrive(s) not properly recognized
Brought to you by:
aeb,
bencollins
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/ |