Re: Lenovo V330-14 touchpad is not working at all
> On 14 Jun 2019, at 02:38, Tristan wrote: > > > >> On Jun 14, 2019, at 12:00 AM, Tristan wrote: >> >> >> >>> On 13 Jun 2019, at 23:47, Bryan Steele wrote: >>> >>> On Thu, Jun 13, 2019 at 11:38:24PM +0200, Tristan wrote: > On 13 Jun 2019, at 22:34, Tristan wrote: > > > >> On 13 Jun 2019, at 22:25, Bryan Steele wrote: >> >> On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote: >>> Hi there, >>> >>> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX >>> Vega 8 >>> and so was looking forward to using OpenBSD on this one. I'm currently >>> running a >>> snapshot I grabbed today. To get the screen working I had to set >>> machdep.allowaperture=2 >>> unfortunately, but it works now and great as well. Video seems smooth. >>> Audio works as well >> >> You should avoid doing that -- see recent mailing lists post from Mark >> Kettenis. >> >> https://marc.info/?l=openbsd-misc&m=156029398905090&w=2 >> >> For Vega graphics you need to recompile your kernel with the amdgpu >> driver lines uncommented, alternatively reinstall in UEFI mode to get the >> efifb(4) driver instead. This is probably better as amdgpu support is >> still a WIP. >> > This worked really good. Now using efifb without the machdep setting. So > thanks for that pointer for sure. > > OK yes, I remember seeing something about it. Will give that a try. Much > better then opening up :) > > >>> but the touchpad is not working at all. Wireless card does not work >>> either, but using the >>> ethernet port on it for now until I get an USB dongle for it. >>> >>> wsconsctl | grep mouse gives me only: >>> mouse.type=ps2 >>> >>> In the dmesg output I can see only: >>> wsmouse0 at pms0 mux 0 >> >> Indeed, there's no pms(4) compatible touchpad on your machine. :-( >> >>> "AMDI0010" at acpi0 not configured >>> "SYNA2B3F" at acpi0 not configured >> >> And instead requires a driver to attach to the I2C HID controler. AMD's >> implementation seems to be somewhat compatible with dwiic(4) written by >> jcs@, however interrupts are not working-- hangs the machine. It does >> work if polling mode is forced. >> >> This diff made the touchscreen and touchpad work be detected and mostly >> work on my Huawei MateBook D (AMD), however with the touchpad it seems >> to be break Tap-To-Drag. I don't know if this is a side effect of the >> drivers polling, unlike the pms(4) support-- which is working on that >> machine. We have no way to prefer one driver over other, which is why >> I haven't sent this diff yet. >> >> Let me know if it works at all for you. > > Much appreciated, will try this and report the outcome Applying this patch gives me the following: Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: dwiic_acpi.c |=== |RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v |retrieving revision 1.8 |diff -u -p -u -r1.8 dwiic_acpi.c |--- sys/dev/acpi/dwiic_acpi.c1 Jul 2018 11:37:11 -1.8 |+++ sys/dev/acpi/dwiic_acpi.c5 Jun 2019 00:25:29 - -- Patching file dwiic_acpi.c using Plan A... patch: malformed patch at line 9: }; >>> >>> Your mail client may have mangled it-- can you try grabbing it >>> from marc.info? If not, I'll send a direct link. >>> >>> https://marc.info/?l=openbsd-misc&m=156045760827816&q=raw >>> >> >> Yes sorry about that false report :) my mistake. >> >> Applied and recompiling at the moment. Will report back soon. >> > This patch gave some life to my touchpad. Unfortunately its more like a slow > stuttering zombie :) > But yes it has some movement now, but just slow and then jumping forward. The > touchpad touch click works as well. > Cannot provide any output at the moment, but will send over the dmesg and > wsconctl output tomorrow. In case you want to see if there are any other > things we could try: > > Thanks again for the help. > Find the output of wsconsctl | grep mouse wsconsctl: Use explicit arg to view keyboard.map. mouse.type=usb mouse.rawmode=1 mouse.scale=0,0,0,0,0,0,0 mouse1.type=ps2 And my dmesg OpenBSD 6.5-current (CUSTOM) #0: Fri Jun 14 01:44:08 CEST 2019 tris...@etherios-amd.tristan.itaas.etheria.nl:/sys/arch/amd64/compile/CUSTOM real mem = 6322868224 (6029MB) avail mem = 6121222144 (5837MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x4c44d000 (50 entries) bios0: vendor LENOVO version "3ECN35WW(V3.02)" date 11/24/2018 bios0: LENOVO 81B1 acpi0 at bios0: ACPI 5.0Undefined scope: \\_SB_.PCI0.GPP2.BCM5
Re: Lenovo V330-14 touchpad is not working at all
> On Jun 14, 2019, at 12:00 AM, Tristan wrote: > > > >> On 13 Jun 2019, at 23:47, Bryan Steele wrote: >> >> On Thu, Jun 13, 2019 at 11:38:24PM +0200, Tristan wrote: >>> >>> On 13 Jun 2019, at 22:34, Tristan wrote: > On 13 Jun 2019, at 22:25, Bryan Steele wrote: > > On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote: >> Hi there, >> >> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX >> Vega 8 >> and so was looking forward to using OpenBSD on this one. I'm currently >> running a >> snapshot I grabbed today. To get the screen working I had to set >> machdep.allowaperture=2 >> unfortunately, but it works now and great as well. Video seems smooth. >> Audio works as well > > You should avoid doing that -- see recent mailing lists post from Mark > Kettenis. > > https://marc.info/?l=openbsd-misc&m=156029398905090&w=2 > > For Vega graphics you need to recompile your kernel with the amdgpu > driver lines uncommented, alternatively reinstall in UEFI mode to get the > efifb(4) driver instead. This is probably better as amdgpu support is > still a WIP. > This worked really good. Now using efifb without the machdep setting. So thanks for that pointer for sure. OK yes, I remember seeing something about it. Will give that a try. Much better then opening up :) >> but the touchpad is not working at all. Wireless card does not work >> either, but using the >> ethernet port on it for now until I get an USB dongle for it. >> >> wsconsctl | grep mouse gives me only: >> mouse.type=ps2 >> >> In the dmesg output I can see only: >> wsmouse0 at pms0 mux 0 > > Indeed, there's no pms(4) compatible touchpad on your machine. :-( > >> "AMDI0010" at acpi0 not configured >> "SYNA2B3F" at acpi0 not configured > > And instead requires a driver to attach to the I2C HID controler. AMD's > implementation seems to be somewhat compatible with dwiic(4) written by > jcs@, however interrupts are not working-- hangs the machine. It does > work if polling mode is forced. > > This diff made the touchscreen and touchpad work be detected and mostly > work on my Huawei MateBook D (AMD), however with the touchpad it seems > to be break Tap-To-Drag. I don't know if this is a side effect of the > drivers polling, unlike the pms(4) support-- which is working on that > machine. We have no way to prefer one driver over other, which is why > I haven't sent this diff yet. > > Let me know if it works at all for you. Much appreciated, will try this and report the outcome >>> >>> Applying this patch gives me the following: >>> >>> Hmm... Looks like a unified diff to me... >>> The text leading up to this was: >>> -- >>> |Index: dwiic_acpi.c >>> |=== >>> |RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v >>> |retrieving revision 1.8 >>> |diff -u -p -u -r1.8 dwiic_acpi.c >>> |--- sys/dev/acpi/dwiic_acpi.c1 Jul 2018 11:37:11 -1.8 >>> |+++ sys/dev/acpi/dwiic_acpi.c5 Jun 2019 00:25:29 - >>> -- >>> Patching file dwiic_acpi.c using Plan A... >>> patch: malformed patch at line 9: }; >> >> Your mail client may have mangled it-- can you try grabbing it >> from marc.info? If not, I'll send a direct link. >> >> https://marc.info/?l=openbsd-misc&m=156045760827816&q=raw >> > > Yes sorry about that false report :) my mistake. > > Applied and recompiling at the moment. Will report back soon. > This patch gave some life to my touchpad. Unfortunately its more like a slow stuttering zombie :) But yes it has some movement now, but just slow and then jumping forward. The touchpad touch click works as well. Cannot provide any output at the moment, but will send over the dmesg and wsconctl output tomorrow. In case you want to see if there are any other things we could try: Thanks again for the help.
Re: Lenovo V330-14 touchpad is not working at all
> On 13 Jun 2019, at 23:47, Bryan Steele wrote: > > On Thu, Jun 13, 2019 at 11:38:24PM +0200, Tristan wrote: >> >> >>> On 13 Jun 2019, at 22:34, Tristan wrote: >>> >>> >>> On 13 Jun 2019, at 22:25, Bryan Steele wrote: On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote: > Hi there, > > I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega > 8 > and so was looking forward to using OpenBSD on this one. I'm currently > running a > snapshot I grabbed today. To get the screen working I had to set > machdep.allowaperture=2 > unfortunately, but it works now and great as well. Video seems smooth. > Audio works as well You should avoid doing that -- see recent mailing lists post from Mark Kettenis. https://marc.info/?l=openbsd-misc&m=156029398905090&w=2 For Vega graphics you need to recompile your kernel with the amdgpu driver lines uncommented, alternatively reinstall in UEFI mode to get the efifb(4) driver instead. This is probably better as amdgpu support is still a WIP. >>> >>> OK yes, I remember seeing something about it. Will give that a try. Much >>> better then opening up :) >>> >>> > but the touchpad is not working at all. Wireless card does not work > either, but using the > ethernet port on it for now until I get an USB dongle for it. > > wsconsctl | grep mouse gives me only: > mouse.type=ps2 > > In the dmesg output I can see only: > wsmouse0 at pms0 mux 0 Indeed, there's no pms(4) compatible touchpad on your machine. :-( > "AMDI0010" at acpi0 not configured > "SYNA2B3F" at acpi0 not configured And instead requires a driver to attach to the I2C HID controler. AMD's implementation seems to be somewhat compatible with dwiic(4) written by jcs@, however interrupts are not working-- hangs the machine. It does work if polling mode is forced. This diff made the touchscreen and touchpad work be detected and mostly work on my Huawei MateBook D (AMD), however with the touchpad it seems to be break Tap-To-Drag. I don't know if this is a side effect of the drivers polling, unlike the pms(4) support-- which is working on that machine. We have no way to prefer one driver over other, which is why I haven't sent this diff yet. Let me know if it works at all for you. >>> >>> Much appreciated, will try this and report the outcome >> >> Applying this patch gives me the following: >> >> Hmm... Looks like a unified diff to me... >> The text leading up to this was: >> -- >> |Index: dwiic_acpi.c >> |=== >> |RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v >> |retrieving revision 1.8 >> |diff -u -p -u -r1.8 dwiic_acpi.c >> |--- sys/dev/acpi/dwiic_acpi.c 1 Jul 2018 11:37:11 - 1.8 >> |+++ sys/dev/acpi/dwiic_acpi.c 5 Jun 2019 00:25:29 - >> -- >> Patching file dwiic_acpi.c using Plan A... >> patch: malformed patch at line 9: }; > > Your mail client may have mangled it-- can you try grabbing it > from marc.info? If not, I'll send a direct link. > > https://marc.info/?l=openbsd-misc&m=156045760827816&q=raw > Yes sorry about that false report :) my mistake. Applied and recompiling at the moment. Will report back soon.
Re: The su manual doesn't mention use root account by default
On 13/06/2019 20:56, Misc User wrote: > On 6/13/2019 9:42 AM, Adam Thompson wrote: >> On 2019-06-12 03:55, Ingo Schwarze wrote: >> During initial system installation & deployment, before doas is >> configured, and assuming you haven't [yet] added your SSH keys to >> ~root/.ssh/allowed_keys, it's quite impossible to avoid using su. >> (AFAIK. If there's another way, let me know!) > > siteXX.tgz > > https://www.openbsd.org/faq/faq4.html#site This is a neat solution. Another could be to use single user mode as per https://www.openbsd.org/faq/faq8.html#LostPW . This is pretty low level and whether or not it is sufficient depends on what sort of extra configuration needs doing. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Lenovo V330-14 touchpad is not working at all
On Thu, Jun 13, 2019 at 11:38:24PM +0200, Tristan wrote: > > > > On 13 Jun 2019, at 22:34, Tristan wrote: > > > > > > > >> On 13 Jun 2019, at 22:25, Bryan Steele wrote: > >> > >> On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote: > >>> Hi there, > >>> > >>> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega > >>> 8 > >>> and so was looking forward to using OpenBSD on this one. I'm currently > >>> running a > >>> snapshot I grabbed today. To get the screen working I had to set > >>> machdep.allowaperture=2 > >>> unfortunately, but it works now and great as well. Video seems smooth. > >>> Audio works as well > >> > >> You should avoid doing that -- see recent mailing lists post from Mark > >> Kettenis. > >> > >> https://marc.info/?l=openbsd-misc&m=156029398905090&w=2 > >> > >> For Vega graphics you need to recompile your kernel with the amdgpu > >> driver lines uncommented, alternatively reinstall in UEFI mode to get the > >> efifb(4) driver instead. This is probably better as amdgpu support is > >> still a WIP. > >> > > > > OK yes, I remember seeing something about it. Will give that a try. Much > > better then opening up :) > > > > > >>> but the touchpad is not working at all. Wireless card does not work > >>> either, but using the > >>> ethernet port on it for now until I get an USB dongle for it. > >>> > >>> wsconsctl | grep mouse gives me only: > >>> mouse.type=ps2 > >>> > >>> In the dmesg output I can see only: > >>> wsmouse0 at pms0 mux 0 > >> > >> Indeed, there's no pms(4) compatible touchpad on your machine. :-( > >> > >>> "AMDI0010" at acpi0 not configured > >>> "SYNA2B3F" at acpi0 not configured > >> > >> And instead requires a driver to attach to the I2C HID controler. AMD's > >> implementation seems to be somewhat compatible with dwiic(4) written by > >> jcs@, however interrupts are not working-- hangs the machine. It does > >> work if polling mode is forced. > >> > >> This diff made the touchscreen and touchpad work be detected and mostly > >> work on my Huawei MateBook D (AMD), however with the touchpad it seems > >> to be break Tap-To-Drag. I don't know if this is a side effect of the > >> drivers polling, unlike the pms(4) support-- which is working on that > >> machine. We have no way to prefer one driver over other, which is why > >> I haven't sent this diff yet. > >> > >> Let me know if it works at all for you. > > > > Much appreciated, will try this and report the outcome > > Applying this patch gives me the following: > > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |Index: dwiic_acpi.c > |=== > |RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v > |retrieving revision 1.8 > |diff -u -p -u -r1.8 dwiic_acpi.c > |--- sys/dev/acpi/dwiic_acpi.c1 Jul 2018 11:37:11 - 1.8 > |+++ sys/dev/acpi/dwiic_acpi.c5 Jun 2019 00:25:29 - > -- > Patching file dwiic_acpi.c using Plan A... > patch: malformed patch at line 9: }; Your mail client may have mangled it-- can you try grabbing it from marc.info? If not, I'll send a direct link. https://marc.info/?l=openbsd-misc&m=156045760827816&q=raw
Re: Lenovo V330-14 touchpad is not working at all
> On 13 Jun 2019, at 22:34, Tristan wrote:
>
>
>
>> On 13 Jun 2019, at 22:25, Bryan Steele wrote:
>>
>> On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote:
>>> Hi there,
>>>
>>> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 8
>>> and so was looking forward to using OpenBSD on this one. I'm currently
>>> running a
>>> snapshot I grabbed today. To get the screen working I had to set
>>> machdep.allowaperture=2
>>> unfortunately, but it works now and great as well. Video seems smooth.
>>> Audio works as well
>>
>> You should avoid doing that -- see recent mailing lists post from Mark
>> Kettenis.
>>
>> https://marc.info/?l=openbsd-misc&m=156029398905090&w=2
>>
>> For Vega graphics you need to recompile your kernel with the amdgpu
>> driver lines uncommented, alternatively reinstall in UEFI mode to get the
>> efifb(4) driver instead. This is probably better as amdgpu support is
>> still a WIP.
>>
>
> OK yes, I remember seeing something about it. Will give that a try. Much
> better then opening up :)
>
>
>>> but the touchpad is not working at all. Wireless card does not work either,
>>> but using the
>>> ethernet port on it for now until I get an USB dongle for it.
>>>
>>> wsconsctl | grep mouse gives me only:
>>> mouse.type=ps2
>>>
>>> In the dmesg output I can see only:
>>> wsmouse0 at pms0 mux 0
>>
>> Indeed, there's no pms(4) compatible touchpad on your machine. :-(
>>
>>> "AMDI0010" at acpi0 not configured
>>> "SYNA2B3F" at acpi0 not configured
>>
>> And instead requires a driver to attach to the I2C HID controler. AMD's
>> implementation seems to be somewhat compatible with dwiic(4) written by
>> jcs@, however interrupts are not working-- hangs the machine. It does
>> work if polling mode is forced.
>>
>> This diff made the touchscreen and touchpad work be detected and mostly
>> work on my Huawei MateBook D (AMD), however with the touchpad it seems
>> to be break Tap-To-Drag. I don't know if this is a side effect of the
>> drivers polling, unlike the pms(4) support-- which is working on that
>> machine. We have no way to prefer one driver over other, which is why
>> I haven't sent this diff yet.
>>
>> Let me know if it works at all for you.
>
> Much appreciated, will try this and report the outcome
Applying this patch gives me the following:
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: dwiic_acpi.c
|===
|RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
|retrieving revision 1.8
|diff -u -p -u -r1.8 dwiic_acpi.c
|--- sys/dev/acpi/dwiic_acpi.c 1 Jul 2018 11:37:11 - 1.8
|+++ sys/dev/acpi/dwiic_acpi.c 5 Jun 2019 00:25:29 -
--
Patching file dwiic_acpi.c using Plan A...
patch: malformed patch at line 9: };
>>
>> -Bryan.
>>
>> Index: dwiic_acpi.c
>> ===
>> RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
>> retrieving revision 1.8
>> diff -u -p -u -r1.8 dwiic_acpi.c
>> --- sys/dev/acpi/dwiic_acpi.c1 Jul 2018 11:37:11 - 1.8
>> +++ sys/dev/acpi/dwiic_acpi.c5 Jun 2019 00:25:29 -
>> @@ -66,6 +66,7 @@ struct cfattach dwiic_acpi_ca = {
>> };
>>
>> const char *dwiic_hids[] = {
>> +"AMDI0010",
>> "INT33C2",
>> "INT33C3",
>> "INT3432",
>> @@ -163,8 +164,11 @@ dwiic_acpi_attach(struct device *parent,
>> dwiic_enable(sc, 0);
>> dwiic_read(sc, DW_IC_CLR_INTR);
>>
>> -/* try to register interrupt with apic, but not fatal without it */
>> -if (crs.irq_int > 0) {
>> +/* XXX: AMD i2c controllers have a problem with interrupts enabled */
>> +if (strcmp(sc->sc_hid, "AMDI0010") == 0)
>> +sc->sc_poll = 1;
>> +else if (crs.irq_int > 0) {
>> +/* try to register interrupt with apic, not fatal without it */
>> printf(" irq %d", crs.irq_int);
>>
>> sc->sc_ih = acpi_intr_establish(crs.irq_int, crs.irq_flags,
>> @@ -294,6 +298,9 @@ dwiic_acpi_bus_scan(struct device *iic,
>> struct dwiic_softc *sc = (struct dwiic_softc *)aux;
>>
>> sc->sc_iic = iic;
>> +/* XXX: Workaround broken interrupts on AMD for i2c slave devices. */
>> +if (strcmp(sc->sc_hid, "AMDI0010") == 0)
>> +sc->sc_poll_ihidev = 1;
>> aml_find_node(sc->sc_devnode, "_HID", dwiic_acpi_found_hid, sc);
>> }
>>
>>
>
Re: IPsec bandwidth perf on APU4C4
On 13 Jun 2019, at 22:46, Stuart Henderson wrote: On 2019/06/13 20:08, mabi wrote: ‐‐‐ Original Message ‐‐‐ On Wednesday, June 12, 2019 10:26 PM, Stuart Henderson wrote: If you're on an old BIOS revision for the APU (more than a couple of months old), try updating, they have enabled "core performance boost" which increases speed of a single core if the others are not under heavy load. I haven't done network benchmarks but there is a noticable improvement in some other things (md5 -tt goes from 12 -> 9 seconds). To update BIOS from OpenBSD, pkg_add flashrom and download the BIOS version for your board (https://pcengines.github.io/). Go to serial console and reboot in single-user mode (boot -s), mount -a, and run "flashrom --programmer internal -w apuX_vXXX.rom". Then reboot back as normal. If you'd like to compare benchmarks, the feature can be toggled from the setup menu in BIOS. https://blog.3mdeb.com/2019/2019-02-14-enabling-cpb-on-pcengines-apu2/ Thanks Stuart for the hint, that sounds fantastic. I bought my APU4 recently so it has a few months old BIOS (v4.0.24 to be precise) and based on the change log it also seems to include that "core performance boost". I need to reboot and check the BIOS settings first see if this new setting is enabled or not by default. I have the feeling it is not enabled. Anyway I think I will upgrade the BIOS to the latest v4.9.0.6. Will keep you posted as soon as I check this but right no I can't reboot the box. 4.9.0.6 does have it enabled by default. I'm not sure about the 4.0.x releases and don't want to reboot mine to check now either :) Beginning with BIOS 4.0.24 CPB is activated for the legacy 4.0.x BIOS (according to pcengines.github.io). My APU2s and APU3s are running smooth with 4.9.0.6 with 6.5-syspatched.
Re: IPsec bandwidth perf on APU4C4
On 2019/06/13 20:08, mabi wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, June 12, 2019 10:26 PM, Stuart Henderson > wrote: > > > If you're on an old BIOS revision for the APU (more than a couple of > > months old), try updating, they have enabled "core performance boost" > > which increases speed of a single core if the others are not under > > heavy load. > > > > I haven't done network benchmarks but there is a noticable improvement > > in some other things (md5 -tt goes from 12 -> 9 seconds). > > > > To update BIOS from OpenBSD, pkg_add flashrom and download the BIOS > > version for your board (https://pcengines.github.io/). Go to serial > > console and reboot in single-user mode (boot -s), mount -a, and run > > "flashrom --programmer internal -w apuX_vXXX.rom". Then reboot back > > as normal. > > > > If you'd like to compare benchmarks, the feature can be toggled > > from the setup menu in BIOS. > > > > https://blog.3mdeb.com/2019/2019-02-14-enabling-cpb-on-pcengines-apu2/ > > Thanks Stuart for the hint, that sounds fantastic. I bought my APU4 recently > so it has a few months old BIOS (v4.0.24 to be precise) and based on the > change log it also seems to include that "core performance boost". I need to > reboot and check the BIOS settings first see if this new setting is enabled > or not by default. I have the feeling it is not enabled. Anyway I think I > will upgrade the BIOS to the latest v4.9.0.6. > > Will keep you posted as soon as I check this but right no I can't reboot the > box. 4.9.0.6 does have it enabled by default. I'm not sure about the 4.0.x releases and don't want to reboot mine to check now either :)
Re: Lenovo V330-14 touchpad is not working at all
> On 13 Jun 2019, at 22:25, Bryan Steele wrote:
>
> On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote:
>> Hi there,
>>
>> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 8
>> and so was looking forward to using OpenBSD on this one. I'm currently
>> running a
>> snapshot I grabbed today. To get the screen working I had to set
>> machdep.allowaperture=2
>> unfortunately, but it works now and great as well. Video seems smooth. Audio
>> works as well
>
> You should avoid doing that -- see recent mailing lists post from Mark
> Kettenis.
>
> https://marc.info/?l=openbsd-misc&m=156029398905090&w=2
>
> For Vega graphics you need to recompile your kernel with the amdgpu
> driver lines uncommented, alternatively reinstall in UEFI mode to get the
> efifb(4) driver instead. This is probably better as amdgpu support is
> still a WIP.
>
OK yes, I remember seeing something about it. Will give that a try. Much
better then opening up :)
>> but the touchpad is not working at all. Wireless card does not work either,
>> but using the
>> ethernet port on it for now until I get an USB dongle for it.
>>
>> wsconsctl | grep mouse gives me only:
>> mouse.type=ps2
>>
>> In the dmesg output I can see only:
>> wsmouse0 at pms0 mux 0
>
> Indeed, there's no pms(4) compatible touchpad on your machine. :-(
>
>> "AMDI0010" at acpi0 not configured
>> "SYNA2B3F" at acpi0 not configured
>
> And instead requires a driver to attach to the I2C HID controler. AMD's
> implementation seems to be somewhat compatible with dwiic(4) written by
> jcs@, however interrupts are not working-- hangs the machine. It does
> work if polling mode is forced.
>
> This diff made the touchscreen and touchpad work be detected and mostly
> work on my Huawei MateBook D (AMD), however with the touchpad it seems
> to be break Tap-To-Drag. I don't know if this is a side effect of the
> drivers polling, unlike the pms(4) support-- which is working on that
> machine. We have no way to prefer one driver over other, which is why
> I haven't sent this diff yet.
>
> Let me know if it works at all for you.
Much appreciated, will try this and report the outcome.
>
> -Bryan.
>
> Index: dwiic_acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
> retrieving revision 1.8
> diff -u -p -u -r1.8 dwiic_acpi.c
> --- sys/dev/acpi/dwiic_acpi.c 1 Jul 2018 11:37:11 - 1.8
> +++ sys/dev/acpi/dwiic_acpi.c 5 Jun 2019 00:25:29 -
> @@ -66,6 +66,7 @@ struct cfattach dwiic_acpi_ca = {
> };
>
> const char *dwiic_hids[] = {
> + "AMDI0010",
> "INT33C2",
> "INT33C3",
> "INT3432",
> @@ -163,8 +164,11 @@ dwiic_acpi_attach(struct device *parent,
> dwiic_enable(sc, 0);
> dwiic_read(sc, DW_IC_CLR_INTR);
>
> - /* try to register interrupt with apic, but not fatal without it */
> - if (crs.irq_int > 0) {
> + /* XXX: AMD i2c controllers have a problem with interrupts enabled */
> + if (strcmp(sc->sc_hid, "AMDI0010") == 0)
> + sc->sc_poll = 1;
> + else if (crs.irq_int > 0) {
> + /* try to register interrupt with apic, not fatal without it */
> printf(" irq %d", crs.irq_int);
>
> sc->sc_ih = acpi_intr_establish(crs.irq_int, crs.irq_flags,
> @@ -294,6 +298,9 @@ dwiic_acpi_bus_scan(struct device *iic,
> struct dwiic_softc *sc = (struct dwiic_softc *)aux;
>
> sc->sc_iic = iic;
> + /* XXX: Workaround broken interrupts on AMD for i2c slave devices. */
> + if (strcmp(sc->sc_hid, "AMDI0010") == 0)
> + sc->sc_poll_ihidev = 1;
> aml_find_node(sc->sc_devnode, "_HID", dwiic_acpi_found_hid, sc);
> }
>
>
Re: Lenovo V330-14 touchpad is not working at all
On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote:
> Hi there,
>
> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 8
> and so was looking forward to using OpenBSD on this one. I'm currently
> running a
> snapshot I grabbed today. To get the screen working I had to set
> machdep.allowaperture=2
> unfortunately, but it works now and great as well. Video seems smooth. Audio
> works as well
You should avoid doing that -- see recent mailing lists post from Mark
Kettenis.
https://marc.info/?l=openbsd-misc&m=156029398905090&w=2
For Vega graphics you need to recompile your kernel with the amdgpu
driver lines uncommented, alternatively reinstall in UEFI mode to get the
efifb(4) driver instead. This is probably better as amdgpu support is
still a WIP.
> but the touchpad is not working at all. Wireless card does not work either,
> but using the
> ethernet port on it for now until I get an USB dongle for it.
>
> wsconsctl | grep mouse gives me only:
> mouse.type=ps2
>
> In the dmesg output I can see only:
> wsmouse0 at pms0 mux 0
Indeed, there's no pms(4) compatible touchpad on your machine. :-(
> "AMDI0010" at acpi0 not configured
> "SYNA2B3F" at acpi0 not configured
And instead requires a driver to attach to the I2C HID controler. AMD's
implementation seems to be somewhat compatible with dwiic(4) written by
jcs@, however interrupts are not working-- hangs the machine. It does
work if polling mode is forced.
This diff made the touchscreen and touchpad work be detected and mostly
work on my Huawei MateBook D (AMD), however with the touchpad it seems
to be break Tap-To-Drag. I don't know if this is a side effect of the
drivers polling, unlike the pms(4) support-- which is working on that
machine. We have no way to prefer one driver over other, which is why
I haven't sent this diff yet.
Let me know if it works at all for you.
-Bryan.
Index: dwiic_acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 dwiic_acpi.c
--- sys/dev/acpi/dwiic_acpi.c 1 Jul 2018 11:37:11 - 1.8
+++ sys/dev/acpi/dwiic_acpi.c 5 Jun 2019 00:25:29 -
@@ -66,6 +66,7 @@ struct cfattach dwiic_acpi_ca = {
};
const char *dwiic_hids[] = {
+ "AMDI0010",
"INT33C2",
"INT33C3",
"INT3432",
@@ -163,8 +164,11 @@ dwiic_acpi_attach(struct device *parent,
dwiic_enable(sc, 0);
dwiic_read(sc, DW_IC_CLR_INTR);
- /* try to register interrupt with apic, but not fatal without it */
- if (crs.irq_int > 0) {
+ /* XXX: AMD i2c controllers have a problem with interrupts enabled */
+ if (strcmp(sc->sc_hid, "AMDI0010") == 0)
+ sc->sc_poll = 1;
+ else if (crs.irq_int > 0) {
+ /* try to register interrupt with apic, not fatal without it */
printf(" irq %d", crs.irq_int);
sc->sc_ih = acpi_intr_establish(crs.irq_int, crs.irq_flags,
@@ -294,6 +298,9 @@ dwiic_acpi_bus_scan(struct device *iic,
struct dwiic_softc *sc = (struct dwiic_softc *)aux;
sc->sc_iic = iic;
+ /* XXX: Workaround broken interrupts on AMD for i2c slave devices. */
+ if (strcmp(sc->sc_hid, "AMDI0010") == 0)
+ sc->sc_poll_ihidev = 1;
aml_find_node(sc->sc_devnode, "_HID", dwiic_acpi_found_hid, sc);
}
Re: IPsec bandwidth perf on APU4C4
‐‐‐ Original Message ‐‐‐ On Wednesday, June 12, 2019 10:26 PM, Stuart Henderson wrote: > If you're on an old BIOS revision for the APU (more than a couple of > months old), try updating, they have enabled "core performance boost" > which increases speed of a single core if the others are not under > heavy load. > > I haven't done network benchmarks but there is a noticable improvement > in some other things (md5 -tt goes from 12 -> 9 seconds). > > To update BIOS from OpenBSD, pkg_add flashrom and download the BIOS > version for your board (https://pcengines.github.io/). Go to serial > console and reboot in single-user mode (boot -s), mount -a, and run > "flashrom --programmer internal -w apuX_vXXX.rom". Then reboot back > as normal. > > If you'd like to compare benchmarks, the feature can be toggled > from the setup menu in BIOS. > > https://blog.3mdeb.com/2019/2019-02-14-enabling-cpb-on-pcengines-apu2/ Thanks Stuart for the hint, that sounds fantastic. I bought my APU4 recently so it has a few months old BIOS (v4.0.24 to be precise) and based on the change log it also seems to include that "core performance boost". I need to reboot and check the BIOS settings first see if this new setting is enabled or not by default. I have the feeling it is not enabled. Anyway I think I will upgrade the BIOS to the latest v4.9.0.6. Will keep you posted as soon as I check this but right no I can't reboot the box.
Re: The su manual doesn't mention use root account by default
On 6/13/2019 9:42 AM, Adam Thompson wrote: On 2019-06-12 03:55, Ingo Schwarze wrote: During initial system installation & deployment, before doas is configured, and assuming you haven't [yet] added your SSH keys to ~root/.ssh/allowed_keys, it's quite impossible to avoid using su. (AFAIK. If there's another way, let me know!) siteXX.tgz https://www.openbsd.org/faq/faq4.html#site
Lenovo V330-14 touchpad is not working at all
Hi there, I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 8 and so was looking forward to using OpenBSD on this one. I'm currently running a snapshot I grabbed today. To get the screen working I had to set machdep.allowaperture=2 unfortunately, but it works now and great as well. Video seems smooth. Audio works as well but the touchpad is not working at all. Wireless card does not work either, but using the ethernet port on it for now until I get an USB dongle for it. wsconsctl | grep mouse gives me only: mouse.type=ps2 In the dmesg output I can see only: wsmouse0 at pms0 mux 0 Also here my full dmesg. Any help getting this working would be much appreciated. OpenBSD 6.5-current (GENERIC.MP) #22: Wed Jun 12 20:26:15 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6322868224 (6029MB) avail mem = 6121107456 (5837MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xe3b60 (50 entries) bios0: vendor LENOVO version "3ECN35WW(V3.02)" date 11/24/2018 bios0: LENOVO 81B1 acpi0 at bios0: ACPI 5.0Undefined scope: \\_SB_.PCI0.GPP2.BCM5 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI MSDM SSDT ASF! BOOT HPET APIC MCFG SLIC WSMT SSDT CRAT CDIT UEFI SSDT IVRS SSDT SSDT SSDT SSDT SSDT SSDT FPDT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) XHC0(S3) XHC1(S3) GP18(S4) PWRB(S4) 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 5 2500U with Radeon Vega Mobile Gfx, 1996.64 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 5 2500U with Radeon Vega Mobile Gfx, 1996.23 MHz, 17-11-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx, 1996.23 MHz, 17-11-00 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, 4MB 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 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx, 1996.23 MHz, 17-11-00 cpu3: 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 cpu3: 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
Re: Puffy — format SVG
On Thu, Jun 13, 2019 at 2:38 PM Stephane HUC "PengouinBSD" wrote: > https://stephane-huc.net/img/EBNH/OBSD/Puffy.svg This looks like an svg raster image (as opposed to a vector image, which would take some manual effort). Probably worth setting expectations accordingly? Thanks, -- Raul
Puffy — format SVG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 For a little project to promote, I had the idea to convert the gif image about Puffy, into svg with Inkscape. Some will consider it a bad idea ... ! At least, the image in SVG format exists. it is available on my server: https://stephane-huc.net/img/EBNH/OBSD/Puffy.svg Voilà! :D PS: If someone wants to put it on the openbsd www, it's up to you! ;) - -- ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<< - Stephane HUC as PengouinBSD or CIOTBSD b...@stephane-huc.net -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQScTRXz7kMlZfGpDZMTq98t3AMG7wUCXQKXrgAKCRATq98t3AMG 755TAQCe6mlsM7iYoYlYQSdE7nh7uaxR7C/xTOP19l5lk6+YVQD/fgqPutl2dm4s 2XpB5OhLUZp4GM4MSz/Xw8qPY+UyPwk= =FjrT -END PGP SIGNATURE-
Re[2]: How does OpenBSD probe for I/O devices?
>Look under /usr/src/sys/arch/* for functions with "_attach_" in their >names, which should give you a very rough idea of where to start >looking. thanks.
Re: How does OpenBSD probe for I/O devices?
On 2019-06-12 13:12, ¯\__/¯ ¯\__/¯ wrote: I've search for the answer to this question, but I can't find it. I also read the source code, but I still don't get how it works. Help pl0x Not sure exactly what you're looking for... On modern architectures, most OSes (including OpenBSD) "walk the hardware device tree". The possible topologies and nodes of the device tree are controlled by the kernel source code. OpenBSD does 99% of it at boot time, with a few notable exclusions (PCMCIA, PC CARD, USB, can't remember what else). Look under /usr/src/sys/arch/* for functions with "_attach_" in their names, which should give you a very rough idea of where to start looking. For both historical and somewhat-current documentation on how this works, check out https://en.wikipedia.org/wiki/Marshall_Kirk_McKusick#Bibliography . (I'm unaware of any OpenBSD-specific publications covering that sort of thing, but OpenBSD *is* derived from the same BSD UNIX that Kirk wrote about. Lessons learned about one BSD can, usually, have their concepts applied to their cousins - although the implementation details have diverged quite a bit by now.) -Adam
Re: The su manual doesn't mention use root account by default
Well, I often need a root shell. Usually I login as a user in group wheel, but not operator! The perils of group operator were explained in a previous thread. I don't use that group anymore. As I understand, nothing like a web browser, etc. should ever be used by root. So I don't. I have been using doas su -l to get a root shell, while using those other programs as the original user. I never use ssh from the root shell. Am I doing something unsafe here? Should I NOT open the root shell and only execute each command with doas? That's easy to do also. A third choice is actually to login as root directly. Does having a root shell open continously, but only when using it, cause me to have a significant security risk? It's convienent, but not necessary. And there was that tty security problem that came up in another thread. I've been meaning to ask this question, seems like a good thread to ask it in. Things have changed significantly recently, so I feel a little unsure how things stand now. Thanks, Chris Bennett
Re: The su manual doesn't mention use root account by default
On 2019-06-12 03:55, Ingo Schwarze wrote: Even though su(1) can still be used today to relinquish privilege when you are already root, no more development is done on it and people rarely look at the manual page. The last time new functionality was added to the su(1) manual page was almost a decade ago, and the last time before that 17 years ago. Well, su(8) also is used to obtain root privileges in the first place. FWIW, I regularly use "su" on OpenBSD because it's a relatively consistent cross-platform way to have root run a command as someone else. I recall a good number of ports using su(8) internally in, e.g. process-control scripts - but that was years ago, not sure if it's still true or not. doas simply isn't available anywhere else (yet). (IMHO, I don't think a portable version of doas has a lot of potential - it's not complicated enough! ) During initial system installation & deployment, before doas is configured, and assuming you haven't [yet] added your SSH keys to ~root/.ssh/allowed_keys, it's quite impossible to avoid using su. (AFAIK. If there's another way, let me know!) I hope you're just saying that su(8) is a mature, stable utility that needs no further work right now. It kind of sounds like you might be saying that su(8) could be on the chopping block, much like sudo(8)... have I misread that? -Adam
Re: mdoc for REST APIs?
Hi Maximilian, let me start with a disclaimer. While at one time several years ago, an employer forced me to work on REST APIs, i hated it and have forgotten all about it. So it is safe to assume that i have no expertise whatsoever on REST. Yet, assuming you know about REST, what i'm saying about mdoc(7) might allow you to piece things together. Maximilian Lorlacks wrote on Thu, Jun 13, 2019 at 12:32:04PM +: > I like mdoc. It feels like a natural fit for operating system > documentation. It is true that Cynthia Livingston originally developed mdoc(7) for documentation of the C and shell languages, but i do believe it can be used beyond that. That said, i can't say whether using mdoc(7) for a REST API is a good or a bad idea. From a brief perusal of the web, it appears that some recommend tools like OpenAPI (i don't fully understand what that is yet), but it appears it integrates documentation with other purposes. While in general, i strongly oppose the idea of mixing code and documentation, lacking knowledge of REST, i can't say whether my arguments really apply to REST. Using something like OpenAPI might be a good idea because documenting REST may have more requirements than documentation in general and of other languages. Or it may be a good idea to avoid such heavy-weight tools (one site i found said learning the basics of OpenAPI such that you can become productive with it will take you about two weeks of full-time work, which sound quite ridiculous to me - for comparison, i started productive work in both Python and XSLT after half a day of learning each, and those are bloody programming languages, not mere documentation tools): So avoiding OpenAPI and the like may keep stuff simple. I just don't know which of the two is the better argument. All i'm saying below applies *if* you come to the conclusion that a simple, stand-alone tool is as reasonable for REST as for any other language. > Recently however, I've been in a position to document > a REST API. I was wondering how mdoc could be made to work there. > Many of the tags do not fit: For example, there seems to be nothing > to properly map the request method (GET, POST, PUT, DELETE), Those are essentially command names in the HTTP protocol: $ telnet www.openbsd.org 80 Trying 129.128.5.194... Connected to www.openbsd.org. Escape character is '^]'. HEAD / HTTP1.1 Host: www.openbsd.org HTTP1.1 200 OK [...] But they are not the topic of the manual page you are writing, nor do they have their own manual page GET(1) or GET(3) or GET(1http). Consequently, i would simply use .Ic, "internal command" (that is, internal to the HTTP language). > the closest equivalents seem to be Dv and Ft, but neither really fit. No, those are not even in the right formatting group (in this case .Nm .Fl .Cm .Ic .Fn .Cd .Ms .Sy). Note that formatting groups are not documentated because people don't need to worry about them unless adapting mdoc(7) to a new language. Besides, .Dv should only be used for things that are defined after the fact, not for keywords built into a language, and .Ft is really only for data types. > Nm would *have* to contain the method and the path, but Nm also > requires exactly one argument to be given, so that's extra quoting > effort. Currently, i'm looking at https://bocoup.com/blog/documenting-your-api If i understand correctly, the .Nm could be, in the NAME and SYNOPSIS sections and in the running text: .Nm users .Sh SYNOPSIS .Pf / Nm users .br .Pf / Nm users Ns /: Ns Ar id .br .Pf / Nm users Ns ? Ns Cm id Ns =: Ns Ar id or .Sh SYNOPSIS .Nm /users .Nm /users Ns /: Ns Ar id .Nm /users Ns ? Ns Cm id Ns =: Ns Ar id to make .Nm work as a block macro in this special case. >From the roff(7) perspective, nothing would be wrong with ".Nm /users", the slash is just a normal character in roff(7), but man(1) doesn't like that: if the argument to man(1) contains a slash, -l is implied, so with ".Nm /users", ou would have to use man -ak Nm=/users which is admittedly awkward. Besides, you can look at the slash as punctuation in the URI rather than part of the name, and where you want to stress the slash, nothing is wrong with writing .Pf / Nm users . > With REST, you often want to provide an overview of request input > and outputs. These are somewhat analogous to function arguments > and struct output types. Often, the responses may be ad-hoc and > not really have a "type" of sorts. You mean, like the "Data Params" and "Sample Call" on the bocoup.com page i quoted? If you want to talk about an individual field, .Fa email sounds reasonable, and .Vt string for its type. To display a complete, multi-line JSON structure, you would probably use .Bd; for an example, .Bd -literal, for a syntactic display with individual elements marked up, .Bd -ragged. > You tend to need a top-level explanation that describes how error > handling works, how data is serialized (XML,
Re: The su manual doesn't mention use root account by default
Hi, Christian Weisgerber wrote on Thu, Jun 13, 2019 at 11:13:11AM -: > On 2019-06-13, "Theo de Raadt" wrote: >> Somebody wrote: >>> I always considered that su is coming from _s_uper _u_ser. But maybe I >>> am wrong, I am not from old UNIX days. >> incorrect. >> >> NAME >> su - substitute user identity > Well, that's V7, which appears to have engaged in a bit of revisionism > together with the then newly expanded functionality. > > Earlier in V6 it was "su - become privileged user" and "Su allows > one to become the super-user, who has all sorts of marvelous (and > correspondingly dangerous) powers". > > http://man.cat-v.org/unix-6th/8/su Actually, that text (without the parenthetic remark) goes back all the way to v1 (Nov/3/71), To scare you a bit, the SYNOPSIS in v1 said: su password and the DESCRIPTION: In order for su to do its magic, the user must pass as an argument a password. There was a BUGS section, but it was explicitly empty. Those were more carefree times. The table of contents in v2 even said, under section I: su ... become super-user https://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/man13.pdf https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/unix_2nd_edition_manual.pdf I just committed a fix to the HISTORY section of the manual page. CVSROOT:/cvs Module name:src Changes by: schwa...@cvs.openbsd.org2019/06/13 06:59:51 Modified files: usr.bin/su : su.1 Log message: su(I) goes back all the way to v1: https://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/man13.pdf It wasn't in v0 PDP-7 UNIX though: https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZero.txt Index: su.1 === RCS file: /cvs/src/usr.bin/su/su.1,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- su.112 Jun 2019 08:29:17 - 1.32 +++ su.113 Jun 2019 12:59:51 - 1.33 @@ -273,7 +273,7 @@ .Sh HISTORY A .Nm -command appeared in -.At v7 . +command first appeared in +.At v1 . .Sh BUGS The login name is not optional for root if there are shell arguments.
mdoc for REST APIs?
Hi all, I like mdoc. It feels like a natural fit for operating system documentation. Recently however, I've been in a position to document a REST API. I was wondering how mdoc could be made to work there. Many of the tags do not fit: For example, there seems to be nothing to properly map the request method (GET, POST, PUT, DELETE), the closest equivalents seem to be Dv and Ft, but neither really fit. Nm would *have* to contain the method and the path, but Nm also requires exactly one argument to be given, so that's extra quoting effort. With REST, you often want to provide an overview of request input and outputs. These are somewhat analogous to function arguments and struct output types. Often, the responses may be ad-hoc and not really have a "type" of sorts. You tend to need a top-level explanation that describes how error handling works, how data is serialized (XML, JSON or something even more horrifying) and how authentication works. Would a dedicated introduction page be alright for that? Filenames are another issue. '/' is an invalid character on UNIX within a filename, but a REST method starts with a '/'. This will cause the Dt and filename to always mismatch. Has anyone used mdoc for REST API documentation before? How did you make it work? If not: What would be the path of least resistance, surely not DocBook? Max
Re: The su manual doesn't mention use root account by default
On 2019-06-13, "Theo de Raadt" wrote: >> I always considered that su is coming from _s_uper _u_ser. But maybe I >> am wrong, I am not from old UNIX days. > > incorrect. > > NAME > su - substitute user identity Well, that's V7, which appears to have engaged in a bit of revisionism together with the then newly expanded functionality. Earlier in V6 it was "su - become privileged user" and "Su allows one to become the super-user, who has all sorts of marvelous (and correspondingly dangerous) powers". http://man.cat-v.org/unix-6th/8/su -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: The su manual doesn't mention use root account by default
> Ingo seems to be rather good at those. My favorites are Nick Holland's answers. But let's not forget Stuart Henderson, Henning Brauer, Stefan Sperling, Marc Espie ... and Dr. House. The answers from the latter are hard to digest but always solid and in place. May be others too, my excuses for not mentioning them. And for killing the thread.
Re: cwm with multi head setup
Hello, On Wed, 12 Jun 2019 22:10:20 +0200 Henry Jensen wrote: > I'm using OpenBSD Xenocara current with a multi head (dual monitor) > setup. After using fluxbox and dwm I now wanted to try cwm. > > I like it so far, but is there a way I can move the current window from > one monitor to the other with one single keybinding (i.e. like the > "focusmon" command in the dwm window manager)? What I have found out so far: It was suggested on Mastodon, that cwm handles multiple monitors as one, big screen. However, window-snap-left/right "snaps" the current window on the edge of the current monitor. window-snap-* doesn't move windows across monitors. That would suggest, that cwm is aware of multiple monitors after all. Someone gave me a hint to use xdotool and wmctrl. I found a python script at https://github.com/calandoa/movescreen which utilizes this two tools. With this I am able to move a window from the left monitor to the right, but not vice versa. In other winow mangers (e.g. fluxbox) it works in both directions, as it should.
Re: [mark.kette...@xs4all.nl: Check your machdep.allowaperture setting]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 HI, Marc. Thanks for thoses explains. Is there a solution? especially when you have a arch Optimum GPU, where only the Intel GPU works? (yes, I know nvidia is evil!) On 6/13/19 10:55 AM, Marc Espie wrote: > On Wed, Jun 12, 2019 at 06:20:55PM +0200, Stephane HUC "PengouinBSD" wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Hi, >> >> In the french documentation on obsd4a's wiki, I wrote: >> >> "When to add this option? >> When you see into xorg.log: >> $ head /var/log/Xorg.0.log >> [ 33.839] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem >> (Operation not permitted) >> Check that you have set 'machdep.allowaperture=1' >> in /etc/sysctl.conf and reboot your machine >> refer to xf86(4) for details >> (...) >> " >> It's right? >> >> You mention security risks and others problems. >> Which? >> Could you explain simply, please? > > Well, duh. > > allowaperture allows you to open the graphics device, which was the old > model prior to intel graphics and more. > > *if* X + inteldrm no longer needs the graphics device, it does not open > it. > > ... but it's still around. > > ... and allowaperture means some program could possibly still open it, > thus gaining low-level access to some part of the graphics card. > > The attack surface of graphics hardware being huge, it's likely you can > still do harm through that backdoor. - -- ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<< - Stephane HUC as PengouinBSD or CIOTBSD b...@stephane-huc.net -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQScTRXz7kMlZfGpDZMTq98t3AMG7wUCXQIZeAAKCRATq98t3AMG 79tcAQD5+tKHzYenoVxAFzYm8noVJfbEO/qM/7AOxM7AKZZCUwEA8Hri9xFzWEZj fuguxJEm1rHIiNBkerWLJWdd08bX9gk= =t14P -END PGP SIGNATURE-
Re: The su manual doesn't mention use root account by default
Nan Xiao writes: > Hi Ingo, > > Thanks for your detailed explanation! Ingo seems to be rather good at those. The last trivial question I asked got an exposé on precisely how the ports and base development processes interact with one another. I propose a motion that every answer Igno makes to a question be turned into a FAQ item. Or, slightly more seriously, that response I got the other day on ports@ should be in a "how to do ports" document because wow, Ingo, you seem to have a knack for detailed (and *clear*) explanations and I don't think I thanked you for putting it all out there for me. Matthew
Re: dhcpd and Polycom SoundPoint IP 550 phones
> After several days of desperation ... There is no need for this. Try to see the dhcpd's logs, after you put the server to log it to the maximum extent for you. Then you can try tcpdump to watch closely the Polycom's requests, you can see if they are out of standard crap or if there is a problem there. Try again with another client computer, see if it can obtain an address - this way you can check if your dhcp server is correctly configured.
Re: The su manual doesn't mention use root account by default
On Thu, Jun 13, 2019 at 08:55:09AM +0100, Andrew Luke Nesbit wrote: > On 13/06/2019 07:17, Theo de Raadt wrote: > > Mihai Popescu wrote: > > > >>> ... if no account is provided, root is the default > >> > >> I always considered that su is coming from _s_uper _u_ser. But maybe I > >> am wrong, I am not from old UNIX days. > > > > incorrect. > > > > NAME > > su - substitute user identity > > > > I never noticed this before. It's my favorite bit of *nix trivia that > defies misguided assumptions since I learned that `/etc` is apparently > an initialism for "editible text configuration". > > Andrew Right... and the perfect match to commonly used "et caetera" is just pure coincidence. Lol.
Re: [mark.kette...@xs4all.nl: Check your machdep.allowaperture setting]
On Wed, Jun 12, 2019 at 06:20:55PM +0200, Stephane HUC "PengouinBSD" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > In the french documentation on obsd4a's wiki, I wrote: > > "When to add this option? > When you see into xorg.log: > $ head /var/log/Xorg.0.log > [33.839] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem > (Operation not permitted) > Check that you have set 'machdep.allowaperture=1' > in /etc/sysctl.conf and reboot your machine > refer to xf86(4) for details > (...) > " > It's right? > > You mention security risks and others problems. > Which? > Could you explain simply, please? Well, duh. allowaperture allows you to open the graphics device, which was the old model prior to intel graphics and more. *if* X + inteldrm no longer needs the graphics device, it does not open it. ... but it's still around. ... and allowaperture means some program could possibly still open it, thus gaining low-level access to some part of the graphics card. The attack surface of graphics hardware being huge, it's likely you can still do harm through that backdoor.
Re: Putting fifos in subshells into the background
Philip Guenther wrote:
> On Wed, Jun 12, 2019 at 12:54 AM Richard Ulmer
> wrote:
>
> > while making the Kakoune editor work on OpenBSD, I encountered some
> > strange behaviour [1]. This little script doesn't work with the OpenBSD
> > sh, but works at least with dash, bash and zsh:
> >
> > mkfifo 'testfifo'
> > cat "$(
> > ( printf 'foo\n' > testfifo 2>&1 ) > /dev/null 2>&1 &
> > printf 'testfifo'
> > )"
> >
> > I can make it work for all the mentioned shells like this:
> >
> > mkfifo 'testfifo'
> > cat "$(
> > ( ( printf 'foo\n' > testfifo 2>&1 ) & ) > /dev/null 2>&1
> > printf 'testfifo'
> > )"
> >
> > Can someone explain or justify the behaviour of the OpenBSD sh, or do
> > you think this is a bug?
> >
>
> This is a bug, almost certainly from an over-zealous optimization in the
> logic handling subshells where the possibility that an inner redirection
> could be blocking wasn't taken into account when it tries to avoid
> unnecessary forks.
Thanks for the clarification! I'll note your assessment on the issue for
Kakoune.
> Sorry, I don't have a fix in my back pocket. Your workaround is good; I'll
> note the intermediate set of parens can also be braces, which would let you
> avoid the otherwise necessary whitespace between open-parens if that grates
> on your soul like it does mine. :)
I feel you, but I'm afraid our souls will keep getting grated, because
unfortunately bash and the like won't work if I use `{}` instead of the
intermediate `()`. I guess this is a bug of thes other shells then.
Thanks for your help!
Richard Ulmer
Re: The su manual doesn't mention use root account by default
On 13/06/2019 07:17, Theo de Raadt wrote: > Mihai Popescu wrote: > >>> ... if no account is provided, root is the default >> >> I always considered that su is coming from _s_uper _u_ser. But maybe I >> am wrong, I am not from old UNIX days. > > incorrect. > > NAME > su - substitute user identity > I never noticed this before. It's my favorite bit of *nix trivia that defies misguided assumptions since I learned that `/etc` is apparently an initialism for "editible text configuration". Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
