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

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

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

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

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

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

Re: 6.9 + 001: uvm_fault

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

Here is the mail you were both sent:

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

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



Re: OpenBSD on AWS EC2 Nitro

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

Running virtualised it is unclear what msrs the hardware implements.

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

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

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

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

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



Re: 6.9 + 001: uvm_fault

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

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

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

> 
> 
> Regards
> Harri

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

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

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

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



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

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

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

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

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

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



Re: New variant of rtl8168h supported?

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

Thanks, committed with the id added to pcidevs.



Re: New variant of rtl8168h supported?

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

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

Can you try a kernel with this?

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



Re: Difficulty booting UEFI from DVD

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

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



Re: snapshot kernel panic related to radeondrm missing firmware

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

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

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

Thanks for the report.



Re: Issues with Teclast F7 Plus

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

thanks, committed

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



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

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

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

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

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

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



Re: 6.8: page fault

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

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

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

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

> 
> Harri

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

Re: OpenBSD UEFI on QEMU emulator

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

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

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



Re: AMDGPU(4) - Question about man page

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

The man page is for the xorg driver.

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

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

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

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



Re: Inphi CS4223 for 4x 10GbE SFP+

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

Atom C3000 10 GbE is known as X553.

Support was added in


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

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


And is present in 6.7 and 6.8.

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



Re: firefox freezes X on AMD Ryzen running 6.8

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

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

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

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

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

Re: how to figure out reverse package dependency?

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

This is really a question for ports@

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



Re: No xenocara for ATI Radeon HD 2400 XT

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

I can't spot a likely cause for this.

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

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

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

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



Re: No xenocara for ATI Radeon HD 2400 XT

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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



Re: AMDGPU

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

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



Re: AMDGPU

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

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

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

amdgpu: add vega20 TA firmware from 20.20 release

Based on internal commit:
c6aa2bdaa30af815fc257f2b0e50f6c66d74045c

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

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

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

amdgpu: update vega20 firmware from 20.20 release

Based on internal commit:
c6aa2bdaa30af815fc257f2b0e50f6c66d74045c

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

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

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

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



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

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

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

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

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

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

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

Re: Brand new server - bad adventures

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

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

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

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

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



Re: sysupgrade woes on beaglebone black

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

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

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



Re: netsurf-fb fails on framebuffer console

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

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

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

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



Re: netsurf-fb fails on framebuffer console

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

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

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

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



Re: xenocara xcursor issues?

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

suspend/resume currently does not work on amdgpu.

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

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



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

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

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



Re: trouble with radeon r9 290 and eduke32

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

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

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

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

Re: trouble with radeon r9 290 and eduke32

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

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

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

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

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

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

Re: AMDGPU in current issue

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

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

Re: AMDGPU in current issue

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

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



Re: trouble with radeon r9 290 and eduke32

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

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

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

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

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

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

Re: Best 1Gbe NIC

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

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

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



Re: AMDGPU in current issue

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

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

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

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

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



Re: Blank screen after installing OpenBSD 6.5

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

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

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



Re: Configuration of radeondrm

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

Xorg is no longer setuid you should use xenodm.

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

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

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

Re: Secondary monitor switches off when inteldrm switches on

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

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

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

This is complete nonsense.

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



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

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

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

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

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

Re: "ucode too large"

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

The limit was raised only for efiboot.

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

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

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

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



Re: Lenovo w/ AMD Ryzen CPU

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

I disagree.

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

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

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

It is also not enabled by default just yet.

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



Re: Random system freeze.

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

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

jcs@ mentioned off list:

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

Still locks up with no i915 firmware loaded.

Not reachable over network on lockup.

Occurs with intel xorg driver as well as modesetting.



Re: Thinkpad A285 mouse issues

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

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

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

Re: Criteria for errata

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

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



Re: Thinkpad A285 mouse issues

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

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

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



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

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

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

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

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



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

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

Does this help?

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



Re: some more info about ?? hangs

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

Likely fixed by

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


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

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




Re: Patch for X crash on 6.4 and 6.5

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

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

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

Re: current snapshot kernel uvm fault radeondrm firmware not found

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

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



