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