From owner-freebsd-firewire@FreeBSD.ORG Thu Apr 16 20:21:01 2009 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 790A91065793; Thu, 16 Apr 2009 20:21:01 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 5051C8FC23; Thu, 16 Apr 2009 20:20:59 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n3GKKi7g071836; Thu, 16 Apr 2009 22:20:45 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <49E7931C.8050603@fgznet.ch> Date: Thu, 16 Apr 2009 22:20:44 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sean Bruno References: <1239382529.21481.7.camel@localhost.localdomain> <20090411154000.GG8143@alchemy.franken.de> <1239600457.24831.8.camel@localhost.localdomain> <49E2F2FA.6000204@fgznet.ch> <1239639423.24831.85.camel@localhost.localdomain> <20090413170537.GI8143@alchemy.franken.de> <1239643406.24831.95.camel@localhost.localdomain> <20090413173528.GJ8143@alchemy.franken.de> <1239646889.24831.135.camel@localhost.localdomain> <20090414184741.GK8143@alchemy.franken.de> <49E4DF9F.1090804@fgznet.ch> <1239814413.15474.2.camel@localhost.localdomain> <49E61B4D.1050209@fgznet.ch> <1239819547.15474.5.camel@localhost.localdomain> <49E633C7.9030909@fgznet.ch> <1239826803.15474.48.camel@localhost.localdomain> In-Reply-To: <1239826803.15474.48.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-firewire , scottl , Marius Strobl Subject: Re: fwochi.c and bus_space_barrier() 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: Thu, 16 Apr 2009 20:21:06 -0000 Sean Bruno wrote: >>> You may want to retry several times. Like you pointed out in earlier >>> posts, this issue seems to be a race condition. >> Heh, now I remember, I did not speak about a race condition, but about a >> timing issue. >> >> If I leave the printfs away, it panics here. >> >> for (lps = 0, lps_counter = 0; !lps && lps_counter < 3; lps_counter++) { >> lps = (OREAD(sc, OHCI_HCCCTL) & OHCI_HCC_LPS); >> if (!lps) { >> pause("fwlps", (50 * hz + 999) / 1000); >> device_printf(dev, "lps not set, >> attempt(%d)\n", lps_cou >> nter); >> } /* else >> device_printf(dev, "lps(%0x) set\n", lps);*/ >> } >> >> In my case the lps is not NULL, so we print something in the first run >> of the loop, this print statement is enough 'time' for the card to come >> up. If we leave the printf away, it is not enough time to come up for >> the card. Panic. >> >> This was the same thing I reported, adding a printf statement at the >> beginning of fwphy_rddata cures my panic. >> >> So I'd suggest to leave the lps test away and add always a pause(9), or >> does this cause headache on other archs? >> >> Thanks, >> Andreas >> > > > Ok, I think I've finally caught up to Marius (at least in this > situation). > > The *ACTUAL* issue is that fwochi_probe_phy() code isn't properly > handling the transition state from LPS==0 to LPS==1. In this period of > time, the internal SCLK on the firewire board may have not started yet. > There can be a period of time between the value of LPS==1 and the SCLK > actually starting. > > fwphy_rddata() appears to be *trying* to deal with this, but is > obviously failing. > > So "lps" has been set, but the PHY is not up yet. In order to access > PHY resources, we have to wait for SCLK to start(OHCI spec v1.1 table > 6.1). > > I believe your error is defined in the OHCI spec, Appendix A.6, PCI Bus > Errors. The bus error is supposed to happen! :) The driver just isn't > handling the error case properly. > > The proper fix is to handle the ERROR according to spec. I will work on > a proper solution this weekend. In the meantime, here is a patch to get > you by based on the pause() mechanism. > > Sorry for the slow progress here, I appreciate your testing Andreas! Sean, no need to excuse, I'm busy with a lot of things. My day job, well, my day and night job, only permits some hours in the night to play around with this cool OS. For me it is a pleasure to help out testing here. It is a possibility for me to learn more about fbsd and its development process. If I can help more, feed me with code to test. I hope I'll get the experience to push out some patches of my own in the future :) Regards, Andreas