similar to: Nouveau ctxprogs (Re: [git pull] drm)

On Tue, Oct 29, 2013 at 6:11 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote: > On 10/30/13 03:17 AM, Chandler Carruth wrote: > >> On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" <cbergstrom at pathscale.com<mailto: >> cbergstrom at pathscale.**com <cbergstrom at pathscale.com>>> wrote: >> >> On 10/29/13 07:27 AM,

On 10/30/13 03:17 AM, Chandler Carruth wrote: > On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" > <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com>> wrote: > > On 10/29/13 07:27 AM, Chandler Carruth wrote: > > On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" > <cbergstrom at pathscale.com

On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote: > On 10/29/13 07:27 AM, Chandler Carruth wrote: > > On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" <cbergstrom at pathscale.com<mailto: >> cbergstrom at pathscale.**com <cbergstrom at pathscale.com>>> wrote: >> >> fuzzy://How much

Firmware files in firmware/ directory are not expected to be in binary format. The nouveau files are in binary format, and are therefore removed when running e.g. make clean. Fix that by converting them to ihex format instead. The patch is really big as it contains the ctxprogs stuff, so I'll provide a link instead:

On 06/11/14 08:39 PM, Chandler Carruth wrote: > > On Wed, Jun 11, 2014 at 1:44 AM, Ted Kremenek <kremenek at apple.com > <mailto:kremenek at apple.com>> wrote: > > On Jun 10, 2014, at 5:36 PM, C. Bergström > <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com>> wrote: > > > On 06/11/14 06:58 AM, Ted Kremenek wrote: >

If something calls ioremap with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap the address passed to unregister_kmmio_probe was PAGE_SIZE aligned by the caller leading to a complete freeze of the machine. We should always page

On Wed, 16 Apr 2008 13:46:09 +0200 Ingo Molnar <mingo at elte.hu> wrote: > > * Pekka Paalanen <pq at iki.fi> wrote: > > > > we should fix this restriction ASAP. Forcibly dropping to UP will > > > cause mmiotrace to be much less useful for diagnostic purposes of > > > Linux > > > > Ok, how do you propose we solve this? > >

On Tue, Jul 07, 2015 at 08:13:28PM -0400, Ilia Mirkin wrote: > On Tue, Jul 7, 2015 at 8:11 PM, C Bergström <cbergstrom at pathscale.com> wrote: > > On Wed, Jul 8, 2015 at 7:08 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > >> On Tue, Jul 7, 2015 at 8:07 PM, C Bergström <cbergstrom at pathscale.com> wrote: > >>> On Wed, Jul 8, 2015 at 6:58 AM, Ben

On Fri, 25 Oct 2013 17:19:56 +0400 Eugene Shatokhin <euspectre at gmail.com> wrote: > Hi, > > 2013/10/25 Pekka Paalanen <pq at iki.fi> > ... > > We could use some comments from the real reverse-engineers. I used > > to be mostly a tool writer. > > > > Yes, if some experts could share their knowledge of this matter, this would > be most

Hi guys, it's been a year since my last call (below) for updating translations. Unless anyone objects, I propose, that all translation pages are eligible for removal if they have not been properly updated within two weeks since the original page was updated. TiNDCs are an exception, they are not live content, and they should be up-to-date anyway, by definition. mwk already did some good

On Wed, Jul 8, 2015 at 7:08 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Tue, Jul 7, 2015 at 8:07 PM, C Bergström <cbergstrom at pathscale.com> wrote: >> On Wed, Jul 8, 2015 at 6:58 AM, Ben Skeggs <skeggsb at gmail.com> wrote: >>> On 8 July 2015 at 09:53, C Bergström <cbergstrom at pathscale.com> wrote: >>>> regarding >>>>

So, I wrote a generator for ctxprogs on NV50, NV84, NV86, NV92, NV94, NV96, NV98. Atm it's only tested with NV86 and I'd like to see if it works for all the other cards, especially NV50. NVAx support is still missing due to some differences, but should be coming soon. Address is http://0x04.net/~mwk/gen.diff , please test it with all mentioned cards, and involve as much gallium as

On 04/11/15 09:08, cbergstrom at pathscale.com wrote: > Is anyone actually and or actively working on this? > Github.com/pathscale/pscnv is totally bitrot but waaay more portable > base. Nouveau made hard Linux assumptions that will be difficult to > overcome afaik. As pointed out by Ilia, this is not true anymore. Nouveau can also partially run in the userspace, the hard

Chandler has it right. Our intent is to upstream everything. The MS fork will be used as a staging area for LLVM changes as we work to get them upstreamed. Tactically we're merging the MS fork everyday with mainline to try and stay close. We're still ramping up right now, and trying to figure out how best to work day to day, but our over arching goal is to enable (mainline) LLVM to be

On 10/29/13 07:27 AM, Chandler Carruth wrote: > On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" > <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com>> wrote: > > fuzzy://How much "heads up" > > > One full release cycle, so approximately 6 months before a release If it's 3-6 months from *today* before something hits clang

On Sun, Jun 7, 2015 at 2:34 AM, Eric Christopher <echristo at gmail.com> wrote: > > > On Sat, Jun 6, 2015 at 12:31 PM C Bergström <cbergstrom at pathscale.com> > wrote: >> >> On Sun, Jun 7, 2015 at 2:22 AM, Eric Christopher <echristo at gmail.com> >> wrote: >> > >> > >> > On Sat, Jun 6, 2015 at 5:02 AM C Bergström

On Dec 15, 2013, at 7:10 PM, C. Bergström <cbergstrom at pathscale.com> wrote: > On 12/16/13 09:57 AM, Bill Wendling wrote: >> On Dec 12, 2013, at 11:08 PM, C. Bergström <cbergstrom at pathscale.com> wrote: >> >>> On 12/13/13 01:58 PM, Bill Wendling wrote: >>>> That’s a long laundry list of bugs there. It would be great to have them fixed, but the

On Sun, Jun 7, 2015 at 2:52 AM, Eric Christopher <echristo at gmail.com> wrote: > > > On Sat, Jun 6, 2015 at 12:43 PM C Bergström <cbergstrom at pathscale.com> > wrote: >> >> On Sun, Jun 7, 2015 at 2:34 AM, Eric Christopher <echristo at gmail.com> >> wrote: >> > >> > >> > On Sat, Jun 6, 2015 at 12:31 PM C Bergström

After every iounmap mmiotrace has to free kmmio_fault_pages, but it can't do it directly, so it defers freeing by RCU. It usually works, but when mmiotraced code calls ioremap-iounmap multiple times without sleeping between (so RCU won't kick in and start freeing) it can be given the same virtual address, so at every iounmap mmiotrace will schedule the same pages for release. Obviously it

Hi, Good to know that! Yes, it should be faster than page faulting, although I haven't done the benchmarking yet. And yes, it is not needed to disable all but one CPU. In my current implementation, I use an ordered workqueue to send the data to the mmapped output buffer (where they will be read from from the user space) and that ensures the order of events is kept. May be less than ideal but