Re: php-gd-8.1.10 broken on OpenBSD 7.1?

2022-09-25 Thread Jonathan Gray
On Sun, Sep 25, 2022 at 03:34:55PM +1000, Stuart Longland wrote:
> Hi all…
> 
> I'm just in the process of setting up a Wordpress site for development
> purposes on a VPS running OpenBSD 7.1, and I'm seeing this when I try
> to install the `gd` extension:
> 
> vk4msl-bne# pkg_add php-gd-8.1.10 
> quirks-5.5 signed on 2022-09-24T12:39:42Z
> Can't install gd-2.3.2 because of libraries
> |library fontconfig.13.1 not found
> | not found anywhere
> |library freetype.30.1 not found
> | not found anywhere
> Direct dependencies for gd-2.3.2 resolve to tiff-4.4.0p1 png-1.6.37 
> libiconv-1.16p0 libwebp-1.2.2 jpeg-2.1.3v0
> Full dependency tree is libwebp-1.2.2 lz4-1.9.3p0 tiff-4.4.0p1 png-1.6.37 
> xz-5.2.5p1 jpeg-2.1.3v0 giflib-5.1.6 zstd-1.5.2 libiconv-1.16p0
> Can't install php-gd-8.1.10: can't resolve gd-2.3.2
> Couldn't install gd-2.3.2 php-gd-8.1.10
> vk4msl-bne# uname -a
> OpenBSD vk4msl-bne.dmz.longlandclan.id.au 7.1 GENERIC#3 amd64
> 
> gd is needed to manipulate graphics (thumbnail generation, etc).  While
> I can do without, it's far from ideal.

fontconfig and freetype are part of the xbase set

to add it after an install
# tar -C / -xzphf xbase71.tgz



Re: Old Unix manuals (was: Re: A minimal browser in base)

2022-09-14 Thread Jonathan Gray
On Wed, Sep 14, 2022 at 07:00:56AM +0100, Jason McIntyre wrote:
> On Tue, Sep 13, 2022 at 06:54:40PM -0400, luna wrote:
> > On Tue, Sep 13, 2022 at 07:04:55 +0100, Jason McIntyre wrote:
> > > hi.
> > > 
> > > we stopped installing them because many of them were falling out of date
> > > and there wasn;t really the resources (or motivation) to update them.
> > > however not all of them were removed. although no longer installed, some
> > > of the better ones remain in the source tree. from a quick look:
> > 
> > Note that you'll need to pull /usr/src/share/mk/bsd.doc.mk out of the 
> > attic and install it in /usr/share/mk, and then you'll need a copy of 
> > groff to build these documents. I haven't tested this on a recent 
> > version of OpenBSD, though I can say that older versions of both 
> > OpenBSD and FreeBSD work quite well for building these old docs. If you 
> > want versions you can read on your terminal, you can pass -Tascii to 
> > groff like FreeBSD's bsd.doc.mk does, which is (handwaving over other 
> > details here) what groff does to render manpages.
> > 
> > I can wholeheartedly recommend building and reading the ones you can
> > find, especially if you're interested in Unix history. They're something
> > of a time capsule, providing a snapshot of what Unix was at the time and
> > how people used it. In addition, as said above, some of them are just as
> > applicable today as when they were written.
> > 
> 
> also, although it won;t be pretty, you can just pass the documents to
> mandoc and get something that's at least semi-readable.
> 
> jmc

can also be found at

https://docs-legacy.freebsd.org/44doc/
https://wolfram.schneider.org/bsd/7thEdManVol2/

https://9p.io/7thEdMan/v7vol2b.pdf
http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_Vol_2_1983.pdf



Re: Dual external monitors not working since drm 5.10.47 upgrade

2022-09-08 Thread Jonathan Gray
On Thu, Sep 08, 2022 at 10:48:26AM +0200, Paul Kelly wrote:
> On 9/8/22 03:07, Jonathan Gray wrote:
> > Index: sys/dev/pci/drm/i915/i915_drv.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
> > retrieving revision 1.143
> > diff -u -p -r1.143 i915_drv.c
> > --- sys/dev/pci/drm/i915/i915_drv.c 30 Jul 2022 14:15:20 -  1.143
> > +++ sys/dev/pci/drm/i915/i915_drv.c 8 Sep 2022 00:33:22 -
> > @@ -2410,6 +2410,11 @@ inteldrm_attach(struct device *parent, s
> > dev_priv->id = id;
> > info = (struct intel_device_info *)id->driver_data;
> > +   /* Device parameters start as a copy of module parameters. */
> > +   i915_params_copy(_priv->params, _modparams);
> > +   dev_priv->params.enable_guc = 0;
> > +   dev_priv->params.request_timeout_ms = 0;
> > +
> > /* Setup the write-once "constant" device info */
> > device_info = mkwrite_device_info(dev_priv);
> > memcpy(device_info, info, sizeof(*device_info));
> 
> This is cleaner and simpler than what I'd suggested. MST continues to work
> OK, and I haven't seen anything break as a result of the change. I did
> however notice that on a couple of shutdowns I got some additional console
> messages, although this _might_ be related to me having disabled MST in my
> primary display between boot and shutdown.
> 
> > drm:pid8902:drm_dp_check_act_status *ERROR* [drm] *ERROR* Failed to get ACT 
> > after 3000ms, last status: 04
> > drm:pid8902:drm_dp_check_act_status *ERROR* [drm] *ERROR* Failed to get ACT 
> > after 3000ms, last status: 04
> > drm:pid8902:drm_dp_check_act_status *ERROR* [drm] *ERROR* Failed to get ACT 
> > after 3000ms, last status: 04
> 
> I also tested the use of concurrent DP and HDMI outputs on my T470 dock.
> Initially I thought that this wasn't working, but I am using a dock with
> 2xDP + 1xHDMI, and it seems like not all outputs are able to be used
> concurrently. So..dual displays with DP & HDMI works OK if I use a specific
> DP port on the back of the dock. There does also appear to be some fudging
> going on with output names in xrandr when running via the dock: the HDMI
> port is presented as DP output. I suspect that this might be due to the
> internals of the dock, though.
> 
> I've also checked that things work with the laptop undocked...but realised
> that it only has a single HDMI output. That works fine, and xrandr reports
> the output as HDMI-2. This does however seem to stop working if the laptop
> is subsequently docked, with xrandr then reporting that HDMI-2 is
> disconnected. This may also just be normal behaviour for a docked laptop.
> 
> Unfortunately there's now so much console output during startup that dmesg
> appears to be truncated - so I don't have a full dmesg to share after
> applying the new patch. I searched quickly for instructions on increasing
> the buffer size but only found a post from jj@ from 2006 (!). Given that
> things seem to work OK now I suppose that there's little interest in seeing
> a dmesg anyway, but I'm happy to provide one if it's useful.

I can't think of anything in dmesg to check.

To increase the size of the buffer change MSGBUFSIZE in
sys/arch/amd64/include/param.h

> 
> Thanks again for the support to investigate this.

Thanks for the report and figuring it out.  Committed.



Re: Dual external monitors not working since drm 5.10.47 upgrade

2022-09-07 Thread Jonathan Gray
On Wed, Sep 07, 2022 at 05:29:14PM +0200, Paul Kelly wrote:
> On 9/7/22 13:05, Jonathan Gray wrote:
> > If you add "option DRMDEBUG" to your kernel config
> > there may be some hints in the (large amount of) dmesg output
> > 
> > Also build with this to add some more DP messages.
> > Used in sys/dev/pci/drm/drm_dp_mst_topology.c
> > 
> > Index: sys/dev/pci/drm/drm_print.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/drm_print.c,v
> > retrieving revision 1.4
> > diff -u -p -r1.4 drm_print.c
> > --- sys/dev/pci/drm/drm_print.c 12 Jun 2020 10:06:40 -  1.4
> > +++ sys/dev/pci/drm/drm_print.c 7 Sep 2022 10:38:00 -
> > @@ -43,7 +43,7 @@
> >* Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
> >*/
> >   #ifdef DRMDEBUG
> > -unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS;
> > +unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS | DRM_UT_DP;
> >   #else
> >   unsigned int __drm_debug;
> >   #endif
> 
> Thanks; I think I have identified the problem.
> 
> I rebuilt against -current with the suggested modifications. This is tested
> on the HP ProDesk w/ 1x DP + 1x VGA output; only the DP output is in use,
> and it's connected to a monitor with MST enabled. I've included the dmesg
> output at the bottom.
> 
> I've noticed that DP MST seems to be supported by both port and sink (host
> system and monitor respectively, I am guessing). However, it's being
> administratively disabled via a check on the following variable:
> i915->params.enable_dp_mst (see "modparam:no" in the log message below).
> 
> > [drm] [ENCODER:73:DDI B/PHY B] MST support: port: yes, sink: yes, modparam: 
> > no
> 
> Digging a bit further...the params struct is defined in i915_params.h, and
> its members are initialised to specific values that are subsequently used as
> the initial configuration for i915 devices in Linux (see call to
> i915_params_copy() in i915_drv.c). This is however not performed under
> OpenBSD, because it's buried in an #ifdef __linux__ section. So it looks
> like we are simply missing some intended default configuration.
> 
> I've included a bodge below to ignore enable_dp_mst entirely, and I have
> confirmed that this restores my ability to run with DisplayPort MST. I am
> assuming that it's safe to set enable_dp_mst true by default in OpenBSD, but
> that seems unlikely to help other users who are not relying on MST for
> multi-screen support.
> 
> My initial approach to fix this properly would be to introduce
> OpenBSD-conditional config into i915_params.h and then update
> i915_driver_probe() so that it calls i915_params_copy() early. Then it would
> be possible to incrementally identify which defaults are appropriate. If
> that's acceptable then I'm happy to prepare a diff for testing.
> 
> Thanks again for the tips to investigate this - it's a great relief to have
> understood the issue and it will be nice to get use of my second screen
> again.
> 
> Paul

well spotted

comparing the before and after here I see

struct drm_printer p = drm_info_printer(dev_priv->drm.dev);
i915_params_dump(_priv->params, );

i915_params_copy(_priv->params, _modparams);

i915_params_dump(_priv->params, );

@@ -1,36 +1,36 @@
 [drm] i915.vbt_firmware=(null)
-[drm] i915.modeset=0
+[drm] i915.modeset=-1
 [drm] i915.lvds_channel_mode=0
-[drm] i915.panel_use_ssc=0
-[drm] i915.vbt_sdvo_panel_type=0
-[drm] i915.enable_dc=0
-[drm] i915.enable_fbc=0
-[drm] i915.enable_psr=0
+[drm] i915.panel_use_ssc=-1
+[drm] i915.vbt_sdvo_panel_type=-1
+[drm] i915.enable_dc=-1
+[drm] i915.enable_fbc=-1
+[drm] i915.enable_psr=-1
 [drm] i915.psr_safest_params=no
 [drm] i915.enable_psr2_sel_fetch=no
-[drm] i915.disable_power_well=0
-[drm] i915.enable_ips=0
+[drm] i915.disable_power_well=-1
+[drm] i915.enable_ips=1
 [drm] i915.invert_brightness=0
-[drm] i915.enable_guc=0
-[drm] i915.guc_log_level=0
+[drm] i915.enable_guc=-1
+[drm] i915.guc_log_level=-1
 [drm] i915.guc_firmware_path=(null)
 [drm] i915.huc_firmware_path=(null)
 [drm] i915.dmc_firmware_path=(null)
 [drm] i915.mmio_debug=0
 [drm] i915.edp_vswing=0
-[drm] i915.reset=0
+[drm] i915.reset=3
 [drm] i915.inject_probe_failure=0
-[drm] i915.fastboot=0
-[drm] i915.enable_dpcd_backlight=0
-[drm] i915.force_probe=(null)
+[drm] i915.fastboot=-1
+[drm] i915.enable_dpcd_backlight=-1
+[drm] i915.force_probe=
 [drm] i915.fake_lmem_start=0
-[drm] i915.request_timeout_ms=0
-[drm] i915.enable_hangcheck=no
+[drm] i915.request_timeout_ms=2
+[drm] i915.enable_hangcheck=yes
 [drm] i915.load_detect_test=no
 [drm] i915.force_reset_modeset_test=no
-[drm] i915.error_capture=no
+[drm] i915.error_capture=yes
 [drm] i915.disabl

Re: Dual external monitors not working since drm 5.10.47 upgrade

2022-09-07 Thread Jonathan Gray
On Wed, Sep 07, 2022 at 10:04:03AM +0200, Paul Kelly wrote:
> Hey Julian,
> 
> On 9/4/22 18:18, Julian Huhn wrote:
> > Moin!
> > 
> > I can reproduce with my X270. With -current it does not work and with
> > 6.9 both external monitors run without problems.
> > 
> > Same problem as I had already mentioned here:
> > https://marc.info/?l=openbsd-misc=166153179211227=2
> 
> Ah, I'd seen your post but was thrown off by the mention of Thunderbolt, and
> hadn't noticed that you had also tried with a non-Thunderbolt dock. Thanks
> for confirming that it previously worked OK on your X270.
> 
> I've been searching for additional reports, and it seems as though the Intel
> 4xxx CPU series w/ HD Graphics 4400 might also be impacted. Here is a user
> on reddit writing about similar symptoms on a Lenovo T440p:
> 
> https://www.reddit.com/r/openbsd/comments/ws1j1d/double_displayport_dock/
> 
> 
> Paul

If you add "option DRMDEBUG" to your kernel config
there may be some hints in the (large amount of) dmesg output

Also build with this to add some more DP messages.
Used in sys/dev/pci/drm/drm_dp_mst_topology.c

Index: sys/dev/pci/drm/drm_print.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_print.c,v
retrieving revision 1.4
diff -u -p -r1.4 drm_print.c
--- sys/dev/pci/drm/drm_print.c 12 Jun 2020 10:06:40 -  1.4
+++ sys/dev/pci/drm/drm_print.c 7 Sep 2022 10:38:00 -
@@ -43,7 +43,7 @@
  * Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
  */
 #ifdef DRMDEBUG
-unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS;
+unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS | DRM_UT_DP;
 #else
 unsigned int __drm_debug;
 #endif



Re: iMac11,2: internal display only works when DisplayPort is connected

2022-08-29 Thread Jonathan Gray
On Mon, Aug 29, 2022 at 10:03:34AM +0100, Hashim Mahmoud wrote:
> On Mon, 29 Aug 2022 17:19:16 +1000
> Jonathan Gray  wrote:
> 
> > On Mon, Aug 29, 2022 at 07:56:40AM +0100, Hashim Mahmoud wrote:
> > > This iMac's screen works fine, but always turns off when the radeon
> > > GPU driver is loaded on any UNIX (tried Linux Mint and NomadBSD as
> > > well). I had to install OpenBSD on another machine since I was
> > > installing to an SD card, as I didn't have any (big enough) spare
> > > SSDs or USBs, and writing to the SD card from the installer on the
> > > same iMac gives me permission errors.
> > > 
> > > I had installed the radeon firmware already by the time I put the SD
> > > card into the iMac. The GPU seems to work fine and I can login and
> > > run commands blindly, but the display is off... until I had the
> > > bright idea to connect a display over the DisplayPort at boot time,
> > > via a VGA to mini DisplayPort adapter. The internal eDP display
> > > worked, but the tty framebuffer took the resolution of the external
> > > display (similar to what would happen when a low resolution laptop
> > > is connected to a higher resolution display, and both displays are
> > > on), which is 1440x900, and the external display receives no
> > > output, though Xorg seems to acknowledge its existence and renders
> > > itself as if that display exists, as the xenodm login window is not
> > > available on the main display, and the mouse disappears as if it
> > > went to another display when hitting the left edge. I can login
> > > blind and run `xrandr --output DisplayPort-0 --off`, and everything
> > > seems to work perfectly fine and GPU accelerated, as the output of
> > > `glxinfo -B` indicates, and glxgears runs smoothly.
> > > 
> > > However, this only works if the DisplayPort is connected at boot
> > > time:
> > > 
> > > - If it is disconnected after the radeon driver is loaded, but X
> > > hasn't started yet, then the display goes black again, but I can
> > > plug it back in and the display shows up as normal (still in
> > > 1440x900, though), and I get this in blue: `[drm] *ERROR* chosen
> > > encoder in use 0`. No idea what that means.
> > > 
> > > - Once X is started however, I can just disconnect the DisplayPort,
> > > and life is good :) ... except I get the following in xconsole:
> > > ```
> > > [drm] *ERROR* displayport link status failed
> > > [drm] *ERROR* clock recovery failed
> > > [drm] *ERROR* displayport link status failed
> > > [drm] *ERROR* clock recovery failed
> > > ```
> > > - Doesn't seem to effect me in any way, though.
> > > 
> > > - I also get this error message, when I switch from my X session to
> > >   tty: `[drm] *ERROR*
> > > rv770_restrict_performance_levels_before_switch failed`. Also seems
> > > to have no effect.
> > > - Note that these errors only appear in xconsole and not on the
> > > actual console in blue... weird.
> > > 
> > > 
> > > Is there some sort of software remedy for this? I doubt this (unless
> > > someone can tell me otherwise), so I was thinking of getting
> > > something like a Raspberry Pi Zero or an Arduino, and connecting to
> > > the DisplayPort, making it like some sort of dummy DisplayPort
> > > input by programming it... I'm not sure at all how to go about
> > > doing this, as I'm a very amateur programmer, but I know that it
> > > *should* be theoretically possible; any pointers would be very
> > > appreciated.  
> > 
> > Does this help?
> > 
> > RV730 has DCE3.2
> > 
> > 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.17
> > diff -u -p -U6 -r1.17 atombios_encoders.c
> > --- sys/dev/pci/drm/radeon/atombios_encoders.c  24 Feb 2022
> > 12:49:47 -  1.17 +++
> > sys/dev/pci/drm/radeon/atombios_encoders.c  29 Aug 2022
> > 07:12:12 - @@ -2189,13 +2189,14 @@ int
> > radeon_atom_pick_dig_encoder(struct /*
> >  * On DCE32 any encoder can drive any block so usually just
> > use crtc id,
> >  * but Apple thinks different at least on iMac10,1, so there
> > use linkb,
> >  * otherwise the internal eDP panel will stay dark.
> >  */
> > if (ASIC_IS_DCE32(rdev)) {
> > -   if (dmi_matc

Re: iMac11,2: internal display only works when DisplayPort is connected

2022-08-29 Thread Jonathan Gray
On Mon, Aug 29, 2022 at 07:56:40AM +0100, Hashim Mahmoud wrote:
> This iMac's screen works fine, but always turns off when the radeon GPU
> driver is loaded on any UNIX (tried Linux Mint and NomadBSD as well). I
> had to install OpenBSD on another machine since I was installing to an
> SD card, as I didn't have any (big enough) spare SSDs or USBs, and
> writing to the SD card from the installer on the same iMac gives me
> permission errors.
> 
> I had installed the radeon firmware already by the time I put the SD
> card into the iMac. The GPU seems to work fine and I can login and run
> commands blindly, but the display is off... until I had the bright
> idea to connect a display over the DisplayPort at boot time, via a VGA
> to mini DisplayPort adapter. The internal eDP display worked, but the
> tty framebuffer took the resolution of the external display (similar to
> what would happen when a low resolution laptop is connected to a
> higher resolution display, and both displays are on), which is
> 1440x900, and the external display receives no output, though Xorg
> seems to acknowledge its existence and renders itself as if that
> display exists, as the xenodm login window is not available on the main
> display, and the mouse disappears as if it went to another display when
> hitting the left edge. I can login blind and run `xrandr --output
> DisplayPort-0 --off`, and everything seems to work perfectly fine and
> GPU accelerated, as the output of `glxinfo -B` indicates, and glxgears
> runs smoothly.
> 
> However, this only works if the DisplayPort is connected at boot time:
> 
> - If it is disconnected after the radeon driver is loaded, but X hasn't
> started yet, then the display goes black again, but I can plug it back
> in and the display shows up as normal (still in 1440x900, though), and
> I get this in blue: `[drm] *ERROR* chosen encoder in use 0`. No idea
> what that means.
> 
> - Once X is started however, I can just disconnect the DisplayPort, and
>   life is good :) ... except I get the following in xconsole:
> ```
> [drm] *ERROR* displayport link status failed
> [drm] *ERROR* clock recovery failed
> [drm] *ERROR* displayport link status failed
> [drm] *ERROR* clock recovery failed
> ```
> - Doesn't seem to effect me in any way, though.
> 
> - I also get this error message, when I switch from my X session to
>   tty: `[drm] *ERROR* rv770_restrict_performance_levels_before_switch
>   failed`. Also seems to have no effect.
> - Note that these errors only appear in xconsole and not on the actual
>   console in blue... weird.
> 
> 
> Is there some sort of software remedy for this? I doubt this (unless
> someone can tell me otherwise), so I was thinking of getting something
> like a Raspberry Pi Zero or an Arduino, and connecting to the
> DisplayPort, making it like some sort of dummy DisplayPort input by
> programming it... I'm not sure at all how to go about doing this, as
> I'm a very amateur programmer, but I know that it *should* be
> theoretically possible; any pointers would be very appreciated.

Does this help?

RV730 has DCE3.2

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.17
diff -u -p -U6 -r1.17 atombios_encoders.c
--- sys/dev/pci/drm/radeon/atombios_encoders.c  24 Feb 2022 12:49:47 -  
1.17
+++ sys/dev/pci/drm/radeon/atombios_encoders.c  29 Aug 2022 07:12:12 -
@@ -2189,13 +2189,14 @@ int radeon_atom_pick_dig_encoder(struct 
/*
 * On DCE32 any encoder can drive any block so usually just use crtc id,
 * but Apple thinks different at least on iMac10,1, so there use linkb,
 * 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;
 
goto assigned;
}



Re: X11 hangs on StarLabs Mk IV - snapshot 18-06-2022 - more fun

2022-06-27 Thread Jonathan Gray
On Tue, Jun 28, 2022 at 02:56:51AM +0100, Chris Narkiewicz wrote:
> On Thu, Jun 23, 2022 at 07:59:04AM +1000, Jonathan Gray wrote:
> > I can't think of anything to try but am interested to hear
> > how the AMI firmware goes.
> 
> I managed to hang it in similar way without acceleration.
> I did it by repeatedly switching between efifb console
> and X11. After hang, I still could SSH to the machine
> and trigger hard lockup with pkill X.
> 
> This can suggest that the problem is triggered by the
> efifb->X handover.
> 
> I'm wondering if I could somehow disable efifb and use
> plain vga console instead?

For that the EFI firmware would need to support Compatibility Support
Module (CSM), which is unlikely.  Then a install with mbr/vga/biosboot
could be done.

> 
> 
> I also compared Xorg.0.log between working version (7.1 stable)
> and the b0rked snapshot. I attached both logs (too big for inline).
> It seems that X hangs after trying to set physical screen dimensions:
> 
> ... snip ...
> (II) Initializing extension DRI2
> (II) modeset(0): Damage tracking initialized
> (II) modeset(0): Setting screen physical size to 309 x 173
> 
> 
> Working X follows here with input configuration. Perhaps this
> could open some avenue for investigation? I'm keen on experimenting
> with xenocara to dig deeper, but I'm not familiar with the code.
> 
> It's worth noting the modesetting and intel drivers detect
> different screen dimensions: 309x173 (incorrect) vs 250x140 (correct).

don't use the intel xorg driver on this hardware

If you meant efifb vs inteldrm I noticed a dpi difference there on a
different machine recently.

> 
> Any suggestions will be appreciated.
> 
> Best regards,
> Chris Narkiewicz
> 

> (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
>   (Operation not permitted)
>   Check that you have set 'machdep.allowaperture=1'
>   in /etc/sysctl.conf and reboot your machine
>   refer to xf86(4) for details
>   linear framebuffer access unavailable
> (--) Using wscons driver on /dev/ttyC4
> 
> X.Org X Server 1.21.1.3
> X Protocol Version 11, Revision 0
> Current Operating System: OpenBSD tauceti.etacassiopeiae.net 7.1 
> GENERIC.MP#594 amd64
>  
> Current version of pixman: 0.40.0
>   Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jun 25 02:11:13 2022
> (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d"
> (==) No Layout section.  Using the first Screen section.
> (==) No screen section available. Using defaults.
> (**) |-->Screen "Default Screen Section" (0)
> (**) |   |-->Monitor ""
> (==) No monitor specified for screen "Default Screen Section".
>   Using a default monitor configuration.
> (==) Automatically adding devices
> (==) Automatically enabling devices
> (==) Not automatically adding GPU devices
> (==) Automatically binding GPU devices
> (==) Max clients allowed: 256, resource mask: 0x1f
> (==) FontPath set to:
>   /usr/X11R6/lib/X11/fonts/misc/,
>   /usr/X11R6/lib/X11/fonts/TTF/,
>   /usr/X11R6/lib/X11/fonts/OTF/,
>   /usr/X11R6/lib/X11/fonts/Type1/,
>   /usr/X11R6/lib/X11/fonts/100dpi/,
>   /usr/X11R6/lib/X11/fonts/75dpi/
> (==) ModulePath set to "/usr/X11R6/lib/modules"
> (II) The server relies on wscons to provide the list of input devices.
>   If no devices become available, reconfigure wscons or disable 
> AutoAddDevices.
> (II) Loader magic: 0x6ef5aef37c0
> (II) Module ABI versions:
>   X.Org ANSI C Emulation: 0.4
>   X.Org Video Driver: 25.2
>   X.Org XInput driver : 24.4
>   X.Org Server Extension : 10.0
> (--) PCI:*(0@0:2:0) 8086:3184:8086:2212 rev 6, Mem @ 0xa000/16777216, 
> 0x9000/268435456, I/O @ 0xf000/64
> (II) LoadModule: "glx"
> (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
> (II) Module glx: vendor="X.Org Foundation"
>   compiled for 1.21.1.3, module version = 1.0.0
>   ABI class: X.Org Server Extension, version 10.0
> (==) Matched modesetting as autoconfigured driver 0
> (==) Assigned the driver to the xf86ConfigLayout
> (II) LoadModule: "modesetting"
> (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so
> (II) Module modesetting: vendor="X.Org Foundation"
>   compiled for 1.21.1.3, module version = 1.21.1
> 

Re: Gemini Lake HD Audio (azalia?) not working on StarLabs StarLite MK IV

2022-06-03 Thread Jonathan Gray
On Fri, Jun 03, 2022 at 05:33:15PM +0100, Chris Narkiewicz wrote:
> > Your device is subclass audio not subclass hd audio.  Try this:
> 
> I can confirm that the patch works. Also, headphones are correctly
> detected when plugged.
> 
> Many thanks for the help.

thanks, committed



Re: Gemini Lake HD Audio (azalia?) not working on StarLabs StarLite MK IV

2022-05-31 Thread Jonathan Gray
On Wed, Jun 01, 2022 at 03:03:44AM +0100, Chris Narkiewicz wrote:
> Hi,
> 
> I have a StarLabs StarLite mk iv laptop with Gemini Lake CPU and audio
> device is "not configured".
> 
> Relevant pcidump -vv output:
>  0:14:0: Intel Gemini Lake HD Audio
> 0x: Vendor ID: 8086, Product ID: 3198
> 0x0004: Command: 0006, Status: 0010
> 0x0008: Class: 04 Multimedia, Subclass: 01 Audio,
> Interface: 00, Revision: 06
> 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> Cache Line Size: 10
> 0x0010: BAR mem 64bit addr: 0x9111c000/0x4000
> 0x0018: BAR empty ()
> 0x001c: BAR empty ()
> 0x0020: BAR mem 64bit addr: 0x9100/0x0010
> 0x0028: Cardbus CIS: 
> 0x002c: Subsystem Vendor ID: 8086 Product ID: 7270
> 0x0030: Expansion ROM Base Address: 
> 0x0038: 
> 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
> 0x0050: Capability 0x01: Power Management
> State: D0
> 0x0080: Capability 0x09: Vendor Specific
> 0x0060: Capability 0x05: Message Signalled Interrupts (MSI)
> Enabled: no
> 0x0070: Capability 0x10: PCI Express
> Max Payload Size: 128 / 128 bytes
> Max Read Request Size: 512 bytes
> 0x0100: Enhanced Capability 0x00: Unknown
> 
> Relevant dmesg output:
> cpu0: Intel(R) Pentium(R) Silver N5030 CPU @ 1.10GHz, 2800.01 MHz, 06-7a-08
> "Intel Gemini Lake HD Audio" rev 0x06 at pci0 dev 14 function 0 not configured
> 
> Digging into the /sys source code, I found that it should be handled by 
> azalia driver:
> 
> # grep -r PCI_PRODUCT_INTEL_GLK_HDA . 
> ./dev/pci/azalia.c:   case PCI_PRODUCT_INTEL_GLK_HDA:
> ./dev/pci/pcidevs.h:#define   PCI_PRODUCT_INTEL_GLK_HDA   0x3198  
> /* Gemini Lake HD Audio */
> ./dev/pci/pcidevs_data.h:PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_HDA,
> 
> 
> I'm wondering why it could not be configured and how to dig into this?

Your device is subclass audio not subclass hd audio.  Try this:

Index: sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.272
diff -u -p -r1.272 azalia.c
--- sys/dev/pci/azalia.c1 Apr 2022 22:37:21 -   1.272
+++ sys/dev/pci/azalia.c1 Jun 2022 02:21:41 -
@@ -498,6 +498,7 @@ const struct pci_matchid azalia_pci_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_CAVS },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_JSL_HDA },
 };
 



Re: 7.1/amd64 DejaVuSansMono fonts are much larger than 7.0/amd64

2022-05-01 Thread Jonathan Gray
On Sun, May 01, 2022 at 07:07:36PM -0700, Jonathan Thornburg wrote:
> On a freshly installed 7.1/amd64 (Lenovo Thinkpad T530 laptop), the
> DejaVuSansMono fonts are much larger (i.e., each character occupies
> more screen pixels in both x and y) than on 7.0 and earlier.  This is
> true for both fvwm and twm.
> 
> Empirically, I find that for 7.1,
>   # xterm -fa DejaVuSansMono -fs 7
> is needed to get what appears to be the same sized font (& hence the
> same sized xterm window)
> as
>   # xterm -fa DejaVuSansMono -fs 10
> and produced for 7.0 and earlier on the same hardware.
> 
> Is this as expected?  This being OpenBSD, Is there a Fine Manual I
> should have read that would have informed me of this change before I
> wound up with a bunch of giant xterm windows (whose sizes were/are
> specified in character units)?

This is due to xserver dpi changes
https://marc.info/?l=openbsd-tech=163674121630769=2

> 
> Below I give the output of 'dmesg' and 'xdpyinfo'.
> 
> Keep safe and COVID-free, -- Jonathan
> 
> --- begin dmesg ---
> OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16845565952 (16065MB)
> avail mem = 16317718528 (15561MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (68 entries)
> bios0: vendor LENOVO version "G4ETA7WW (2.67 )" date 08/24/2016
> bios0: LENOVO 24292A9
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT 
> ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) 
> EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.96 MHz, 06-3a-09
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.44 MHz, 06-3a-09
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpiec0 at acpi0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG_)
> acpiprt2 at acpi0: bus 2 (EXP1)
> acpiprt3 at acpi0: bus 3 (EXP2)
> acpiprt4 at acpi0: bus 4 (EXP3)
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpicmos0 at acpi0
> acpibat0 at acpi0: BAT0 model "45N1011" serial 54386 type LION oem "LGC"
> acpiac0 at acpi0: AC unit online
> "LEN0078" at acpi0 not configured
> acpithinkpad0 at acpi0: version 1.0
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2
> acpitz0 at acpi0: critical temperature is 103 degC
> acpivideo0 at acpi0: VID_
> acpivout0 at acpivideo0: LCD0
> acpivideo1 at acpi0: VID_
> cpu0: using VERW MDS workaround (except on vmm entry)
> cpu0: Enhanced SpeedStep 2893 MHz: speeds: 2901, 2900, 2800, 2700, 2500, 
> 2400, 2300, 2200, 2000, 1900, 1800, 1700, 1600, 1400, 1300, 1200 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
> inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09
> drm0 at inteldrm0
> inteldrm0: msi, IVYBRIDGE, gen 7
> xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi, xHCI 1.0
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
> addr 1
> "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured

