From owner-freebsd-firewire@FreeBSD.ORG Mon Apr 13 11:06:52 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 B84771065673 for ; Mon, 13 Apr 2009 11:06:52 +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 A38AE8FC13 for ; Mon, 13 Apr 2009 11:06:52 +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 n3DB6qI5084925 for ; Mon, 13 Apr 2009 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3DB6qZw084921 for freebsd-firewire@FreeBSD.org; Mon, 13 Apr 2009 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Apr 2009 11:06:52 GMT Message-Id: <200904131106.n3DB6qZw084921@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, 13 Apr 2009 11:06:53 -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 -------------------------------------------------------------------------------- p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 7 problems total. From owner-freebsd-firewire@FreeBSD.ORG Wed Apr 15 16:53:35 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 C6AFD1065676 for ; Wed, 15 Apr 2009 16:53:35 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id 091508FC23 for ; Wed, 15 Apr 2009 16:53:34 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 6376 invoked from network); 15 Apr 2009 09:53:32 -0700 Received: from 069-064-235-060.pdx.net (HELO ?192.168.1.51?) (69.64.235.60) by iron2.pdx.net with SMTP; 15 Apr 2009 09:53:32 -0700 From: Sean Bruno To: Andreas Tobler In-Reply-To: <49E4DF9F.1090804@fgznet.ch> 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> Content-Type: multipart/mixed; boundary="=-Slrhz045rl+zmU4pfCvQ" Date: Wed, 15 Apr 2009 09:53:33 -0700 Message-Id: <1239814413.15474.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 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: Wed, 15 Apr 2009 16:53:36 -0000 --=-Slrhz045rl+zmU4pfCvQ Content-Type: text/plain Content-Transfer-Encoding: 7bit > >> > > > > This looks basically good, but as outlined earlier a driver > > souldn't busy-wait 50ms. Could one of you please test whether > > pause("fwlps", (50 * hz + 999) / 1000) works as a drop-in > > replacement for DELAY(50000) here? > > Works fine here! > > Thanks! > Andreas > > > Ok, time for more testing. A couple of changes here. 1. change busy DELAY() call with pause() 2. test for lps condition before pause(), if not set pause and retry. Sean --=-Slrhz045rl+zmU4pfCvQ Content-Disposition: attachment; filename="fwohci.c.diff" Content-Type: text/x-patch; name="fwohci.c.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit Index: fwohci.c =================================================================== --- fwohci.c (revision 191002) +++ fwohci.c (working copy) @@ -280,7 +280,8 @@ fun = (PHYDEV_WRCMD | (addr << PHYDEV_REGADDR) | (data << PHYDEV_WRDATA)); OWRITE(sc, OHCI_PHYACCESS, fun); - DELAY(100); + bus_space_barrier(sc->bst, sc->bsh, OHCI_PHYACCESS, + 4, BUS_SPACE_BARRIER_WRITE); return(fwphy_rddata( sc, addr)); } @@ -324,11 +325,15 @@ OWRITE(sc, FWOHCI_INTSTATCLR, OHCI_INT_REG_FAIL); fun = PHYDEV_RDCMD | (addr << PHYDEV_REGADDR); OWRITE(sc, OHCI_PHYACCESS, fun); + bus_space_barrier(sc->bst, sc->bsh, OHCI_PHYACCESS, + 4, BUS_SPACE_BARRIER_WRITE); + for ( i = 0 ; i < MAX_RETRY ; i ++ ){ fun = OREAD(sc, OHCI_PHYACCESS); + bus_space_barrier(sc->bst, sc->bsh, OHCI_PHYACCESS, + 4, BUS_SPACE_BARRIER_READ); if ((fun & PHYDEV_RDCMD) == 0 && (fun & PHYDEV_RDDONE) != 0) break; - DELAY(100); } if(i >= MAX_RETRY) { if (firewire_debug) @@ -426,20 +431,43 @@ static int fwohci_probe_phy(struct fwohci_softc *sc, device_t dev) { - uint32_t reg, reg2; + uint32_t lps, reg, reg2; + int lps_counter = 0; int e1394a = 1; -/* - * probe PHY parameters - * 0. to prove PHY version, whether compliance of 1394a. - * 1. to probe maximum speed supported by the PHY and - * number of port supported by core-logic. - * It is not actually available port on your PC . - */ + + /* + * Enable LPS(Link Power Status as per + * section 5.7 of OHCI v1.1 + * This allows PHY communication after + * a hard/soft reset + */ OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_LPS); - DELAY(500); - + bus_space_barrier(sc->bst, sc->bsh, OHCI_HCCCTL, 4, BUS_SPACE_BARRIER_WRITE); + 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_counter); + } else + device_printf(dev, "lps(%0x) set\n", lps); + } + /* + * probe PHY parameters + * 0. to prove PHY version, whether compliance of 1394a. + * 1. to probe maximum speed supported by the PHY and + * number of port supported by core-logic. + * It is not actually available port on your PC . + */ reg = fwphy_rddata(sc, FW_PHY_SPD_REG); + /* + * ref 1394-2000 table 5B-1 + * ref 1394-1995 table J.12 + * If Extended is not set + * Assume 1394-1995 + * If Extended is set + * Assume 1394-2000(1394a) + */ if((reg >> 5) != 7 ){ sc->fc.mode &= ~FWPHYASYST; sc->fc.nport = reg & FW_PHY_NP; @@ -453,12 +481,12 @@ "Phy 1394 only %s, %d ports.\n", linkspeed[sc->fc.speed], sc->fc.nport); }else{ - reg2 = fwphy_rddata(sc, FW_PHY_ESPD_REG); sc->fc.mode |= FWPHYASYST; sc->fc.nport = reg & FW_PHY_NP; + reg2 = fwphy_rddata(sc, FW_PHY_ESPD_REG); sc->fc.speed = (reg2 & FW_PHY_ESPD) >> 5; if (sc->fc.speed > MAX_SPEED) { - device_printf(dev, "invalid speed %d (fixed to %d).\n", + device_printf(dev, "invalid extended speed %d (fixed to %d).\n", sc->fc.speed, MAX_SPEED); sc->fc.speed = MAX_SPEED; } @@ -468,11 +496,7 @@ /* check programPhyEnable */ reg2 = fwphy_rddata(sc, 5); -#if 0 - if (e1394a && (OREAD(sc, OHCI_HCCCTL) & OHCI_HCC_PRPHY)) { -#else /* XXX force to enable 1394a */ if (e1394a) { -#endif if (firewire_debug) device_printf(dev, "Enable 1394a Enhancements\n"); --=-Slrhz045rl+zmU4pfCvQ-- From owner-freebsd-firewire@FreeBSD.ORG Wed Apr 15 17:37:37 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 818061065694; Wed, 15 Apr 2009 17:37:37 +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 15C7D8FC13; Wed, 15 Apr 2009 17:37:36 +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 n3FHbI2Q019024; Wed, 15 Apr 2009 19:37:18 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <49E61B4D.1050209@fgznet.ch> Date: Wed, 15 Apr 2009 19:37:17 +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> In-Reply-To: <1239814413.15474.2.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: Wed, 15 Apr 2009 17:37:38 -0000 Sean Bruno wrote: >>> This looks basically good, but as outlined earlier a driver >>> souldn't busy-wait 50ms. Could one of you please test whether >>> pause("fwlps", (50 * hz + 999) / 1000) works as a drop-in >>> replacement for DELAY(50000) here? >> Works fine here! >> >> Thanks! >> Andreas >> >> >> > > Ok, time for more testing. A couple of changes here. > > 1. change busy DELAY() call with pause() > 2. test for lps condition before pause(), if not set pause and retry. Fine here, but see that there was no pause needed, strange. Andreas FreeBSD 8.0-CURRENT (GENERIC) #3 r191101:191110M: Wed Apr 15 19:21:30 CEST 2009 You have new mail. u60# kldload firewire fwohci0: mem 0x4008000-0x40087ff,0x400c000-0x400ff ff at device 4.0 on pci0 fwohci0: latency timer 24 -> 32. fwohci0: cache size 16 -> 16. fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:10:74:60:00:00:ee:a9 fwohci0: resetting OHCI...done (loop=0) fwohci0: lps(80000) set fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Enable 1394a Enhancements fwohci0: Link S400, max_rec 2048 bytes. fwohci0: BUS_OPT 0xa002 -> 0xf800a002 fwohci0: fwohci_set_intr: 1 firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode node:0 link:1 gap:63 spd:2 con:1 pwr:4 p0:1 p1:1 p2:1 i:1 m:0 firewire0: 1 nodes, maxhop <= 0 capable IRM irm(0) (me) fwohci0: fwohci_set_bus_manager: 0->0 (loop=0) firewire0: bus manager 0 firewire0: fw_phy_config: root_node=-1 gap_count=5 fwohci0: fwohci_start: maxdesc 2 fwohci0: start AT DMA status=0 u60# firewire0: fw_bus_probe:iterate and invalidate all nodes firewire0: fw_explore:found myself node(0) fc->nodeid(0) fc->max_node(0) bus_explore done u60# kldunload firewire firewire0: detached fwohci0: fwohci_set_intr: 0 fwohci0: detached u60# From owner-freebsd-firewire@FreeBSD.ORG Wed Apr 15 18:19:09 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 06773106566B for ; Wed, 15 Apr 2009 18:19:09 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id CF7858FC0A for ; Wed, 15 Apr 2009 18:19:08 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 20169 invoked from network); 15 Apr 2009 11:19:06 -0700 Received: from 069-064-235-060.pdx.net (HELO ?192.168.1.51?) (69.64.235.60) by iron2.pdx.net with SMTP; 15 Apr 2009 11:19:06 -0700 From: Sean Bruno To: Andreas Tobler In-Reply-To: <49E61B4D.1050209@fgznet.ch> 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> Content-Type: text/plain Date: Wed, 15 Apr 2009 11:19:07 -0700 Message-Id: <1239819547.15474.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit 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: Wed, 15 Apr 2009 18:19:09 -0000 On Wed, 2009-04-15 at 19:37 +0200, Andreas Tobler wrote: > Sean Bruno wrote: > >>> This looks basically good, but as outlined earlier a driver > >>> souldn't busy-wait 50ms. Could one of you please test whether > >>> pause("fwlps", (50 * hz + 999) / 1000) works as a drop-in > >>> replacement for DELAY(50000) here? > >> Works fine here! > >> > >> Thanks! > >> Andreas > >> > >> > >> > > > > Ok, time for more testing. A couple of changes here. > > > > 1. change busy DELAY() call with pause() > > 2. test for lps condition before pause(), if not set pause and retry. > > Fine here, but see that there was no pause needed, strange. > > Andreas > > You may want to retry several times. Like you pointed out in earlier posts, this issue seems to be a race condition. > FreeBSD 8.0-CURRENT (GENERIC) #3 r191101:191110M: Wed Apr 15 19:21:30 > CEST 2009 > You have new mail. > u60# kldload firewire > fwohci0: mem > 0x4008000-0x40087ff,0x400c000-0x400ff > ff at device 4.0 on pci0 > fwohci0: latency timer 24 -> 32. > fwohci0: cache size 16 -> 16. > fwohci0: [ITHREAD] > fwohci0: OHCI version 1.0 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:10:74:60:00:00:ee:a9 > fwohci0: resetting OHCI...done (loop=0) > fwohci0: lps(80000) set > fwohci0: Phy 1394a available S400, 3 ports. > fwohci0: Enable 1394a Enhancements > fwohci0: Link S400, max_rec 2048 bytes. > fwohci0: BUS_OPT 0xa002 -> 0xf800a002 > fwohci0: fwohci_set_intr: 1 > firewire0: on fwohci0 > fwohci0: Initiate bus reset > fwohci0: fwohci_intr_core: BUS reset > fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, > CYCLEMASTER mode > node:0 link:1 gap:63 spd:2 con:1 pwr:4 p0:1 p1:1 p2:1 i:1 m:0 > firewire0: 1 nodes, maxhop <= 0 capable IRM irm(0) (me) > fwohci0: fwohci_set_bus_manager: 0->0 (loop=0) > firewire0: bus manager 0 > firewire0: fw_phy_config: root_node=-1 gap_count=5 > fwohci0: fwohci_start: maxdesc 2 > fwohci0: start AT DMA status=0 > u60# firewire0: fw_bus_probe:iterate and invalidate all nodes > firewire0: fw_explore:found myself node(0) fc->nodeid(0) fc->max_node(0) > bus_explore done > > u60# kldunload firewire > firewire0: detached > fwohci0: fwohci_set_intr: 0 > fwohci0: detached > u60# Thanks for testing this. I will see if we can close a PR regarding unloading the firewire module. Sean From owner-freebsd-firewire@FreeBSD.ORG Wed Apr 15 19:21:55 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 ED7AD1065677; Wed, 15 Apr 2009 19:21:54 +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 2F6118FC12; Wed, 15 Apr 2009 19:21:53 +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 n3FJLh1A086980; Wed, 15 Apr 2009 21:21:44 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <49E633C7.9030909@fgznet.ch> Date: Wed, 15 Apr 2009 21:21:43 +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> In-Reply-To: <1239819547.15474.5.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: Wed, 15 Apr 2009 19:22:05 -0000 Sean Bruno wrote: > On Wed, 2009-04-15 at 19:37 +0200, Andreas Tobler wrote: >> Sean Bruno wrote: >>>>> This looks basically good, but as outlined earlier a driver >>>>> souldn't busy-wait 50ms. Could one of you please test whether >>>>> pause("fwlps", (50 * hz + 999) / 1000) works as a drop-in >>>>> replacement for DELAY(50000) here? >>>> Works fine here! >>>> >>>> Thanks! >>>> Andreas >>>> >>>> >>>> >>> Ok, time for more testing. A couple of changes here. >>> >>> 1. change busy DELAY() call with pause() >>> 2. test for lps condition before pause(), if not set pause and retry. >> Fine here, but see that there was no pause needed, strange. >> >> Andreas >> >> > 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 From owner-freebsd-firewire@FreeBSD.ORG Wed Apr 15 20:20:04 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 C3440106567D for ; Wed, 15 Apr 2009 20:20:04 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id 917AE8FC24 for ; Wed, 15 Apr 2009 20:20:04 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 25817 invoked from network); 15 Apr 2009 13:20:01 -0700 Received: from 069-064-235-060.pdx.net (HELO ?192.168.1.51?) (69.64.235.60) by iron2.pdx.net with SMTP; 15 Apr 2009 13:20:01 -0700 From: Sean Bruno To: Andreas Tobler In-Reply-To: <49E633C7.9030909@fgznet.ch> 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> Content-Type: multipart/mixed; boundary="=-P2CbIcOK6oM3FCRmbcZ+" Date: Wed, 15 Apr 2009 13:20:03 -0700 Message-Id: <1239826803.15474.48.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 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: Wed, 15 Apr 2009 20:20:05 -0000 --=-P2CbIcOK6oM3FCRmbcZ+ Content-Type: text/plain Content-Transfer-Encoding: 7bit > >> > > 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 --=-P2CbIcOK6oM3FCRmbcZ+ Content-Disposition: attachment; filename="fwohci.c.diff" Content-Type: text/x-patch; name="fwohci.c.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit Index: fwohci.c =================================================================== --- fwohci.c (revision 191002) +++ fwohci.c (working copy) @@ -280,7 +280,8 @@ fun = (PHYDEV_WRCMD | (addr << PHYDEV_REGADDR) | (data << PHYDEV_WRDATA)); OWRITE(sc, OHCI_PHYACCESS, fun); - DELAY(100); + bus_space_barrier(sc->bst, sc->bsh, OHCI_PHYACCESS, + 4, BUS_SPACE_BARRIER_WRITE); return(fwphy_rddata( sc, addr)); } @@ -324,11 +325,15 @@ OWRITE(sc, FWOHCI_INTSTATCLR, OHCI_INT_REG_FAIL); fun = PHYDEV_RDCMD | (addr << PHYDEV_REGADDR); OWRITE(sc, OHCI_PHYACCESS, fun); + bus_space_barrier(sc->bst, sc->bsh, OHCI_PHYACCESS, + 4, BUS_SPACE_BARRIER_WRITE); + for ( i = 0 ; i < MAX_RETRY ; i ++ ){ fun = OREAD(sc, OHCI_PHYACCESS); + bus_space_barrier(sc->bst, sc->bsh, OHCI_PHYACCESS, + 4, BUS_SPACE_BARRIER_READ); if ((fun & PHYDEV_RDCMD) == 0 && (fun & PHYDEV_RDDONE) != 0) break; - DELAY(100); } if(i >= MAX_RETRY) { if (firewire_debug) @@ -426,20 +431,47 @@ static int fwohci_probe_phy(struct fwohci_softc *sc, device_t dev) { - uint32_t reg, reg2; + uint32_t lps, reg, reg2; + int lps_counter = 0; int e1394a = 1; -/* - * probe PHY parameters - * 0. to prove PHY version, whether compliance of 1394a. - * 1. to probe maximum speed supported by the PHY and - * number of port supported by core-logic. - * It is not actually available port on your PC . - */ + + /* + * Enable LPS(Link Power Status as per + * section 5.7 of OHCI v1.1 + * This allows PHY communication after + * a hard/soft reset + * + * Some users report that the code + * will crash without the pause due + * to the lps bit being set and the + * PHY not being up. Strictly speaking, + * this code SHOULD check that the SCLK + * has started before it attempts + * to access other PHY resources. + */ OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_LPS); - DELAY(500); - + bus_space_barrier(sc->bst, sc->bsh, OHCI_HCCCTL, 4, BUS_SPACE_BARRIER_WRITE); + for (lps = 0, lps_counter = 0; !lps && lps_counter < 3; lps_counter++) { + pause("fwlps", (50 * hz + 999) / 1000); + lps = (OREAD(sc, OHCI_HCCCTL) & OHCI_HCC_LPS); + } + /* + * probe PHY parameters + * 0. to prove PHY version, whether compliance of 1394a. + * 1. to probe maximum speed supported by the PHY and + * number of port supported by core-logic. + * It is not actually available port on your PC . + */ reg = fwphy_rddata(sc, FW_PHY_SPD_REG); + /* + * ref 1394-2000 table 5B-1 + * ref 1394-1995 table J.12 + * If Extended is not set + * Assume 1394-1995 + * If Extended is set + * Assume 1394-2000(1394a) + */ if((reg >> 5) != 7 ){ sc->fc.mode &= ~FWPHYASYST; sc->fc.nport = reg & FW_PHY_NP; @@ -453,12 +485,12 @@ "Phy 1394 only %s, %d ports.\n", linkspeed[sc->fc.speed], sc->fc.nport); }else{ - reg2 = fwphy_rddata(sc, FW_PHY_ESPD_REG); sc->fc.mode |= FWPHYASYST; sc->fc.nport = reg & FW_PHY_NP; + reg2 = fwphy_rddata(sc, FW_PHY_ESPD_REG); sc->fc.speed = (reg2 & FW_PHY_ESPD) >> 5; if (sc->fc.speed > MAX_SPEED) { - device_printf(dev, "invalid speed %d (fixed to %d).\n", + device_printf(dev, "invalid extended speed %d (fixed to %d).\n", sc->fc.speed, MAX_SPEED); sc->fc.speed = MAX_SPEED; } @@ -468,11 +500,7 @@ /* check programPhyEnable */ reg2 = fwphy_rddata(sc, 5); -#if 0 - if (e1394a && (OREAD(sc, OHCI_HCCCTL) & OHCI_HCC_PRPHY)) { -#else /* XXX force to enable 1394a */ if (e1394a) { -#endif if (firewire_debug) device_printf(dev, "Enable 1394a Enhancements\n"); @@ -488,6 +516,13 @@ reg2 = fwphy_wrdata(sc, 5, reg2); } + /* + * Re-read and check for extended 1394a + * PHY Register map. + * Then set the Contender bit on. + * This makes us a possible bus or isoc + * resource manager. (ieee 1394a-2000, 5B.1) + */ reg = fwphy_rddata(sc, FW_PHY_SPD_REG); if((reg >> 5) == 7 ){ reg = fwphy_rddata(sc, 4); --=-P2CbIcOK6oM3FCRmbcZ+-- 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 From owner-freebsd-firewire@FreeBSD.ORG Sat Apr 18 12:40:03 2009 Return-Path: Delivered-To: freebsd-firewire@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C44C81067009 for ; Sat, 18 Apr 2009 12:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 74A498FC08 for ; Sat, 18 Apr 2009 12:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3ICe2x3090055 for ; Sat, 18 Apr 2009 12:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3ICe26O090054; Sat, 18 Apr 2009 12:40:02 GMT (envelope-from gnats) Date: Sat, 18 Apr 2009 12:40:02 GMT Message-Id: <200904181240.n3ICe26O090054@freefall.freebsd.org> To: freebsd-firewire@FreeBSD.org From: =?ISO-8859-1?Q?Stefan_Kr=FCger?= Cc: Subject: Re: kern/125673: [firewire] [panic] FreeBSD7 panics when kldunloading firewire X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-1?Q?Stefan_Kr=FCger?= List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 12:40:22 -0000 The following reply was made to PR kern/125673; it has been noted by GNATS. From: =?ISO-8859-1?Q?Stefan_Kr=FCger?= To: Sean Bruno Cc: bug-followup@FreeBSD.org Subject: Re: kern/125673: [firewire] [panic] FreeBSD7 panics when kldunloading firewire Date: Sat, 18 Apr 2009 12:11:48 +0000 Sean Bruno wrote: > Please retest and attach the following: > > your kernel configuration > the output of "kldstat" Hallo Sean, I'm so sorry for answering so late :( I found out that my test box (the one were the firewire panic happend) was disassembled a few weeks ago, so I can't test anything anymore Please close this PR