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