Date: Thu, 16 Apr 2009 22:20:44 +0200 From: Andreas Tobler <andreast-list@fgznet.ch> To: Sean Bruno <sean.bruno@dsl-only.net> Cc: freebsd-firewire <freebsd-firewire@freebsd.org>, scottl <scottl@freebsd.org>, Marius Strobl <marius@alchemy.franken.de> Subject: Re: fwochi.c and bus_space_barrier() Message-ID: <49E7931C.8050603@fgznet.ch> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E7931C.8050603>