From owner-freebsd-firewire@FreeBSD.ORG Sun Dec 28 22:15:37 2008 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D718A1065674; Sun, 28 Dec 2008 22:15:37 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id B61798FC13; Sun, 28 Dec 2008 22:15:37 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 3032A1A90E1; Sun, 28 Dec 2008 15:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZX7LrKxKJLg; Sun, 28 Dec 2008 15:15:35 -0800 (PST) Received: from [10.47.1.6] (vpn.office.miralink.com [10.0.0.5]) by plato.miralink.com (Postfix) with ESMTP id 6E6271A90B1; Sun, 28 Dec 2008 15:15:35 -0800 (PST) Message-ID: <4957FA88.1000604@miralink.com> Date: Sun, 28 Dec 2008 14:15:36 -0800 From: Sean Bruno User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Dieter References: <200812260623.GAA20643@sopwith.solgatos.com> In-Reply-To: <200812260623.GAA20643@sopwith.solgatos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-firewire@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2008 22:15:37 -0000 Dieter wrote: >>> I confirmed that spl's are complete no-ops since rel 5. So, you want >>> to ignore >>> them as they are just markers now where locking should be implemented. >>> > > I hunted down the spl code, and you're right. Wow, I wonder how drivers > still using spl calls work at all? > > I believe that the spl() calls are just left there as a hint where locking should be. As far as I understand, we need to pay attention to the mutex locks. >> is to real behavior, but /var/log/messages has a tendency to get garbled >> like this: >> >> Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset >> Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset >> Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, >> CYCLEMASTER mode >> Dec 22 16:00:18 home-test kernel: firewi >> Dec 22 16:00:18 home-test kernel: re1: >> Dec 22 16:00:18 home-test kernel: 1 n >> Dec 22 16:00:18 home-test kernel: odes >> Dec 22 16:00:18 home-test kernel: , ma >> Dec 22 16:00:18 home-test kernel: xhop >> Dec 22 16:00:18 home-test kernel: <= >> Dec 22 16:00:18 home-test kernel: 0, c >> Dec 22 16:00:18 home-test kernel: able >> > > Do the lines get folded on the console, or only in /var/log/messages? > As far as I can see, the console messages are fine. It's only the messages that get garbled. Sean From owner-freebsd-firewire@FreeBSD.ORG Mon Dec 29 05:51:21 2008 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 140F41065686; Mon, 29 Dec 2008 05:51:21 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (pool-71-117-207-61.ptldor.fios.verizon.net [71.117.207.61]) by mx1.freebsd.org (Postfix) with ESMTP id 1F91C8FC17; Mon, 29 Dec 2008 05:51:19 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: by sopwith.solgatos.com (Postfix, from userid 66) id DDE3DB650; Sun, 28 Dec 2008 21:44:57 -0800 (PST) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id FAA02342; Mon, 29 Dec 2008 05:49:00 GMT Message-Id: <200812290549.FAA02342@sopwith.solgatos.com> To: freebsd-firewire@freebsd.org, bug-followup@freebsd.org In-reply-to: Your message of "Sun, 28 Dec 2008 14:15:36 PST." <4957FA88.1000604@miralink.com> Date: Sun, 28 Dec 2008 21:49:00 +0000 From: Dieter Cc: Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 05:51:21 -0000 > >>> I confirmed that spl's are complete no-ops since rel 5. So, you want > >>> to ignore > >>> them as they are just markers now where locking should be implemented. > >>> > > > > I hunted down the spl code, and you're right. Wow, I wonder how drivers > > still using spl calls work at all? > > > > > I believe that the spl() calls are just left there as a hint where > locking should be. > > As far as I understand, we need to pay attention to the mutex locks. I'll rephrase my question. In the old days, locking was done with spl. The new way is with mutex. But with the spl calls being replaced with noops, and as far as I can tell the driver is not using mutex, there doesn't appear to be any locking. So the driver can step on itself. > >> is to real behavior, but /var/log/messages has a tendency to get garbled > >> like this: > >> > >> Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset > >> Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset > >> Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, > >> CYCLEMASTER mode > >> Dec 22 16:00:18 home-test kernel: firewi > >> Dec 22 16:00:18 home-test kernel: re1: > >> Dec 22 16:00:18 home-test kernel: 1 n > >> Dec 22 16:00:18 home-test kernel: odes > >> Dec 22 16:00:18 home-test kernel: , ma > >> Dec 22 16:00:18 home-test kernel: xhop > >> Dec 22 16:00:18 home-test kernel: <= > >> Dec 22 16:00:18 home-test kernel: 0, c > >> Dec 22 16:00:18 home-test kernel: able > >> > > > > Do the lines get folded on the console, or only in /var/log/messages? > > > > As far as I can see, the console messages are fine. It's only the > messages that get > garbled. Perhaps an artifact of syslogd? From owner-freebsd-firewire@FreeBSD.ORG Mon Dec 29 06:22:27 2008 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACEF9106564A; Mon, 29 Dec 2008 06:22:27 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8220C8FC0C; Mon, 29 Dec 2008 06:22:27 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 0988E1A90E2; Sun, 28 Dec 2008 23:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUNMFXxcP71i; Sun, 28 Dec 2008 23:22:25 -0800 (PST) Received: from [10.47.1.6] (vpn.office.miralink.com [10.0.0.5]) by plato.miralink.com (Postfix) with ESMTP id 59FA01A90CA; Sun, 28 Dec 2008 23:22:25 -0800 (PST) Message-ID: <49586CA2.60907@miralink.com> Date: Sun, 28 Dec 2008 22:22:26 -0800 From: Sean Bruno User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Dieter References: <200812290549.FAA02342@sopwith.solgatos.com> In-Reply-To: <200812290549.FAA02342@sopwith.solgatos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-firewire@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 06:22:27 -0000 Dieter wrote: >>> >>> >>> >> I believe that the spl() calls are just left there as a hint where >> locking should be. >> >> As far as I understand, we need to pay attention to the mutex locks. >> > > I'll rephrase my question. In the old days, locking was done with spl. > The new way is with mutex. But with the spl calls being replaced with > noops, and as far as I can tell the driver is not using mutex, there > doesn't appear to be any locking. So the driver can step on itself. > > Well, there is locking around a couple of mutex's via FW_GLOCK(). It appears that the locking is not robust, and that is one of the issues that I am looking into right now. > >>>> is to real behavior, but /var/log/messages has a tendency to get garbled >>>> like this: >>>> >>>> Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset >>>> Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset >>>> Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, >>>> CYCLEMASTER mode >>>> Dec 22 16:00:18 home-test kernel: firewi >>>> Dec 22 16:00:18 home-test kernel: re1: >>>> Dec 22 16:00:18 home-test kernel: 1 n >>>> Dec 22 16:00:18 home-test kernel: odes >>>> Dec 22 16:00:18 home-test kernel: , ma >>>> Dec 22 16:00:18 home-test kernel: xhop >>>> Dec 22 16:00:18 home-test kernel: <= >>>> Dec 22 16:00:18 home-test kernel: 0, c >>>> Dec 22 16:00:18 home-test kernel: able >>>> >>>> >>> Do the lines get folded on the console, or only in /var/log/messages? >>> >>> >> As far as I can see, the console messages are fine. It's only the >> messages that get >> garbled. >> > > Perhaps an artifact of syslogd? > I doubt it. I'm working on a patch that improves the locking a bit and does some other "gross" things to try and keep things from flying apart. I've SEEN this behaviour in my implementations with sbp_targ and couldn't pin it down. Scott Long gave me a couple of pointers this evening, but I'm still working on locking down the taskqueues and some of the callback_handlers. There are some bad things going on specifically during initialization that are pre-empting normal operation. Sean From owner-freebsd-firewire@FreeBSD.ORG Mon Dec 29 07:33:24 2008 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D432106564A; Mon, 29 Dec 2008 07:33:24 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (pool-71-117-207-61.ptldor.fios.verizon.net [71.117.207.61]) by mx1.freebsd.org (Postfix) with ESMTP id BBF2F8FC17; Mon, 29 Dec 2008 07:33:23 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: by sopwith.solgatos.com (Postfix, from userid 66) id A330DB650; Sun, 28 Dec 2008 23:26:57 -0800 (PST) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id HAA23593; Mon, 29 Dec 2008 07:30:55 GMT Message-Id: <200812290730.HAA23593@sopwith.solgatos.com> To: freebsd-firewire@freebsd.org, bug-followup@freebsd.org In-reply-to: Your message of "Sun, 28 Dec 2008 22:22:26 PST." <49586CA2.60907@miralink.com> Date: Sun, 28 Dec 2008 23:30:55 +0000 From: Dieter Cc: Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 07:33:24 -0000 > > I'll rephrase my question. In the old days, locking was done with spl. > > The new way is with mutex. But with the spl calls being replaced with > > noops, and as far as I can tell the driver is not using mutex, there > > doesn't appear to be any locking. So the driver can step on itself. > > > Well, there is locking around a couple of mutex's via FW_GLOCK(). Ah, I wasn't grepping for the right string. So there *is* mutex locking. Although the lingering spl calls are still troubling. From owner-freebsd-firewire@FreeBSD.ORG Mon Dec 29 11:06:54 2008 Return-Path: Delivered-To: freebsd-firewire@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ED411065678 for ; Mon, 29 Dec 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E055D8FC12 for ; Mon, 29 Dec 2008 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBTB6rQa024420 for ; Mon, 29 Dec 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBTB6rmZ024416 for freebsd-firewire@FreeBSD.org; Mon, 29 Dec 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Dec 2008 11:06:53 GMT Message-Id: <200812291106.mBTB6rmZ024416@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-firewire@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 11:06:54 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 2 problems total.