Re: OpenBSD on AWS - pciide/wd issue
On Wed, Sep 4, 2019 at 12:56 PM Pavel Korovin wrote: > The logs showed where it stuck: > > pciide0:0:0: not ready, st=0x0, err=0x00 > wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying > pciide0:0:0: not ready, st=0x0, err=0x00 > wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying I can reproduce this on my local Xen environment with the latest bsd.rd snapshot (OpenBSD 6.6-beta (RAMDISK_CD) #270: Wed Sep 4 11:46:05 MDT 2019); 6.5 works just fine. > For some reason, the boot volume was recognized also as > wd0 at pciide0 channel 0 drive 0: > and then as > sd0 at scsibus1 targ 0 lun 0: SCSI5 0/direct > > As a quick fix I disabled pciide/wd, the instance booted and runs fine. I noticed that in the problematic snapshot, pciide is listed in dmesg *before* any xen stuff, whereas in 6.5, xen0/xbf0/sd0 are listed first, and pciide comes later and says "channel 0 disabled (no drives)". I believe xbf(4) and xnf(4) disable any emulated devices (e.g. wd0, re0) when they load, so maybe they need to load first? Here's a "known good" dmesg from OpenBSD 6.5 + syspatches (up through 010_frag6ecn): OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056964608 (1008MB) avail mem = 1015353344 (968MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (12 entries) bios0: vendor Xen version "4.4.4_40-61.43.2" date 03/21/2019 bios0: Xen HVM domU acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2494.24 MHz, 06-17-06 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,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 6MB 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 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2493.89 MHz, 06-17-06 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,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured pvbus0 at mainbus0: Xen 4.4 xen0 at pvbus0: features 0x705, 32 grant table frames, event channel 4 "vfb" at xen0: device/vfb/0 not configured "console" at xen0: device/console/0 not configured xbf0 at xen0 backend 0 channel 6: disk scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 4096MB, 512 bytes/sector, 8388608 sectors xnf0 at xen0 backend 0 channel 7: address 00:16:3e:79:85:28 xnf1 at xen0 backend 0 channel 8: address 00:16:3e:46:21:98 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (70bae60fe9b7d0df.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown -Andrew
Re: AMDGPU in current issue
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
> > > > +++ 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
>
Re: AMDGPU in current issue
My apologies for bothering the mailing list once more-
I found the relevant commit for this in the linux git history, and found
the relevant changes. I added those changes locally on my machine, however
when I compile I get the following:
ld -T ld.script -X --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS}
ld: error: undefined symbol: psp_v11_0_set_psp_funcs
>>> referenced by amdgpu_psp.c:62
(/usr/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_psp.c:62)
>>> amdgpu_psp.o:(psp_sw_init)
ld: error: undefined symbol: vega20_smu_funcs
>>> referenced by hwmgr.c:164
(/usr/src/sys/dev/pci/drm/amd/powerplay/hwmgr/hwmgr.c:164)
>>> hwmgr.o:(hwmgr_early_init)
ld: error: undefined symbol: vega20_hwmgr_init
>>> referenced by hwmgr.c:165
(/usr/src/sys/dev/pci/drm/amd/powerplay/hwmgr/hwmgr.c:165)
>>> hwmgr.o:(hwmgr_early_init)
ld: error: undefined symbol: nbio_v7_4_funcs
>>> referenced by soc15.c:501
(/usr/src/sys/dev/pci/drm/amd/amdgpu/soc15.c:501)
>>> soc15.o:(soc15_set_ip_blocks)
ld: error: undefined symbol: nbio_v7_4_funcs
>>> referenced by soc15.c:501
(/usr/src/sys/dev/pci/drm/amd/amdgpu/soc15.c:501)
>>> soc15.o:(soc15_set_ip_blocks)
*** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:1426
'bsd': @echo ld -T ld.script -X --warn-common -nopie -o bsd '${SYST...)
>From what I can tell, these all mention functions added in new files added
from the linux drm... is there anything in particular I need to do to make
sure the compiler picks up the relevant files, or maybe something to the
Makefile? I can post a diff of what I've done so far if that would be
useful.
Thanks again for all the help.
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:
Re: What is you motivational to use OpenBSD
On 2019-08-28 07:47, Raul Miller wrote: I would fix the issue, or use something else to get that done or abandon that project. (I am not sure why you would imagine that using OpenBSD implies not using other operating systems. It's *because* I use other operating systems that I like using OpenBSD.) Thanks, So many good points brought up. Along with all that has been mentioned, I use OpenBSD because there are no surprises when you install a service. The service is not started until you start it. Even if it started inadvertently, the config will have 'sane' defaults and not get you breached. My OpenBSD start: I was running Untangle (based on Debian Linux) back in 2009 while looking for a PC-based router of some sort. I read Dru Lavigne's 'BSD Hacks' and found some things that I wanted my router to do using OpenBSD that Linux couldn't do (at least without recompiling the kernel). After that I was onto OpenBSD 4.6 with some early 'bump in the wire' devices in front of my Linux firewalls. I also read Michael W. Lucas OpenBSD books - lots of info. Then around 2010 I started using only OpenBSD as my firewall. I studied and built the pf rules up (thanks Peter N.M. Hansteen) so that I had confidence in placing OpenBSD on the open Internet as my only protection. These days I use only OpenBSD for all my server builds. This includes router/firewall (pf), http webserver (in base), and OpenVPN servers. If there is anything I place on the open Internet - it is an OpenBSD build. No other. Truthfully, you'll never know how good OpenBSD is until you try it. That's what I did. Thank you. Zann (at zonbie-dot-net)
OpenBSD on AWS - pciide/wd issue
Dear all, Today I've got some headache after upgrading OpenBSD-current running on AWS. Usually I upgrade twice a month using ansible. Last time I upgraded it on Aug 13. Today I started upgrade to the snapshot built on Sep 2, the instance didn't boot. The logs showed where it stuck: pciide0:0:0: not ready, st=0x0, err=0x00 wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying pciide0:0:0: not ready, st=0x0, err=0x00 wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying fd0 at fdc0 drive 0: density unknown For some reason, the boot volume was recognized also as wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 16384MB, 33554432 sectors wd0(pciide0:0:0): using PIO mode 0, DMA mode 2 and then as scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI5 0/direct fixed sd0: 16384MB, 512 bytes/sector, 33554432 sectors As a quick fix I disabled pciide/wd, the instance booted and runs fine. The dmesgs from successful and unsuccessful boots are attached. May be this information can be helful for somebody. -- With best regards, Pavel Korovin OpenBSD 6.6-beta (GENERIC) #0: Sun Aug 11 13:09:21 MSK 2019 real mem = 1056964608 (1008MB) avail mem = 1014919168 (967MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb01f (11 entries) bios0: vendor Xen version "4.2.amazon" date 08/24/2006 bios0: Xen HVM domU acpi0 at bios0: ACPI 4.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz, 2394.81 MHz, 06-3f-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,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu0: 256KB 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 100MHz acpihpet0 at acpi0: 6250 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 "ACPI0007" at acpi0 not configured cpu0: using Broadwell MDS workaround pvbus0 at mainbus0: Xen 4.2 xen0 at pvbus0: features 0x705, 32 grant table frames, event channel 3 xbf0 at xen0 backend 0 channel 5: disk scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 16384MB, 512 bytes/sector, 33554432 sectors xnf0 at xen0 backend 0 channel 6: address 0a:e4:5b:de:3e:56 "console" at xen0: device/console/0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (9fe353d6b8fcec8d.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown OpenBSD 6.6-beta (GENERIC) #0: Mon Sep 2 18:40:03 MSK 2019 real mem = 1056964608 (1008MB) avail mem = 1012391936 (965MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb01f (11 entries) bios0: vendor Xen version "4.2.amazon" date 08/24/2006 bios0: Xen HVM domU acpi0 at bios0: ACPI 4.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz, 2400.36 MHz, 06-3f-02 cpu0:
Re: AMDGPU in current issue
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
> > > +++ 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;
> > > }
> > >
> > >
> > >
>
wskbd without wsdisplay
I want to use an USB-keyboard/barcode-reader on a pc-engines apu. Since the apu has no graphics card, there is no wsdisplay and the keyboard stays unconnected. # wsconscfg -k wsconscfg: /dev/ttyCcfg: Device not configured How can I read that keyboard input? Do I even have to write some C and use usbhid.h or is there an api in wscons for that? Or something simpler? Any hints or directions to go would be appreciated. Thanks.
Re: AMDGPU in current issue
Look for individual post 4.19 linux commits that are relevant.
We have in the past taken small patches to enable more
generations of hardware.
On Wed, Sep 04, 2019 at 08:11:24AM -0500, Charlie Burnett wrote:
> Hey,
> I???ve been trying to write a patch to get vega 20 working, but due to a
> screw up on my end I lost the progress I???d made. Before I start over again,
> I was wondering if you had any advice on how to do it? Before, I was trying
> to more or less just port the vega 20 hwmgr files in from FreeBSD drm next
> which is at linux drm 5.0 as well as the other files which seemed to
> mention Vega 20 or seemed to be needed to compile. I wasn???t having much
> luck as you can imagine, and currently I???m still in university so my
> experience with kernel patching isn???t fantastic, I was wondering if you
> might have any advice where to begin if I???m having to start from scratch?
> Best regards,
> Charlie Burnett
>
> On Thu, Aug 1, 2019 at 11:06 PM Jonathan Gray wrote:
>
> > On Fri, Aug 02, 2019 at 03:11:54AM -0500, Charlie Burnett wrote:
> > > Hey-
> > > I'd been messing around with the AMDGPU on current (which I'm aware is
> > very
> > > experimental) and had very few issues with it using a Vega 56 GPU. I
> > > recently swapped to another Vega GPU (Radeon VII) and have issues with
> > the
> > > display not showing anything. Still boots fine, in that I can still enter
> > > commands (i.e. reboot) so it has to be a display issue. I tried searching
> > > for the diff where the firmware was added which I'm certain I saw (for
> > Vega
> > > 20) but can't seem to find it in the commit history. Anyone have a fix
> > for
> > > it, and if not, who should I talk to if I wanted to help get it working?
> > I
> > > saw most of the AMDGPU commits have been by @jonathangray if he would be
> > > the best option.
> > > Thanks!
> >
> > vega20 firmware was added when ports/sysutils/firmware/amdgpu was
> > updated to 20190312.
> >
> > vega20 is marked as experimental in the version of drm we have, but we
> > don't currently check the flag on probe like linux does.
> >
> > The following diff will prevent amdgpu from matching on devices
> > in the amdgpu_pciidlist table with the AMD_EXP_HW_SUPPORT flag
> > (currently these are all vega20 ids).
> >
> > Index: sys/dev/pci/drm/include/drm/drm_drv.h
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/include/drm/drm_drv.h,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 drm_drv.h
> > --- sys/dev/pci/drm/include/drm/drm_drv.h 25 Jul 2019 05:48:16
> > - 1.2
> > +++ sys/dev/pci/drm/include/drm/drm_drv.h 2 Aug 2019 03:29:58 -
> > @@ -291,5 +291,7 @@ static inline bool drm_drv_uses_atomic_m
> > intdrm_dev_register(struct drm_device *, unsigned long);
> > void drm_dev_unregister(struct drm_device *);
> > intdrm_getpciinfo(struct drm_device *, void *, struct drm_file *);
> > +const struct drm_pcidev*drm_find_description(int, int,
> > +const struct drm_pcidev *);
> >
> > #endif
> > Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 amdgpu_kms.c
> > --- sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 4 Jul 2019 03:39:07 -
> > 1.3
> > +++ sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 2 Aug 2019 03:35:35 -
> > @@ -1337,10 +1337,23 @@ int amdgpu_debugfs_firmware_init(struct
> > int
> > amdgpu_probe(struct device *parent, void *match, void *aux)
> > {
> > + struct pci_attach_args *pa = aux;
> > + const struct drm_pcidev *id_entry;
> > + unsigned long flags = 0;
> > +
> > if (amdgpu_fatal_error)
> > return 0;
> > - if (drm_pciprobe(aux, amdgpu_pciidlist))
> > - return 20;
> > +
> > + id_entry = drm_find_description(PCI_VENDOR(pa->pa_id),
> > + PCI_PRODUCT(pa->pa_id), amdgpu_pciidlist);
> > + if (id_entry != NULL) {
> > + flags = id_entry->driver_data;
> > + if (flags & AMD_EXP_HW_SUPPORT)
> > + return 0;
> > + else
> > + return 20;
> > + }
> > +
> > return 0;
> > }
> >
> >
> >
Re: AMDGPU in current issue
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;
> }
>
>
>
support new
0 C Turkey P Ankara T Cankaya Z 06510 O Rakort Information Technologies I Ebubekir Okur A 2139. Street 2/11 M open...@rakort.com U http://www.rakort.com B +90-850-460-10-58 X N More than 5 years, OpenBSD setup/installation/remote administration. Network engineering, software development. Also experienced with Solaris and Linux. We specialize in providing open source solutions for businesses using OpenBSD and Linux. CCNP, RHCE certifications, VPNs, firewalls, wireless, DNS, squidGuard, mail - even training with OpenBSD. We have more then 5 years experience with the OpenBSD platform and are able to deliver 24/7 solutions with necessary SLA's.
Re: What is you motivational to use OpenBSD
User since ~2001 here, albeit intermittently. My first encounter with it was where it was used — mostly to run Postfix, Squid and BIND, if my hazy memory is trustworthy — by a private company who was effectively an ISP for many Australian Federal Government departments. I think the aspect I like most is the gradual, carefully-considered but also inexorable flow of improvements that may individually look small, but, when viewed collectively, represent a huge improvement. A [software developer] colleague recently said, in a different context, "a big-bang release only guarantees a big bang". Seems appropriate here. I might have missed one but I can't remember a "big bang" OpenBSD release. That's a good thing. John On Thu, 29 Aug 2019 at 00:32, Mohamed salah wrote: > I wanna put something in discussion, what's your motivational to use > OPENBSD what not other bsd's what not gnu/Linux, if something doesn't work > fine on openbsd and you love this os so much what will do? >
Re: athn in 6.5: no link. Works in 6.4
On Wed, Sep 04, 2019 at 04:55:02AM +, Pedro Fortuny Ayuso wrote: > How can I do that? I mean, commit of what files, etc? If all you need is a list of files in the source tree, the list is: sys/dev/ic/athn.c sys/dev/ic/athnvar.h sys/dev/ic/ar5008.c sys/dev/ic/ar5416.c sys/dev/ic/ar5416reg.h sys/dev/ic/ar9280.c sys/dev/ic/ar928reg.h The general idea is to test kernels from different dates and find out when things started breaking for you. To speed this up you could start by testing pre-compiled kernels from here: http://ftp.hostserver.de/archive/ Based on other similar problem reports which have already been addressed a possible cut-off date is around February 2019: https://marc.info/?l=openbsd-bugs=155769666903558=2 If you need more assistence let me know.
Re: athn in 6.5: no link. Works in 6.4
How can I do that? I mean, commit of what files, etc? Thanks, Pedro. - Pedro Fortuny Ayuso pe...@pfortuny.net > On 3 Sep 2019, at 22:09, Stefan Sperling wrote: > >> On Tue, Sep 03, 2019 at 04:17:05PM +, Pedro Fortuny Ayuso wrote: >> >> I am having a surprising problem: my athn driver (computer is >> a 2007 MacBook Pro Core 2 duo) works flawlessly with an iphone 7 >> as a wifi router (i.e. wifi tethering). The device, as per >> dmesg is: >> >> athn0 at pci3 dev 0 function 0 "Atheros AR5418" rev 0x01: apic 1 int 17 >> athn0: MAC AR5418 rev 2, RF AR5133 (2T3R), ROM rev 4, address ... > > Known issue. I will need more information to fix it. > Specifically, knowing which commit between 6.4 and 6.5 broke your > device would be very helpful. > > Alternatively, if somebody could ship me one of these AR5418 devices, > I could debug the problem myself. > > Regards, > Stefan
