> On Apr 30, 2019, at 11:24 AM, Warner Losh <i...@bsdimp.com> wrote: > > > On Tue, Apr 30, 2019 at 9:17 AM Hans Petter Selasky <h...@selasky.org > <mailto:h...@selasky.org>> wrote: > On 4/30/19 3:10 PM, Niclas Zeising wrote: > > On 2019-04-30 12:41, Hans Petter Selasky wrote: > >> Author: hselasky > >> Date: Tue Apr 30 10:41:20 2019 > >> New Revision: 346958 > >> URL: https://svnweb.freebsd.org/changeset/base/346958 > >> <https://svnweb.freebsd.org/changeset/base/346958> > >> > >> Log: > >> Reduce the number of mutexes after r346645 in the LinuxKPI. > >> Make function macro wrappers for locking and unlocking to ease > >> readability. > >> No functional change. > >> Discussed with: kib@, tychon@ and zeising@ > > > > I was not part of any discussion regarding this. If this is related to > > https://reviews.freebsd.org/D20097 <https://reviews.freebsd.org/D20097> I > > explicitly asked you on gitter to > > hold of for a bit, while we try to figure out why we are seeing > > regressions in graphics with the latest dmar changes. > > > > Can you please revert this since it colludes the dmar graphics issue, > > and it makes the suggested patch not apply cleanly, which makes it > > harder to get people to help test. > > Thank you! > > Regards > > In response to your request I've collected fixes for all the known > LinuxKPI+DMA issues at: > https://reviews.freebsd.org/D20097 <https://reviews.freebsd.org/D20097> > > It is based on top of the latest -current. > > Hopefully this will solve the problem. Do you have any idea of when we might > see resolution of this issue? I'd like to see it fixed by Friday either with > fixes or a revert. Do you think that's a reasonable time frame? If not, what > do you think a reasonable time frame will be? I know we have a number of > unknowns to factor in, so my queries are based on our best guesses.
Friday seems reasonable. The issues that have been exposed are that several callers of the Linux API are not compliant with the documented API. For example according to the documentation, dma_map_sg() may coalesce entries and our current implementation does that. This broke some graphics drivers. To support these drivers, going back to the non-coalesced version is the only path forward as the callee bugs redefine this API de facto; this is included in D20097. Also included in D20097 is a fix to ensure sg_dma_len() is equal to sg->length — again to address assumptions in drivers. Finally, apparently some drivers load the same DMA address multiple times without any prior unload. Those drivers need to work too; D20097 contains a fix. Thanks hps@ for helping out! Tycho _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
