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