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