Re: HEADS UP: Merging drm update

2022-02-15 Thread Jun Ebihara 
From: Jun Ebihara 
Subject: Re: HEADS UP: Merging drm update
Date: Tue, 18 Jan 2022 08:31:01 +0900 (JST)

On Dynabook R63/P i5-5300U
 
works well:
  NetBSD 9.99.92 (GENERIC) #0: Mon Dec  6 04:25:36 UTC 2021

after update :
  NetBSD 9.99.93 (GENERIC) #0: Mon Feb 14 20:37:51 UTC 2022
- startx works.
- mate-session works.
- can't detect HDMI display connector.

dmesg
 https://github.com/ebijun/NetBSD/blob/master/dmesg/amd64/TOSHIBA_dynabook_R63P
 
dmesg diff
 
https://github.com/ebijun/NetBSD/commit/e8129abcfeea2237c53f7939ab3535d4b9626899#diff-c15e469826fbbbdb7eaa80395b80459cfabf482b8e57fbb4d0114b18d6df6753

+kern info: [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0
 intelfb0 at i915drmkms0
-warning: /usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_uncore.c:647: 
Unclaimed register detected before writing to register 0x41000
-intelfb0: framebuffer at 0xe00af000, size 1366x768, depth 32, stride 5504
+kern info: [drm] DRM_I915_DEBUG enabled
+kern info: [drm] DRM_I915_DEBUG_GEM enabled
+intelfb0: framebuffer at 0xe0001000, size 1366x768, depth 32, stride 5504
 wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using 
wskbd0

--
Jun Ebihara

Re: HEADS UP: Merging drm update

2022-01-22 Thread Germain Le Chapelain 
On Wed, 5 Jan 2022 10:20:45 +0200
Andrius V  wrote:

> I am also not sure how to redirect boot
> messages to serial attached through USB to see if any backtrace is
> available.

I had the same question actually!

I looked around for a bit, even for linux or what and couldn't find something 
obvious.  It sounds like it'd be helpful though!


Thank you,

Germain

-- 
Germain Le Chapelain

Re: HEADS UP: Merging drm update

2022-01-17 Thread Jun Ebihara 
On Dynabook R63/P i5-5300U

works well:
 NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021

after update :
NetBSD 9.99.93 (GENERIC) #0: Sun Jan 16 10:52:18 UTC 2022
- startx works.
- mate-session:
  background image, only shows upper 1/5 area.
  logout the session,panic.

dmesg
https://github.com/ebijun/NetBSD/blob/master/dmesg/amd64/TOSHIBA_dynabook_R63P

dmesg diff
https://github.com/ebijun/NetBSD/commit/e8129abcfeea2237c53f7939ab3535d4b9626899#diff-c15e469826fbbbdb7eaa80395b80459cfabf482b8e57fbb4d0114b18d6df6753

frame buffer address changed:
+kern info: [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0
 intelfb0 at i915drmkms0
-warning: /usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_uncore.c:647: 
Unclaimed register detected before writing to register 0x41000
-intelfb0: framebuffer at 0xe00af000, size 1366x768, depth 32, stride 5504
+kern info: [drm] DRM_I915_DEBUG enabled
+kern info: [drm] DRM_I915_DEBUG_GEM enabled
+intelfb0: framebuffer at 0xeb741000, size 1366x768, depth 32, stride 5504
 wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using w

--
Jun Ebihara

Re: HEADS UP: Merging drm update (Lenovo X230 mode switch issue in UEFI mode only, BIOS works)

2022-01-11 Thread Matthias Petermann 

Hello,

unfortunately my build was broken the night before last, so I had to 
restart yesterday. This morning I could now test with the changed FONT 
option. The error pattern is still unchanged - with deactivated CSM, the 
graphics switches to this disturbed mode at the modeswitch.


As expected, the font was changed by the FONT option, which shows that 
the first lines before the mode switch appear in the Spleen font.


I'm afraid these findings don't really help?

Best regards
Matthias


On 09.01.22 17:40, Matthias Petermann wrote:

Hello,

On 04.01.22 21:10, RVP wrote:


Can you check something else as well?

Compile a kernel with:

-
# Give us a choice of fonts based on monitor size
#options    FONT_BOLD8x16
#options    FONT_BOLD16x32
options FONT_SPLEEN12x24
-
Sorry for the delay... just started a build with this options you 
recommended. You can expect some result until tomorrow morning.


Kind regards
Matthias

Re: HEADS UP: Merging drm update (Lenovo X230 mode switch issue in UEFI mode only, BIOS works)

2022-01-09 Thread Matthias Petermann 

Hello,

On 04.01.22 21:10, RVP wrote:


Can you check something else as well?

Compile a kernel with:

-
# Give us a choice of fonts based on monitor size
#options    FONT_BOLD8x16
#options    FONT_BOLD16x32
options FONT_SPLEEN12x24
-
Sorry for the delay... just started a build with this options you 
recommended. You can expect some result until tomorrow morning.


Kind regards
Matthias

Re: HEADS UP: Merging drm update

2022-01-05 Thread Andrius V 
Hi,

I potentially have the same issue as Ryo with my mac mini based on
Intel i5-4278U with Iris graphics 5100. After DRM upgrade system goes
blank on boot just before intelfb attachment (I guess) and likely
crash (no logs messages available it seems). Before drm upgrade it
also goes blank at the same time but restores the view soon after. I
didn't follow full thread, but I may help to investigate/test if
there's anything I can do. I am also not sure how to redirect boot
messages to serial attached through USB to see if any backtrace is
available.



On Tue, Jan 4, 2022 at 12:05 PM Ryo ONODERA  wrote:
>
> Hi,
>
> Taylor R Campbell  writes:
>
> >> Date: Mon, 03 Jan 2022 22:08:26 +0900
> >> From: Ryo ONODERA 
> >>
> >> Ryo ONODERA  writes:
> >>
> >> > __engines_record_defaults
> >> > intel_gt_wait_for_idle
> >> > intel_gt_retire_requests_timeout
> >> > dma_fence_wait_timeout
> >> > i915_fence_wait (via *fence->ops->wait)
> >> > i915_request_wait
> >> >
> >> > In i915_request_wait, DRM_SPIN_TIMED_WAIT_UNTIL sets timeout=0
> >> > and i915_request_wait returns timeout=-ETIME.
> >
> > Thanks, I think there's something going wrong either with submitting
> > requests or noticing that they're submitted, but it only happens on
> > some machines.  It might be related to some of the other panics around
> > requests, like the cv_is_valid panic in signal_irq_work (56561), or it
> > might be something is mapped wrong or there's a missing cache flush /
> > bus_dmamap_sync...  Will investigate when I have a chance.
>
> Thank you.
>
> I will try to figure out my problem.
>
> --
> Ryo ONODERA // r...@tetera.org
> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update (Lenovo X230 mode switch issue in UEFI mode only, BIOS works)

2022-01-04 Thread RVP 

On Tue, 4 Jan 2022, Matthias Petermann wrote:

RVP's tip was good and I can also confirm on my side that the problem is not 
fundamentally caused by the actual UEFI boot process, but that only the 
enabling/disabling of the CSM affects it. Also, the problem did not exist in 
NetBSD 9.2 at all.




Can you check something else as well?

Compile a kernel with:

-
# Give us a choice of fonts based on monitor size
#optionsFONT_BOLD8x16
#optionsFONT_BOLD16x32
options FONT_SPLEEN12x24
-

ie. with a non-standard font. On my Asus X202E laptop (in CSM mode) the
system comes up OK, but, X hangs as soon as you start it with this
message being repeated every 3 secs. in the logs. (Power-off using the
power button works correctly and the system does an orderly shutdown
which is why I could collect these logs.)

-
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat rcs0 heartbeat 
{prio:-2147483645} not ticking
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat Awake? 4
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat Barriers?: no
Dec 27 09:04:51 x202e /netbsd: [  34.6986941] heartbeat Latency: 27us
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat Heartbeat: 3000 
ms ago
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat Reset count: 0 
(global 0)
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat Requests:
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat active  
3:4*-  @ 6000ms: X[2108]
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat 
ring->start:  0x7fffa000
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat 
ring->head:   0x0248
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat 
ring->tail:   0x04a8
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat 
ring->emit:   0x04a8
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat 
ring->space:  0x3d60
Dec 27 09:04:51 x202e /netbsd: [  34.6986941] heartbeat 
ring->hwsp:   0x7fffe100
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat [head 0248, postfix 
0300, tail 0318, batch 0x_5000]:
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] warning: 
/usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_engine_cs.c:1234: 
WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos, rowsize, sizeof(u32), line, 
sizeof(line), 0) >= sizeof(line))heartbeat [] 027a 02001000  
 027a 1c4c1501 80f0ff7f 
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] 027a a1501001 80f0ff7f 
 0111 2022 f
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat [0020] 027a 
a1501001 80f0ff7f  0111 2022  0111
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] 2822 bf7f 01004012 
2822 00f0ff7f 0111 c
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat [0040] 2822 
bf7f 01004012 2822 00f0ff7f 0111 c020 00020002
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] 027a a1501001 80f0ff7f 
 027a 02001000 0
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] 2822 60] 027a 
a1501001 80f0ff7f  027a 02001000  
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] 027a 1c4c1501 80f0ff7f 
 0004  0
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat [0080] 027a 
1c4c1501 80f0ff7f  0004  000c 0c01ff7f
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat [0080] 027a 
1c4c1501 80f0ff7f 0 0
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat [0080]  
0104 8018 0050 00018018 a010 027a a1501001
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] 00e1ff7f 0400 0001 

Dec 27 09:04:51 x202e /netbsd: 
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat 	On hold?: 0

Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat MMIO base:  
0x2000
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat CCID: 0x7fff010d
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat RING_START: 
0x7fffa000
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat RING_HEAD:  
0x02e8
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat RING_TAIL:  
0x04a8
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat RING_CTL:   
0x3001
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat RING_MODE:  
0x4000
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat RING_IMR: 
ffde
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat ACTHD:  
0x_02e8
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat BBADDR: 
0x_7fff1230
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat DMA_FADDR: 
0x_7fffa2e8
Dec 27 09:04:51 x202e /netbsd: [ 234.6986941] heartbeat

Re: HEADS UP: Merging drm update

2022-01-04 Thread Ryo ONODERA 
Hi,

Taylor R Campbell  writes:

>> Date: Mon, 03 Jan 2022 22:08:26 +0900
>> From: Ryo ONODERA 
>> 
>> Ryo ONODERA  writes:
>> 
>> > __engines_record_defaults
>> > intel_gt_wait_for_idle
>> > intel_gt_retire_requests_timeout
>> > dma_fence_wait_timeout
>> > i915_fence_wait (via *fence->ops->wait)
>> > i915_request_wait
>> >
>> > In i915_request_wait, DRM_SPIN_TIMED_WAIT_UNTIL sets timeout=0
>> > and i915_request_wait returns timeout=-ETIME.
>
> Thanks, I think there's something going wrong either with submitting
> requests or noticing that they're submitted, but it only happens on
> some machines.  It might be related to some of the other panics around
> requests, like the cv_is_valid panic in signal_irq_work (56561), or it
> might be something is mapped wrong or there's a missing cache flush /
> bus_dmamap_sync...  Will investigate when I have a chance.

Thank you.

I will try to figure out my problem.

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update

2022-01-03 Thread Taylor R Campbell 
> Date: Mon, 03 Jan 2022 22:08:26 +0900
> From: Ryo ONODERA 
> 
> Ryo ONODERA  writes:
> 
> > __engines_record_defaults
> > intel_gt_wait_for_idle
> > intel_gt_retire_requests_timeout
> > dma_fence_wait_timeout
> > i915_fence_wait (via *fence->ops->wait)
> > i915_request_wait
> >
> > In i915_request_wait, DRM_SPIN_TIMED_WAIT_UNTIL sets timeout=0
> > and i915_request_wait returns timeout=-ETIME.

Thanks, I think there's something going wrong either with submitting
requests or noticing that they're submitted, but it only happens on
some machines.  It might be related to some of the other panics around
requests, like the cv_is_valid panic in signal_irq_work (56561), or it
might be something is mapped wrong or there's a missing cache flush /
bus_dmamap_sync...  Will investigate when I have a chance.

Re: HEADS UP: Merging drm update

2022-01-03 Thread Ryo ONODERA 
Hi,

If you missed, could you read my following email?

Thank you.

Ryo ONODERA  writes:

