Re: booting 6.1

[Jonathan Gray]

On Thu, Jun 08, 2017 at 03:10:33PM -0300, Friedrich Locke wrote:
> Hi folks,
> 
> i burnt and install61.iso cd and tried to boot uefi, but could not.
> Does anybody know this amd64 6.1 install image support booting UEFI ?
> 
> Thanks in advance

The iso does not handle uefi at the moment.  Write install61.fs to a usb
stick instead.

Re: Pinebook (if anyones up for it)

[Jonathan Gray]

On Tue, Aug 15, 2017 at 09:48:14AM -0400, Patrick Wildt wrote:
> On Mon, Aug 14, 2017 at 10:08:13PM +0300, valerij zaporogeci wrote:
> > 2017-08-14 10:21 GMT+03:00, Alex Naumov :
> > > Hello,
> > >
> > > there is one enthusiast, who wants to make it possible:
> > > http://openbsd-archive.7691.n7.nabble.com/Working-on-support-for-Pinebook-td318562.html
> > >
> > > I don't know the current state, but I also have a Pinebook and would
> > > like to run OpenBSD on it.
> > >
> > >
> > > Some info you can find there: https://www.openbsd.org/arm64.html
> > > ==
> > > The Pine64 currently requires an image based on a non-redistributable
> > > boot0 file from Allwinner to be installed on the system disk. This
> > > will hopefully be resolved by a replacement in a future U-Boot
> > > release. The install media does not include these boot images or a
> > > Pine64 device tree. For similar reasons we do not provide install
> > > media for the Firefly-RK3399 either.
> > > ==
> 
> Correction: The problem of the boot0 file has been solved thanks to
> changes in u-boot.  Work on install media for the Pine64 is now in
> progress, without unredistributable blobs.

pine64 firmware that doesn't require boot0 is included in
https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot61.fs

Looking for testers.

Re: Pinebook (if anyones up for it)

[Jonathan Gray]

On Mon, Aug 21, 2017 at 12:17:20AM +1000, Jonathan Gray wrote:
> On Tue, Aug 15, 2017 at 09:48:14AM -0400, Patrick Wildt wrote:
> > On Mon, Aug 14, 2017 at 10:08:13PM +0300, valerij zaporogeci wrote:
> > > 2017-08-14 10:21 GMT+03:00, Alex Naumov :
> > > > Hello,
> > > >
> > > > there is one enthusiast, who wants to make it possible:
> > > > http://openbsd-archive.7691.n7.nabble.com/Working-on-support-for-Pinebook-td318562.html
> > > >
> > > > I don't know the current state, but I also have a Pinebook and would
> > > > like to run OpenBSD on it.
> > > >
> > > >
> > > > Some info you can find there: https://www.openbsd.org/arm64.html
> > > > ==
> > > > The Pine64 currently requires an image based on a non-redistributable
> > > > boot0 file from Allwinner to be installed on the system disk. This
> > > > will hopefully be resolved by a replacement in a future U-Boot
> > > > release. The install media does not include these boot images or a
> > > > Pine64 device tree. For similar reasons we do not provide install
> > > > media for the Firefly-RK3399 either.
> > > > ==
> > 
> > Correction: The problem of the boot0 file has been solved thanks to
> > changes in u-boot.  Work on install media for the Pine64 is now in
> > progress, without unredistributable blobs.
> 
> pine64 firmware that doesn't require boot0 is included in
> https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot61.fs
> 
> Looking for testers.
> 

Though the pinebook may require a different device tree
https://patchwork.kernel.org/patch/9591501/

And will likely require 3.3v serial instead of video
http://linux-sunxi.org/Pine_Pinebook#Adding_a_serial_port

Re: TouchPad on Asus UX390

[Jonathan Gray]

On Sun, Aug 27, 2017 at 03:04:58PM +0200, Remi Locherer wrote:
> Hi,
> 
> recently I bought a Asus UX390. It's very small and light notebook
> (less than 1 kg!). OpenBSD runs fine on it. Only its touchpad is not
> supported.
> 
> In the dmesg this is shown (full dmesg at the bottom):
> "ELAN1301" at acpi0 not configured
> 
> Nothing else that hints at an mouse/touchpad device.
> 
> Would support for this touchpad mean writing a new driver or tweak an
> existing one?

jcs@ was looking into LPSS/PCI DesignWare I2C for
https://jcs.org/2017/07/14/matebook

> "Intel 100 Series I2C" rev 0x21 at pci0 dev 21 function 0 not configured
> "Intel 100 Series I2C" rev 0x21 at pci0 dev 21 function 1 not configured

>  0:21:0: Intel 100 Series I2C
>   0x: Vendor ID: 8086 Product ID: 9d60
>   0x0004: Command:  Status: 0010
>   0x0008: Class: 11 Subclass: 80 Interface: 00 Revision: 21
>   0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00
>   0x0010: BAR mem 64bit addr: 0xef233000/0x1000
>   0x0018: BAR empty ()
>   0x001c: BAR empty ()
>   0x0020: BAR empty ()
>   0x0024: BAR empty ()
>   0x0028: Cardbus CIS: 
>   0x002c: Subsystem Vendor ID: 1043 Product ID: 15c0
>   0x0030: Expansion ROM Base Address: 
>   0x0038: 
>   0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
>   0x0080: Capability 0x01: Power Management
>   State: D3
>   0x0090: Capability 0x09: Vendor Specific
>   0x: 9d608086 0010 11800021 0080
>   0x0010: ef233004   
>   0x0020:    15c01043
>   0x0030:  0080  01ff
>   0x0040:    
>   0x0050:    
>   0x0060:    
>   0x0070:    
>   0x0080: 00039001 000b  
>   0x0090: f0140009 01400010 2101 24c1
>   0x00a0: 000f0800   
>   0x00b0:    
>   0x00c0:    
>   0x00d0:    
>   0x00e0:    
>   0x00f0:   08400fb3 
>  0:21:1: Intel 100 Series I2C
>   0x: Vendor ID: 8086 Product ID: 9d61
>   0x0004: Command:  Status: 0010
>   0x0008: Class: 11 Subclass: 80 Interface: 00 Revision: 21
>   0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00
>   0x0010: BAR mem 64bit addr: 0xef232000/0x1000
>   0x0018: BAR empty ()
>   0x001c: BAR empty ()
>   0x0020: BAR empty ()
>   0x0024: BAR empty ()
>   0x0028: Cardbus CIS: 
>   0x002c: Subsystem Vendor ID: 1043 Product ID: 15c0
>   0x0030: Expansion ROM Base Address: 
>   0x0038: 
>   0x003c: Interrupt Pin: 02 Line: ff Min Gnt: 00 Max Lat: 00
>   0x0080: Capability 0x01: Power Management
>   State: D3
>   0x0090: Capability 0x09: Vendor Specific
>   0x: 9d618086 0010 11800021 0080
>   0x0010: ef232004   
>   0x0020:    15c01043
>   0x0030:  0080  02ff
>   0x0040:    
>   0x0050:    
>   0x0060:    
>   0x0070:    
>   0x0080: 00039001 000b  
>   0x0090: f0140009 01400010 2101 24c1
>   0x00a0: 000f0800   
>   0x00b0:    
>   0x00c0:    
>   0x00d0:    
>   0x00e0:    
>   0x00f0:   08400fb3 

Re: X710 10Gb card not configured

[Jonathan Gray]

On Tue, Sep 26, 2017 at 05:35:40PM -0700, James A. Peltier wrote:
> Hi Misc,
> 
> I am running the latest OpenBSD snapshot and it appears that the 10Gb cards 
> that we have in the unit aren't recognized or configured properly.  I had a 
> look at pcidevs and pcidevs.h files in src/dev/pci and it appears that the 
> device should be found as 
> 
> src/sys/dev/pcidevs
> product INTEL X710_10G_SFP0x1572  X710 SFP+
> 
> src/sys/dev/pcidevs.h
> #define   PCI_PRODUCT_INTEL_X710_10G_SFP  0x1572  /* X710 SFP+ */
> 
> 
> I have attached a pcidump -v below hoping someone might resolve this issue.  
> Please let me know if there is anything else I can provide and when I might 
> be able to try another snapshot.

There is currently no driver in the tree for Intel X710/XL710 10Gb/40Gb.

Re: X710 10Gb card not configured

[Jonathan Gray]

On Wed, Sep 27, 2017 at 03:53:26AM -0700, James A. Peltier wrote:
> - On 26 Sep, 2017, at 20:25, Jonathan Gray j...@jsg.id.au wrote:
> 
> | On Tue, Sep 26, 2017 at 05:35:40PM -0700, James A. Peltier wrote:
> |> Hi Misc,
> |> 
> |> I am running the latest OpenBSD snapshot and it appears that the 10Gb 
> cards that
> |> we have in the unit aren't recognized or configured properly.  I had a 
> look at
> |> pcidevs and pcidevs.h files in src/dev/pci and it appears that the device
> |> should be found as
> |> 
> |> src/sys/dev/pcidevs
> |> product INTEL X710_10G_SFP 0x1572  X710 SFP+
> |> 
> |> src/sys/dev/pcidevs.h
> |> #definePCI_PRODUCT_INTEL_X710_10G_SFP  0x1572  /* X710 SFP+ */
> |> 
> |> 
> |> I have attached a pcidump -v below hoping someone might resolve this issue.
> |> Please let me know if there is anything else I can provide and when I 
> might be
> |> able to try another snapshot.
> | 
> | There is currently no driver in the tree for Intel X710/XL710 10Gb/40Gb.
> 
> Can I get a recommendation on a comparable 10Gb/40Gb card that will work?  
> Specific card or model numbers so I can get them in ASAP

