On 03/13/2014 09:59 AM, Stefan Richter wrote:
On Mar 13 Peter Hurley wrote:
With patch applied, happened last night but I just noticed this am:
Mar 12 20:47:40 thor kernel: [ 2.516017] firewire_ohci 0000:01:00.0: failed to read phy reg 1
[...]
Mar 12 20:47:40 thor kernel: [ 2.516175] [<ffffffffa003bcd9>] ohci_read_phy_reg+0x39/0x60 [firewire_ohci]
Mar 12 20:47:40 thor kernel: [ 2.516187] [<ffffffffa000f30f>] fw_send_phy_config+0xbf/0xe0 [firewire_core]
Mar 12 20:47:40 thor kernel: [ 2.516198] [<ffffffffa000752c>] br_work+0x6c/0xe0 [firewire_core]
[...]
Mar 12 20:47:40 thor kernel: [ 3.316012] firewire_ohci 0000:01:00.0: failed to read phy reg 5
[...]
Mar 12 20:47:40 thor kernel: [ 3.320426] [<ffffffffa003bc6d>] ohci_update_phy_reg+0x4d/0x80 [firewire_ohci]
Mar 12 20:47:40 thor kernel: [ 3.320927] [<ffffffffa000754f>] br_work+0x8f/0xe0 [firewire_core]
[...]
0000:01:00.0 is the very same FW643-e2 [11c1:5901] (rev 08) as in the
changelog of commit bd972688eb24, right?
Yes.
Incidentally, the mailman brought me a dual FW643-e2 card just yesterday
(IOI FWBX2-PCIE1XE220 alias Delock 89208). I will try to reproduce the
issue as time permits. I take it from your previous messages that it is
not quite sure whether or not this is influenced by a long pause between
LPS-enable and first PHY register access.
I have _never_ observed this failure with either my original patch
which broke FW323 init nor my follow-up patch series which fixed the FW323
init breakage.
Until the proper cure to this rarely occurring problem with FW643-e2 is
found,
Rarely occurring to whom? Non-FW643 rev8 devices?
When I fixed this the first time, the failure was easily repeatable.
With your revert, the failure has returned.
I prefer to have the current fix-by-revert spreading out to the
various stable kernel branches, since it fixes the frequent FW323
initialization failure (which had about 30% chance of occurrence with
CONFIG_HZ=1000).
Ok. I can carry the FW643 rev8 fixes as needed.
--------
I note that the above failing accesses are not the very first ones during
startup of the driver stack. Before them,
ohci.c::configure_1394a_enhancements issues one read_phy_reg to register
2, 0 or 1 read_paged_phy_reg to page 1 register 8, 0 or 1 update_phy_reg
to register 5, then ohci_enable issues one update_phy_reg to register 4,
and then br_work is queued (and either this run of br_work or a later run
of br_work failed).
As I originally reported, the failure is manifested before the update to
phy reg 5 in configure_1394a_enhancements(). A dump of phy reg 5 when
it is read in update_phy_reg() returns the value 0x19 (Watchdog, Pwr_fail,
Timeout).
I intend to lightly instrument ohci_enable() and the phy reg functions
with ftrace to obtain timestamps and register values during initialization.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html