> Hi,
>
> Taylor R Campbell  writes:
>
>>> Date: Tue, 28 Dec 2021 11:34:43 +0900
>>> From: Ryo ONODERA 
>>> 
>>> intel_gt_pm_fini() at netbsd:intel_gt_pm_fini+0x18
>>> intel_gt_init() at netbsd:intel_gt_init+0x6ad
>>> i915_gem_init() at netbsd:i915_gem_init+0x14d
>>> i915_driver_probe() at netbsd:i915_driver_probe+0x949
>>> i915drmkms_attach_real() at netbsd:i915drmkms_attach_real+0x4c
>>> config_mountroot_thread() at netbsd:config_mountroot_thread+0x60
>>
>> So intel_gt_init is failing on boot, and the driver has decided to
>> give up -- and proximate cause of the crash is that one of the error
>> branches is screwy, but while it would be nice to fix the error
>> branches it's more important to find why we're reaching them in the
>> first place.
>>
>> Can you get a line number for intel_gt_init+0x6ad, and can you also
>> insert prints into every error branch of intel_gt_init to find out
>> which one it is and how it fails?  And maybe do that recursively in
>> whichever branch does fail?
>
> In sys/external/bsd/drm2/dist/drm/i915/gt/intel_gt.c: intel_gt_init(),
> __engines_record_defaults(gt) failed and went to err_gt label,
> then the panic happened.
> "intel_gt_init+0x6ad" is err_uc_init's intel_uc_fini(>uc).
>
> (snip)
> err = __engines_record_defaults(gt);
> if (err)
> goto err_gt;
> (snip)
> err_gt:
> __intel_gt_disable(gt);
> intel_uc_fini_hw(>uc);
> err_uc_init:
> intel_uc_fini(>uc);
> err_engines:
> intel_engines_release(gt);
> i915_vm_put(fetch_and_zero(>vm));
> err_pm:
> intel_gt_pm_fini(gt);
> intel_gt_fini_scratch(gt);
> out_fw:
> if (err)
> (snip)
>
>
> And I have added some printfs to __engines_record_defaults() and
> the other functions invoked from __engines_record_defaults() as follows.
>
> __engines_record_defaults
> intel_gt_wait_for_idle
> intel_gt_retire_requests_timeout
> dma_fence_wait_timeout
> i915_fence_wait (via *fence->ops->wait)
> i915_request_wait
>
> In i915_request_wait, DRM_SPIN_TIMED_WAIT_UNTIL sets timeout=0
> and i915_request_wait returns timeout=-ETIME.
>
> #ifdef __NetBSD__
> spin_lock(rq->fence.lock);
> #define C   (i915_request_completed(rq) ? 1 : 
> \
> (spin_unlock(rq->fence.lock), 
> \
> intel_engine_flush_submission(rq->engine),
> \
> spin_lock(rq->fence.lock),
> \
> i915_request_completed(rq)))
> if (flags & I915_WAIT_INTERRUPTIBLE) {
> DRM_SPIN_TIMED_WAIT_UNTIL(timeout, ,
> rq->fence.lock, timeout,
> C);
> } else {
> DRM_SPIN_TIMED_WAIT_NOINTR_UNTIL(timeout, ,
> rq->fence.lock, timeout,
> C);
> }
> #undef  C
> if (timeout > 0) {  /* succeeded before timeout */
> KASSERT(i915_request_completed(rq));
> dma_fence_signal_locked(>fence);
> } else if (timeout == 0) {  /* timed out */
> timeout = -ETIME;
> }
> spin_unlock(rq->fence.lock);
> DRM_DESTROY_WAITQUEUE();
> #else
>
>
> Thank you.
>
> -- 
> Ryo ONODERA // r...@tetera.org
> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update (Lenovo X230 mode switch issue in UEFI mode only, BIOS works)

2021-12-31 Thread Rhialto 
On Fri 31 Dec 2021 at 11:30:32 +0100, Matthias Petermann wrote:
> - When I boot current in UEFI mode, after the mode switch it only displays a
> blank screen with a white background. After that, within a few seconds, a
> kind of randomly structured dark spot develops from the center of the
> screen, which then stretches to the edge of the screen [1].

I think I have seen that sort of effect in the past when playing with
various sleep modes of my laptop. It may be that the display (or some
display-related thing) is powered off and decaying.

-Olaf.
-- 
___ "Buying carbon credits is a bit like a serial killer paying someone else to
\X/  have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto



signature.asc
Description: PGP signature

Re: HEADS UP: Merging drm update (Lenovo X230 mode switch issue in UEFI mode only, BIOS works)

2021-12-31 Thread Taylor R Campbell 
> Date: Fri, 31 Dec 2021 11:30:32 +0100
> From: Matthias Petermann 
> 
> - When I boot current in UEFI mode, after the mode switch it only 
> displays a blank screen with a white background. After that, within a 
> few seconds, a kind of randomly structured dark spot develops from the 
> center of the screen, which then stretches to the edge of the screen [1].

Can you get dmesg from the previous boot if you reboot back in BIOS
mode?  Or can you ssh in and get it, or get it over a serial console?

Re: HEADS UP: Merging drm update (Lenovo X230 mode switch issue in UEFI mode only, BIOS works)

2021-12-31 Thread Matthias Petermann 

Hello,

first of all, thanks for the effort to bring an up-to-date DRM to 
NetBSD! Proper graphics support is essential for most users and 
therefore the work cannot be appreciated enough.


I have now also managed to test current on my laptop and made an 
observation that I would like to share and hopefully be able to help to 
clarify / fix the underlying issue.


The Laptop is a Lenovo X230 model with i5 CPU and integrated intel 
graphics. It can boot NetBSD in both - BIOS (CSM) and UEFI mode.


- With NetBSD 9.2, the mode switch (when initializing the i915drmkms0 
device) works fine in both boot modes.


- In current from 28.12.2021 the mode switch only works when I boot in 
BIOS mode.


- When I boot current in UEFI mode, after the mode switch it only 
displays a blank screen with a white background. After that, within a 
few seconds, a kind of randomly structured dark spot develops from the 
center of the screen, which then stretches to the edge of the screen [1].


One (not necessarily related) observation: after the appearance of the 
above-mentioned spot, I turn off the laptop and boot back into NetBSD 
9.2. Immediately afterwards, I have a strange flickering on the display, 
which is especially noticeable with brighter colors. The graphical 
display seems normal otherwise. The flickering then disappeared again 
over time. Although I have absolutely no idea about it, my first thought 
was that the dark spot could be some kind of thermal problem that occurs 
with the mode switch? Is this possible?


In any case, I would like to help track down the problem. I'm building a 
current from the current sources and then setting up an identical laptop 
as a test machine. In the meantime, I'd appreciate any hints on what 
might be needed as diagnostic data.


Many greetings
Matthias

[1] http://www.petermann-it.de/netbsd/netbsd-drm.mp4
(SSL certicate renewal in progress)

Re: HEADS UP: Merging drm update

2021-12-29 Thread Ryo ONODERA 
Hi,

Taylor R Campbell  writes:

>> Date: Tue, 28 Dec 2021 11:34:43 +0900
>> From: Ryo ONODERA 
>> 
>> intel_gt_pm_fini() at netbsd:intel_gt_pm_fini+0x18
>> intel_gt_init() at netbsd:intel_gt_init+0x6ad
>> i915_gem_init() at netbsd:i915_gem_init+0x14d
>> i915_driver_probe() at netbsd:i915_driver_probe+0x949
>> i915drmkms_attach_real() at netbsd:i915drmkms_attach_real+0x4c
>> config_mountroot_thread() at netbsd:config_mountroot_thread+0x60
>
> So intel_gt_init is failing on boot, and the driver has decided to
> give up -- and proximate cause of the crash is that one of the error
> branches is screwy, but while it would be nice to fix the error
> branches it's more important to find why we're reaching them in the
> first place.
>
> Can you get a line number for intel_gt_init+0x6ad, and can you also
> insert prints into every error branch of intel_gt_init to find out
> which one it is and how it fails?  And maybe do that recursively in
> whichever branch does fail?

In sys/external/bsd/drm2/dist/drm/i915/gt/intel_gt.c: intel_gt_init(),
__engines_record_defaults(gt) failed and went to err_gt label,
then the panic happened.
"intel_gt_init+0x6ad" is err_uc_init's intel_uc_fini(>uc).

(snip)
err = __engines_record_defaults(gt);
if (err)
goto err_gt;
(snip)
err_gt:
__intel_gt_disable(gt);
intel_uc_fini_hw(>uc);
err_uc_init:
intel_uc_fini(>uc);
err_engines:
intel_engines_release(gt);
i915_vm_put(fetch_and_zero(>vm));
err_pm:
intel_gt_pm_fini(gt);
intel_gt_fini_scratch(gt);
out_fw:
if (err)
(snip)


And I have added some printfs to __engines_record_defaults() and
the other functions invoked from __engines_record_defaults() as follows.

__engines_record_defaults
intel_gt_wait_for_idle
intel_gt_retire_requests_timeout
dma_fence_wait_timeout
i915_fence_wait (via *fence->ops->wait)
i915_request_wait

In i915_request_wait, DRM_SPIN_TIMED_WAIT_UNTIL sets timeout=0
and i915_request_wait returns timeout=-ETIME.

#ifdef __NetBSD__
spin_lock(rq->fence.lock);
#define C   (i915_request_completed(rq) ? 1 : \
(spin_unlock(rq->fence.lock), \
intel_engine_flush_submission(rq->engine),\
spin_lock(rq->fence.lock),\
i915_request_completed(rq)))
if (flags & I915_WAIT_INTERRUPTIBLE) {
DRM_SPIN_TIMED_WAIT_UNTIL(timeout, ,
rq->fence.lock, timeout,
C);
} else {
DRM_SPIN_TIMED_WAIT_NOINTR_UNTIL(timeout, ,
rq->fence.lock, timeout,
C);
}
#undef  C
if (timeout > 0) {  /* succeeded before timeout */
KASSERT(i915_request_completed(rq));
dma_fence_signal_locked(>fence);
} else if (timeout == 0) {  /* timed out */
timeout = -ETIME;
}
spin_unlock(rq->fence.lock);
DRM_DESTROY_WAITQUEUE();
#else


Thank you.

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update

2021-12-28 Thread Taylor R Campbell 
> Date: Tue, 28 Dec 2021 11:34:43 +0900
> From: Ryo ONODERA 
> 
> intel_gt_pm_fini() at netbsd:intel_gt_pm_fini+0x18
> intel_gt_init() at netbsd:intel_gt_init+0x6ad
> i915_gem_init() at netbsd:i915_gem_init+0x14d
> i915_driver_probe() at netbsd:i915_driver_probe+0x949
> i915drmkms_attach_real() at netbsd:i915drmkms_attach_real+0x4c
> config_mountroot_thread() at netbsd:config_mountroot_thread+0x60

So intel_gt_init is failing on boot, and the driver has decided to
give up -- and proximate cause of the crash is that one of the error
branches is screwy, but while it would be nice to fix the error
branches it's more important to find why we're reaching them in the
first place.

Can you get a line number for intel_gt_init+0x6ad, and can you also
insert prints into every error branch of intel_gt_init to find out
which one it is and how it fails?  And maybe do that recursively in
whichever branch does fail?

Re: HEADS UP: Merging drm update

2021-12-27 Thread Ryo ONODERA 
Hi,

Taylor R Campbell  writes:

>> Date: Tue, 28 Dec 2021 08:41:16 +0900
>> From: Ryo ONODERA 
>> 
>> panic: mutex_vector_enter,518: uninitialized lock (lock=0xd80023501458, 
>> from=807c091c)
>> cpu0: Begin traceback...
>> vpanic() at netbsd:vpanic+0x156
>> panic() at netbsd:panic+0x3c
>> lockdebug_wantlock() at netbsd:lockdebug_wantlock+0x180
>> mutex_enter() at netbsd:mutex_enter+0x213
>> intel_rps_mark_interactive() at netbsd:intel_rps_mark_interactive+0x1e
>
> Weird -- can you insert db_stacktrace() into intel_rps_init_early and
> intel_rps_fini?  This looks like i915->gt.rps.power.mutex, judging by
> the stack trace, but I don't see how we can get here without first
> initializing the mutex.

Thanks for your suggestion.

With the following patch,