I suspect most people are using the Intel based cards supported by ix(4)
for 10GbE (https://man.openbsd.org/ix.4).  There are no drivers for any
40GbE parts.

Re: RPI3 fails to relink kernel

[Jonathan Gray]

On Tue, Oct 17, 2017 at 04:48:19PM -0700, Carlos Cardenas wrote:
> Howdy.
> 
> I found a working USB (Sandisk Cruzer Fit 8GB) to install 6.2 on a RPI3.
> 
> Install went fine and so was first boot, then I noticed that relinking
> the kernel failed.
> 
> Below is my dmesg and error log.
> 
> I thought it might have been due to the clock being way skewed by I
> sync'ed it manually and still run into the same error.
> 
> Any pointers on how to proceed?

The version of lld (4.0.0) in 6.2 could not handle the linker script
required for that.  Snapshots have llvm/lld 5.0.0 and relinking should
work there.

> 
> +--+
> Carlos
> OpenBSD 6.2 (GENERIC) #34: Tue Oct  3 23:53:05 MDT 2017
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC
> real mem  = 964972544 (920MB)
> avail mem = 909017088 (866MB)
> mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2
> cpu0 at mainbus0: ARM Cortex-A53 r0p4
> simplefb0 at mainbus0: 656x416
> wsdisplay0 at simplefb0 mux 1
> wsdisplay0: screen 0 added (std, vt100 emulation)
> simplebus0 at mainbus0: "soc"
> bcmintc0 at simplebus0
> bcmdog0 at simplebus0
> pluart0 at simplebus0
> bcmaux0 at simplebus0
> com0 at simplebus0: ns16550, no working fifo
> com0: console
> dwctwo0 at simplebus0
> agtimer0 at simplebus0: tick rate 19200 KHz
> syscon0 at simplebus0
> simplebus1 at mainbus0: "clocks"
> usb0 at dwctwo0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev 
> 2.00/1.00 addr 1
> uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard Microsystems 
> product 0x9514" rev 2.00/2.00 addr 2
> smsc0 at uhub1 port 1 configuration 1 interface 0 "Standard Microsystems 
> SMSC9512/14" rev 2.00/2.00 addr 3
> smsc0: address b8:27:eb:1c:06:b7
> ukphy0 at smsc0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x0001f0, model 0x000c
> umass0 at uhub1 port 5 configuration 1 interface 0 "SanDisk Cruzer Fit" rev 
> 2.10/1.00 addr 4
> umass0: using SCSI over Bulk-Only
> scsibus0 at umass0: 2 targets, initiator 0
> sd0 at scsibus0 targ 1 lun 0:  SCSI4 0/direct 
> removable serial.07815571040905110075
> sd0: 7632MB, 512 bytes/sector, 15630336 sectors
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> bootfile: sd0a:/bsd
> boot device: sd0
> root on sd0a (b045dd5058980495.a) swap on sd0b dump on sd0b
> WARNING: CHECK AND RESET THE DATE!
> 
> 
> # cat /usr/share/compile/GENERIC/relink.log
> (SHA256) /bsd: OK
> LD="ld" sh makegap.sh 0xd4d4d4d4 gapdummy.o
> ld: error: gap.link:11: unknown command ;
> ld: error: gap.link:11: LONG(0xd4d4d4d4);
> ld: error: gap.link:11:   ^
> ld: error: cannot open gapdummy.o: No such file or directory
> ld: error: target emulation unknown: -m or at least one .o file required
> *** Error 1 in /usr/share/compile/GENERIC (Makefile:529 'newbsd')
> 

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

[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: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

[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: Can't open /dev/bio on arm

[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: Can't open /dev/bio on arm

[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

[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

[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: Keyboard repeats characters way to often

[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 processor)

Re: Keyboard repeats characters way to often

[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: radeondrm failure on amd64 but not on i386?

[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: radeondrm failure on amd64 but not on i386?

[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: [drm] *ERROR* [CRTC:41:pipe ] flip_done timed out

[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&r=1&w=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 = &dev->vblank[pipe];
+   const struct drm_display_mode *mode = &vblank->hwmode;
i915_reg_t high_frame, low_frame;
u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
-   const struct drm_display_mode *mode = &dev->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;

Re: AMDGPU

[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: AMDGPU

[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: no u-boot serial output on raspberry pi 3

[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: AMD 5700XT (NAVI10) misreported and non-working

[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 at

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

[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: No xenocara for ATI Radeon HD 2400 XT

[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&T/Lucent FW322 1394" rev 0x61 at pci5 dev 5 fu

Re: No xenocara for ATI Radeon HD 2400 XT

[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: how to figure out reverse package dependency?

[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: firefox freezes X on AMD Ryzen running 6.8

[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: Inphi CS4223 for 4x 10GbE SFP+

[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: AMDGPU(4) - Question about man page

[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: OpenBSD UEFI on QEMU emulator

[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: Blank screen after installing OpenBSD 6.5

[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: AMDGPU in current issue

[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: Best 1Gbe NIC

[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: trouble with radeon r9 290 and eduke32

[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: AMDGPU in current issue

[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: AMDGPU in current issue

[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
> > -
> > >

Re: trouble with radeon r9 290 and eduke32

[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} ${W

Re: trouble with radeon r9 290 and eduke32

[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

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

[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: xenocara xcursor issues?

[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: netsurf-fb fails on framebuffer console

[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: netsurf-fb fails on framebuffer console

[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: sysupgrade woes on beaglebone black

[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&m=156889553923923&w=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&r2=1.1142&f=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: Brand new server - bad adventures

[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: PC Engine APU.1D4 installation stopper.

[Jonathan Gray]

For i386/amd64 you have to tell boot you want serial output
either at the boot prompt or via boot.conf.

stty com0 115200
set tty com0

On Mon, Oct 19, 2015 at 10:34:15PM -0400, Daniel Ouellet wrote:
> Hi,
> 
> I am trying to load OpenBSD on this box and no matter what I try I end
> up not being able too.
> 
> I did search and saw plenty that were successful and all. May be it's
> the newer model.
> 
> APU.1D4?
> 
> Or is there any special truck?
> 
> I tried from usb flash drive, and even from a Sata drive inside a USB
> hosing.
> 
> Could this may be use UEFI now?
> 
> I tried 5.7, 5.8 and still no go.
> 
> May be the only way to load it in there is via PXE- Boot?
> 
> And I saw the note as well about the bios for OpenBSD in case anyone
> thought to say that. It is newer then April 2014 as recommended.
> 
> Here is where it block no matter what drives and version I tried.
> 
> Any clue stick would be greatly appreciated. I obviously must be
> overlooking something stupid...
> 
> Daniel
> 
> =
> USB Fash Drive
> =
> > PC Engines APU BIOS build date: Sep  8 2014
> Total memory 4096 MB
> AMD G-T40E Processor
> CPU MHz=1000
> USB MSC blksize=512 sectors=7897088
> Press F10 key now for boot menu:
> drive 0x000f2a60: PCHS=0/0/0 translation=lba LCHS=979/128/63 s=7897088
> drive 0x000f2a90: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> s=31277232
> Booting from Hard Disk...
> Using drive 0, partition 3.
> Loading.
> probing: pc0 com0 com1 mem[639K 3568M 496M a20=on]
> disk: hd0+ hd1+*
> >> OpenBSD/amd64 BOOT 3.28
> boot>
> booting hd0a:/bsd: 6707920+2128368+250888+0+598016
> [97+561408+373901]=0xa228f8
> entry point at 0x1000160 [7205c766, 3404, 24448b12, 62e0a304]
> 
> =
> SATA Drive via USB adaptor
> =
> 
> > PC Engines APU BIOS build date: Sep  8 2014
> Total memory 4096 MB
> AMD G-T40E Processor
> CPU MHz=1000
> USB MSC blksize=512 sectors=125045424
> Press F10 key now for boot menu:
> drive 0x000f2a60: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=125045424
> drive 0x000f2a90: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> s=31277232
> Booting from Hard Disk...
> Using drive 0, partition 3.
> Loading.
> probing: pc0 com0 com1 mem[639K 3568M 496M a20=on]
> disk: hd0+ hd1+*
> >> OpenBSD/amd64 BOOT 3.28
> boot>
> booting hd0a:/bsd:6741232+2129936+250888+0+598016
> [97+563616+375372/]=0xa2c758
> entry point at 0x1000160 [7205c766, 3404, 24448b12, f2e0a304]

Re: pledge(2) problems on 18/x/ octeon snapshot

[Jonathan Gray]

On Tue, Oct 20, 2015 at 12:10:39PM +0200, Sebastien Marie wrote:
> On Tue, Oct 20, 2015 at 11:09:58AM +0200, Kim Zeitler wrote:
> > Hello
> > 
> > On 10/19/15 19:58, Sebastien Marie wrote:
> > >
> > >RELEASE 5.8 returns ENOSYS ("Function not implemented") on tame(2) call
> > >(which is the old name for pledge, so with the same syscall number).
> > I pulled the kernel down from the same URL path as the tgz I used.
> > Before reinstalling the system I noticed, the Kernel login string having an
> > older date than the snapshot.
> > 
> > >I would be great if you can grab the kernel version echoed at boot time.
> > >You could use `boot -c' in the boot loader, in order to enter in config
> > >mode, and have the time to read the OpenBSD version.
> > >
> > Sadly EdgeRouterLite have no 'real bootloader' but use U-Boot. Which I guess
> > is part of the problem.
> > 
> > My steps where as followed:
> > 
> > mv bsd obsd
> > mv /tmp/bsd /bsd
> > mv /tmp/bsd.rd /bsd.rd
> > reboot
> > 
> > Can i be, that U-boot does not cleanly reload the new kernel on reboot?
> 
> As I don't know U-boot, I couldn't say anything...
> 
> As you told previously that you have problem when running command, I
> think you have a valid shell ? If it is the case, could you run:
> # sysctl kern.version
> 
> sysctl(8) isn't pledged, so it should be runnable (if you have a shell).
> 
> after, if the running bsd is a too old version (without pledge(2)
> support), you will need to change the booted kernel to something else.
> 
> Reading the INSTALL.octeon file, it seems it should be possible to
> choose at boottime the image you want to boot. The more simple should be
> to try booting bsd.rd: it is self-contained so inside the RAMDISK the
> userland will be compatible with the kernel.
> 
> And after you will have to download another bsd file, and try to boot it.
> 
> For checking the version of an arbitrary bsd file, you could use
> what(1):
> 
> # what /bsd
> /bsd
> OpenBSD 5.8-current (GENERIC.MP) #27: Tue Oct 20 09:23:20 CEST 2015
> 
> I will try to get more information about U-boot.

There is no OpenBSD bootloader for armv7 or octeon, in part because
u-boot by default provides no interface for enumerating disks, reading blocks
or putc/getc equivalents unlike firmware shipped with almost every
other system.

As a result the kernel has to live on filesystems u-boot understands,
fat32 or ext2 not ffs.  So /bsd will not be the kernel that is loaded.

kernel arguments like -c to get into ukc can be set via
setenv bootargs
though it seems the octeon code may not use that while armv7 does.

Re: PC Engine APU.1D4 installation stopper.

[Jonathan Gray]

On Tue, Oct 20, 2015 at 02:12:35PM +0200, Mark Kettenis wrote:
> > > For i386/amd64 you have to tell boot you want serial output
> > > either at the boot prompt or via boot.conf.
> > > 
> > > stty com0 115200
> > > set tty com0
> > 
> > 
> > OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > RTC BIOS diagnostic error
> > ff
> > real mem = 4246003712 (4049MB)
> > avail mem = 4113428480 (3922MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
> > bios0: vendor coreboot version "4.0" date 09/08/2014
> > bios0: PC Engines APU
> > acpi0 at bios0: rev 0
> > acpi0: sleep states S0 S1 S3 S4 S5
> > acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
> 
> Since the ACPI BIOS provides a SPCR table, we can actually tell that
> we're on a serial console.  Shouldn't be too difficult to add support
> to the kernel for this, although we'd probably miss the first part of
> the dmesg if we do that.  So a better place would be the bootloader,
> but then we'd have to add code to find and parse acpi tables there.
> And there might be space issues there.
> 

Interesting.  On a dell server from 2007 booted via glass console
the table is present with the address and baud set to 0.  I guess
that changes if I were to configure the bios to put the console
on serial.

On the other hand I have a machine from 2009 that only has serial
and there is no SPCR table "acpi0: tables DSDT FACP APIC MCFG HPET".

It seems there can be a DBGP/DBG2 table in some cases that indicates
if debug ports are available on serial/firewire/usb/network as well.

[028h 0040  12] Serial Port Register : [Generic Address Structure]
[028h 0040   1] Space ID : 00 [SystemMemory]
[029h 0041   1]Bit Width : 00
[02Ah 0042   1]   Bit Offset : 00
[02Bh 0043   1] Encoded Access Width : 00 [Undefined/Legacy]
[02Ch 0044   8]  Address : 

[034h 0052   1]   Interrupt Type : 03
[035h 0053   1]  PCAT-compatible IRQ : 04
[036h 0054   4]Interrupt : 0004
[03Ah 0058   1]Baud Rate : 00
[03Bh 0059   1]   Parity : 00
[03Ch 0060   1]Stop Bits : 01
[03Dh 0061   1] Flow Control : 02
[03Eh 0062   1]Terminal Type : 01
[04Ch 0076   1] Reserved : 00
[040h 0064   2]PCI Device ID : 
[042h 0066   2]PCI Vendor ID : 
[044h 0068   1]  PCI Bus : 00
[045h 0069   1]   PCI Device : 00
[046h 0070   1] PCI Function : 00
[047h 0071   4]PCI Flags : 
[04Bh 0075   1]  PCI Segment : 00
[04Ch 0076   4] Reserved : 

Re: ThinkPad W541 resume doesn't work.

[Jonathan Gray]

On Wed, Oct 21, 2015 at 05:07:32PM +0200, Christoph R. Murauer wrote:
> Hello !
> 
> Don't tread this post as bug. If it works nice - if not also no
> problem because I don't need it really.
> 
> I have a W541 where suspend works but resume not.
> 
> The machine has no serial port. But beside the i7 a nVidia optimus
> which can't be switched off in the bios.
> 
> If I close the lid after a normal installation it suspends but, if I
> open the display it doesn't resume. Even not, if I press some keys,
> the power button is blinking and, the display stays black. The only
> way is, to press the power button till it switches off. If I switch it
> on again, it doesn't boot. Instead I have to press and hold the power
> button again, till it is really off.
> 
> If I set in rc.conf.local apmd_flags="-C" I can reproduce it using zzz
> and ZZZ. In booth the same. The only difference is, that in one of
> them (I can't remember which one but I think you know which it is) I
> have only press the power butten once to switch it off.
> 
> At the moment I set in sysctl.conf machdep.lidsuspend=0 and, can
> confirm, that the display switch on after I open it for something like
> 1 centimeter.
> 
> If someone is interested to look at it and, more informations are
> needed, let me know.

If that's anything like the x250 and 2015 X1 Carbon you'll need
to disable the tpm in the bios:

https://bugzilla.redhat.com/show_bug.cgi?id=1164937

> 
> Regards,
> 
> 
> Christoph
> 
> dmesg :
> 
> OpenBSD 5.8-current (GENERIC.MP) #1527: Sun Oct 18 14:40:13 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 33939300352 (32367MB)
> avail mem = 32906575872 (31382MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7cd2d000 (69 entries)
> bios0: vendor LENOVO version "GNET73WW (2.21 )" date 03/12/2015
> bios0: LENOVO 20EFS00B00
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT
> SSDT SSDT SSDT PCCT SSDT TCPA UEFI POAT ASF! BATB FPDT UEFI
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) EXP3(S4)
> XHCI(S3) EHC1(S3) EHC2(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> 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-4810MQ CPU @ 2.80GHz, 798.33 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> 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.2.4, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 798.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 798.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 798.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> cpu4 at mainbus0: apid 4 (application processor)
> cpu4: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 798.15 MHz
> 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,SM

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Jonathan Gray]

On Wed, Oct 28, 2015 at 10:18:26PM -0400, Dewey Hylton wrote:
> i like these little boxes; they are silent and stable and perfect for plenty
> of my projects. this new version promises to be better than the several fit2
> machines i have scattered around customer sites, affording more cores and
> memory.
> 
> the man page for em shows the i211 to be supported. this machine uses that
> chip, and it is even reported by the kernel - but still does not work. is it
> possible that its specific id is simply missing from the driver, or is there
> more to it than that?
> 
> i booted the computer via pxe, so the ethernet is clearly working. it
> shipped with linux, and networking worked there too.
> 
> of course it'd be nice for all the other bits to be in working order as
> well, but at the moment ethernet is the most important for my purposes.
> 
> please let me know what i can do to get this working, or how i can assist
> otherwise.

If you can get the dmesg output of a kernel built with the following
diff it should indicate where the problem is:

Index: sys/dev/pci/if_em_osdep.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
retrieving revision 1.12
diff -u -p -r1.12 if_em_osdep.h
--- sys/dev/pci/if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
+++ sys/dev/pci/if_em_osdep.h   29 Oct 2015 03:27:36 -
@@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
 
 #define MSGOUT(S, A, B)printf(S "\n", A, B)
 #define DEBUGFUNC(F)   DEBUGOUT(F);
-#ifdef DBG
+//#ifdef DBG
+#if 1
#define DEBUGOUT(S) printf(S "\n")
#define DEBUGOUT1(S,A)  printf(S "\n",A)
#define DEBUGOUT2(S,A,B)printf(S "\n",A,B)

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Jonathan Gray]

On Thu, Oct 29, 2015 at 10:15:26AM -0400, Dewey Hylton wrote:
> On Wed, Oct 28, 2015 at 11:35 PM, Jonathan Gray  wrote:
> 
> > On Wed, Oct 28, 2015 at 10:18:26PM -0400, Dewey Hylton wrote:
> > > i like these little boxes; they are silent and stable and perfect for
> > plenty
> > > of my projects. this new version promises to be better than the several
> > fit2
> > > machines i have scattered around customer sites, affording more cores and
> > > memory.
> > >
> > > the man page for em shows the i211 to be supported. this machine uses
> > that
> > > chip, and it is even reported by the kernel - but still does not work.
> > is it
> > > possible that its specific id is simply missing from the driver, or is
> > there
> > > more to it than that?
> > >
> > > i booted the computer via pxe, so the ethernet is clearly working. it
> > > shipped with linux, and networking worked there too.
> > >
> > > of course it'd be nice for all the other bits to be in working order as
> > > well, but at the moment ethernet is the most important for my purposes.
> > >
> > > please let me know what i can do to get this working, or how i can assist
> > > otherwise.
> >
> > If you can get the dmesg output of a kernel built with the following
> > diff it should indicate where the problem is:
> >
> > Index: sys/dev/pci/if_em_osdep.h
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
> > retrieving revision 1.12
> > diff -u -p -r1.12 if_em_osdep.h
> > --- sys/dev/pci/if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
> > +++ sys/dev/pci/if_em_osdep.h   29 Oct 2015 03:27:36 -
> > @@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
> >
> >  #define MSGOUT(S, A, B)printf(S "\n", A, B)
> >  #define DEBUGFUNC(F)   DEBUGOUT(F);
> > -#ifdef DBG
> > +//#ifdef DBG
> > +#if 1
> > #define DEBUGOUT(S) printf(S "\n")
> > #define DEBUGOUT1(S,A)  printf(S "\n",A)
> > #define DEBUGOUT2(S,A,B)printf(S "\n",A,B)
> >
> 
> 
> 
> 
> i'll attempt to build a new bsd.rd with this patch and report back.
> 
> i've never done this, so it may take a bit of time to work out the
> details. thanks for the suggestion.

It would be enough to log the serial output and boot a normal kernel
with pxe.  Though it seems you may have the "fitlet-B" that doesn't
have serial unlike the "fitlet-i" and "fitlet-X".  Or perhaps
the output isn't so verbose that you could transcribe it.

If you have a spare usb flash drive you could install to that on a
different machine, put the test kernel on it, then boot it on the
machine.

It takes a while to test changes if you have to run make build and
make release every time.

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Jonathan Gray]

On Fri, Oct 30, 2015 at 11:32:16AM -0400, Dewey Hylton wrote:
> >
> didn't have -current onhand, but was able to perform this function on a 5.8
> system ... i have 3 of these devices i'd really like to get going on
> openbsd. THANKS!

...

> Invalid PHY ID 0xA0044E90

This shouldn't be possible, perhaps something isn't powering up correctly.

You could try the following patch which will force the id to a known one:

Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.88
diff -u -p -r1.88 if_em_hw.c
--- if_em_hw.c  12 Sep 2015 02:38:14 -  1.88
+++ if_em_hw.c  31 Oct 2015 04:43:49 -
@@ -5369,6 +5369,9 @@ em_match_gig_phy(struct em_hw *hw)
hw->phy_id |= (uint32_t) (phy_id_low & PHY_REVISION_MASK);
hw->phy_revision = (uint32_t) phy_id_low & ~PHY_REVISION_MASK;
 
+   if (hw->phy_id == 0xA0044E90)
+   hw->phy_id = I210_I_PHY_ID;
+
switch (hw->mac_type) {
case em_82543:
if (hw->phy_id == M88E1000_E_PHY_ID)
Index: if_em_osdep.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
retrieving revision 1.12
diff -u -p -r1.12 if_em_osdep.h
--- if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
+++ if_em_osdep.h   29 Oct 2015 03:27:36 -
@@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
 
 #define MSGOUT(S, A, B)printf(S "\n", A, B)
 #define DEBUGFUNC(F)   DEBUGOUT(F);
-#ifdef DBG
+//#ifdef DBG
+#if 1
#define DEBUGOUT(S) printf(S "\n")
#define DEBUGOUT1(S,A)  printf(S "\n",A)
#define DEBUGOUT2(S,A,B)printf(S "\n",A,B)

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Jonathan Gray]

On Sat, Oct 31, 2015 at 11:20:40AM -0400, Dewey Hylton wrote:
> >
> > THANKS for your time and assistance.
> >
> > i now have enough networking to commence an installation, which is in
> > progress. i'll have to build
> > and copy in a new kernel of course to use the booted system afterward.
> > assuming nothing is shown
> > broken in the dmesg below, what do i need to do in order to get this
> > change (or another fix which
> > would not require this change, if this was just an improper hack)
> > committed?
> >
> >
> HOLD THE PRESSES!
> 
> after the installation and reboot, just prior to copying the rebuild kernel
> that was to provide networking,
> i notice that networking is in fact working. so somehow, with regard to
> this specific network interface,
> there was a disparity between bsd.rd and bsd (GENERIC) kernels. i'll try to
> run this through its paces
> with vlans and other such things, but at the moment it looks like GENERIC
> from 5.8 actually works as
> it should without any changes. perhaps it's time to dust off the old usb
> installer sticks and forgo pxe for
> these little devices. at least for the time being ...
> 
> is it safe to assume that the disparity between bsd.rd and bsd is due to
> trimming to keep the image at
> a minimum? i know other things are removed from bsd.rd for this purpose ...
> and if not, does this point
> to a bug for which i need to make a report?

It isn't clear if it is that or the state the PXE option rom puts the
chip into.

I would be interested to hear if you still see the problem booting
bsd.rd off of a disk.

Re: compulab fitlet, non-working intel i211 ethernet, help requested

[Jonathan Gray]

On Mon, Nov 02, 2015 at 08:55:40PM -0500, Dewey Hylton wrote:
> On Sat, Oct 31, 2015 at 11:20 AM, Dewey Hylton 
> wrote:
> 
> > 2015-10-31 10:56 GMT-04:00 Dewey Hylton :
> >
> >> On Sat, Oct 31, 2015 at 12:49 AM, Jonathan Gray  wrote:
> >>
> >>> On Fri, Oct 30, 2015 at 11:32:16AM -0400, Dewey Hylton wrote:
> >>> > >
> >>> > didn't have -current onhand, but was able to perform this function on
> >>> a 5.8
> >>> > system ... i have 3 of these devices i'd really like to get going on
> >>> > openbsd. THANKS!
> >>>
> >>> ...
> >>>
> >>> > Invalid PHY ID 0xA0044E90
> >>>
> >>> This shouldn't be possible, perhaps something isn't powering up
> >>> correctly.
> >>>
> >>> You could try the following patch which will force the id to a known one:
> >>>
> >>> Index: if_em_hw.c
> >>> ===
> >>> RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
> >>> retrieving revision 1.88
> >>> diff -u -p -r1.88 if_em_hw.c
> >>> --- if_em_hw.c  12 Sep 2015 02:38:14 -  1.88
> >>> +++ if_em_hw.c  31 Oct 2015 04:43:49 -
> >>> @@ -5369,6 +5369,9 @@ em_match_gig_phy(struct em_hw *hw)
> >>> hw->phy_id |= (uint32_t) (phy_id_low & PHY_REVISION_MASK);
> >>> hw->phy_revision = (uint32_t) phy_id_low & ~PHY_REVISION_MASK;
> >>>
> >>> +   if (hw->phy_id == 0xA0044E90)
> >>> +   hw->phy_id = I210_I_PHY_ID;
> >>> +
> >>> switch (hw->mac_type) {
> >>> case em_82543:
> >>> if (hw->phy_id == M88E1000_E_PHY_ID)
> >>> Index: if_em_osdep.h
> >>> ===
> >>> RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v
> >>> retrieving revision 1.12
> >>> diff -u -p -r1.12 if_em_osdep.h
> >>> --- if_em_osdep.h   5 Oct 2011 02:52:10 -   1.12
> >>> +++ if_em_osdep.h   29 Oct 2015 03:27:36 -
> >>> @@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE.
> >>>
> >>>  #define MSGOUT(S, A, B)printf(S "\n", A, B)
> >>>  #define DEBUGFUNC(F)   DEBUGOUT(F);
> >>> -#ifdef DBG
> >>> +//#ifdef DBG
> >>> +#if 1
> >>> #define DEBUGOUT(S) printf(S "\n")
> >>> #define DEBUGOUT1(S,A)  printf(S "\n",A)
> >>> #define DEBUGOUT2(S,A,B)printf(S "\n",A,B)
> >>>
> >>
> >> THANKS for your time and assistance.
> >>
> >> i now have enough networking to commence an installation, which is in
> >> progress. i'll have to build
> >> and copy in a new kernel of course to use the booted system afterward.
> >> assuming nothing is shown
> >> broken in the dmesg below, what do i need to do in order to get this
> >> change (or another fix which
> >> would not require this change, if this was just an improper hack)
> >> committed?
> >>
> >>
> > HOLD THE PRESSES!
> >
> > after the installation and reboot, just prior to copying the rebuild
> > kernel that was to provide networking,
> > i notice that networking is in fact working. so somehow, with regard to
> > this specific network interface,
> > there was a disparity between bsd.rd and bsd (GENERIC) kernels. i'll try
> > to run this through its paces
> > with vlans and other such things, but at the moment it looks like GENERIC
> > from 5.8 actually works as
> > it should without any changes. perhaps it's time to dust off the old usb
> > installer sticks and forgo pxe for
> > these little devices. at least for the time being ...
> >
> > is it safe to assume that the disparity between bsd.rd and bsd is due to
> > trimming to keep the image at
> > a minimum? i know other things are removed from bsd.rd for this purpose
> > ... and if not, does this point
> > to a bug for which i need to make a report?
> >
> > thanks again for your assistance, Jonathan!
> >
> >
> >
> Jonathan wondered whether the issue was related to trimming of bsd.rd or
> possibly
> pxe leaving the interface in an incorrect state. the email never came to
> me, but i saw
> it on the list so i'll reply to this, the last message i do see in my inbox.
> 
> i installed 5.8 to a usb stick and used that to boot bsd.rd on the fitlet.
> the problem
> did not show up there - so the issue must be related to pxe.
> 
> if this means i should be reporting somehow, please point me in the right
> direction;
> i'm not sure if that would be a bug in the pxe code on the interface
> firmware or in the
> pxeboot code from openbsd. and i'd have no idea how to find the answer.
> 

There is likely something that is not being initialised or reset
correctly.  Unfortunately it is hard to think of where to start
looking for the problem.

Re: Ethernet not working

[Jonathan Gray]

On Wed, Nov 04, 2015 at 10:15:11AM +0100, Stefan Sperling wrote:
> On Wed, Nov 04, 2015 at 01:53:33PM +0530, Jay Patel wrote:
> > "Attansic Technology AR8172" rev 0x10 at pci1 dev 0 function 0 not 
> > configured
> 
> That's your ethernet device. The 'not configured' message means
> there is no driver support in OpenBSD for this device yet.
> 
> It looks like Linux has a driver for it, called alx.
> 
> FreeBSD does not have a driver for this device either.

FreeBSD and NetBSD had sizable patches to alc(4) to support
that and related variants.  Anyone interested in making
these parts work should look at those patches.

Re: Iked, ca_getreq: no valid local certificate found

[Jonathan Gray]

Which release or snapshot are you running?  For the version of the file
Reyk pointed you at you'll need a -current snapshot.

On Thu, Nov 05, 2015 at 12:58:29PM -0500, Toyam Cox wrote:
> This got me past that error pretty handidly.
> 
> However, now it is complaining about no index.txt. The path given
> doesn't help me know where to put the index.txt
> 
> Getting Private key
> Using configuration from /etc/ssl/ikeca.cnf
> index.txt: No such file or directory
> unable to open 'index.txt'
> 250120122244:error:02001002:system library:fopen:No such file or
> directory:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:255:fopen('index.txt',
> 'r')
> 250120122244:error:20074002:BIO routines:FILE_CTRL:system
> lib:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:257:
> 
> On Thu, Nov 5, 2015 at 7:48 AM, Reyk Floeter  wrote:
> > Copy ikeca.cnf from the ipsecctl source tree to /etc/ssl/ and retry.
> >
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/ikectl/ikeca.cnf
> >
> > The openssl.cnf version broke and we somehow didn't install ikeca.cnf by 
> > default.
> >
> > Reyk
> >
> >> On 05.11.2015, at 08:28, Toyam Cox  wrote:
> >>
> >> Ho misc@,
> >>
> >> I have been (loosely) following the guide at
> >> http://puffysecurity.com/wiki/openikedoffshore.html and have run into
> >> a roadblock.
> >>
> >> I have packets going between my two hosts on different networks, the
> >> configuration files on both are good, and both have the ca installed.
> >>
> >> However on my remote host, I get (ips and hostnames redacted):
> >> Nov  5 01:38:14 hostname iked[7047]: ikev2_msg_send: IKE_SA_INIT
> >> request from $local_wan:500 to $remote.168:500 msgid 0, 534 bytes
> >> Nov  5 01:38:14 hostname iked[7047]: ikev2_recv: IKE_SA_INIT response
> >> from responder $remote8:500 to $local:500 policy 'policy1' id 0, 471
> >> bytes
> >> Nov  5 01:38:14 hostname iked[12679]: ca_getreq: no valid local
> >> certificate found
> >>
> >> This is coupled with, as I create the ca key...
> >> # ikectl ca vpn1 create
> >> CA passphrase:
> >> Retype CA passphrase:
> >> [stuff-happens-and-inputs]
> >> Getting Private key
> >> Using configuration from /etc/ssl/openssl.cnf
> >> variable lookup failed for ca::default_ca
> >> 24387713617796:error:0E06D06C:configuration file
> >> routines:NCONF_get_string:no
> >> value:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/conf/conf_lib.c:323:group=ca
> >> name=default_ca
> >>
> >> I've checked the mail logs for misc@ and found a person in August with
> >> this problem, http://marc.info/?l=openbsd-misc&m=133675466519976&w=2
> >>
> >> Unfortunately, editing /etc/ssl/x509v3.cnf didn't work for me.
> >> Variable lookup still failed.
> >>
> >> Thank you for any help.

Re: Iked, ca_getreq: no valid local certificate found

[Jonathan Gray]

On Fri, Nov 06, 2015 at 12:24:30AM -0500, Toyam Cox wrote:
> I'm running 5.8-release.

ikectl ca in 5.8 is non-functional as LibreSSL removed support for
environment variables in openssl cnf files and this was not
noticed/fixed until after 5.8.

Here is a patch against 5.8 that adds the changes to cope with that.

Index: Makefile
===
RCS file: /cvs/src/usr.sbin/ikectl/Makefile,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- Makefile18 Jan 2014 05:54:51 -  1.3
+++ Makefile19 Aug 2015 12:25:59 -  1.4
@@ -1,9 +1,9 @@
-# $OpenBSD: Makefile,v 1.3 2014/01/18 05:54:51 martynas Exp $
+# $OpenBSD: Makefile,v 1.4 2015/08/19 12:25:59 reyk Exp $
 
 .PATH: ${.CURDIR}/../../sbin/iked
 
 PROG=  ikectl
-SRCS=  log.c ikeca.c ikectl.c parser.c
+SRCS=  log.c ikeca.c ikectl.c parser.c util.c
 
 MAN=   ikectl.8
 
Index: ikeca.c
===
RCS file: /cvs/src/usr.sbin/ikectl/ikeca.c,v
retrieving revision 1.30
retrieving revision 1.33
diff -u -p -r1.30 -r1.33
--- ikeca.c 16 Jan 2015 06:40:17 -  1.30
+++ ikeca.c 19 Aug 2015 12:25:59 -  1.33
@@ -1,4 +1,4 @@
-/* $OpenBSD: ikeca.c,v 1.30 2015/01/16 06:40:17 deraadt Exp $  */
+/* $OpenBSD: ikeca.c,v 1.33 2015/08/19 12:25:59 reyk Exp $ */
 
 /*
  * Copyright (c) 2010 Jonathan Gray 
@@ -82,13 +82,39 @@ struct {
{ "/private",   0700 }
 };
 
-int ca_sign(struct ca *, char *, int, char *);
+/* explicitly list allowed variables */
+const char *ca_env[][2] = {
+   { "$ENV::CADB", NULL },
+   { "$ENV::CERTFQDN", NULL },
+   { "$ENV::CERTIP", NULL },
+   { "$ENV::CERTPATHLEN", NULL },
+   { "$ENV::CERTUSAGE", NULL },
+   { "$ENV::CERT_C", NULL },
+   { "$ENV::CERT_CN", NULL },
+   { "$ENV::CERT_EMAIL", NULL },
+   { "$ENV::CERT_L", NULL },
+   { "$ENV::CERT_O", NULL },
+   { "$ENV::CERT_OU", NULL },
+   { "$ENV::CERT_ST", NULL },
+   { "$ENV::EXTCERTUSAGE", NULL },
+   { "$ENV::NSCERTTYPE", NULL },
+   { NULL }
+};
+
+int ca_sign(struct ca *, char *, int);
 int ca_request(struct ca *, char *);
 int ca_newpass(char *, char *);
 char *  ca_readpass(char *, size_t *);
 int fcopy(char *, char *, mode_t);
+int fcopy_env(const char *, const char *, mode_t);
 int rm_dir(char *);
 int ca_hier(char *);
+voidca_setenv(const char *, const char *);
+voidca_clrenv(void);
+voidca_setcnf(struct ca *, const char *);
+
+/* util.c */
+int expand_string(char *, size_t, const char *, const char *);
 
 int
 ca_delete(struct ca *ca)
@@ -173,10 +199,13 @@ ca_request(struct ca *ca, char *keyname)
charcmd[PATH_MAX * 2];
charpath[PATH_MAX];
 
+   ca_setenv("$ENV::CERT_CN", keyname);
+   ca_setcnf(ca, keyname);
+
snprintf(path, sizeof(path), "%s/private/%s.csr", ca->sslpath, keyname);
-   snprintf(cmd, sizeof(cmd), "env CERT_CN=%s %s req %s-new"
+   snprintf(cmd, sizeof(cmd), "%s req %s-new"
" -key %s/private/%s.key -out %s -config %s",
-   keyname, PATH_OPENSSL, ca->batch, ca->sslpath, keyname,
+   PATH_OPENSSL, ca->batch, ca->sslpath, keyname,
path, ca->sslcnf);
 
system(cmd);
@@ -186,40 +215,40 @@ ca_request(struct ca *ca, char *keyname)
 }
 
 int
-ca_sign(struct ca *ca, char *keyname, int type, char *envargs)
+ca_sign(struct ca *ca, char *keyname, int type)
 {
charcmd[PATH_MAX * 2];
charhostname[HOST_NAME_MAX+1];
charname[128];
+   const char  *extensions = NULL;
 
strlcpy(name, keyname, sizeof(name));
 
-   if (envargs == NULL)
-   envargs = "";
-
if (type == HOST_IPADDR) {
-   snprintf(cmd, sizeof(cmd), "env CERTIP=%s%s %s x509 -req"
-   " -days 365 -in %s/private/%s.csr"
-   " -CA %s/ca.crt -CAkey %s/private/ca.key -CAcreateserial"
-   " -extfile %s -extensions x509v3_IPAddr -out %s/%s.crt"
-   " -passin file:%s", name, envargs, PATH_OPENSSL,
-   ca->sslpath, keyname, ca->sslpath, ca->sslpath,
-   ca->extcnf, ca->sslpath, keyname, ca->passfile);
+   ca_setenv("$ENV::CERTIP", name);
+   extensions = "x509v3_IPAddr";
} else if (type == HOST_FQDN) {
if (!strcmp(keyname, &quo

Re: No sound on speaker with azalia and Intel HD 3400

[Jonathan Gray]

On Mon, Nov 16, 2015 at 06:02:38PM +, Mike Cond wrote:
> Hello, that is my first post on openbsd mailing list.
> I have installed openbsd 5.8 stable on HP Elitebook 2540p and encountered a
> problem with sound system.
> It's a Intel HD 3400 version 0.5 . The kernel uses azalia driver.
> There is sound on hp2 (headphone) but no sound on speaker.
> I tested all setting on mixerctl without positive result.
> The media buttons (mut on/off) is always off. Pressing the button works -
> Hp (actually dac 0:1 is muted and unmuted) but button led is always red
> (muted).??During the power down process is the button for short time unmuted
> and there is noise through speaker.
> I could not find a solution. Here the dmesg, mixerctl and audioctl:

Can you try the below patch and include the "pcidump -v" output as well?

Index: sys/dev/pci/azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.170
diff -u -p -r1.170 azalia_codec.c
--- sys/dev/pci/azalia_codec.c  24 Aug 2015 04:50:40 -  1.170
+++ sys/dev/pci/azalia_codec.c  17 Nov 2015 02:18:38 -
@@ -228,6 +228,7 @@ azalia_codec_init_vtbl(codec_t *this)
break;
case 0x111d7603:
this->name = "IDT 92HD75B3/4";
+   this->qrks |= AZ_QRK_GPIO_UNMUTE_0;
break;
case 0x111d7604:
this->name = "IDT 92HD83C1X";

Re: VGC-LV50DB: Intel G45: Xorg does not work in native 1920x1200 mode

[Jonathan Gray]

On Wed, Nov 18, 2015 at 03:30:57PM +, OpenBSD user wrote:
> Dear misc@,
> 
> It would be really nice if someone could give me any hint(s) on how to
> get a native 1920x1200 working on VGC-LV50DB. As it is, only 1600x1200
> works out of the box.
> 
> Right side of the monitor results in black 320(?)x1200, not usable space.
> Panning (for 1920x1200) does work, but only in the 1600x1200 area.
> Custom mode setting (through cvt) does not work either.
> 
> There are no related changeable values in the BIOS.
> 
> xrandr:
> Screen 0: minimum 8 x 8, current 1600 x 1200, maximum 32767 x 32767
> LVDS1 connected 1600x1200+0+0 (normal left inverted right x axis y
> axis) 0mm x 0mm
>1600x1200 60.00*+
> VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 
> 0mm
>1024x768  60.00*
>800x600   60.3256.25
>848x480   60.00
>640x480   59.94
> VIRTUAL1 disconnected (normal left inverted right x axis y axis)

So the vga output isn't actually present/connected?

A bit of a long shot but you could try the following:

Index: sys/dev/pci/drm/i915/intel_display.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_display.c,v
retrieving revision 1.56
diff -u -p -r1.56 intel_display.c
--- sys/dev/pci/drm/i915/intel_display.c25 Sep 2015 09:42:14 -  
1.56
+++ sys/dev/pci/drm/i915/intel_display.c18 Nov 2015 15:57:22 -
@@ -10850,6 +10850,9 @@ static struct intel_quirk intel_quirks[]
/* Sony Vaio Y cannot use SSC on LVDS */
{ 0x0046, 0x104d, 0x9076, quirk_ssc_force_disable },
 
+   /* Sony VGC-LV50DB cannot use SSC on LVDS */
+   { 0x2e22, 0x104d, 0x9043, quirk_ssc_force_disable },
+
/* Acer Aspire 5734Z must invert backlight brightness */
{ 0x2a42, 0x1025, 0x0459, quirk_invert_brightness },

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[Jonathan Gray]

On Thu, Nov 26, 2015 at 11:51:03AM -0500, Joe Gidi wrote:
> The newly installed system boots successfully, but then it seems to fail
> to initialize video properly at the end of the boot process. My monitor
> goes into an endless cycle of trying to sync up. I can ssh in and see this
> in /var/log/messages:
> 
> Nov 26 11:45:55 opteron /bsd: root on sd0a (ef051b8fc18f2fbe.a) swap on
> sd0b dump on sd0b
> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
> Nov 26 11:45:55 opteron /bsd: drm:pid0:evergreen_init *ERROR* disabling
> GPU acceleration
> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
> 0x802922c0 unpin not necessary
> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
> 0x802922c0 unpin not necessary
> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
> Nov 26 11:45:55 opteron /bsd: error: [drm:pid0:radeonfb_create] *ERROR*
> failed to create fbcon object -12
> Nov 26 11:45:55 opteron ntpd[27846]: /var/db/ntpd.drift is empty
> Nov 26 11:45:55 opteron savecore: no core dump
> 
> My video card is:
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
> drm0 at radeondrm0
> radeondrm0: msi
> 
> And the radeondrm-firmware-20150927 package is installed.

Can you include a full dmesg when booted via uefi with radeondrm
still enabled? pcidump -v output would be helpful as well.

We may have to read the video bios out of the acpi VFCT table
when booting via efi and the radeondrm code doesn't do that currently.

Re: em0 ... cannot find mem space

[Jonathan Gray]

On Fri, Nov 27, 2015 at 12:56:36AM +0100, Mikkel C. Simonsen wrote:
> Today I installed an Intel 82546EB dual-port NIC in a Fujitsu Siemens
> Futro S400, that I plan to use as a router/firewall.
> 
> Only one of the interfaces shows up in dmesg, and it's not working after
> boot. Is this a known problem, and is there a fix? Full dmesg attached.
> 
> Mikkel C. Simonsen

It sounds like your system didn't setup the pci bar correctly.
pcidump -v will give more details on that.

0x8186 is unheard of for intel pci nics.

Be warned that machines with sis chipsets are horrible, I'm glad they
stopped making them a while back.

> 
> 
> 
> OpenBSD 5.8 (GENERIC) #1066: Sun Aug 16 02:33:00 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
> cache) 1.01 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
> real mem  = 251084800 (239MB)
> avail mem = 233758720 (222MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 05/14/08, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
> 2.2 @ 0xf (31 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0Q"
> date 05/14/2008
> bios0: FUJITSU SIEMENS FUTRO S400
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT
> acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4)
> UAR1(S5) UAR2(S5) PS2M(S5) PS2K(S4) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpitz0 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: PWRB
> bios0: ROM list: 0xc/0xc000 0xcc000/0x4000!
> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: PowerNow! K7 1001 MHz: speeds: 1000 800 667 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> 0:7:1: mem address conflict 0x100/0x10
> 0:7:1: mem address conflict 0x100/0x10
> 0:7:1: mem address conflict 0x100/0x100
> pchb0 at pci0 dev 0 function 0 "SiS 741 PCI" rev 0x03
> sisagp0 at pchb0
> agp0 at sisagp0: aperture at 0xe800, size 0x400
> ppb0 at pci0 dev 1 function 0 "SiS 86C202 AGP" rev 0x00
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 "SiS 6330 VGA" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> pcib0 at pci0 dev 2 function 0 "SiS 85C503 System" rev 0x25
> pciide0 at pci0 dev 2 function 5 "SiS 5513 EIDE" rev 0x00: 741: DMA,
> channel 0 configured to compatibility, channel 1 configured to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 1-sector PIO, LBA48, 3815MB, 7813120 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 3 function 0 "SiS 5597/5598 USB" rev 0x0f: irq 3,
> version 1.0, legacy support
> ohci1 at pci0 dev 3 function 1 "SiS 5597/5598 USB" rev 0x0f: irq 5,
> version 1.0, legacy support
> ehci0 at pci0 dev 3 function 3 "SiS 7002 USB" rev 0x00: irq 12
> ehci0: timed out waiting for BIOS
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "SiS EHCI root hub" rev 2.00z/1.00 addr 1
> em0 at pci0 dev 7 function 0 "Intel 82546EB" rev 0x01: cannot find mem space
> unknown vendor 0x8186 product 0x1010 (class network subclass ethernet,
> rev 0x01) at pci0 dev 7 function 1 not configured
> re0 at pci0 dev 9 function 0 "Realtek 8169SC" rev 0x10: RTL8169/8110SCd
> (0x1800), irq 15, address 00:90:dc:a3:5e:c3
> rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 2
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbc0: unable to establish interrupt for irq 12pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> wbsio0 at isa0 port 0x2e/2: W83697HF rev 0x12
> lm1 at wbsio0 port 0x290/8: W83697HF
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> usb1 at ohci0: USB revision 1.0
> uhub1 at usb1 "SiS OHCI root hub" rev 1.00/1.00 addr 1
> usb2 at ohci1: USB revision 1.0
> uhub2 at usb2 "SiS OHCI root hub" rev 1.00/1.00 addr 1
> umass0 at uhub1 port 2 configuration 1 interface 0 "TEAC TEAC FD-05PUB"
> rev 1.10/0.00 addr 2
> umass0: using UFI over CBI with CCI
> scsibus1 at umass0: 2 targets, initiator 0
> sd0 at scsibus1 targ 1 lun 0:  ATAPI 0/direct
> removable
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> root on wd0a (558bcbde01142a1f.a) swap on wd0b dump on wd0b

Re: Puzzled over setting non-VESA mode for intel in xorg.conf

[Jonathan Gray]

The intel xorg driver requires inteldrm for mode setting.

Initial support for Broadwell/5500 was added to inteldrm
after 5.8 and is available in -current/snapshots.

On Mon, Dec 14, 2015 at 05:29:19PM +, Mark Carroll wrote:
> I'm following the OPENBSD_5_8 tag for src and xenocara on a system that
> reports,
> 
> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09
> intagp at vga1 not configured
> 
> pcidump reports that as,
> 
>  0:2:0: Intel HD Graphics 5500
> 0x: Vendor ID: 8086 Product ID: 1616
> 
> I set machdep.allowaperture=2 and have been using xorg and it defaults
> to 1920x1080 on monitors for which that is fine. However, today I tried
> it on a monitor for which the best resolution is 1360x768 and I just
> can't get xorg to do that:
> 
> On a Linux system (with a Radeon card) I just set an appropriate
> modeline in xorg.conf and the radeon driver happily takes it and gives
> me that mode. Indeed, even if I don't supply a modeline on my OpenBSD
> system, the Xorg.0.log still reports something similar from EDID,
> 
> (II) VESA(0): Modeline "1366x768"x59.8   84.75  1366 1431 1567 1776  768 771 
> 781 798 -hsync +vsync (47.7 kHz e)
> 
> However, as you can see, it's VESA looking at this. Whether I name
> "1366x768" or my other modeline or whatever, it just says "no mode of
> this name" and goes to 1920x1080. (Indeed, I can imagine it's not a VESA
> mode!)
> 
> The intel driver does report itself, e.g.,
> 
> (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
> (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
> (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300
> (II) VESA: driver for VESA chipsets: vesa
> (II) Loading sub module "vbe"
> (II) LoadModule: "vbe"
> ... but then it's all VESA thereafter in the log.
> 
> If I try setting Driver "intel" in xorg.conf it promptly fails,
> 
> (EE) No devices detected.
> (EE) no screens found(EE)
> 
> I'm happy to share fuller dmesg[1], xorg.conf, Xorg.0.log, etc. if that
> would help. (The xorg.conf that works for this monitor from Linux just
> sets the modeline.) But, from this summary, does anyone have a clue
> what's going on? Why's the intel driver not handling everything, instead
> leaving me stuck with vesa and not letting me set the mode myself? (Of
> course, xrandr in that environment reports only VESA modes.)
> 
> [1] dmesg from an identical system is
> http://permalink.gmane.org/gmane.os.openbsd.misc/226800
> 
> ... is this even the correct place to ask? Is it an OpenBSD issue or a
> more general one with xorg's intel driver? (I don't know to what extent
> kernel support could be an issue.)
> 
> -- Mark

Re: libGL error: failed to open drm device: Permission denied

[Jonathan Gray]

On Mon, Dec 28, 2015 at 12:25:25AM +0200, Mihai Popescu wrote:
> Hello,
> 
> I am running cwm and I had some problems starting chrome from the menu
> - it starts for the very first time when i click on the menu, then i
> have to click 2 or 3 times on menu entry to start chrome again. This
> is not a big deal, maybe a cwm glitch.
> 
> I went to start chrome from xterm, and I got these errors:
> 
> $ chrome
> libGL error: failed to open drm device: Permission denied
> libGL error: failed to load driver: r600
> libGL error: failed to open drm device: Permission denied
> libGL error: failed to load driver: r600
> 
> Is it normal, can it be fixed on my side?

The ownership of /dev/drm0 should be changed according to
/etc/fbtab to your user after logging in.

Can you include the output of ls -l /dev/drm0 and
the contents of /var/log/Xorg.0.log ?

How are you starting X, xdm/startx/?

Re: 3D acceleration in Xenocara on GCN Radeon GPUs, specifically PITCAIRN

[Jonathan Gray]

On Mon, Jan 18, 2016 at 10:41:43AM +0100, Hvard Farberg wrote:
> Is it the case that 3D acceleration does not work for AMD
> PITCAIRN-based GPUs in X on OpenBSD 5.8?
> 
> Is there any documents describing what features work on what GPUs?

Everything should work on northern islands cards and below.
http://xorg.freedesktop.org/wiki/RadeonFeature/ should mostly
describe the situation for those, but it refers to newer drm code/features
in some spots.  OpenGL 3.x is available on radeon with -current
and 5.9.

The handful of southern islands parts the kernel knows about
(TAHITI/PITCAIRN/CAPE VERDE) need a version of Mesa compiled
against a newish version of LLVM (which we can't use from xenocara
currently) then Mesa needs to be compiled with a version of gcc
from ports due to the llvm headers/libraries requiring things
from recent c++ standards.

Re: igmp option 148 (RA)

[Jonathan Gray]

On Thu, Jan 21, 2016 at 11:40:41AM +0100, Stefan Sperling wrote:
> On Thu, Jan 21, 2016 at 12:27:06PM +0200, Kapetanakis Giannis wrote:
> > Hi,
> > 
> > I'm constantly seeing this on my pf router.
> > rule 61/(ip-option) pass in on $ext_if: $ext_gw > 224.0.0.1: igmp query [tos
> > 0xc0] [ttl 1]
> > 
> > Rule 61 is:
> > @61 pass quick inet proto igmp from $ext_if:network to 224.0.0.1 keep state
> > (no-sync)
> > 
> > tcpdump on $ext_if shows:
> > $ext_gw > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 59056, len 32,
> > optlen=4 IPOPT-148{4})
> > 
> > I guess pf has a problem with ip-option 148 which is router alert (rfc2113)
> > Is this normal? Why does it think it's bad?
> > 
> > Ext gateway is cisco (no under my control) which apparently is sending this
> > option.
> > 
> > G
> 
> Multicast traffic is black-holed by default.
> You may want to set multicast_host=Yes in /etc/rc.conf.local.
> See the MULTICAST ROUTING section in the netstart(8) man page.
> 

Note that it is just "multicast" with snapshots and >= 5.9
http://www.openbsd.org/faq/current.html#20151205

Re: "Available disks are: none" on Sony Vaio SVZ13115GGXI

[Jonathan Gray]

On Fri, Jan 29, 2016 at 04:18:04PM +0100, Paul de Weerd wrote:
> Hi Ben,
> 
> Upon another close inspection of your dmesg and mine, I don't think
> the below diff will work for you...
> 
> This is in my machine:
> 
> | +   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_RAID,
> | +   NULL,   ahci_intel_attach },
> 
> And this is in yours:
> 
> | | pciide0 at pci0 dev 31 function 2 "Intel 82081HBM RAID" rev 0x04: DMA,
> | | channel 0 wired to native-PCI, channel 1 wired to native-PCI
> | | pciide0: using apic 0 int 22 for native-PCI interrupt
> 
> Although they look quite the same, 82081 != 82801.  Sorry :(
> 
> You could try adding the product id of your controller to ahci.c much
> like I did in my diff and try that.  Good luck!
> 
> Paul 'WEiRD' de Weerd

They are the same, the string in pcidevs was wrong.  I just commited
a change to fix it.

Re: Cannot Cleanly Exit FVWM / X Windows System

[Jonathan Gray]

On Thu, Feb 04, 2016 at 08:39:43AM +, David Dahlberg wrote:
> Am Mittwoch, den 03.02.2016, 15:29 -0500 schrieb Samir Parikh:
> >  I am running version 5.8 (amd64) on a Lenovo Thinkpad T450s 
> > with a fairly default installation.
> 
> The T405s is a Broadwell.
> 
> > I have a few issues to sort out but my first concern is that I cannot 
> > exit out of FVWM.  I launch it via the command startx while logged in
> > as 
> > root.  When I go to exit (left mouse click on the desktop > Exit),
> > the 
> > system just hangs which requires me to forcefully power down the
> > laptop. 
> 
> If you investigate more closely, you will probably find out, that the
> system still works, just the graphics is fscked up: Try logging in via
> ssh, or shutting down the system by blindly typing into ttyC0.
> 
> Broadwell graphics support was added a while ago. IIRC 5.8 should have
> some basic support, but still a few bugs. By now (-current) it is petty
> stable though.
> 
> > Any ideas or suggestions?
> 
> 1) Use modesetting(4) in xorg.conf and wait for 5.9

The update that added Broadwell related parts to inteldrm went in after
5.8.  The modesetting driver requires kms support.  So yes, use snapshots.

> 2) Avoid the vulnerable code paths (e.g. "shutdown" in wm)
>    and wait for 5.9   
> 3) Update to a recent snapshot.

Re: Radeon discrete graphics issues

[Jonathan Gray]

On Sat, Nov 18, 2017 at 07:43:03PM +, Timothy Legge wrote:
> @Maurice, Don't worry about teaching me to suck eggs, I'd rather cover all
> the bases :)
> 
> I've run "fw_update -a"  to ensure that the drivers are installed and where
> they need to be. (Bit overkill I know, but I'd rather be sure at this
> point.)
> As for support from the Radeon driver as linked above, it falls under the
> "OLAND Radeon HD 8000 series".

The radeon code in the kernel is derived from Linux 3.8, support for
the OLAND family wasn't added till 3.9.

> It's almost as though the kernel forgets to add "radeondrm0 at vga1" and
> "drm0 at radeondrm0" as seen on other dmesg from systems with Radeon cards.
> I can't help shake the sense that the fix to this is going to be something
> rather simple, and I'm just too stupid to figure it out! :)
> 
> On 18 November 2017 at 19:14, Maurice McCarthy  wrote:
> 
> > I assume the radeon firmware is in /etc/firmware. If not download
> > http://firmware.openbsd.org/firmware/6.2/radeondrm-firmware-20150927.tgz
> > and untar it in that directory. (Sorry if I'm teaching granny to suck
> > eggs.)
> >
> >
> >  > source=link&utm_campaign=sig-email&utm_content=webmail>
> > Virus-free.
> > www.avast.com
> >  > source=link&utm_campaign=sig-email&utm_content=webmail>
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >

Re: Radeon discrete graphics issues

[Jonathan Gray]

The userland driver that page describes won't work without kernel support.

For GCN parts like OLAND it is worse as they require Mesa to be built
against LLVM libraries for 2D acceleration.  And LLVM libraries/llvm-config
etc are not built/shipped in base.

On Sun, Nov 19, 2017 at 01:16:19AM +, Timothy Legge wrote:
> I copy/pasted "OLAND Radeon HD 8000 series" from the radeon(4)
> <https://man.openbsd.org/radeon> man page under the section header
> "Supported Hardware". Maybe I'm missing something.
> 
> On 19 November 2017 at 01:08, Jonathan Gray  wrote:
> 
> > On Sat, Nov 18, 2017 at 07:43:03PM +, Timothy Legge wrote:
> > > @Maurice, Don't worry about teaching me to suck eggs, I'd rather cover
> > all
> > > the bases :)
> > >
> > > I've run "fw_update -a"  to ensure that the drivers are installed and
> > where
> > > they need to be. (Bit overkill I know, but I'd rather be sure at this
> > > point.)
> > > As for support from the Radeon driver as linked above, it falls under the
> > > "OLAND Radeon HD 8000 series".
> >
> > The radeon code in the kernel is derived from Linux 3.8, support for
> > the OLAND family wasn't added till 3.9.
> >
> > > It's almost as though the kernel forgets to add "radeondrm0 at vga1" and
> > > "drm0 at radeondrm0" as seen on other dmesg from systems with Radeon
> > cards.
> > > I can't help shake the sense that the fix to this is going to be
> > something
> > > rather simple, and I'm just too stupid to figure it out! :)
> > >
> > > On 18 November 2017 at 19:14, Maurice McCarthy 
> > wrote:
> > >
> > > > I assume the radeon firmware is in /etc/firmware. If not download
> > > > http://firmware.openbsd.org/firmware/6.2/radeondrm-
> > firmware-20150927.tgz
> > > > and untar it in that directory. (Sorry if I'm teaching granny to suck
> > > > eggs.)
> > > >
> > > >
> > > > <https://www.avast.com/sig-email?utm_medium=email&utm_
> > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > Virus-free.
> > > > www.avast.com
> > > > <https://www.avast.com/sig-email?utm_medium=email&utm_
> > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > >
> >

Re: Radeon discrete graphics issues

[Jonathan Gray]

There is kernel support for the initial GCN parts
(CAPE VERDE, PITCAIRN, TAHITI) acceleration for those requires userland
changes.  The last generation with full acceleration is Northern Islands.

On Sun, Nov 19, 2017 at 09:04:40AM +, Timothy Legge wrote:
> So after re-reading man pages and a quick consultation of some Wikipedia
> pages, kernel support for most Radeon cards upto those in the Northern
> Islands family are supported. That ties in nicely with what you've outlined
> as thats the family that came before they made the change to the GCN
> Microarchitecture and Instruction set.
> 
> Hopefully it's something that will be supported in the not too distant
> future.Until then, it's back in my box.
> 
> Thanks all.
> 
> On 19 November 2017 at 01:34, Jonathan Gray  wrote:
> 
> > The userland driver that page describes won't work without kernel support.
> >
> > For GCN parts like OLAND it is worse as they require Mesa to be built
> > against LLVM libraries for 2D acceleration.  And LLVM libraries/llvm-config
> > etc are not built/shipped in base.
> >
> > On Sun, Nov 19, 2017 at 01:16:19AM +, Timothy Legge wrote:
> > > I copy/pasted "OLAND Radeon HD 8000 series" from the radeon(4)
> > > <https://man.openbsd.org/radeon> man page under the section header
> > > "Supported Hardware". Maybe I'm missing something.
> > >
> > > On 19 November 2017 at 01:08, Jonathan Gray  wrote:
> > >
> > > > On Sat, Nov 18, 2017 at 07:43:03PM +, Timothy Legge wrote:
> > > > > @Maurice, Don't worry about teaching me to suck eggs, I'd rather
> > cover
> > > > all
> > > > > the bases :)
> > > > >
> > > > > I've run "fw_update -a"  to ensure that the drivers are installed and
> > > > where
> > > > > they need to be. (Bit overkill I know, but I'd rather be sure at this
> > > > > point.)
> > > > > As for support from the Radeon driver as linked above, it falls
> > under the
> > > > > "OLAND Radeon HD 8000 series".
> > > >
> > > > The radeon code in the kernel is derived from Linux 3.8, support for
> > > > the OLAND family wasn't added till 3.9.
> > > >
> > > > > It's almost as though the kernel forgets to add "radeondrm0 at vga1"
> > and
> > > > > "drm0 at radeondrm0" as seen on other dmesg from systems with Radeon
> > > > cards.
> > > > > I can't help shake the sense that the fix to this is going to be
> > > > something
> > > > > rather simple, and I'm just too stupid to figure it out! :)
> > > > >
> > > > > On 18 November 2017 at 19:14, Maurice McCarthy 
> > > > wrote:
> > > > >
> > > > > > I assume the radeon firmware is in /etc/firmware. If not download
> > > > > > http://firmware.openbsd.org/firmware/6.2/radeondrm-
> > > > firmware-20150927.tgz
> > > > > > and untar it in that directory. (Sorry if I'm teaching granny to
> > suck
> > > > > > eggs.)
> > > > > >
> > > > > >
> > > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_
> > > > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > > > Virus-free.
> > > > > > www.avast.com
> > > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_
> > > > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > > >
> > > >
> >

Re: no sound by "Intel 6321ESB HD Audio"

[Jonathan Gray]

On Mon, Dec 04, 2017 at 01:37:53PM +0900, Tuyosi T wrote:
> i install openbsd 6.2 into mac pro 2006 .
> (boot by fedora's grub )
> 
> but i cannot hear sound .
> 
> $ dmesg | grep audio
> audio0 at azalia0
> 
> $ dmesg | grep azalia
> azalia0 at pci0 dev 27 function 0 "Intel 6321ESB HD Audio" rev 0x09: msi
> azalia0: codecs: Realtek ALC885
> audio0 at azalia0
> 
> are there any advices ?
> ---
> regards

Try the following diff though it may need a further quirk.

And include a full dmesg and pcidump -v output.

Index: sys/dev/pci/azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.172
diff -u -p -r1.172 azalia_codec.c
--- sys/dev/pci/azalia_codec.c  28 Mar 2017 04:54:44 -  1.172
+++ sys/dev/pci/azalia_codec.c  4 Dec 2017 05:20:35 -
@@ -205,6 +205,14 @@ azalia_codec_init_vtbl(codec_t *this)
this->subid == 0x00a3106b) {/* APPLE_MB4 */
this->qrks |= AZ_QRK_GPIO_UNMUTE_0;
}
+   if (this->subid == 0x1000106b ||/* iMac 24 */
+   this->subid == 0x2800106b ||/* AppleTV */
+   this->subid == 0x3e00106b ||/* iMac 24 Aluminum */
+   this->subid == 0x0c00106b ||/* Mac Pro */
+   this->subid == 0x4200106b) {/* Mac Pro 4,1/5,1 */
+   this->qrks |= AZ_QRK_GPIO_UNMUTE_0 |
+   AZ_QRK_GPIO_UNMUTE_1;
+   }
if (this->subid == 0x00a1106b ||
this->subid == 0xcb7910de ||/* APPLE_MACMINI3_1 
(internal spkr) */
this->subid == 0x00a0106b)

Re: AMD Pro A10/A12 Radeon R7 Support

[Jonathan Gray]

On Mon, Jan 22, 2018 at 10:43:03AM -0800, Bryan Vyhmeister wrote:
> I have been looking at the new Lenovo ThinkPad A275 which is much like
> the X260/X270 but with AMD Pro A10 or A12 chip and graphics. I am
> interested in looking at something other than Intel for the first time
> in more than a decade. I am interested in radeondrm(4) support for any
> of the options available which are the AMD Pro A10-8730B, AMD Pro
> A10-9700B, or AMD Pro A12-9800B. I am personally most interested in
> ordering the AMD Pro A12-9800B. Any possilibity that radeondrm(4) might
> work for these chips in some fashion?
> 
> Bryan
> 

CARRIZO parts like that would require a new amdgpu drm driver.

Re: AMD Pro A10/A12 Radeon R7 Support

[Jonathan Gray]

On Mon, Jan 22, 2018 at 07:06:32PM -0800, Bryan Vyhmeister wrote:
> On Tue, Jan 23, 2018 at 11:57:35AM +1100, Jonathan Gray wrote:
> > On Mon, Jan 22, 2018 at 10:43:03AM -0800, Bryan Vyhmeister wrote:
> > > I have been looking at the new Lenovo ThinkPad A275 which is much like
> > > the X260/X270 but with AMD Pro A10 or A12 chip and graphics. I am
> > > interested in looking at something other than Intel for the first time
> > > in more than a decade. I am interested in radeondrm(4) support for any
> > > of the options available which are the AMD Pro A10-8730B, AMD Pro
> > > A10-9700B, or AMD Pro A12-9800B. I am personally most interested in
> > > ordering the AMD Pro A12-9800B. Any possilibity that radeondrm(4) might
> > > work for these chips in some fashion?
> > 
> > CARRIZO parts like that would require a new amdgpu drm driver.
> 
> Understood. I will not get an A275 then. As far as radeondrm(4) support
> goes, is my understanding from previous discussions correct that Radeon
> HD 7750 or 7870 cards have kernel support but would have to be used
> through the modesetting(4) driver in Xorg? I am still looking at those
> cards for 4k monitor support for multiple monitors on a system that does
> not have integrated graphics (Xeon E5 for example). In particular the
> four mDP or six mDP cards are interesting to me. Thanks again.

The GCN parts like the 7750 (Cape VERDE) 7870 (PITCAIRN) will use
the radeon xorg driver but will not have acceleration until the userland
parts are sorted out which involves changing how LLVM is built, adding
additional dependencies like libelf to base or xenocara and changing
how Mesa is built.

I am looking into a radeondrm update that would add modesetting support
for second generation GCN/sea islands parts and some more first
generation southern islands parts.

ie, OLAND/HAINAN/BONAIRE/KABINI/MULLINS/KAVERI/HAWAII.

Re: Support for AMD/ATI Firepro M7820

[Jonathan Gray]

On Sat, Feb 10, 2018 at 03:18:22PM -0800, Raymond Lillard wrote:
> I have a Dell M6500 Precision workstation with an Nvidia FX 3800M.
> 
> I would like to wipe it and install OBSD. I can get a Firepro M7820
> for it.?? If I do, will any of the OBSD drivers work or will I
> be stuck with fb performance.

It looks like that has a product id of 0x68a0 which is a JUNIPER radeon
comparable to a Mobility Radeon HD 5870.  JUNIPER is part of the
evergreen generation which has modesetting and 2d/3d acceleration with
the in tree radeondrm(4) and Mesa 13.0.6.

> 
> I see no mention of Firepro on the OBSD web site and google is
> no help either.

Each radeon part can have many different marketing names for each
variant that change each time they change the marketing names and
rebadge the old parts.

The kernel and userland code generally refers to codenames and
there isn't any one place that has an exhaustive mapping.

https://www.x.org/wiki/RadeonFeature/
https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units
https://en.wikipedia.org/wiki/List_of_AMD_accelerated_processing_unit_microprocessors
src/sys/dev/pci/drm/drm_pciids.h

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_pciids.h?h=v4.15
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c?h=v4.15#n469

Re: drm permissions error with i965 on amd64 6.2 with libGL applications

[Jonathan Gray]

On Sat, Mar 03, 2018 at 06:48:21AM -0600, ed...@pettijohn-web.com wrote:
> 
> On Mar 3, 2018 5:52 AM, Z Ero  wrote:
> >
> > "libGL error: failed to open drm device: Permission denied
> > libGL error: failed to load driver: i965"
> >
> > I can solve it by changing the permissions on /dev/drm0 to rw for users but:
> >
> > (1) I am not sure if that introduces a realistic security risk.
> 
> I don't know.
> 
> > (2) The permissions are reverted on reboot making a minor annoyance to
> > reset them.
> >
> /etc/rc.local
> chmod o+rw /dev/drm0

Do not do that.  Ownership is set on login via /etc/fbtab.

Re: System hangs after detecting radeondrm

[Jonathan Gray]

On Sun, Mar 11, 2018 at 12:15:11AM +, Kaashif Hymabaccus wrote:
> Hello
> 
> I have a sparc64 machine with no real graphics card, only the onboard
> Mach64 framebuffer. I found an ATI Radeon 9200 and decided to see if
> it works, then I could run X, test some graphical ports, etc.
> 
> My problem is that with the GPU connected, the system hangs completely
> and is unresponsive to breaks in the serial line or any form of
> input. I do not have a Sun keyboard, only a USB keyboard connected to
> a PCI USB card (which works with no problem).
> 
> The card itself works fine on an amd64 machine I have, and I did
> preemptively install the radeondrm-firmware package on the
> sparc64. The machine boots up fine if I disable the radeondrm device
> in the kernel.
> 
> This is an unusual setup so I wouldn't be surprised if someone told me
> that it can't work for some reason. The real problem I have is that it
> just hangs and seems a bit hard to debug, so I'd appreciate some
> advice on how to track down the issue myself.

The radeondrm code is designed to take over the console on sparc64.
But the console will only get setup if you have a card with the sun/apple
fcode in the pci option rom.

It may be possible to use a different type of card but it is entirely
possible that path doesn't work at the moment.

radeon cards from sun with fcode

xvr-100 (0x1002:0x5159 pci rv100)
xvr-300 (0x1002:0x5b64 pcie rv380)

> 
> Here is the full output on the serial line:
> 
> Connected to /dev/cuaU0 (speed 9600)
> 
> Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard
> OpenBoot 3.11, 512 MB memory installed, Serial #1653024.
> Ethernet address 8:0:20:19:39:20, Host ID: 80193920.
> 
> 
> 
>   
> ok boot
> Boot device: disk:a  File and args: 
> OpenBSD IEEE 1275 Bootblock 1.4
> ..>> OpenBSD BOOT 1.9
> Trying bsd...
> Booting /pci@1f,0/pci@1,1/ide@3/disk@0,0:a/bsd
> 8491696@0x100+3408@0x18192b0+200624@0x1c0+3993680@0x1c30fb0 
> symbols @ 0xfef18400 165+565992+375599 start=0x100
> [ using 942784 bytes of bsd ELF symbol table ]
> console is /pci@1f,0/pci@1,1/ebus@1/se@14,40:a
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 6.3-beta (GENERIC) #461: Thu Mar  8 23:11:47 MST 2018
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC
> real mem = 536870912 (512MB)
> avail mem = 512303104 (488MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root: Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz)
> cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 1.3) @ 269.808 MHz
> cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 256K external (64 
> b/l)
> psycho0 at mainbus0 addr 0xfffc4000: SUNW,sabre, impl 0, version 0, ign 7c0
> psycho0: bus range 0-2, PCI bus 0
> psycho0: dvma map c000-dfff
> pci0 at psycho0
> ppb0 at pci0 dev 1 function 1 "Sun Simba" rev 0x11
> pci1 at ppb0 bus 1
> ebus0 at pci1 dev 1 function 0 "Sun PCIO EBus2" rev 0x01
> auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, 
> 72c000-72c003, 72f000-72f003
> power0 at ebus0 addr 724000-724003 ivec 0x25
> "SUNW,pll" at ebus0 addr 504000-504002 not configured
> sab0 at ebus0 addr 40-40007f ivec 0x2b: rev 3.2
> sabtty0 at sab0 port 0: console
> sabtty1 at sab0 port 1
> comkbd0 at ebus0 addr 3083f8-3083ff ivec 0x29: no keyboard
> comms0 at ebus0 addr 3062f8-3062ff ivec 0x2a
> wsmouse0 at comms0 mux 0
> lpt0 at ebus0 addr 3043bc-3043cb, 30015c-30015d, 70-7f ivec 0x22: 
> polled
> clock1 at ebus0 addr 0-1fff: mk48t59
> "flashprom" at ebus0 addr 0-f not configured
> audioce0 at ebus0 addr 20-2000ff, 702000-70200f, 704000-70400f, 
> 722000-722003 ivec 0x23 ivec 0x24: nvaddrs 0
> audio0 at audioce0
> hme0 at pci1 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7e1, address 
> 08:00:20:19:39:20
> nsphy0 at hme0 phy 1: DP83840 10/100 PHY, rev. 1
> machfb0 at pci1 dev 2 function 0 "ATI Mach64" rev 0x9a
> machfb0: ATY,GT-B, 1152x900
> wsdisplay0 at machfb0 mux 1
> wsdisplay0: screen 0 added (std, sun emulation)
> pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x03: DMA, 
> channel 0 configured to native-PCI, channel 1 configured to native-PCI
> pciide0: using ivec 0x7e0 for native-PCI interrupt
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA48, 117800MB, 241254720 sectors
> wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
> removable
> cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
> ppb1 at pci0 dev 1 function 0 "Sun Simba" rev 0x11
> pci2 at ppb1 bus 2
> ohci0 at pci2 dev 1 function 0 "NEC USB" rev 0x41: ivec 0x7d0, version 1.0
> ohci1 at pci2 dev 1 function 1 "NEC USB" rev 0x41: ivec 0x7d1, version 1.0
> 

Re: Lenovo X61 (notebook not tablet) does not return from sleep

[Jonathan Gray]

On Thu, Mar 15, 2018 at 10:10:18PM -0700, Mike Larkin wrote:
> On Thu, Mar 15, 2018 at 11:55:53PM -0500, Z Ero wrote:
> > If the adapter is ejected before closing the laptop lid there is no
> > problem waking from sleep. But is a minor inconvenience to eject the
> > adapter. Would it be possible to patch the kernel some how to make it
> > think the adapter is ejected before entering sleep?
> > 
> 
> Possibly. Since likely nobody has a configuration this ancient with the
> same hardware that is causing your trouble, once you have your patch
> ready, please share it here.
> 
> -ml

There are likely few people trying to suspend machines with wdc(4).

wdc_pcmcia_activate() lacks DVACT_SUSPEND and doesn't try to
save registers like pciide does.

On i386 if you disable pciide* wdc will attach which may be helpful for
anyone wanting to look at it with qemu/bochs or machines that normally
attach wd at pciide.

> 
> > On Thu, Mar 15, 2018 at 11:27 PM, Z Ero  wrote:
> > > On 6.2 amd-64 mp ONLY when PC card to CF-II adapter is in PC card slot
> > > and 2Gb Sandisk Ultra II CF media is inserted in adaptor. Repeatable.
> > > No other sleep / wake problems.
> > >
> > > OpenBSD 6.2 (GENERIC.MP) #6: Wed Feb 28 21:13:02 CET 2018
> > > 
> > > r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > real mem = 4201316352 (4006MB)
> > > avail mem = 4066914304 (3878MB)
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (63 entries)
> > > bios0: vendor LENOVO version "7NET25WW (1.06 )" date 07/02/2007
> > > bios0: LENOVO 76754KU
> > > acpi0 at bios0: rev 2
> > > acpi0: sleep states S0 S3 S4 S5
> > > acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT ASF!
> > > SSDT SSDT SSDT SSDT
> > > acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4)
> > > EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3)
> > > USB3(S3) USB4(S3) EHC0(S3) EHC1(S3) [...]
> > > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > > acpiec0 at acpi0
> > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > > cpu0 at mainbus0: apid 0 (boot processor)
> > > cpu0: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz, 798.15 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,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 199MHz
> > > cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> > > cpu1 at mainbus0: apid 1 (application processor)
> > > cpu1: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz, 798.00 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> > > cpu1: 4MB 64b/line 16-way L2 cache
> > > cpu1: smt 0, core 1, package 0
> > > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> > > , remapped to apid 1
> > > acpimcfg0 at acpi0 addr 0xf000, bus 0-63
> > > acpihpet0 at acpi0: 14318179 Hz
> > > acpiprt0 at acpi0: bus 0 (PCI0)
> > > acpiprt1 at acpi0: bus -1 (AGP_)
> > > acpiprt2 at acpi0: bus 2 (EXP0)
> > > acpiprt3 at acpi0: bus 3 (EXP1)
> > > acpiprt4 at acpi0: bus -1 (EXP2)
> > > acpiprt5 at acpi0: bus -1 (EXP3)
> > > acpiprt6 at acpi0: bus -1 (EXP4)
> > > acpiprt7 at acpi0: bus 5 (PCI1)
> > > acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10),
> > > C1(1000@1 mwait.1), PSS
> > > acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10),
> > > C1(1000@1 mwait.1), PSS
> > > acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB4, EHC0, EHC1
> > > acpitz0 at acpi0: critical temperature is 127 degC
> > > acpitz1 at acpi0: critical temperature is 99 degC
> > > acpibtn0 at acpi0: LID_
> > > acpibtn1 at acpi0: SLPB
> > > "IBM3780" at acpi0 not configured
> > > tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x32031114 rev 0x9
> > > acpibat0 at acpi0: BAT0 model "92P1003" serial 19888 type LION oem "SANYO"
> > > acpiac0 at acpi0: AC unit offline
> > > acpithinkpad0 at acpi0
> > > acpidock0 at acpi0: GDCK not docked (0)
> > > acpivideo0 at acpi0: VID_
> > > acpivout0 at acpivideo0: LCD0
> > > acpivideo1 at acpi0: VID_
> > > cpu0: Enhanced SpeedStep 798 MHz: speeds: 2001, 2000, 1600, 1200, 800 MHz
> > > pci0 at mainbus0 bus 0
> > > pchb0 at pci0 dev 0 function 0 "Intel GM965 Host" rev 0x0c
> > > inteldrm0 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x0c
> > > drm0 at inteldrm0
> > > intagp0 at inteldrm0
> > > agp0 at intagp0: aperture at 0xe000, size 0x1000
> > > inteldrm0: msi
> > > inteldrm0: 1024x768, 32bpp
> > > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)

Re: X server keeps crashing in current/amd64

[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&component=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&component=Driver/Radeon],
 [xf86-video-ati])
 
Index: src/drmmode_display.c

Re: X server keeps crashing in current/amd64

[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&content-type=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 Radeon 9600, AT

Re: OpenBSD 6.2 amd64 and ATI Radeon 9550

[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: a

Re: 6.3 : how to check microcode?

[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 a

Re: pine64-lts - can't detect disk

[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: pine64-lts - can't detect disk

[Jonathan Gray]

On Fri, Apr 13, 2018 at 11:05:06AM -0700, jungle Boogie wrote:
> On 13 April 2018 at 09:39, Jonathan Gray  wrote:
> > 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.
> >
> 
> 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: 6.8: page fault

[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)
> acpi

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

[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&rev=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: Issues with Teclast F7 Plus

[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: snapshot kernel panic related to radeondrm missing firmware

[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: Difficulty booting UEFI from DVD

[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: New variant of rtl8168h supported?

[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: New variant of rtl8168h supported?

[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: Does intel(4) support Iris Xe Graphics?

[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&m=161754767328009&w=2
> 
> Regards,
> 
> Michel
> 

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

[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: 6.9 + 001: uvm_fault

[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&m=162012367130138&w=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: OpenBSD on AWS EC2 Nitro

[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

[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&m=162123695228236&w=2

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

Re: ATI Mobility Radeon 7500: radeon: Invalid PCI ID.

[Jonathan Gray]

On Sun, Jul 23, 2023 at 12:10:54AM +0200, Benjamin Stürz wrote:
> Hi misc@,
> 
> I just got an old Thinkpad T40 with an ATI Mobility Radeon 7500 (32MB)
> and installed OpenBSD 7.3-release on it.
> 
> Unfortunately GPU acceleration doesn't work,
> neofetch tells me that my GPU is llvmpipe.
> 
> When I run `glxinfo > /dev/null` I get the following output:
> > radeon: Invalid PCI ID.
> > libGL error: glx: failed to create dri2 screen
> > libGL error: failed to load driver: radeonsi
> 
> I tracked down the error to line 198 of
> /usr/xenocara/lib/mesa/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> 
> The oldest GPU family in the switch stmt is r300, while my GPU is r100.
> This leads me to believe that hardware acceleration for my GPU is not
> supported.

Right.  Mesa removed 'classic' drivers, including r100.  There is a way
to build two different versions of Mesa and put libglvnd in front of
them, but we don't do that.

> 
> At least it's PCI ID is listed in
> /usr/xenocara/driver/xf86-video-ati/src/ati_pciids_gen.h:81
> 
> # pcidump -v> Domain /dev/pci0:
> >  0:0:0: Intel 82855PM Host
> > 0x: Vendor ID: 8086, Product ID: 3340
> > 0x0004: Command: 0106, Status: 2090
> > 0x0008: Class: 06 Bridge, Subclass: 00 Host,
> > Interface: 00, Revision: 03
> > 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> > Cache Line Size: 00
> > 0x0010: BAR mem prefetchable 32bit addr: 0xd000/0x1000
> > 0x0014: BAR empty ()
> > 0x0018: BAR empty ()
> > 0x001c: BAR empty ()
> > 0x0020: BAR empty ()
> > 0x0024: BAR empty ()
> > 0x0028: Cardbus CIS: 
> > 0x002c: Subsystem Vendor ID: 1014 Product ID: 0529
> > 0x0030: Expansion ROM Base Address: 
> > 0x0038: 
> > 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
> > 0x00e4: Capability 0x09: Vendor Specific
> > 0x00a0: Capability 0x02: AGP
> >  0:1:0: Intel 82855PM AGP
> > 0x: Vendor ID: 8086, Product ID: 3341
> > 0x0004: Command: 0107, Status: 00a0
> > 0x0008: Class: 06 Bridge, Subclass: 04 PCI,
> > Interface: 00, Revision: 03
> > 0x000c: BIST: 00, Header Type: 01, Latency Timer: 60,
> > Cache Line Size: 00
> > 0x0010: BAR empty ()
> > 0x0014: BAR empty ()
> > 0x0018: Primary Bus: 0, Secondary Bus: 1, Subordinate Bus: 1,
> > Secondary Latency Timer: 40
> > 0x001c: I/O Base: 30, I/O Limit: 30, Secondary Status: 22a0
> > 0x0020: Memory Base: c010, Memory Limit: c010
> > 0x0024: Prefetch Memory Base: e000, Prefetch Memory Limit: e7f0
> > 0x0028: Prefetch Memory Base Upper 32 Bits: 
> > 0x002c: Prefetch Memory Limit Upper 32 Bits: 
> > 0x0030: I/O Base Upper 16 Bits: , I/O Limit Upper 16 Bits: 
> > 0x0038: Expansion ROM Base Address: 
> > 0x003c: Interrupt Pin: 00, Line: 00, Bridge Control: 000c
> >  0:29:0: Intel 82801DB USB
> > 0x: Vendor ID: 8086, Product ID: 24c2
> > 0x0004: Command: 0005, Status: 0280
> > 0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
> > Interface: 00, Revision: 01
> > 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
> > Cache Line Size: 00
> > 0x0010: BAR empty ()
> > 0x0014: BAR empty ()
> > 0x0018: BAR empty ()
> > 0x001c: BAR empty ()
> > 0x0020: BAR io addr: 0x1800/0x0020
> > 0x0024: BAR empty ()
> > 0x0028: Cardbus CIS: 
> > 0x002c: Subsystem Vendor ID: 1014 Product ID: 052d
> > 0x0030: Expansion ROM Base Address: 
> > 0x0038: 
> > 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
> >  0:29:1: Intel 82801DB USB
> > 0x: Vendor ID: 8086, Product ID: 24c4
> > 0x0004: Command: 0005, Status: 0280
> > 0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
> > Interface: 00, Revision: 01
> > 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> > Cache Line Size: 00
> > 0x0010: BAR empty ()
> > 0x0014: BAR empty ()
> > 0x0018: BAR empty ()
> > 0x001c: BAR empty ()
> > 0x0020: BAR io addr: 0x1820/0x0020
> > 0x0024: BAR empty ()
> > 0x0028: Cardbus CIS: 
> > 0x002c: Subsystem Vendor ID: 1014 Product ID: 052d
> > 0x0030: Expansion ROM Base Address: 
> > 0x0038: 
> > 0x003c: Interrupt Pin: 02 Line: 0b Min Gnt: 00 Max Lat: 00
> >  0:29:2: Intel 82801DB USB
> > 0x: Vendor ID: 8086, Product ID: 24c7
> > 0x0004: Command: 0005, Status: 0280
> > 0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
> > Interface: 00, Revision: 01
> > 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> > Cache Line Size: 00
> > 0x0010: BAR empty ()
> > 0x0014: BAR empty ()
> > 0x0

Re: amd microcode

[Jonathan Gray]

On Mon, Jul 24, 2023 at 03:17:26PM -0700, Courtney wrote:
> $ pkg_info | grep amd
> amd-firmware-20230719 microcode update binaries for AMD CPUs

It by no means covers all zen 2 models.
See /etc/firmware/amd/README

  Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes
  Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a8 Length=3200 bytes

17-31-00 Rome/Castle Peak   0x0830107a
17-a0-00 Mendocino  0x08a8

The family-model-stepping is printed at the end of cpu lines in dmesg.

Zen2 models missing include:

17-60-01 Renoir 0x0860010b
17-68-01 Lucienne   0x08608105
17-71-00 Matisse0x08701032
17-90-02 Van Gogh

The known good patch levels are used by xen and linux.  But the
microcode for Renoir, Lucienne and Matisse is not available as far as
I can tell.

An updated kernel will set DE_CFG bit 9 on all Zen2 models,
which does not require new microcode.

> 
> I however, do not have the test code to check if you are impacted by
> Zenbleed or not. There is test code, but it only compiles on Linux.
> 
> Theo de Raadt also put out info if you are doing syspatch for the new
> errata.
> 
> https://marc.info/?l=openbsd-tech&m=169021508718971&w=2
> 
> Courtney
> 
> On 7/23/23 23:02, Christer Solskogen wrote:
> > I just saw https://undeadly.org/cgi?action=article;sid=20230723185853
> > and was wondering how I can check if it works? Does or should the
> > microcode update show up in dmesg or in some other log?
> > 
> 
> 

Re: Force Probing Intel GPU

[Jonathan Gray]

On Thu, Sep 28, 2023 at 11:23:03AM +, Gökhan Özdemir wrote:
> Hello,
> 
> I have an Intel Arc A770 which requires force probe kernel parameter 
> (i915.force_probe=56a0) on linux 6.1. Since current drm stack on OpenBSD is 
> 6.1, I am looking for a way to find OpenBSD equivalent of force probe.
> 
> I am running -current and manually installed inteldrm firmware via fw_update

Matching isn't the whole problem.

The dg2 cards take paths that are not fully implemented:
https://marc.info/?l=openbsd-tech&w=2&r=1&s=dg2&q=b

Re: OnLogic Helix 330

[Jonathan Gray]

On Mon, Nov 27, 2023 at 11:30:23PM -, Stuart Henderson wrote:
> On 2023-11-27, Devin Reade  wrote:
> > Once running snapshots, I initially configured the network for dwqe0.
> > It came up and I was able to ping hosts on the dwqe0 network, but
> > I noticed that carrier state seemed unpredictable.  I then deleted
> > hostname.dwqe0 and started trying to determine behavior based only on
> > ifconfig status and media values.   In short, things seem to be
> > quite unpredicable.  Some sample trials are shown, below:
> [..]
> 
> I don't know enough about it to go into detail, but these sort of symptoms
> are making me think of issues with the PHY driver rather than the nic driver.
> 
> > dwqe0 at pci0 dev 29 function 1 "Intel Elkhart Lake Ethernet" rev 0x11: rev 
> > 0x52, address 84:8b:cd:4d:b5:f6
> > ukphy0 at dwqe0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> > 0x19f277, model 0x0030
> > dwqe1 at pci0 dev 29 function 2 "Intel Elkhart Lake Ethernet" rev 0x11: rev 
> > 0x52, address 84:8b:cd:4d:bc:36
> > ukphy1 at dwqe1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> > 0x19f277, model 0x0030
> 
> No idea whether there might be a better phy driver to start from, nothing
> shows up in searches for that OUI. Maybe there are clues in linux dmesg or
> mii tools.

https://www.onlogic.com/hx330/
"1x MaxLinear GPY115 or 2x MaxLinear GPY115"

https://assets.maxlinear.com/web/documents/617807_gpy115b1vi_gpy115c0vi_ds_rev1.4.pdf
STD_PHYID1  67C9
STD_PHYID2  DC00

/sys/dev/mii/miivar.h
#define MII_OUI(id1, id2)   (((id1) << 6) | ((id2) >> 10))

(0x67c9 << 6) | (0xdc00 >> 10) is 0x19f277

#define IDR2_MODEL  0x03f0  /* vendor model */
#define MII_MODEL(id2)  (((id2) & IDR2_MODEL) >> 4)

as model is 0x30 ID2 will have those bits set
0xdc00 | (0x30 << 4) is 0xdf00

Re: OnLogic Helix 330

[Jonathan Gray]

On Mon, Nov 27, 2023 at 09:10:18PM -0700, Devin Reade wrote:
> On Tue, 2023-11-28 at 11:29 +1100, Jonathan Gray wrote:
> 
> > STD_PHYID1  67C9
> > STD_PHYID2  DC00
> > 
> > /sys/dev/mii/miivar.h
> [...]
> 
> Thanks.
> 
> So it looks like the approach here is to add a gpyphy.c and
> gpyphyreg.h file, and tie it in via miidevs, correct?

Yes, though a .h isn't needed.  Two models are described on page 182 of
the datasheet "Chip Identification and Ordering Information".

> 
> I don't understand files.mii but it looks like it's only had one
> commit in the last nine years; is files.mii obsolete?  If not,
> where do I find out more?

Not all Ethernet drivers use the sys/dev/mii code.

The config glue would look something like the below, see files.conf(5)
and config(8).

miidevs.h is regenerated by running 'make' in /sys/dev/mii after
modifying miidevs.

Index: sys/dev/mii/miidevs
===
RCS file: /cvs/src/sys/dev/mii/miidevs,v
diff -u -p -r1.133 miidevs
--- sys/dev/mii/miidevs 8 Jul 2023 08:18:30 -   1.133
+++ sys/dev/mii/miidevs 28 Nov 2023 04:23:25 -
@@ -73,6 +73,7 @@ oui PLESSEYSEMI   0x046b40Plessey 
Semi.
 oui NATSEMI0x080017National Semi.
 oui TI 0x080028Texas Instruments
 oui MOTORCOMM  0x13d47aMotorcomm
+oui MAXLINEAR  0x19f277MaxLinear
 
 /* in the 79c873, AMD uses another OUI (which matches Davicom!) */
 oui xxALTIMA   0x000895Altima
@@ -264,6 +265,10 @@ model MARVELL E1116R   0x0024  88E1116R Gi
 model MARVELL E30160x0026  88E3016 10/100 PHY
 model MARVELL PHYG65G  0x0027  PHYG65G Gigabit PHY
 model MARVELL E15450x002a  88E1545 Quad 10/100/1000 PHY
+
+/* MaxLinear PHYs */
+model MAXLINEAR GPY115B0x0030  GPY115B Gigabit PHY
+model MAXLINEAR GPY115C0x0031  GPY115C Gigabit PHY
 
 /* Micrel PHYs */
 model MICREL KSZ9021   0x0021  KSZ9021 10/100/1000 PHY
Index: sys/dev/mii/files.mii
===
RCS file: /cvs/src/sys/dev/mii/files.mii,v
diff -u -p -r1.33 files.mii
--- sys/dev/mii/files.mii   4 Mar 2023 22:40:37 -   1.33
+++ sys/dev/mii/files.mii   28 Nov 2023 04:25:43 -
@@ -152,3 +152,7 @@ filedev/mii/brswphy.c   brswphy
 device ytphy: mii_phy
 attach ytphy at mii
 file   dev/mii/ytphy.c ytphy
+
+device gpyphy: mii_phy
+attach gpyphy at mii
+file   dev/mii/gpyphy.cgpyphy
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
diff -u -p -r1.520 GENERIC
--- sys/arch/amd64/conf/GENERIC 11 Oct 2023 12:52:00 -  1.520
+++ sys/arch/amd64/conf/GENERIC 28 Nov 2023 04:27:28 -
@@ -626,6 +626,7 @@ etphy*  at mii? # Agere/LSI 
ET1011 Tru
 jmphy* at mii? # JMicron JMP202/JMP211 PHYs
 atphy* at mii? # Attansic F1 PHYs
 ipgphy*at mii? # IC Plus IP1000A PHYs
+gpyphy* at mii?# MaxLinear GPY115 PHYs
 ukphy* at mii? # "unknown" PHYs
 
 eap*   at pci? # Ensoniq AudioPCI S5016

Re: wsfont .h file generation

[Jonathan Gray]

On Sun, Jan 14, 2024 at 05:09:09AM +0300, S V wrote:
> Hello misc
> 
> What tools devs are using to generate .h wsfont files from bdf?
> 
> Thanks in advance

one way of doing it:

pkg_add bdf2psf psftools
(converters/bdf2psf sysutils/psftools)

bdf2psf --fb file.bdf /usr/local/share/bdf2psf/standard.equivalents \
/usr/local/share/bdf2psf/fontsets/Lat15.256 256 file.psf

psf2bsd --name=faceWxH --first=32 --typeface="Face WxH" FaceWxH.psf \
> faceWxH.h