Re: On boot, screen remains black after radeondrm driver initializes
On Tue, Feb 22, 2022 at 02:31:21PM +1100, Jonathan Gray wrote: > On Mon, Feb 21, 2022 at 07:39:14PM -0500, Frank J. Cameron wrote: > > That patch also seems to work well on 7.1 snapshot with the drm 5.15.14: > > I don't understand why you see this after the delay.h change > for the same imac model: > > sys/dev/pci/drm/include/linux/delay.h > > > revision 1.3 > date: 2020/08/18 19:50:08; author: mglocker; state: Exp; lines: +1 -1; > commitid: 5kwux8n8bT8IM82I; > Our usleep_range(min, max) implementation today is only taking account > of the min value to delay. On the iMac11,2 this was too short, causing > a timeout in the DP AUX transaction retry loop, leaving the eDP dark > after the KMS initialization attempt. Affected code line for reference: > > sys/dev/pci/drm/drm_dp_helper.c:771, revision 1.11 I booted to /obsd (7.1 GENERIKC.MP#0374 amd64) and tried it again. The last thing I saw was "radeondrm0: RV730" and the screen went black and stayed black. After a few minutes I booted the custom kernel with the atmobios_encoders.c patch (7.1 GENERIK.MP#0 amd64) and the display worked again, Let me know if there is anything you want to see from this system. dmesg: https://0x0.st/oKNW.txt
Re: On boot, screen remains black after radeondrm driver initializes
On Mon, Feb 21, 2022 at 07:39:14PM -0500, Frank J. Cameron wrote:
> On Sat, Feb 19, 2022 at 05:30:47PM -0500, Frank J. Cameron wrote:
> > On Mon, 3 Aug 2020 02:24:47 +1000 Jonathan Gray wrote:
> > > On Sun, Aug 02, 2020 at 01:05:37PM +0200, mgloc...@openbsd.org wrote:
> > > > System : OpenBSD 6.7
> > > > Installing an OpenBSD snapshot the first time on this iMac Intel
> > > > Core i3 machine. After the radaeon firmware package has been
> > > > installed and you reboot the system, the screen remains black after
> > > > the radeondrm driver initializes.
> > >
> > > Try this. RV730 is DCE3.2
> > > - if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
> > > + if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
> > > + dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
> >
> > OpenBSD 7.0 on an Intel iMac Core i3 (iMac11,2; RV730) had the same black
> > screen behaviour, but setting enc_idx to 1 did restore a working screen
> > with radeondrm.
> >
> > I haven't extensively tested the system with the patch but DPMS is
> > working and I played some bzflag with high graphics settings; have
> > not seen any regressions yet.
>
> That patch also seems to work well on 7.1 snapshot with the drm 5.15.14:
I don't understand why you see this after the delay.h change
for the same imac model:
sys/dev/pci/drm/include/linux/delay.h
revision 1.3
date: 2020/08/18 19:50:08; author: mglocker; state: Exp; lines: +1 -1;
commitid: 5kwux8n8bT8IM82I;
Our usleep_range(min, max) implementation today is only taking account
of the min value to delay. On the iMac11,2 this was too short, causing
a timeout in the DP AUX transaction retry loop, leaving the eDP dark
after the KMS initialization attempt. Affected code line for reference:
sys/dev/pci/drm/drm_dp_helper.c:771, revision 1.11
Therefore we change the behavior of usleep_range(min, max) to delay
the average value of min and max instead, which finally fixes the KMS
initialization on the iMac11,2.
Help and ok jsg@
>
> Index: sys/dev/pci/drm/radeon/atombios_encoders.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_encoders.c,v
> retrieving revision 1.16
> diff -u -p -u -p -r1.16 atombios_encoders.c
> --- sys/dev/pci/drm/radeon/atombios_encoders.c 14 Jan 2022 06:53:14 -
> 1.16
> +++ sys/dev/pci/drm/radeon/atombios_encoders.c 22 Feb 2022 00:32:06 -
> @@ -2191,7 +2191,8 @@ int radeon_atom_pick_dig_encoder(struct
> * otherwise the internal eDP panel will stay dark.
> */
> if (ASIC_IS_DCE32(rdev)) {
> - if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
> + if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
> + dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
> enc_idx = (dig->linkb) ? 1 : 0;
> else
> enc_idx = radeon_crtc->crtc_id;
>
>
Re: On boot, screen remains black after radeondrm driver initializes
On Sat, Feb 19, 2022 at 05:30:47PM -0500, Frank J. Cameron wrote:
> On Mon, 3 Aug 2020 02:24:47 +1000 Jonathan Gray wrote:
> > On Sun, Aug 02, 2020 at 01:05:37PM +0200, mgloc...@openbsd.org wrote:
> > > System : OpenBSD 6.7
> > > Installing an OpenBSD snapshot the first time on this iMac Intel
> > > Core i3 machine. After the radaeon firmware package has been
> > > installed and you reboot the system, the screen remains black after
> > > the radeondrm driver initializes.
> >
> > Try this. RV730 is DCE3.2
> > - if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
> > + if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
> > + dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
>
> OpenBSD 7.0 on an Intel iMac Core i3 (iMac11,2; RV730) had the same black
> screen behaviour, but setting enc_idx to 1 did restore a working screen
> with radeondrm.
>
> I haven't extensively tested the system with the patch but DPMS is
> working and I played some bzflag with high graphics settings; have
> not seen any regressions yet.
That patch also seems to work well on 7.1 snapshot with the drm 5.15.14:
Index: sys/dev/pci/drm/radeon/atombios_encoders.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_encoders.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 atombios_encoders.c
--- sys/dev/pci/drm/radeon/atombios_encoders.c 14 Jan 2022 06:53:14 -
1.16
+++ sys/dev/pci/drm/radeon/atombios_encoders.c 22 Feb 2022 00:32:06 -
@@ -2191,7 +2191,8 @@ int radeon_atom_pick_dig_encoder(struct
* otherwise the internal eDP panel will stay dark.
*/
if (ASIC_IS_DCE32(rdev)) {
- if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
+ if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
+ dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
enc_idx = (dig->linkb) ? 1 : 0;
else
enc_idx = radeon_crtc->crtc_id;
UDP divert-to rule: getsockname(2) won't show original destination
>Synopsis: UDP divert-to rule: getsockname(2) won't show original
destination
>Category: kernel amd64
>Environment:
System : OpenBSD 7.1-beta
Details : OpenBSD 7.1-beta (GENERIC) #353: Sun Feb 20 17:14:05
MST 2022
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
getsockname(2) won't show the original destination address/port for a
UDP inet packet redirected using a PF divert-to rule to a local
socket.
This works as expected for TCP.
>How-To-Repeat:
server:
(pf.conf)
pass in on vio0 inet proto udp from any to 100.64.0.100 divert-to 127.0.0.1
port 9000
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> s.bind(("127.0.0.1", 9000))
>>> s.recvfrom(1024)
(b'data\n', ('100.64.0.1', 16079))
>>> s.getsockname()
('127.0.0.1', 9000)
client:
$ echo data | nc -u 100.64.0.100 12345
>Fix:
Unknown.
Re: witness: acquiring duplicate lock of same type: ">vmobjlock"
On 17/02/22(Thu) 16:22, Klemens Nanni wrote:
> On Wed, Feb 16, 2022 at 11:39:19PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 16 Feb 2022 21:13:03 +
> > > From: Klemens Nanni
> > >
> > > Unmodified -current with WITNESS enabled booting into X on my X230:
> > >
> > > wsdisplay0: screen 1-5 added (std, vt100 emulation)
> > > witness: acquiring duplicate lock of same type: ">vmobjlock"
> > > 1st uobjlk
> > > 2nd uobjlk
> > > Starting stack trace...
> > > witness_checkorder(fd83b625f9b0,9,0) at witness_checkorder+0x8ac
> > > rw_enter(fd83b625f9a0,1) at rw_enter+0x68
> > > uvm_obj_wire(fd843c39e948,0,4,800033b70428) at
> > > uvm_obj_wire+0x46
> > > shmem_get_pages(88008500) at shmem_get_pages+0xb8
> > > __i915_gem_object_get_pages(88008500) at
> > > __i915_gem_object_get_pages+0x6d
> > > i915_gem_fault(88008500,800033b707c0,10009b000,a43d6b1c000,800033b70740,1,35ba896911df1241,800aa078,800aa178)
> > > at i915_gem_fault+0x203
> > > drm_fault(800033b707c0,a43d6b1c000,800033b70740,1,0,0,7eca45006f70ee0,800033b707c0)
> > > at drm_fault+0x156
> > > uvm_fault(fd843a7cf480,a43d6b1c000,0,2) at uvm_fault+0x179
> > > upageflttrap(800033b70920,a43d6b1c000) at upageflttrap+0x62
> > > usertrap(800033b70920) at usertrap+0x129
> > > recall_trap() at recall_trap+0x8
> > > end of kernel
> > > end trace frame: 0x7f7dc7c0, count: 246
> > > End of stack trace.
> > >
> > > The system works fine (unless booted with kern.witness.watch=3), so I'm
> > > posting it here for reference -- haven't had time to look into this.
> >
> > Yes, this is expected. The graphics buffers are implented as a uvm
> > object and this object is backed by an anonymous memory uvm_object
> > (aobj). So I think the vmobjlock needs a RW_DUPOK flag.
>
> I see, thanks for the hint.
>
> I looked at drm first to see if I could easily add RW_DUPOK to their
> init/enter calls only such that RW_DUPOK for objlk is contained within
> drm, but that's neither easy nor needed.
>
> uvm_obj_wire() is only called from sys/dev/pci/drm/ anyway, so we can
> just treat drm there.
>
> The lock order reversal is about uvm_obj_wire() only and I haven't seen
> one in uvm_obj_unwire(), but my diff consequently adds RW_DUPOK to both
> as both are being used in drm.
>
> This makes the witness report go away on my X230.
>
> Does that RW_DUPOK deserve a comment?
If the commit message is clear enough I don't think so.
> Feedback? Objections? OK?
ok mpi@
> > > wsdisplay0: screen 1-5 added (std, vt100 emulation)
> > > witness: acquiring duplicate lock of same type: ">vmobjlock"
> > > 1st uobjlk
> > > 2nd uobjlk
> > > Starting stack trace...
> > > witness_checkorder(fd83b625f9b0,9,0) at witness_checkorder+0x8ac
> > > rw_enter(fd83b625f9a0,1) at rw_enter+0x68
> > > uvm_obj_wire(fd843c39e948,0,4,800033b70428) at
> > > uvm_obj_wire+0x46
> > > shmem_get_pages(88008500) at shmem_get_pages+0xb8
> > > __i915_gem_object_get_pages(88008500) at
> > > __i915_gem_object_get_pages+0x6d
> > > i915_gem_fault(88008500,800033b707c0,10009b000,a43d6b1c000,800033b70740,1,35ba896911df1241,800aa078,800aa178)
> > > at i915_gem_fault+0x203
> > > drm_fault(800033b707c0,a43d6b1c000,800033b70740,1,0,0,7eca45006f70ee0,800033b707c0)
> > > at drm_fault+0x156
> > > uvm_fault(fd843a7cf480,a43d6b1c000,0,2) at uvm_fault+0x179
> > > upageflttrap(800033b70920,a43d6b1c000) at upageflttrap+0x62
> > > usertrap(800033b70920) at usertrap+0x129
> > > recall_trap() at recall_trap+0x8
> > > end of kernel
> > > end trace frame: 0x7f7dc7c0, count: 246
> > > End of stack trace.
>
>
> Index: uvm_object.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_object.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 uvm_object.c
> --- uvm_object.c 17 Jan 2022 13:55:32 - 1.24
> +++ uvm_object.c 17 Feb 2022 16:12:54 -
> @@ -133,7 +133,7 @@ uvm_obj_wire(struct uvm_object *uobj, vo
>
> left = (end - start) >> PAGE_SHIFT;
>
> - rw_enter(uobj->vmobjlock, RW_WRITE);
> + rw_enter(uobj->vmobjlock, RW_WRITE | RW_DUPOK);
> while (left) {
>
> npages = MIN(FETCH_PAGECOUNT, left);
> @@ -147,7 +147,7 @@ uvm_obj_wire(struct uvm_object *uobj, vo
> if (error)
> goto error;
>
> - rw_enter(uobj->vmobjlock, RW_WRITE);
> + rw_enter(uobj->vmobjlock, RW_WRITE | RW_DUPOK);
> for (i = 0; i < npages; i++) {
>
> KASSERT(pgs[i] != NULL);
> @@ -197,7 +197,7 @@ uvm_obj_unwire(struct uvm_object *uobj,
> struct vm_page *pg;
> off_t offset;
>
> - rw_enter(uobj->vmobjlock, RW_WRITE);
> + rw_enter(uobj->vmobjlock, RW_WRITE | RW_DUPOK);
> uvm_lock_pageq();
> for (offset = start; offset < end; offset +=