Index: sys/external/bsd/drm2/dist/drm/i915/gt/intel_rps.c
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_rps.c,v
retrieving revision 1.5
diff -u -r1.5 intel_rps.c
--- sys/external/bsd/drm2/dist/drm/i915/gt/intel_rps.c  19 Dec 2021 12:32:15 
-  1.5
+++ sys/external/bsd/drm2/dist/drm/i915/gt/intel_rps.c  28 Dec 2021 02:32:37 
-
@@ -9,6 +9,10 @@
 #include 
 __KERNEL_RCSID(0, "$NetBSD: intel_rps.c,v 1.5 2021/12/19 12:32:15 riastradh 
Exp $");
 
+#if 1
+#include 
+#endif
+
 #include "i915_drv.h"
 #include "intel_gt.h"
 #include "intel_gt_irq.h"
@@ -1618,6 +1622,9 @@
 
 void intel_rps_init_early(struct intel_rps *rps)
 {
+#if 1
+   db_stacktrace()
+#endif
mutex_init(>lock);
mutex_init(>power.mutex);
 
@@ -1679,6 +1686,9 @@
 
 void intel_rps_fini(struct intel_rps *rps)
 {
+#if 1
+   db_stacktrace()
+#endif
 
mutex_destroy(>power.mutex);
mutex_destroy(>lock);

I have gotten dmesg here:

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
2018, 2019, 2020, 2021 The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 9.99.93 (LOCKDEBUG) #1: Tue Dec 28 11:26:27 JST 2021
ryoon@brownie:/usr/world/9.99/amd64/obj/sys/arch/amd64/compile/LOCKDEBUG
total memory = 15961 MB
avail memory = 15405 MB
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
efi: systbl at pa 5697d018
mainbus0 (root)
ACPI: RSDP 0x63FFE014 24 (v02 DELL  )
ACPI: XSDT 0x63F9C188 F4 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FACP 0x63FF6000 000114 (v06 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: DSDT 0x63FB3000 03F8DE (v02 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FACS 0x63EDF000 40
ACPI: SSDT 0x63FFB000 001B61 (v02 CpuRef CpuSsdt  3000 INTL 
20180927)
ACPI: SSDT 0x63FF7000 003C64 (v02 INTEL  DptfTabl 1000 INTL 
20180927)
ACPI: HPET 0x63FF5000 38 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: APIC 0x63FF4000 00012C (v03 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: MCFG 0x63FF3000 3C (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FB2000 0008D9 (v02 DELL   DellRtd3 1000 INTL 
20180927)
ACPI: NHLT 0x63FB1000 2D (v00 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FB 000CB8 (v02 DELL   UsbCTabl 1000 INTL 
20180927)
ACPI: SSDT 0x63FAF000 000612 (v02 DELL   Tpm2Tabl 1000 INTL 
20180927)
ACPI: TPM2 0x63FAE000 34 (v04 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: LPIT 0x63FAD000 94 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FAC000 000B75 (v02 DELL   PtidDevc 1000 INTL 
20180927)
ACPI: SSDT 0x63FAB000 000FBB (v02 DELL   TbtTypeC  INTL 
20180927)
ACPI: DBGP 0x63FAA000 34 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: DBG2 0x63FA9000 54 (v00 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SLIC 0x63FA8000 000176 (v03 DELL   CBX3 06222004 MSFT 
00010013)
ACPI: BOOT 0x63FA7000 28 (v01 DELL   CBX3 20170001 ??LL 
20160422)
ACPI: MSDM 0x63FA6000 55 (v03 DELL   CBX3 06222004 AMI  
00010013)
ACPI: SSDT 0x63FA4000 001554 (v02 SaSsdt SaSsdt   3000 INTL 
20180927)
ACPI: SSDT 0x63F9D000 006C63 (v02 INTEL  TcssSsdt 1000 INTL 
20180927)
ACPI: DMAR 0x63FFD000 B0 (v02 INTEL  Dell Inc 0002  
0113)
ACPI: SSDT 0x63F9B000 000BE6 (v02 DELL   xh_Dell_  INTL 
20180927)
ACPI: SSDT 0x63F9A000 000156 (v02 Dell   ADebTabl 1000 INTL 
20180927)
ACPI: BGRT 0x63F99000 38 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FPDT 0x63F98000 34 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: 12 ACPI AML tables successfully acquired and loaded

Re: HEADS UP: Merging drm update

2021-12-27 Thread Taylor R Campbell 
> Date: Tue, 28 Dec 2021 08:41:16 +0900
> From: Ryo ONODERA 
> 
> panic: mutex_vector_enter,518: uninitialized lock (lock=0xd80023501458, 
> from=807c091c)
> cpu0: Begin traceback...
> vpanic() at netbsd:vpanic+0x156
> panic() at netbsd:panic+0x3c
> lockdebug_wantlock() at netbsd:lockdebug_wantlock+0x180
> mutex_enter() at netbsd:mutex_enter+0x213
> intel_rps_mark_interactive() at netbsd:intel_rps_mark_interactive+0x1e

Weird -- can you insert db_stacktrace() into intel_rps_init_early and
intel_rps_fini?  This looks like i915->gt.rps.power.mutex, judging by
the stack trace, but I don't see how we can get here without first
initializing the mutex.

Re: HEADS UP: Merging drm update

2021-12-27 Thread Taylor R Campbell 
> Date: Mon, 27 Dec 2021 12:34:10 +0900
> From: Ryo ONODERA 
> 
> panic: kernel diagnostic assertion "!(!i915_request_completed(rq))" failed: 
> file "/usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_gt.c", line 475 

I committed a change that I think will fix the particular bug leading
to this assertion, but I suspect it won't fix the underlying issue.
Nevertheless, can you cvs up and try again?

Re: HEADS UP: Merging drm update

2021-12-27 Thread Martin Husemann 
On Mon, Dec 27, 2021 at 06:58:34PM +0900, Ryo ONODERA wrote:
> Hi,
> 
> My previous dmesg is confusing.
> Two messages are accidentally concatenated. The former message has no newline.
> They should be splitted as follows.
> 
> panic: i915drmkms0: notice: DMC firmware homepage:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

Yeah, I get the same. I downloaded the firmware blob from that git repo,
but now am not sure where to put it on the machine so the driver would
find it. Since it talks about i915/skl_dmc_ver1_27.bin I thought putting
it into /libdata/firmware/i915/skl_dmc_ver1_27.bin should work - but it
doesn't.

Martin

Re: HEADS UP: Merging drm update

2021-12-27 Thread Ryo ONODERA 
Hi,

My previous dmesg is confusing.
Two messages are accidentally concatenated. The former message has no newline.
They should be splitted as follows.

panic: i915drmkms0: notice: DMC firmware homepage:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

kernel diagnostic assertion "!(!i915_request_completed(rq))" failed:
file "/usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_gt.c",
line 475

Thank you.

On Mon, Dec 27, 2021 at 4:26 PM Martin Husemann  wrote:
>
> On Mon, Dec 27, 2021 at 12:34:10PM +0900, Ryo ONODERA wrote:
> > "panic: i915drmkms0: notice: DMC firmware homepage:
>
> Where would the firmware need to be?
>
> /libdata/firmware/i915/skl_dmc_ver1_27.bin
>
> obviously is not the right place.
>
> Martin

Re: HEADS UP: Merging drm update

2021-12-26 Thread Martin Husemann 
On Mon, Dec 27, 2021 at 12:34:10PM +0900, Ryo ONODERA wrote:
> "panic: i915drmkms0: notice: DMC firmware homepage: 

Where would the firmware need to be?

/libdata/firmware/i915/skl_dmc_ver1_27.bin

obviously is not the right place.

Martin

Re: HEADS UP: Merging drm update

2021-12-26 Thread Ryo ONODERA 
Hi,

Taylor R Campbell  writes:

> Can you try the attached patch?  Also, if you haven't already, can you
> try running a DIAGNOSTIC/DEBUG/LOCKDEBUG kernel?

Thanks for your patch.
It seems that it is already in src tree.

My laptop has no Intel AMT support.
I have added as follows:

options DDB_COMMANDONENTER="bt;sync"
options DIAGNOSTIC
options DEBUG
options LOCKDEBUG

And I have gotten the following dmesg.
"panic: i915drmkms0: notice: DMC firmware homepage: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915kernel
 diagnostic assertion "!(!i915_request_completed(rq))" failed: file 
"/usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_gt.c", line 475"
is critical part for my laptop.
I should enable debug mode more earlier...

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
2018, 2019, 2020, 2021 The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 9.99.93 (DTRACE7) #7: Mon Dec 27 11:57:21 JST 2021
ryoon@brownie:/usr/world/9.99/amd64/obj/sys/arch/amd64/compile/DTRACE7
total memory = 15961 MB
avail memory = 15405 MB
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
efi: systbl at pa 5697d018
mainbus0 (root)
ACPI: RSDP 0x63FFE014 24 (v02 DELL  )
ACPI: XSDT 0x63F9C188 F4 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FACP 0x63FF6000 000114 (v06 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: DSDT 0x63FB3000 03F8DE (v02 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FACS 0x63EDF000 40
ACPI: SSDT 0x63FFB000 001B61 (v02 CpuRef CpuSsdt  3000 INTL 
20180927)
ACPI: SSDT 0x63FF7000 003C64 (v02 INTEL  DptfTabl 1000 INTL 
20180927)
ACPI: HPET 0x63FF5000 38 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: APIC 0x63FF4000 00012C (v03 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: MCFG 0x63FF3000 3C (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FB2000 0008D9 (v02 DELL   DellRtd3 1000 INTL 
20180927)
ACPI: NHLT 0x63FB1000 2D (v00 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FB 000CB8 (v02 DELL   UsbCTabl 1000 INTL 
20180927)
ACPI: SSDT 0x63FAF000 000612 (v02 DELL   Tpm2Tabl 1000 INTL 
20180927)
ACPI: TPM2 0x63FAE000 34 (v04 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: LPIT 0x63FAD000 94 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FAC000 000B75 (v02 DELL   PtidDevc 1000 INTL 
20180927)
ACPI: SSDT 0x63FAB000 000FBB (v02 DELL   TbtTypeC  INTL 
20180927)
ACPI: DBGP 0x63FAA000 34 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: DBG2 0x63FA9000 54 (v00 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SLIC 0x63FA8000 000176 (v03 DELL   CBX3 06222004 MSFT 
00010013)
ACPI: BOOT 0x63FA7000 28 (v01 DELL   CBX3 20170001 ??LL 
20160422)
ACPI: MSDM 0x63FA6000 55 (v03 DELL   CBX3 06222004 AMI  
00010013)
ACPI: SSDT 0x63FA4000 001554 (v02 SaSsdt SaSsdt   3000 INTL 
20180927)
ACPI: SSDT 0x63F9D000 006C63 (v02 INTEL  TcssSsdt 1000 INTL 
20180927)
ACPI: DMAR 0x63FFD000 B0 (v02 INTEL  Dell Inc 0002  
0113)
ACPI: SSDT 0x63F9B000 000BE6 (v02 DELL   xh_Dell_  INTL 
20180927)
ACPI: SSDT 0x63F9A000 000156 (v02 Dell   ADebTabl 1000 INTL 
20180927)
ACPI: BGRT 0x63F99000 38 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FPDT 0x63F98000 34 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: 12 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x20, 120 pins
x2APIC available but disabled by DMAR table
cpu0 at mainbus0 apid 0
cpu0: Use lfence to serialize rdtsc
cpu0: CPU base freq 15 Hz
cpu0: CPU max freq 39 Hz
cpu0: TSC freq CPUID 149760 Hz
cpu0: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu0: node 0, package 0, core 0, smt 0
cpu1 at mainbus0 apid 2
cpu1: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu1: node 0, package 0, core 1, smt 0
cpu2 at mainbus0 apid 4
cpu2: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu2: node 0, package 0, core 2, smt 0
cpu3 at mainbus0 apid 6
cpu3: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu3: node 0, package 0, core 3, smt 0
cpu4 at mainbus0 apid 1
cpu4: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu4: node 0, package 0, core 0, smt 1
cpu5 at mainbus0 apid 3
cpu5: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu5: node 0, package 0, core 1, smt 1
cpu6 at mainbus0

Re: HEADS UP: Merging drm update

2021-12-26 Thread Taylor R Campbell 
Can you try the attached patch?  Also, if you haven't already, can you
try running a DIAGNOSTIC/DEBUG/LOCKDEBUG kernel?
>From 025745d6f43aff21c88bc9e3b393ce146fc9af04 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell 
Date: Sun, 26 Dec 2021 16:05:20 +
Subject: [PATCH] drm: Fix locking around accurate vblank counts.

- Make drm_crtc_accurate_vblank_count require the caller to hold the
  event lock, rather than take it internally.

- Fix locking around drm_crtc_accurate_vblank_count and related
  operations in amdgpu and nouveau interrupt handlers.

- Use drm_crtc_vblank_put_locked, not drm_crtc_vblank_put, when we
  already hold the event lock.
---
 .../dist/drm/amd/display/amdgpu_dm/amdgpu_dm.c|  2 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c |  2 ++
 sys/external/bsd/drm2/dist/drm/drm_vblank.c   | 15 ++-
 .../drm/nouveau/dispnv50/nouveau_dispnv50_disp.c  |  2 +-
 4 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/sys/external/bsd/drm2/dist/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/sys/external/bsd/drm2/dist/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c8cbf7a6f68e..d0386f514457 100644
--- a/sys/external/bsd/drm2/dist/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/sys/external/bsd/drm2/dist/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -361,7 +361,7 @@ static void dm_pflip_high_irq(void *interrupt_params)
drm_crtc_send_vblank_event(_crtc->base, e);
 
/* Event sent, so done with vblank for this flip */
-   drm_crtc_vblank_put(_crtc->base);
+   drm_crtc_vblank_put_locked(_crtc->base);
}
} else if (e) {
/* VRR active and inside front-porch: vblank count and
diff --git 
a/sys/external/bsd/drm2/dist/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c 
b/sys/external/bsd/drm2/dist/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index 79cb94ea67dc..5a154037c524 100644
--- a/sys/external/bsd/drm2/dist/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/sys/external/bsd/drm2/dist/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -319,7 +319,9 @@ void amdgpu_dm_crtc_handle_crc_irq(struct drm_crtc *crtc)
   [0], [1], [2]))
return;
 
+   spin_lock(>dev->event_lock);
drm_crtc_add_crc_entry(crtc, true,
   drm_crtc_accurate_vblank_count(crtc), 
crcs);
+   spin_unlock(>dev->event_lock);
}
 }
diff --git a/sys/external/bsd/drm2/dist/drm/drm_vblank.c 
b/sys/external/bsd/drm2/dist/drm/drm_vblank.c
index 9ced81bd7ed8..ec91bbe9391b 100644
--- a/sys/external/bsd/drm2/dist/drm/drm_vblank.c
+++ b/sys/external/bsd/drm2/dist/drm/drm_vblank.c
@@ -337,7 +337,7 @@ static u64 drm_vblank_count(struct drm_device *dev, 
unsigned int pipe)
  * This is mostly useful for hardware that can obtain the scanout position, but
  * doesn't have a hardware frame counter.
  */
-static u64 drm_crtc_accurate_vblank_count_locked(struct drm_crtc *crtc)
+u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
@@ -358,17 +358,6 @@ static u64 drm_crtc_accurate_vblank_count_locked(struct 
drm_crtc *crtc)
 
return vblank;
 }
-
-u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
-{
-   u64 vblank;
-
-   spin_lock(>dev->event_lock);
-   vblank = drm_crtc_accurate_vblank_count_locked(crtc);
-   spin_unlock(>dev->event_lock);
-
-   return vblank;
-}
 EXPORT_SYMBOL(drm_crtc_accurate_vblank_count);
 
 static void __disable_vblank(struct drm_device *dev, unsigned int pipe)
@@ -972,7 +961,7 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
assert_spin_locked(>event_lock);
 
e->pipe = pipe;
-   e->sequence = drm_crtc_accurate_vblank_count_locked(crtc) + 1;
+   e->sequence = drm_crtc_accurate_vblank_count(crtc) + 1;
list_add_tail(>base.link, >vblank_event_list);
 }
 EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
diff --git 
a/sys/external/bsd/drm2/dist/drm/nouveau/dispnv50/nouveau_dispnv50_disp.c 
b/sys/external/bsd/drm2/dist/drm/nouveau/dispnv50/nouveau_dispnv50_disp.c
index b9423cdc84fb..f49bb2ddf56d 100644
--- a/sys/external/bsd/drm2/dist/drm/nouveau/dispnv50/nouveau_dispnv50_disp.c
+++ b/sys/external/bsd/drm2/dist/drm/nouveau/dispnv50/nouveau_dispnv50_disp.c
@@ -2136,9 +2136,9 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
*state)
if (new_crtc_state->event) {
unsigned long flags;
/* Get correct count/ts if racing with vblank irq */
+   spin_lock_irqsave(>dev->event_lock, flags);
if (new_crtc_state->active)
drm_crtc_accurate_vblank_count(crtc);
-   spin_lock_irqsave(>dev->event_lock, flags);
drm_crtc_send_vblank_event(crtc,

Re: HEADS UP: Merging drm update

2021-12-26 Thread iquiw 
Hi,

New drm works great with my NVIDIA GT 710.
Manual scaling by xrandr, which is required before, is no longer necessary.
Boot time gets faster, and I have better font looking.

Thank you so much!!

On Sun, Dec 19, 2021 at 2:06 AM Taylor R Campbell  wrote:
>
> I'm planning to merge the drm update this weekend -- a cvs import and
> merge commit, plus about 1300 commits on top of that from the git
> repository.
>
> Please don't commit anything to the following subtrees until done --
> if you do, your changes will be lost:
>
> sys/external/bsd/drm2
> sys/external/bsd/common
>
> Please don't touch the following additional files outside those
> subtrees:
>
> sys/arch/arm/nvidia/tegra_drm.c
> sys/arch/arm/nvidia/tegra_drm.h
> sys/arch/arm/nvidia/tegra_drm_fb.c
> sys/arch/arm/nvidia/tegra_drm_mode.c
> sys/arch/arm/nvidia/tegra_fb.c
> sys/arch/arm/nvidia/tegra_nouveau.c
> sys/arch/arm/nxp/imx6_dwhdmi.c
> sys/arch/arm/rockchip/rk_anxdp.c
> sys/arch/arm/rockchip/rk_drm.c
> sys/arch/arm/rockchip/rk_drm.h
> sys/arch/arm/rockchip/rk_dwhdmi.c
> sys/arch/arm/rockchip/rk_fb.c
> sys/arch/arm/rockchip/rk_vop.c
> sys/arch/arm/sunxi/sunxi_drm.c
> sys/arch/arm/sunxi/sunxi_drm.h
> sys/arch/arm/sunxi/sunxi_dwhdmi.c
> sys/arch/arm/sunxi/sunxi_fb.c
> sys/arch/arm/sunxi/sunxi_hdmiphy.h
> sys/arch/arm/sunxi/sunxi_lcdc.c
> sys/arch/arm/sunxi/sunxi_mixer.c
> sys/arch/arm/ti/ti_fb.c
> sys/arch/arm/ti/ti_lcdc.c
> sys/arch/arm/ti/ti_lcdc.h
> sys/dev/fdt/fdt_panel.c
> sys/dev/fdt/hdmi_connector.c
> sys/dev/i2c/anxedp.c
> sys/dev/i2c/tda19988.c
> sys/dev/ic/anx_dp.c
> sys/dev/ic/anx_dp.h
> sys/dev/ic/dw_hdmi.c
> sys/dev/ic/dw_hdmi.h
> sys/dev/ic/dw_hdmi_phy.c
> sys/dev/videomode/edidvar.h
> sys/modules/*drmkms*
> sys/sys/agpio.h

Re: HEADS UP: Merging drm update

2021-12-25 Thread Taylor R Campbell 
> Date: Sun, 26 Dec 2021 02:37:31 +0900
> From: Ryo ONODERA 
> 
> If panic is removed, my LCD turns black finally and stay black forever
> and does not reach to USB serial console.
> [...]
> However I am not sure because I cannot get any message.
> 
> Do you have an idea to investigate deeper?

Does your laptop have anything like Intel AMT which you could use to
get serial-over-LAN?

Maybe you can put in a panic later, after the display changes, and
build your kernel with DDB_COMMANDONENTER="bt;sync", so you might be
able to either (a) get a crash dump or (b) see the last boot's dmesg
when the machine resets (and you then boot an older kernel)?

Re: HEADS UP: Merging drm update

2021-12-25 Thread Ryo ONODERA 
Hi,

Ryo ONODERA  writes:

> Hi,
>
> Taylor R Campbell  writes:
>
>> Better yet -- can you try the attached patch?
>> From e484fe666999730543f490ce6084486f7d7ce524 Mon Sep 17 00:00:00 2001
>> From: Taylor R Campbell 
>> Date: Fri, 24 Dec 2021 11:12:43 +
>> Subject: [PATCH] i915: Use AcpiOsMapMemory, not bus_space_map, for opregion.
>>
>> Needed because this appears in firmware-type memory mappings, which
>> are excluded from bus_space_map.
>>
>> XXX pullup-9 (via manual patch since the code has changed a bit)
> (snip)
>
> Thank you very much.
>
> Your attached patch seems to be committed already.
> I have updated my src tree and build, boot the latest kernel.
> And the LCD turns black forever at different point.
> However I cannot see the last message from the kernel.
>
> Something goes wrong and i915drmkms does not work for my laptop yet.
> I will try to find a problematic point.

I915_WRITE_FW(PLANE_SURF(pipe, plane_id), 0); in line 687 turns
my LCD to yellow (rarely to blue).
If panic is removed, my LCD turns black finally and stay black forever
and does not reach to USB serial console.

   668  static void
   669  skl_disable_plane(struct intel_plane *plane,
   670const struct intel_crtc_state *crtc_state)
   671  {
   672  printf("Enter %s\n", __func__);
   673  struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
   674  enum plane_id plane_id = plane->id;
   675  enum pipe pipe = plane->pipe;
   676  unsigned long irqflags;
   677
   678  spin_lock_irqsave(_priv->uncore.lock, irqflags);
   679
   680  if (icl_is_hdr_plane(dev_priv, plane_id))
   681  I915_WRITE_FW(PLANE_CUS_CTL(pipe, plane_id), 0);
   682
   683  skl_write_plane_wm(plane, crtc_state);
   684
   685  I915_WRITE_FW(PLANE_CTL(pipe, plane_id), 0);
   686  panic("Before turning yellow");
   687  I915_WRITE_FW(PLANE_SURF(pipe, plane_id), 0);
   688
   689  spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
   690  }

I think that line 687 completes disabling primary plane
and followed logics will not able to enable the plane.
However I am not sure because I cannot get any message.

Do you have an idea to investigate deeper?

Thank you.

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update

2021-12-24 Thread Ryo ONODERA 
Hi,

Taylor R Campbell  writes:

> Better yet -- can you try the attached patch?
> From e484fe666999730543f490ce6084486f7d7ce524 Mon Sep 17 00:00:00 2001
> From: Taylor R Campbell 
> Date: Fri, 24 Dec 2021 11:12:43 +
> Subject: [PATCH] i915: Use AcpiOsMapMemory, not bus_space_map, for opregion.
>
> Needed because this appears in firmware-type memory mappings, which
> are excluded from bus_space_map.
>
> XXX pullup-9 (via manual patch since the code has changed a bit)
(snip)

Thank you very much.

Your attached patch seems to be committed already.
I have updated my src tree and build, boot the latest kernel.
And the LCD turns black forever at different point.
However I cannot see the last message from the kernel.

Something goes wrong and i915drmkms does not work for my laptop yet.
I will try to find a problematic point.

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update

2021-12-24 Thread Taylor R Campbell 
Better yet -- can you try the attached patch?
>From e484fe666999730543f490ce6084486f7d7ce524 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell 
Date: Fri, 24 Dec 2021 11:12:43 +
Subject: [PATCH] i915: Use AcpiOsMapMemory, not bus_space_map, for opregion.

Needed because this appears in firmware-type memory mappings, which
are excluded from bus_space_map.

XXX pullup-9 (via manual patch since the code has changed a bit)
---
 .../dist/drm/i915/display/intel_opregion.c| 34 +--
 .../dist/drm/i915/display/intel_opregion.h| 14 
 2 files changed, 8 insertions(+), 40 deletions(-)

diff --git a/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c 
b/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
index 4b0412828d49..b2f986bd74c0 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
+++ b/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
@@ -952,15 +952,7 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
INIT_WORK(>asle_work, asle_work);
 
 #ifdef __NetBSD__
-   opregion->bst = pdev->pd_pa.pa_memt;
-   err = -bus_space_map(opregion->bst, asls, OPREGION_SIZE,
-   BUS_SPACE_MAP_LINEAR|BUS_SPACE_MAP_CACHEABLE,
-   >asls_bsh);
-   if (err) {
-   DRM_DEBUG_DRIVER("Failed to map opregion: %d\n", err);
-   return err;
-   }
-   base = bus_space_vaddr(opregion->bst, opregion->asls_bsh);
+   base = AcpiOsMapMemory(asls, OPREGION_SIZE);
 #else
base = memremap(asls, OPREGION_SIZE, MEMREMAP_WB);
 #endif
@@ -1035,14 +1027,7 @@ int intel_opregion_setup(struct drm_i915_private 
*dev_priv)
}
 
 #ifdef __NetBSD__
-   if (bus_space_map(opregion->bst, rvda,
-   opregion->asle->rvds,
-   BUS_SPACE_MAP_LINEAR|BUS_SPACE_MAP_CACHEABLE,
-   >rvda_bsh))
-   opregion->rvda = NULL;
-   else
-   opregion->rvda = bus_space_vaddr(opregion->bst,
-   opregion->rvda_bsh);
+   opregion->rvda = AcpiOsMapMemory(rvda, opregion->asle->rvds);
 #else
opregion->rvda = memremap(rvda, opregion->asle->rvds,
  MEMREMAP_WB);
@@ -1058,11 +1043,8 @@ int intel_opregion_setup(struct drm_i915_private 
*dev_priv)
} else {
DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (RVDA)\n");
 #ifdef __NetBSD__
-   if (opregion->rvda) {
-   bus_space_unmap(opregion->bst,
-   opregion->rvda_bsh,
-   opregion->asle->rvds);
-   }
+   AcpiOsUnmapMemory(opregion->rvda,
+   opregion->asle->rvds);
 #else
memunmap(opregion->rvda);
 #endif
@@ -1094,7 +1076,7 @@ out:
 
 err_out:
 #ifdef __NetBSD__
-   bus_space_unmap(opregion->bst, opregion->asls_bsh, OPREGION_SIZE);
+   AcpiOsUnmapMemory(base, OPREGION_SIZE);
 #else
memunmap(base);
 #endif
@@ -1251,14 +1233,14 @@ void intel_opregion_unregister(struct drm_i915_private 
*i915)
 
/* just clear all opregion memory pointers now */
 #ifdef __NetBSD__
-   bus_space_unmap(opregion->bst, opregion->asls_bsh, OPREGION_SIZE);
+   size_t rvds = opregion->asle->rvds;
+   AcpiOsUnmapMemory(opregion->header, OPREGION_SIZE);
 #else
memunmap(opregion->header);
 #endif
if (opregion->rvda) {
 #ifdef __NetBSD__
-   bus_space_unmap(opregion->bst, opregion->rvda_bsh,
-   opregion->asle->rvds);
+   AcpiOsUnmapMemory(opregion->rvda, rvds);
 #else
memunmap(opregion->rvda);
 #endif
diff --git a/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.h 
b/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.h
index a04f1c9d9f74..879c4135f670 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.h
+++ b/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.h
@@ -38,17 +38,7 @@ struct opregion_acpi;
 struct opregion_swsci;
 struct opregion_asle;
 
-#ifdef __NetBSD__  /* XXX acpi iomem */
-#  include 
-#  define  __iomem __acpi_iomem
-#endif
-
 struct intel_opregion {
-#ifdef __NetBSD__
-   bus_space_tag_t bst;
-   bus_space_handle_t asls_bsh;
-   bus_space_handle_t rvda_bsh;
-#endif
struct opregion_header *header;
struct opregion_acpi *acpi;
struct opregion_swsci *swsci;
@@ -66,10 +56,6 @@ struct intel_opregion {
 
 #define OPREGION_SIZE(8 * 1024)
 
-#ifdef __NetBSD__  /* XXX acpi iomem */
-#  undef   __iomem
-#endif
-
 #ifdef CONFIG_ACPI
 
 int intel_opregion_setup(struct drm_i915_private *dev_priv);

Re: HEADS UP: Merging drm update

2021-12-24 Thread Taylor R Campbell 
> Date: Thu, 23 Dec 2021 17:26:49 +
> From: Taylor R Campbell 
> 
> > Date: Fri, 24 Dec 2021 01:53:03 +0900
> > From: Ryo ONODERA 
> > 
> > And with this patch, I have gotten the following dmesg:
> > This has no bus_space_map and extent_alloc_subregion1...
> 
> OK, can you try the attached patch and see if it gives us any clues in
> dmesg?  This prints a stack trace any time subr_extent.c writes to a
> struct extent_region and the region now covers the relevant space.

The extent regions might be created too early in x86_parse_clusters,
before dmesg starts recording.

Can you dump bootinfo, e.g. from crash(8)?  Running this on an older
working kernel will do -- doesn't have to be from the broken one.

x/bx bootinfo,1000

(bootinfo might be more than 0x1000 bytes long, but this will probably
suffice to find what covers ASLS=0x63ec5018.)

Re: HEADS UP: Merging drm update

2021-12-24 Thread Michael van Elst 
riastr...@netbsd.org (Taylor R Campbell) writes:

>   #include 

>   if (bpa <=3D BADADDR && BADADDR < bpa + size)
>   db_stacktrace();

>Then share the dmesg output on boot with this change to
>bus_space_reserve?

>This way we can track down who's reserving the registers that
>intel_opregion.c wants.


In my case (T420 with Sandy Bridge) nobody did bus_space_reserve
the registers that intel_opregion wants.

This here is the attempt to map the opregion:

 bus_space_reserve 0x80554799: 0xdaef6018+0x2000 -> extent_alloc_region 
failed
 bus_space_map 0x807689ee: 0xdaef6018+0x2000 -> bus_space_reserve failed

The iomem extent at that point is:

extent `iomem' (0x0 - 0x), flags = 0x3
  0x0 - 0x57fff
  0x58000 - 0x58fff
  0x59000 - 0x9
  0x10 - 0x1fff
  0x2020 - 0x3fff
  0x4020 - 0xda99efff
  0xdae9f000 - 0xdaf9efff <
  0xdaf9f000 - 0xdaffefff
  0xdafff000 - 0xdaff
  0xf000 - 0xf01f
  0xf020 - 0xf03f
  0xf140 - 0xf14000ff
  0xf240 - 0xf2401fff
  0xf250 - 0xf251
  0xf252 - 0xf2523fff
  0xf2528000 - 0xf25287ff
  0xf2529000 - 0xf25293ff
  0xf252a000 - 0xf252a3ff
  0xf252b000 - 0xf252bfff
  0xf800 - 0xf8000fff
  0xf801 - 0xf8010fff
  0xf80b - 0xf80b0fff
  0xf80c8000 - 0xf80c8fff
  0xf80d - 0xf80d0fff
  0xf80d8000 - 0xf80d8fff
  0xf80e - 0xf80e0fff
  0xf80e1000 - 0xf80e1fff
  0xf80e3000 - 0xf80e3fff
  0xf80e4000 - 0xf80e4fff
  0xf80e8000 - 0xf80e8fff
  0xf80f8000 - 0xf80f8fff
  0xf80fa000 - 0xf80fafff
  0xf80fb000 - 0xf80fbfff
  0xf830 - 0xf8300fff
  0xf8d0 - 0xf8d00fff
  0xfed0 - 0xfed003ff
  0xfed1c000 - 0xfed1
  0xfed4 - 0xfed44fff
  0x1 - 0x21e5f

The iomem extent is initialized from the UEFI memory map:

  #  N STARTEND
  0  7  00057fff
  1 10 00058000 00058fff
  2  7 00059000 0009
  3  7 0010 1fff
  4  0 2000 201f
  5  7 2020 3fff
  6  0 4000 401f
  7  7 4020 da99efff
  8  5 da99f000 daac1fff
  9  5 daac2000 dab9efff
 10  6 dab9f000 dacb1fff
 11  6 dacb2000 dad9efff
 12  0 dad9f000 dae21fff
 13  0 dae22000 dae9afff
 14  0 dae9b000 dae9bfff
 15  0 dae9c000 dae9efff
 16 10 dae9f000 daeddfff
 17 10 daede000 daf9efff  <--
 18  9 daf9f000 dafdcfff
 19  9 dafdd000 daffefff
 20  7 dafff000 daff
 21 11 f80f8000 f80f8fff
 22 11 fed1c000 fed1
 23  7 0001 00021e5f

The second column is the EFI md_type that gets translated to a
bootinfo memory type:
0 = null -> BIM_Reserved
5 = rt_code  -> BIM_Reserved
6 = rt_data  -> BIM_Reserved
7 = free -> BIM_Memory
9 = reclaim  -> BIM_ACPI
   10 = firmware -> BIM_NVS
   11 = iomem-> BIM_Reserved

The needed pages are in cluster 17 of type BIM_NVS, which the
extent has added as pre-allocated (merged with cluster 16).

Re: HEADS UP: Merging drm update

2021-12-23 Thread Dmitrii Postolov 
Acer Revo Box RN86 with DisplayPort connection: 
http://bsd-hardware.info/?probe=6d184a1e62


dmesg: https://disk.yandex.ru/d/EbYO4kOkUMqhfw

Photos of screen:
https://disk.yandex.ru/i/2fFMSqX14LT9ig
https://disk.yandex.ru/i/S7Bj_2-62Mna3w
https://disk.yandex.ru/i/7o46UsqbxfFKVw

23.12.2021 22:22, Dmitrii Postolov пишет:

Hi! Sorry for my bad English... I am beginning user of NetBSD-Current.

I am owner of Acer Revo Box RN86 (CPU Intel 9400T and UHD Graphics 
630) with DisplayPort and HDMI connection. With DisplayPort connection 
NetBSD-Current with new drm works on Acer Revo RN86 (with some 
warnings) and graphics works. Also I test NetBSD-Current on Acer 
Aspire XC-895 with _HDMI_ connection and Intel NUC DN2820FYKH with 
HDMI connection, in this case the screen in blank on boot and system 
stop.


I think that the problem is in HDMI mode and NetBSD-Current drm.

Now Firefox is build on NetBSD-Current, so I send statistics later.

--Dmitrii

Re: HEADS UP: Merging drm update

2021-12-23 Thread Taylor R Campbell 
> Date: Fri, 24 Dec 2021 01:53:03 +0900
> From: Ryo ONODERA 
> 
> And with this patch, I have gotten the following dmesg:
> This has no bus_space_map and extent_alloc_subregion1...

OK, can you try the attached patch and see if it gives us any clues in
dmesg?  This prints a stack trace any time subr_extent.c writes to a
struct extent_region and the region now covers the relevant space.
diff --git a/sys/kern/subr_extent.c b/sys/kern/subr_extent.c
index 05962829e9a9..e7a461c6f265 100644
--- a/sys/kern/subr_extent.c
+++ b/sys/kern/subr_extent.c
@@ -98,6 +98,22 @@ panic(a ...) printf(a)
 #defineKASSERT(exp)
 #endif
 
+#include 
+#defineBADSTART((unsigned long)0x63ec5018)
+#defineOPREGION_SIZE   (8 * 1024)
+#defineBADEND  (BADSTART + OPREGION_SIZE)
+static void
+dumpex(const struct extent_region *rp, const char *file, int line)
+{
+
+   if (BADEND < rp->er_start || rp->er_end <= BADSTART)
+   return;
+   printf("%s:%d extent_region @ %p [0x%lx, 0x%lx)\n", file, line, rp,
+   rp->er_start, rp->er_end);
+   db_stacktrace();
+}
+#defineDUMPEX(rp)  dumpex(rp, __FILE__, __LINE__)
+
 static struct pool expool;
 
 /*
@@ -373,6 +389,7 @@ extent_insert_and_optimize(struct extent *ex, u_long start, 
u_long size,
 * We can coalesce.  Prepend us to the first region.
 */
LIST_FIRST(>ex_regions)->er_start = start;
+   DUMPEX(LIST_FIRST(>ex_regions));
extent_free_region_descriptor(ex, rp);
return;
}
@@ -383,6 +400,7 @@ extent_insert_and_optimize(struct extent *ex, u_long start, 
u_long size,
 */
rp->er_start = start;
rp->er_end = start + (size - 1);
+   DUMPEX(rp);
LIST_INSERT_HEAD(>ex_regions, rp, er_link);
return;
}
@@ -402,6 +420,7 @@ extent_insert_and_optimize(struct extent *ex, u_long start, 
u_long size,
 * note of it.
 */
after->er_end = start + (size - 1);
+   DUMPEX(after);
appended = 1;
}
 
@@ -420,6 +439,7 @@ extent_insert_and_optimize(struct extent *ex, u_long start, 
u_long size,
 * Yup, we can free it up.
 */
after->er_end = LIST_NEXT(after, er_link)->er_end;
+   DUMPEX(after);
nextr = LIST_NEXT(after, er_link);
LIST_REMOVE(nextr, er_link);
extent_free_region_descriptor(ex, nextr);
@@ -428,6 +448,7 @@ extent_insert_and_optimize(struct extent *ex, u_long start, 
u_long size,
 * Nope, just prepend us to the next region.
 */
LIST_NEXT(after, er_link)->er_start = start;
+   DUMPEX(LIST_NEXT(after, er_link));
}
 
extent_free_region_descriptor(ex, rp);
@@ -452,6 +473,7 @@ extent_insert_and_optimize(struct extent *ex, u_long start, 
u_long size,
 */
rp->er_start = start;
rp->er_end = start + (size - 1);
+   DUMPEX(rp);
LIST_INSERT_AFTER(after, rp, er_link);
 }
 
@@ -1118,12 +1140,14 @@ extent_free(struct extent *ex, u_long start, u_long 
size, int flags)
/* Case 2. */
if ((start == rp->er_start) && (end < rp->er_end)) {
rp->er_start = (end + 1);
+   DUMPEX(rp);
goto done;
}
 
/* Case 3. */
if ((start > rp->er_start) && (end == rp->er_end)) {
rp->er_end = (start - 1);
+   DUMPEX(rp);
goto done;
}
 
@@ -1132,9 +1156,11 @@ extent_free(struct extent *ex, u_long start, u_long 
size, int flags)
/* Fill in new descriptor. */
nrp->er_start = end + 1;
nrp->er_end = rp->er_end;
+   DUMPEX(nrp);
 
/* Adjust current descriptor. */
rp->er_end = start - 1;
+   DUMPEX(rp);
 
/* Insert new descriptor after current. */
LIST_INSERT_AFTER(rp, nrp, er_link);

Re: HEADS UP: Merging drm update

2021-12-23 Thread Dmitrii Postolov 

Hi! Sorry for my bad English... I am beginning user of NetBSD-Current.

I am owner of Acer Revo Box RN86 (CPU Intel 9400T and UHD Graphics 630) 
with DisplayPort and HDMI connection. With DisplayPort connection 
NetBSD-Current with new drm works on Acer Revo RN86 (with some warnings) 
and graphics works. Also I test NetBSD-Current on Acer Aspire XC-895 
with _HDMI_ connection and Intel NUC DN2820FYKH with HDMI connection, in 
this case the screen in blank on boot and system stop.


I think that the problem is in HDMI mode and NetBSD-Current drm.

Now Firefox is build on NetBSD-Current, so I send statistics later.

--Dmitrii

Re: HEADS UP: Merging drm update

2021-12-23 Thread Ryo ONODERA 
Hi,

Ryo ONODERA  writes:

> Hi,
>
> Taylor R Campbell  writes:
>
>>> Date: Thu, 23 Dec 2021 14:56:19 +
>>> From: Taylor R Campbell 
>>> 
>>> I'm wondering whether the two bus_space_maps in intel_opregion_setup
>>> overlap, and whether one needs to be a bus_space_subregion or
>>> something.
>>
>> Never mind, that's a red herring and obviously not what's happening
>> here.
>>
>> Maybe it's bus_space_alloc that's taking the address, not
>> bus_space_map or bus_space_reserve at all?  Can you put the same
>> db_stacktrace treatment into extent_alloc_subregion1?  Maybe every
>> time an extent_region is inserted into the list or every time anything
>> writes to er_start, print its address, start, end, and stack trace?
>
> I will add db_stacktrace() to extent_alloc_subregion1()
> not to extent_alloc_subregion().
> Please give me some minutes.

I have applied this patch:

Index: sys/kern/subr_extent.c
===
RCS file: /cvsroot/src/sys/kern/subr_extent.c,v
retrieving revision 1.89
diff -u -r1.89 subr_extent.c
--- sys/kern/subr_extent.c  15 Aug 2019 09:04:22 -  1.89
+++ sys/kern/subr_extent.c  23 Dec 2021 17:05:00 -
@@ -51,6 +51,8 @@
 
 #include 
 
+#include 
+
 #elif defined(_EXTENT_TESTING)
 
 /*
@@ -357,6 +359,12 @@
 extent_insert_and_optimize(struct extent *ex, u_long start, u_long size,
 int flags, struct extent_region *after, struct extent_region *rp)
 {
+#if 1
+   if (start <= 0x63ec5018 && 0x63ec5018 < start + size) {
+   printf("extent_insert_and_optimize: Found!!! start=0x%lx, 
size=0x%lx\n", start, size);
+   db_stacktrace();
+   }
+#endif
struct extent_region *nextr;
int appended = 0;
 
@@ -461,6 +469,13 @@
 int
 extent_alloc_region(struct extent *ex, u_long start, u_long size, int flags)
 {
+#if 1
+   printf("extent_alloc_region handles addr=0x%lx, size=0x%lx\n", start, 
size);
+   if (start <= 0x63ec5018 && 0x63ec5018 < start + size) {
+   printf("extent_alloc_region: Found!!! start=0x%lx, 
size=0x%lx\n", start, size);
+   db_stacktrace();
+   }
+#endif
struct extent_region *rp, *last, *myrp;
u_long end = start + (size - 1);
int error;
@@ -555,6 +570,7 @@
 * Check for a conflict.
 */
if (rp->er_end >= start) {
+   printf("extent_alloc_region: conflict: reserved: 
rp->er_start=0x%lx to rp->er_end=0x%lx, try: start=0x%lx to end=0x%lx\n", 
rp->er_start, rp->er_end, start, end);
/*
 * We conflict.  If we can (and want to) wait,
 * do so.
@@ -619,6 +635,13 @@
 u_long size, u_long alignment, u_long skew, u_long boundary,
 int flags, u_long *result)
 {
+#if 1
+   if (substart <= 0x63ec5018 && 0x63ec5018 < subend) {
+   printf("extent_alloc_subregion1: Found!!! substart=0x%lx, 
subend=0x%lx, size=0x%lx\n", substart, subend, size);
+   db_stacktrace();
+   }
+#endif
+
struct extent_region *rp, *myrp, *last, *bestlast;
u_long newstart, newend, exend, beststart, bestovh, ovh;
u_long dontcross;
@@ -992,7 +1015,6 @@
 extent_alloc_subregion(struct extent *ex, u_long start, u_long end, u_long 
size,
 u_long alignment, u_long boundary, int flags, u_long *result)
 {
-
return (extent_alloc_subregion1(ex, start, end, size, alignment,
0, boundary, flags, result));
 }
Index: sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
===
RCS file: 
/cvsroot/src/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c,v
retrieving revision 1.4
diff -u -r1.4 intel_opregion.c
--- sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c19 Dec 
2021 11:49:11 -  1.4
+++ sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c23 Dec 
2021 17:05:01 -
@@ -927,6 +927,7 @@
 
 int intel_opregion_setup(struct drm_i915_private *dev_priv)
 {
+   printf("Enter intel_opregion_setup\n");
struct intel_opregion *opregion = _priv->opregion;
struct pci_dev *pdev = dev_priv->drm.pdev;
u32 asls, mboxes;
@@ -953,11 +954,15 @@
 
 #ifdef __NetBSD__
opregion->bst = pdev->pd_pa.pa_memt;
+   printf("intel_opregion_setup: asls=0x%x\n", asls);
err = -bus_space_map(opregion->bst, asls, OPREGION_SIZE,
BUS_SPACE_MAP_LINEAR|BUS_SPACE_MAP_CACHEABLE,
>asls_bsh);
if (err) {
DRM_DEBUG_DRIVER("Failed to map opregion: %d\n", err);
+#if 1
+   panic("Failed to map opregion: %d\n", err);
+#endif
return err;
}
base = bus_space_vaddr(opregion->bst, opregion->asls_bsh);
@@ -1035,6 +1040,7 @@
}
 
 #ifdef __NetBSD__
+   printf("intel_opregion_setup:

Re: HEADS UP: Merging drm update

2021-12-23 Thread Ryo ONODERA 
Hi,

Taylor R Campbell  writes:

>> Date: Thu, 23 Dec 2021 14:56:19 +
>> From: Taylor R Campbell 
>> 
>> I'm wondering whether the two bus_space_maps in intel_opregion_setup
>> overlap, and whether one needs to be a bus_space_subregion or
>> something.
>
> Never mind, that's a red herring and obviously not what's happening
> here.
>
> Maybe it's bus_space_alloc that's taking the address, not
> bus_space_map or bus_space_reserve at all?  Can you put the same
> db_stacktrace treatment into extent_alloc_subregion1?  Maybe every
> time an extent_region is inserted into the list or every time anything
> writes to er_start, print its address, start, end, and stack trace?

I will add db_stacktrace() to extent_alloc_subregion1()
not to extent_alloc_subregion().
Please give me some minutes.

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update

2021-12-23 Thread Taylor R Campbell 
> Date: Thu, 23 Dec 2021 14:56:19 +
> From: Taylor R Campbell 
> 
> I'm wondering whether the two bus_space_maps in intel_opregion_setup
> overlap, and whether one needs to be a bus_space_subregion or
> something.

Never mind, that's a red herring and obviously not what's happening
here.

Maybe it's bus_space_alloc that's taking the address, not
bus_space_map or bus_space_reserve at all?  Can you put the same
db_stacktrace treatment into extent_alloc_subregion1?  Maybe every
time an extent_region is inserted into the list or every time anything
writes to er_start, print its address, start, end, and stack trace?

Re: HEADS UP: Merging drm update

2021-12-23 Thread Taylor R Campbell 
> Date: Thu, 23 Dec 2021 20:53:00 +0900
> From: Ryo ONODERA 
> 
> I have added panic()s to extent_alloc_region and
> extent_insert_and_optimize.
> And the kernel with this change does not display anything at all.
> After bootloader, my LCD turns black and stays black forever.
> I have removed panic()s after db_stacktrace()s and added only
> db_stacktrace() to extent_alloc_region and extent_insert_and_optimize.
> And I have gotten the following dmesg.
> (I feel that this has no new information.)

Can you use pcictl to dump the pci config registers of the graphics
device, and dump the content of whatever address is in register 0xfc?

Something like:

# pcictl pci0 dump -b 0 -d 2 -f 0
PCI configuration registers:
  Common header:
0x00: 0x01668086 0x0097 0x0309 0x

Vendor Name: Intel (0x8086)
Device Name: Ivy Bridge Integrated Graphics Device (0x0166)
...
# pcictl pci0 read -b 0 -d 2 -f 0 0xfc
daf4f018
# dd if=/dev/mem iseek=$((0xdaf4f018)) bs=1 count=8192 | hexdump -C

Separately, if you can dmesgs out -- can you print asls and rvda in
intel_opregion_setup?

I'm wondering whether the two bus_space_maps in intel_opregion_setup
overlap, and whether one needs to be a bus_space_subregion or
something.

Re: HEADS UP: Merging drm update

2021-12-22 Thread Taylor R Campbell 
> Date: Wed, 22 Dec 2021 18:58:51 +
> From: Taylor R Campbell 
> 
> > Date: Thu, 23 Dec 2021 00:57:13 +0900
> > From: Ryo ONODERA 
> > 
> > Ryo ONODERA  writes:
> > 
> > > I have no useful information or thought yet…
> > >
> > > I have added check for BADADDR+OPREGION_SIZE in bus_space_reserve.
> > > And I have found that no one uses that address.
> > 
> > I have added similar logic to extent_alloc_region() and
> > extent_insert_and_optimize(). And I have found that someone
> > reserves 0x6375c000 to 0x63f3.
> > However I cannot find who reserves this range.
> > i915drmkms wants 0x63ec5018 to 0x63ec7017 and this is overlapped
> > with 0x6375c000 to 0x63f3.
> 
> Can you use db_stacktrace() in extent_alloc_region and
> extent_insert_and_optimize when the region covers that address?  That
> might help narrow it down.

Can you make it stop panicking here, but still print the messages and
get the dmesg at the end?  (If you need to make it panic to get the
dmesg, maybe make it panic in drmfb_attach?)  It may be that i915
tries to map it twice but we didn't notice because we were looking for
any other driver before i915.

Re: HEADS UP: Merging drm update

2021-12-22 Thread Taylor R Campbell 
> Date: Thu, 23 Dec 2021 00:57:13 +0900
> From: Ryo ONODERA 
> 
> Ryo ONODERA  writes:
> 
> > I have no useful information or thought yet…
> >
> > I have added check for BADADDR+OPREGION_SIZE in bus_space_reserve.
> > And I have found that no one uses that address.
> 
> I have added similar logic to extent_alloc_region() and
> extent_insert_and_optimize(). And I have found that someone
> reserves 0x6375c000 to 0x63f3.
> However I cannot find who reserves this range.
> i915drmkms wants 0x63ec5018 to 0x63ec7017 and this is overlapped
> with 0x6375c000 to 0x63f3.

Can you use db_stacktrace() in extent_alloc_region and
extent_insert_and_optimize when the region covers that address?  That
might help narrow it down.

Re: HEADS UP: Merging drm update

2021-12-22 Thread Ryo ONODERA 
Hi,

Ryo ONODERA  writes:

> hi,
>
> I have no useful information or thought yet…
>
> I have added check for BADADDR+OPREGION_SIZE in bus_space_reserve.
> And I have found that no one uses that address.

I have added similar logic to extent_alloc_region() and
extent_insert_and_optimize(). And I have found that someone
reserves 0x6375c000 to 0x63f3.
However I cannot find who reserves this range.
i915drmkms wants 0x63ec5018 to 0x63ec7017 and this is overlapped
with 0x6375c000 to 0x63f3.

I can get dmesg as text file.

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
2018, 2019, 2020, 2021 The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 9.99.93 (DTRACE7) #47: Wed Dec 22 23:36:08 JST 2021
ryoon@brownie:/usr/world/9.99/amd64/obj/sys/arch/amd64/compile/DTRACE7
total memory = 15961 MB
avail memory = 15405 MB
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
efi: systbl at pa 5697d018
mainbus0 (root)
ACPI: RSDP 0x63FFE014 24 (v02 DELL  )
ACPI: XSDT 0x63F9C188 F4 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FACP 0x63FF6000 000114 (v06 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: DSDT 0x63FB3000 03F8DE (v02 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FACS 0x63EDF000 40
ACPI: SSDT 0x63FFB000 001B61 (v02 CpuRef CpuSsdt  3000 INTL 
20180927)
ACPI: SSDT 0x63FF7000 003C64 (v02 INTEL  DptfTabl 1000 INTL 
20180927)
ACPI: HPET 0x63FF5000 38 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: APIC 0x63FF4000 00012C (v03 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: MCFG 0x63FF3000 3C (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FB2000 0008D9 (v02 DELL   DellRtd3 1000 INTL 
20180927)
ACPI: NHLT 0x63FB1000 2D (v00 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FB 000CB8 (v02 DELL   UsbCTabl 1000 INTL 
20180927)
ACPI: SSDT 0x63FAF000 000612 (v02 DELL   Tpm2Tabl 1000 INTL 
20180927)
ACPI: TPM2 0x63FAE000 34 (v04 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: LPIT 0x63FAD000 94 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FAC000 000B75 (v02 DELL   PtidDevc 1000 INTL 
20180927)
ACPI: SSDT 0x63FAB000 000FBB (v02 DELL   TbtTypeC  INTL 
20180927)
ACPI: DBGP 0x63FAA000 34 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: DBG2 0x63FA9000 54 (v00 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SLIC 0x63FA8000 000176 (v03 DELL   CBX3 06222004 MSFT 
00010013)
ACPI: BOOT 0x63FA7000 28 (v01 DELL   CBX3 20170001 ??LL 
20160422)
ACPI: MSDM 0x63FA6000 55 (v03 DELL   CBX3 06222004 AMI  
00010013)
ACPI: SSDT 0x63FA4000 001554 (v02 SaSsdt SaSsdt   3000 INTL 
20180927)
ACPI: SSDT 0x63F9D000 006C63 (v02 INTEL  TcssSsdt 1000 INTL 
20180927)
ACPI: DMAR 0x63FFD000 B0 (v02 INTEL  Dell Inc 0002  
0113)
ACPI: SSDT 0x63F9B000 000BE6 (v02 DELL   xh_Dell_  INTL 
20180927)
ACPI: SSDT 0x63F9A000 000156 (v02 Dell   ADebTabl 1000 INTL 
20180927)
ACPI: BGRT 0x63F99000 38 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FPDT 0x63F98000 34 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: 12 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x20, 120 pins
x2APIC available but disabled by DMAR table
cpu0 at mainbus0 apid 0
cpu0: Use lfence to serialize rdtsc
cpu0: CPU base freq 15 Hz
cpu0: CPU max freq 39 Hz
cpu0: TSC freq CPUID 149760 Hz
cpu0: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu0: node 0, package 0, core 0, smt 0
cpu1 at mainbus0 apid 2
cpu1: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu1: node 0, package 0, core 1, smt 0
cpu2 at mainbus0 apid 4
cpu2: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu2: node 0, package 0, core 2, smt 0
cpu3 at mainbus0 apid 6
cpu3: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu3: node 0, package 0, core 3, smt 0
cpu4 at mainbus0 apid 1
cpu4: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu4: node 0, package 0, core 0, smt 1
cpu5 at mainbus0 apid 3
cpu5: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu5: node 0, package 0, core 1, smt 1
cpu6 at mainbus0 apid 5
cpu6: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu6: node 0, package 0, core 2, smt 1
cpu7 at mainbus0 apid 7
cpu7: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz, id 0x706e5
cpu7: node 0, package 0, core 3, smt 1
extent_alloc_region handles addr=0x0, size=0x10

Re: HEADS UP: Merging drm update

2021-12-21 Thread Ryo ONODERA 
Hi,

Taylor R Campbell  writes:

>> Date: Tue, 21 Dec 2021 22:47:34 +0900
>> From: Ryo ONODERA 
>> 
>> I think that "Cannot find any crtc or sizes" may be related to
>> "Failed to find VBIOS tables (VBT)".
>> I have added some printf lines to some functions invoked before
>> intel_bios_init in
>> sys/external/bsd/drm2/dist/drm/i915/display/intel_bios.c .
>> 
>> And bus_space_map (line 956)
>> in intel_opregion_setup in 
>> sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
>> failed and return value 35.
>
> Can you do the following diagnostics?
>
> 1. Print what the bus address is when bus_space_map fails here; call
>it BADADDR.
>
> 2. Add a fragment to bus_space_reserve in x86/bus_space.c:
>
>#include 
>
>   if (bpa <= BADADDR && BADADDR < bpa + size)
>   db_stacktrace();
>
> Then share the dmesg output on boot with this change to
> bus_space_reserve?
>
> This way we can track down who's reserving the registers that
> intel_opregion.c wants.

Thanks for your suggestion.

I have applied the following patch.
I cannot get dmesg easily and I have added panic() to stop vertical scroll.

Index: sys/arch/x86/x86/bus_space.c
===
RCS file: /cvsroot/src/sys/arch/x86/x86/bus_space.c,v
retrieving revision 1.46
diff -u -r1.46 bus_space.c
--- sys/arch/x86/x86/bus_space.c7 Oct 2021 12:52:27 -   1.46
+++ sys/arch/x86/x86/bus_space.c21 Dec 2021 15:41:49 -
@@ -51,6 +51,8 @@
 #include 
 #endif
 
+#include 
+
 /*
  * Macros for sanity-checking the aligned-ness of pointers passed to
  * bus space ops.  These are not strictly necessary on the x86, but
@@ -251,6 +253,11 @@
 bus_size_t size,
 int flags, bus_space_reservation_t *bsrp)
 {
+   if (bpa <= 0x63ec5018 && 0x63ec5018 < bpa + size) {
+   db_stacktrace();
+   panic("BADADDR");
+   }
+
struct extent *ex;
int error;
bus_space_tag_t it;
Index: sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
===
RCS file: 
/cvsroot/src/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c,v
retrieving revision 1.4
diff -u -r1.4 intel_opregion.c
--- sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c19 Dec 
2021 11:49:11 -  1.4
+++ sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c21 Dec 
2021 15:41:49 -
@@ -943,6 +943,7 @@
BUILD_BUG_ON(sizeof(struct opregion_asle_ext) != 0x400);
 
pci_read_config_dword(pdev, ASLS, );
+   printf("graphic opregion physical addr: 0x%x\n", asls);
DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
if (asls == 0) {
DRM_DEBUG_DRIVER("ACPI OpRegion not supported!\n");

My result is very strange. No one except i195drmkms itself
requests asls=0x63ec5018 address.
My patch has panic() and if someone requests the address,
boot process will stop immediately.

Here is the last part of dmesg manually transcribed from photo.

(snip)
i915drmkms0 at pci0 dev 2 function 0: Intel product 8a52 (rev. 0x03)
(snip)
boot device: ld0
root file system type: ffs
kern.module.path=/stand/amd64/9.99.92/modules
graphics opregion physical addr: 0x63ec5018
bus_space_map() at netbsd:bus_space_map+0x43
intel_opregion_setup() at netbsd:intel_opregion_setup+0xa3
i915_driver_probe() at netbsd:i915_driver_probe+0x64f
i915drmkms_attach_real() at netbsd:i915drmkms_attach_real+0x40
config_mountroot_thread() at netbsd:config_mountroot_thread+0x37
panic: BADADDR
cpu0: Begin traceback...
vpanic() netbsd:vpanic+0x156
panic() at netbsd:panic+0x3c
bus_space_reserve() at netbsd:bus_space_reserve+0x104
bus_space_map() at netbsd:bus_space_map+0x43
intel_opregion_setuo() at netbsd:intel_opregion_setup+0xa3
i915_driver_probe() at netbsd:i915_driver_probe+0x64f
i915drmkms_attach_real() at netbsd:i915drmkms_attach_real+0x40
config_mountroot_thread() at netbsd:config_mountroot_thread+0x37
cpu0: End traceback...
fatal breakpoint trap insupervisor mode
trap type 1 code 0 rip 0x80221995 cs 0x8 rflags 0x202 cdr 0 ilevel 0 
rsp 0xdd014aa69d40
curlwp 0xc279f4c75900 pid 0.384 lowest kstack 0xdd014aa652c0
Stopped in pid 0.384 (system) at   netbsd:breakpoiny+0x5: leave
(snip)

I do not understand my situation yet...

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update

2021-12-21 Thread Taylor R Campbell 
> Date: Tue, 21 Dec 2021 22:47:34 +0900
> From: Ryo ONODERA 
> 
> I think that "Cannot find any crtc or sizes" may be related to
> "Failed to find VBIOS tables (VBT)".
> I have added some printf lines to some functions invoked before
> intel_bios_init in
> sys/external/bsd/drm2/dist/drm/i915/display/intel_bios.c .
> 
> And bus_space_map (line 956)
> in intel_opregion_setup in 
> sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
> failed and return value 35.

Can you do the following diagnostics?

1. Print what the bus address is when bus_space_map fails here; call
   it BADADDR.

2. Add a fragment to bus_space_reserve in x86/bus_space.c:

   #include 

if (bpa <= BADADDR && BADADDR < bpa + size)
db_stacktrace();

Then share the dmesg output on boot with this change to
bus_space_reserve?

This way we can track down who's reserving the registers that
intel_opregion.c wants.

Re: HEADS UP: Merging drm update

2021-12-21 Thread Ryo ONODERA 
Hi,

Martin Husemann  writes:

> On Tue, Dec 21, 2021 at 01:50:05AM +0900, Ryo ONODERA wrote:
>> (snip)
>> boot device: ld0
>> root on dk1 dumps on dk2
>> root file system type: ffs
>> kern.module.path=/stand/amd64/9.99.92/modules
>> kern info: [drm] Support vblank timestamp caching Rev 2 (21.10.2013).
>> kern info: [drm] Driver supports precise vblank timestamp query.
>> kern info: [drm] Failed to find VBIOS tables (VBT)
>> i915drmkms0: interrupting at msi5 vec 0 (i915drmkms0)
>> i915drmkms0: notice: Failed to load DMC firmware i915/icl_dmc_ver1_09.bin. 
>> Disabling runtime power management.
>> (screen turns black)
>
> I get the same on a machine with "real" serial console- it comes up fine,
> but nothing in wscons land works:
>
> scsibus0 at umass0: 2 targets, 1 lun per target
> sd0 at scsibus0 target 0 lun 0:  disk removable
> sd0: drive offline
> WARNING: 3 errors while detecting hardware; check system log.
> boot device: wd1
> root on wd1e dumps on wd1b
> root file system type: ffs
> kern.module.path=/stand/amd64/9.99.92/modules
> kern info: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> kern info: [drm] Driver supports precise vblank timestamp query.
> kern info: [drm] Failed to find VBIOS tables (VBT)
> allocated pic msi7 type edge pin 0 level 6 to cpu1 slot 2 idt entry 98
> i915drmkms0: interrupting at msi7 vec 0 (i915drmkms0)
> i915drmkms0: notice: Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. 
> Disa$
> i915drmkms0: notice: DMC firmware homepage: 
> https://git.kernel.org/pub/scm/linu$
> kern info: [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0
> i915drmkms0: info: [drm] Cannot find any crtc or sizes
> kern info: [drm] DRM_I915_DEBUG enabled
> kern info: [drm] DRM_I915_DEBUG_GEM enabled  
> i915drmkms0: info: [drm] Cannot find any crtc or sizes

Thanks for your information.
I think that "Cannot find any crtc or sizes" may be related to
"Failed to find VBIOS tables (VBT)".
I have added some printf lines to some functions invoked before
intel_bios_init in
sys/external/bsd/drm2/dist/drm/i915/display/intel_bios.c .

And bus_space_map (line 956)
in intel_opregion_setup in 
sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
failed and return value 35.

   954  #ifdef __NetBSD__
   955  opregion->bst = pdev->pd_pa.pa_memt;
   956  err = -bus_space_map(opregion->bst, asls, OPREGION_SIZE,
   957  BUS_SPACE_MAP_LINEAR|BUS_SPACE_MAP_CACHEABLE,
   958  >asls_bsh);
   959  if (err) {
   960  DRM_DEBUG_DRIVER("Failed to map opregion: %d\n", err);
   961  return err;
   962  }
   963  base = bus_space_vaddr(opregion->bst, opregion->asls_bsh);
   964  #else

> Martin

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: HEADS UP: Merging drm update

2021-12-20 Thread Kengo NAKAHARA 

Hi,

On 2021/12/21 8:28, Taylor R Campbell wrote:

Date: Mon, 20 Dec 2021 11:35:45 +0900
From: Kengo NAKAHARA 

GENERIC kernel without DIAGNOSTIC option fails to build.
Could you apply the following patch?
  
https://github.com/knakahara/netbsd-src/commit/b1c93870ef5689201b6eb7e08811bc40e3e1543e


Thanks!  I did it slightly differently, to reduce the amount of
upstream patching we need to do.  OK now?


LGTM. Thank you for your quick response!


Thanks,

--
//
Internet Initiative Japan Inc.

Device Engineering Section,
Product Division,
Technology Unit

Kengo NAKAHARA

Re: HEADS UP: Merging drm update

2021-12-20 Thread Taylor R Campbell 
> Date: Mon, 20 Dec 2021 11:35:45 +0900
> From: Kengo NAKAHARA 
> 
> GENERIC kernel without DIAGNOSTIC option fails to build.
> Could you apply the following patch?
>  
> https://github.com/knakahara/netbsd-src/commit/b1c93870ef5689201b6eb7e08811bc40e3e1543e

Thanks!  I did it slightly differently, to reduce the amount of
upstream patching we need to do.  OK now?

Re: HEADS UP: Merging drm update

2021-12-20 Thread Martin Husemann 
On Tue, Dec 21, 2021 at 01:50:05AM +0900, Ryo ONODERA wrote:
> (snip)
> boot device: ld0
> root on dk1 dumps on dk2
> root file system type: ffs
> kern.module.path=/stand/amd64/9.99.92/modules
> kern info: [drm] Support vblank timestamp caching Rev 2 (21.10.2013).
> kern info: [drm] Driver supports precise vblank timestamp query.
> kern info: [drm] Failed to find VBIOS tables (VBT)
> i915drmkms0: interrupting at msi5 vec 0 (i915drmkms0)
> i915drmkms0: notice: Failed to load DMC firmware i915/icl_dmc_ver1_09.bin. 
> Disabling runtime power management.
> (screen turns black)

I get the same on a machine with "real" serial console- it comes up fine,
but nothing in wscons land works:

scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0:  disk removable
sd0: drive offline
WARNING: 3 errors while detecting hardware; check system log.
boot device: wd1
root on wd1e dumps on wd1b
root file system type: ffs
kern.module.path=/stand/amd64/9.99.92/modules
kern info: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
kern info: [drm] Driver supports precise vblank timestamp query.
kern info: [drm] Failed to find VBIOS tables (VBT)
allocated pic msi7 type edge pin 0 level 6 to cpu1 slot 2 idt entry 98
i915drmkms0: interrupting at msi7 vec 0 (i915drmkms0)
i915drmkms0: notice: Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disa$
i915drmkms0: notice: DMC firmware homepage: https://git.kernel.org/pub/scm/linu$
kern info: [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0
i915drmkms0: info: [drm] Cannot find any crtc or sizes
kern info: [drm] DRM_I915_DEBUG enabled
kern info: [drm] DRM_I915_DEBUG_GEM enabled  
i915drmkms0: info: [drm] Cannot find any crtc or sizes


Martin

Re: HEADS UP: Merging drm update

2021-12-20 Thread Ryo ONODERA 
Hi,

Taylor R Campbell  writes:

>> Date: Sun, 19 Dec 2021 01:42:53 +
>> From: Taylor R Campbell 
>> 
>> > Date: Sat, 18 Dec 2021 17:06:13 +
>> > From: Taylor R Campbell 
>> > 
>> > I'm planning to merge the drm update this weekend -- a cvs import and
>> > merge commit, plus about 1300 commits on top of that from the git
>> > repository.
>> 
>> The update is in progress, but my commitbomb script isn't perfect and
>> sometimes requires manual intervention, which won't happen while I'm
>> asleep.  The tree might not build for a few hours in that event.
>> Apologies in advance!
>
> The commitbomb is done -- drm update merged.  There may be build
> fallout; let me know if so and I'll try to take care of it.

Thanks for your great work!!!

I have Ice Lake laptop (Dell XPS 13 9300) and its CPU is
Intel Core i7-1065G7. The Core i7-1065G7 has Intel Iris Plus 11th
generation GPU (VID/PID=0x8086/0x8a52).

I have gotten black screen and boot process seems no progress.
I think that the kernel stalls behind black screen.

(snip)
boot device: ld0
root on dk1 dumps on dk2
root file system type: ffs
kern.module.path=/stand/amd64/9.99.92/modules
kern info: [drm] Support vblank timestamp caching Rev 2 (21.10.2013).
kern info: [drm] Driver supports precise vblank timestamp query.
kern info: [drm] Failed to find VBIOS tables (VBT)
i915drmkms0: interrupting at msi5 vec 0 (i915drmkms0)
i915drmkms0: notice: Failed to load DMC firmware i915/icl_dmc_ver1_09.bin. 
Disabling runtime power management.
(screen turns black)

I cannnot see any other kernel message because screen does not show
anything on LCD.
I have prepared to login via USB uplcom(4) serial console, however
it does not emit any characters.
I think that the kernel stalls.

I want to collect information for debugging.
Could you tell me your idea how to debug my problem?

When i915drmkms is disabled, I can get dmesg as follows:

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
2018, 2019, 2020, 2021 The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 9.99.92 (GENERIC) #16: Tue Dec 21 01:28:13 JST 2021
ryoon@brownie:/usr/world/9.99/amd64/obj/sys/arch/amd64/compile/GENERIC
total memory = 15961 MB
avail memory = 15405 MB
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
userconf: configure system autoconfiguration:
uc> disable i915drmkms
i915drmkms* disabled
uc> quit
Continuing...
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
efi: systbl at pa 5697d018
mainbus0 (root)
ACPI: RSDP 0x63FFE014 24 (v02 DELL  )
ACPI: XSDT 0x63F9C188 F4 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FACP 0x63FF6000 000114 (v06 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: DSDT 0x63FB3000 03F8DE (v02 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: FACS 0x63EDF000 40
ACPI: SSDT 0x63FFB000 001B61 (v02 CpuRef CpuSsdt  3000 INTL 
20180927)
ACPI: SSDT 0x63FF7000 003C64 (v02 INTEL  DptfTabl 1000 INTL 
20180927)
ACPI: HPET 0x63FF5000 38 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: APIC 0x63FF4000 00012C (v03 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: MCFG 0x63FF3000 3C (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FB2000 0008D9 (v02 DELL   DellRtd3 1000 INTL 
20180927)
ACPI: NHLT 0x63FB1000 2D (v00 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FB 000CB8 (v02 DELL   UsbCTabl 1000 INTL 
20180927)
ACPI: SSDT 0x63FAF000 000612 (v02 DELL   Tpm2Tabl 1000 INTL 
20180927)
ACPI: TPM2 0x63FAE000 34 (v04 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: LPIT 0x63FAD000 94 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SSDT 0x63FAC000 000B75 (v02 DELL   PtidDevc 1000 INTL 
20180927)
ACPI: SSDT 0x63FAB000 000FBB (v02 DELL   TbtTypeC  INTL 
20180927)
ACPI: DBGP 0x63FAA000 34 (v01 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: DBG2 0x63FA9000 54 (v00 DELL   Dell Inc 20170001 ??LL 
20160422)
ACPI: SLIC 0x63FA8000 000176 (v03 DELL   CBX3 06222004 MSFT 
00010013)
ACPI: BOOT 0x63FA7000 28 (v01 DELL   CBX3 20170001 ??LL 
20160422)
ACPI: MSDM 0x63FA6000 55 (v03 DELL   CBX3 06222004 AMI  
00010013)
ACPI: SSDT 0x63FA4000 001554 (v02 SaSsdt SaSsdt   3000 INTL 
20180927)
ACPI: SSDT 0x63F9D000 006C63 (v02 INTEL  TcssSsdt 1000 INTL 
20180927)
ACPI: DMAR 0x63FFD000 B0 (v02 INTEL  Dell Inc 0002  
0113)
ACPI: SSDT 0x63F9B000 000BE6 (v02 DELL   xh_Dell_  INTL 
20180927)
ACPI: SSDT 0x63F9A000 000156 (v02 Dell   ADebTabl 1000 INTL 
20180927)
ACPI: BGRT

Re: HEADS UP: Merging drm update

2021-12-19 Thread Kengo NAKAHARA 

Hi,

On 2021/12/19 21:48, Taylor R Campbell wrote:

Date: Sun, 19 Dec 2021 01:42:53 +
From: Taylor R Campbell 


Date: Sat, 18 Dec 2021 17:06:13 +
From: Taylor R Campbell 

I'm planning to merge the drm update this weekend -- a cvs import and
merge commit, plus about 1300 commits on top of that from the git
repository.


The update is in progress, but my commitbomb script isn't perfect and
sometimes requires manual intervention, which won't happen while I'm
asleep.  The tree might not build for a few hours in that event.
Apologies in advance!


The commitbomb is done -- drm update merged.  There may be build
fallout; let me know if so and I'll try to take care of it.


GENERIC kernel without DIAGNOSTIC option fails to build.
Could you apply the following patch?

https://github.com/knakahara/netbsd-src/commit/b1c93870ef5689201b6eb7e08811bc40e3e1543e

Here is the same patch.

diff --git a/sys/external/bsd/drm2/dist/drm/i915/gt/intel_lrc.c 
b/sys/external/bsd/drm2/dist/drm/i915/gt/intel_lrc.c
index ac348156cd0..4464bc69dce 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/gt/intel_lrc.c
+++ b/sys/external/bsd/drm2/dist/drm/i915/gt/intel_lrc.c
@@ -2248,7 +2248,7 @@ gen12_csb_parse(const struct intel_engine_execlists 
*execlists, const u32 *csb)
 {
u32 lower_dw = csb[0];
u32 upper_dw = csb[1];
-   bool ctx_to_valid = GEN12_CSB_CTX_VALID(lower_dw);
+   bool ctx_to_valid __diagused = GEN12_CSB_CTX_VALID(lower_dw);
bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_dw);
bool new_queue = lower_dw & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
 
diff --git a/sys/external/bsd/drm2/dist/drm/i915/gt/intel_reset.c b/sys/external/bsd/drm2/dist/drm/i915/gt/intel_reset.c

index be7b47e3828..b0948d7b8e1 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/gt/intel_reset.c
+++ b/sys/external/bsd/drm2/dist/drm/i915/gt/intel_reset.c
@@ -1120,7 +1120,7 @@ static inline int intel_gt_reset_engine(struct 
intel_engine_cs *engine)
  */
 int intel_engine_reset(struct intel_engine_cs *engine, const char *msg)
 {
-   struct intel_gt *gt = engine->gt;
+   struct intel_gt *gt __diagused = engine->gt;
bool uses_guc = intel_engine_in_guc_submission_mode(engine);
int ret;
 
diff --git a/sys/external/bsd/drm2/dist/drm/i915/gt/intel_ring_submission.c b/sys/external/bsd/drm2/dist/drm/i915/gt/intel_ring_submission.c

index 1becea96e4b..26e7d097dea 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/gt/intel_ring_submission.c
+++ b/sys/external/bsd/drm2/dist/drm/i915/gt/intel_ring_submission.c
@@ -1946,7 +1946,7 @@ static void setup_bcs(struct intel_engine_cs *engine)
 
 static void setup_vecs(struct intel_engine_cs *engine)

 {
-   struct drm_i915_private *i915 = engine->i915;
+   struct drm_i915_private *i915 __diagused = engine->i915;
 
 	GEM_BUG_ON(INTEL_GEN(i915) < 7);
 
diff --git a/sys/external/bsd/drm2/dist/drm/i915/gt/uc/intel_guc_fw.c b/sys/external/bsd/drm2/dist/drm/i915/gt/uc/intel_guc_fw.c

index 33af59c0fab..440ecc6a9b7 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/gt/uc/intel_guc_fw.c
+++ b/sys/external/bsd/drm2/dist/drm/i915/gt/uc/intel_guc_fw.c
@@ -64,7 +64,7 @@ static void guc_xfer_rsa(struct intel_uc_fw *guc_fw,
 struct intel_uncore *uncore)
 {
u32 rsa[UOS_RSA_SCRATCH_COUNT];
-   size_t copied;
+   size_t copied __diagused;
int i;
 
 	copied = intel_uc_fw_copy_rsa(guc_fw, rsa, sizeof(rsa));

diff --git a/sys/external/bsd/drm2/dist/drm/i915/gt/uc/intel_huc.c 
b/sys/external/bsd/drm2/dist/drm/i915/gt/uc/intel_huc.c
index 1bb5944efab..23d8fb22577 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/gt/uc/intel_huc.c
+++ b/sys/external/bsd/drm2/dist/drm/i915/gt/uc/intel_huc.c
@@ -64,7 +64,7 @@ static int intel_huc_rsa_data_create(struct intel_huc *huc)
struct intel_gt *gt = huc_to_gt(huc);
struct intel_guc *guc = >uc.guc;
struct i915_vma *vma;
-   size_t copied;
+   size_t copied __diagused;
void *vaddr;
int err;
 
diff --git a/sys/external/bsd/drm2/dist/drm/i915/i915_request.c b/sys/external/bsd/drm2/dist/drm/i915/i915_request.c

index e3ba11e16cc..9030365c689 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/i915_request.c
+++ b/sys/external/bsd/drm2/dist/drm/i915/i915_request.c
@@ -1290,7 +1290,7 @@ __i915_request_add_to_timeline(struct i915_request *rq)
 struct i915_request *__i915_request_commit(struct i915_request *rq)
 {
struct intel_engine_cs *engine = rq->engine;
-   struct intel_ring *ring = rq->ring;
+   struct intel_ring *ring __diagused = rq->ring;
u32 *cs;
 
 	RQ_TRACE(rq, "\n");

diff --git a/sys/external/bsd/drm2/dist/drm/i915/i915_scheduler.c 
b/sys/external/bsd/drm2/dist/drm/i915/i915_scheduler.c
index 30e63daa6a6..af3489bbdc7 100644
--- a/sys/external/bsd/drm2/dist/drm/i915/i915_scheduler.c
+++ b/sys/external/bsd/drm2/dist/drm/i915/i915_scheduler.c
@@ -55,7 +55,7 @@ static inline struct i915_priolist

re: HEADS UP: Merging drm update

2021-12-19 Thread matthew green 
> Please update and try again?  (I've only compile-tested the changes,
> will take a closer look tomorrow if it doesn't fix the problem.)

seems to work for me.  i can once again mostly play 720p video
with "mpv -vo x11".

thanks!


.mrg.

Re: HEADS UP: Merging drm update

2021-12-19 Thread Taylor R Campbell 
> Date: Sun, 19 Dec 2021 23:51:58 +
> From: Taylor R Campbell 
> 
> > Date: Sun, 19 Dec 2021 21:41:14 +0100
> > From: Benny Siegert 
> > 
> > Meanwhile, I built a new kernel from HEAD on my Pinebook Pro. There is
> > a bit of a pause when DRM is initialized during boot, and X is
> > basically unusable -- it takes a minute or so to draw the login screen
> > (slim).
> > [...]
> > This is not working as intended, I suppose? :)
> 
> Oops -- the rockchip vblank logic got lost in the shuffle to elide
> debug commits from the commitbomb.  The necessary logic is in
> 
> but I need to dust it off and commit it properly with a little less
> debugging crud!

Please update and try again?  (I've only compile-tested the changes,
will take a closer look tomorrow if it doesn't fix the problem.)

Re: HEADS UP: Merging drm update

2021-12-19 Thread Taylor R Campbell 
> Date: Sun, 19 Dec 2021 21:41:14 +0100
> From: Benny Siegert 
> 
> Meanwhile, I built a new kernel from HEAD on my Pinebook Pro. There is
> a bit of a pause when DRM is initialized during boot, and X is
> basically unusable -- it takes a minute or so to draw the login screen
> (slim).
> [...]
> This is not working as intended, I suppose? :)

Oops -- the rockchip vblank logic got lost in the shuffle to elide
debug commits from the commitbomb.  The necessary logic is in

but I need to dust it off and commit it properly with a little less
debugging crud!

Re: HEADS UP: Merging drm update

2021-12-19 Thread Benny Siegert 
On Sun, Dec 19, 2021 at 2:35 PM nia  wrote:
> > > > I'm planning to merge the drm update this weekend -- a cvs import and
> > > > merge commit, plus about 1300 commits on top of that from the git
> > > > repository.
>
> thank you Maya and Taylor for this monumental effort!

Yes, thank you, this is great!! :)

Meanwhile, I built a new kernel from HEAD on my Pinebook Pro. There is
a bit of a pause when DRM is initialized during boot, and X is
basically unusable -- it takes a minute or so to draw the login screen
(slim).

On the console, I see these:

[   5.3118036] video0 at uvideo0: Sonix Technology Co., Ltd. (0x0c45)
USB Camera (0x6321), rev 2.00/0.00, addr 3
[  12.4019283] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x788}
*ERROR* [CRTC:38:crtc-1] flip_done timed out
[  22.4020997] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x7f8}
*ERROR* [CONNECTOR:35:eDP-1] flip_done timed out
[  32.4022714] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x824}
*ERROR* [PLANE:36:plane-1] flip_done timed out
[  32.4022714] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:1083:
driver forgot to call drm_crtc_vblank_off()
[  32.4022714] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:2313:
new_crtc_state->event
[  42.4024501] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x788}
*ERROR* [CRTC:38:crtc-1] flip_done timed out
[  52.4026288] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x7f8}
*ERROR* [CONNECTOR:35:eDP-1] flip_done timed out
[  62.4028023] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x824}
*ERROR* [PLANE:36:plane-1] flip_done timed out
[  62.6028057] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:2313:
new_crtc_state->event

[...]

[  78.4135804] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x788}
*ERROR* [CRTC:38:crtc-1] flip_done timed out
[  88.4140717] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x7f8}
*ERROR* [CONNECTOR:35:eDP-1] flip_done timed out
[  98.4146493] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x824}
*ERROR* [PLANE:36:plane-1] flip_done timed out
[  98.4146493] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:2313:
new_crtc_state->event
[ 109.6452513] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x788}
*ERROR* [CRTC:38:crtc-1] flip_done timed out
[ 119.6458660] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x7f8}
*ERROR* [CONNECTOR:35:eDP-1] flip_done timed out
[ 129.6464760] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x824}
*ERROR* [PLANE:36:plane-1] flip_done timed out
[ 129.6464760] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:2313:
new_crtc_state->event

This is not working as intended, I suppose? :)

-- 
Benny



-- 
Benny

Re: HEADS UP: Merging drm update

2021-12-19 Thread nia 
On Sun, Dec 19, 2021 at 12:48:15PM +, Taylor R Campbell wrote:
> > Date: Sun, 19 Dec 2021 01:42:53 +
> > From: Taylor R Campbell 
> > 
> > > Date: Sat, 18 Dec 2021 17:06:13 +
> > > From: Taylor R Campbell 
> > > 
> > > I'm planning to merge the drm update this weekend -- a cvs import and
> > > merge commit, plus about 1300 commits on top of that from the git
> > > repository.
> > 
> > The update is in progress, but my commitbomb script isn't perfect and
> > sometimes requires manual intervention, which won't happen while I'm
> > asleep.  The tree might not build for a few hours in that event.
> > Apologies in advance!
> 
> The commitbomb is done -- drm update merged.  There may be build
> fallout; let me know if so and I'll try to take care of it.

thank you Maya and Taylor for this monumental effort!

Re: HEADS UP: Merging drm update

2021-12-19 Thread Taylor R Campbell 
> Date: Sun, 19 Dec 2021 01:42:53 +
> From: Taylor R Campbell 
> 
> > Date: Sat, 18 Dec 2021 17:06:13 +
> > From: Taylor R Campbell 
> > 
> > I'm planning to merge the drm update this weekend -- a cvs import and
> > merge commit, plus about 1300 commits on top of that from the git
> > repository.
> 
> The update is in progress, but my commitbomb script isn't perfect and
> sometimes requires manual intervention, which won't happen while I'm
> asleep.  The tree might not build for a few hours in that event.
> Apologies in advance!

The commitbomb is done -- drm update merged.  There may be build
fallout; let me know if so and I'll try to take care of it.

Re: HEADS UP: Merging drm update

2021-12-18 Thread Taylor R Campbell 
> Date: Sat, 18 Dec 2021 17:06:13 +
> From: Taylor R Campbell 
> 
> I'm planning to merge the drm update this weekend -- a cvs import and
> merge commit, plus about 1300 commits on top of that from the git
> repository.

The update is in progress, but my commitbomb script isn't perfect and
sometimes requires manual intervention, which won't happen while I'm
asleep.  The tree might not build for a few hours in that event.
Apologies in advance!

HEADS UP: Merging drm update

2021-12-18 Thread Taylor R Campbell 
I'm planning to merge the drm update this weekend -- a cvs import and
merge commit, plus about 1300 commits on top of that from the git
repository.

Please don't commit anything to the following subtrees until done --
if you do, your changes will be lost:

sys/external/bsd/drm2
sys/external/bsd/common

Please don't touch the following additional files outside those
subtrees:

sys/arch/arm/nvidia/tegra_drm.c
sys/arch/arm/nvidia/tegra_drm.h
sys/arch/arm/nvidia/tegra_drm_fb.c
sys/arch/arm/nvidia/tegra_drm_mode.c
sys/arch/arm/nvidia/tegra_fb.c
sys/arch/arm/nvidia/tegra_nouveau.c
sys/arch/arm/nxp/imx6_dwhdmi.c
sys/arch/arm/rockchip/rk_anxdp.c
sys/arch/arm/rockchip/rk_drm.c
sys/arch/arm/rockchip/rk_drm.h
sys/arch/arm/rockchip/rk_dwhdmi.c
sys/arch/arm/rockchip/rk_fb.c
sys/arch/arm/rockchip/rk_vop.c
sys/arch/arm/sunxi/sunxi_drm.c
sys/arch/arm/sunxi/sunxi_drm.h
sys/arch/arm/sunxi/sunxi_dwhdmi.c
sys/arch/arm/sunxi/sunxi_fb.c
sys/arch/arm/sunxi/sunxi_hdmiphy.h
sys/arch/arm/sunxi/sunxi_lcdc.c
sys/arch/arm/sunxi/sunxi_mixer.c
sys/arch/arm/ti/ti_fb.c
sys/arch/arm/ti/ti_lcdc.c
sys/arch/arm/ti/ti_lcdc.h
sys/dev/fdt/fdt_panel.c
sys/dev/fdt/hdmi_connector.c
sys/dev/i2c/anxedp.c
sys/dev/i2c/tda19988.c
sys/dev/ic/anx_dp.c
sys/dev/ic/anx_dp.h
sys/dev/ic/dw_hdmi.c
sys/dev/ic/dw_hdmi.h
sys/dev/ic/dw_hdmi_phy.c
sys/dev/videomode/edidvar.h
sys/modules/*drmkms*
sys/sys/agpio.h