Re: GMA500 drivers

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

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

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



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

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

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



Re: X server gbm: failed to open any driver

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

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

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

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

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



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

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

A MMU is required to run OpenBSD.



Re: radeondrm failure on amd64 but not on i386?

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

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



Re: radeondrm failure on amd64 but not on i386?

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

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



Re: radeondrm failure on amd64 but not on i386?

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

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

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



Re: Keyboard repeats characters way to often

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

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

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

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



Re: Keyboard repeats characters way to often

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

Could be tsc desync.

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

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

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

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

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

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



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

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

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



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

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

bio as well

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



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

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

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

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



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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

I have no plans regarding amdgpu.

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



Re: pine64-lts - can't detect disk

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

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

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

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

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



Re: pine64-lts - can't detect disk

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

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

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

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

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

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



Re: 6.3 : how to check microcode?

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

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

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

Re: OpenBSD 6.2 amd64 and ATI Radeon 9550

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

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

At the moment there is

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

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

Re: X server keeps crashing in current/amd64

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

If you can get a backtrace that would be helpful.

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

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

Re: X server keeps crashing in current/amd64

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

I see you have multiple screens in your Xorg log.

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

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

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

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

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

2018-03-15 Thread 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: 

Re: System hangs after detecting radeondrm

2018-03-10 Thread 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" 

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

2018-03-03 Thread 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: Support for AMD/ATI Firepro M7820

2018-02-10 Thread 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: AMD Pro A10/A12 Radeon R7 Support

2018-01-22 Thread 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: AMD Pro A10/A12 Radeon R7 Support

2018-01-22 Thread 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: no sound by "Intel 6321ESB HD Audio"

2017-12-03 Thread 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: Radeon discrete graphics issues

2017-11-19 Thread 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 <j...@jsg.id.au> 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 <j...@jsg.id.au> 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 <mansel...@gmail.com>
> > > > 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_
> > > > > > source=link_campaign=sig-email_content=webmail>
> > > > > > Virus-free.
> > > > > > www.avast.com
> > > > > > <https://www.avast.com/sig-email?utm_medium=email_
> > > > > > source=link_campaign=sig-email_content=webmail>
> > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > > >
> > > >
> >



Re: Radeon discrete graphics issues

2017-11-18 Thread 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 <j...@jsg.id.au> 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 <mansel...@gmail.com>
> > 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_
> > > > source=link_campaign=sig-email_content=webmail>
> > > > Virus-free.
> > > > www.avast.com
> > > > <https://www.avast.com/sig-email?utm_medium=email_
> > > > source=link_campaign=sig-email_content=webmail>
> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > >
> >



Re: Radeon discrete graphics issues

2017-11-18 Thread 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_campaign=sig-email_content=webmail>
> > Virus-free.
> > www.avast.com
> >  > source=link_campaign=sig-email_content=webmail>
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >



Re: RPI3 fails to relink kernel

2017-10-17 Thread 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: X710 10Gb card not configured

2017-09-27 Thread 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: X710 10Gb card not configured

2017-09-26 Thread 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: TouchPad on Asus UX390

2017-08-27 Thread 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: Pinebook (if anyones up for it)

2017-08-20 Thread 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 <alexander_nau...@opensuse.org>:
> > > > 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: Pinebook (if anyones up for it)

2017-08-20 Thread 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: booting 6.1

2017-06-08 Thread 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: OpenBSD 6.1 ix Intel 82598EB issue

