From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758960AbZBKAd5 (ORCPT ); Tue, 10 Feb 2009 19:33:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757616AbZBKA2V (ORCPT ); Tue, 10 Feb 2009 19:28:21 -0500 Received: from kroah.org ([198.145.64.141]:51125 "EHLO coco.kroah.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757552AbZBKA2S (ORCPT ); Tue, 10 Feb 2009 19:28:18 -0500 Date: Tue, 10 Feb 2009 16:24:50 -0800 From: Greg KH To: linux-kernel@vger.kernel.org, stable@kernel.org Cc: Justin Forbes , Zwane Mwaikambo , "Theodore Ts'o" , Randy Dunlap , Dave Jones , Chuck Wolber , Chris Wedgwood , Michael Krufky , Chuck Ebbert , Domenico Andreoli , Willy Tarreau , Rodrigo Rubira Branco , Jake Edge , Eugene Teo , torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Stefan Richter Subject: [patch 17/56] ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others Message-ID: <20090211002450.GR14660@kroah.com> References: <20090211001439.873435357@mini.kroah.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch" In-Reply-To: <20090211002328.GA14660@kroah.com> User-Agent: Mutt/1.5.16 (2007-06-09) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2.6.27-stable review patch. If anyone has any objections, please let us know. ------------------ From: Stefan Richter Commit 64c634ef83991b390ec0503e61f16efb0ba3c60b upstream. Camcorders have a tendency to fail read requests to their config ROM and write request to their FCP command register with ack_busy_X. This has become a problem with newer kernels and especially Panasonic camcorders, causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently logs "send oops"; kino reports loss of AV/C control. I suspect that lower CPU scheduling latencies in newer kernels made this issue more prominent now. According to https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 this can be fixed by configuring the FireWire controller for more hardware retries for request transmission; these retries are evidently more successful than libavc1394's own retry loop (typically 3 tries on top of hardware retries). Presumably the same issue has been reported at https://bugzilla.redhat.com/show_bug.cgi?id=449252 and https://bugzilla.redhat.com/show_bug.cgi?id=477279 . Tested-by: Mathias Beilstein Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman --- drivers/ieee1394/ohci1394.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/ieee1394/ohci1394.h +++ b/drivers/ieee1394/ohci1394.h @@ -26,7 +26,7 @@ #define OHCI1394_DRIVER_NAME "ohci1394" -#define OHCI1394_MAX_AT_REQ_RETRIES 0x2 +#define OHCI1394_MAX_AT_REQ_RETRIES 0xf #define OHCI1394_MAX_AT_RESP_RETRIES 0x2 #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8 #define OHCI1394_MAX_SELF_ID_ERRORS 16