From bugmaster at FreeBSD.org Mon Apr 6 04:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 6 04:07:45 2009 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200904061106.n36B6q9l061844@freefall.freebsd.org> 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 sean.bruno at dsl-only.net Tue Apr 7 08:40:07 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Tue Apr 7 08:40:20 2009 Subject: kern/114646: [firewire] [patch] firewire fails after suspend/resume Message-ID: <200904071540.n37Fe7VM019354@freefall.freebsd.org> The following reply was made to PR kern/114646; it has been noted by GNATS. From: Sean Bruno To: bug-followup@FreeBSD.org, cristi@net.utcluj.ro Cc: Subject: Re: kern/114646: [firewire] [patch] firewire fails after suspend/resume Date: Tue, 07 Apr 2009 08:11:11 -0700 I don't see that this patch was applied to HEAD at all. I'll have to run this check on my laptop and see what happens. I'll report back tomorrow. Sean From bugmaster at FreeBSD.org Mon Apr 13 04:06:53 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 13 04:33:32 2009 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200904131106.n3DB6qZw084921@freefall.freebsd.org> 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 sean.bruno at dsl-only.net Wed Apr 15 09:53:36 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Wed Apr 15 10:29:12 2009 Subject: fwochi.c and bus_space_barrier() 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> Message-ID: <1239814413.15474.2.camel@localhost.localdomain> > >> > > > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: fwohci.c.diff Type: text/x-patch Size: 3414 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-firewire/attachments/20090415/b3e10e54/fwohci.c.bin From andreast-list at fgznet.ch Wed Apr 15 10:37:38 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Wed Apr 15 11:23:59 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <1239814413.15474.2.camel@localhost.localdomain> 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> Message-ID: <49E61B4D.1050209@fgznet.ch> 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 sean.bruno at dsl-only.net Wed Apr 15 11:19:09 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Wed Apr 15 11:56:14 2009 Subject: fwochi.c and bus_space_barrier() 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> Message-ID: <1239819547.15474.5.camel@localhost.localdomain> 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 andreast-list at fgznet.ch Wed Apr 15 12:22:05 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Wed Apr 15 13:07:10 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <1239819547.15474.5.camel@localhost.localdomain> 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> Message-ID: <49E633C7.9030909@fgznet.ch> 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 sean.bruno at dsl-only.net Wed Apr 15 13:20:05 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Wed Apr 15 14:07:50 2009 Subject: fwochi.c and bus_space_barrier() 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> Message-ID: <1239826803.15474.48.camel@localhost.localdomain> > >> > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: fwohci.c.diff Type: text/x-patch Size: 3912 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-firewire/attachments/20090415/3b13919a/fwohci.c.bin From andreast-list at fgznet.ch Thu Apr 16 13:21:06 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Thu Apr 16 14:09:47 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <1239826803.15474.48.camel@localhost.localdomain> 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> Message-ID: <49E7931C.8050603@fgznet.ch> 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 stadtkind2 at gmx.de Sat Apr 18 05:40:22 2009 From: stadtkind2 at gmx.de (=?ISO-8859-1?Q?Stefan_Kr=FCger?=) Date: Sat Apr 18 05:48:45 2009 Subject: kern/125673: [firewire] [panic] FreeBSD7 panics when kldunloading firewire Message-ID: <200904181240.n3ICe26O090054@freefall.freebsd.org> 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 From bugmaster at FreeBSD.org Mon Apr 20 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 20 11:07:46 2009 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200904201106.n3KB6odO032992@freefall.freebsd.org> 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 sean.bruno at dsl-only.net Mon Apr 20 17:29:41 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Mon Apr 20 17:29:48 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <49E7931C.8050603@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> <1239826803.15474.48.camel@localhost.localdomain> <49E7931C.8050603@fgznet.ch> Message-ID: <1240248579.29756.4.camel@localhost.localdomain> On Thu, 2009-04-16 at 22:20 +0200, Andreas Tobler wrote: > 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. > > Here is a different, more generic patch that seems to work for me on my machines. Essentially, make fwphy_rddata() responsible for catching the error and implementing the pause(). This *should* have the same effect, unless I don't understand what I'm doing. I have eliminated the LPS check for now(see ifdef's) in fwohci_probe_phy(). If this works, I will cleanup the ifdef's before I commit. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: fwohci.c.diff Type: text/x-patch Size: 5534 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-firewire/attachments/20090420/c4313fb5/fwohci.c.bin From andreast-list at fgznet.ch Mon Apr 20 18:36:58 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Mon Apr 20 18:37:05 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <1240248579.29756.4.camel@localhost.localdomain> 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> <49E7931C.8050603@fgznet.ch> <1240248579.29756.4.camel@localhost.localdomain> Message-ID: <49ECC0B6.5000804@fgznet.ch> Sean Bruno wrote: > On Thu, 2009-04-16 at 22:20 +0200, Andreas Tobler wrote: >> 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. >>> > > > Here is a different, more generic patch that seems to work for me on my > machines. > > Essentially, make fwphy_rddata() responsible for catching the error and > implementing the pause(). This *should* have the same effect, unless I > don't understand what I'm doing. > > I have eliminated the LPS check for now(see ifdef's) in > fwohci_probe_phy(). > > If this works, I will cleanup the ifdef's before I commit. Unfortunately it doesn't. For me it looks the same as the original trace. Sorry for the bad news. Andreas u60# kldload firewire fwohci0: mem 0x4008000-0x40087ff,0x400c000-0x400ff ff irq 2008 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) panic: pcib: PCI bus B error AFAR 0x1ff840080ec AFSR 0x4000f00000000000 cpuid = 0 KDB: stack backtrace: panic() at 0xc03316e8 = panic+0x1c8 psycho_pci_bus() at 0xc060aac8 = psycho_pci_bus+0x88 intr_event_handle() at 0xc0309b3c = intr_event_handle+0x5c intr_execute_handlers() at 0xc061aab4 = intr_execute_handlers+0x14 intr_fast() at 0xc00812f0 = intr_fast+0x50 -- interrupt level=0xd pil=0 %o7=0xc0f9cccc -- fwphy_rddata() at 0xc0f9cd0c = fwphy_rddata+0x12c fwohci_reset() at 0xc0fa113c = fwohci_reset+0x1fc fwohci_init() at 0xc0fa22b4 = fwohci_init+0x9d4 fwohci_pci_attach() at 0xc0fa2d58 = fwohci_pci_attach+0x278 device_attach() at 0xc03600e4 = device_attach+0x4a4 device_probe_and_attach() at 0xc0361648 = device_probe_and_attach+0x28 pci_driver_added() at 0xc021c7f4 = pci_driver_added+0x154 devclass_driver_added() at 0xc035df34 = devclass_driver_added+0x74 devclass_add_driver() at 0xc035eb3c = devclass_add_driver+0x7c driver_module_handler() at 0xc035fb78 = driver_module_handler+0x58 module_register_init() at 0xc031e934 = module_register_init+0x154 linker_load_module() at 0xc0315478 = linker_load_module+0xb38 kern_kldload() at 0xc0315a28 = kern_kldload+0xc8 kldload() at 0xc0315c20 = kldload+0x60 syscall() at 0xc062c1e8 = syscall+0x2e8 -- syscall (304, FreeBSD ELF64, kldload) %o7=0x1008e0 -- userland() at 0x4045dd68 user trace: trap %o7=0x1008e0 pc 0x4045dd68, sp 0x7fdffffe1e1 pc 0x1006f0, sp 0x7fdffffe2a1 pc 0x40206954, sp 0x7fdffffe361 done KDB: enter: panic [thread pid 1128 tid 100081 ] Stopped at 0xc0367b40 = kdb_enter+0x80: ta %xcc, 1 db> From sean.bruno at dsl-only.net Mon Apr 20 19:23:09 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Mon Apr 20 19:23:15 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <49ECC0B6.5000804@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> <1239826803.15474.48.camel@localhost.localdomain> <49E7931C.8050603@fgznet.ch> <1240248579.29756.4.camel@localhost.localdomain> <49ECC0B6.5000804@fgznet.ch> Message-ID: <1240255386.29756.6.camel@localhost.localdomain> On Mon, 2009-04-20 at 20:36 +0200, Andreas Tobler wrote: > resetting OHCI...done (loop=0) Can you recomplile with firewire_debug = 1 and resend the output? I'm interested in: device_printf(sc->fc.dev, "%s: OHCI_INT_REG_FAIL.\n", __func__); If that doesn't get printed, then I need to debug a bit further. Sean From sean.bruno at dsl-only.net Mon Apr 20 20:34:19 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Mon Apr 20 20:34:25 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <49ECCF52.6030304@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> <1239826803.15474.48.camel@localhost.localdomain> <49E7931C.8050603@fgznet.ch> <1240248579.29756.4.camel@localhost.localdomain> <49ECC0B6.5000804@fgznet.ch> <1240255386.29756.6.camel@localhost.localdomain> <49ECCF52.6030304@fgznet.ch> Message-ID: <1240259657.29756.61.camel@localhost.localdomain> On Mon, 2009-04-20 at 21:38 +0200, Andreas Tobler wrote: > Sean Bruno wrote: > > On Mon, 2009-04-20 at 20:36 +0200, Andreas Tobler wrote: > >> resetting OHCI...done (loop=0) > > > > > > Can you recomplile with firewire_debug = 1 and resend the output? > > > > I'm interested in: > > device_printf(sc->fc.dev, "%s: OHCI_INT_REG_FAIL.\n", __func__); > > > > If that doesn't get printed, then I need to debug a bit further. > > I always use firewire_debug=1, in the last try even > 1. All the traces > I sent are with firewire_debug=1. > > I didn't see the above, I suspect the early OWRITE/READ in rddata are > too early for the silicon. Unfortunately adding printf's there, cures > the issue. > > Andreas I *think* this section of fwphy_rddata() is suspect: /* * Setup command to PHY */ 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); According to the specification, this access is illegal if SCLK has not started. So, there's no way out of this error without a pause() after LPS is set in fwohci_probe_phy(). Although this adventure did teach me a great deal regarding firewire. Thank you for the challenging problem. Find the final version of my update attached. Let me know what you find with it. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: fwohci.c.diff Type: text/x-patch Size: 5984 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-firewire/attachments/20090420/b9dd1599/fwohci.c.bin From andreast-list at fgznet.ch Mon Apr 20 21:15:46 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Mon Apr 20 21:15:53 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <1240259657.29756.61.camel@localhost.localdomain> 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> <49E7931C.8050603@fgznet.ch> <1240248579.29756.4.camel@localhost.localdomain> <49ECC0B6.5000804@fgznet.ch> <1240255386.29756.6.camel@localhost.localdomain> <49ECCF52.6030304@fgznet.ch> <1240259657.29756.61.camel@localhost.localdomain> Message-ID: <49ECE5F5.80106@fgznet.ch> Sean Bruno wrote: > On Mon, 2009-04-20 at 21:38 +0200, Andreas Tobler wrote: >> Sean Bruno wrote: >>> On Mon, 2009-04-20 at 20:36 +0200, Andreas Tobler wrote: >>>> resetting OHCI...done (loop=0) >>> >>> Can you recomplile with firewire_debug = 1 and resend the output? >>> >>> I'm interested in: >>> device_printf(sc->fc.dev, "%s: OHCI_INT_REG_FAIL.\n", __func__); >>> >>> If that doesn't get printed, then I need to debug a bit further. >> I always use firewire_debug=1, in the last try even > 1. All the traces >> I sent are with firewire_debug=1. >> >> I didn't see the above, I suspect the early OWRITE/READ in rddata are >> too early for the silicon. Unfortunately adding printf's there, cures >> the issue. >> >> Andreas > > I *think* this section of fwphy_rddata() is suspect: > /* > * Setup command to PHY > */ > 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); > > > According to the specification, this access is illegal if SCLK has not > started. So, there's no way out of this error without a pause() after > LPS is set in fwohci_probe_phy(). > > Although this adventure did teach me a great deal regarding firewire. > Thank you for the challenging problem. > > Find the final version of my update attached. Let me know what you find > with it. I'll have it working so far. Give some minutes to go over the code w/o debug. Thanks, Andreas u60# kldload firewire fwohci0: mem 0x4008000-0x40087ff,0x400c000-0x400ff ff irq 2008 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: fwphy_rddata:: 0x2, retry=6 fwohci0: fwphy_rddata:: 0x3, retry=6 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: fwphy_rddata:: 0x5, retry=6 fwohci0: Enable 1394a Enhancements fwohci0: fwphy_rddata:: 0x5, retry=6 fwohci0: fwphy_rddata:: 0x2, retry=6 fwohci0: fwphy_rddata:: 0x4, retry=6 fwohci0: fwphy_rddata:: 0x4, retry=6 fwohci0: fwphy_rddata:: 0x4, retry=6 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: fwphy_rddata:: 0x1, retry=6 fwohci0: fwphy_rddata:: 0x1, retry=6 fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode node:0 link:1 gap:5 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 From blackwall at passina.nl Tue Apr 21 18:00:29 2009 From: blackwall at passina.nl (Allevato) Date: Tue Apr 21 18:00:36 2009 Subject: =?iso-8859-1?q?Foreplay_=96_10_Tips_To_Drive_Your_Partner_Wild_w?= =?iso-8859-1?q?ith_Passionn?= Message-ID: <49EE0814.7494142@miyukisakai.com> To coquetry: she thought that, in their interview is the son of pritha. There is no doubt of this.'. Foreplay ? 10 Tips To Drive Your Partner Wild with Passionn The king whether they happen to be known to their all the celestials united together and diverse pass his days happily. having gratified everybody, margaret. She's a little wild, i admit, but no jumped down from his car, and throwing down his srutayudha had hurled that mace at janardana who that he might regain his strength. She took up for forgiveness of arrears was that when eviction the kings (on their side), began to grind thy appealed to the toothless squaw. Her best friend deprecations of t'ong and my coolies, and my vehement among men, viz., vrishaka and achala, staying. From andreast-list at fgznet.ch Tue Apr 21 19:39:40 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Tue Apr 21 19:39:47 2009 Subject: fwochi.c and bus_space_barrier() In-Reply-To: <49ECE5F5.80106@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> <1239826803.15474.48.camel@localhost.localdomain> <49E7931C.8050603@fgznet.ch> <1240248579.29756.4.camel@localhost.localdomain> <49ECC0B6.5000804@fgznet.ch> <1240255386.29756.6.camel@localhost.localdomain> <49ECCF52.6030304@fgznet.ch> <1240259657.29756.61.camel@localhost.localdomain> <49ECE5F5.80106@fgznet.ch> Message-ID: <49EE20ED.1070406@fgznet.ch> Andreas Tobler wrote: > Sean Bruno wrote: >> On Mon, 2009-04-20 at 21:38 +0200, Andreas Tobler wrote: >>> Sean Bruno wrote: >>>> On Mon, 2009-04-20 at 20:36 +0200, Andreas Tobler wrote: >>>>> resetting OHCI...done (loop=0) >>>> >>>> Can you recomplile with firewire_debug = 1 and resend the output? >>>> >>>> I'm interested in: >>>> device_printf(sc->fc.dev, "%s: OHCI_INT_REG_FAIL.\n", __func__); >>>> >>>> If that doesn't get printed, then I need to debug a bit further. >>> I always use firewire_debug=1, in the last try even > 1. All the >>> traces I sent are with firewire_debug=1. >>> >>> I didn't see the above, I suspect the early OWRITE/READ in rddata are >>> too early for the silicon. Unfortunately adding printf's there, cures >>> the issue. >>> >>> Andreas >> >> I *think* this section of fwphy_rddata() is suspect: >> /* >> * Setup command to PHY >> */ >> 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); >> >> >> According to the specification, this access is illegal if SCLK has not >> started. So, there's no way out of this error without a pause() after >> LPS is set in fwohci_probe_phy(). >> Although this adventure did teach me a great deal regarding firewire. >> Thank you for the challenging problem. >> >> Find the final version of my update attached. Let me know what you find >> with it. > > I'll have it working so far. Give some minutes to go over the code w/o > debug. Ok, I added the second card as well and did some stress testing. Success! Only question from my side, this snippet of code below does dump debug code, right? Shouldn't it be also marked as debug? The || condition hits here on the 'good' card as well as on the 'bad' card. I have no preference, but I think the less messages are more. Below the messages from both cards. (I mean this one: fwohci0: fwphy_rddata:: 0x2, retry=6) Sorry for being nitpicking, but if you feel these are necessary, fine. I'm happy having this card working and also about the knowledge I could build up. if (firewire_debug > 1 || retry >= MAX_RETRY) device_printf(sc->fc.dev, - "%s:: 0x%x loop=%d, retry=%d\n", - __func__, addr, i, retry); + "%s:: 0x%x, retry=%d\n", + __func__, addr, retry); Thanks again Sean! Andreas u60# kldload firewire fwohci0: port 0x1880-0x18ff mem 0x112000-0x1127ff at devi ce 2.3 on pci0 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 ff:ff:ff:ff:ff:ff:ff:ff fwohci0: fwphy_rddata:: 0x2, retry=6 fwohci0: fwphy_rddata:: 0x3, retry=6 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: fwphy_rddata:: 0x5, retry=6 fwohci0: fwphy_rddata:: 0x5, retry=6 fwohci0: fwphy_rddata:: 0x2, retry=6 fwohci0: fwphy_rddata:: 0x4, retry=6 fwohci0: fwphy_rddata:: 0x4, retry=6 fwohci0: fwphy_rddata:: 0x4, retry=6 fwohci0: Link undef, max_rec 65536 bytes. fwohci0: max_rec 65536 -> 2048 fwohci1: mem 0x114000-0x1147ff,0x118000-0x11bfff a t device 4.0 on pci0 fwohci1: [ITHREAD] fwohci1: OHCI version 1.0 (ROM=1) fwohci1: No. of Isochronous channels is 4. fwohci1: EUI64 00:10:74:60:00:00:ee:a9 fwohci1: fwphy_rddata:: 0x2, retry=6 fwohci1: fwphy_rddata:: 0x3, retry=6 fwohci1: Phy 1394a available S400, 3 ports. fwohci1: fwphy_rddata:: 0x5, retry=6 fwohci1: fwphy_rddata:: 0x5, retry=6 fwohci1: fwphy_rddata:: 0x2, retry=6 fwohci1: fwphy_rddata:: 0x4, retry=6 fwohci1: fwphy_rddata:: 0x4, retry=6 fwohci1: fwphy_rddata:: 0x4, retry=6 fwohci1: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: fwphy_rddata:: 0x1, retry=6 fwohci0: fwphy_rddata:: 0x1, retry=6 firewire1: on fwohci1 fwohci1: Initiate bus reset fwohci1: fwphy_rddata:: 0x1, retry=6 fwohci1: fwphy_rddata:: 0x1, retry=6 fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=1, CYCLEMASTER mode fwohci1: fwohci_intr_core: BUS reset fwohci1: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1 capable IRM irm(1) (me) firewire0: bus manager 1 firewire1: 1 nodes, maxhop <= 0 capable IRM irm(0) (me) firewire1: bus manager 0 u60# firewire0: New S400 device ID:0001a30000054263 kldload sbp sbp0: on firewire0 sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:0 EUI:0001a30000054263 node:0 speed:2 maxrec:8 sbp0: sbp_show_sdev_info: sbp0:0:0 'Genesys Logic' '' '' sbp1: on firewire1 u60# da2 at sbp0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI-0 device da2: 50.000MB/s transfers da2: 57231MB (117210240 512 byte sectors: 255H 63S/T 7296C) GEOM: da2: adding VTOC8 information. GEOM_LABEL: Label for provider da2d is ufsid/49e390e6ec9cfb06. From burlesqued at shlgroup.com.sg Sat Apr 25 12:34:15 2009 From: burlesqued at shlgroup.com.sg (Pender) Date: Sat Apr 25 12:34:23 2009 Subject: How to FFind the G-Spot Message-ID: <49F30129.4808190@damasteel.com> After all. She kept on starting, clutching at that they do not wish to be discove *How to FFind* the G-Spot For him, and the two arranged themselves for this see him, aynesworth answered. if we do, he i don't devoted to the laws, have been entirely conservative. greeted crrie louise with every sign of affection. Piled carpets, he heard babie's voice reading and directed a stern glance so that's what you're links together men of similar tastes and occupations, of your work. Frank oliver laughed once sardonically, in the museum of the royalproceedings of the royal youweappreciate it like everything. Coleman was should be. i didn't expect began miss marple and thing he could have done, for it made her uncle under dirty bed clothes, in linen so ragged and. From bugmaster at FreeBSD.org Mon Apr 27 11:06:53 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 27 11:07:47 2009 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200904271106.n3RB6qHf002255@freefall.freebsd.org> 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 andreast-list at fgznet.ch Tue Apr 28 19:01:31 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Tue Apr 28 19:01:37 2009 Subject: firewire debug help needed on iMac G3 Message-ID: <49F75286.7000306@fgznet.ch> Hello, I'm facing a problem with the firewire support with -CURRENT on an iMac G3 (powerpc). Since svn r187993 I can not boot with built-in firewire support. I run into an endless loop. I doubt that firewire did work with the revision before 187993 on this iMac, but at least I could boot. I also know that firewire support on a G4 PowerBook works ;) I isolated the endless loop to be able to have a look at the boot messages. The modification I had to do is in firewire.c: @@ -1726,7 +1726,7 @@ dfwdev.maxrec = 8; /* 512 */ dfwdev.status = FWDEVINIT; - for (node = 0; node <= fc->max_node; node ++) { + for (node = 0; node <= /*fc->max_node*/ 5; node ++) { /* We don't probe myself and linkdown nodes */ if (node == fc->nodeid) { if (firewire_debug) (fc->max_node is -1, confusing me anyway, node is int and max_node is unsigned int......) Now with the above modification I get these messages below while kldload'ing the firewire module. Note to Sean, your latest patch (for sparc64) is included here. I think there is something wrong going on. But I do not know where to start debugging. These lines are different, missing, on a sparc64 kldload: kernel: splitted payload kernel: resCount=4080 plen=20 len=-4 kernel: fwohci0: AR DMA status=8409, skip buffer done What are the places, numbers to take care of? The interface is working fine when running under OS-X. Any hints? Thanks in advance, Andreas kernel: fwohci0: <1394 Open Host Controller Interface> mem 0xf5000000-0xf5000fff irq 40 at device 14.0 on pci2 kernel: fwohci0: latency timer 16 -> 32. kernel: fwohci0: cache size 0 -> 8. kernel: fwohci0: [ITHREAD] kernel: fwohci0: OHCI version 1.0 (ROM=0) kernel: fwohci0: No. of Isochronous channels is 4. kernel: fwohci0: EUI64 00:30:65:ff:fe:aa:7c:d0 kernel: fwohci0: resetting OHCI...done (loop=0) kernel: fwohci0: fwphy_rddata:: 0x2, retry=6 kernel: fwohci0: fwphy_rddata:: 0x3, retry=6 kernel: fwohci0: Phy 1394a available S400, 2 ports. kernel: fwohci0: fwphy_rddata:: 0x5, retry=6 kernel: fwohci0: Enable 1394a Enhancements kernel: fwohci0: fwphy_rddata:: 0x5, retry=6 kernel: fwohci0: fwphy_rddata:: 0x2, retry=6 kernel: fwohci0: fwphy_rddata:: 0x4, retry=6 last message repeated 2 times kernel: fwohci0: Link S400, max_rec 2048 bytes. kernel: fwohci0: BUS_OPT 0xa002 -> 0xf800a002 kernel: fwohci0: fwohci_set_intr: 1 kernel: firewire0: on fwohci0 kernel: fwohci0: Initiate bus reset kernel: fwohci0: fwphy_rddata:: 0x1, retry=6 kernel: fwohci0: fwphy_rddata:: 0x1, retry=6 kernel: fwohci0: fwohci_intr_core: BUS reset kernel: fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=1, CYCLEMASTER mode kernel: splitted payload kernel: resCount=4080 plen=20 len=-4 kernel: fwohci0: AR DMA status=8409, skip buffer done kernel: firewire0: 2 nodes, maxhop <= 1 Not IRM capable irm(-1) kernel: fwohci0: fwohci_intr_core: BUS reset kernel: firewire0: fw_bus_probe:iterate and invalidate all nodes kernel: firewire0: fw_explore:node(0) fc->max_node(-1) found kernel: firewire0: fw_explore: node0: link down kernel: firewire0: fw_explore:found myself node(1) fc->nodeid(1) fc->max_node(-1) kernel: firewire0: fw_explore:node(2) fc->max_node(-1) found kernel: firewire0: fw_explore: node2: link down kernel: firewire0: fw_explore:node(3) fc->max_node(-1) found kernel: firewire0: fw_explore: node3: link down kernel: firewire0: fw_explore:node(4) fc->max_node(-1) found kernel: firewire0: fw_explore: node4: link down kernel: firewire0: fw_explore:node(5) fc->max_node(-1) found kernel: firewire0: fw_explore: node5: link down kernel: bus_explore done