Updating for reference after rebase; also changed linuxkpi_ to lkpi_
as per recent discussions until we have a README.

If no one replies this will go in on Monday.

No idea why auto-close did not work.

In D45755#1051740, @jfree wrote:

In D45755#1050226, @bz wrote:

Anyone? Anyone who can test the Intel debug on drm code?

I just compiled with this patch and read/wrote to a bunch of debugfs files that I verified working in the past. I found no unexpected errors. Looks good to me.

Please see 046d8d89ed1956944b12ec4f0580c30bc202bbfb . Seems you are reverting that.

Only scrolled through but looks good

In D46099#1051506, @pho wrote:

I ran stress tests for 10 hours with D46099.141332.patch. I did not observe any issues.

I am happy with it for now.
If someone wants to refine it (and write a regression test for it) then I think they can in main afterwards.

Remove kasan_mark calls as per @markj

Hi Joe,

Address comments from @kib and @imp

@kib @imp I removed the BURN_BRIDGES (will come with the other changes in a few minutes); almost want an attribute __deprecated. I wonder how (other) big projects annotate deprecated APIs to yield warnings on use...

u_long -> uintptr_t

Done locally.

Address comments from @kib (I left the bridges alone but I agree a better name would be appreciated)

I've run a make tinderbox and I tried to remove any variables only used to hold the length for contigfree but nothing else; I did punt at one point (vmci code) and did not track all callers of vmci_free_kernel_mem().

If this version is still good it would be great to just get that checkbox again and I'll put the 3 suggested follow-up changes out as well.

Address comments from @markj and @kib

Try to address all the comments from @markj

I've locally implemented all the suggestions (Thanks a lot!).

In D45756#1050225, @emaste wrote:

In D45756#1050213, @bz wrote:

if you wait n channels * 300ms or so (say 10s), does a follow-up scan then still work or work again if you were to type scan once a second?

It remains FAIL-BUSY on a few tries over 60+ seconds.

Anyone?

Mark state to address Mark's comments.

Anyone? Anyone who can test the Intel debug on drm code?

In D45756#1048488, @emaste wrote:

I got:

> scan
OK

(a moment later)

> scan
FAIL-BUSY

In D45756#1048483, @emaste wrote:

Is there anything specific you'd like to see for testing this?

In D45888#1047565, @imp wrote:

In D45888#1047564, @bz wrote:

In D45888#1047563, @imp wrote:

In D45888#1047562, @bz wrote:

Can we please make sure pxeboot is small enough (again) before doing that bump so that we know that was a usable version at least

This won't change that... last i checked we were good with the text only loader as the payload for sure and the full graphics loader looked to be small enough.

I was just saying given whatever we currently install as pxeboot barfed on a Supermicro X10SRG-F (mercat) in the TestCluster a few days ago and I had to revert to an old version lying around somewhere again.

Ah. This is orthogonal... at worst you’ll get a this boot loader needs to be updated message.. it's harmless...

The other issue may be worth pursuing elsewhere though

In D45888#1047563, @imp wrote:

In D45888#1047562, @bz wrote:

Can we please make sure pxeboot is small enough (again) before doing that bump so that we know that was a usable version at least

This won't change that... last i checked we were good with the text only loader as the payload for sure and the full graphics loader looked to be small enough.

Can we please make sure pxeboot is small enough (again) before doing that bump so that we know that was a usable version at least?

Is the plan to remove linux_pci_[un]register_drm_driver() then in the future?

Update based on 'The Open Group Base Specifications Issue 7, 2018 edition'
as per updated link in the description.

Thanks for doing all this finding all bittlies and places!

Add Ed for the OpenSSH dependency (problem).