2017-04-24 Thread Jonathan Gray
On Mon, Apr 24, 2017 at 12:31:52PM +0200, Robert Blacquiere wrote:
> 
> Hi,
> 
> I have updated one of our machines from 6.0 to 6.1. 
> It has 2  dual 10 gb interfaces . One of them a  Intel 82598EB based
> dual card will not initialize any more. 
> 
> The other 10gig works and is based on Intel 82599. 
> 
> from dmesg: 
> 
> ix0 at pci2 dev 0 function 0 "Intel 82598EB" rev 0x01: mmba is not mem
> space
> ix1 at pci2 dev 0 function 1 "Intel 82598EB" rev 0x01: mmba is not mem
> space
> 
> pcidump:
> 
> $ doas pcidump -v 2:0:0  
>  2:0:0: Intel 82598EB
> 0x: Vendor ID: 8086 Product ID: 10dd
> 0x0004: Command: 0007 Status: 0010
> 0x0008: Class: 02 Subclass: 00 Interface: 00 Revision: 01
> 0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line
> Size: 10
> 0x0010: BAR mem 32bit addr: 0xfb22/0x0002
> 0x0014: BAR mem 32bit addr: 0xfb1c/0x0004
> 0x0018: BAR io addr: 0xe020/0x0020
> 0x001c: BAR mem 32bit addr: 0xfb244000/0x4000
> 0x0020: BAR empty ()
> 0x0024: BAR empty ()
> 0x0028: Cardbus CIS: 
> 0x002c: Subsystem Vendor ID: 15d9 Product ID: af80
> 0x0030: Expansion ROM Base Address: fb18
> 0x0038: 
> 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
> 0x0040: Capability 0x01: Power Management
> State: D0
> 0x0050: Capability 0x05: Message Signalled Interrupts (MSI)
> 0x0060: Capability 0x11: Extended Message Signalled Interrupts
> (MSI-X)
> 0x00a0: Capability 0x10: PCI Express
> Link Speed: 2.5 / 2.5 GT/s Link Width: x4 / x8
> 0x0100: Enhanced Capability 0x01: Advanced Error Reporting
> 0x0140: Enhanced Capability 0x03: Device Serial Number
> 
> 
> Any clues on how to enable them again?

Try this patch to not require a 64 bit BAR:

