Re: Harddrive(s) not properly recognized

[Eric L. <ela...@te...>]

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