Re: Dell G3 3590 audio and touchpad

2022-04-03 Thread Jonathan Gray
On Sun, Apr 03, 2022 at 09:56:09AM -0400, Adriano Barbosa wrote:
> Em dom., 3 de abr. de 2022 às 09:38, Jonathan Gray  escreveu:
> >
> > On Sun, Apr 03, 2022 at 09:22:24AM -0400, Adriano Barbosa wrote:
> > > Em dom., 3 de abr. de 2022 às 00:38, Jonathan Gray  
> > > escreveu:
> > >
> > > > On Sat, Apr 02, 2022 at 09:45:11AM -0400, Adriano Barbosa wrote:
> > > > > Em sex., 1 de abr. de 2022 às 18:46, Jonathan Gray 
> > > > escreveu:
> > > > >
> > > > > > On Fri, Apr 01, 2022 at 05:11:35PM -0400, Adriano Barbosa wrote:
> > > > > > > Thank you for your help and sorry for the delay.
> > > > > > > I had to learn how to compile from source and still not sure if I
> > > > did it
> > > > > > > correctly or if the patch didn't work.
> > > > > > > I downloaded src.tar.gz and sys.tar.gz from 7.0 release, updated 
> > > > > > > to
> > > > > > -current
> > > > > > > using cvs and applied the patch. Then, followed only step 3 of
> > > > release(8)
> > > > > > > (which took around 60 minutes to build). I repeated it twice to 
> > > > > > > make
> > > > > > sure I
> > > > > > > didn't miss any step, but the result was the same, still getting
> > > > "Intel
> > > > > > 300
> > > > > > > Series cAVS" rev 0x10 at pci0 dev 31 function 3 not configured in
> > > > dmesg.
> > > > > > > Should I do anything else or anything different?
> > > > > > >
> > > > > > > Obrigado!
> > > > > >
> > > > > > I've committed this change.  Try a snapshot in a few days time.
> > > > > >
> > > > > >
> > > > > Managed to compile correctly and the audio patch works.
> > > > > Thank you very much!
> > > > >
> > > > > Any hints on the touchpad? Looks like it is configured (Intel 300 
> > > > > Series
> > > > > I2C,
> > > > > right?), but it doesn't move or click. Any tool to test it?
> > > > >
> > > > > dwiic0 at pci0 dev 21 function 0 "Intel 300 Series I2C" rev 0x10: 
> > > > > apic 2
> > > > > int 16
> > > > > iic0 at dwiic0
> > > > > dwiic1 at pci0 dev 21 function 1 "Intel 300 Series I2C" rev 0x10: 
> > > > > apic 2
> > > > > int 17
> > > > > iic1 at dwiic1
> > > > > ihidev0 at iic1 addr 0x2cdwiic1: timed out reading remaining 30
> > > > > , failed fetching initial HID descriptor
> > > >
> > > > this is less clear, does the following diff to force polling help?
> > > >
> > > > Index: sys/dev/pci/dwiic_pci.c
> > > > ===
> > > > RCS file: /cvs/src/sys/dev/pci/dwiic_pci.c,v
> > > > retrieving revision 1.20
> > > > diff -u -p -r1.20 dwiic_pci.c
> > > > --- sys/dev/pci/dwiic_pci.c 11 Mar 2022 18:00:45 -  1.20
> > > > +++ sys/dev/pci/dwiic_pci.c 3 Apr 2022 04:28:45 -
> > > > @@ -212,7 +212,8 @@ dwiic_pci_attach(struct device *parent,
> > > >
> > > > /* install interrupt handler */
> > > > sc->sc_poll = 1;
> > > > -   if (pci_intr_map(>sc_paa, ) == 0) {
> > > > +// if (pci_intr_map(>sc_paa, ) == 0) {
> > > > +   if (0) {
> > > > intrstr = pci_intr_string(sc->sc_paa.pa_pc, ih);
> > > > sc->sc_ih = pci_intr_establish(sc->sc_paa.pa_pc, ih,
> > > > IPL_BIO,
> > > > dwiic_intr, sc, sc->sc_dev.dv_xname);
> > > >
> > > >
> > > Thank you again for all the help!
> > >
> > > I see polling on dmesg, but touchpad still doesn't work:
> > > dwiic0 at pci0 dev 21 function 0 "Intel 300 Series I2C" rev 0x10: polling
> > > iic0 at dwiic0
> > > dwiic1 at pci0 dev 21 function 1 "Intel 300 Series I2C" rev 0x10: polling
> > > iic1 at dwiic1
> > > ihidev0 at iic1 addr 0x2cdwiic1: timed out reading remaining 30
> > > , failed fetching initial HID descriptor
> > >
> > > 0:21:0: Intel 300 Series I2C
> > > 0x: Vendor ID: 8086, Product ID: a368
> &

Re: Dell G3 3590 audio and touchpad

2022-04-03 Thread Jonathan Gray
On Sun, Apr 03, 2022 at 09:22:24AM -0400, Adriano Barbosa wrote:
> Em dom., 3 de abr. de 2022 às 00:38, Jonathan Gray  escreveu:
> 
> > On Sat, Apr 02, 2022 at 09:45:11AM -0400, Adriano Barbosa wrote:
> > > Em sex., 1 de abr. de 2022 às 18:46, Jonathan Gray 
> > escreveu:
> > >
> > > > On Fri, Apr 01, 2022 at 05:11:35PM -0400, Adriano Barbosa wrote:
> > > > > Thank you for your help and sorry for the delay.
> > > > > I had to learn how to compile from source and still not sure if I
> > did it
> > > > > correctly or if the patch didn't work.
> > > > > I downloaded src.tar.gz and sys.tar.gz from 7.0 release, updated to
> > > > -current
> > > > > using cvs and applied the patch. Then, followed only step 3 of
> > release(8)
> > > > > (which took around 60 minutes to build). I repeated it twice to make
> > > > sure I
> > > > > didn't miss any step, but the result was the same, still getting
> > "Intel
> > > > 300
> > > > > Series cAVS" rev 0x10 at pci0 dev 31 function 3 not configured in
> > dmesg.
> > > > > Should I do anything else or anything different?
> > > > >
> > > > > Obrigado!
> > > >
> > > > I've committed this change.  Try a snapshot in a few days time.
> > > >
> > > >
> > > Managed to compile correctly and the audio patch works.
> > > Thank you very much!
> > >
> > > Any hints on the touchpad? Looks like it is configured (Intel 300 Series
> > > I2C,
> > > right?), but it doesn't move or click. Any tool to test it?
> > >
> > > dwiic0 at pci0 dev 21 function 0 "Intel 300 Series I2C" rev 0x10: apic 2
> > > int 16
> > > iic0 at dwiic0
> > > dwiic1 at pci0 dev 21 function 1 "Intel 300 Series I2C" rev 0x10: apic 2
> > > int 17
> > > iic1 at dwiic1
> > > ihidev0 at iic1 addr 0x2cdwiic1: timed out reading remaining 30
> > > , failed fetching initial HID descriptor
> >
> > this is less clear, does the following diff to force polling help?
> >
> > Index: sys/dev/pci/dwiic_pci.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/dwiic_pci.c,v
> > retrieving revision 1.20
> > diff -u -p -r1.20 dwiic_pci.c
> > --- sys/dev/pci/dwiic_pci.c 11 Mar 2022 18:00:45 -  1.20
> > +++ sys/dev/pci/dwiic_pci.c 3 Apr 2022 04:28:45 -
> > @@ -212,7 +212,8 @@ dwiic_pci_attach(struct device *parent,
> >
> > /* install interrupt handler */
> > sc->sc_poll = 1;
> > -   if (pci_intr_map(>sc_paa, ) == 0) {
> > +// if (pci_intr_map(>sc_paa, ) == 0) {
> > +   if (0) {
> > intrstr = pci_intr_string(sc->sc_paa.pa_pc, ih);
> > sc->sc_ih = pci_intr_establish(sc->sc_paa.pa_pc, ih,
> > IPL_BIO,
> > dwiic_intr, sc, sc->sc_dev.dv_xname);
> >
> >
> Thank you again for all the help!
> 
> I see polling on dmesg, but touchpad still doesn't work:
> dwiic0 at pci0 dev 21 function 0 "Intel 300 Series I2C" rev 0x10: polling
> iic0 at dwiic0
> dwiic1 at pci0 dev 21 function 1 "Intel 300 Series I2C" rev 0x10: polling
> iic1 at dwiic1
> ihidev0 at iic1 addr 0x2cdwiic1: timed out reading remaining 30
> , failed fetching initial HID descriptor
> 
> 0:21:0: Intel 300 Series I2C
> 0x: Vendor ID: 8086, Product ID: a368
> 0x0004: Command: 0006, Status: 0010
> 0x0008: Class: 0c Serial Bus, Subclass: 80 (unknown),
> Interface: 00, Revision: 10
> 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
> Cache Line Size: 10
> 0x0010: BAR mem 64bit addr: 0xa5528000/0x1000
> 0x0018: BAR mem 64bit addr: 0xa5527000/0x1000
> 0x0020: BAR empty ()
> 0x0024: BAR empty ()
> 0x0028: Cardbus CIS: 
> 0x002c: Subsystem Vendor ID: 1028 Product ID: 0949
> 0x0030: Expansion ROM Base Address: 
> 0x0038: 
> 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
> 0x0080: Capability 0x01: Power Management
> State: D0
> 0x0090: Capability 0x09: Vendor Specific
> 
> 
> Also, although audio output works both on speakers and audio jack,
> audio recording is not working. Is it supposed to work on this card?
> I found some info about it on Linux that I suppose can help, but I'm
> not able to make any change myself:
> https://lore.kernel.org/all/s5h8rzdjkkf.wl-ti...@suse.de/T/

To enable audio recording 

Re: Dell G3 3590 audio and touchpad

2022-04-02 Thread Jonathan Gray
On Sat, Apr 02, 2022 at 09:45:11AM -0400, Adriano Barbosa wrote:
> Em sex., 1 de abr. de 2022 às 18:46, Jonathan Gray  escreveu:
> 
> > On Fri, Apr 01, 2022 at 05:11:35PM -0400, Adriano Barbosa wrote:
> > > Thank you for your help and sorry for the delay.
> > > I had to learn how to compile from source and still not sure if I did it
> > > correctly or if the patch didn't work.
> > > I downloaded src.tar.gz and sys.tar.gz from 7.0 release, updated to
> > -current
> > > using cvs and applied the patch. Then, followed only step 3 of release(8)
> > > (which took around 60 minutes to build). I repeated it twice to make
> > sure I
> > > didn't miss any step, but the result was the same, still getting "Intel
> > 300
> > > Series cAVS" rev 0x10 at pci0 dev 31 function 3 not configured in dmesg.
> > > Should I do anything else or anything different?
> > >
> > > Obrigado!
> >
> > I've committed this change.  Try a snapshot in a few days time.
> >
> >
> Managed to compile correctly and the audio patch works.
> Thank you very much!
> 
> Any hints on the touchpad? Looks like it is configured (Intel 300 Series
> I2C,
> right?), but it doesn't move or click. Any tool to test it?
> 
> dwiic0 at pci0 dev 21 function 0 "Intel 300 Series I2C" rev 0x10: apic 2
> int 16
> iic0 at dwiic0
> dwiic1 at pci0 dev 21 function 1 "Intel 300 Series I2C" rev 0x10: apic 2
> int 17
> iic1 at dwiic1
> ihidev0 at iic1 addr 0x2cdwiic1: timed out reading remaining 30
> , failed fetching initial HID descriptor

this is less clear, does the following diff to force polling help?

Index: sys/dev/pci/dwiic_pci.c
===
RCS file: /cvs/src/sys/dev/pci/dwiic_pci.c,v
retrieving revision 1.20
diff -u -p -r1.20 dwiic_pci.c
--- sys/dev/pci/dwiic_pci.c 11 Mar 2022 18:00:45 -  1.20
+++ sys/dev/pci/dwiic_pci.c 3 Apr 2022 04:28:45 -
@@ -212,7 +212,8 @@ dwiic_pci_attach(struct device *parent, 
 
/* install interrupt handler */
sc->sc_poll = 1;
-   if (pci_intr_map(>sc_paa, ) == 0) {
+// if (pci_intr_map(>sc_paa, ) == 0) {
+   if (0) {
intrstr = pci_intr_string(sc->sc_paa.pa_pc, ih);
sc->sc_ih = pci_intr_establish(sc->sc_paa.pa_pc, ih, IPL_BIO,
dwiic_intr, sc, sc->sc_dev.dv_xname);



Re: Dell G3 3590 audio and touchpad

2022-04-01 Thread Jonathan Gray
On Fri, Apr 01, 2022 at 05:11:35PM -0400, Adriano Barbosa wrote:
> Thank you for your help and sorry for the delay.
> I had to learn how to compile from source and still not sure if I did it
> correctly or if the patch didn't work.
> I downloaded src.tar.gz and sys.tar.gz from 7.0 release, updated to -current
> using cvs and applied the patch. Then, followed only step 3 of release(8)
> (which took around 60 minutes to build). I repeated it twice to make sure I
> didn't miss any step, but the result was the same, still getting "Intel 300
> Series cAVS" rev 0x10 at pci0 dev 31 function 3 not configured in dmesg.
> Should I do anything else or anything different?
> 
> Obrigado!

I've committed this change.  Try a snapshot in a few days time.



Re: Dell G3 3590 audio and touchpad

2022-03-31 Thread Jonathan Gray
On Thu, Mar 31, 2022 at 10:54:17AM -0400, Adriano Barbosa wrote:
> Hi misc
> 
> I'm trying to make audio and touchpad work on a Dell laptop.
> I've never played with this kind of stuff and I don't even know how to
> properly start.
> I have no hope on making NVIDIA hardware to work, but I believe
> Realtek ALC295 audio could work as, from what I got, it is supported
> by OpenBSD.
> 
> >From FreeBSD (where audio and touchpad work) I get the following information:
> 
> hdacc0:  at cad 0 on hdac0
> hdaa0:  at nid 1 on hdacc0
> pcm0:  at nid 7 on hdaa0
> 
> hdacc1:  at cad 0 on hdac1
> hdaa1:  at nid 1 on hdacc1
> pcm1:  at nid 20 on hdaa1
> pcm2:  at nid 33 on hdaa1
> hdacc2:  at cad 2 on hdac1
> hdaa2:  at nid 1 on hdacc2
> pcm3:  at nid 3 on hdaa2
> 
> hms0:  on hidbus0
> hms0: 2 buttons and [XY] coordinates ID=1
> hmt0:  on hidbus0
> hconf0:  on hidbus0
> hmt0: Multitouch touchpad with 0 external buttons, click-pad
> hmt0: 5 contacts with [C] properties. Report range [0:0] - [3211:2431]
> 
> On  OpenBSD (where audio and touchpad don't work) I can identify the
> following relevant information on dmesg:
> 
> "Intel 300 Series cAVS" rev 0x10 at pci0 dev 31 function 3 not configured

does not match as it uses pci subclass audio instead of hd audio
should work with this

Index: sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.271
diff -u -p -r1.271 azalia.c
--- sys/dev/pci/azalia.c21 Mar 2022 19:22:41 -  1.271
+++ sys/dev/pci/azalia.c31 Mar 2022 23:31:08 -
@@ -494,6 +494,7 @@ azalia_configure_pci(azalia_t *az)
 
 const struct pci_matchid azalia_pci_devices[] = {
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_200SERIES_U_HDA },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_CAVS },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_CAVS },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA },



Re: some graphics (firmware?) problems

2022-02-20 Thread Jonathan Gray
On Mon, Feb 21, 2022 at 04:53:50AM +, Claus Assmann wrote:
> On Mon, Feb 21, 2022, Jonathan Gray wrote:
> 
> > No, it is not firmware.  But I'd need to see a dmesg with inteldrm
> > enabled to comment further.  In -current there is a different version of
> 
> That should be this one:

> inteldrm0 at pci0 dev 2 function 0 "Intel 82Q965 Video" rev 0x02
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0: apic 2 int 16, I965G, gen 4

Handled with the following commit.  The workaround is still there.
I haven't checked if it is still needed after the drm update.

sys/dev/pci/drm/i915/gem/i915_gem_context.c


revision 1.6
date: 2021/10/02 14:26:05;  author: jsg;  state: Exp;  lines: +3 -2;  commitid: 
fnFjt33nCWo0vNlX;
Extend workaround for reset on context closure from gen 7-8 to gen 4-8
as asavvycomput...@disroot.org reported this occurs on gm45 (gen 4).




Re: some graphics (firmware?) problems

2022-02-20 Thread Jonathan Gray
On Sun, Feb 20, 2022 at 05:14:57PM +, Claus Assmann wrote:
> Yesterday the monitor on my OpenBSD 7.0 box went blank twice while
> using firefox. Later on I found these entries in the log:
> 
> Feb 19 10:17:38 vxrs /bsd: drm:pid11842:intel_gt_reset *NOTICE* [drm] 
> Resetting chip for context closure in firefox<11842>
> Feb 19 11:06:10 vxrs /bsd: drm:pid1527:intel_gt_reset *NOTICE* [drm] 
> Resetting chip for context closure in firefox<1527>
> 
> According to some posting the firmware has to be updated, but AFAICT
> that requires to update the OS to a snapshot (i.e., I cannot install
> the newer firmware on 7.0 and expect it to work?), hence it's not a
> good solution for me right now.

No, it is not firmware.  But I'd need to see a dmesg with inteldrm
enabled to comment further.  In -current there is a different version of
drm, so worth testing for that reason.

> 
> Instead I added an ATI Radeon HD3450 256MB Dual DVI graphics card,
> but that didn't work so well either.
> 
> radeondrm0: RV620
> drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> [TTM] Memory type 2 has not been initialized
> drm0 detached
> radeondrm0 detached
> and hence X didn't find the right driver (?).
> There was something in the archives about this back in 2019:
>   xserver problem with 1.19.7->1.20.5
> so this doesn't seem to apply to OpenBSD 7.0 (Xorg 1.20.13)?
> 
> I guess that card is not supported (at all)?
> 

It is unclear why the right bios is not found, but again try
-current.

> 
> dmesg and Xorg log follow (the latter has been shortened because
> it was very long, there does not seem to be anything relevant to
> this problem after the last "EE").
> 
> ==
> OpenBSD 7.0 (GENERIC) #224: Thu Sep 30 14:13:34 MDT 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> real mem = 4208492544 (4013MB)
> avail mem = 4065021952 (3876MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe3c30 (38 entries)
> bios0: vendor Intel Corp. version "CO96510J.86A.5773.2007.0206.0046" date 
> 02/06/2007
> bios0: Intel Corporation DQ965GF
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC WDDT MCFG ASF! SSDT SSDT SSDT SSDT SSDT TCPA
> acpi0: wakeup devices SLPB(S4) P32_(S4) ILAN(S4) PEGP(S4) PEX0(S4) PEX1(S4) 
> PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) 
> EHCI(S3) EHC2(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz, 2397.94 MHz, 06-0f-06
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu0: 4MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 266MHz
> cpu0: mwait min=64, max=64, C-substates=0.2, IBE
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-127
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 7 (P32_)
> acpiprt2 at acpi0: bus 2 (PEX0)
> acpiprt3 at acpi0: bus 3 (PEX1)
> acpiprt4 at acpi0: bus 4 (PEX2)
> acpiprt5 at acpi0: bus 5 (PEX3)
> acpiprt6 at acpi0: bus 6 (PEX4)
> acpiprt7 at acpi0: bus -1 (PEX5)
> acpibtn0 at acpi0: SLPB
> acpipci0 at acpi0 PCI0
> acpicmos0 at acpi0
> "PNP0003" at acpi0 not configured
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> cpu0: Enhanced SpeedStep 2397 MHz: speeds: 2394, 1596 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82Q965 Host" rev 0x02
> ppb0 at pci0 dev 1 function 0 "Intel 82Q965 PCIE" rev 0x02: apic 2 int 16
> pci1 at ppb0 bus 1
> 1:0:0: rom address conflict 0xfffe/0x2
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 3450" rev 0x00
> drm0 at radeondrm0
> radeondrm0: apic 2 int 16
> azalia0 at pci1 dev 0 function 1 "ATI Radeon HD 34xx HD Audio" rev 0x00: apic 
> 2 int 17
> azalia0: no supported codecs
> "Intel 82Q965 HECI" rev 0x02 at pci0 dev 3 function 0 not configured
> pciide0 at pci0 dev 3 function 2 "Intel 82Q965 PT IDER" rev 0x02: DMA 
> (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
> pciide0: using apic 2 int 18 for native-PCI interrupt
> pciide0: channel 0 ignored (not responding; disabled or no drives?)
> pciide0: channel 1 ignored (not responding; disabled or no drives?)
> puc0 at pci0 dev 3 function 3 "Intel 82Q965 KT" rev 0x02: ports: 16 com
> com4 at puc0 port 0 apic 2 int 17: ns16550a, 16 byte fifo
> com4: probed fifo depth: 15 bytes
> em0 at 

Re: Either intel nor glamor drivers do not work for Samsung NC215S

2022-02-03 Thread Jonathan Gray
On Thu, Feb 03, 2022 at 07:59:44PM +0300, Sergey Andrianov wrote:
> Hello, I've recently found some old Atom-based netbook in a "trash"
> box in my friend's house. HDD was dead, so I've replaced it with
> Kingston SSD and installed OpenBSD 7. I've installed Xorg, but I can't
> manage to start it.
> 
> According to the specs of this netbook, the graphics card is Intel GMA
> 3150. But I did not find any solution for this particular adapter for
> OpenBSD.

xf86-video-intel needs to scan the pci bus, you need to use
xenodm not startx on this hardware

we stopped installing the xserver setuid in 2018

> 
> Here are dmesg and logs:
> 
> OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2119892992 (2021MB)
> avail mem = 2039676928 (1945MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xdf010 (29 entries)
> bios0: vendor Phoenix Technologies Ltd. version
> "02FR.M025.20110711.RHU" date 07/11/2011
> bios0: SAMSUNG ELECTRONICS CO., LTD. NC215S
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP MCFG HPET APIC BOOT SLIC SSDT SSDT SSDT SSDT SSDT
> acpi0: wakeup devices EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCIB(S3) PWRB(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-16
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU N570 @ 1.66GHz, 4821.60 MHz, 06-1c-0a
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu0: 512KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Atom(TM) CPU N570 @ 1.66GHz, 997.51 MHz, 06-1c-0a
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu1: 512KB 64b/line 8-way L2 cache
> cpu1: disabling user TSC (skew=345)
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Atom(TM) CPU N570 @ 1.66GHz, 1662.51 MHz, 06-1c-0a
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu2: 512KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 0, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Atom(TM) CPU N570 @ 1.66GHz, 997.51 MHz, 06-1c-0a
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu3: 512KB 64b/line 8-way L2 cache
> cpu3: disabling user TSC (skew=300)
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 5 (EXP1)
> acpiprt2 at acpi0: bus 7 (EXP2)
> acpiprt3 at acpi0: bus 9 (EXP3)
> acpiprt4 at acpi0: bus 11 (EXP4)
> acpiprt5 at acpi0: bus 17 (PCIB)
> acpiec0 at acpi0
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpibat0 at acpi0: BAT1 type LION oem "SAMSUNG Electronics"
> acpicmos0 at acpi0
> acpiac0 at acpi0: AC unit online
> acpibtn0 at acpi0: LID0
> acpibtn1 at acpi0: PWRB
> acpibtn2 at acpi0: SLPB
> acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C1(1000@1 mwait.1), PSS
> acpitz0 at acpi0: critical temperature is 98 degC
> acpivideo0 at acpi0: IGD0
> acpivout0 at acpivideo0: DD04
> cpu0: Enhanced SpeedStep 4821 MHz: speeds: 1667, 1333, 1000 MHz
> pci0 at mainbus0 bus 0
> 0:29:7: mem address conflict 0xf0504000/0x400
> pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
> inteldrm0 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0: apic 4 int 16, PINEVIEW, gen 3
> "Intel Pineview Video" rev 0x02 at pci0 dev 2 function 1 not configured
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
> azalia0: codecs: Realtek ALC269
> audio0 at azalia0
> ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: msi
> pci1 at ppb0 bus 5
> 

Re: Edimax EW-7612UAN V2 appears as "generic" Realtek WLAN Adapter

2022-01-25 Thread Jonathan Gray
On Tue, Jan 25, 2022 at 08:16:43PM +0100, Joel Carnat wrote:
> Le 25/01/2022 à 01:32, Jonathan Gray a écrit :
> > On Tue, Jan 25, 2022 at 01:08:16AM +0100, Joel Carnat wrote:
> > > Hello,
> > > 
> > > Because my Internet Box has just died, I plugged a spare Edimax EW-7612UAN
> > > V2 on my OpenBSD 7.0 router and connected it to my iPhone WiFi connection
> > > sharing. I've tested it for a few hours with Video-on-Demand, email etc 
> > > and
> > > it works without issues.
> > > 
> > > The thing is it seems to be recognized as a generic Realtek device:
> > > 
> > > # dmesg
> > > (...)
> > > urtwn0 at uhub0 port 4 configuration 1 interface 0 "Realtek 802.11n WLAN
> > > Adapter" rev 2.00/2.00 addr 2
> > > urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address 08:be:ac:1d:40:96
> > > 
> > > # usbdevs -v
> > > (...)
> > > addr 02: 7392:7822 Realtek, 802.11n WLAN Adapter
> > >   high speed, power 500 mA, config 1, rev 2.00, iSerial 
> > > 00e04c01
> > >   driver: urtwn0
> > > 
> > > It is also not referenced in the man page as a supported device.
> > > 
> > > In src/sys/dev/usb/usbdevs, on line 1722, I could can find
> > > product EDIMAX RTL8192CU   0x7822  RTL8192CU
> > > but I have no real clue about what to modify and propose a diff. Sorry.
> > 
> > for usb, strings from the device are preferred with usbdevs as fallback
> > see usbd_cache_devinfo() in sys/dev/usb/usb_subr.c
> > 
> 
> Hum, ok. Does this means that particular device does not announce itself
> with the proper brand/model but with a generic identifier?

Yes, likely those strings are the defaults from Realtek.



Re: Edimax EW-7612UAN V2 appears as "generic" Realtek WLAN Adapter

2022-01-24 Thread Jonathan Gray
On Tue, Jan 25, 2022 at 01:08:16AM +0100, Joel Carnat wrote:
> Hello,
> 
> Because my Internet Box has just died, I plugged a spare Edimax EW-7612UAN
> V2 on my OpenBSD 7.0 router and connected it to my iPhone WiFi connection
> sharing. I've tested it for a few hours with Video-on-Demand, email etc and
> it works without issues.
> 
> The thing is it seems to be recognized as a generic Realtek device:
> 
> # dmesg
> (...)
> urtwn0 at uhub0 port 4 configuration 1 interface 0 "Realtek 802.11n WLAN
> Adapter" rev 2.00/2.00 addr 2
> urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address 08:be:ac:1d:40:96
> 
> # usbdevs -v
> (...)
> addr 02: 7392:7822 Realtek, 802.11n WLAN Adapter
>  high speed, power 500 mA, config 1, rev 2.00, iSerial 00e04c01
>  driver: urtwn0
> 
> It is also not referenced in the man page as a supported device.
> 
> In src/sys/dev/usb/usbdevs, on line 1722, I could can find
> product EDIMAX RTL8192CU   0x7822  RTL8192CU
> but I have no real clue about what to modify and propose a diff. Sorry.

for usb, strings from the device are preferred with usbdevs as fallback
see usbd_cache_devinfo() in sys/dev/usb/usb_subr.c

> 
> Regards,
> Joel C.
> 
> 



Re: Documentation error in pci_mapreg_probe(9)

2022-01-10 Thread Jonathan Gray
On Mon, Jan 10, 2022 at 09:17:25PM +1100, Jonathan Gray wrote:
> On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote:
> > 
> > On 2022-01-10 2:18 a.m., Jonathan Gray wrote:
> > > On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote:
> > > > The manpage incorrectly describes the behaviour and usage of
> > > > pci_mapreg_probe(9). This function does not return 0 for success and !0
> > > > for failure as described in the manual, see the diff below for a
> > > > possible re-wording and corrected description.
> > > 
> > > I agree the return value is wrong but your description introduces an
> > > error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example.
> > > Which is something that the pci_mapreg_type text also gets wrong.
> > > 
> > > How about this to start with?
> > 
> > It certainly corrects the mechanical issue with the returns, it doesn't help
> > though with understanding how to use the function correctly though.  Under
> > what circumstances will the type bits get set as you indicate? I wasn't at
> > all clear about that from peering through the call tree.
> 
> as the define would suggest, when it is a 64-bit mem bar

expanding on this some more

Index: pci_mapreg_map.9
===
RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v
retrieving revision 1.1
diff -u -p -r1.1 pci_mapreg_map.9
--- pci_mapreg_map.923 Feb 2019 04:54:25 -  1.1
+++ pci_mapreg_map.910 Jan 2022 10:51:36 -
@@ -128,6 +128,11 @@ pointers.
 attempts to determine if the BAR referenced by
 .Fa reg
 describes a valid register mapping.
+If it does
+.Fa typep
+will point to a value with flags matching those described for the return value
+of
+.Nm pci_mapreg_type .
 .Pp
 .Nm pci_mapreg_type
 returns the type of register access for the registers at the BAR
@@ -135,18 +140,22 @@ referenced by
 .Fa reg .
 .Sh RETURN VALUES
 .Nm pci_mapreg_map ,
-.Nm pci_mapreg_info ,
 and
-.Nm pci_mapreg_probe
+.Nm pci_mapreg_info
 return 0 on success, or an
 .Xr errno 2
 style value on failure.
 .Pp
+.Nm pci_mapreg_probe
+returns 1 if if the BAR describes a valid mapping, 0 if not.
+.Pp
 .Nm pci_mapreg_type
-returns either
-.Dv PCI_MAPREG_TYPE_IO
-or
-.Dv PCI_MAPREG_TYPE_MEM .
+returns a value with flags for type information.
+.Dv PCI_MAPREG_TYPE_IO ,
+.Dv PCI_MAPREG_TYPE_MEM ,
+.Dv PCI_MAPREG_MEM_TYPE_32BIT ,
+.Dv PCI_MAPREG_MEM_TYPE_32BIT_1M and
+.Dv PCI_MAPREG_MEM_TYPE_64BIT .
 .Sh SEE ALSO
 .Xr pci 4 ,
 .Xr bus_space 9 ,



Re: Documentation error in pci_mapreg_probe(9)

2022-01-10 Thread Jonathan Gray
On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote:
> 
> On 2022-01-10 2:18 a.m., Jonathan Gray wrote:
> > On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote:
> > > The manpage incorrectly describes the behaviour and usage of
> > > pci_mapreg_probe(9). This function does not return 0 for success and !0
> > > for failure as described in the manual, see the diff below for a
> > > possible re-wording and corrected description.
> > 
> > I agree the return value is wrong but your description introduces an
> > error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example.
> > Which is something that the pci_mapreg_type text also gets wrong.
> > 
> > How about this to start with?
> 
> It certainly corrects the mechanical issue with the returns, it doesn't help
> though with understanding how to use the function correctly though.  Under
> what circumstances will the type bits get set as you indicate? I wasn't at
> all clear about that from peering through the call tree.

as the define would suggest, when it is a 64-bit mem bar

for example

0x0010: BAR mem 64bit addr: 0xf122/0x0001

xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: bar 0x10 type 
0x4 : msi, xHCI 1.0

Index: xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
retrieving revision 1.10
diff -u -p -r1.10 xhci_pci.c
--- xhci_pci.c  18 Nov 2018 08:46:57 -  1.10
+++ xhci_pci.c  10 Jan 2022 09:54:09 -
@@ -134,6 +134,7 @@ xhci_pci_attach(struct device *parent, s
pci_intr_handle_t ih;
pcireg_t reg;
int error;
+   pcireg_t type;
 
reg = pci_mapreg_type(pa->pa_pc, pa->pa_tag, PCI_CBMEM);
if (pci_mapreg_map(pa, PCI_CBMEM, reg, 0, >sc.iot, >sc.ioh,
@@ -141,6 +142,9 @@ xhci_pci_attach(struct device *parent, s
printf(": can't map mem space\n");
return;
}
+
+   if (pci_mapreg_probe(pa->pa_pc, pa->pa_tag, 0x10, ))
+   printf(": bar 0x10 type 0x%x ", type);
 
psc->sc_pc = pa->pa_pc;
psc->sc_tag = pa->pa_tag;

from pcireg.h:

#define PCI_MAPREG_TYPE(mr) \
((mr) & PCI_MAPREG_TYPE_MASK)
#define PCI_MAPREG_TYPE_MASK0x0001

#define PCI_MAPREG_TYPE_MEM 0x
#define PCI_MAPREG_TYPE_IO  0x0001

#define PCI_MAPREG_MEM_TYPE(mr) \
((mr) & PCI_MAPREG_MEM_TYPE_MASK)
#define PCI_MAPREG_MEM_TYPE_MASK0x0006

#define PCI_MAPREG_MEM_TYPE_32BIT   0x
#define PCI_MAPREG_MEM_TYPE_32BIT_1M0x0002
#define PCI_MAPREG_MEM_TYPE_64BIT   0x0004

#define _PCI_MAPREG_TYPEBITS(reg) \
(PCI_MAPREG_TYPE(reg) == PCI_MAPREG_TYPE_IO ? \
reg & PCI_MAPREG_TYPE_MASK : \
reg & (PCI_MAPREG_TYPE_MASK|PCI_MAPREG_MEM_TYPE_MASK))

> 
> Anyway it's certainly a weakness of the document. This at least stops the
> error from the return values.
> 
> > 
> > Index: pci_mapreg_map.9
> > ===
> > RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 pci_mapreg_map.9
> > --- pci_mapreg_map.923 Feb 2019 04:54:25 -  1.1
> > +++ pci_mapreg_map.910 Jan 2022 09:13:30 -
> > @@ -135,12 +135,14 @@ referenced by
> >   .Fa reg .
> >   .Sh RETURN VALUES
> >   .Nm pci_mapreg_map ,
> > -.Nm pci_mapreg_info ,
> >   and
> > -.Nm pci_mapreg_probe
> > +.Nm pci_mapreg_info
> >   return 0 on success, or an
> >   .Xr errno 2
> >   style value on failure.
> > +.Pp
> > +.Nm pci_mapreg_probe
> > +returns 1 if if the BAR is implemented, 0 if not.
> >   .Pp
> >   .Nm pci_mapreg_type
> >   returns either
> 
> -- 
> Ted Bullock 
> 
> 



Re: Documentation error in pci_mapreg_probe(9)

2022-01-10 Thread Jonathan Gray
On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote:
> The manpage incorrectly describes the behaviour and usage of
> pci_mapreg_probe(9). This function does not return 0 for success and !0
> for failure as described in the manual, see the diff below for a
> possible re-wording and corrected description.

I agree the return value is wrong but your description introduces an
error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example.
Which is something that the pci_mapreg_type text also gets wrong.

How about this to start with?

Index: pci_mapreg_map.9
===
RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v
retrieving revision 1.1
diff -u -p -r1.1 pci_mapreg_map.9
--- pci_mapreg_map.923 Feb 2019 04:54:25 -  1.1
+++ pci_mapreg_map.910 Jan 2022 09:13:30 -
@@ -135,12 +135,14 @@ referenced by
 .Fa reg .
 .Sh RETURN VALUES
 .Nm pci_mapreg_map ,
-.Nm pci_mapreg_info ,
 and
-.Nm pci_mapreg_probe
+.Nm pci_mapreg_info
 return 0 on success, or an
 .Xr errno 2
 style value on failure.
+.Pp
+.Nm pci_mapreg_probe
+returns 1 if if the BAR is implemented, 0 if not.
 .Pp
 .Nm pci_mapreg_type
 returns either



Re: power of 2 revisited

2021-12-29 Thread Jonathan Gray
On Wed, Dec 29, 2021 at 09:27:34PM -0700, Ted Bullock wrote:
> This started out as a direct question to Ingo, but I have readdressed it
> to misc@
> 
> This is around documenting peculiar behaviour around power of 2 math in
> the kernel.
> 
> I noticed that in sys/dev/pci/drm/radeon/radeon_device.c:1137 there is a
> call to radeon_check_pot_argument, this function isn't correct in that
> it returns true for a value of zero (as you know, 0 is not a power of two).
> 
> I sent a diff to Jonathan to correct the behaviour which he rejected
> because he doesn't want to add local changes to change behaviour which
> isn't hitting a bug here. Fair Enough.
> 
> Then reading through old mail archives I came across this discussion
> from a few years back:
> https://marc.info/?t=14432152764=1=2
> 
> I'm wondering if it's worth documenting the peculiarities here, and
> possibly putting an actually mathematically correct check somewhere in
> the kernel or maybe userland? Perhaps hypothetical PEER REVIEWED
> functions with prototypes like isnpotu(uint64_t n) or isnpot(int64_t n).
> 
> Is this at all worthwhile? Maybe this would help stop people from
> incorrectly reinventing the wheel?
> 
> For instance in the kernel right now there is :
> radeon_check_pot_argument
> IS_POWER_OF_2
> is_power_of_2
> is_power_of_2_u64
> powerof2
> probably others too.

IS_POWER_OF_2 and is_power_of_2_u64 are inteldrm specific
is_power_of_2 is a linux interface.

radeon_check_pot_argument should be replaced in linux by
is_power_of_2.
https://lists.freedesktop.org/archives/amd-gfx/2021-December/073108.html

No code outside of drm should be using the linux interfaces and
I don't think we should be documenting them.

> 
> And manual checks like
> sys/arch/amd64/amd64/identcpu.c:804
> powerof2 = ((x - 1) & x) == 0;
> 
> -- 
> Ted Bullock 
> 
> 



Re: Device not recognized: T14s gen 2 (intel); soldered intel wifi chip isn't recognized by openbsd.

2021-07-23 Thread Jonathan Gray
On Fri, Jul 23, 2021 at 07:29:21PM +, Alex Beakes wrote:
> (this is my first time mailing a mailing list, getting into BSD, long time 
> linux user; sorry if I got anything wrong.)
> 
> Using a lenovo T14s gen2 intel, intel wifi chip isn't working, looks like the 
> device isn't being recognized.

https://psref.lenovo.com/Product/ThinkPad/ThinkPad_T14s_Gen_2_Intel?MT=20WM

Intel Wi-Fi 6 AX200, 802.11ax 2x2 Wi-Fi + Bluetooth 5.2
Intel Wi-Fi 6 AX201, 802.11ax 2x2 Wi-Fi + Bluetooth 5.2
Intel Wi-Fi 6E AX210, 802.11ax 2x2 Wi-Fi + Bluetooth 5.2

It looks like you have the AX210 option which is not yet supported.
At the moment iwx(4) only handles AX200 and AX201.

> 
> Maybe there is already a driver, but the device isn't in the pcidevice list...
> 
> Here is some data:
> 
> dmesg:
> 
> ***
> OpenBSD 6.9-current (GENERIC.MP) #139: Wed Jul 21 MDT 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16873091072 (16091MB)
> avail mem = 16345780224 (15588MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x910b1000 (63 entries)
> bios0: vendor LENOVO version "(1.07 )" date 02/22/2021
> bios0: LENOVO 20WM0052US
> acpi0 at bios0: ACPI 6.1
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT TPM2 SSDT ECDT HPET APIC MCFG 
> SSDT SSDT SSDT NHLT SSDT SSDT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM SSDT BATB 
> SSDT BGRT PTDT UEFI FPDT
> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) GLAN(S4) XHCI(S3) 
> XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
> RP04(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpihpet0 at acpi0: 1920 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 27448.30 MHz, 06-8c-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 256KB 64b/line disabled L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 38MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 2294.72 MHz, 06-8c-01
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu1: 256KB 64b/line disabled L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 2294.71 MHz, 06-8c-01
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu2: 256KB 64b/line disabled L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 2294.71 MHz, 06-8c-01
> cpu3: 
> 

Re: 6.9 + 001: uvm_fault

2021-05-27 Thread Jonathan Gray
On Thu, May 27, 2021 at 07:57:28AM +0200, Harald Dunkel wrote:
> On 5/17/21 12:27 AM, Antonino Sidoti wrote:
> > Hi,
> > 
> > I also have this issue on a fresh install of 6.9 amd64. I reported it as a 
> > bug last week to “bugs” mail list with all appropriate information. I can 
> > confirm that plugging in a monitor will allow my system to boot. I did not 
> > have the 001 patch installed.
> > 
> 
> I have sent a metoo on this list, but there was no response.

Here is the mail you were both sent:

https://marc.info/?l=openbsd-bugs=162123695228236=2

If no one tries patches and no fix is found there can be no syspatch.



Re: OpenBSD on AWS EC2 Nitro

2021-05-19 Thread Jonathan Gray
On Mon, May 17, 2021 at 12:28:39AM +0300, Ilya Voronin wrote:
> I was able to fix boot error on t3a (AMD EPYC based) instances (kernel:
> protection fault trap at lapic_set_lvt:rdmsr) with this patch (tested
> against 6.9):
> 
> Index: arch/amd64/amd64/lapic.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 lapic.c
> --- arch/amd64/amd64/lapic.c    6 Sep 2020 20:50:00 - 1.57
> +++ arch/amd64/amd64/lapic.c    16 May 2021 15:25:55 -
> @@ -300,7 +300,8 @@ lapic_set_lvt(void)
>  *   #32559 revision 3.00
>  */
>     if ((cpu_id & 0x0f00) == 0x0f00 &&
> -   (cpu_id & 0x0fff) >= 0x0004) {
> +   (cpu_id & 0x0fff) >= 0x0004 &&
> +   (cpu_id & 0x0fff) < 0x0080) {
>     uint64_t msr;
> 
>     msr = rdmsr(MSR_INT_PEN_MSG);
> 
> It seems EPYC CPUs no longer needs the workaround, which is being applied
> here.

Running virtualised it is unclear what msrs the hardware implements.

While you are testing family < 17h the 16h bkdgs have it as
RAZ/non-functional as well.  Bits are documented in 15h.

BKDG for AMD Family 16h Models 00h-0Fh Processors
MSRC001_0055 Interrupt Pending
63:0 RAZ.

BKDG for AMD Family 16h Models 30h-3Fh Processors
MSRC001_0055 Interrupt Pending
63:0 RAZ

PPR for AMD Family 17h Model 71h B0
MSRC001_0055 [Reserved.] (Core::X86::Msr::IntPend)
Read-only. Reset: Fixed,___h.

Index: sys/arch/amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.57
diff -u -p -r1.57 lapic.c
--- sys/arch/amd64/amd64/lapic.c6 Sep 2020 20:50:00 -   1.57
+++ sys/arch/amd64/amd64/lapic.c19 May 2021 09:16:37 -
@@ -299,8 +299,7 @@ lapic_set_lvt(void)
 *Family 0Fh Processors"
 *   #32559 revision 3.00
 */
-   if ((cpu_id & 0x0f00) == 0x0f00 &&
-   (cpu_id & 0x0fff) >= 0x0004) {
+   if (ci->ci_family >= 0xf && ci->ci_family < 0x16) {
uint64_t msr;
 
msr = rdmsr(MSR_INT_PEN_MSG);
Index: sys/arch/i386/i386/lapic.c
===
RCS file: /cvs/src/sys/arch/i386/i386/lapic.c,v
retrieving revision 1.47
diff -u -p -r1.47 lapic.c
--- sys/arch/i386/i386/lapic.c  30 Jul 2018 14:19:12 -  1.47
+++ sys/arch/i386/i386/lapic.c  19 May 2021 09:19:41 -
@@ -160,8 +160,7 @@ lapic_set_lvt(void)
 *Family 0Fh Processors"
 *   #32559 revision 3.00
 */
-   if ((cpu_id & 0x0f00) == 0x0f00 &&
-   (cpu_id & 0x0fff) >= 0x0004) {
+   if (ci->ci_family >= 0xf && ci->ci_family < 0x16) {
uint64_t msr;
 
msr = rdmsr(MSR_INT_PEN_MSG);



Re: 6.9 + 001: uvm_fault

2021-05-16 Thread Jonathan Gray
On Sun, May 16, 2021 at 12:10:33PM +0200, Harald Dunkel wrote:
> And another attempt, see attachment.
> 
> Seems I have to power cycle to make it boot.

There have been a few reports of this in the last few weeks.
An initial workaround patch is in
https://marc.info/?l=openbsd-bugs=162012367130138=2

If you can plug in a display does this still occur afterwards?

> 
> 
> Regards
> Harri

> OpenBSD/amd64 (redgatea.red.aixigo.de) (tty00)
> 
> login: root
> Password:
> Last login: Sun May 16 11:45:27 on ttyp0 from 2a00:fe0:30:60::7a
> OpenBSD 6.8 (GENERIC.MP) #5: Mon Feb 22 04:36:10 MST 2021
> 
> Welcome to OpenBSD: The proactively secure Unix-like operating system.
> 
> Please use the sendbug(1) utility to report bugs in the system.
> Before reporting a bug, please try to reproduce it with the latest
> version of the code.  With bug reports, please try to ensure that
> enough information to reproduce the problem is enclosed, and if a
> known fix for it exists, include that as well.
> 
> You have mail.
> redgatea# sysupgrade
> Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.9/amd64/
> SHA256.sig   100% |*|  2144   00:00   
>  
> Signature Verified
> INSTALL.amd64 100% || 43523   00:00   
>  
> base69.tgz   100% |*|   291 MB00:16   
>  
> bsd  100% |*| 20423 KB00:02   
>  
> bsd.mp   100% |*| 20515 KB00:02   
>  
> bsd.rd   100% |*|  4107 KB00:01   
>  
> comp69.tgz   100% |*| 85958 KB00:06   
>  
> game69.tgz   100% |*|  2741 KB00:00   
>  
> man69.tgz100% |*|  7560 KB00:01   
>  
> xbase69.tgz  100% |*| 29789 KB00:03   
>  
> xfont69.tgz  100% |*| 39342 KB00:04   
>  
> xserv69.tgz  100% |*| 18351 KB00:02   
>  
> xshare69.tgz 100% |*|  4502 KB00:01   
>  
> Verifying sets.
> Fetching updated firmware.
> Upgrading.
> stopping package daemons: dnsmasq zabbix_agentd.
> syncing disks... done
> carp: carp0 demoted group carp by 1 to 1 (carpdev)
> carp: carp0 demoted group external by 1 to 1 (carpdev)
> carp: carp0 demoted group externalcarp by 1 to 1 (carpdev)
> carp: carp0 demoted group egress by 1 to 1 (carpdev)
> carp: carp1 demoted group carp by 1 to 2 (carpdev)
> carp: carp1 demoted group internal by 1 to 1 (carpdev)
> carp: carp2 demoted group carp by 1 to 3 (carpdev)
> carp: carp2 demoted group yellow by 1 to 1 (carpdev)
> rebooting...
> 919 3939
> 19 99   19³¹)   391919  219993  39
> 932192921   219919219
> 21939931
> 919  91921¹þÞWÞ×Þ1BBBÂB"BBBÂBBBRBÂ>> OpenBSD/amd64 BOOT 3.52
> boot> 
> booting hd0a:/bsd.upgrade: 3818189+1590272+3878376+0+704512 
> [109+288+28]=0x989530
> entry point at 0x81001000
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2021 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 6.9 (RAMDISK_CD) #456: Mon Apr 19 10:47:37 MDT 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 8478871552 (8086MB)
> avail mem = 8217878528 (7837MB)
> random: good seed from bootblocks
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xecef0 (51 entries)
> bios0: vendor American Megatrends Inc. version "5.11" date 04/08/2016
> bios0: Default string Default string
> acpi0 at bios0: ACPI 5.0
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT CSRT
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1680.44 MHz, 06-4c-04
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> cpu0: 1MB 64b/line 16-way L2 cache
> cpu0: apic clock running at 79MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (RP01)
> acpiprt2 at acpi0: bus 2 (RP02)
> acpiprt3 at acpi0: bus 3 (RP03)
> acpiprt4 at acpi0: bus 4 (RP04)
> acpiec0 at acpi0: not present
> acpicmos0 at acpi0
> acpipci0 at acpi0 PCI0: 0x0004 0x0011 

Re: Does intel(4) support Iris Xe Graphics?

2021-04-07 Thread Jonathan Gray
On Wed, Apr 07, 2021 at 11:34:54AM +0100, Tom Smyth wrote:
> Try Current and 6.8  and see if you get a different result in each..
> dmesgs are key for getting help on this type of query ...

There is a snapshot dmesg in the bug report.  I don't see a benefit to
6.8 or linux dmesgs.



Re: Does intel(4) support Iris Xe Graphics?

2021-04-06 Thread Jonathan Gray
On Tue, Apr 06, 2021 at 11:09:07AM +0400, Michel von Behr wrote:
> Hi - (not a dev, just trying to use OpenBSD snapshot) whenever I try to
> launch Xorg, either via xenodm or startx, I'm getting a kernel panic,
> like "pool_do_get:
> drmobj : page empty" (I already sent an e-mail [1] to b...@openbsd.org with
> dmesg and all).

The pool should already be initialised via
i915_global_objects_init()
i915_globals_init()
inteldrm_attachhook()

> 
> I'm wondering if the problem could be with my video card, Intel Iris Xe?
> Even though dmesg shows that is was detected and should (?) be working. But
> I can't find a reason why my laptop would not run Xorg.
> 
> inteldrm0 at pci0 dev 2 function 0 "Intel Xe Graphics" rev 0x01
> drm0 at inteldrm0
> inteldrm0: msi, TIGERLAKE, gen 12
> 

jcs@ has/had a tiger lake machine which could run Xorg with the
linux 5.7 based drm in -current.  I'm not sure what is different here.

> 
> Any pointing to the right direction would be appreciated. (If this problem
> relates to Xorg specifically and not to OpenBSD please let me know).
> 
> [1] https://marc.info/?l=openbsd-bugs=161754767328009=2
> 
> Regards,
> 
> Michel
> 



Re: New variant of rtl8168h supported?

2021-01-23 Thread Jonathan Gray
On Sat, Jan 23, 2021 at 08:53:44AM -0600, John Batteen wrote:
> Just working in chronological order, this patch from j...@jsg.id.au was 
> sufficient to make it work.  I have not tried the subsequent patch from 
> b...@comstyle.com, though I can if you want.
> 
> re1 at pci4 dev 0 function 0 vendor "Realtek", unknown product 0x8161 rev 
> 0x15: RTL8168H/8111H (0x5400), msi, address d8:07:b6:54:d7:98
> 
> Thanks!!
> 
> John

Thanks, committed with the id added to pcidevs.



Re: New variant of rtl8168h supported?

2021-01-22 Thread Jonathan Gray
On Fri, Jan 22, 2021 at 06:58:05PM -0600, John Batteen wrote:
> Hi misc,
> 
> I just bought a TP-link TG-3468, and the chip says 8168h on it, but it is not 
> recognized by 6.8-current.  Is this chip truly unsupported or just 
> unrecognized?
> 
> Thanks,
> 
> John
> 
> The line from dmesg is:
> vendor "Realtek", unknown product 0x8161 (class network subclass ethernet, 
> rev 0x15) at pci4 dev 0 function 0 not configured

It looks like adding the new id should be enough here.

Can you try a kernel with this?

Index: sys/dev/pci/if_re_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.53
diff -u -p -r1.53 if_re_pci.c
--- sys/dev/pci/if_re_pci.c 17 Jun 2020 10:48:44 -  1.53
+++ sys/dev/pci/if_re_pci.c 23 Jan 2021 01:42:48 -
@@ -57,12 +57,15 @@ struct re_pci_softc {
bus_size_t sc_iosize;
 };
 
+#define PCI_PRODUCT_REALTEK_RT8168_2 0x8161
+
 const struct pci_matchid re_pci_devices[] = {
{ PCI_VENDOR_COREGA, PCI_PRODUCT_COREGA_CGLAPCIGT },
{ PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE528T },
{ PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE530T_C1 },
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8101E },
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8168 },
+   { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8168_2 },
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8169 },
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8169SC },
{ PCI_VENDOR_TTTECH, PCI_PRODUCT_TTTECH_MC322 },



Re: Difficulty booting UEFI from DVD

2021-01-16 Thread Jonathan Gray
On Sun, Jan 17, 2021 at 03:45:19AM +, ocelot wrote:
> Hey guys. I'm trying to install OpenBSD on a laptop, but the UEFI boot
> manager doesn't see the DVD. The laptop is a Dell with a Ryzen 4700U,
> and only has UEFI boot capability.
> 
> The ISO I'm using is the latest version, 6.8. The ISO hash matches one
> listed in the SHA256 file, and I also verified the files with a windows
> port of signify.
> 
> I burned multiple DVDs to rule out the possibility of a bad burn, and
> these DVDs weren't detected. I tried with my desktop, and they were
> not detected by the desktop's UEFI boot manager either.
> 
> Is OpenBSD able to boot in UEFI mode from DVDs?

The iso does not support booting with UEFI.
Write install68.img to a USB disk and boot from that.



Re: snapshot kernel panic related to radeondrm missing firmware

2021-01-12 Thread Jonathan Gray
On Wed, Jan 13, 2021 at 04:10:46AM +0200, Mihai Popescu wrote:
> I took the chance and installed from a recent snapshot - 12.01.2021. I got
> a kernel panic at first boot after install, related to missing firmware for
> radeondrm.
> I disabled the radeondrm then the boot process was fine and I installed
> radeondrm firmware by hand. At the next boot everything was fine again.
> 
> My question: is this known, maybe related to the recent changes in compiler
> stuff?
> The short message is panic: vfree, non vmalloced addr 0x0. My keyboard is
> not responsive, so if the info is necessary, then i need to use another
> computer to capture all on serial.
> Is it needed? Should i be patient for the next snapshot? Last good known
> snapshot kernel was 03.01.2021.

This should be resolved by future snapshots as I just reverted the
vmalloc changes for unrelated reasons.

Normally when radeondrm can't find firmware it will detach and vga or
efifb will take over the console.

Thanks for the report.



Re: Issues with Teclast F7 Plus

2020-12-25 Thread Jonathan Gray
On Fri, Dec 25, 2020 at 12:34:36AM -0500, James Hastings wrote:
> On 13 Dec 2020, 13:27:48 +, Joel Carnat wrote:
> > Hello,
> >
> > I just got a Teclast F7 Plus laptop and installed OpenBSD 6.8-current on
> > it. Most things works except apm and touchpad
> >
> > Using zzz or ZZZ, it seems suspend/hibernation start but are never
> > achieved. The backlight keyboard and power led are still on. On Linux,
> > keyboard goes black and power led slowly blinks.
> > Plus, there is no way to resume the laptop. I have to force a poweroff
> > using the power button.
> >
> > Regarding the touchpad, it doesn't work ; neither with wsmoused(8) nor
> > in Xorg. It seems to be identified and attached to pms0. Looking at a
> > Linux dmesg, it references I2C:
> > [5.462957] kernel: input: HTIX5288:00 0911:5288 Touchpad as
> > /devices/pci:00/:00:17.3/i2c_designware.7/i2c-8/i2c-HTIX5288:00/0018:0911:5288.0001/input/input11
> > So I guess OpenBSD should rather attach it to imt(4)?
> 
> 
> This diff should activate I2C touchpad on your laptop:

thanks, committed

> 
> Index: dev/pci/dwiic_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/dwiic_pci.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 dwiic_pci.c
> --- dev/pci/dwiic_pci.c   7 Oct 2020 11:17:59 -   1.14
> +++ dev/pci/dwiic_pci.c   23 Dec 2020 00:02:50 -
> @@ -117,6 +117,14 @@ const struct pci_matchid dwiic_pci_ids[]
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_6 },
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_7 },
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_8 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_1 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_2 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_3 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_4 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_5 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_6 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_7 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_8 },
>  };
>  
>  int
> 
> 



Re: Any insight on drm resetting chip for stopped heartbeat error

2020-12-06 Thread Jonathan Gray
On Sun, Dec 06, 2020 at 11:44:11AM -0800, Joseph Olatt wrote:
> Hi,
> 
> I've started seeing the following error on my laptop along with
> associated temporary freezing of the system:
> 
>   drm:pid90783:intel_gt_reset *NOTICE* Resetting chip for stopped
>   heartbeat on rcs0
>   drm:pid90783:mark_guilty *NOTICE* Xorg[83345] context reset due to GPU
>   hang
>   i915_vma_coredump_create: stub
>   i915_vma_coredump_create: stub
>   i915_vma_coredump_create: stub
>   i915_vma_coredump_create: stub
>   i915_vma_coredump_create: stub
>   i915_vma_coredump_create: stub
>   i915_vma_coredump_create: stub
>   i915_vma_coredump_create: stub
>   i915_vma_coredump_create: stub
>   pool_fini: stub
>   err_free_sgl: stub

This is inteldrm after it noticed a gpu hang.  Was there something in
particular that was running at that point?

This diff against -current should help for some haswell problems,
but perhaps not the one you are seeing.

https://patchwork.freedesktop.org/patch/395580/?series=82783=1
https://gitlab.freedesktop.org/drm/intel/-/issues/2024

Index: sys/dev/pci/drm/i915/gt/gen7_renderclear.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/gt/gen7_renderclear.c,v
retrieving revision 1.1
diff -u -p -r1.1 gen7_renderclear.c
--- sys/dev/pci/drm/i915/gt/gen7_renderclear.c  8 Jun 2020 04:48:13 -   
1.1
+++ sys/dev/pci/drm/i915/gt/gen7_renderclear.c  28 Nov 2020 02:50:26 -
@@ -7,8 +7,6 @@
 #include "i915_drv.h"
 #include "intel_gpu_commands.h"
 
-#define MAX_URB_ENTRIES 64
-#define STATE_SIZE (4 * 1024)
 #define GT3_INLINE_DATA_DELAYS 0x1E00
 #define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
 
@@ -34,8 +32,7 @@ struct batch_chunk {
 };
 
 struct batch_vals {
-   u32 max_primitives;
-   u32 max_urb_entries;
+   u32 max_primitives; /* == number of VFE threads */
u32 cmd_size;
u32 state_size;
u32 state_start;
@@ -50,18 +47,35 @@ static void
 batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
 {
if (IS_HASWELL(i915)) {
-   bv->max_primitives = 280;
-   bv->max_urb_entries = MAX_URB_ENTRIES;
+   switch (INTEL_INFO(i915)->gt) {
+   default:
+   case 1:
+   bv->max_primitives = 70;
+   break;
+   case 2:
+   bv->max_primitives = 140;
+   break;
+   case 3:
+   bv->max_primitives = 280;
+   break;
+   }
bv->surface_height = 16 * 16;
bv->surface_width = 32 * 2 * 16;
} else {
-   bv->max_primitives = 128;
-   bv->max_urb_entries = MAX_URB_ENTRIES / 2;
+   switch (INTEL_INFO(i915)->gt) {
+   default:
+   case 1: /* including vlv */
+   bv->max_primitives = 36;
+   break;
+   case 2:
+   bv->max_primitives = 128;
+   break;
+   }
bv->surface_height = 16 * 8;
bv->surface_width = 32 * 16;
}
bv->cmd_size = bv->max_primitives * 4096;
-   bv->state_size = STATE_SIZE;
+   bv->state_size = SZ_4K;
bv->state_start = bv->cmd_size;
bv->batch_size = bv->cmd_size + bv->state_size;
bv->scratch_size = bv->surface_height * bv->surface_width;
@@ -244,7 +258,6 @@ gen7_emit_vfe_state(struct batch_chunk *
u32 urb_size, u32 curbe_size,
u32 mode)
 {
-   u32 urb_entries = bv->max_urb_entries;
u32 threads = bv->max_primitives - 1;
u32 *cs = batch_alloc_items(batch, 32, 8);
 
@@ -254,7 +267,7 @@ gen7_emit_vfe_state(struct batch_chunk *
*cs++ = 0;
 
/* number of threads & urb entries for GPGPU vs Media Mode */
-   *cs++ = threads << 16 | urb_entries << 8 | mode << 2;
+   *cs++ = threads << 16 | 1 << 8 | mode << 2;
 
*cs++ = 0;
 



Re: 6.8: page fault

2020-11-04 Thread Jonathan Gray
On Wed, Nov 04, 2020 at 07:38:53AM +0100, Harald Dunkel wrote:
> Hi folks,
> 
> after applying the recent 4 syspatches for 6.8 one (of 5) openBSD
> host ran into the kernel debugger. I missed the error message, but
> on a reboot there was a page fault. On another reboot there was no
> problem any more. log is attached.
> 
> I would be glad to help, but I need some advice how to proceed
> if the page fault happens again. Every helpful comment is highly
> appreciated.

The output of "trace" and "show registers" at the ddb prompt would
be helpful.

Building a 6.8 amd64 kernel and looking at that function points to
sys/dev/pci/drm/i915/i915_vma.c:1032 so it seems something is wrong with
the vma function argument used in
struct i915_address_space *vm = vma->vm;

The vma code has changed in -current so behaviour there may be different.

> 
> Harri

> {hdunkel@dpcl082:~ 07:14:57 (local) 501} ssh -x -p 3011 
> ad...@ts02.peppercon.aixigo.de
> 
> ddb{2}> 
> ddb{2}> boot reboot
> rebooting...
> ÿü  21929
> Ùê612   312193129b2192129I
> 39   39393
> 2129219929
> 9191292131119219
>   31293933199991{kþÞ×Þ× !"BBB@ÂB""BBBÂ"BBBÂ>> 
> OpenBSD/amd64 BOOT 3.52
> boot> 
> NOTE: random seed is being reused.
> booting hd0a:/bsd: 14415144+3195912+344096+0+880640 
> [1004551+128+1138200+861220]=0x14d6ac8
> entry point at 0x81001000
> [ using 3005128 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2020 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 6.8 (GENERIC.MP) #1: Tue Nov  3 09:06:04 MST 2020
> 
> r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8478871552 (8086MB)
> avail mem = 8206848000 (7826MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xecef0 (51 entries)
> bios0: vendor American Megatrends Inc. version "5.11" date 04/08/2016
> bios0: Default string Default string
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT CSRT
> acpi0: wakeup devices BRC1(S0) XHC1(S4) HDEF(S4) RP01(S4) PXSX(S4) RP02(S4) 
> PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1680.39 MHz, 06-4c-04
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 1MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 79MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1679.95 MHz, 06-4c-04
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu1: 1MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1599.97 MHz, 06-4c-04
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu2: 1MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1599.96 MHz, 06-4c-04
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu3: 1MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (RP01)
> 

Re: OpenBSD UEFI on QEMU emulator

2020-10-22 Thread Jonathan Gray
On Thu, Oct 22, 2020 at 10:37:31PM -0400, Brad Smith wrote:
> On 10/22/2020 9:59 PM, Kevin Shell wrote:
> > Hello misc@.
> > 
> > I want to try out OpenBSD UEFI.
> > How to install OpenBSD with UEFI boot on qemu?
> The installer does prompt you during disk setup.
> > The install68.iso has no UEFI support.
> 
> This is not true.

It does not include a fat fs el torito image with efiboot only
cdbr for mbr.

> 
> > My following command on Linux can't boot OpenBSD UEFI.
> > 
> > qemu-system-x86_64 -enable-kvm \
> > -machine q35 \
> > -cpu host \
> > -smp cores=4,threads=1 \
> > -m 1G \
> > -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
> > -drive file=install68.img,format=raw
> > 
> > 
> > --
> > kevin
> > 
> 
> 



Re: AMDGPU(4) - Question about man page

2020-10-21 Thread Jonathan Gray
On Wed, Oct 21, 2020 at 11:13:59AM -0500, flint pyrite wrote:
> Question: is the amdgpu(4) manual page up to correct and up to date?
> 
> https://man.openbsd.org/amdgpu

The man page is for the xorg driver.

> 
> I set up an xorg.conf file in /etc/X11/xorg.conf and was trying to get
> AMDgpu working.
> 
> The man page uses "Device" as the section. This worked as root but not
> a normal user. When I changed "Device" to "OutputClass," X loaded
> without error as a normal user.
> 
> Also, the man page does not mention setting
> 
> machdep.allowaperture=1
> 
> in /etc/sysctl.conf

That is to permit non-kms drivers, why are you setting this?

> 
> cat /etc/X11/xorg.conf
> 
> Section "OutputClass"
> Identifier "AMDgpu"
> MatchDriver "amdgpu"
> Driver "amdgpu"
> Option "DRI" "3"
> Option "TearFree" "true"
> EndSection
> #copied from /usr/X11R6/share/X11/xorg.conf.d/10-amdgpu.conf
> 
> 
> #Section "Device"
> #   Identifier "AMDgpu"
> #   Driver "amdgpu"
> #   Option "DRI" "3"
> #   Option "TearFree" "true"
> #EndSection
> 
> Section  "Files"
> FontPath "/usr/local/share/fonts/spleen/"
> FontPath "/usr/local/share/fonts/ghostscript"
> EndSection
> 
> 6.8 GENERIC.MP#98 amd64
> 
> As a normal user, and using "Device" X fails with "No devices
> detected. If I leave out the section completely, X goes through mode
> setting and chooses Radeon.

I suspect you have hardware claimed by radeondrm and not amdgpu.
It is hard to know without seeing a dmesg and /var/log/Xorg.0.log



Re: Inphi CS4223 for 4x 10GbE SFP+

2020-10-19 Thread Jonathan Gray
On Mon, Oct 19, 2020 at 01:28:50PM +0200, Harald Dunkel wrote:
> Hi folks,
> 
> I am about to order 2 network appliances, providing an
> "Inphi CS4223 for 4x 10GbE SFP+".
> 
> Does this ring a bell? Is this already supported by 6.8? Other
> technical specs can be found on
> 
> https://www.ibase.com.tw/english/ProductDetail/NetworkAppliance/FWA8506

Atom C3000 10 GbE is known as X553.

Support was added in


revision 1.161
date: 2020/03/02 01:59:01;  author: jmatthew;  state: Exp;  lines: +134 -83;  
commitid: xmdy2UWGGO2CwfiN;
Update ix(4) from freebsd to add support for X553 controllers.

Tested on 82599 (sfp+) and X540 (baseT) by me and Hrvoje Popovski,
and on X553 by sthen@ and abieber@, and possibly more via snapshots
ok sthen@ mikeb@


And is present in 6.7 and 6.8.

> 
> BTW, congratulations to the new release
> 
> 
> Regards
> Harri
> 
> 



Re: firefox freezes X on AMD Ryzen running 6.8

2020-10-17 Thread Jonathan Gray
On Sat, Oct 17, 2020 at 09:51:49PM +0200, Marco Scholz wrote:
> I am running 6.8 #116 amd64 on a Thinkpad T495s (AMD Ryzen). Firefox
> keeps freezing X. No problem with 6.7.
> 
> Does anybody have this problem too?

There are changes coming to the memory handling in drm.
The drm_mm changes in snapshots change how memory regions are allocated
and change when the no-retry page fault situation is hit.

Another pending diff not currently in snapshots changes the ttm fault
handler.

I've asked for the drm_mm diff to be pulled from snapshots for now.

> 
> /var/log/messages:
> 
> Oct 17 12:53:24 sirius /bsd: drm:pid90646:gmc_v9_0_process_interrupt
> *ERROR* in page starting at address 0x800103b0 from client 27
> Oct 17 12:53:24 sirius /bsd: drm:pid90646:gmc_v9_0_process_interrupt
> *ERROR* VM_L2_PROTECTION_FAULT_STATUS:0x
> Oct 17 12:53:24 sirius /bsd: drm:pid90646:gmc_v9_0_process_interrupt
> *ERROR* MORE_FAULTS: 0x0
> Oct 17 12:53:24 sirius /bsd: drm:pid90646:gmc_v9_0_process_interrupt
> *ERROR* WALKER_ERROR: 0x0
> Oct 17 12:53:24 sirius /bsd: drm:pid90646:gmc_v9_0_process_interrupt
> *ERROR* PERMISSION_FAULTS: 0x0
> Oct 17 12:53:24 sirius /bsd: drm:pid90646:gmc_v9_0_process_interrupt
> *ERROR* MAPPING_ERROR: 0x0
> Oct 17 12:53:24 sirius /bsd: drm:pid90646:gmc_v9_0_process_interrupt
> *ERROR* RW: 0x0
> Oct 17 12:53:24 sirius /bsd: drm:pid90646:gmc_v9_0_process_interrupt
> *ERROR* [gfxhub0] no-retry page fault (src_id:0 ring:157 vmid:2
> pasid:32796, for process pid 0 thread
> firefox pid 99170)
> 
> 
> dmesg:
> 
> OpenBSD 6.8-current (RAMDISK_CD) #110: Fri Oct 16 12:38:28 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 6334730240 (6041MB)
> avail mem = 6138724352 (5854MB)
> random: good seed from bootblocks
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc025000 (63 entries)
> bios0: vendor LENOVO version "R13ET27W(1.01 )" date 04/18/2019
> bios0: LENOVO 20QJ000AUS
> acpi0 at bios0: ACPI 5.0
> acpi0: tables DSDT FACP SSDT SSDT SSDT MSDM SLIC BATB HPET APIC MCFG
> SBST WSMT VFCT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.38 MHz,
> 17-18-01
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
> cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully
> associative
> cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully
> associative
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 32 pa 0xfec0, version 21, 24 pins, can't
> remap
> ioapic1 at mainbus0: apid 33 pa 0xfec01000, version 21, 32 pins, can't
> remap
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (GPP0)
> acpiprt2 at acpi0: bus 1 (GPP1)
> acpiprt3 at acpi0: bus 2 (GPP2)
> acpiprt4 at acpi0: bus 3 (GPP3)
> acpiprt5 at acpi0: bus -1 (GPP4)
> acpiprt6 at acpi0: bus -1 (GPP5)
> acpiprt7 at acpi0: bus 4 (GPP6)
> acpiprt8 at acpi0: bus 5 (GP17)
> acpiprt9 at acpi0: bus -1 (GP18)
> acpiec0 at acpi0
> "PNP0C0C" at acpi0 not configured
> acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
> acpicmos0 at acpi0
> "PNP0C0A" at acpi0 not configured
> "ACPI0003" at acpi0 not configured
> "LEN0268" at acpi0 not configured
> "SMB0001" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "PNP0C0D" at acpi0 not configured
> "PNP0C0E" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x400 irq 7, 184 pins
> "USBC000" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> acpicpu at acpi0 not configured
> acpipwrres at acpi0 not configured
> acpipwrres at acpi0 not configured
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD 17h/1xh Root Complex" rev 0x00
> "AMD 17h/1xh IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured
> pchb1 at pci0 dev 1 function 0 "AMD 17h PCIE" rev 0x00
> ppb0 at pci0 dev 1 function 2 "AMD 17h/1xh PCIE" rev 0x00: msi
> pci1 at ppb0 bus 1
> iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev
> 0x78, msi

Re: how to figure out reverse package dependency?

2020-08-23 Thread Jonathan Gray
On Sun, Aug 23, 2020 at 08:15:01AM +0200, Matthias wrote:
> How do I figure out which packages directly or indirectly depend on a
> specific package? Let's assume that only installed packages shall be
> considered.
> 
> For example, if 'glib2' is the package in question, 'cairo',
> 'gdk-pixbuf', 'shared-mime-info', 'ImageMagick', etc. should be returned
> as all those depend on 'glib2'.
> 
> Thank you.

This is really a question for ports@

One way would be to install databases/sqlports then run
'show-reverse-deps devel/glib2'



Re: No xenocara for ATI Radeon HD 2400 XT

2020-08-10 Thread Jonathan Gray
On Sun, Aug 09, 2020 at 10:01:43AM -0600, Andy Bradford wrote:
> Thus said Jonathan Gray on Sun, 09 Aug 2020 12:39:36 +1000:
> 
> > When this  came up previously running  i386 resulted in being  able to
> > read the atombios. Can you confirm that is the case here?
> 
> Yes, this is the case. I installed OpenBSD 6.7 i386 to the same hardware
> and  there is  no  error in  dmesg  and X  starts  up without  requiring
> machdep.allowaperture to be set.
> 
> > The drm code in -current/snapshots has  been replaced by a new port of
> > the linux 5.7 code so behaviour there may change.
> 
> I tried  the amd64 current/snapshot  from August 8  and it has  the same
> problem.
> 
> I guess for now I can reinstall with i386 unless there is something else
> that I should try for debugging. I can provide whatever is needed.
> 
> Thanks,
> 
> Andy

I can't spot a likely cause for this.

For now we could just skip reading a disabled bios on RV610.
Both of the reports on this were for Dell machines with RV610.

Sebastien with OptiPlex 755
RV610 0x1002:0x94C3 0x1028:0x0402 0x00

and your DXP051
RV610 0x1002:0x94C1 0x1028:0x0D02 0x00

Index: src/sys/dev/pci/drm/radeon/radeon_bios.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_bios.c,v
retrieving revision 1.17
diff -u -p -r1.17 radeon_bios.c
--- src/sys/dev/pci/drm/radeon/radeon_bios.c8 Jun 2020 04:48:15 -   
1.17
+++ src/sys/dev/pci/drm/radeon/radeon_bios.c10 Aug 2020 13:41:43 -
@@ -524,6 +524,9 @@ static bool r600_read_disabled_bios(stru
uint32_t lower_gpio_enable;
bool r;
 
+   if (rdev->family == CHIP_RV610)
+   return false;
+
viph_control = RREG32(RADEON_VIPH_CONTROL);
bus_cntl = RREG32(R600_BUS_CNTL);
d1vga_control = RREG32(AVIVO_D1VGA_CONTROL);



Re: No xenocara for ATI Radeon HD 2400 XT

2020-08-08 Thread Jonathan Gray
On Sat, Aug 08, 2020 at 10:23:13AM -0600, Andy Bradford wrote:
> Hello,
> 
> I put OpenBSD 6.7 on an older PC that used to run OpenBSD 6.3 and X just
> fine. xenodm refuses to start. Is there  something I can do to make this
> work (edit  sources in xenocara  or kernel  and recompile), or  should I
> just email bugs@?
> 
> The following is found in dmesg:
> 
> initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02 0x00).
> drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> [TTM] Memory type 2 has not been initialized

When this came up previously running i386 resulted in being able to read
the atombios.  Can you confirm that is the case here?

The drm code in -current/snapshots has been replaced by a new port of
the linux 5.7 code so behaviour there may change.

> drm0 detached
> radeondrm0 detached
> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation), using wskbd0
> wskbd1: connecting to wsdisplay0
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> 
> # fw_update -i
> Installed: radeondrm-firmware-20181218 intel-firmware-20200508v0
> 
> What follows are full dmesg, xenodm.log and Xorg.0.log:
> 
> OpenBSD 6.7 (GENERIC.MP) #5: Tue Jul 21 13:50:07 MDT 2020
> 
> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3739795456 (3566MB)
> avail mem = 3613900800 (3446MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0450 (65 entries)
> bios0: vendor Dell Inc. version "A04" date 04/19/2006
> bios0: Dell Inc. Dell DXP051
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET
> acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5) 
> PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Pentium(R) D CPU 3.00GHz, 2993.07 MHz, 0f-06-04
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF,MELTDOWN
> cpu0: 2MB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 199MHz
> cpu0: mwait min=64, max=64
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Pentium(R) D CPU 3.00GHz, 2992.61 MHz, 0f-06-04
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF,MELTDOWN
> cpu1: 2MB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-63
> acpimcfg0: addr 0x0, bus 0-0
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 5 (PCI4)
> acpiprt2 at acpi0: bus 2 (PCI2)
> acpiprt3 at acpi0: bus -1 (PCI3)
> acpiprt4 at acpi0: bus 1 (PCI1)
> acpiprt5 at acpi0: bus 3 (PCI5)
> acpiprt6 at acpi0: bus 4 (PCI6)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpibtn0 at acpi0: VBTN
> acpipci0 at acpi0 PCI0: _OSC failed
> acpicmos0 at acpi0
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x00
> ppb0 at pci0 dev 1 function 0 "Intel 82945G PCIE" rev 0x00: msi
> pci1 at ppb0 bus 1
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00
> drm0 at radeondrm0
> radeondrm0: msi
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
> azalia0: codecs: Sigmatel STAC9220/1
> audio0 at azalia0
> ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: msi
> pci3 at ppb2 bus 3
> ppb3 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: msi
> pci4 at ppb3 bus 4
> em0 at pci4 dev 0 function 0 "Intel 82573L" rev 0x01: msi, address 
> 00:13:72:1a:ed:5c
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 8 int 21
> uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 8 int 22
> uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 8 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 8 int 23
> ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 8 int 21
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
> addr 1
> ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
> pci5 at ppb4 bus 5
> "AT/Lucent FW322 1394" rev 0x61 at pci5 dev 5 

Re: amdgpu: AMD 5700XT (NAVI10) misreported and non-working

2020-08-05 Thread Jonathan Gray
On Sun, Jul 19, 2020 at 04:36:37PM +1000, Jonathan Gray wrote:
> On Sun, Jul 19, 2020 at 01:13:51AM -0400, jcm...@gmail.com wrote:
> > I saw that much of the amdgpu related drm code had been updated against
> > linux 5.7 and decided to try it out using a recent snapshot.  While the
> > amdgpu module loads and is able to mirror to both of my displays when in
> > a tty, attempting to use startx or starting xenodm results in both
> > displays showing a blank black screen.  When this occurs I am unable to
> > switch to another tty though I am able to SSH into the system and poke
> > around.
> 
> Userland support for navi10/gfx1010 requires at least llvm 9.
> Currently llvm 8 is in the tree.  We stopped updating when the license
> changed for the worse.  With llvm versions being tied to amd hardware
> support and newer c++ standards, not updating is becoming increasingly
> painful as time goes by so this may have to change in the near future.

Snapshots now have llvm 10 so navi10 acceleration should work with the
version of Mesa already in xenocara.



Re: amdgpu: AMD 5700XT (NAVI10) misreported and non-working

2020-07-19 Thread Jonathan Gray
On Sun, Jul 19, 2020 at 01:13:51AM -0400, jcm...@gmail.com wrote:
> I saw that much of the amdgpu related drm code had been updated against
> linux 5.7 and decided to try it out using a recent snapshot.  While the
> amdgpu module loads and is able to mirror to both of my displays when in
> a tty, attempting to use startx or starting xenodm results in both
> displays showing a blank black screen.  When this occurs I am unable to
> switch to another tty though I am able to SSH into the system and poke
> around.

Userland support for navi10/gfx1010 requires at least llvm 9.
Currently llvm 8 is in the tree.  We stopped updating when the license
changed for the worse.  With llvm versions being tied to amd hardware
support and newer c++ standards, not updating is becoming increasingly
painful as time goes by so this may have to change in the near future.

I would expect the modesetting driver to be able to run even if amdgpu
with acceleration does not.  I'm not sure why it does not fallback.

> 
> 
> /etc/sysctl.conf
> 
> > machdep.allowaperture=1
> 
> 
> dmesg
> 
> > OpenBSD 6.7-current (GENERIC.MP) #358: Sat Jul 18 11:25:13 MDT 2020
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 17111711744 (16319MB)
> > avail mem = 16578068480 (15810MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xdcecf000 (59 entries)
> > bios0: vendor American Megatrends Inc. version "1.C0" date 09/06/2019
> > bios0: Micro-Star International Co., Ltd. MS-7B79
> > acpi0 at bios0: ACPI 6.0
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT MCFG HPET SSDT UEFI 
> > VFCT IVRS SSDT CRAT CDIT BGRT SSDT SSDT WSMT
> > acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) 
> > GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) 
> > GPPF(S4) GP17(S4) [...]
> > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: AMD Ryzen 5 2600 Six-Core Processor, 3400.52 MHz, 17-08-02
> > cpu0: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> > 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
> > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 99MHz
> > cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: AMD Ryzen 5 2600 Six-Core Processor, 3400.00 MHz, 17-08-02
> > cpu1: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> > 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
> > cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu1: disabling user TSC (skew=102)
> > cpu1: smt 0, core 1, package 0
> > cpu2 at mainbus0: apid 4 (application processor)
> > cpu2: AMD Ryzen 5 2600 Six-Core Processor, 3400.00 MHz, 17-08-02
> > cpu2: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> > 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
> > cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu2: smt 0, core 2, package 0
> > cpu3 

Re: no u-boot serial output on raspberry pi 3

2020-07-05 Thread Jonathan Gray
On Sun, Jul 05, 2020 at 09:18:55PM +0100, testing999...@zohomail.eu wrote:
> i can't get any u-boot serial output from miniroot67.fs on a raspberry
> pi 3.  i'm using a 'FTDI232' which cost ~$4 - USB to 3.3V jumper
> cables, connecting TX to RX and vice versa on GPIO header.
> 
> my serial console setup works without issue with a pi 1 and a pi 3,
> running raspbian, with:
> $ screen /dev/ttyUSB0 115200
> i had to add 'enable_uart=1' to /boot/config.txt before with console
> became accessible, on the pi 3.
> 
> i tried mounting the partitions after dd'ing miniroot67.fs and
> looking for some text files to edit, but there were only binaries
> 
> any ideas? i can only think of trying older miniroots or snapshots
> next. thanks

The arm64 miniroot contains a fat filesystem with raspberry pi firmware,
config.txt and rpi_3 u-boot. The config.txt already has serial enabled
(with pl011 uart):

arm_64bit=1
enable_uart=1
dtoverlay=disable-bt
kernel=u-boot.bin

You can force the firmware stage which runs before u-boot to output on
serial by modifying bootcode.bin as described at the end of
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/README.md

If you try miniroot67.img from a snapshot you'll get a more recent
version of u-boot.  May be worth trying.



Re: AMDGPU

2020-07-01 Thread Jonathan Gray
On Mon, Jun 29, 2020 at 11:59:28PM -0500, Charlie Burnett wrote:
> For sure, whatever helps!
> Jun 27 18:58:21 tabr /bsd: [drm] *ERROR* sdma_v4_0: Failed to load firmware
> "amdgpu/vega20_sdma.bin"
> Jun 27 18:58:21 tabr /bsd: [drm] *ERROR* Failed to load sdma firmware!
> Jun 27 18:58:21 tabr /bsd: drm:pid0:psp_v11_0_init_microcode *ERROR* psp
> v11.0: Failed to load firmware "amdgpu/vega20_sos.bin"
> Jun 27 18:58:21 tabr /bsd: [drm] *ERROR* Failed to load psp firmware!
> Jun 27 18:58:21 tabr /bsd: [drm] *ERROR* sw_init of IP block  failed -2
> Jun 27 18:58:21 tabr /bsd: drm:pid0:amdgpu_device_init *ERROR*
> amdgpu_device_ip_init failed
> Jun 27 18:58:21 tabr /bsd: drm:pid0:amdgpu_attachhook *ERROR* Fatal error
> during GPU init
> That's with the old firmware, and yeah that's with the newest firmware. I
> had to use newer firmware on your newdrm branch as well. Let me know how I
> can help! :)

Thanks, I've updated the port to 20200619 after checking vega10 and
picasso.  It will later be available via fw_update(1).



Re: AMDGPU

2020-06-29 Thread Jonathan Gray
On Mon, Jun 29, 2020 at 11:13:49PM -0500, Charlie Burnett wrote:
> Hi,
> 
> Wasn’t sure who to tell this to, but with Vega 20 hardware under -current,
> there is an issue with the firmware, where it cannot load. Manually
> installing the latest amdgpu firmware from kernel.org fixes this seemingly.

can you show the output when the 20200421 firmware failed to load?
you are referring to the following in linux-firmware 20200619 and later?

commit f73f82cd4b7506a22a9aa1aa19e009fac3092eef
Author: Alex Deucher 
Date:   Mon Jun 15 17:33:26 2020 -0400

amdgpu: add vega20 TA firmware from 20.20 release

Based on internal commit:
c6aa2bdaa30af815fc257f2b0e50f6c66d74045c

Signed-off-by: Alex Deucher 
Signed-off-by: Josh Boyer 

 amdgpu/vega20_ta.bin | Bin 0 -> 54016 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

commit 9ecaba882d78501d2ab2f6bd9407409128b351ed
Author: Alex Deucher 
Date:   Mon Jun 15 17:30:20 2020 -0400

amdgpu: update vega20 firmware from 20.20 release

Based on internal commit:
c6aa2bdaa30af815fc257f2b0e50f6c66d74045c

Signed-off-by: Alex Deucher 
Signed-off-by: Josh Boyer 

 amdgpu/vega20_asd.bin   | Bin 147968 -> 160256 bytes
 amdgpu/vega20_ce.bin| Bin 9344 -> 9344 bytes
 amdgpu/vega20_me.bin| Bin 17536 -> 17536 bytes
 amdgpu/vega20_mec.bin   | Bin 268048 -> 268048 bytes
 amdgpu/vega20_mec2.bin  | Bin 268048 -> 268048 bytes
 amdgpu/vega20_pfp.bin   | Bin 21632 -> 21632 bytes
 amdgpu/vega20_sdma.bin  | Bin 17408 -> 17408 bytes
 amdgpu/vega20_sdma1.bin | Bin 17408 -> 17408 bytes
 amdgpu/vega20_smc.bin   | Bin 262912 -> 262912 bytes
 amdgpu/vega20_sos.bin   | Bin 170896 -> 174992 bytes
 10 files changed, 0 insertions(+), 0 deletions(-)

> There's also an issue that I've been unable to figure out for a while here
> as well, in that undergoing a CPU intensive task will freeze up the entire
> system. Disabling all power management options and setting the
> amdgpu_vm_update_mode to 3 lessens the occurrence of this, and using an
> HDMI connection instead of a DisplayPort with said modifications seemingly
> eliminates it. Just switching amdgpu_vm_update_mode to 3 without anything
> else leads to issues, in which when launching X in which only a small
> square of seemingly random pixels are displayed. Using a vanilla kernel,
> only "Waiting for fences timed out!" appears. However, turning on
> amdgpu_debug_vm in amdgpu_drv.c will output quite a few DRM errors for
> "gmc_v9_0_process_interrupt", sometimes in the tens of thousands. Any hang
> ups require a hard reboot. With amdgpu_vm_update_mode set to 3, the crash
> occurs differently in that whichever windows are using a bunch of GPU/CPU
> time turn a lime green color. They're completely functional at first,
> however if I keep putting heavy loads on both the screen becomes pixelated
> on any changed pixels for those windows. I have a huge amount of logs for
> these, however from a couple weeks of trying to fix it myself they didn't
> offer much beyond what was stated in this email.

this is similar to what is seen on vega10 and other parts



Re: [drm] *ERROR* [CRTC:41:pipe ] flip_done timed out

2020-03-08 Thread Jonathan Gray
On Sat, Mar 07, 2020 at 08:50:44PM -0400, Jon Whalen wrote:
> Hi there,
> 
> I also receive these errors as well as hangs on an old Dell Inspiron
> 1525 with OpenBSD, several releases of Ubuntu Linux, and NetBSD 9.0.
> My unqualified assumption is that it's an Intel i915 driver issue and
> not an actual OpenBSD issue. I don't know anything about computer
> programming, but given the errors, I wonder if it could be narrowed
> down to the drm_irq.c, drm_vblank.c, and/or intel_fifo_underrun.c
> files in the Intel driver? There are differences between the current
> Linux and OpenBSD source trees, but I lack the skills, expertise, and
> brain power to begin troubleshooting this. The main differences appear
> to have something to do with spinlocks and mutexes, but again, this is
> beyond my abilities.
> 
> OpenBSD became affected after 6.6 development began (6.5 is not
> affected). Probably irrelevant, but not all Linux distributions are
> affected; Kubuntu and Alpine are not, and neither is the latest Ubuntu
> 20.04 development release.
> 
> NetBSD 9.0 repeated the following errors upon boot and is what led me
> to my assumption above:
> [4.6926206] warning:
> /usr/src/sys/external/bsd/drm2/dist/drm/drm_irq.c:1510 vblank wait
> timed out on crtc 0
> [4.7526574] kern error:
> [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:363)intel_cpu_fifo_underrun_irq_handler]
> *ERROR* CPU pipe A FIFO underrun
> 
> Booting OpenBSD with inteldrm enabled, there is a delay of
> approximately 30 seconds when inteldrm is "probed" after root is
> mounted, which is also when the [drm] errors begin to appear. The boot
> process continues normally after the hang.
> 
> If xenodm is configured to start it takes about 60 seconds for it to
> load and become usable.
> 
> After entering credentials into xenodm, cwm takes approximately 30
> seconds to become usable and xconsole starts repeating the same [drm]
> errors. Things seem to work fine after this, though the errors
> continue to litter /var/log/messages.
> 
> Resuming from a suspend, the system hangs for ~30s.
> 
> None of this occurs if inteldrm is disabled.
> 
> On Linux, adding the following line to the grub conf eliminated the
> errors and hangs:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="video=SVIDEO-1:d"
> 
> Is it possible to pass similar Linux grub parameters to boot on
> OpenBSD via boot.conf? If there is a way, could this be the "easiest"
> solution?
> 
> Sendbug text below, with -current as of March 7, 2020.
> 
> This message refers to:
> https://marc.info/?t=15807519011=1=2

https://bugs.freedesktop.org/show_bug.cgi?id=93782

This appears to have been fixed in linux 5.1 in commit
32db0b6501d97b09e92e70caefc74fa35aa9a8d6 which was marked as being for
stable but did not appear in the stable branches likely due it it not
applying cleanly (ed20151a7699bb2c77eba3610199789a126940c4 did land in
the 4.19 branch so we already have that).

Here is a backport of 32db0b6501d97b09e92e70caefc74fa35aa9a8d6 to our
4.19 tree.

drm/i915: Don't try to use the hardware frame counter with i965gm TV output

Index: sys/dev/pci/drm/i915/i915_irq.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_irq.c,v
retrieving revision 1.33
diff -u -p -r1.33 i915_irq.c
--- sys/dev/pci/drm/i915/i915_irq.c 14 Apr 2019 10:14:51 -  1.33
+++ sys/dev/pci/drm/i915/i915_irq.c 8 Mar 2020 12:46:04 -
@@ -822,11 +822,26 @@ static void i915_enable_asle_pipestat(st
 static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   const struct drm_display_mode *mode = >hwmode;
i915_reg_t high_frame, low_frame;
u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
-   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
unsigned long irqflags;
 
+   /*
+* On i965gm TV output the frame counter only works up to
+* the point when we enable the TV encoder. After that the
+* frame counter ceases to work and reads zero. We need a
+* vblank wait before enabling the TV encoder and so we
+* have to enable vblank interrupts while the frame counter
+* is still in a working state. However the core vblank code
+* does not like us returning non-zero frame counter values
+* when we've told it that we don't have a working frame
+* counter. Thus we must stop non-zero values leaking out.
+*/
+   if (!vblank->max_vblank_count)
+   return 0;
+
htotal = mode->crtc_htotal;
hsync_start = mode->crtc_hsync_start;
vbl_start = mode->crtc_vblank_start;
@@ -4803,16 +4818,10 @@ void intel_irq_init(struct drm_i915_priv
if (INTEL_GEN(dev_priv) >= 8)
rps->pm_intrmsk_mbz |= GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
 
-   if 

Re: Brand new server - bad adventures

2020-01-22 Thread Jonathan Gray
On Wed, Jan 22, 2020 at 11:30:51PM +0300, Özgür Kazancci wrote:
> Hello everyone! Greetings to misc people!
> 
> Got a brand new dedicated server with a hardware: Intel Xeon-E 2274G - 64GB
> DDR4 ECC 2666MHz - 2x SSD NVMe 960GB
> and installed "brand new" OpenBSD 6.6 on it. (I'm managing it remotely via
> KVM/IPMI)
> 
> After the first boot, dmesg is outputting sequentally between few seconds
> delays:
> "wsdisplay0 at inteldrm0 mux 1
> init: can't open /dev/console: Device not configured" and the system doesn't
> boot at all.
> 
> Please refer to the screenshot attached: https://ibb.co/sQbt7F7
> 
> And after few hours of forums/IRC-logs readings, I tried to try the
> suggestion of lots of similar-people: "disable inteldrm"
> 
> To do that, during the boot I typed "boot -c", then got a brand new error
> (IPMI/KVM freezes, no more keyboard input):
> "kbc: cmd word write error" (with a weird cursor)
> Please refer to the screenshot attached: https://ibb.co/QchqhtY
> 
> Anyways, wanted to skip that -for now-, rebooted the server again, and
> booted into bsd.rd, mounted the / and /usr on the harddisk, chrooted into
> there and did;
> "config -ef /bsd", then "disable inteldrm" and "quit" to save the changes.
> Finally rebooted.
> 
> The system booted up fine! Got the login prompt shell, logged in, well, with
> -an another- brand new error :)
> 
> "reorder_kernel: failed - see /usr/...GENERIC.MP/relink.log"
> 
> I guess that was because I modified the kernel, anyway, wanted to skip that
> too -for now-. Did what I always do the first: syspatch
> 
> installed the patches, rebooted the system, aand...Tada! "inteldrm0 is back,
> b1tch3z!" :)
> 
> Dmesg has again: "init: can't open /dev/console: Device not configured" and
> delays there. No boot, again.
> 
> My questions are:
> 
> How can I get the rid of the error "init: can't open /dev/console: Device
> not configured" to be able to boot into the system?
> 
> if that was the only way (disabling inteldrm), would I repeat it each time I
> issue syspatch?

It would be helpful if you would include a full dmesg.

1024x768 is the default mode when there are no connected outputs.

You should see
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0

The way inteldrm claims the console changes depending on whether or not
you are booting via efi.



Re: sysupgrade woes on beaglebone black

2020-01-10 Thread Jonathan Gray
On Fri, Jan 10, 2020 at 10:06:41AM +0100, Jan Stary wrote:
> On Jan 09 11:44:25, h...@stare.cz wrote:
> > Installing bsd  100% |**|  6248 KB00:05 ETA
> > Installing bsd.rd   100% |**| 11229 KB00:10 ETA
> > Installing base66.tgz   100% |**| 99116 MB  - 
> > 07:12edT-
> > Installing comp66.tgz83% |* | 45312 KB  - 
> > stalledT-syncing disks... done
> > rebooting...
> 
> On Jan 09 14:48:25, dera...@openbsd.org wrote:
> > > https://marc.info/?l=openbsd-cvs=156889553923923=2
> > > Looking at install.sub, it seems that the watchdog timer (30 min)
> > > is reset after installing every set. I don't see the watchdog being
> > > reset whenever there is "progress" - did you mean the completion
> > > of a set (as opposed to just not being -stalled-)?
> > > 
> > > Also, the resets only happen with $UU, which is only set with -x
> > > - where should that option be passed? (not in sysupgrade.)
> > > 
> > > Grandpa's analog stopwatch on a chain says
> > > that it indeed reboot around the 30 min mark.
> > 
> > This entire design is intentional.
> > 
> > If a machine gets stuck doing an upgrade, we want it to abandon the
> > upgrade and go back to the /bsd kernel (which hopefully has not been
> > installed yet).
> 
> Well, /bsd is the first thing that gest installed,
> and is relatively small compared to the other sets.
> In this particular machine, the watchdog timeout hits when
> bsd, bsd.rd, base, and half of comp have been installed.
> 
> > Your machine is too slow.
> 
> It seems it's the SD card that is slow (the machine
> is a BeagleBone Black) - will try with a faster one.

Support for using edma with ommmc(4) is lacking, that would help.

> 
> It seems I am missing out on
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141=1.1142=h
> - I can't figure out how to pass the -x option that sets $UU
> (and thus makes the timer reset before each set is installed).
> 
> Thank you for the insight.
> 
> 



Re: netsurf-fb fails on framebuffer console

2019-12-25 Thread Jonathan Gray
On Wed, Dec 25, 2019 at 04:20:04PM +0530, putridsou...@gmail.com wrote:
> The port maintainer has confirmed both sdl and x interface 
> for netsurf-fb require X.
> Is it possible to modify sdl source code to work with openbsd 
> framebuffer driver? In my case it's inteldrm driver.

There is old code in sdl that does wsdisplay ioctls but it doesn't
handle the inteldrm display type.

The kernel side would need at least this diff and likely more:

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c,v
retrieving revision 1.8
diff -u -p -r1.8 amdgpu_kms.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 25 Dec 2019 11:42:05 -  
1.8
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 25 Dec 2019 11:49:50 -
@@ -1648,6 +1648,9 @@ amdgpu_wsioctl(void *v, u_long cmd, cadd
wdf->depth = ri->ri_depth;
wdf->cmsize = 0;
return 0;
+   case WSDISPLAYIO_LINEBYTES:
+   *(u_int *)data = ri->ri_stride;
+   return 0;
case WSDISPLAYIO_GETPARAM:
if (bd == NULL)
return -1;
Index: sys/dev/pci/drm/i915/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.126
diff -u -p -r1.126 i915_drv.c
--- sys/dev/pci/drm/i915/i915_drv.c 25 Dec 2019 11:42:05 -  1.126
+++ sys/dev/pci/drm/i915/i915_drv.c 25 Dec 2019 11:49:51 -
@@ -3225,6 +3225,9 @@ inteldrm_wsioctl(void *v, u_long cmd, ca
wdf->depth = ri->ri_depth;
wdf->cmsize = 0;
return 0;
+   case WSDISPLAYIO_LINEBYTES:
+   *(u_int *)data = ri->ri_stride;
+   return 0;
case WSDISPLAYIO_GETPARAM:
if (ws_get_param && ws_get_param(dp) == 0)
return 0;
Index: sys/dev/pci/drm/radeon/radeon_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
retrieving revision 1.63
diff -u -p -r1.63 radeon_kms.c
--- sys/dev/pci/drm/radeon/radeon_kms.c 25 Dec 2019 11:42:05 -  1.63
+++ sys/dev/pci/drm/radeon/radeon_kms.c 25 Dec 2019 11:49:51 -
@@ -231,6 +231,9 @@ radeondrm_wsioctl(void *v, u_long cmd, c
wdf->depth = ri->ri_depth;
wdf->cmsize = 0;
return 0;
+   case WSDISPLAYIO_LINEBYTES:
+   *(u_int *)data = ri->ri_stride;
+   return 0;
default:
return -1;
}



Re: netsurf-fb fails on framebuffer console

2019-12-25 Thread Jonathan Gray
On Wed, Dec 25, 2019 at 01:57:01PM +0530, putridsou...@gmail.com wrote:
> I'm running openbsd 6.6-current Dec24 snapshot 
> 
> The browser works perfectly within X.
> But fails without it.
> Following output is given by command:netsurf-fb -v
> 
> (0.00) utils/log.c:264 nserror nslog_init(nslog_ensure_t *, int *, char 
> **): NetSurf version '3.9 (17th July 2019)'
> (0.59) utils/log.c:275 nserror nslog_init(nslog_ensure_t *, int *, char 
> **): NetSurf on , node , release <6.6>, 
> version , machine 
> (0.000144) utils/messages.c:140 nserror messages_add_from_file(const char *): 
> Loading Messages from '/usr/local/share/netsurf-fb/Messages'
> (0.002182) content/handlers/image/image_cache.c:432 nserror 
> image_cache_init(const struct image_cache_parameters *): Image cache 
> initialised with a limit of 3145728 hysteresis of 629145
> (0.002204) content/handlers/html/html_css_fetcher.c:70 _Bool 
> html_css_fetcher_initialise(lwc_string *): html_css_fetcher_initialise called 
> for x-ns-css
> (0.002310) content/fetchers/curl.c:1493 nserror fetch_curl_register(void): 
> curl_version libcurl/7.67.0 LibreSSL/3.0.2 zlib/1.2.3 nghttp2/1.40.0
> (0.004905) utils/useragent.c:69 void user_agent_build_string(void): Built 
> user agent "NetSurf/3.9 (OpenBSD)"
> (0.004914) content/fetchers/curl.c:1584 nserror fetch_curl_register(void): 
> cURL linked against openssl
> (0.004931) content/fetchers/curl.c:177 _Bool fetch_curl_initialise(lwc_string 
> *): Initialise cURL fetcher for http
> (0.004936) content/fetchers/curl.c:177 _Bool fetch_curl_initialise(lwc_string 
> *): Initialise cURL fetcher for https
> (0.004943) content/fetchers/data.c:61 _Bool fetch_data_initialise(lwc_string 
> *): fetch_data_initialise called for data
> (0.004983) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for adblock.css
> (0.005008) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for default.css
> (0.005027) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for internal.css
> (0.005043) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for quirks.css
> (0.005077) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for credits.html
> (0.005097) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for licence.html
> (0.005122) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for welcome.html
> (0.005139) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for maps.html
> (0.005191) content/fetchers/resource.c:288 _Bool 
> fetch_resource_initialise(lwc_string *): redirect url for netsurf.png
> (0.005279) content/llcache.c:3510 nserror llcache_initialise(const struct 
> llcache_parameters *): llcache initialising with a limit of 9437184 bytes
> (0.005302) frontends/framebuffer/gui.c:469 _Bool process_cmdline(int, char 
> **): argc 1, argv 0x7f7f7488
> WSCONS error: ioctl WSDISPLAYIO_LINEBYTES: Inappropriate ioctl for device
> Unable to init SDL: ioctl WSDISPLAYIO_LINEBYTES: Inappropriate ioctl for 
> device
> (0.008676) frontends/framebuffer/framebuffer.c:609 nsfb_t 
> *framebuffer_initialise(const char *, int, int, int): Unable to initialise 
> nsfb surface
> 
> Unable to initialise framebuffer
> 
> 

wsdisplay ioctls depend on the hardware you have, you need to include a
dmesg.

drm drivers do not implement WSDISPLAYIO_LINEBYTES but could do so
easily enough with ri->ri_stride from the first fb.

Whoever last touched the wscons code in libsdl 1.x only seems to have
cared about sparc and zaurus framebuffers.  The code does not handle
other display types.  And there are multiple fb encoding formats for
each drm framebuffer so deciding that based on the display type is
going to be wrong in at least some cases.



Re: xenocara xcursor issues?

2019-09-29 Thread Jonathan Gray
On Sun, Sep 29, 2019 at 06:42:08PM -0700, Travis Cole wrote:
> I've been banging my head on this one long enough that I figured I'd just ask 
> the list if anyone else is seeing this behavior.
> 
> I'm getting really inconsistent xcursor behavior.
> 
> I've tried setting a few xcursor themes, and they seem to only take 
> inconsistently. 
> On certain areas of applications they inconsistently default back to the X 
> cursor 
> (XC_X_cursor) and the xcursor often doesn't change how it's supposed to.
> 
> But this does seem to be triggered when crossing areas where the cursor is
> supposed to change.
> 
> I spent a bunch of time hacking on dwm/st to see if the issue was there.
> But finally just ran my same dwm/st config on an Arch Linux laptop I have
> and the xcursors behave just fine there.
> 
> I also tried as a new user to rule out any dotfiles issues. The problem 
> persists.
> 
> Finally, I installed gnome/gdm from ports, and same issue. Gnome sets
> it's default xcursor theme, which works sometimes. But I also get it flipping
> back to the X shaped xcursor and sometimes the xcursor will stick at the wrong
> one, like stay at the window resize xcursor after resizing a window.
> 
> It seems like maybe some xcursor change events are getting missed
> and or defaulting back to XC_X_cursor. 
> 
> For reference, this is on  the latest -CURRENT snapshot. On a Lenovo 
> Thinkpad X395, which incidentally also has X crash on wake from sleep when 
> trying to 
> enable the graphics adapter.

suspend/resume currently does not work on amdgpu.

There is a problem with hardware cursor state on amdgpu.  As a workaround
try creating an /etc/X11/xorg.conf with:

Section "Device"
Identifier "amdgpu"
Option "SWcursor" "True"
EndSection



Re: arm on Tinker Board (rk3288) - currently broken?

2019-09-27 Thread Jonathan Gray
On Fri, Sep 27, 2019 at 08:01:53PM -0400, Joe Gidi wrote:
> Hello,
> 
> I've seen a number of recent commits for the rk3288 SoC, so I dug out my
> Tinker Board and tried to install the latest snapshot (miniroot dated
> 27-Sep-2019 06:14).
> 
> I followed the updated directions for this chip:
> 
>   For systems based on Rockchip RK3288 SoCs:
> 
>   dd if=/usr/local/share/u-boot/board/idbloader.img \
>   of=/dev/sdXc seek=64
>   dd if=/usr/local/share/u-boot/board/u-boot.img \
>   of=/dev/sdXc seek=16384
> 
> Unfortunately, when I try to boot, I get:
> 
> rying to boot from BOOTROM
> Returning to boot ROM...
> 
> U-Boot SPL 2019.07 (Sep 25 2019 - 20:12:08 -0600)
> Trying to boot from MMC1
> spl: mmc init failed with error: -110
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> 
> Is this currently known to be broken, or am I doing something wrong?

tinker-rk3288 was broken in U-Boot 2019.07.  I have just committed an
update to U-Boot 2019.10-rc4 which corrects this.  Either build
u-boot-arm from ports or wait till updated packages appear.



Re: trouble with radeon r9 290 and eduke32

2019-09-21 Thread Jonathan Gray
On Sat, Sep 21, 2019 at 02:37:21PM +0200, Solene Rapenne wrote:
> On Sat, Sep 21, 2019 at 09:34:35PM +1000, Jonathan Gray wrote:
> > On Sat, Sep 21, 2019 at 12:29:59PM +0200, Solene Rapenne wrote:
> > > On Tue, Aug 20, 2019 at 05:40:50PM +1000, Jonathan Gray wrote:
> > > > On Tue, Aug 20, 2019 at 09:43:48AM +0300,  wrote:
> > > > > Hello,
> > > > > When I start eduke32 with LD_PRELOAD=/usr/X11R6/lib/libGL.so.17.0  so 
> > > > > it
> > > > > can run in opengl,
> > > > > on ion fury it freezes after starting the game and whole machine 
> > > > > becomes
> > > > > unresponsive for some time. I can ssh to it from my cell phone after 
> > > > > some
> > > > > time. Here is screenshot of dmesg:
> > > > > 
> > > > > https://yadi.sk/i/C6NSFEqjxuchoA
> > > > > 
> > > > > Here is dmesg after reboot: https://pastebin.com/HiHp8DUQ
> > > > > 
> > > > > Help. please.
> > > > > Thanks.
> > > > 
> > > > Why are you using LD_PRELOAD?  OpenGL should work without that.
> > > > eduke32 will dlopen libGL.so after libGL.so.1 can't be opened going by
> > > > source/glad/src/glad.c.
> > > > 
> > > > Are you using the version of eduke32 in ports?  It is quite old and
> > > > ion fury had the initial release a few days ago.
> > > > 
> > > > Can you reproduce this with any other game supported by eduke32?
> > > > I don't have ion fury but have the rest (and duke3d shareware
> > > > is installed when installing the eduke32 package).
> > > > 
> > > > Here is an update to the latest eduke32 which has some graphical
> > > > glitches on the title screen with duke3d shareware with inteldrm.
> > > > Not sure if the xmp bits are properly built for the tracker music
> > > > in ion fury.
> > > > 
> > > 
> > > With your patch I can play Ion Fury, sounds works but there is no music.
> > > 
> > >   Generating voxel models for Polymost. This may take a while...
> > >   Initializing music...
> > >   Initializing sound... 64 voices, 2 channels, 16-bit 48000 Hz
> > >   MV_PlayXMP: libxmp-lite support not included in this binary.
> > >   MV_PlayXMP: libxmp-lite support not included in this binary.
> > >   Line 1637, starttrackslot: invalid level 25 or null music for volume 0 
> > > level 25
> > >   Cache time: 939ms
> > > 
> > > The duke nukem shareware works too, I did not see any glitch.
> > > My graphic card from dmesg:
> > > 
> > > "Intel UHD Graphics 620" rev 0x07 at pci0 dev 2 function 0 not configured
> > > inteldrm0 at pci0 dev 2 function 0 "Intel UHD Graphics 620" rev 0x07
> > > 
> > > I don't know if this is expected, but I was only able to play Ion Fury 
> > > smoothly
> > > in 640x480, eduke32 was always near 98% of cpu usage, at higher 
> > > resolution it
> > > was not playable at all. This is curious given my cpu is a i7-8550U 
> > > 1.80GHz.
> > > 
> > 
> > Here is a diff to build with HAVE_XMP=1 and FURY=1.
> > 
> > This changes the binary to 'fury' and isn't intended to support duke3d
> > from what I understand, so isn't something that should be committed.
> > 
> > Building with FURY=1 disables the polymer OpenGL renderer so this may
> > help with running at higher resolutions.
> > 
> > ifeq ($(FURY),1)
> > APPNAME := Ion Fury
> > APPBASENAME := fury
> > STANDALONE := 1
> > POLYMER := 0
> > USE_LIBVPX := 0
> > NETCODE := 0
> > SIMPLE_MENU := 1
> > endif
> 
> HAVE_XMP solves the music issue on Ion Fury and duke3d still works fine
> (sound, music, game)
> 
> maybe the ports could be split into multipackages to make a
> eduke3d-duke3d and eduke3d-fury
> 
> I did retry, I already had polymer disabled, but it's slow only in
> certains areas at a certain time. Like if loading ennemies was requiring
> lot of cpu, then usage reduces.

HAVE_XMP=1 is normally the default so we can just stop disabling it.

Can you see a difference between building with FURY=1 and without?
Perhaps just the single binary is enough.

Index: Makefile
===
RCS file: /cvs/ports/games/eduke32/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile14 Jul 2019 02:16:51 -  1.22
+++ Makefile2

Re: trouble with radeon r9 290 and eduke32

2019-09-21 Thread Jonathan Gray
On Sat, Sep 21, 2019 at 12:29:59PM +0200, Solene Rapenne wrote:
> On Tue, Aug 20, 2019 at 05:40:50PM +1000, Jonathan Gray wrote:
> > On Tue, Aug 20, 2019 at 09:43:48AM +0300,  wrote:
> > > Hello,
> > > When I start eduke32 with LD_PRELOAD=/usr/X11R6/lib/libGL.so.17.0  so it
> > > can run in opengl,
> > > on ion fury it freezes after starting the game and whole machine becomes
> > > unresponsive for some time. I can ssh to it from my cell phone after some
> > > time. Here is screenshot of dmesg:
> > > 
> > > https://yadi.sk/i/C6NSFEqjxuchoA
> > > 
> > > Here is dmesg after reboot: https://pastebin.com/HiHp8DUQ
> > > 
> > > Help. please.
> > > Thanks.
> > 
> > Why are you using LD_PRELOAD?  OpenGL should work without that.
> > eduke32 will dlopen libGL.so after libGL.so.1 can't be opened going by
> > source/glad/src/glad.c.
> > 
> > Are you using the version of eduke32 in ports?  It is quite old and
> > ion fury had the initial release a few days ago.
> > 
> > Can you reproduce this with any other game supported by eduke32?
> > I don't have ion fury but have the rest (and duke3d shareware
> > is installed when installing the eduke32 package).
> > 
> > Here is an update to the latest eduke32 which has some graphical
> > glitches on the title screen with duke3d shareware with inteldrm.
> > Not sure if the xmp bits are properly built for the tracker music
> > in ion fury.
> > 
> 
> With your patch I can play Ion Fury, sounds works but there is no music.
> 
>   Generating voxel models for Polymost. This may take a while...
>   Initializing music...
>   Initializing sound... 64 voices, 2 channels, 16-bit 48000 Hz
>   MV_PlayXMP: libxmp-lite support not included in this binary.
>   MV_PlayXMP: libxmp-lite support not included in this binary.
>   Line 1637, starttrackslot: invalid level 25 or null music for volume 0 
> level 25
>   Cache time: 939ms
> 
> The duke nukem shareware works too, I did not see any glitch.
> My graphic card from dmesg:
> 
> "Intel UHD Graphics 620" rev 0x07 at pci0 dev 2 function 0 not configured
> inteldrm0 at pci0 dev 2 function 0 "Intel UHD Graphics 620" rev 0x07
> 
> I don't know if this is expected, but I was only able to play Ion Fury 
> smoothly
> in 640x480, eduke32 was always near 98% of cpu usage, at higher resolution it
> was not playable at all. This is curious given my cpu is a i7-8550U 1.80GHz.
> 

Here is a diff to build with HAVE_XMP=1 and FURY=1.

This changes the binary to 'fury' and isn't intended to support duke3d
from what I understand, so isn't something that should be committed.

Building with FURY=1 disables the polymer OpenGL renderer so this may
help with running at higher resolutions.

ifeq ($(FURY),1)
APPNAME := Ion Fury
APPBASENAME := fury
STANDALONE := 1
POLYMER := 0
USE_LIBVPX := 0
NETCODE := 0
SIMPLE_MENU := 1
endif

Index: Makefile
===
RCS file: /cvs/ports/games/eduke32/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile14 Jul 2019 02:16:51 -  1.22
+++ Makefile21 Sep 2019 11:25:53 -
@@ -1,15 +1,14 @@
 # $OpenBSD: Makefile,v 1.22 2019/07/14 02:16:51 naddy Exp $
 
 COMMENT =  Enhanced Duke Nukem 3D engine
-RDATE =20171105
-RTAG = 6496
+RDATE =20190919
+RTAG = 8133
 DISTNAME = eduke32_src_${RDATE}-${RTAG}
 PKGNAME =  eduke32-2.0.0.${RTAG}
-REVISION = 3
 EXTRACT_SUFX = .tar.xz
 CATEGORIES =   games x11
 
-HOMEPAGE = http://www.eduke32.com/
+HOMEPAGE = https://www.eduke32.com/
 
 MAINTAINER =   Ryan Freeman 
 
@@ -35,9 +34,9 @@ LIB_DEPENDS = archivers/lz4 \
 LIB_DEPENDS += x11/gtk+2
 WANTLIB += gtk-x11-2.0
 
-RUN_DEPENDS =  games/duke3ddata
+#RUN_DEPENDS = games/duke3ddata
 
-MASTER_SITES = http://dukeworld.duke4.net/eduke32/synthesis/${RDATE}-${RTAG}/
+MASTER_SITES = https://dukeworld.duke4.net/eduke32/synthesis/${RDATE}-${RTAG}/
 
 COMPILER = base-clang ports-gcc
 
@@ -47,8 +46,9 @@ MAKE_FLAGS += PRETTY_OUTPUT=0 \
CXX="${CXX}" \
STRIP=true \
PACKAGE_REPOSITORY=1 \
-   HAVE_XMP=0 \
-   NOASM=1
+   HAVE_XMP=1 \
+   NOASM=1 \
+   FURY=1
 MAKE_FILE =GNUmakefile
 USE_GMAKE =Yes
 NO_TEST =  Yes
@@ -68,7 +68,7 @@ post-extract:
rm ${WRKSRC}/source/build/include/lz4.h ${WRKSRC}/source/build/src/lz4.c
 
 do-install:
-   ${INSTALL_PROGRAM} ${WRKBUILD}/eduke32 ${PREFIX}/bin
+   ${INSTALL_PROGRAM} ${WRKBUILD}/fury ${PREFIX}/bin
${INSTALL_PROGRAM} ${WRKBUILD}/mapster32 ${PREFIX}/bin
  

Re: AMDGPU in current issue

2019-09-04 Thread Jonathan Gray
amdgpu tracks the linux-4.19.y (lts) branch of linux-stable
currently this is 4.19.69

On Wed, Sep 04, 2019 at 10:28:51AM -0500, Charlie Burnett wrote:
> Thanks for the advice!
> Do you happen to have a link to the commit amdgpu is at currently?
> 
> On Wed, Sep 4, 2019 at 9:44 AM Jonathan Gray  wrote:
> 
> > Look for individual post 4.19 linux commits that are relevant.
> > We have in the past taken small patches to enable more
> > generations of hardware.
> >
> > On Wed, Sep 04, 2019 at 08:11:24AM -0500, Charlie Burnett wrote:
> > > Hey,
> > > I???ve been trying to write a patch to get vega 20 working, but due to a
> > > screw up on my end I lost the progress I???d made. Before I start over
> > again,
> > > I was wondering if you had any advice on how to do it? Before, I was
> > trying
> > > to more or less just port the vega 20 hwmgr files in from FreeBSD drm
> > next
> > > which is at linux drm 5.0 as well as the other files which seemed to
> > > mention Vega 20 or seemed to be needed to compile. I wasn???t having much
> > > luck as you can imagine, and currently I???m still in university so my
> > > experience with kernel patching isn???t fantastic, I was wondering if you
> > > might have any advice where to begin if I???m having to start from
> > scratch?
> > > Best regards,
> > > Charlie Burnett
> > >
> > > On Thu, Aug 1, 2019 at 11:06 PM Jonathan Gray  wrote:
> > >
> > > > On Fri, Aug 02, 2019 at 03:11:54AM -0500, Charlie Burnett wrote:
> > > > > Hey-
> > > > > I'd been messing around with the AMDGPU on current (which I'm aware
> > is
> > > > very
> > > > > experimental) and had very few issues with it using a Vega 56 GPU. I
> > > > > recently swapped to another Vega GPU (Radeon VII) and have issues
> > with
> > > > the
> > > > > display not showing anything. Still boots fine, in that I can still
> > enter
> > > > > commands (i.e. reboot) so it has to be a display issue. I tried
> > searching
> > > > > for the diff where the firmware was added which I'm certain I saw
> > (for
> > > > Vega
> > > > > 20) but can't seem to find it in the commit history. Anyone have a
> > fix
> > > > for
> > > > > it, and if not, who should I talk to if I wanted to help get it
> > working?
> > > > I
> > > > > saw most of the AMDGPU commits have been by @jonathangray if he
> > would be
> > > > > the best option.
> > > > > Thanks!
> > > >
> > > > vega20 firmware was added when ports/sysutils/firmware/amdgpu was
> > > > updated to 20190312.
> > > >
> > > > vega20 is marked as experimental in the version of drm we have, but we
> > > > don't currently check the flag on probe like linux does.
> > > >
> > > > The following diff will prevent amdgpu from matching on devices
> > > > in the amdgpu_pciidlist table with the AMD_EXP_HW_SUPPORT flag
> > > > (currently these are all vega20 ids).
> > > >
> > > > Index: sys/dev/pci/drm/include/drm/drm_drv.h
> > > > ===
> > > > RCS file: /cvs/src/sys/dev/pci/drm/include/drm/drm_drv.h,v
> > > > retrieving revision 1.2
> > > > diff -u -p -r1.2 drm_drv.h
> > > > --- sys/dev/pci/drm/include/drm/drm_drv.h   25 Jul 2019 05:48:16
> > > > -  1.2
> > > > +++ sys/dev/pci/drm/include/drm/drm_drv.h   2 Aug 2019 03:29:58
> > -
> > > > @@ -291,5 +291,7 @@ static inline bool drm_drv_uses_atomic_m
> > > >  intdrm_dev_register(struct drm_device *, unsigned long);
> > > >  void   drm_dev_unregister(struct drm_device *);
> > > >  intdrm_getpciinfo(struct drm_device *, void *, struct drm_file *);
> > > > +const struct drm_pcidev*drm_find_description(int, int,
> > > > +const struct drm_pcidev *);
> > > >
> > > >  #endif
> > > > Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
> > > > ===
> > > > RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c,v
> > > > retrieving revision 1.3
> > > > diff -u -p -r1.3 amdgpu_kms.c
> > > > --- sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 4 Jul 2019 03:39:07
> > -
> > > >  1.3
> > 

Re: AMDGPU in current issue

2019-09-04 Thread Jonathan Gray
Look for individual post 4.19 linux commits that are relevant.
We have in the past taken small patches to enable more
generations of hardware.

On Wed, Sep 04, 2019 at 08:11:24AM -0500, Charlie Burnett wrote:
> Hey,
> I???ve been trying to write a patch to get vega 20 working, but due to a
> screw up on my end I lost the progress I???d made. Before I start over again,
> I was wondering if you had any advice on how to do it? Before, I was trying
> to more or less just port the vega 20 hwmgr files in from FreeBSD drm next
> which is at linux drm 5.0 as well as the other files which seemed to
> mention Vega 20 or seemed to be needed to compile. I wasn???t having much
> luck as you can imagine, and currently I???m still in university so my
> experience with kernel patching isn???t fantastic, I was wondering if you
> might have any advice where to begin if I???m having to start from scratch?
> Best regards,
> Charlie Burnett
> 
> On Thu, Aug 1, 2019 at 11:06 PM Jonathan Gray  wrote:
> 
> > On Fri, Aug 02, 2019 at 03:11:54AM -0500, Charlie Burnett wrote:
> > > Hey-
> > > I'd been messing around with the AMDGPU on current (which I'm aware is
> > very
> > > experimental) and had very few issues with it using a Vega 56 GPU. I
> > > recently swapped to another Vega GPU (Radeon VII) and have issues with
> > the
> > > display not showing anything. Still boots fine, in that I can still enter
> > > commands (i.e. reboot) so it has to be a display issue. I tried searching
> > > for the diff where the firmware was added which I'm certain I saw (for
> > Vega
> > > 20) but can't seem to find it in the commit history. Anyone have a fix
> > for
> > > it, and if not, who should I talk to if I wanted to help get it working?
> > I
> > > saw most of the AMDGPU commits have been by @jonathangray if he would be
> > > the best option.
> > > Thanks!
> >
> > vega20 firmware was added when ports/sysutils/firmware/amdgpu was
> > updated to 20190312.
> >
> > vega20 is marked as experimental in the version of drm we have, but we
> > don't currently check the flag on probe like linux does.
> >
> > The following diff will prevent amdgpu from matching on devices
> > in the amdgpu_pciidlist table with the AMD_EXP_HW_SUPPORT flag
> > (currently these are all vega20 ids).
> >
> > Index: sys/dev/pci/drm/include/drm/drm_drv.h
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/include/drm/drm_drv.h,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 drm_drv.h
> > --- sys/dev/pci/drm/include/drm/drm_drv.h   25 Jul 2019 05:48:16
> > -  1.2
> > +++ sys/dev/pci/drm/include/drm/drm_drv.h   2 Aug 2019 03:29:58 -
> > @@ -291,5 +291,7 @@ static inline bool drm_drv_uses_atomic_m
> >  intdrm_dev_register(struct drm_device *, unsigned long);
> >  void   drm_dev_unregister(struct drm_device *);
> >  intdrm_getpciinfo(struct drm_device *, void *, struct drm_file *);
> > +const struct drm_pcidev*drm_find_description(int, int,
> > +const struct drm_pcidev *);
> >
> >  #endif
> > Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 amdgpu_kms.c
> > --- sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 4 Jul 2019 03:39:07 -
> >  1.3
> > +++ sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 2 Aug 2019 03:35:35 -
> > @@ -1337,10 +1337,23 @@ int amdgpu_debugfs_firmware_init(struct
> >  int
> >  amdgpu_probe(struct device *parent, void *match, void *aux)
> >  {
> > +   struct pci_attach_args *pa = aux;
> > +   const struct drm_pcidev *id_entry;
> > +   unsigned long flags = 0;
> > +
> > if (amdgpu_fatal_error)
> > return 0;
> > -   if (drm_pciprobe(aux, amdgpu_pciidlist))
> > -   return 20;
> > +
> > +   id_entry = drm_find_description(PCI_VENDOR(pa->pa_id),
> > +   PCI_PRODUCT(pa->pa_id), amdgpu_pciidlist);
> > +   if (id_entry != NULL) {
> > +   flags = id_entry->driver_data;
> > +   if (flags & AMD_EXP_HW_SUPPORT)
> > +   return 0;
> > +   else
> > +   return 20;
> > +   }
> > +
> > return 0;
> >  }
> >
> >
> >



Re: trouble with radeon r9 290 and eduke32

2019-08-20 Thread Jonathan Gray
On Tue, Aug 20, 2019 at 09:43:48AM +0300,  wrote:
> Hello,
> When I start eduke32 with LD_PRELOAD=/usr/X11R6/lib/libGL.so.17.0  so it
> can run in opengl,
> on ion fury it freezes after starting the game and whole machine becomes
> unresponsive for some time. I can ssh to it from my cell phone after some
> time. Here is screenshot of dmesg:
> 
> https://yadi.sk/i/C6NSFEqjxuchoA
> 
> Here is dmesg after reboot: https://pastebin.com/HiHp8DUQ
> 
> Help. please.
> Thanks.

Why are you using LD_PRELOAD?  OpenGL should work without that.
eduke32 will dlopen libGL.so after libGL.so.1 can't be opened going by
source/glad/src/glad.c.

Are you using the version of eduke32 in ports?  It is quite old and
ion fury had the initial release a few days ago.

Can you reproduce this with any other game supported by eduke32?
I don't have ion fury but have the rest (and duke3d shareware
is installed when installing the eduke32 package).

Here is an update to the latest eduke32 which has some graphical
glitches on the title screen with duke3d shareware with inteldrm.
Not sure if the xmp bits are properly built for the tracker music
in ion fury.

Index: Makefile
===
RCS file: /cvs/ports/games/eduke32/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile14 Jul 2019 02:16:51 -  1.22
+++ Makefile20 Aug 2019 07:03:43 -
@@ -1,15 +1,14 @@
 # $OpenBSD: Makefile,v 1.22 2019/07/14 02:16:51 naddy Exp $
 
 COMMENT =  Enhanced Duke Nukem 3D engine
-RDATE =20171105
-RTAG = 6496
+RDATE =20190818
+RTAG = 8040
 DISTNAME = eduke32_src_${RDATE}-${RTAG}
 PKGNAME =  eduke32-2.0.0.${RTAG}
-REVISION = 3
 EXTRACT_SUFX = .tar.xz
 CATEGORIES =   games x11
 
-HOMEPAGE = http://www.eduke32.com/
+HOMEPAGE = https://www.eduke32.com/
 
 MAINTAINER =   Ryan Freeman 
 
@@ -37,7 +36,7 @@ WANTLIB +=gtk-x11-2.0
 
 RUN_DEPENDS =  games/duke3ddata
 
-MASTER_SITES = http://dukeworld.duke4.net/eduke32/synthesis/${RDATE}-${RTAG}/
+MASTER_SITES = https://dukeworld.duke4.net/eduke32/synthesis/${RDATE}-${RTAG}/
 
 COMPILER = base-clang ports-gcc
 
Index: distinfo
===
RCS file: /cvs/ports/games/eduke32/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo22 Nov 2017 03:43:46 -  1.4
+++ distinfo20 Aug 2019 06:29:45 -
@@ -1,2 +1,2 @@
-SHA256 (eduke32_src_20171105-6496.tar.xz) = 
1+MCe1npolXkOvGK6Jtk+THxlaIL9kwoTLKYpdkMPrI=
-SIZE (eduke32_src_20171105-6496.tar.xz) = 14351444
+SHA256 (eduke32_src_20190818-8040.tar.xz) = 
NO62FnQvdvlKWlAwdVctrBboDeAFIAU8VRmS9ik0i0k=
+SIZE (eduke32_src_20190818-8040.tar.xz) = 15922772
Index: patches/patch-Common_mak
===
RCS file: /cvs/ports/games/eduke32/patches/patch-Common_mak,v
retrieving revision 1.1
diff -u -p -r1.1 patch-Common_mak
--- patches/patch-Common_mak22 Nov 2017 03:43:46 -  1.1
+++ patches/patch-Common_mak20 Aug 2019 06:36:43 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-Common_mak,v 1.1 2017/11
 Index: Common.mak
 --- Common.mak.orig
 +++ Common.mak
-@@ -638,7 +638,7 @@ ifeq (0,$(RELEASE))
+@@ -700,7 +700,7 @@ ifeq (0,$(RELEASE))
  F_NO_STACK_PROTECTOR :=
  else
  ifeq (0,$(CLANG))
@@ -11,4 +11,4 @@ Index: Common.mak
 +#COMMONFLAGS += -funswitch-loops
  endif
  
- ifeq (0,$(DEBUGANYWAY))
+ ifeq (0,$(FORCEDEBUG))
Index: patches/patch-GNUmakefile
===
RCS file: /cvs/ports/games/eduke32/patches/patch-GNUmakefile,v
retrieving revision 1.2
diff -u -p -r1.2 patch-GNUmakefile
--- patches/patch-GNUmakefile   17 Jul 2018 07:56:44 -  1.2
+++ patches/patch-GNUmakefile   20 Aug 2019 06:36:55 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-GNUmakefile,v 1.2 2018/0
 Index: GNUmakefile
 --- GNUmakefile.orig
 +++ GNUmakefile
-@@ -161,7 +161,6 @@ engine_objs := \
+@@ -227,7 +227,6 @@ engine_objs := \
  textfont.cpp \
  smalltextfont.cpp \
  kplib.cpp \
@@ -11,7 +11,7 @@ Index: GNUmakefile
  osd.cpp \
  pragmas.cpp \
  scriptfile.cpp \
-@@ -581,7 +580,7 @@ ifeq ($(SUBPLATFORM),LINUX)
+@@ -655,7 +654,7 @@ ifeq ($(SUBPLATFORM),LINUX)
  endif
  
  ifeq ($(PLATFORM),BSD)
@@ -20,12 +20,12 @@ Index: GNUmakefile
  endif
  
  ifeq ($(PLATFORM),DARWIN)
-@@ -755,7 +754,7 @@ endif
+@@ -829,7 +828,7 @@ endif
  
   Final setup
  
--COMPILERFLAGS += -I$(engine_inc) -I$(mact_inc) -I$(audiolib_inc) -I$(enet_inc)
-+COMPILERFLAGS := -I$(engine_inc) -I$(mact_inc) -I$(audiolib_inc) 
-I$(enet_inc) $(COMPILERFLAGS)
- 
- 
- # Recipes
+-COMPILERFLAGS += -I$(engine_inc) -I$(mact_inc) -I$(audiolib_inc) 
-I$(enet_inc) -I$(glad_inc) -MP -MMD
++COMPILERFLAGS := -I$(engine_inc) -I$(mact_inc) -I$(audiolib_inc) 
-I$(enet_inc) -I$(glad_inc) -MP -MMD $(COMPILERFLAGS)
+ ifneq (0,$(USE_PHYSFS))

Re: Best 1Gbe NIC

2019-08-02 Thread Jonathan Gray
On Fri, Aug 02, 2019 at 09:19:09AM +0100, Andy Lemin wrote:
> Hi list,
> 
> I know this is a rather classic question, but I have searched a lot on this 
> again recently, and I just cannot find any conclusive up to date information?
> 
> I am looking to buy the best 1Gbe NIC possible for OpenBSD and the only 
> official comments I can find relate to 3COM for ISA, or community consensus 
> towards Chelsio for 10Gbe.
> 
> I know Intel works ok and I???ve used the i350???s before, but my 
> understanding is that Intel still doesn???t provide the documentation for 
> their NICs and so the emX driver is reverse engineered.

This is incorrect.  Intel provides datasheets for Ethernet parts.
em(4) is derived from Intel authored code for FreeBSD supplied under a
permissive license.

> 
> And if I remember correctly some offload features were also disabled in the 
> emX driver a while back as some functions where found to be insecure on die 
> and so it was deemed safer to bring the logic back on CPU.
> 
> So I???m looking for the best 1Gbe NIC that supports the most offloading/best 
> driver support/performance etc.
> 
> Thanks, Andy.
> 
> PS; could we update the official supported hardware lists? ;)
> All the best.
> 
> 
> Sent from a teeny tiny keyboard, so please excuse typos
> 



Re: AMDGPU in current issue

2019-08-01 Thread Jonathan Gray
On Fri, Aug 02, 2019 at 03:11:54AM -0500, Charlie Burnett wrote:
> Hey-
> I'd been messing around with the AMDGPU on current (which I'm aware is very
> experimental) and had very few issues with it using a Vega 56 GPU. I
> recently swapped to another Vega GPU (Radeon VII) and have issues with the
> display not showing anything. Still boots fine, in that I can still enter
> commands (i.e. reboot) so it has to be a display issue. I tried searching
> for the diff where the firmware was added which I'm certain I saw (for Vega
> 20) but can't seem to find it in the commit history. Anyone have a fix for
> it, and if not, who should I talk to if I wanted to help get it working? I
> saw most of the AMDGPU commits have been by @jonathangray if he would be
> the best option.
> Thanks!

vega20 firmware was added when ports/sysutils/firmware/amdgpu was
updated to 20190312.

vega20 is marked as experimental in the version of drm we have, but we
don't currently check the flag on probe like linux does.

The following diff will prevent amdgpu from matching on devices
in the amdgpu_pciidlist table with the AMD_EXP_HW_SUPPORT flag
(currently these are all vega20 ids).

Index: sys/dev/pci/drm/include/drm/drm_drv.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/drm/drm_drv.h,v
retrieving revision 1.2
diff -u -p -r1.2 drm_drv.h
--- sys/dev/pci/drm/include/drm/drm_drv.h   25 Jul 2019 05:48:16 -  
1.2
+++ sys/dev/pci/drm/include/drm/drm_drv.h   2 Aug 2019 03:29:58 -
@@ -291,5 +291,7 @@ static inline bool drm_drv_uses_atomic_m
 intdrm_dev_register(struct drm_device *, unsigned long);
 void   drm_dev_unregister(struct drm_device *);
 intdrm_getpciinfo(struct drm_device *, void *, struct drm_file *);
+const struct drm_pcidev*drm_find_description(int, int,
+const struct drm_pcidev *);
 
 #endif
Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c,v
retrieving revision 1.3
diff -u -p -r1.3 amdgpu_kms.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 4 Jul 2019 03:39:07 -   
1.3
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 2 Aug 2019 03:35:35 -
@@ -1337,10 +1337,23 @@ int amdgpu_debugfs_firmware_init(struct 
 int
 amdgpu_probe(struct device *parent, void *match, void *aux)
 {
+   struct pci_attach_args *pa = aux;
+   const struct drm_pcidev *id_entry;
+   unsigned long flags = 0;
+
if (amdgpu_fatal_error)
return 0;
-   if (drm_pciprobe(aux, amdgpu_pciidlist))
-   return 20;
+
+   id_entry = drm_find_description(PCI_VENDOR(pa->pa_id),
+   PCI_PRODUCT(pa->pa_id), amdgpu_pciidlist);
+   if (id_entry != NULL) {
+   flags = id_entry->driver_data;
+   if (flags & AMD_EXP_HW_SUPPORT)
+   return 0;
+   else
+   return 20;  
+   }
+   
return 0;
 }
 



Re: Blank screen after installing OpenBSD 6.5

2019-07-17 Thread Jonathan Gray
On Wed, Jul 17, 2019 at 01:32:37PM +0200, Stefan Sperling wrote:
> On Wed, Jul 17, 2019 at 01:15:26PM +0200, oxst...@gmx.net wrote:
> > Hello,
> > 
> > I recently installed OpenBSD 6.5 on an i386 router.
> > The intallation process went fine. However, I got a black screen after 
> > rebooting.
> > 
> > I tried opening a SSH session, but the computer doesn't reply.
> > 
> > The screen is attached using a VGA cable. The computer send a signal over 
> > that cable. If I detach it from the router, the screen turns off. If I plug 
> > it back, the screen turns on (but nothing is displayed).
> > 
> > I send you the dmesg output. I took pictures of the output and used an OCR 
> > to convert them to text format.
> > 
> > Thank you !
> 
> Your CPU should be capable of running OpenBSD/amd64.
> 
> Please try to install that instead of OpenBSD/i386.

Or an i386 snapshot.  There were known problems running the linux 4.4 based
drm that was part of OpenBSD 6.5 on ivy bridge with i386 that don't show up
with the linux 4.19 based drm we have in -current.

>  
> > OpenBSD 6.5 (RAMDISC_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISC_CD
> > real mem  = 2029793280 (1935MB)
> > avail mem = 1983680512 (1891MB)
> > mainbus0 at root
> > bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xeb530 (73 entries)
> > bios0: vendor American Megatrends Inc. version "4.6.5" date 07/10/2016
> > bios0: INTEL Corporation ChiefRiver
> > acpi0 at bios0: rev 2
> > acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT
> > acpimadt0 at acpi0 addr 0xfee0: PC???AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz ("Genuinelntel" 686-class) 
> > 1.80 GH
> > z, 06-3a-09
> > cpu0: 
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
> > LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> > .EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NX
> > E,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SHEP,ERMS,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> 



Re: Configuration of radeondrm

2019-07-07 Thread Jonathan Gray
On Sun, Jul 07, 2019 at 07:49:58PM +, Ibsen S Ripsbusker wrote:
> I have an ATI Radeon HD8490. It seems to be recognized properly
> in the dmesg. Also, I can view ttys from either of its two plugs.
> 
> Unfortunately, it is not recognized as a screen for X. The attached
> Xorg.0.log is from when I run "startx".

Xorg is no longer setuid you should use xenodm.

See https://www.openbsd.org/faq/upgrade65.html

> 
> This is on 6.5, and it has been like this since I installed.
> I haven't tried any other versions or operating systems.
> 
> Here is some other information that may be relevant.
> 
> $ sysctl machdep.allowaperture
> machdep.allowaperture=1
> $ ls -lh /dev/mem /dev/xf86
> crw-r-  1 root  kmem 2,   0 Apr 13 23:19 /dev/mem
> crw---  1 root  wheel2,   4 Apr 13 23:19 /dev/xf86
> 
> What should I do in order to have X start when I run startx?

> OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 137378279424 (131014MB)
> avail mem = 133205159936 (127034MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf1e20 (125 entries)
> bios0: vendor Dell Inc. version "A18" date 06/21/2018
> bios0: Dell Inc. Precision T5600
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG TCPA SSDT SRAT SLIT HPET BOOT SSDT SLIC
> acpi0: wakeup devices NPE2(S4) NPE3(S4) NPE7(S4) EHC1(S3) EHC2(S3) HDEF(S4) 
> PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
> PXSX(S4) RP05(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 1995.46 MHz, 06-2d-07
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 1995.19 MHz, 06-2d-07
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 1995.19 MHz, 06-2d-07
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 1995.19 MHz, 06-2d-07
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 8 (application processor)
> cpu4: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 1995.19 MHz, 06-2d-07
> cpu4: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu4: smt 0, core 4, package 0
> cpu5 at mainbus0: apid 10 (application processor)
> cpu5: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 1995.19 MHz, 06-2d-07
> cpu5: 
> 

Re: Secondary monitor switches off when inteldrm switches on

2019-07-02 Thread Jonathan Gray
On Tue, Jul 02, 2019 at 05:38:35PM -0700, Misc User wrote:
> On 7/2/2019 2:45 PM, Henry Jensen wrote:
> > Greetings,
> > 
> > to keep it short:
> > 
> > - older Fujitsu Esprimo PC, Core2Duo, Integrated Intel Graphics
> > - 2 monitors, connected at VGA and DVI
> > - during installation both monitors were on all the time.
> > - Computer switched on, both displays on, boot begins
> > - inteldrm kicks in, the monitor at the DVI port switches OFF (short 
> > message on the display says "power saving mode")
> > - Xenodm starts, only at 1 display. xrandr reports only 1 monitor, Xorg log 
> > says DVI monitor is disconnected
> > - similar behaviour on FreeBSD, but:
> > - on Linux both monitors are working with drm and X.
> > 
> > Where to begin to look?
> > 
> > Kind regards,
> > 
> > Henry
> > 
> 
> 
> Can you post a dmesg, there were a -lot- of different video chips used
> on the core2duo architecture and each has its quirks.  Yours might be
> actually supported, but a lot of them aren't.

inteldrm attaches to this all all integrated Intel video of that era.

> 
> From what I remember, there is some kind of proprietary bit of firmware
> that needs to be installed to get both outputs working simultaneously,
> but it requires a binary blob to be injected into the driver.  IIRC its
> some undocumented set of registers that need to get their bits flipped
> for the second output to be recognized by the itneldrm code.

This is complete nonsense.

I would not be surprised if the DVI output is SDVO.
Building a kernel with 'option DRMDEBUG' added to the config will
show some additional information in dmesg.
It can be made more verbose by setting additional variables.



Re: Installing OpenBSD on Supermicro A2SDi-4C-HLN4F

2019-06-15 Thread Jonathan Gray
On Sat, Jun 15, 2019 at 09:02:11AM +0100, Richard Laysell wrote:
> 
> Hello,
> 
> I was trying OpenBSD on a Supermicro A2SDi-4C-HLN4F which uses an Intel
> Atom CPU (Denverton).  The board boots but most devices are not
> detected because ACPI can't be enabled.
> 
> Does anyone know if this is likely to be supported at some point?

Try a snapshot.  ACPI changes were made for a similiar machine
(Lanner NCA-1510) in May.

However there is no support for the integrated X553 Ethernet at the
moment.

> 
> Full dmesg is below
> 
> OpenBSD 6.5 (RAMDISK_CD) #3: Sat Apr 13 14:55:38 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 17125621760 (16332MB)
> avail mem = 16602619904 (15833MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f0c3000 (35 entries)
> bios0: vendor American Megatrends Inc. version "1.1b" date 12/17/2018
> bios0: Supermicro Super Server
> acpi0 at bios0: rev 2, can't enable ACPI
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.41 MHz, 06-5f-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 2MB 64b/line 16-way L2 cache
> cpu0: cannot disable silicon debug
> cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
> pci0 at mainbus0 bus 0
> 0:31:5: mem address conflict 0xfe01/0x1000
> pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x1980 rev 0x11
> pchb1 at pci0 dev 4 function 0 vendor "Intel", unknown product 0x19a1 rev 0x11
> vendor "Intel", unknown product 0x19a2 (class system subclass root complex 
> event, rev 0x11) at pci0 dev 5 function 0 not configured
> ppb0 at pci0 dev 6 function 0 vendor "Intel", unknown product 0x19a3 rev 0x11
> pci1 at ppb0 bus 1
> vendor "Intel", unknown product 0x19e2 (class processor subclass 
> Co-processor, rev 0x11) at pci1 dev 0 function 0 not configured
> ppb1 at pci0 dev 10 function 0 vendor "Intel", unknown product 0x19a5 rev 0x11
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 16 function 0 vendor "Intel", unknown product 0x19aa rev 0x11
> pci3 at ppb2 bus 3
> ppb3 at pci0 dev 17 function 0 vendor "Intel", unknown product 0x19ab rev 0x11
> pci4 at ppb3 bus 4
> ppb4 at pci4 dev 0 function 0 "ASPEED Technology AST1150 PCI" rev 0x03
> pci5 at ppb4 bus 5
> "ASPEED Technology AST2000" rev 0x30 at pci5 dev 0 function 0 not configured
> vendor "Intel", unknown product 0x19ac (class system subclass miscellaneous, 
> rev 0x11) at pci0 dev 18 function 0 not configured
> ahci0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x19b2 rev 
> 0x11: unable to map interrupt
> ahci1 at pci0 dev 20 function 0 vendor "Intel", unknown product 0x19c2 rev 
> 0x11: unable to map interrupt
> xhci0 at pci0 dev 21 function 0 vendor "Intel", unknown product 0x19d0 rev 
> 0x11: couldn't map interrupt
> ppb5 at pci0 dev 22 function 0 vendor "Intel", unknown product 0x19d1 rev 0x11
> pci6 at ppb5 bus 6
> vendor "Intel", unknown product 0x15e4 (class network subclass ethernet, rev 
> 0x11) at pci6 dev 0 function 0 not configured
> vendor "Intel", unknown product 0x15e4 (class network subclass ethernet, rev 
> 0x11) at pci6 dev 0 function 1 not configured
> ppb6 at pci0 dev 23 function 0 vendor "Intel", unknown product 0x19d2 rev 0x11
> pci7 at ppb6 bus 7
> vendor "Intel", unknown product 0x15e5 (class network subclass ethernet, rev 
> 0x11) at pci7 dev 0 function 0 not configured
> vendor "Intel", unknown product 0x15e5 (class network subclass ethernet, rev 
> 0x11) at pci7 dev 0 function 1 not configured
> vendor "Intel", unknown product 0x19d3 (class communications subclass 
> miscellaneous, rev 0x11) at pci0 dev 24 function 0 not configured
> vendor "Intel", unknown product 0x19dc (class bridge subclass ISA, rev 0x11) 
> at pci0 dev 31 function 0 not configured
> vendor "Intel", unknown product 0x19de (class memory subclass miscellaneous, 
> rev 0x11) at pci0 dev 31 function 2 not configured
> vendor "Intel", unknown product 0x19df (class serial bus subclass SMBus, rev 
> 0x11) at pci0 dev 31 function 4 not configured
> vendor "Intel", unknown product 0x19e0 (class serial bus unknown subclass 
> 0x80, rev 0x11) at pci0 dev 31 function 5 not configured
> isa0 at mainbus0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> efifb0 at mainbus0: 1920x1200, 32bpp
> wsdisplay at efifb0 not configured
> softraid0 at root
> scsibus0 at softraid0: 256 targets
> root on rd0a swap on rd0b dump on rd0b
> erase ^?, werase ^W, kill ^U, intr ^C, status ^T
> 
> Welcome to the OpenBSD/amd64 6.5 installation program.
> (I)nstall, 

Re: "ucode too large"

2019-06-07 Thread Jonathan Gray
On Fri, Jun 07, 2019 at 03:43:39PM +0200, Paul de Weerd wrote:
> I've just replaced my home gateway with a brandless machine with an
> i5-7200U.  While preparing, I noticed the message "ucode too large"
> scrolling by on the serial console, just before the kernel starts.
> 
> The dmesg shows cpu0 as mode 06-8e-09:
> 
> cpu0: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2395.19 MHz, 06-8e-09
> 
> While /etc/firmware/intel/06-8e-09 is the biggest file in that
> directory (at 193kB), so this probably has something to do with that
> and the MDS "fun".
> 
> Machine works fine as far as I can tell (typing this mail over an SSH
> session through it).

The limit was raised only for efiboot.

https://marc.info/?l=openbsd-cvs=155853966111794=2

For non-efi it is still 128KB.  The region of memory it uses starts
at 1MB.  I think you should be able to raise the 'too large' check
to 256KB without problem but have not tested this.

You'll need to run installboot after installing.  Wouldn't hurt
to have a miniroot on removable media to recover if needed.

Index: arch/amd64/stand/boot/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/boot/conf.c,v
retrieving revision 1.46
diff -u -p -r1.46 conf.c
--- arch/amd64/stand/boot/conf.c15 May 2019 06:52:33 -  1.46
+++ arch/amd64/stand/boot/conf.c7 Jun 2019 14:05:58 -
@@ -40,7 +40,7 @@
 #include 
 #include 
 
-const char version[] = "3.44";
+const char version[] = "3.45";
 intdebug = 1;
 
 
Index: arch/amd64/stand/libsa/exec_i386.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/exec_i386.c,v
retrieving revision 1.31
diff -u -p -r1.31 exec_i386.c
--- arch/amd64/stand/libsa/exec_i386.c  28 May 2019 17:38:02 -  1.31
+++ arch/amd64/stand/libsa/exec_i386.c  7 Jun 2019 14:04:19 -
@@ -226,7 +226,7 @@ ucode_load(void)
return;
 
buflen = sb.st_size;
-   if (buflen > 128*1024) {
+   if (buflen > 256*1024) {
printf("ucode too large\n");
return;
}



Re: Lenovo w/ AMD Ryzen CPU

2019-05-28 Thread Jonathan Gray
On Tue, May 28, 2019 at 09:58:58AM -0700, Chris Cappuccio wrote:
> David Anthony [d...@silentsystems.org] wrote:
> > All,
> > 
> > The Lenovo release of T*95 series laptops with AMD Ryzen CPU appears 
> > imminent. 
> > 
> > Would these be poor choices for OpenBSD? Are there any anticipated 
> > ???gotchas??? that I should be aware of? Any thoughts would be greatly 
> > appreciated.
> > 
> 
> Chances are it will work very well.

I disagree.

> 
> First, less flaws were identified with AMD's implementation of speculative
> execution. That means that there are less mitigations to slow down the system.
> Whether there are unidentified flaws, that's another issue..
> 
> Second, the amdgpu driver was just imported to OpenBSD 6.5-current. That
> means you'll have graphics support. Combined with the recent improvements
> to xhci and wi-fi driver improvments (well, mostly intel), support for modern
> laptops has never been better.

There is no support for newer Intel wireless like the 9260 the T495 has.

The version of amdgpu in the tree does not include support for
picasso APUs (Ryzen 3xxx) https://en.wikichip.org/wiki/amd/cores/picasso
or whatever raven2 works out to be.

It is also not enabled by default just yet.

If anyone wants to have a Ryzen thinkpad work in the short term the
current A series A285/A485 and similar generation E series require less
work.  Suspend/resume doesn't work right on them currently.
They mostly ship with RTL8822BE wireless which there is no support for
but this can be replaced with an Intel 8265 which is in the bios
whitelist and is supported by iwm(4).



Re: Random system freeze.

2019-05-28 Thread Jonathan Gray
On Tue, May 28, 2019 at 09:25:52AM -, Stuart Henderson wrote:
> On 2019-05-23, Paco Esteban  wrote:
> > Hi misc@,
> >
> > I've been having some system freezes lately, as others using intel
> > graphics.
> >
> > Sometimes it does not hit in days but sometimes the system hangs 2 or 3
> > times a day.
> >
> > I was wondering if there's any iformation I can supply to devs that
> > could be useful (besides dmesg ...).
> 
> Some things to try:
> 
> Does it seem to be in ddb? Try typing "call cpu_reset" blindly and see
> if it reboots.
> 
> Does it start responding again if you wait?
> 
> What does "sysctl kern.timecounter.hardware" say? If it's tsc, try one
> of the other names shown in "sysctl kern.timecounter.choice", probably
> acpihpet0 if available.
> 
> Is it any better with the intel driver rathef than modesetting? Try this
> in xorg.conf:
> 
> Section "Device"
>Identifier  "Intel Graphics"
>Driver  "intel"
> EndSection
> 

All the reports I have seen have been from skylake or kabylake.
Have never encountered it with ivy bridge or broadwell here.

jcs@ mentioned off list:

enable_dc enable_fbc enable_psr enable_ips 0 lasts longer but locked up
after a few days.

Still locks up with no i915 firmware loaded.

Not reachable over network on lockup.

Occurs with intel xorg driver as well as modesetting.



Re: Thinkpad A285 mouse issues

2019-05-10 Thread Jonathan Gray
On systems with tsc desychronised between cores acpihpet is preferable.
There is no code to detect this and automatically select acpihpet or try
to sychronise tsc between cores currently.

This often comes up on AMD based systems but not Intel ones.

On Fri, May 10, 2019 at 03:30:41PM +0100, Oriol Demaria wrote:
> Actually both things fix the issue. Seems to be better just changing the
> timecounter, rather than running on just one core. I noticed by the way that
> when I run sysupgrade, or upgrade as before the SP kernel is the one
> installed. And I have to change manually and reboot. Also I noticed that
> when I run dmesg both kernels output data. Can't recall if this was the
> usual behavior.
> 
> So, are there any advise against running with acpihpet0 timecounter instead
> of tsc? I'm attaching my dmesg.
> 
> timecounters:
> 
> sysctl kern.timecounter
> kern.timecounter.tick=1
> kern.timecounter.timestepwarnings=0
> kern.timecounter.hardware=acpihpet0
> kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000)
> dummy(-100)
> 
> Regards,
> 
> ---
> Oriol Demaria
> 2FFED630C16E4FF8
> 
> On 10/05/2019 01:15, Jonathan Gray wrote:
> > On Thu, May 09, 2019 at 04:17:40PM +0100, Oriol Demaria wrote:
> > > I have this laptop and I'm having issues with this laptop. Wireless
> > > has to
> > > be replaced and basically have to wait till the graphics card is
> > > properly
> > > supported, right now is running X with the UEFI framebuffer. So this
> > > issues
> > > are expected.
> > > 
> > > But I'm having a very annoying bug on X. The mouse stops working,
> > > specially
> > > Firefox seems to be a problem, but other apps too (perhaps I notice
> > > more
> > > here as others I mainly use the keyboard). When I run xprop to try
> > > to figure
> > > out something I get the error "Can't grab the mouse" and won't run.
> > > Seems
> > > that some event holds the mouse, and prevents you from "clicking".
> > > 
> > > Changed the touchpad to synaptics to see if it makes difference,
> > > seems to
> > > improve a bit, but still the problem comes back. The other mouse
> > > devices are
> > > using ws driver. Has someone got a workaround for this? Similar
> > > experience?
> > 
> > Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0
> > 
> > > 
> > > Thanks in advance.
> > > 
> > > Relevant part of the xorg log file:
> > > 
> > > [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd"
> > > (type:
> > > KEYBOARD, id 6)
> > > [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0
> > > [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse
> > > touchpad"
> > > [ 18193.925] (II) LoadModule: "synaptics"
> > > [ 18193.927] (II) Loading
> > > /usr/X11R6/lib/modules/input/synaptics_drv.so
> > > [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation"
> > > [ 18193.929]compiled for 1.19.7, module version = 1.9.1
> > > [ 18193.929]Module class: X.Org XInput Driver
> > > [ 18193.929]ABI class: X.Org XInput driver, version 24.1
> > > [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0'
> > > [ 18193.929] (**) /dev/wsmouse0: always reports core events
> > > [ 18193.929] (**) Option "Device" "/dev/wsmouse0"
> > > [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676
> > > resolution 45
> > > [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760
> > > resolution 69
> > > [ 18194.832] (**) /dev/wsmouse0: always reports core events
> > > [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0"
> > > (type: TOUCHPAD, id 7)
> > > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now
> > > constant
> > > deceleration 2.5
> > > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now
> > > 1.75
> > > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is
> > > now 0.035
> > > [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1
> > > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1
> > > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000
> > > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4
> > > [ 18195.340] (II) config/wscons: checking

Re: Criteria for errata

2019-05-10 Thread Jonathan Gray
On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote:
> Jeremy O'Brien wrote:
> > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above fix, 
> > and installed it on my system which has made X rock-stable for me. This is 
> > totally fine for me personally, but I was curious if other people have run 
> > into this issue on their 6.5 installs, and if so, is this something worth 
> > pushing a reliability errata out for? I'm unfamiliar with how the process 
> > traditionally works so please excuse me if the question is outlandish.
> 
> security issues and major reliability issues. but we try not to spend all our
> time making errata. that fix may be a contender. depends on how widely
> reported it is.
> 

vga arbiter is only used with multiple cards which isn't the common case



Re: Thinkpad A285 mouse issues

2019-05-09 Thread Jonathan Gray
On Thu, May 09, 2019 at 04:17:40PM +0100, Oriol Demaria wrote:
> I have this laptop and I'm having issues with this laptop. Wireless has to
> be replaced and basically have to wait till the graphics card is properly
> supported, right now is running X with the UEFI framebuffer. So this issues
> are expected.
> 
> But I'm having a very annoying bug on X. The mouse stops working, specially
> Firefox seems to be a problem, but other apps too (perhaps I notice more
> here as others I mainly use the keyboard). When I run xprop to try to figure
> out something I get the error "Can't grab the mouse" and won't run. Seems
> that some event holds the mouse, and prevents you from "clicking".
> 
> Changed the touchpad to synaptics to see if it makes difference, seems to
> improve a bit, but still the problem comes back. The other mouse devices are
> using ws driver. Has someone got a workaround for this? Similar experience?

Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0

> 
> Thanks in advance.
> 
> Relevant part of the xorg log file:
> 
> [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd" (type:
> KEYBOARD, id 6)
> [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0
> [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse touchpad"
> [ 18193.925] (II) LoadModule: "synaptics"
> [ 18193.927] (II) Loading /usr/X11R6/lib/modules/input/synaptics_drv.so
> [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation"
> [ 18193.929]compiled for 1.19.7, module version = 1.9.1
> [ 18193.929]Module class: X.Org XInput Driver
> [ 18193.929]ABI class: X.Org XInput driver, version 24.1
> [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0'
> [ 18193.929] (**) /dev/wsmouse0: always reports core events
> [ 18193.929] (**) Option "Device" "/dev/wsmouse0"
> [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676
> resolution 45
> [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760
> resolution 69
> [ 18194.832] (**) /dev/wsmouse0: always reports core events
> [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0"
> (type: TOUCHPAD, id 7)
> [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now constant
> deceleration 2.5
> [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now 1.75
> [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is now 0.035
> [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1
> [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1
> [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000
> [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4
> [ 18195.340] (II) config/wscons: checking input device /dev/wsmouse
> [ 18195.340] (II) LoadModule: "ws"
> [ 18195.341] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so
> [ 18195.342] (II) Module ws: vendor="X.Org Foundation"
> [ 18195.342]compiled for 1.19.7, module version = 1.3.0
> [ 18195.342]Module class: X.Org XInput Driver
> [ 18195.342]ABI class: X.Org XInput driver, version 24.1
> [ 18195.343] (II) Using input driver 'ws' for '/dev/wsmouse'
> [ 18195.343] (**) /dev/wsmouse: always reports core events
> [ 18195.343] (II) ws: /dev/wsmouse: debuglevel 0
> [ 18195.343] (**) Option "Device" "/dev/wsmouse"
> [ 18195.343] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5
> [ 18195.343] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7
> [ 18195.343] (**) ws: /dev/wsmouse: associated screen: 0
> [ 18195.372] (II) ws: /dev/wsmouse: minimum x position: 0
> [ 18195.372] (II) ws: /dev/wsmouse: maximum x position: 1919
> [ 18195.372] (II) ws: /dev/wsmouse: minimum y position: 0
> [ 18195.372] (II) ws: /dev/wsmouse: maximum y position: 1079
> [ 18195.372] (==) ws: /dev/wsmouse: Buttons: 7
> [ 18195.404] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5
> [ 18195.404] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type:
> MOUSE, id 8)
> [ 18195.436] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1
> [ 18195.436] (**) /dev/wsmouse: (accel) acceleration profile 0
> [ 18195.436] (**) /dev/wsmouse: (accel) acceleration factor: 2.000
> [ 18195.436] (**) /dev/wsmouse: (accel) acceleration threshold: 4
> 
> wsconsctl | grep mouse
> mouse.type=synaptics
> mouse.rawmode=0
> mouse.scale=1266,5676,1094,4760,0,45,69
> mouse.tp.tapping=0
> mouse.tp.scaling=0.160
> mouse.tp.swapsides=0
> mouse.tp.disable=0
> mouse.tp.edges=0.0,5.0,10.0,5.0
> mouse1.type=ps2
> mouse2.type=usb
> 
> 
> -- 
> Oriol Demaria
> 2FFED630C16E4FF8
> 



Re: Xorg blanks until I switch to a TTY and back on 6.5

2019-05-01 Thread Jonathan Gray
On Wed, May 01, 2019 at 12:34:12PM -0300, Daniel Bolgheroni wrote:
> On Mon, Apr 29, 2019 at 07:05:25AM +0000, Jonathan Gray wrote:
> > Does this help?
> 
> It was already commited but fixed the problem here.
> 
> However, I still can't see the correct modes set for LVDS-1 and for the
> external monitor on HDMI-1. An ultrawide 2560x1080 monitor can see at most
> 1920x1080, but worked fine with the previous drm.

There is a change queued for the next 4.19 release which concerns the
modesetting xorg driver, I'm not sure if it is relevant:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/plain/queue-4.19/revert-drm-i915-fbdev-actually-configure-untiled-displays.patch

Index: sys/dev/pci/drm/i915/intel_fbdev.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_fbdev.c,v
retrieving revision 1.5
diff -u -p -r1.5 intel_fbdev.c
--- sys/dev/pci/drm/i915/intel_fbdev.c  14 Apr 2019 10:14:52 -  1.5
+++ sys/dev/pci/drm/i915/intel_fbdev.c  30 Apr 2019 07:38:31 -
@@ -380,8 +380,8 @@ static bool intel_fb_initial_config(stru
bool *enabled, int width, int height)
 {
struct drm_i915_private *dev_priv = to_i915(fb_helper->dev);
+   unsigned long conn_configured, conn_seq, mask;
unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
-   unsigned long conn_configured, conn_seq;
int i, j;
bool *save_enabled;
bool fallback = true, ret = true;
@@ -399,9 +399,10 @@ static bool intel_fb_initial_config(stru
drm_modeset_backoff();
 
memcpy(save_enabled, enabled, count);
-   conn_seq = GENMASK(count - 1, 0);
+   mask = GENMASK(count - 1, 0);
conn_configured = 0;
 retry:
+   conn_seq = conn_configured;
for (i = 0; i < count; i++) {
struct drm_fb_helper_connector *fb_conn;
struct drm_connector *connector;
@@ -414,8 +415,7 @@ retry:
if (conn_configured & BIT(i))
continue;
 
-   /* First pass, only consider tiled connectors */
-   if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
+   if (conn_seq == 0 && !connector->has_tile)
continue;
 
if (connector->status == connector_status_connected)
@@ -519,10 +519,8 @@ retry:
conn_configured |= BIT(i);
}
 
-   if (conn_configured != conn_seq) { /* repeat until no more are found */
-   conn_seq = conn_configured;
+   if ((conn_configured & mask) != mask && conn_configured != conn_seq)
goto retry;
-   }
 
/*
 * If the BIOS didn't enable everything it could, fall back to have the



Re: Xorg blanks until I switch to a TTY and back on 6.5

2019-04-29 Thread Jonathan Gray
On Sun, Apr 28, 2019 at 07:26:54PM -0400, Charles wrote:
> Hello list,
> 
> Ever since the new inteldrm driver got merged into -current, shortly
> before the 6.5 release, I'm seeing an odd new behavior on my Thinkpad
> T430 -- when an external display is connected, Xorg blanks all screens
> (but the mouse can still be seen) until I switch to a TTY and back with
> (i.e. C-A-F4 then C-A-F5) after which point it goes back to normal.
> 
> I'm glad the new inteldrm driver got merged, since it fixes several
> other video issues I was having. This problem is very minor since the
> workaround is just a few extra keystrokes when I dock or undock, but it
> is nevertheless annoying.
> 
> Is anyone else experiencing this issue on third gen core-I series Intel
> chips with integrated graphics? Or on any other chips for that matter?
> 
> I checked Xorg.0.log and didn't see anything suspicious. I also tried
> disabling monitor hotplugging via Xorg.conf, but I either did it wrong
> or it had no effect.
> 
> I would attach xorg logs and dmesg, but AFAIK misc@ does not allow
> attachments, and I don't want to annoy people with that much inline
> info.

Does this help?

Index: sys/dev/pci/drm/drm_fb_helper.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_fb_helper.c,v
retrieving revision 1.13
diff -u -p -r1.13 drm_fb_helper.c
--- sys/dev/pci/drm/drm_fb_helper.c 14 Apr 2019 10:14:51 -  1.13
+++ sys/dev/pci/drm/drm_fb_helper.c 29 Apr 2019 06:58:25 -
@@ -575,6 +575,9 @@ static bool drm_fb_helper_is_bound(struc
 #ifdef notyet
if (READ_ONCE(dev->master))
return false;
+#else
+   if (!SPLAY_EMPTY(>files))
+   return false;
 #endif
 
drm_for_each_crtc(crtc, dev) {



Re: some more info about ?? hangs

2019-04-27 Thread Jonathan Gray
On Sat, Apr 27, 2019 at 04:55:50PM +0300, Gregory Edigarov wrote:
> attached please find  dmesg and backtrace of X when that happen again
> hope this bug report will be more useful than previous one.
> 
> thank you.
> --
> With best regards,
>   Gregory Edigarov

Likely fixed by

xenocara/xserver/hw/xfree86/common/xf86VGAarbiterPriv.h


revision 1.9
date: 2019/04/28 03:12:53;  author: jsg;  state: Exp;  lines: +13 -7;  
commitid: gMqza1DBk6OCnvP4;
Backport cf7517675d988c2d1ff967d6d162a17acbdad46 from xserver 1.20
xfree86: Hold input_lock across SPRITE functions in VGA arbiter

Fixes stack overflow crash with VGA arbiter used with multi GPU systems.
Report and fix identified by 'Joe M' on misc@. ok matthieu@




Re: Patch for X crash on 6.4 and 6.5

2019-04-27 Thread Jonathan Gray
On Fri, Apr 26, 2019 at 11:57:14AM -0700, Joe M wrote:
> Hello,
> 
> I had this same issue with 6.4 and 6.5. Applying this patch has fixed
> the issue. I am using 2 radeon gpu's.
> 
> https://patchwork.freedesktop.org/series/28284/

Thanks for the report and tracking this down.  I've committed this patch
to xenocara in -current.

> 
> This is the gdb backtrace of the crashed core file.
> 
> joe:10201$ d gdb /usr/X11R6/bin/X Xorg.core
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-unknown-openbsd6.5"...
> Core was generated by `Xorg'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libpthread.so.26.1...done.
> Loaded symbols for /usr/lib/libpthread.so.26.1
> Loaded symbols for /usr/X11R6/bin/X
> Symbols already loaded for /usr/lib/libpthread.so.26.1
> Reading symbols from /usr/X11R6/lib/libpciaccess.so.2.0...done.
> Loaded symbols for /usr/X11R6/lib/libpciaccess.so.2.0
> Reading symbols from /usr/X11R6/lib/libdrm.so.7.6...done.
> Loaded symbols for /usr/X11R6/lib/libdrm.so.7.6
> Reading symbols from /usr/X11R6/lib/libpixman-1.so.36.0...done.
> Loaded symbols for /usr/X11R6/lib/libpixman-1.so.36.0
> Reading symbols from /usr/X11R6/lib/libXfont2.so.1.0...done.
> Loaded symbols for /usr/X11R6/lib/libXfont2.so.1.0
> Reading symbols from /usr/X11R6/lib/libfontenc.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libfontenc.so.4.0
> Reading symbols from /usr/X11R6/lib/libfreetype.so.29.0...done.
> Loaded symbols for /usr/X11R6/lib/libfreetype.so.29.0
> Reading symbols from /usr/lib/libz.so.5.0...done.
> Loaded symbols for /usr/lib/libz.so.5.0
> Reading symbols from /usr/X11R6/lib/libXau.so.10.0...done.
> Loaded symbols for /usr/X11R6/lib/libXau.so.10.0
> Reading symbols from /usr/X11R6/lib/libxshmfence.so.0.0...done.
> Loaded symbols for /usr/X11R6/lib/libxshmfence.so.0.0
> Reading symbols from /usr/X11R6/lib/libXdmcp.so.11.0...done.
> Loaded symbols for /usr/X11R6/lib/libXdmcp.so.11.0
> Reading symbols from /usr/lib/libkvm.so.17.0...done.
> Loaded symbols for /usr/lib/libkvm.so.17.0
> Reading symbols from /usr/lib/libm.so.10.1...done.
> Loaded symbols for /usr/lib/libm.so.10.1
> Reading symbols from /usr/lib/libc.so.95.0...done.
> Loaded symbols for /usr/lib/libc.so.95.0
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> Reading symbols from /usr/X11R6/lib/modules/extensions/libglx.so...done.
> Loaded symbols for /usr/X11R6/lib/modules/extensions/libglx.so
> Reading symbols from /usr/X11R6/lib/libGL.so.17.1...done.
> Loaded symbols for /usr/X11R6/lib/libGL.so.17.1
> Reading symbols from /usr/lib/libexpat.so.12.0...done.
> Loaded symbols for /usr/lib/libexpat.so.12.0
> Reading symbols from /usr/X11R6/lib/libxcb-dri3.so.0.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-dri3.so.0.1
> Reading symbols from /usr/X11R6/lib/libxcb-xfixes.so.1.2...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-xfixes.so.1.2
> Reading symbols from /usr/X11R6/lib/libxcb-present.so.0.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-present.so.0.1
> Reading symbols from /usr/X11R6/lib/libxcb-sync.so.1.2...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-sync.so.1.2
> Reading symbols from /usr/X11R6/lib/libglapi.so.0.2...done.
> Loaded symbols for /usr/X11R6/lib/libglapi.so.0.2
> Reading symbols from /usr/X11R6/lib/libXdamage.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libXdamage.so.4.0
> Reading symbols from /usr/X11R6/lib/libXfixes.so.6.0...done.
> Loaded symbols for /usr/X11R6/lib/libXfixes.so.6.0
> Reading symbols from /usr/X11R6/lib/libX11-xcb.so.2.0...done.
> Loaded symbols for /usr/X11R6/lib/libX11-xcb.so.2.0
> Reading symbols from /usr/X11R6/lib/libxcb-glx.so.1.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-glx.so.1.1
> Reading symbols from /usr/X11R6/lib/libxcb-dri2.so.1.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-dri2.so.1.1
> Reading symbols from /usr/X11R6/lib/libXxf86vm.so.6.0...done.
> Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.6.0
> Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done.
> Loaded symbols for /usr/X11R6/lib/libXext.so.13.0
> Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done.
> Loaded symbols for /usr/X11R6/lib/libX11.so.16.1
> Reading symbols from /usr/X11R6/lib/libxcb.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libxcb.so.4.0
> Reading symbols from /usr/X11R6/lib/modules/drivers/radeon_drv.so...done.
> Loaded symbols for /usr/X11R6/lib/modules/drivers/radeon_drv.so
> Reading symbols from /usr/X11R6/lib/libdrm_radeon.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libdrm_radeon.so.4.0
> Reading symbols from /usr/X11R6/lib/libgbm.so.0.3...done.
> 

Re: current snapshot kernel uvm fault radeondrm firmware not found

2019-04-19 Thread Jonathan Gray
On Sat, Apr 20, 2019 at 12:58:06AM +0300, Mihai Popescu wrote:
> Here is the error message part:
> 
> initializing kernel modesetting (Rs880 0x1002:0x9715 0x17AA:0x3082 0x00).
> r600_cp: Failed to load firmware "radeon/RS780_pfp.bin"
> [drm] *ERROR* Failed to load firmware!
> drm:pid0: radeondrm_attachhook *ERROR* Fatal error during GPU init
> uvm_fault(0x81dc5468, 0x12, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at config_detach+0x9d: movzwl 0x12(%rax),%ecx
> ddb{0}>_
> 
> I clipped the first lines of dmesg, by mistake, so here they are:
> 
> OpenBSD 6.5-current (GENERIC.MP) #7: Fri Apr 19 12:10:14 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8029429760 (7657MB)
> avail mem = 7775989760 (7415MB)
> mpath0 at root
> 
> Thank you.
> 

Thanks for the report.  Fixed in radeon_kms.c rev 1.60.



Re: GMA500 drivers

2019-03-25 Thread Jonathan Gray
On Mon, Mar 25, 2019 at 07:50:30AM +, Maurice McCarthy wrote:
> On 23/03/2019, Normen Wohner  wrote:
> > I have now successfully installed OpenBSD
> > on my Netbook, however Graphics performance
> > is abysmal.
> > I know that sadly Linux uses binary blobs for
> > the GMA500 as it is a licensed Powervr chip.
> > Any idea on how to "maybe" get faster graphics
> > working?
> > I'm willing to do the legwork.
> >
> 
> I assume you've tried fw_update to attempt from firmware.openbsd.org ?!
> 
> As it is not listed in man 4 intel (don't know how up to date that is)
> maybe someone is already porting the firmware driver from freebsd.
> Otherwise I'd guess you would have to port a linux driver yourself.
> 
> Best Wishes
> 

There is a GPLv2 driver in linux.
"experimental 2D KMS framebuffer driver for the Intel GMA500 ('Poulsbo')
and other Intel IMG based graphics devices"

No one is looking at adding support for obscure Intel PowerVR parts from
over ten years ago with no documentation and incomplete and badly
licensed code.  Running fw_update won't change that.



Re: No network with latest snap (5jan-19)

2019-01-05 Thread Jonathan Gray
On Sat, Jan 05, 2019 at 03:39:34PM +0100, Christer Solskogen wrote:
> On my APU2 I got no network with the latest snap.
> 
> I get this in the console:
> starting network
> ifconfig: SIOCSETPFSYNC: Invalid argument
> ifconfig: SIOCSVH: Invalid argument
> ifconfig: SIOCSETPFSYNC: Invalid argument
> 
> OpenBSD 6.4-current (GENERIC.MP) #562: Sat Jan  5 04:37:18 MST 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

I made a mistake in an em(4) commit.  Should be fixed in the next snapshot.



Re: X server gbm: failed to open any driver

2018-12-03 Thread Jonathan Gray
On Mon, Dec 03, 2018 at 08:06:18PM +0300, Denis wrote:
> When X server starts on OpenBSD6.4amd64 I'm getting the message below
> 
> ...
> (II) [KMS] Kernel modesetting enabled.
> gbm: failed to open any driver (search paths /usr/X11R6/lib/modules/dri)
> gbm: Last dlopen error: File not found
> failed to load driver: redeonsi
> EGL_MESA_drm_image required.
> spectrwm: Welcome to spectrwm ...
> 
> Can it be fixed?
> 

As the radeonsi Mesa driver depends on libLLVM and libelf it can not
currently be included in the xenocara sets.

With -current using Mesa 17.3.9 in xenocara and LLVM 6.0 from ports it
is possible to build it yourself.

Install libelf and llvm packages, apply the below patch and then build
xenocara.

Index: lib/mesa/Makefile.bsd-wrapper
===
RCS file: /cvs/xenocara/lib/mesa/Makefile.bsd-wrapper,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile.bsd-wrapper
--- lib/mesa/Makefile.bsd-wrapper   23 Oct 2018 06:35:32 -  1.21
+++ lib/mesa/Makefile.bsd-wrapper   4 Dec 2018 02:44:28 -
@@ -11,7 +11,7 @@ GALLIUM_DRIVERS=  swrast
 
 .if ${MACHINE} == i386 || ${MACHINE} == amd64
 DRI_DRIVERS=swrast,radeon,r200,i915,i965
-GALLIUM_DRIVERS=swrast,r300,r600
+GALLIUM_DRIVERS=swrast,r300,r600,radeonsi
 .endif
 
 .if ${MACHINE} == arm64 || ${MACHINE} == loongson || \
@@ -23,7 +23,8 @@ GALLIUM_DRIVERS=swrast,r300,r600
 CONFIGURE_ARGS=--with-dri-drivers=${DRI_DRIVERS} \
--with-gallium-drivers=${GALLIUM_DRIVERS} \
--disable-silent-rules \
-   --disable-llvm \
+   --enable-llvm \
+   --with-llvm-prefix=/usr/local \
--disable-glx-tls \
--disable-regen-sources \
--enable-gles1 --enable-gles2 \
@@ -70,6 +71,25 @@ O2= ${O1} -fthread-jumps -fcrossjumping 
 
 CONFIGURE_ARGS+=   USER_CFLAGS="-O0 ${O2}"
 .endif
+
+PKGCONFIG_LIBDIR=  
/usr/lib/pkgconfig:${X11BASE}/lib/pkgconfig:/usr/local/lib/pkgconfig
+
+XENOCARA_PATH= /bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
+
+config.status:
+   PKG_CONFIG_LIBDIR="${PKGCONFIG_LIBDIR}" \
+   CONFIG_SITE=$(CONFIG_SITE) \
+   CC=${CC} \
+   CFLAGS="${CFLAGS}" \
+   CXX=${CXX} \
+   CXXFLAGS="${CXXFLAGS}" \
+   AR_FLAGS="cruD" \
+   MAKE="${MAKE}" \
+   PATH=$(XENOCARA_PATH) \
+   sh ${_SRCDIR}/configure --prefix=${X11BASE} \
+   --sysconfdir=/etc \
+   --mandir=${X11BASE}/man \
+   ${CONFIGURE_ARGS}
 
 ${.OBJDIR}/src/util/format_srgb.c:
lndir -s -e obj -e obj.${MACHINE_ARCH} -e Makefile.bsd-wrapper 
${.CURDIR}



Re: OpenBSD/landisk on J-core/J2 based systems?

2018-12-03 Thread Jonathan Gray
On Mon, Dec 03, 2018 at 01:16:09PM -0500, Charles A Daniels wrote:
> I'm curious to know if anyone involved with OpenBSD/landisk has any
> comments on J-core[1]? It claims to implement SuperH and capability to
> boot Linux on an FPGA.
> 
> To that end, has anyone tried booting OpenBSD/landisk on a J2 based
> system?
> 
> One of my hobbies is obscure architectures, and OpenBSD/landisk seemed
> like and interesting one; I stumbled across J-core while researching for
> background on the SH-4 CPU. It seems like targeting (relatively) readily
> available FPGA development boards would make SuperH compatible systems
> much more accessible to those interested in the landisk port.
> 
> 1 - http://j-core.org/

A MMU is required to run OpenBSD.



Re: radeondrm failure on amd64 but not on i386?

2018-11-25 Thread Jonathan Gray
On Mon, Nov 19, 2018 at 08:37:01AM -0700, Andy Bradford wrote:
> Thus said Jonathan Gray on Mon, 19 Nov 2018 20:42:46 +1100:
> 
> > > Thanks for the suggestion. Here's the additional output provided by your
> > > patch:
> > > 
> > > radeon_atrm_get_bios false
> > > radeon_acpi_vfct_bios false
> > > igp_read_bios_from_vram false
> > > radeon_read_bios false
> > > radeon_read_disabled_bios true
> > > drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> > > drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> > > [TTM] Memory type 2 has not been initialized
> > > drm0 detached
> > > radeondrm0 detached
> > 
> > Thanks, could you also show the i386 output with the patch?
> 
> The output on i386 looks pretty much the same except for the failure:
> 
> initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02).
> radeon_atrm_get_bios false
> radeon_acpi_vfct_bios false
> igp_read_bios_from_vram false
> radeon_read_bios false
> radeon_read_disabled_bios true
> radeondrm0: 1680x1050, 32bpp
> wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0

r600_read_disabled_bios is just doing register reads/writes it isn't
clear to me why that would be different between amd64 and i386.



Re: radeondrm failure on amd64 but not on i386?

2018-11-19 Thread Jonathan Gray
On Sun, Nov 18, 2018 at 10:47:10PM -0700, Andy Bradford wrote:
> Thus said Jonathan Gray on Sat, 17 Nov 2018 14:08:53 +1100:
> 
> > There are many  ways of getting an  atom bios it would  be helpfull to
> > know which method is having trouble.
> 
> Thanks for the suggestion. Here's the additional output provided by your
> patch:
> 
> radeon_atrm_get_bios false
> radeon_acpi_vfct_bios false
> igp_read_bios_from_vram false
> radeon_read_bios false
> radeon_read_disabled_bios true
> drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> [TTM] Memory type 2 has not been initialized
> drm0 detached
> radeondrm0 detached

Thanks, could you also show the i386 output with the patch?
You can build an i386 kernel on amd64 if that helps.



Re: radeondrm failure on amd64 but not on i386?

2018-11-16 Thread Jonathan Gray
On Thu, Nov 15, 2018 at 09:15:48PM -0700, Andy Bradford wrote:
> Hello,
> 
> I  recently installed  OpenBSD 6.4  amd64  and radeondrm  fails to  load
> properly. I then  installed OpenBSD 6.4 i386 on the  same hardware (to a
> USB pendrive) and it works fine. Any ideas?

There are many ways of getting an atom bios it would be helpfull to know
which method is having trouble.

Index: sys/dev/pci/drm/radeon/radeon_bios.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_bios.c,v
retrieving revision 1.14
diff -u -p -r1.14 radeon_bios.c
--- sys/dev/pci/drm/radeon/radeon_bios.c25 Aug 2018 18:42:43 -  
1.14
+++ sys/dev/pci/drm/radeon/radeon_bios.c17 Nov 2018 03:00:34 -
@@ -801,16 +801,27 @@ bool radeon_get_bios(struct radeon_devic
uint16_t tmp;
 
r = radeon_atrm_get_bios(rdev);
-   if (r == false)
+printf("radeon_atrm_get_bios %s\n", r == true ? "true" : "false");
+   if (r == false) {
r = radeon_acpi_vfct_bios(rdev);
-   if (r == false)
+printf("radeon_acpi_vfct_bios %s\n", r == true ? "true" : "false");
+   }
+   if (r == false) {
r = igp_read_bios_from_vram(rdev);
-   if (r == false)
+printf("igp_read_bios_from_vram %s\n", r == true ? "true" : "false");
+   }
+   if (r == false) {
r = radeon_read_bios(rdev);
-   if (r == false)
+printf("radeon_read_bios %s\n", r == true ? "true" : "false");
+   }
+   if (r == false) {
r = radeon_read_disabled_bios(rdev);
-   if (r == false)
+printf("radeon_read_disabled_bios %s\n", r == true ? "true" : "false");
+   }
+   if (r == false) {
r = radeon_read_platform_bios(rdev);
+printf("radeon_read_platform_bios %s\n", r == true ? "true" : "false");
+   }
if (r == false || rdev->bios == NULL) {
DRM_ERROR("Unable to locate a BIOS ROM\n");
rdev->bios = NULL;



Re: Keyboard repeats characters way to often

2018-09-18 Thread Jonathan Gray
On Wed, Sep 19, 2018 at 03:03:12AM +0200, Leo Unglaub wrote:
> > > The only big problem I have is that as soon as I start X I cannot use the
> > > keyboard correctly. Every time I type a character on the keyboard it gets
> > > repeated multiple times. Most often it gets repeated between 3 and 7 
> > > times.
> > > Do you have any idea what I could to in order to fix/debug this?
> > Could be tsc desync.
> > 
> > Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0
> > 
> 
> thank you very much! The sysctl kern.timecounter.hardware=acpih option fixed
> the issue for me!
> 
> Thank you very much!
> Greetings
> Leo
> 

I had hoped it was gone with zen/17h.  As it is very inconsistent as to
which systems have this problem (ie 16h apu laptop has the problem,
16h pcengines apu2 doesn't) we need to test if tsc is desynchronised
on boot.

Here is the old big hammer diff I had extended for 17h but I don't want
to force hpet in cases where tsc is not desynchronised between cores.

Index: tsc.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/tsc.c,v
retrieving revision 1.10
diff -u -p -r1.10 tsc.c
--- tsc.c   27 Jul 2018 21:11:31 -  1.10
+++ tsc.c   19 Sep 2018 01:16:24 -
@@ -32,6 +32,7 @@ int   tsc_recalibrate;
 
 uint64_t   tsc_frequency;
 inttsc_is_invariant;
+inttsc_desync;
 
 uint   tsc_get_timecount(struct timecounter *tc);
 
@@ -172,7 +173,7 @@ calibrate_tsc_freq(void)
return;
tsc_frequency = freq;
tsc_timecounter.tc_frequency = freq;
-   if (tsc_is_invariant)
+   if (tsc_is_invariant && tsc_desync == 0)
tsc_timecounter.tc_quality = 2000;
 }
 
@@ -206,10 +207,25 @@ tsc_timecounter_init(struct cpu_info *ci
tsc_frequency = tsc_freq_cpuid(ci);
tsc_is_invariant = 1;
 
+#ifdef MULTIPROCESSOR
+   /*
+* TSC often desynchronised between cores on
+* 15h (Bulldozer, Piledriver, Steamroller, Excavator)
+* 16h (Jaguar, Puma)
+* 17h (Zen)
+*/
+   if ((strcmp(cpu_vendor, "AuthenticAMD") == 0) &&
+   ((ci->ci_family == 0x15 && ci->ci_model <= 0x6f) ||
+(ci->ci_family == 0x16 && ci->ci_model <= 0x3f) ||
+(ci->ci_family == 0x17 && ci->ci_model <= 0x1f)))
+   tsc_desync = 1;
+#endif
+
/* Newer CPUs don't require recalibration */
if (tsc_frequency > 0) {
tsc_timecounter.tc_frequency = tsc_frequency;
-   tsc_timecounter.tc_quality = 2000;
+   if (tsc_desync == 0)
+   tsc_timecounter.tc_quality = 2000;
} else {
tsc_recalibrate = 1;
tsc_frequency = cpufreq;



Re: Keyboard repeats characters way to often

2018-09-18 Thread Jonathan Gray
On Wed, Sep 19, 2018 at 12:27:29AM +0200, Leo Unglaub wrote:
> Hi,
> today I got my new Laptop. A Lenovo ThinkPad E485 with an AMD Ryzen CPU. I
> installed the latest OpenBSD -current on the device and a lot of stuff work
> very well. I used the traditional installation method without EFI. Only Wifi
> and Hybernate/Suspend don't work, but that was expected and is okay.
> 
> The only big problem I have is that as soon as I start X I cannot use the
> keyboard correctly. Every time I type a character on the keyboard it gets
> repeated multiple times. Most often it gets repeated between 3 and 7 times.
> Do you have any idea what I could to in order to fix/debug this?

Could be tsc desync.

Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0

> 
> I attach you a dmesg of the machine. Also here is some additional
> information that might help.
> 
> > # wsconsctl
> > keyboard.type=pc-xt
> > keyboard.bell.pitch=400
> > keyboard.bell.period=100
> > keyboard.bell.volume=50
> > keyboard.bell.pitch.default=400
> > keyboard.bell.period.default=100
> > keyboard.bell.volume.default=50
> > wsconsctl: Use explicit arg to view keyboard.map.
> > keyboard.repeat.del1=400
> > keyboard.repeat.deln=100
> > keyboard.repeat.del1.default=400
> > keyboard.repeat.deln.default=100
> > keyboard.ledstate=0
> > keyboard.encoding=us
> > mouse.type=synaptics
> > mouse.rawmode=0
> > mouse.scale=1266,5676,1162,4690,0,45,54
> > mouse.tp.tapping=0
> > mouse.tp.scaling=0.163
> > mouse.tp.swapsides=0
> > mouse.tp.disable=0
> > mouse.tp.edges=0.0,5.0,10.0,5.0
> > mouse1.type=ps2
> > display.type=vga-pci
> > display.emulations=vt100
> > display.screentypes=80x25,80x25bf,80x40,80x40bf,80x50,80x50bf
> > display.focus=0
> > display.brightness=100.00%
> > display.screen_on=250
> > display.screen_off=0
> > display.vblank=off
> > display.kbdact=on
> > display.msact=on
> > display.outact=on
> 
> I use the latest version of -current that I could find. I am on AMD64.
> 
> Thanks so much for any hints.
> Greetings
> Leo
> 
> > $ dmesg
> > OpenBSD 6.4-beta (GENERIC.MP) #302: Tue Sep 18 10:01:39 MDT 2018
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 16622096384 (15852MB)
> > avail mem = 16109076480 (15362MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x986e9000 (62 entries)
> > bios0: vendor LENOVO version "R0UET52W (1.32 )" date 09/01/2018
> > bios0: LENOVO 20KUCTO1WW
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP SSDT SSDT CRAT CDIT SSDT TPM2 UEFI MSDM BATB HPET 
> > APIC MCFG SBST IVRS FPDT SSDT SSDT SSDT UEFI SSDT
> > acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) GPP5(S3) 
> > GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) SLPB(S3)
> > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > acpihpet0 at acpi0: 14318180 Hz
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx, 2196.25 MHz, 17-11-00
> > cpu0: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
> > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 24MHz
> > cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> > cpu1 at mainbus0: apid 1 (application processor)
> > cpu1: AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx, 2195.85 MHz, 17-11-00
> > cpu1: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
> > cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu1: smt 1, core 0, package 0
> > cpu2 at mainbus0: apid 2 (application 

Re: Can't open /dev/bio on arm

2018-08-05 Thread Jonathan Gray
On Sun, Aug 05, 2018 at 10:39:10AM +0200, Janne Johansson wrote:
> Is there MAKEDEV things to add also?

No, the MAKEDEV and conf.c parts are already there.

It should be possible to use softraid with ramdisks on arm* with future
snapshots, just not as a boot volume.



Re: Can't open /dev/bio on arm

2018-08-05 Thread Jonathan Gray
On Sat, Aug 04, 2018 at 06:38:20PM +1000, Jonathan Gray wrote:
> On Sat, Aug 04, 2018 at 05:37:11PM +1000, Jonathan Gray wrote:
> > On Sat, Aug 04, 2018 at 09:33:45AM +0300, Kihaguru Gathura wrote:
> > > Hi,
> > > 
> > > I am getting message:  bioctl: Can't open /dev/bio: Device not configured
> > > 
> > > No clue whatsoever on how to go about this. Please assist.
> > > 
> > > Instructions
> > > --
> > > almandine# fdisk -iy sd0
> > > Writing MBR at offset 0.
> > > almandine# fdisk -iy sd1
> > > Writing MBR at offset 0.
> > > almandine# disklabel -E sd0
> > > Label editor (enter '?' for help at any prompt)
> > > > a
> > > partition: [a]
> > > offset: [64]
> > > size: [15727571] *
> > > FS type: [4.2BSD] RAID
> > > > w
> > > > q
> > > No label changes.
> > > almandine# disklabel sd0 > layout
> > > almandine# disklabel -R sd1 layout
> > > almandine# rm layout
> > > almandine# bioctl -c 1 -l sd0a,sd1a softraid0
> > > bioctl: Can't open /dev/bio: Device not configured
> > > --
> > 
> > softraid is not currently built as part of the ramdisk kernel on arm*
> > also the case for landisk, loongson, luna88k, octeon, sgi, socppc
> 
> bio as well

And then someone needs to add support to armv7/arm64 efiboot to be able
to boot from it like amd64, i386 and sparc64 can.



Re: Can't open /dev/bio on arm

2018-08-04 Thread Jonathan Gray
On Sat, Aug 04, 2018 at 05:37:11PM +1000, Jonathan Gray wrote:
> On Sat, Aug 04, 2018 at 09:33:45AM +0300, Kihaguru Gathura wrote:
> > Hi,
> > 
> > I am getting message:  bioctl: Can't open /dev/bio: Device not configured
> > 
> > No clue whatsoever on how to go about this. Please assist.
> > 
> > Instructions
> > --
> > almandine# fdisk -iy sd0
> > Writing MBR at offset 0.
> > almandine# fdisk -iy sd1
> > Writing MBR at offset 0.
> > almandine# disklabel -E sd0
> > Label editor (enter '?' for help at any prompt)
> > > a
> > partition: [a]
> > offset: [64]
> > size: [15727571] *
> > FS type: [4.2BSD] RAID
> > > w
> > > q
> > No label changes.
> > almandine# disklabel sd0 > layout
> > almandine# disklabel -R sd1 layout
> > almandine# rm layout
> > almandine# bioctl -c 1 -l sd0a,sd1a softraid0
> > bioctl: Can't open /dev/bio: Device not configured
> > --
> 
> softraid is not currently built as part of the ramdisk kernel on arm*
> also the case for landisk, loongson, luna88k, octeon, sgi, socppc

bio as well

Index: sys/arch/armv7/conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v
retrieving revision 1.103
diff -u -p -r1.103 RAMDISK
--- sys/arch/armv7/conf/RAMDISK 3 Aug 2018 13:37:08 -   1.103
+++ sys/arch/armv7/conf/RAMDISK 4 Aug 2018 08:36:08 -
@@ -30,6 +30,7 @@ configbsd root on rd0a swap on rd0b
 
 # The main bus device
 mainbus0   at root
+softraid0  at root
 simplebus* at fdt?
 cpu0   at mainbus?
 
@@ -266,3 +268,4 @@ pseudo-device   openprom
 pseudo-device  loop 1
 pseudo-device  bpfilter 1
 pseudo-device  rd 1
+pseudo-device  bio 1
Index: sys/arch/arm64/conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/arm64/conf/RAMDISK,v
retrieving revision 1.66
diff -u -p -r1.66 RAMDISK
--- sys/arch/arm64/conf/RAMDISK 3 Aug 2018 13:37:08 -   1.66
+++ sys/arch/arm64/conf/RAMDISK 4 Aug 2018 08:36:08 -
@@ -46,6 +46,7 @@ configbsd root on rd0a swap on rd0b
 
 # The main bus device
 mainbus0   at root
+softraid0  at root
 cpu0   at mainbus?
 efi0   at mainbus?
 acpi0  at mainbus?
@@ -244,3 +245,4 @@ rkpmic* at iic? # RK808 PMIC
 pseudo-device  loop 1
 pseudo-device  bpfilter 1
 pseudo-device  rd 1
+pseudo-device  bio 1



Re: Can't open /dev/bio on arm

2018-08-04 Thread Jonathan Gray
On Sat, Aug 04, 2018 at 09:33:45AM +0300, Kihaguru Gathura wrote:
> Hi,
> 
> I am getting message:  bioctl: Can't open /dev/bio: Device not configured
> 
> No clue whatsoever on how to go about this. Please assist.
> 
> Instructions
> --
> almandine# fdisk -iy sd0
> Writing MBR at offset 0.
> almandine# fdisk -iy sd1
> Writing MBR at offset 0.
> almandine# disklabel -E sd0
> Label editor (enter '?' for help at any prompt)
> > a
> partition: [a]
> offset: [64]
> size: [15727571] *
> FS type: [4.2BSD] RAID
> > w
> > q
> No label changes.
> almandine# disklabel sd0 > layout
> almandine# disklabel -R sd1 layout
> almandine# rm layout
> almandine# bioctl -c 1 -l sd0a,sd1a softraid0
> bioctl: Can't open /dev/bio: Device not configured
> --

softraid is not currently built as part of the ramdisk kernel on arm*
also the case for landisk, loongson, luna88k, octeon, sgi, socppc

Index: sys/arch/armv7/conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v
retrieving revision 1.103
diff -u -p -r1.103 RAMDISK
--- sys/arch/armv7/conf/RAMDISK 3 Aug 2018 13:37:08 -   1.103
+++ sys/arch/armv7/conf/RAMDISK 4 Aug 2018 07:30:38 -
@@ -30,6 +30,7 @@ configbsd root on rd0a swap on rd0b
 
 # The main bus device
 mainbus0   at root
+softraid0  at root
 simplebus* at fdt?
 cpu0   at mainbus?
 
Index: sys/arch/arm64/conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/arm64/conf/RAMDISK,v
retrieving revision 1.66
diff -u -p -r1.66 RAMDISK
--- sys/arch/arm64/conf/RAMDISK 3 Aug 2018 13:37:08 -   1.66
+++ sys/arch/arm64/conf/RAMDISK 4 Aug 2018 07:30:38 -
@@ -46,6 +46,7 @@ configbsd root on rd0a swap on rd0b
 
 # The main bus device
 mainbus0   at root
+softraid0  at root
 cpu0   at mainbus?
 efi0   at mainbus?
 acpi0  at mainbus?



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-26 Thread Jonathan Gray
On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote:
> 
> > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote:
> >> drivers/gpu/drm/amd in linux has over 1.5 million lines of code.  Which
> >> is multiple times larger than the complete OpenBSD kernel source...
> 
> Thanks for this update!
> 
> Just to clarify, before I spend a bunch of money on new hardware, should I
> be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort with
> this updated driver?
> 
> Thanks again,

It appears that 'R7 250' can mean either a cape verde or oland radeon
depending on the model.  Both are GCN parts.

4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0
Both claim support for displayport 1.2 which should be able to do
4k 60Hz.  HDMI 2.0 seems to only be on later hardware with DCE >= 11
carrizo (not carrizo-l which is mullins), polaris etc.

With the low end radeons displayport is sometimes only available on
oem models of cards sold as options for systems marketed as business
desktops or workstations.

And as mentioned earlier for acceleration you'll currently have to build
a different version of Mesa than what OpenBSD releases/snapshots ship
with.



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-25 Thread Jonathan Gray
On Wed, Apr 25, 2018 at 03:10:15AM -0400, Joseph Mayer wrote:
> Hi!
> 
> Radeon drivers are specific per Radeon microarchitecture and Radeon
> microarchitecture version. 
> 
> The Radeon microarchitectures to date are TS 1, TS 2, TS 3, GCN 1, GCN
> 2, GCN 3, GCN 4, GCN 5 (TS = TeraScale and GCN = Graphics Core Next),
> in that ascending chronological order. [1]

Terascale is r600, so there are more than just that.
The drivers in Mesa are radeon (r100), r200, r300, r600, radeonsi.

> 
> 
> First, thank you very much jsg@ for that you committed full OpenBSD
> kernel support for the radeondrm(4) driver today! [2]
> 
> Previously, while Xorg's radeondrm(4) driver supported all cards up to
> GCN 2, OpenBSD's kernel supported the Radeons up to GCN 1 only. The
> radeon(4) man page listed all cards up to GCN 2, but only the cards up
> to GCN 1 were actually supported by OpenBSD.
> 
> jsg@'s diff today extends radeondrm(4) to support Radeons up to GCN 2.

It is worth reiterating that there is no self contained 2d acceleration
in the xorg driver for GCN/radeonsi parts.

Acceleration is only via glamor and requires Mesa to work.
The radeonsi driver in Mesa is not built as it has build time and run
time dependencies on libLLVM and libelf which are not in src or xenocara.
And to use libLLVM from LLVM 6.0 a newer version of Mesa than what is in
the xenocara tree is required (ie 17.3).  Mesa 17.x triggers some kind of
graphical corruption on Intel hardware for reasons still unclear so
xenocara remains on Mesa 13.0.6.

> 
> 
> The major move with Radeon graphics cards today, is their move from the
> radeondrm(4) driver (called "xf86-video-ati" by Xorg and "radeon" on
> Linux) [3], to the "amdgpu" driver (called "xf86-video-amdgpu" by Xorg)
> [4].
> 
> All new Radeon are driven by the amdgpu driver:
> 
> The radeondrm driver supports all Radeon cards up to and including GCN
> 2. GCN 2 was released 2013 and the last GCN 2 card was released 2015.
> No more GCN 2 cards will be coming.

Parts get rebadged through multiple generations of marketing names,
especially on the low end.

> 
> The amdgpu driver supports all new Radeon cards from GCN 1.2 and up.

There are build time options for 'enable experimental support for SI asics'
and 'enable support for CIK asics' which seem to not be the default.

> 
> This means the amdgpu driver is needed for GCN 3 and newer Radeons, and
> GCN 3 cards started coming to the market 2014.
> 
> amdgpu(4) has not been ported to OpenBSD yet. [5]
> 
> 
> I am not perfectly clear about the max feature set in the GCN 2 cards,
> maybe I will make a post later about what you can and cannot do with
> amdgpu(4) (not yet ported) vs. radeondrm(4) cards, however more modern
> features like Displayport 1.4 and 1.3 support, support for higher
> resolutions, MST (Multi-Stream Transport), newer video codecs with
> higher resolutions etc., appear to be only in the newer GCN 5 and GCN 4
> cards, which are supported only by the amdgpu driver.

There are MST parts in radeondrm though they may be experimental.
Many of the GCN parts covered by radeondrm are advertised as being able
to support 4k SST/MST on displayport.

> 
> The Radeon GPU:s are important in OpenBSD's ecosystem as they are the
> only way to increase graphics functionality, that not involves changing
> CPU to Intel's latest, and hence change motherboard and other hardware.
> 
> 
> Do you have plans to port amdgpu?
> 
> Would particular hardware donations or other donations be of help?

I have no plans regarding amdgpu.

Most people seem to be interested from the point of view of polaris/vega
which are not supported in linux 4.4.  Ignoring the parts of the shared
drm/ttm code that would have to be updated the latest
drivers/gpu/drm/amd in linux has over 1.5 million lines of code.  Which
is multiple times larger than the complete OpenBSD kernel source...



Re: pine64-lts - can't detect disk

2018-04-13 Thread Jonathan Gray
On Fri, Apr 13, 2018 at 11:05:06AM -0700, jungle Boogie wrote:
> On 13 April 2018 at 09:39, Jonathan Gray <j...@jsg.id.au> wrote:
> > On Fri, Apr 13, 2018 at 09:19:23AM -0700, jungle Boogie wrote:
> >> On 13 April 2018 at 08:30, jungle Boogie <jungleboog...@gmail.com> wrote:
> >> > Hi All,
> >> >
> >> > So between Peter Hessler's post here:
> >> > https://bsd.network/@phessler/99389809617980837
> >> >
> >> > And the install instructions for arm64:
> >> > https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/INSTALL.arm64
> >> >
> >> > I have the pine64-lts:
> >> > https://www.pine64.org/?page_id=46823
> >>
> >>
> >> Forgot the dmesg:
> >>
> >> OpenBSD 6.3-current (RAMDISK) #235: Thu Apr 12 14:38:28 MDT 2018
> >> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
> >> real mem  = 2015993856 (1922MB)
> >> avail mem = 1915539456 (1826MB)
> >> mainbus0 at root: Pine64+
> >
> > The sopine U-Boot image does not currently include the sopine device
> > tree as there isn't a sopine device tree in U-Boot.
> >
> > Until that changes, on the msdos/efi partition create an 'allwinner'
> > directory, install the dtb port and copy
> > /usr/local/share/dtb/arm64/allwinner/sun50i-a64-sopine-baseboard.dtb
> > to
> > allwinner/sun50i-a64-pine64-plus.dtb
> >
> > or to a different path and change fdtfile in the U-Boot environment.
> >
> > Though it isn't clear if that is the appropriate device tree.
> >
> 
> Thanks for the reply. I think I'm closer, but there still seems to be
> some gaps...
> 
> my sd card:
> $ ls /mnt/allwinner/
> sun50i-a64-pine64-plus.dtb
> 
> 
> => run findfdt
> ## Error: "findfdt" not defined
> => load mmc 0:1 ${fdt_addr_r} allwinner/sun50i-a64-pine64-plus.dtb
> 12734 bytes read in 35 ms (354.5 KiB/s)
> => load mmc 0:1 ${kernel_addr_r} efi/boot/bootaa64.efi
> 98588 bytes read in 43 ms (2.2 MiB/s)
> => bootefi ${kernel_addr_r} ${fdt_addr_r}

You shouldn't have to explicitly run bootefi as the target supports what
U-Boot calls 'generic distro boot' which will load a dtb and run bootefi
automatically.

If you were to keep the original dtb name you would have to do something
like

setenv fdtfile allwinner/sun50i-a64-sopine-baseboard.dtb
saveenv
boot

Until such time that the U-Boot patch series for it gets merged/released:
https://patchwork.ozlabs.org/patch/885574/



Re: pine64-lts - can't detect disk

2018-04-13 Thread Jonathan Gray
On Fri, Apr 13, 2018 at 09:19:23AM -0700, jungle Boogie wrote:
> On 13 April 2018 at 08:30, jungle Boogie  wrote:
> > Hi All,
> >
> > So between Peter Hessler's post here:
> > https://bsd.network/@phessler/99389809617980837
> >
> > And the install instructions for arm64:
> > https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/INSTALL.arm64
> >
> > I have the pine64-lts:
> > https://www.pine64.org/?page_id=46823
> 
> 
> Forgot the dmesg:
> 
> OpenBSD 6.3-current (RAMDISK) #235: Thu Apr 12 14:38:28 MDT 2018
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
> real mem  = 2015993856 (1922MB)
> avail mem = 1915539456 (1826MB)
> mainbus0 at root: Pine64+

The sopine U-Boot image does not currently include the sopine device
tree as there isn't a sopine device tree in U-Boot.

Until that changes, on the msdos/efi partition create an 'allwinner'
directory, install the dtb port and copy
/usr/local/share/dtb/arm64/allwinner/sun50i-a64-sopine-baseboard.dtb
to
allwinner/sun50i-a64-pine64-plus.dtb

or to a different path and change fdtfile in the U-Boot environment.

Though it isn't clear if that is the appropriate device tree.

> cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
> efi0 at mainbus0: UEFI 2.7
> efi0: Das U-Boot rev 0x0
> psci0 at mainbus0: PSCI 0.2
> agtimer0 at mainbus0: tick rate 24000 KHz
> simplebus0 at mainbus0: "soc"
> sxiccmu0 at simplebus0
> sxipio0 at simplebus0: 103 pins
> ampintc0 at simplebus0 nirq 224, ncpu 4: "interrupt-controller"
> sxiccmu1 at simplebus0
> sxipio1 at simplebus0: 13 pins
> sximmc0 at simplebus0
> sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
> ehci0 at simplebus0
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev
> 2.00/1.00 addr 1
> com0 at simplebus0: ns16550, no working fifo
> com0: console
> sxitwi0 at simplebus0
> iic0 at sxitwi0
> sxirtc0 at simplebus0
> dwxe0 at simplebus0: address 02:ba:43:50:f0:a3
> rgephy0 at dwxe0 phy 0: RTL8169S/8110S/8211 PHY, rev. 5
> rgephy1 at dwxe0 phy 1: RTL8169S/8110S/8211 PHY, rev. 5
> gpio0 at sxipio0: 32 pins
> gpio1 at sxipio0: 32 pins
> gpio2 at sxipio0: 32 pins
> gpio3 at sxipio0: 32 pins
> gpio4 at sxipio0: 32 pins
> gpio5 at sxipio0: 32 pins
> gpio6 at sxipio0: 32 pins
> gpio7 at sxipio0: 32 pins
> gpio8 at sxipio1: 32 pins
> bootfile: sd0a:/bsd
> boot device: lookup sd0a:/bsd failed
> root on rd0a swap on rd0b dump on rd0b
> 



Re: 6.3 : how to check microcode?

2018-04-03 Thread Jonathan Gray
On Tue, Apr 03, 2018 at 01:36:57PM +0200, Maurice Janssen wrote:
> Hi,
> 
> I just installed 6.3 and it seems to work great.
> I've a question about the microcode. Is there a way to check whether an
> updated microcode was installed??? I have an i5 Ivybridge CPU and the Intel
> microcode is in /etc/firmware/intel, but I don't see anything in dmesg about
> it.

The messages regarding microcode versions are gated by UCODE_DEBUG.
You have IBRS,IBPB,STIBP in cpuid so you are running the updated microcode.

> 
> Thanks in advance,
> Maurice
> 
> 
> OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 12751667200 (12160MB)
> avail mem = 12358139904 (11785MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb450 (77 entries)
> bios0: vendor American Megatrends Inc. version "F22" date 11/14/2013
> bios0: Gigabyte Technology Co., Ltd. Z77-D3H
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT DMAR
> acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)
> USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
> PXSX(S4) RP04(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3403.81 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> acpitimer0: recalibrated TSC frequency 3403350537 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3403.35 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3403.35 MHz
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3403.35 MHz
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpihpet0: recalibrated TSC frequency 3403372040 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (P0P1)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus -1 (RP02)
> acpiprt4 at acpi0: bus -1 (RP03)
> acpiprt5 at acpi0: bus -1 (RP04)
> acpiprt6 at acpi0: bus -1 (RP05)
> acpiprt7 at acpi0: bus 2 (RP06)
> acpiprt8 at acpi0: bus 4 (RP07)
> acpiprt9 at acpi0: bus 5 (RP08)
> acpiprt10 at acpi0: bus -1 (PEG0)
> acpiprt11 at acpi0: bus -1 (PEG1)
> acpiprt12 at acpi0: bus -1 (PEG2)
> acpiprt13 at acpi0: bus -1 (PEG3)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0: C3(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: FN00, resource for FAN0
> acpipwrres1 at acpi0: FN01, resource for FAN1
> acpipwrres2 at acpi0: FN02, resource for FAN2
> acpipwrres3 at acpi0: FN03, resource for FAN3
> acpipwrres4 at acpi0: FN04, resource for FAN4
> acpitz0 at 

Re: OpenBSD 6.2 amd64 and ATI Radeon 9550

2018-03-24 Thread Jonathan Gray
On Fri, Mar 23, 2018 at 06:12:26PM +0100, Freen wrote:
> Hi all
> 
> I have installed OpenBSD 6.2 AMD64 on my old PC consisting of:
> Motherboard:  MSI K8N Neo2 Series (MS-7025);
> Graphic card: Sapphire (ATI) Radeon 9550/X1050 Series (RV350) AGP 8x.
> 
> Unfortunately, things don't work very well: the AGP seems to be not 
> configured and there is an error in dmesg. X environment is slow and when 
> scrolling the mouse become irresponsive until the scrolling stops. Setting 
> different values in "machdep.allowaperture" doesn't change anything.
> 
> Don't know if it matters, but I noticed that though my card is listed in the 
> radeon(4) man page, it isn't listed in the Xorg.0.log Driver section: it is 
> instead recognized as an ATI Radeon 9600 AS (ChipID = 0x4153) of which my 
> card should be a derivative with different chipset ID (0x4173). Automatically 
> installed firmware is "radeondrm-firmware-20150927".
> 
> USB has problem too, but I think I'll not go in depth further if I can't fix 
> the graphic issue, provided that my hardware is still supported. Hope someone 
> helps me understand what exactly is wrong here.

There is no support for nvidia AGP at the moment.  Someone needs to write
that or port code from FreeBSD or elsewhere
https://svnweb.freebsd.org/base/head/sys/dev/agp/agp_nvidia.c?view=log

At the moment there is

agp_ali.c
agp_amd.c
agp_apple.c
agp_i810.c
agp_intel.c
agp_sis.c
agp_via.c

> 
> FWIW here are the dmesg.boot and Xorg.0.log files.
> 
> Thank you.
> 
> -dmesg.boot-
> 
> OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct  3 21:22:29 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3204382720 (3055MB)
> avail mem = 3100299264 (2956MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.2 @ 0xf (43 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 01/29/2007
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT APIC
> acpi0: wakeup devices HUB0(S5) HUB1(S4) USB0(S3) USB1(S3) USB2(S3) F139(S3) 
> MMAC(S5) MMCI(S5) UAR1(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2009.42 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 200MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2009.17 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG
> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
> , remapped to apid 2
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (HUB0)
> acpiprt2 at acpi0: bus 1 (AGPB)
> acpiprt3 at acpi0: bus -1 (HUB1)
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpicpu1 at acpi0: C1(@1 halt!), PSS
> acpipwrres0 at acpi0: ISAV, resource for IDE0
> acpibtn0 at acpi0: PWRB
> "PNP0700" at acpi0 not configured
> "PNP0F13" at acpi0 not configured
> cpu0: Cool'n'Quiet K8 2009 MHz: speeds: 2000 1800 1000 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "NVIDIA nForce3 250 Host" rev 0xa1
> agp at pchb0 not configured
> pcib0 at pci0 dev 1 function 0 "NVIDIA nForce3 250 ISA" rev 0xa2
> nviic0 at pci0 dev 1 function 1 "NVIDIA nForce3 250 SMBus" rev 0xa1
> iic0 at nviic0
> spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM non-parity PC3200CL3.0
> spdmem1 at iic0 addr 0x51: 512MB DDR SDRAM non-parity PC3200CL3.0
> spdmem2 at iic0 addr 0x52: 1GB DDR SDRAM non-parity PC3200CL3.0
> spdmem3 at iic0 addr 0x53: 1GB DDR SDRAM non-parity PC3200CL3.0
> iic1 at nviic0
> iic1: addr 0x2f 00=12 01=0f 02=10 03=01 04=07 05=00 06=18 07=00 08=00 14=14 
> 15=62 16=02 17=05 words 00=12ff 01=0fff 02=10ff 03=01ff 04=07ff 05=00ff 
> 06=18ff 07=00ff
> ohci0 at pci0 dev 2 function 0 "NVIDIA nForce3 250 USB" rev 0xa1: apic 2 int 
> 20, version 1.0, legacy support
> ohci1 at pci0 dev 2 function 1 "NVIDIA nForce3 250 USB" rev 0xa1: apic 2 int 
> 20, version 1.0, legacy support
> ehci0 at pci0 dev 2 function 2 "NVIDIA nForce3 250 USB" rev 0xa2: 

Re: X server keeps crashing in current/amd64

2018-03-22 Thread Jonathan Gray
On Thu, Mar 22, 2018 at 07:21:33PM +0100, Robert wrote:
> On Tue, 20 Mar 2018 22:11:21 +0100
> Robert  wrote:
> > I am happy to report that with the latest snapshot (20.3.) the
> > crashing problem seems to be gone.
> 
> Well, that was an early celebration.
> The problem occured again; guess I just had luck when I verified it
> earlier.
> 
> Same issue: X crashes and I have to restart it several times until I
> get a stable session.

If you can get a backtrace that would be helpful.

Getting Xorg to dump a core file is described in
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/README?rev=1.40=text/plain

> 
> What I noticed is that one crash terminated X with:
> [26.914] (EE) Received signal 6 sent by process 0, uid 0
> [26.914] (EE) 
> Fatal server error:
> [26.914] (EE) Caught signal 6 (Abort trap). Server aborting
> 
> Whereas the next crash was:
> [   262.977] (EE) Segmentation fault at address 0x10d7c4b2d000
> [   262.977] (EE) 
> Fatal server error:
> [   262.977] (EE) Caught signal 11 (Segmentation fault). Server aborting
> 
> Both Xorg.log and xorg.conf below.
> 
> regards,
> Robert
> 
> 
> OpenBSD 6.3 (GENERIC.MP) #82: Tue Mar 20 11:28:30 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Xorg.0.log
> ==
> [26.441] (--) checkDevMem: using aperture driver /dev/xf86
> [26.460] (--) Using wscons driver on /dev/ttyC4
> [26.467] 
> X.Org X Server 1.19.6
> Release Date: 2017-12-20
> [26.467] X Protocol Version 11, Revision 0
> [26.467] Build Operating System: OpenBSD 6.3 amd64 
> [26.467] Current Operating System: OpenBSD pcc.abc.test 6.3
> GENERIC.MP#82 amd64 [26.467] Build Date: 20 March 2018  11:45:26AM
> [26.467]  
> [26.467] Current version of pixman: 0.34.0
> [26.467]  Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> [26.467] Markers: (--) probed, (**) from config file, (==) default
> setting, (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [26.467] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 22
> 18:59:34 2018 [26.468] (==) Using config file: "/etc/X11/xorg.conf"
> [26.468] (==) Using system config directory
> "/usr/X11R6/share/X11/xorg.conf.d" [26.469] (==) ServerLayout
> "layout0" [26.469] (**) |-->Screen "screen0" (0)
> [26.469] (**) |   |-->Monitor "monitor0"
> [26.469] (**) |   |-->Device "device0"
> [26.469] (**) |-->Screen "screen1" (1)
> [26.469] (**) |   |-->Monitor "monitor1"
> [26.469] (**) |   |-->Device "device1"
> [26.470] (**) Option "Xinerama" "true"
> [26.470] (==) Automatically adding devices
> [26.470] (==) Automatically enabling devices
> [26.470] (==) Not automatically adding GPU devices
> [26.470] (**) Xinerama: enabled
> [26.470] (==) Max clients allowed: 256, resource mask: 0x1f
> [26.476] (==) FontPath set to:
>   /usr/X11R6/lib/X11/fonts/misc/,
>   /usr/X11R6/lib/X11/fonts/TTF/,
>   /usr/X11R6/lib/X11/fonts/OTF/,
>   /usr/X11R6/lib/X11/fonts/Type1/,
>   /usr/X11R6/lib/X11/fonts/100dpi/,
>   /usr/X11R6/lib/X11/fonts/75dpi/
> [26.476] (==) ModulePath set to "/usr/X11R6/lib/modules"
> [26.476] (II) The server relies on wscons to provide the list of
> input devices. If no devices become available, reconfigure wscons or
> disable AutoAddDevices. [26.476] (II) Loader magic: 0xb8907542000
> [26.476] (II) Module ABI versions:
> [26.476]  X.Org ANSI C Emulation: 0.4
> [26.476]  X.Org Video Driver: 23.0
> [26.476]  X.Org XInput driver : 24.1
> [26.476]  X.Org Server Extension : 10.0
> [26.476] (--) PCI:*(0:1:0:0) 1002:683f:1787:7250 rev 0, Mem @
> 0xe000/268435456, 0xf7e0/262144, I/O @ 0xe000/256, BIOS @
> 0x/131072 [26.476] (II) LoadModule: "glx" [26.478] (II)
> Loading /usr/X11R6/lib/modules/extensions/libglx.so [26.487] (II)
> Module glx: vendor="X.Org Foundation" [26.487]compiled for
> 1.19.6, module version = 1.0.0 [26.487]   ABI class: X.Org
> Server Extension, version 10.0 [26.487] (II) LoadModule: "radeon"
> [26.488] (II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.so
> [26.490] (II) Module radeon: vendor="X.Org Foundation"
> [26.490]  compiled for 1.19.6, module version = 18.0.1
> [26.490]  Module class: X.Org Video Driver
> [26.490]  ABI class: X.Org Video Driver, version 23.0
> [26.490] (II) RADEON: Driver for ATI/AMD Radeon chipsets:
>   ATI Radeon Mobility X600 (M24), ATI FireMV 2400,
>   ATI Radeon Mobility X300 (M24), ATI FireGL M24 GL,
>   ATI Radeon X600 (RV380), ATI FireGL V3200 (RV380),
>   ATI Radeon IGP320 (A3), ATI Radeon IGP330/340/350 (A4),
>   ATI Radeon 9500, ATI Radeon 9600TX, ATI FireGL Z1, ATI Radeon
> 9800SE, ATI Radeon 9800, ATI FireGL X2, ATI 

Re: X server keeps crashing in current/amd64

2018-03-17 Thread Jonathan Gray
On Sat, Mar 17, 2018 at 10:40:55PM +0100, Robert wrote:
> Hi,
> 
> Since about two weeks the X server keeps crashing (segfault) most of the
> time when I start it (through xenodm).
> I have to restart it (rcctl restart xenodm) about 5-10 times
> until I get an (xfce) session that stays stable. 
> 
> I reinstalled today with the latest current/amd64, and now this issue became
> worse: In addition, even when I get a stable session, it crashes as
> soon as I do some actions, such as moving the mouse for a couple of
> seconds or starting Firefox.
> 
> Xorg.log says (from various such occurences):
> (EE) Segmentation fault at address 0x64bfcd81018
> (EE) Segmentation fault at address 0x17e082969018
> (EE) Segmentation fault at address 0x78e6159b000
> 
> Any ideas / recommendations on how to debug or fix this?
> (dmesg / xorg log below)

I see you have multiple screens in your Xorg log.

I've just committed an update to xf86-video-ati 18.0.1 which
mentions fixing a crash with multiple screens.

https://lists.x.org/archives/xorg-announce/2018-March/002884.html

* The Xorg process could crash when multiple primary screens are
  configured in xorg.conf.

Index: configure
===
RCS file: /cvs/xenocara/driver/xf86-video-ati/configure,v
retrieving revision 1.23
diff -u -p -r1.23 configure
--- configure   13 Mar 2018 06:13:13 -  1.23
+++ configure   17 Mar 2018 23:25:41 -
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for xf86-video-ati 18.0.0.
+# Generated by GNU Autoconf 2.69 for xf86-video-ati 18.0.1.
 #
 # Report bugs to 
.
 #
@@ -591,8 +591,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='xf86-video-ati'
 PACKAGE_TARNAME='xf86-video-ati'
-PACKAGE_VERSION='18.0.0'
-PACKAGE_STRING='xf86-video-ati 18.0.0'
+PACKAGE_VERSION='18.0.1'
+PACKAGE_STRING='xf86-video-ati 18.0.1'
 
PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=xorg=Driver/Radeon'
 PACKAGE_URL=''
 
@@ -1390,7 +1390,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures xf86-video-ati 18.0.0 to adapt to many kinds of 
systems.
+\`configure' configures xf86-video-ati 18.0.1 to adapt to many kinds of 
systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1460,7 +1460,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of xf86-video-ati 18.0.0:";;
+ short | recursive ) echo "Configuration of xf86-video-ati 18.0.1:";;
esac
   cat <<\_ACEOF
 
@@ -1616,7 +1616,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-xf86-video-ati configure 18.0.0
+xf86-video-ati configure 18.0.1
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2031,7 +2031,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by xf86-video-ati $as_me 18.0.0, which was
+It was created by xf86-video-ati $as_me 18.0.1, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -2862,7 +2862,7 @@ fi
 
 # Define the identity of the package.
  PACKAGE='xf86-video-ati'
- VERSION='18.0.0'
+ VERSION='18.0.1'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -19881,7 +19881,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_wri
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by xf86-video-ati $as_me 18.0.0, which was
+This file was extended by xf86-video-ati $as_me 18.0.1, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -19947,7 +19947,7 @@ _ACEOF
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-xf86-video-ati config.status 18.0.0
+xf86-video-ati config.status 18.0.1
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
Index: configure.ac
===
RCS file: /cvs/xenocara/driver/xf86-video-ati/configure.ac,v
retrieving revision 1.16
diff -u -p -r1.16 configure.ac
--- configure.ac13 Mar 2018 06:13:13 -  1.16
+++ configure.ac17 Mar 2018 23:25:17 -
@@ -23,7 +23,7 @@
 # Initialize Autoconf
 AC_PREREQ([2.60])
 AC_INIT([xf86-video-ati],
-[18.0.0],
+[18.0.1],
 
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg=Driver/Radeon],
 [xf86-video-ati])
 
Index: src/drmmode_display.c

  1   2   3   4   5   6   >