Index: sys/dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.150
diff -u -p -r1.150 if_ix.c
--- sys/dev/pci/if_ix.c 24 Jan 2017 03:57:35 -  1.150
+++ sys/dev/pci/if_ix.c 24 Apr 2017 10:37:09 -
@@ -1550,8 +1550,7 @@ ixgbe_allocate_pci_resources(struct ix_s
int  val;
 
val = pci_conf_read(pa->pa_pc, pa->pa_tag, PCIR_BAR(0));
-   if (PCI_MAPREG_TYPE(val) != PCI_MAPREG_TYPE_MEM ||
-   PCI_MAPREG_MEM_TYPE(val) != PCI_MAPREG_MEM_TYPE_64BIT) {
+   if (PCI_MAPREG_TYPE(val) != PCI_MAPREG_TYPE_MEM) {
printf(": mmba is not mem space\n");
return (ENXIO);
}



Re: printf(3): extra parameters, %b token, and cpp antics

2017-04-23 Thread Jonathan Gray
On Sun, Apr 23, 2017 at 03:39:22AM -0400, Ian Sutton wrote:
> I noticed some strange code in src/sys/arch/armv7/omap/ommmc.c
> 
> This preprocessor define seems to map intr. state bit positions with
> strings describing them:
> 
> 149 #define  MMCHS_STAT_FMT "\20" \
> 150 "\x09d_BADA" \
> 151 "\x09c_CERR" \
> 152 "\x098_ACE" \
> 153 "\x096_DEB" \
> 154 "\x095_DCRC" \
> 155 "\x094_DTO" \
> 156 "\x093_CIE" \
> 157 "\x092_CEB" \
> 158 "\x091_CCRC" \
> 159 "\x090_CTO" \
> 160 "\x08f_ERRI" \
> 161 "\x089_OBI" \
> 162 "\x088_CIRQ" \
> 163 "\x085_BRR" \
> 164 "\x084_BWR" \
> 165 "\x082_BGE" \
> 166 "\x081_TC" \
> 167 "\x080_CC"
> 
> It's used later as an extra printf() argument (edited for clarity):
> 
> 1174 printf("%s: interrupt status=%b\n", DEVNAME(sc), status, MMCHS_STAT_FMT);
> 
> Whenever the above is called, the string counterpart to each interupt
> bit set in 'status' is printed, for example:
> 
> mmmc0: interrupt status=20008000<_BADA,_ERRI>
> 
> Where BADA and ERRI are intr. status bits at positions 29 and 15
> respectively.
> 
> So through some combination of:
>   * CPP multi-string define with unclear hex escapes prepended
>   * printf() call with one too many parameters
>   * undocumented %b printf() token

http://man.openbsd.org/printf.9



Re: OpenBSD 6.1-snapshot boot issues in bhyve

2017-04-04 Thread Jonathan Gray
On Wed, Apr 05, 2017 at 12:46:27PM +1000, Jason Tubnor wrote:
> Hi,
> 
> Just wondering if anyone else is seeing the same issue I am booting a
> 6.1-snapshot in bhyve?  In preparation for the 6.1 pending release, I have
> tried to spin up 6.1-snap to iron out any issues in bhyve but I don't get
> very far into the installation process:
> 
> 
> 
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> 
> OpenBSD 6.1 (RAMDISK_CD) #19: Sat Apr  1 13:49:18 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 251658240 (240MB)
> avail mem = 240402432 (229MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (10 entries)
> bios0: vendor BHYVE version "1.00" date 03/14/2014
> bios0: bhyve BHYVE
> acpi0 at bios0: rev 2
> acpi0: tables DSDT APIC FACP HPET MCFG
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.87 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16
> ,xTPR,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PA
> GE1GB,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> rdmsr to register 0xc80 on vcpu 0
>  fatal protection fault in supervisor mode
> trap type 4 code 0 rip 811c1d17 cs 8 rflags 202 cr2  0 cpl e rsp
> 81a05940
> panic: trap type 4, code=0, pc=811c1d17
> 
> The operating system has halted.
> Please press any key to reboot.
> 
> -
> 
> Is anyone able to shed light on this?  I can confirm that 6.0-stable
> installed and runs fine as a guest on this host:

That MSR is IA32_DEBUG_INTERFACE.

/*
 * Attempt to disable Silicon Debug and lock the configuration
 * if it's enabled and unlocked.
 */
if (!strcmp(cpu_vendor, "GenuineIntel") &&
(cpu_ecxfeature & CPUIDECX_SDBG)) {
uint64_t msr;

msr = rdmsr(IA32_DEBUG_INTERFACE);
if ((msr & IA32_DEBUG_INTERFACE_ENABLE) &&
(msr & IA32_DEBUG_INTERFACE_LOCK) == 0) {
msr &= IA32_DEBUG_INTERFACE_MASK;
msr |= IA32_DEBUG_INTERFACE_LOCK;
wrmsr(IA32_DEBUG_INTERFACE, msr);
} else if (msr & IA32_DEBUG_INTERFACE_ENABLE)
printf("%s: cannot disable silicon debug\n",
ci->ci_dev->dv_xname);
}

If they don't support SDBG they should be masking the cpuid bit.

> 
> -
> OpenBSD 6.0 (GENERIC.MP) #2: Wed Oct 12 07:46:27 AEDT 2016
> mrbuil...@cybermen.ar18.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2130030592 (2031MB)
> avail mem = 2061062144 (1965MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7fb6a000 (10 entries)
> bios0: vendor BHYVE version "1.00" date 03/14/2014
> acpi0 at bios0: rev 2
> acpi0: sleep states S5
> acpi0: tables DSDT FACP HPET APIC MCFG SPCR
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 1000 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.95 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,FMA3,CX16,xTPR
> ,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB
> ,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: CPU supports MTRRs but not enabled by BIOS
> cpu0: apic clock running at 134MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3499.42 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,FMA3,CX16,xTPR
> ,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB
> ,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 0, package 1
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PC00)
> "PNP0303" at acpi0 not configured
> "PNP0F03" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> pvbus0 at mainbus0: bhyve
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 unknown vendor 0x1275 product 0x1275 

Re: -current cvs update failure

2017-03-22 Thread Jonathan Gray
On Wed, Mar 22, 2017 at 07:20:54PM -0500, mitchell wodach wrote:
> I am having trouble getting my src tree updated. When I  try running
> cvs the following output is produced:
> $ cd /usr/src
> $ cvs -q up -Pd
> 
> cvs server: WARNING: Read-only repository access mode selected via `cvs -R'.
> Using this option to access a repository which some users write to may
> cause intermittent sandbox corruption.
> P etc/acme-client.conf
> cvs [update aborted]: cannot open directory
> /cvs/src/gnu/llvm/utils/lit/tests/Inputs/exec-discovery-in-tree/obj:
> No such file or directory
> 
> but the directory indeed exists:
> 
> $ ls gnu/llvm/utils/lit/tests/Inputs/exec-discovery-in-tree/
> CVS   lit.cfg   obj   test-one.txt
> 
> 
> So I don't know what I did wrong or whats going on.

As the obj directory should not have been imported it was manually
removed in the repository.

Remove the directory
gnu/llvm/utils/lit/tests/Inputs/exec-discovery-in-tree/
and cvs up again.

This is due to
gnu/llvm/utils/lit/tests/Inputs/exec-discovery-in-tree/CVS/Entries
still having a reference to the obj directory.



Re: Raspberry Pi 3 booting from USB

2017-03-06 Thread Jonathan Gray
On Tue, Mar 07, 2017 at 06:58:25AM +0100, Otto Moerbeek wrote:
> On Mon, Mar 06, 2017 at 05:58:36PM +1100, Jonathan Gray wrote:
> 
> > On Mon, Mar 06, 2017 at 07:46:30AM +0100, Otto Moerbeek wrote:
> > > On Sun, Mar 05, 2017 at 09:41:27AM -0500, Joe Gidi wrote:
> > > 
> > > > I was stuck at that point for a while. Make sure you have everything 
> > > > you need
> > > > to boot on the DOS partition of your USB drive; mine was missing 
> > > > u-boot.bin.
> > > > Are you using the bootcode.bin and start.elf files from Raspbian?
> > > 
> > > I'm using the files as installed by the installer. But indeed,
> > > u-boot.bin is missing on the i partition on the USB disk. Will add
> > > that (and find out why it isn't there) tonight.  In the meantime I'm
> > > doing a make build, which does not seem to be stable yet. I've seen
> > > segfaults now and then plus at least one malloc use-after-free error.
> > > 
> > >   -Otto
> > > 
> > 
> > Missing something like this, should already be present as
> > /usr/mdec/rpi/u-boot.bin on the ramdisk.
> 
> It's not in the /usr/mdec installed on the USB disk, that has only one
> file in it here: (trying to look it up, but the machine is remote and
> it paniced it looks...)

The ramdisk filesystem, not the installed one.

> 
> Anyway, did not succed yet to boot without SD card in it. I must say,
> from all the messages, it is not clear to me which steps from the OP
> are neccesary and which not. Later in the week I'll have some more
> time to investigate.
> 
>   -Otto
> 
> > 
> > Index: install.md
> > ===
> > RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 install.md
> > --- install.md  18 Feb 2017 02:01:53 -  1.2
> > +++ install.md  6 Mar 2017 06:55:24 -
> > @@ -56,6 +56,8 @@ md_installboot() {
> > device_tree_address=0x100
> > kernel=u-boot.bin
> > __EOT
> > +
> > +   cp $_mdec/u-boot.bin /mnt/mnt/
> >  }
> >  
> >  md_prep_fdisk() {



Re: Raspberry Pi 3 booting from USB

2017-03-05 Thread Jonathan Gray
On Mon, Mar 06, 2017 at 07:46:30AM +0100, Otto Moerbeek wrote:
> On Sun, Mar 05, 2017 at 09:41:27AM -0500, Joe Gidi wrote:
> 
> > I was stuck at that point for a while. Make sure you have everything you 
> > need
> > to boot on the DOS partition of your USB drive; mine was missing u-boot.bin.
> > Are you using the bootcode.bin and start.elf files from Raspbian?
> 
> I'm using the files as installed by the installer. But indeed,
> u-boot.bin is missing on the i partition on the USB disk. Will add
> that (and find out why it isn't there) tonight.  In the meantime I'm
> doing a make build, which does not seem to be stable yet. I've seen
> segfaults now and then plus at least one malloc use-after-free error.
> 
>   -Otto
> 

Missing something like this, should already be present as
/usr/mdec/rpi/u-boot.bin on the ramdisk.

Index: install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.2
diff -u -p -r1.2 install.md
--- install.md  18 Feb 2017 02:01:53 -  1.2
+++ install.md  6 Mar 2017 06:55:24 -
@@ -56,6 +56,8 @@ md_installboot() {
device_tree_address=0x100
kernel=u-boot.bin
__EOT
+
+   cp $_mdec/u-boot.bin /mnt/mnt/
 }
 
 md_prep_fdisk() {



Re: Raspberry Pi 3 booting from USB

2017-03-05 Thread Jonathan Gray
The arm64 miniroot and bsd.rd already include fixup.dat and dtbs
from https://github.com/raspberrypi/firmware/tree/master/boot

There is no need to manually change them.

On Sun, Mar 05, 2017 at 08:21:56AM -0500, Joe Gidi wrote:
> >From further tinkering, I discovered that my Pi was only recognizing 128 MB 
> >of
> RAM until I switched to using the DTB and fixup.dat files from Raspbian. Seems
> that those /boot/ files should be kept in sync.
> 
> Thanks for all your work on this new platform!
> 
> On March 5, 2017 3:36:16 AM EST, Jonathan Gray <j...@jsg.id.au> wrote:
> >On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote:
> >> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:
> >>
> >> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
> >> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
> >> > >
> >> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB
> >device
> >> > > > might be
> >> > > > possible, I decided to find out how deep the rabbit hole is.
> >> > > > As it turns out,
> >> > > > it's currently a bit convoluted, but it can be made
> >> > > > to work with OpenBSD.
> >> > > > First off, USB boot support is just now getting fully ironed
> >out.
> >> > > > You'll need
> >> > > > to update the firmware on your Pi to make it work. I
> >> > > > installed the latest
> >> > > > (2017-03-02) Raspbian image to an SD card and
> >> > > > booted the Pi from that. While
> >> > > > booted in Raspbian, update the
> >> > > > firmware:
> >> > > >
> >> > > > sudo apt-get update
> >> > > > sudo apt-get
> >> > > > install rpi-update
> >> > > > sudo rpi-update
> >> > > >
> >> > > > It's then necessary to actually enable USB
> >> > > > boot support. Add the
> >> > > > following 2 lines to /boot/config.txt to enable USB boot
> >> > > > mode and set
> >> > > > a 5-second timeout to allow time for USB device initialization:
> >> > > > program_usb_boot_mode=1
> >> > > > program_usb_boot_timeout=1
> >> > > >
> >> > > > NOTE: Apparently these
> >> > > > variables are set in the Pi's OTP memory, which
> >> > > > means once they're set, they
> >> > > > can't ever be unset.
> >> > > >
> >> > > > Reboot for the changes to take effect. At this point the
> >> > > > Pi should be
> >> > > > ready to support USB booting.
> >> > > >
> >> > > > While you still have a working
> >> > > > Raspbian install, grab a copy of the
> >> > > > /boot/bootcode.bin and /boot/start.elf
> >> > > > files for later use; apparently
> >> > > > we need these special versions of those two
> >> > > > files for USB boot
> >> > > > support. At this point we're done with Raspbian and can
> >> > > > shut it down
> >> > > > to install OpenBSD.
> >> > > >
> >> > > > Next, write the OpenBSD miniroot60.fs to an
> >> > > > SD card, plug in your USB
> >> > > > drive, and boot the Pi. You should be greeted with
> >> > > > the usual OpenBSD
> >> > > > installer, and you should be able to install to your USB
> >> > > > drive
> >> > > > (probably sd0). Once the installer is done, run 'halt', unplug
> >the Pi,
> >> > > > and remove the SD card and USB drive.
> >> > > >
> >> > > > To make your USB drive bootable, you'll
> >> > > > need to plug it into another
> >> > > > system and mount its 'i' partition (the FAT32
> >> > > > boot partition) to make
> >> > > > a few changes. Replace the bootcode.bin and start.elf
> >> > > > files with the
> >> > > > ones from Raspbian, and add the u-boot.bin file from the 'i'
> >> > > > partition
> >> > > > of your miniroot60.fs SD card.
> >> > > >
> >> > > > With those changes made, your Pi
> >> > > > should be able to boot OpenBSD
> >> > &

Re: Raspberry Pi 3 booting from USB

2017-03-05 Thread Jonathan Gray
On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote:
> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:
> 
> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
> > > 
> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB device
> > > > might be
> > > > possible, I decided to find out how deep the rabbit hole is.
> > > > As it turns out,
> > > > it's currently a bit convoluted, but it can be made
> > > > to work with OpenBSD.
> > > > First off, USB boot support is just now getting fully ironed out.
> > > > You'll need
> > > > to update the firmware on your Pi to make it work. I
> > > > installed the latest
> > > > (2017-03-02) Raspbian image to an SD card and
> > > > booted the Pi from that. While
> > > > booted in Raspbian, update the
> > > > firmware:
> > > > 
> > > > sudo apt-get update
> > > > sudo apt-get
> > > > install rpi-update
> > > > sudo rpi-update
> > > > 
> > > > It's then necessary to actually enable USB
> > > > boot support. Add the
> > > > following 2 lines to /boot/config.txt to enable USB boot
> > > > mode and set
> > > > a 5-second timeout to allow time for USB device initialization:
> > > > program_usb_boot_mode=1
> > > > program_usb_boot_timeout=1
> > > > 
> > > > NOTE: Apparently these
> > > > variables are set in the Pi's OTP memory, which
> > > > means once they're set, they
> > > > can't ever be unset.
> > > > 
> > > > Reboot for the changes to take effect. At this point the
> > > > Pi should be
> > > > ready to support USB booting.
> > > > 
> > > > While you still have a working
> > > > Raspbian install, grab a copy of the
> > > > /boot/bootcode.bin and /boot/start.elf
> > > > files for later use; apparently
> > > > we need these special versions of those two
> > > > files for USB boot
> > > > support. At this point we're done with Raspbian and can
> > > > shut it down
> > > > to install OpenBSD.
> > > > 
> > > > Next, write the OpenBSD miniroot60.fs to an
> > > > SD card, plug in your USB
> > > > drive, and boot the Pi. You should be greeted with
> > > > the usual OpenBSD
> > > > installer, and you should be able to install to your USB
> > > > drive
> > > > (probably sd0). Once the installer is done, run 'halt', unplug the Pi,
> > > > and remove the SD card and USB drive.
> > > > 
> > > > To make your USB drive bootable, you'll
> > > > need to plug it into another
> > > > system and mount its 'i' partition (the FAT32
> > > > boot partition) to make
> > > > a few changes. Replace the bootcode.bin and start.elf
> > > > files with the
> > > > ones from Raspbian, and add the u-boot.bin file from the 'i'
> > > > partition
> > > > of your miniroot60.fs SD card.
> > > > 
> > > > With those changes made, your Pi
> > > > should be able to boot OpenBSD
> > > > directly from a USB drive with no SD card
> > > > needed. Note that it seems
> > > > to take around 10 seconds for the Pi to reach the
> > > > OpenBSD bootloader
> > > > and fire up the kernel.
> > > > 
> > > > Hope this information is helpful
> > > > to someone...
> > > > 
> > > > -- 
> > > >  Joe Gidi
> > > >  j...@entropicblur.com
> > > > 
> > > >  "You cannot buy skill."
> > > > -- Ross Seyfried
> > > 
> > > Thanks, I'll try this out soon,
> > > 
> > > Some notes of things I saw when trying to boot from a sd-card using
> > > various a USB devices to install to:
> > > 
> > > Some USB devices do seem to hang the rpi3 sometimes while u-boot is
> > > scanning the usb bus, in my case an old USB flash stick.
> > > 
> > > With a disk enclosure (2.5" usb bus powered with spinning disk), the
> > > hangs did not occur. But I saw another problem that looked to be
> > > caused by the reset of the usb bus while the kernel was booting (from
> > > sd-card). The disk enclosure did not 

  1   2   3   4   5   6   >