Re: Pass -U to pgrep and pkill in rc.subr(8)

2021-11-25 Thread Ville Valkonen
Hello,

I would guess the main reason is privilege separation. There will be
privileged (owner root) and unprivileged (dedicated user) processess and
both needs to be killed.

--
Kind regards,
Ville Valkonen

On Fri 26. Nov 2021 at 2.24, Vincent Lee  wrote:

> Hey all,
>
> I noticed that rc.subr(8)'s invocations of pgrep(1) and pkill(1) don't
> filter by the user (by passing -U or -u). I'm wondering if there's a
> reason for this?
>
> The reason is that I'm running thelounge (thelounge.chat). It's a NodeJS
> application, and by default its command line shows in top(1) as
> "node". I know that I can set `pexp` in my rc script, but setting it to
> just "node" without filtering by user seems overly broad, in case other
> node binaries are running as other users.
>
> I know I can also override rc_check and friends entirely in the rc
> script, but this seems like something that most rc scripts can benefit
> from.
>
> Here's a diff that makes the change, but let me know if this wasn't done
> for any reason or other ways I can get around this problem. Thanks!
>
> diff --git etc/rc.d/rc.subr etc/rc.d/rc.subr
> index 2af4887d1..addc6f95d 100644
> --- etc/rc.d/rc.subr
> +++ etc/rc.d/rc.subr
> @@ -144,7 +144,7 @@ _rc_alarm()
>  }
>
>  _rc_sendsig() {
> -   pkill -${1:-TERM} -T "${daemon_rtable}" -xf "${pexp}"
> +   pkill -${1:-TERM} -T "${daemon_rtable}" -U "${daemon_user}" -xf
> "${pexp}"
>  }
>
>  _rc_wait_for_start() {
> @@ -165,7 +165,7 @@ rc_start() {
>  }
>
>  rc_check() {
> -   pgrep -T "${daemon_rtable}" -q -xf "${pexp}"
> +   pgrep -T "${daemon_rtable}" -U "${daemon_user}" -q -xf "${pexp}"
>  }
>
>  rc_reload() {
>
>


Re: uhidpp(4): logitech hid++ device driver

2021-02-03 Thread Ville Valkonen
On Tue, 2021-02-02 at 19:55 +0100, Anton Lindqvist wrote:
> On Tue, Feb 02, 2021 at 01:00:48PM +0100, Marcus Glocker wrote:
> > On Tue, Feb 02, 2021 at 08:23:29AM +0100, Anton Lindqvist wrote:
> > 
> > > On Sat, Jan 30, 2021 at 01:18:07PM +0200, Ville Valkonen wrote:
> > > > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote:
> > > > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I have a bit oldish Logitech M705 mouse, bought around
> > > > > > 2010-2011.
> > > > > > Regarding the dmesg (on below) I can see it gets attached
> > > > > > correctly
> > > > > > to
> > > > > > uhiddp0 but doesn't report battery levels. Here's the line
> > > > > > from
> > > > > > dmesg:
> > > > > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx,
> > > > > > device
> > > > > > 2 keyboard "K750" serial xx-xx-xx-xx.
> > > > > > And corresponding sysctl values:
> > > > > > hw.sensors.uhidpp0.raw0=unknown (battery levels)
> > > > > > hw.sensors.uhidpp0.raw1=unknown (battery levels)
> > > > > > hw.sensors.uhidpp0.percent0=unknown (battery level)
> > > > > > hw.sensors.uhidpp0.percent1=unknown (battery level)
> > > > > > 
> > > > > > Not sure if censoring of serial has any value, though.
> > > > > 
> > > > > Glad to see it attaches fine to a receiver with more than one
> > > > > device
> > > > > paired. I only have one device myself and have therefore
> > > > > never been
> > > > > enable to verify this.
> > > > > 
> > > > > Could you enable UHIDPP_DEBUG and send me the output?
> > > > > 
> > > > > > On Ubuntu battery levels are detected correctly so I could
> > > > > > probably
> > > > > > take a USB dump with Wireshark and compare the differences.
> > > > > 
> > > > > Taking a USB dump on your Linux machine would be very
> > > > > helpful.
> > > > 
> > > > Hi,
> > > > 
> > > > Yes. Also remembered that you were mentioning about the debug
> > > > flag but
> > > > completely forgot that while testing. Then just before going to
> > > > sleep
> > > > recalled the debug flag. Here are the results with debug
> > > > enabled:
> > > > 
> > > > uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech
> > > > USB Receiver" rev 2.00/12.10 addr 3
> > > > uhidev0: iclass 3/1
> > > > ukbd0 at uhidev0: 8 variable keys, 6 key codes
> > > > wskbd1 at ukbd0 mux 1
> > > > wskbd1: connecting to wsdisplay0
> > > > uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech
> > > > USB Receiver" rev 2.00/12.10 addr 3
> > > > uhidev1: iclass 3/1, 8 report ids
> > > > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir
> > > > wsmouse2 at ums0 mux 0
> > > > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
> > > > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
> > > > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
> > > > uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech
> > > > USB Receiver" rev 2.00/12.10 addr 3
> > > > uhidev2: iclass 3/0, 33 report ids
> > > > uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00]
> > > > uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00
> > > > 00 00 00 00]
> > > > hidpp_send_report: 10 ff 83 b5 [20 00 00]
> > > > uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00
> > > > 00 00 00 00]
> > > > hidpp_send_report: 10 ff 83 b5 [40 00 00]
> > > > uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00
> > > > 00 00 00 00]
> > > >  device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10
> > > > ff 83 b5 [31 00 00]
> > > > uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00
> > > > 00 00 00 00]
> > > > hidpp_send_report: 10 ff 83 b5 [21 00 00]
> > > > uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00
> > > > 00 

Re: uhidpp(4): logitech hid++ device driver

2021-01-30 Thread Ville Valkonen
On Sat, 2021-01-30 at 13:18 +0200, Ville Valkonen wrote:
> On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote:
> > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote:
> > > Hi,
> > > 
> > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011.
> > > Regarding the dmesg (on below) I can see it gets attached
> > > correctly
> > > to
> > > uhiddp0 but doesn't report battery levels. Here's the line from
> > > dmesg:
> > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx,
> > > device
> > > 2 keyboard "K750" serial xx-xx-xx-xx.
> > > And corresponding sysctl values:
> > > hw.sensors.uhidpp0.raw0=unknown (battery levels)
> > > hw.sensors.uhidpp0.raw1=unknown (battery levels)
> > > hw.sensors.uhidpp0.percent0=unknown (battery level)
> > > hw.sensors.uhidpp0.percent1=unknown (battery level)
> > > 
> > > Not sure if censoring of serial has any value, though.
> > 
> > Glad to see it attaches fine to a receiver with more than one
> > device
> > paired. I only have one device myself and have therefore never been
> > enable to verify this.
> > 
> > Could you enable UHIDPP_DEBUG and send me the output?
> > 
> > > On Ubuntu battery levels are detected correctly so I could
> > > probably
> > > take a USB dump with Wireshark and compare the differences.
> > 
> > Taking a USB dump on your Linux machine would be very helpful.
> 
> Hi,
> 
> Yes. Also remembered that you were mentioning about the debug flag
> but
> completely forgot that while testing. Then just before going to sleep
> recalled the debug flag. Here are the results with debug enabled:
> 
> uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB
> Receiver" rev 2.00/12.10 addr 3
> uhidev0: iclass 3/1
> ukbd0 at uhidev0: 8 variable keys, 6 key codes
> wskbd1 at ukbd0 mux 1
> wskbd1: connecting to wsdisplay0
> uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB
> Receiver" rev 2.00/12.10 addr 3
> uhidev1: iclass 3/1, 8 report ids
> ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir
> wsmouse2 at ums0 mux 0
> uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
> uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
> uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
> uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB
> Receiver" rev 2.00/12.10 addr 3
> uhidev2: iclass 3/0, 33 report ids
> uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00]
> uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00
> 00 00]
> hidpp_send_report: 10 ff 83 b5 [20 00 00]
> uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00
> 00 00]
> hidpp_send_report: 10 ff 83 b5 [40 00 00]
> uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00
> 00 00]
>  device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83
> b5 [31 00 00]
> uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00
> 00 00]
> hidpp_send_report: 10 ff 83 b5 [21 00 00]
> uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00
> 00 00]
> hidpp_send_report: 10 ff 83 b5 [41 00 00]
> uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00
> 00 00]
> , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff
> 83 b5 [32 00 00]
> uhidpp_intr: 10 ff 8f 83 [b5 03 00]
> hidpp_send_report: 10 ff 83 b5 [33 00 00]
> uhidpp_intr: 10 ff 8f 83 [b5 03 00]
> hidpp_send_report: 10 ff 83 b5 [34 00 00]
> uhidpp_intr: 10 ff 8f 83 [b5 03 00]
> hidpp_send_report: 10 ff 83 b5 [35 00 00]
> uhidpp_intr: 10 ff 8f 83 [b5 03 00]
> hidpp_send_report: 10 ff 80 00 [10 09 00]
> uhidpp_intr: 10 ff 80 00 [00 00 00]
> 
> 
> That's when the mouse was off. When I switched on the mouse kernel
> panicked. I couldn't break into DDB or alternatively failed to type
> correct commands blindly. Eventually had to shutdown the system by
> pressing the power button. Picture of the panic is here:
> https://imgur.com/a/QRAD5v1
> 
> Btw. Time has passed since my previous kernel compile. I saw the
> procedure has changed a bit since then. I initially tried to compile
> debug flags by prepending `option UHIDPP_DEBUG` to
> sys/arch/amd64/compile/GENERIC.MP but couldn't see debug lines in
> dmesg. By doing the "old way" I got the debug lines:
> cd arch/amd64/conf
> cp GENERIC.MP HIDPP.MP
> # Add debug flags at this point
> config HIDPP.MP
> and compiling as usual. Is this the correct way to do it?
> 
> I'll do the Wireshark later in the evening.
> 
> --
> Regards,
> Ville

Hello,

please find the link covering the USB capture on Ubuntu:

https://paste.c-net.org/FieryExperts

What I did:
- Turned mouse on
- Moved it around
- Clicked left, middle and right buttons (not in that order)

If you need more more information, please let me know.

--
Kind regards,
Ville



Re: uhidpp(4): logitech hid++ device driver

2021-01-30 Thread Ville Valkonen
On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote:
> On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote:
> > Hi,
> > 
> > I have a bit oldish Logitech M705 mouse, bought around 2010-2011.
> > Regarding the dmesg (on below) I can see it gets attached correctly
> > to
> > uhiddp0 but doesn't report battery levels. Here's the line from
> > dmesg:
> > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device
> > 2 keyboard "K750" serial xx-xx-xx-xx.
> > And corresponding sysctl values:
> > hw.sensors.uhidpp0.raw0=unknown (battery levels)
> > hw.sensors.uhidpp0.raw1=unknown (battery levels)
> > hw.sensors.uhidpp0.percent0=unknown (battery level)
> > hw.sensors.uhidpp0.percent1=unknown (battery level)
> > 
> > Not sure if censoring of serial has any value, though.
> 
> Glad to see it attaches fine to a receiver with more than one device
> paired. I only have one device myself and have therefore never been
> enable to verify this.
> 
> Could you enable UHIDPP_DEBUG and send me the output?
> 
> > On Ubuntu battery levels are detected correctly so I could probably
> > take a USB dump with Wireshark and compare the differences.
> 
> Taking a USB dump on your Linux machine would be very helpful.

Hi,

Yes. Also remembered that you were mentioning about the debug flag but
completely forgot that while testing. Then just before going to sleep
recalled the debug flag. Here are the results with debug enabled:

uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB Receiver" rev 
2.00/12.10 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB Receiver" rev 
2.00/12.10 addr 3
uhidev1: iclass 3/1, 8 report ids
ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir
wsmouse2 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB Receiver" rev 
2.00/12.10 addr 3
uhidev2: iclass 3/0, 33 report ids
uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00]
uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00 00 00]
hidpp_send_report: 10 ff 83 b5 [20 00 00]
uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00 00 00]
hidpp_send_report: 10 ff 83 b5 [40 00 00]
uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00 00 00]
 device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83 b5 [31 00 
00]
uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00 00 00]
hidpp_send_report: 10 ff 83 b5 [21 00 00]
uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00 00 00]
hidpp_send_report: 10 ff 83 b5 [41 00 00]
uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00 00 00]
, device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff 83 b5 [32 
00 00]
uhidpp_intr: 10 ff 8f 83 [b5 03 00]
hidpp_send_report: 10 ff 83 b5 [33 00 00]
uhidpp_intr: 10 ff 8f 83 [b5 03 00]
hidpp_send_report: 10 ff 83 b5 [34 00 00]
uhidpp_intr: 10 ff 8f 83 [b5 03 00]
hidpp_send_report: 10 ff 83 b5 [35 00 00]
uhidpp_intr: 10 ff 8f 83 [b5 03 00]
hidpp_send_report: 10 ff 80 00 [10 09 00]
uhidpp_intr: 10 ff 80 00 [00 00 00]


That's when the mouse was off. When I switched on the mouse kernel
panicked. I couldn't break into DDB or alternatively failed to type
correct commands blindly. Eventually had to shutdown the system by
pressing the power button. Picture of the panic is here:
https://imgur.com/a/QRAD5v1

Btw. Time has passed since my previous kernel compile. I saw the
procedure has changed a bit since then. I initially tried to compile
debug flags by prepending `option UHIDPP_DEBUG` to
sys/arch/amd64/compile/GENERIC.MP but couldn't see debug lines in
dmesg. By doing the "old way" I got the debug lines:
cd arch/amd64/conf
cp GENERIC.MP HIDPP.MP
# Add debug flags at this point
config HIDPP.MP
and compiling as usual. Is this the correct way to do it?

I'll do the Wireshark later in the evening.

--
Regards,
Ville





Re: uhidpp(4): logitech hid++ device driver

2021-01-29 Thread Ville Valkonen
,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x
2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSC
P,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP
,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB
,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
@@ -26,7 +26,7 @@ mtrr: Pentium Pro MTRR support, 10 var r
 cpu0: apic clock running at 99MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
 cpu1 at mainbus0: apid 2 (application processor)
-cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 MHz, 06-3d-04
+cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.23 MHz, 06-3d-04
 cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36
,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAI
T,DS-
CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x
2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSC
P,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP
,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB
,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 1, package 0
@@ -107,32 +107,29 @@ pms0: Synaptics clickpad, firmware 8.1,
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 vmm0 at mainbus0: VMX/EPT
-ugen0 at uhub0 port 7 "Intel Bluetooth" rev 2.01/0.01 addr 2
-uhub2 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching
Hub" rev 2.00/0.03 addr 2
-vscsi0 at root
-scsibus2 at vscsi0: 256 targets
-softraid0 at root
-scsibus3 at softraid0: 256 targets
-root on sd0a (c01774372c2b714a.a) swap on sd0b dump on sd0b
-inteldrm0: 1920x1080, 32bpp
-wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using
wskbd0
-wsdisplay0: screen 1-5 added (std, vt100 emulation)
-iwm0: hw rev 0x210, fw ver 17.3216344376.0, address 60:57:18:6a:df:8d
-uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB
Receiver" rev 2.00/12.10 addr 3
+uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB
Receiver" rev 2.00/12.10 addr 2
 uhidev0: iclass 3/1
 ukbd0 at uhidev0: 8 variable keys, 6 key codes
 wskbd1 at ukbd0 mux 1
-wskbd1: connecting to wsdisplay0
-uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB
Receiver" rev 2.00/12.10 addr 3
+uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB
Receiver" rev 2.00/12.10 addr 2
 uhidev1: iclass 3/1, 8 report ids
 ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir
 wsmouse2 at ums0 mux 0
 uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
 uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
 uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
-uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB
Receiver" rev 2.00/12.10 addr 3
+uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB
Receiver" rev 2.00/12.10 addr 2
 uhidev2: iclass 3/0, 33 report ids
-uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0
-uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0
-uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0
-uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0
+uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-xx-xx, device 2
keyboard "K750" serial xx-xx-xx-xx
+ugen0 at uhub0 port 7 "Intel Bluetooth" rev 2.01/0.01 addr 3
+uhub2 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching
Hub" rev 2.00/0.03 addr 2
+vscsi0 at root
+scsibus2 at vscsi0: 256 targets
+softraid0 at root
+scsibus3 at softraid0: 256 targets
+root on sd0a (c01774372c2b714a.a) swap on sd0b dump on sd0b
+inteldrm0: 1920x1080, 32bpp
+wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using
wskbd0
+wskbd1: connecting to wsdisplay0
+wsdisplay0: screen 1-5 added (std, vt100 emulation)
+iwm0: hw rev 0x210, fw ver 17.3216344376.0, address 60:57:18:6a:df:8d


--
Kind regards,
Ville

On Fri, 2021-01-29 at 19:23 +0200, Ville Valkonen wrote:
Hello Anton,

either I failed to use git or then files have changed since the first
patch:
$ git apply -p0 --check hid_plusplus.patch
error: patch failed: share/man/man4/Makefile:83
error: share/man/man4/Makefile: patch does not apply
error: patch failed: share/man/man4/uhidev.4:40
error: share/man/man4/uhidev.4: patch does not apply
error: patch failed: share/man/man4/usb.4:255
error: share/man/man4/usb.4: patch does not apply
error: patch failed: sys/arch/amd64/conf/GENERIC:288
error: sys/arch/amd64/conf/GENERIC: patch does not apply
error: patch failed: sys/dev/usb/uhidev.c:950
error: sys/dev/usb/uhidev.c: patch does not apply
error: sys/dev/usb/uhidpp.c: already exists in working directory

Running that on root of src. A quick peek on sys/dev/usb/uhidev.c file
shows that it has been modified on 25th of Jan so

Re: uhidpp(4): logitech hid++ device driver

2021-01-29 Thread Ville Valkonen
Hello Anton,

either I failed to use git or then files have changed since the first patch:
$ git apply -p0 --check hid_plusplus.patch
error: patch failed: share/man/man4/Makefile:83
error: share/man/man4/Makefile: patch does not apply
error: patch failed: share/man/man4/uhidev.4:40
error: share/man/man4/uhidev.4: patch does not apply
error: patch failed: share/man/man4/usb.4:255
error: share/man/man4/usb.4: patch does not apply
error: patch failed: sys/arch/amd64/conf/GENERIC:288
error: sys/arch/amd64/conf/GENERIC: patch does not apply
error: patch failed: sys/dev/usb/uhidev.c:950
error: sys/dev/usb/uhidev.c: patch does not apply
error: sys/dev/usb/uhidpp.c: already exists in working directory

Running that on root of src. A quick peek on sys/dev/usb/uhidev.c file
shows that it has been modified on 25th of Jan so I'd guess the patch
needs to be updated.

Thanks in advance! Been thinking to have a look on that protocol but
since I am no HW hacker I've postponed that for years :)

--
Kind regards,
Ville

On Fri, 29 Jan 2021 at 09:21, Anton Lindqvist  wrote:
>
> Ping
>
> On Fri, Jan 22, 2021 at 08:18:51AM +0100, Anton Lindqvist wrote:
> > Hi,
> > Here's a new driver for Logitech HID++ devices, currently limited to
> > exposing battery sensors. Here's an example using a Logitech M330 mouse:
> >
> >   $ dmesg | grep uhidpp
> >   uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33
> >   $ sysctl hw.sensors.uhidpp0
> >   hw.sensors.uhidpp0.raw0=2 (battery levels)
> >   hw.sensors.uhidpp0.percent0=70.00% (battery level), OK
> >
> > The raw0 sensor reflects number of available battery levels, the
> > resolution on this device is not great...
> >
> > Most of the code is derived from the hid-logitech-hidpp Linux driver.
> > Some assorted notes:
> >
> > * In order to communicate with the device inside the attach routine, I
> >   had to wire up the interrupt handler as this by default is done first
> >   once the same attach routine has returned. Hence the introduction of
> >   uhidev_set_intr(). If this is an acceptable approach, this can go in
> >   as a separate commit.
> >
> > * I kept using the `return -errno' convention from the Linux driver in
> >   order to distingush errors from the hardware, which are always
> >   positive.
> >
> > I you happen to have a Logitech HID++ device and run into any
> > problem(s), please enable UHIDPP_DEBUG and send me the output.
> >
> > Comments? OK?
> >
> > diff --git share/man/man4/Makefile share/man/man4/Makefile
> > index 02af7a47a44..74a4e17d7dc 100644
> > --- share/man/man4/Makefile
> > +++ share/man/man4/Makefile
> > @@ -83,8 +83,8 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \
> >   txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \
> >   ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \
> >   udav.4 udcf.4 udl.4 udp.4 udsbr.4 \
> > - uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \
> > - uk.4 ukbd.4 \
> > + uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \
> > + uipaq.4 uk.4 ukbd.4 \
> >   ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \
> >   ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \
> >   uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \
> > diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4
> > index f0a6776a27b..d264935a65c 100644
> > --- share/man/man4/uhidev.4
> > +++ share/man/man4/uhidev.4
> > @@ -40,6 +40,7 @@
> >  .Cd "ucycom*  at uhidev?"
> >  .Cd "ugold*   at uhidev?"
> >  .Cd "uhid*at uhidev?"
> > +.Cd "uhidpp*  at uhidev?"
> >  .Cd "ukbd*at uhidev?"
> >  .Cd "ums* at uhidev?"
> >  .Cd "umstc*   at uhidev?"
> > @@ -73,6 +74,7 @@ only dispatches data to them based on the report id.
> >  .Xr ucycom 4 ,
> >  .Xr ugold 4 ,
> >  .Xr uhid 4 ,
> > +.Xr uhidpp 4 ,
> >  .Xr ukbd 4 ,
> >  .Xr ums 4 ,
> >  .Xr umstc 4 ,
> > diff --git share/man/man4/uhidpp.4 share/man/man4/uhidpp.4
> > new file mode 100644
> > index 000..4c78380c35b
> > --- /dev/null
> > +++ share/man/man4/uhidpp.4
> > @@ -0,0 +1,48 @@
> > +.\"  $OpenBSD$
> > +.\"
> > +.\" Copyright (c) 2021 Anton Lindqvsit 
> > +.\"
> > +.\" Permission to use, copy, modify, and distribute this software for any
> > +.\" purpose with or without fee is hereby granted, provided that the above
> > +.\" copyright notice and this permission notice appear in all copies.
> > +.\"
> > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL 
> > WARRANTIES
> > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > +.\" OR IN CONNECTION 

[PATCH] Extra lines in ssh-pkcs11-client.c file

2019-11-18 Thread Ville Valkonen
Hello,

if I didn't overlook the function, there's extra lines in there.
Please see the patch below.


diff --git usr.bin/ssh/ssh-pkcs11-client.c usr.bin/ssh/ssh-pkcs11-client.c
index 20284d98ecf..44065df1a96 100644
--- usr.bin/ssh/ssh-pkcs11-client.c
+++ usr.bin/ssh/ssh-pkcs11-client.c
@@ -230,9 +230,6 @@ wrap_key(struct sshkey *k)
 static int
 pkcs11_start_helper_methods(void)
 {
-if (helper_ecdsa != NULL)
-return (0);
-
 int (*orig_sign)(int, const unsigned char *, int, unsigned char *,
 unsigned int *, const BIGNUM *, const BIGNUM *, EC_KEY *) = NULL;
 if (helper_ecdsa != NULL)


--
Kind regards,
Ville Valkonen



Re: iwm(4) WPA2 crypto hardware offload

2019-08-03 Thread Ville Valkonen
Forgot to mention this was on Intel Dual Band Wireless AC 7265" rev 0x59

On Fri, 2 Aug 2019 at 21:52, Ville Valkonen  wrote:
>
> On Fri, 2 Aug 2019 at 14:18, Stefan Sperling  wrote:
> >
> > This diff enables HW offload for WPA2 CCMP (AES) encrypted unicast
> > frames in iwm(4). This is in preparation for Tx aggregation support.
> >
> > WEP and WPA1/TKIP ciphers are still handled in software, which mirrors
> > what the older iwn(4) driver is doing. We don't enable 11n at all with
> > those ciphers (see ieee80211_ht_negotiate()), and we won't aggregate
> > non-encrypted frames (see ieee80211_can_use_ampdu()).
> >
> > Based on an initial diff by procter@ and some code from iwn(4).
> >
> > Tested on 7260, 7265, 8260, and 8265 in bsd.rd upgrade and with pkg_add -u.
> >
> > ok?
> >
> > diff refs/heads/master refs/heads/iwm-hwcrypt
> > blob - 7add1e9e682ef5e22169ec1e89a182cda1af7e2a
> > blob + 839c0a0f8b3a62115ba6d5e15adfa63158475c86
> > --- sys/dev/pci/if_iwm.c
> > +++ sys/dev/pci/if_iwm.c
> > @@ -367,6 +367,8 @@ int iwm_get_signal_strength(struct iwm_softc *, struct
> >  void   iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *,
> > struct iwm_rx_data *);
> >  intiwm_get_noise(const struct iwm_statistics_rx_non_phy *);
> > +intiwm_ccmp_decap(struct iwm_softc *, struct mbuf *,
> > +   struct ieee80211_node *);
> >  void   iwm_rx_rx_mpdu(struct iwm_softc *, struct iwm_rx_packet *,
> > struct iwm_rx_data *);
> >  void   iwm_enable_ht_cck_fallback(struct iwm_softc *, struct iwm_node *);
> > @@ -448,6 +450,10 @@ intiwm_disassoc(struct iwm_softc *);
> >  intiwm_run(struct iwm_softc *);
> >  intiwm_run_stop(struct iwm_softc *);
> >  struct ieee80211_node *iwm_node_alloc(struct ieee80211com *);
> > +intiwm_set_key(struct ieee80211com *, struct ieee80211_node *,
> > +   struct ieee80211_key *);
> > +void   iwm_delete_key(struct ieee80211com *,
> > +   struct ieee80211_node *, struct ieee80211_key *);
> >  void   iwm_calib_timeout(void *);
> >  intiwm_media_change(struct ifnet *);
> >  void   iwm_newstate_task(void *);
> > @@ -3429,11 +3435,91 @@ iwm_get_noise(const struct 
> > iwm_statistics_rx_non_phy *
> > return (nbant == 0) ? -127 : (total / nbant) - 107;
> >  }
> >
> > +int
> > +iwm_ccmp_decap(struct iwm_softc *sc, struct mbuf *m, struct ieee80211_node 
> > *ni)
> > +{
> > +   struct ieee80211com *ic = >sc_ic;
> > +   struct ieee80211_key *k = >ni_pairwise_key;
> > +   struct ieee80211_frame *wh;
> > +   struct ieee80211_rx_ba *ba;
> > +   uint64_t pn, *prsc;
> > +   uint8_t *ivp;
> > +   uint8_t tid;
> > +   int hdrlen, hasqos;
> > +
> > +   wh = mtod(m, struct ieee80211_frame *);
> > +   hdrlen = ieee80211_get_hdrlen(wh);
> > +   ivp = (uint8_t *)wh + hdrlen;
> > +
> > +   /* Check that ExtIV bit is be set. */
> > +   if (!(ivp[3] & IEEE80211_WEP_EXTIV)) {
> > +   DPRINTF(("CCMP decap ExtIV not set\n"));
> > +   return 1;
> > +   }
> > +   hasqos = ieee80211_has_qos(wh);
> > +   tid = hasqos ? ieee80211_get_qos(wh) & IEEE80211_QOS_TID : 0;
> > +   ba = hasqos ? >ni_rx_ba[tid] : NULL;
> > +   prsc = >k_rsc[tid];
> > +
> > +   /* Extract the 48-bit PN from the CCMP header. */
> > +   pn = (uint64_t)ivp[0]   |
> > +(uint64_t)ivp[1] <<  8 |
> > +(uint64_t)ivp[4] << 16 |
> > +(uint64_t)ivp[5] << 24 |
> > +(uint64_t)ivp[6] << 32 |
> > +(uint64_t)ivp[7] << 40;
> > +   if (pn <= *prsc) {
> > +   if (hasqos && ba->ba_state == IEEE80211_BA_AGREED) {
> > +   /*
> > +* This is an A-MPDU subframe.
> > +* Such frames may be received out of order due to
> > +* legitimate retransmissions of failed subframes
> > +* in previous A-MPDUs. Duplicates will be handled
> > +* in ieee80211_input() as part of A-MPDU 
> > reordering.
> > +*/
> > +   } else if (ieee80211_has_seq(wh)) {
> > +   /*
> > +* Not necessarily a replayed frame since we did not
> > +* check the sequ

Re: iwm(4) WPA2 crypto hardware offload

2019-08-02 Thread Ville Valkonen
On Fri, 2 Aug 2019 at 14:18, Stefan Sperling  wrote:
>
> This diff enables HW offload for WPA2 CCMP (AES) encrypted unicast
> frames in iwm(4). This is in preparation for Tx aggregation support.
>
> WEP and WPA1/TKIP ciphers are still handled in software, which mirrors
> what the older iwn(4) driver is doing. We don't enable 11n at all with
> those ciphers (see ieee80211_ht_negotiate()), and we won't aggregate
> non-encrypted frames (see ieee80211_can_use_ampdu()).
>
> Based on an initial diff by procter@ and some code from iwn(4).
>
> Tested on 7260, 7265, 8260, and 8265 in bsd.rd upgrade and with pkg_add -u.
>
> ok?
>
> diff refs/heads/master refs/heads/iwm-hwcrypt
> blob - 7add1e9e682ef5e22169ec1e89a182cda1af7e2a
> blob + 839c0a0f8b3a62115ba6d5e15adfa63158475c86
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -367,6 +367,8 @@ int iwm_get_signal_strength(struct iwm_softc *, struct
>  void   iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *,
> struct iwm_rx_data *);
>  intiwm_get_noise(const struct iwm_statistics_rx_non_phy *);
> +intiwm_ccmp_decap(struct iwm_softc *, struct mbuf *,
> +   struct ieee80211_node *);
>  void   iwm_rx_rx_mpdu(struct iwm_softc *, struct iwm_rx_packet *,
> struct iwm_rx_data *);
>  void   iwm_enable_ht_cck_fallback(struct iwm_softc *, struct iwm_node *);
> @@ -448,6 +450,10 @@ intiwm_disassoc(struct iwm_softc *);
>  intiwm_run(struct iwm_softc *);
>  intiwm_run_stop(struct iwm_softc *);
>  struct ieee80211_node *iwm_node_alloc(struct ieee80211com *);
> +intiwm_set_key(struct ieee80211com *, struct ieee80211_node *,
> +   struct ieee80211_key *);
> +void   iwm_delete_key(struct ieee80211com *,
> +   struct ieee80211_node *, struct ieee80211_key *);
>  void   iwm_calib_timeout(void *);
>  intiwm_media_change(struct ifnet *);
>  void   iwm_newstate_task(void *);
> @@ -3429,11 +3435,91 @@ iwm_get_noise(const struct iwm_statistics_rx_non_phy *
> return (nbant == 0) ? -127 : (total / nbant) - 107;
>  }
>
> +int
> +iwm_ccmp_decap(struct iwm_softc *sc, struct mbuf *m, struct ieee80211_node 
> *ni)
> +{
> +   struct ieee80211com *ic = >sc_ic;
> +   struct ieee80211_key *k = >ni_pairwise_key;
> +   struct ieee80211_frame *wh;
> +   struct ieee80211_rx_ba *ba;
> +   uint64_t pn, *prsc;
> +   uint8_t *ivp;
> +   uint8_t tid;
> +   int hdrlen, hasqos;
> +
> +   wh = mtod(m, struct ieee80211_frame *);
> +   hdrlen = ieee80211_get_hdrlen(wh);
> +   ivp = (uint8_t *)wh + hdrlen;
> +
> +   /* Check that ExtIV bit is be set. */
> +   if (!(ivp[3] & IEEE80211_WEP_EXTIV)) {
> +   DPRINTF(("CCMP decap ExtIV not set\n"));
> +   return 1;
> +   }
> +   hasqos = ieee80211_has_qos(wh);
> +   tid = hasqos ? ieee80211_get_qos(wh) & IEEE80211_QOS_TID : 0;
> +   ba = hasqos ? >ni_rx_ba[tid] : NULL;
> +   prsc = >k_rsc[tid];
> +
> +   /* Extract the 48-bit PN from the CCMP header. */
> +   pn = (uint64_t)ivp[0]   |
> +(uint64_t)ivp[1] <<  8 |
> +(uint64_t)ivp[4] << 16 |
> +(uint64_t)ivp[5] << 24 |
> +(uint64_t)ivp[6] << 32 |
> +(uint64_t)ivp[7] << 40;
> +   if (pn <= *prsc) {
> +   if (hasqos && ba->ba_state == IEEE80211_BA_AGREED) {
> +   /*
> +* This is an A-MPDU subframe.
> +* Such frames may be received out of order due to
> +* legitimate retransmissions of failed subframes
> +* in previous A-MPDUs. Duplicates will be handled
> +* in ieee80211_input() as part of A-MPDU reordering.
> +*/
> +   } else if (ieee80211_has_seq(wh)) {
> +   /*
> +* Not necessarily a replayed frame since we did not
> +* check the sequence number of the 802.11 header yet.
> +*/
> +   int nrxseq, orxseq;
> +
> +   nrxseq = letoh16(*(u_int16_t *)wh->i_seq) >>
> +   IEEE80211_SEQ_SEQ_SHIFT;
> +   if (hasqos)
> +   orxseq = ni->ni_qos_rxseqs[tid];
> +   else
> +   orxseq = ni->ni_rxseq;
> +   if (nrxseq < orxseq) {
> +   DPRINTF(("CCMP replayed (n=%d < o=%d)\n",
> +   nrxseq, orxseq));
> +   ic->ic_stats.is_ccmp_replays++;
> +   return 1;
> +   }
> +   } else {
> +   DPRINTF(("CCMP replayed\n"));
> +   ic->ic_stats.is_ccmp_replays++;
> +   return 1;
> +   }
> +   }
> +   /* Update 

[PATCH] Parallelize sysupgrade downloads

2019-05-07 Thread Ville Valkonen
Hello,

thanks for the great new tool, sysupgrade. Works like a charm.

While on it, I came with this patch to speed up the downloading.
It uses xargs -P to parallelize downloads (max 6, chosen from top of my head).

Also, removed trailing spaces in two lines.

Without parallel patch:
4m20.91s real 0m00.44s user 0m24.26s system
With parallel patch:
3m14.14s real 0m00.32s user 0m13.80s system


diff --git usr.sbin/sysupgrade/sysupgrade.sh usr.sbin/sysupgrade/sysupgrade.sh
index 87de9ccf432..635b48186f5 100644
--- usr.sbin/sysupgrade/sysupgrade.sh
+++ usr.sbin/sysupgrade/sysupgrade.sh
@@ -44,7 +44,7 @@ unpriv()
 _file=$2
 shift 2
 fi
- if [[ -n ${_file} ]]; then
+if [[ -n ${_file} ]]; then
 >${_file}
 chown "${_user}" "${_file}"
 fi
@@ -69,6 +69,16 @@ rmel() {
 echo -n "$_c"
 }

+generate_urls()
+{
+OFS=$IFS
+IFS=$'\n'
+printf "${2}\n" | while read -r f; do
+printf "%s%s\n" "${1}" "${f}"
+done
+IFS=$OFS
+}
+
 RELEASE=false
 SNAP=false
 FORCE=false
@@ -122,7 +132,7 @@ if [[ -e ${SETSDIR} ]]; then
  ug_err "${SETSDIR} needs to be owned by root:wheel"
 [[ $st_gid -eq 0 ]] ||
  ug_err "${SETSDIR} needs to be owned by root:wheel"
-[[ $st_mode -eq 040755 ]] ||
+[[ $st_mode -eq 040755 ]] ||
 ug_err "${SETSDIR} is not a directory with permissions 0755"
 else
 mkdir -p ${SETSDIR}
@@ -167,9 +177,13 @@ for f in $SETS; do
 done

 [[ -n ${OLD_FILES} ]] && rm ${OLD_FILES}
+cd ${SETSDIR}
+generate_urls $URL "$(echo ${DL} |tr ' ' '\n')" \
+| xargs -P 6 -n 1 ftp -VCm
 for f in ${DL}; do
-unpriv -f $f ftp -Vmo ${f} ${URL}${f}
+unpriv -f $f
 done
+cd -

 echo Verifying sets.
 [[ -n ${DL} ]] && unpriv cksum -qC SHA256 ${DL}


--
Kind regards,
Ville Valkonen



Ext4 and suspend

2019-03-18 Thread Ville Valkonen
Hello,

just a hint for those who are having ext4 partitions mounted: that
will prohibit suspend to work.

Pardon for my unscientific claim, but If I'm not correctly mistaken
this was related to changes that made syncing disks faster in halting.
For a long time I thought that also was affecting ext2 partitions too
but a few weeks ago I was happy to find out that it only affects ext4
partitions, even in readonly mode.

Wanted to share my findings since there might be someone else
pondering why the suspend doesn't work. Unmount the ext4 for good and
be happy.

--
Kind regards,
Ville



[PATCH] Double free in ldapclient.c

2019-01-26 Thread Ville Valkonen
Hello,

a pointer p is freed twice in ldapclient.c.

diff --git usr.bin/ldap/ldapclient.c usr.bin/ldap/ldapclient.c
index 02b15e0669b..336b9430325 100644
--- usr.bin/ldap/ldapclient.c
+++ usr.bin/ldap/ldapclient.c
@@ -477,7 +477,6 @@ ldapc_printattr(struct ldapc *ldap, const char *key,
 }

 printf("%s: %s\n", key, p);
-free(p);
 }

 free(p);

--
Kind regards,
Ville Valkonen



[PATCH] Remove an obsolete function tty_cmd_linefeed in tmux

2019-01-26 Thread Ville Valkonen
Hello,

this patch removes an obsolete tty_cmd_linefeed function in tmux.

It seems tty_cmd_linefeed function was used last time in:
Author: nicm 
Date:   Wed Feb 8 17:31:09 2017 +

Add support for scroll up escape sequence (CSI S) and use it when
possible instead of sending individual line feeds.

Namely here (filtered with grep -C3):

screen_write_collect_scroll(ctx);
-   screen_write_initctx(ctx, );
-   tty_write(tty_cmd_linefeed, );
+   ctx->scrolled++;


Grepping the tmux directory with tty_cmd_linefeed reveals two hits, one in
tmux.h and an another in tty.c which implements that.
Both are addressed in the following patch.

diff --git tmux.h tmux.h
index 6d901cecc72..44ed64d13f0 100644
--- tmux.h
+++ tmux.h
@@ -1734,7 +1734,6 @@ voidtty_cmd_deleteline(struct tty *, const
struct tty_ctx *);
 voidtty_cmd_erasecharacter(struct tty *, const struct tty_ctx *);
 voidtty_cmd_insertcharacter(struct tty *, const struct tty_ctx *);
 voidtty_cmd_insertline(struct tty *, const struct tty_ctx *);
-voidtty_cmd_linefeed(struct tty *, const struct tty_ctx *);
 voidtty_cmd_scrollup(struct tty *, const struct tty_ctx *);
 voidtty_cmd_reverseindex(struct tty *, const struct tty_ctx *);
 voidtty_cmd_setselection(struct tty *, const struct tty_ctx *);
diff --git tty.c tty.c
index 75ba0e1dec8..75b390a2c0f 100644
--- tty.c
+++ tty.c
@@ -1553,47 +1553,6 @@ tty_cmd_reverseindex(struct tty *tty, const
struct tty_ctx *ctx)
 tty_putcode(tty, TTYC_RI);
 }

-void
-tty_cmd_linefeed(struct tty *tty, const struct tty_ctx *ctx)
-{
-struct window_pane*wp = ctx->wp;
-
-if (ctx->ocy != ctx->orlower)
-return;
-
-if (ctx->bigger ||
-(!tty_pane_full_width(tty, ctx) && !tty_use_margin(tty)) ||
-tty_fake_bce(tty, wp, 8) ||
-!tty_term_has(tty->term, TTYC_CSR) ||
-wp->sx == 1 ||
-wp->sy == 1) {
-tty_redraw_region(tty, ctx);
-return;
-}
-
-tty_default_attributes(tty, wp, ctx->bg);
-
-tty_region_pane(tty, ctx, ctx->orupper, ctx->orlower);
-tty_margin_pane(tty, ctx);
-
-/*
- * If we want to wrap a pane while using margins, the cursor needs to
- * be exactly on the right of the region. If the cursor is entirely off
- * the edge - move it back to the right. Some terminals are funny about
- * this and insert extra spaces, so only use the right if margins are
- * enabled.
- */
-if (ctx->xoff + ctx->ocx > tty->rright) {
-if (!tty_use_margin(tty))
-tty_cursor(tty, 0, ctx->yoff + ctx->ocy);
-else
-tty_cursor(tty, tty->rright, ctx->yoff + ctx->ocy);
-} else
-tty_cursor_pane(tty, ctx, ctx->ocx, ctx->ocy);
-
-tty_putc(tty, '\n');
-}
-
 void
 tty_cmd_scrollup(struct tty *tty, const struct tty_ctx *ctx)
 {

--
Kind regards,
Ville Valkonen



Re: new USB audio class v2.0 driver

2019-01-02 Thread Ville Valkonen
t; rev 0x03
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbdprobe: reset response 0xfe
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
wsmouse1 at pms0 mux 0
pms0: Synaptics clickpad, firmware 8.1, 0x1e2b1 0x943300
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
Unclaimed register detected before reading register 0x23a0
uhub1 at uhub0 port 1 configuration 1 interface 0 "Intel Rate Matching Hub"
rev 2.00/0.03 addr 2
ugen0 at uhub1 port 7 "Intel Bluetooth" rev 2.01/0.01 addr 3
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (ce822de83a7969c0.a) swap on sd0b dump on sd0b
iwm0: hw rev 0x210, fw ver 16.242414.0, address 60:57:18:6a:df:8d
uaudio0 at uhub1 port 2 configuration 1 interface 1 "Cambridge Audio
Cambridge Audio USB Audio 2.0" rev 2.00/3.26 addr 4
uaudio0: class v2, high-speed, async, channels: 2 play, 0 rec, 0 ctls
audio1 at uaudio0
ugen1 at uhub1 port 2 configuration 1 "Cambridge Audio Cambridge Audio USB
Audio 2.0" rev 2.00/3.26 addr 4
uaudio0: request failed: TIMEOUT
uaudio0: failed to set clock rate
audio1: failed to start playback
uaudio0: request failed: TIMEOUT
uaudio0: failed to set clock rate
audio1: failed to start playback

--
Regards,
Ville Valkonen


Add Sparkfun ATtiny programmer in to usbdevs

2017-10-24 Thread Ville Valkonen
Hi,

as the topic states.

On Linux lsusb's iProduct shows:
  iProduct2 FabISP
And on OpenBSD:
  iProduct2 (error)

So in that sense the naming might be a bit off.

Adding the lines below in to uftdi.c doesn't make it work yet, so more
love is needed:

RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.75
diff -u -p -r1.75 uftdi.c
--- uftdi.c12 Dec 2016 04:35:04 -1.75
+++ uftdi.c23 Oct 2017 19:38:37 -
@@ -635,6 +635,7 @@ static const struct usb_devno uftdi_devs
 { USB_VENDOR_MATRIXORB, USB_PRODUCT_MATRIXORB_LCD_01FE },
 { USB_VENDOR_MATRIXORB, USB_PRODUCT_MATRIXORB_LCD_01FF },
 { USB_VENDOR_MECANIQUE, USB_PRODUCT_MECANIQUE_TELLSTICK },
+{ USB_VENDOR_MECANIQUE, USB_PRODUCT_MECANIQUE_AVRPROGRAMMER },
 { USB_VENDOR_MELCO, USB_PRODUCT_MELCO_PCOPRS1 },
 { USB_VENDOR_MOBILITY, USB_PRODUCT_MOBILITY_ED200H },
 { USB_VENDOR_OCT, USB_PRODUCT_OCT_US2308 },


And when the device is attached:

uftdi0 at uhub0 port 1 configuration 1 interface 0 "Mecanique Sparkfun
Tiny AVR programmer" rev 1.10/1.04 addr 2
uftdi0: Could not find data bulk in


Anyway, here's the usbdevs part:

Index: usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.684
diff -u -p -r1.684 usbdevs_data.h
--- usbdevs_data.h11 Oct 2017 17:20:36 -1.684
+++ usbdevs_data.h24 Oct 2017 17:26:22 -
@@ -1,4 +1,4 @@
-/*$OpenBSD: usbdevs_data.h,v 1.684 2017/10/11 17:20:36 patrick Exp $*/
+/*$OpenBSD$*/

 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -7088,6 +7088,10 @@ const struct usb_known_product usb_known
 {
 USB_VENDOR_MECANIQUE, USB_PRODUCT_MECANIQUE_TELLSTICK,
 "Telldus Tellstick",
+},
+{
+USB_VENDOR_MECANIQUE, USB_PRODUCT_MECANIQUE_AVRPROGRAMMER,
+"Sparkfun Tiny AVR programmer",
 },
 {
 USB_VENDOR_METAGEEK, USB_PRODUCT_METAGEEK_WISPY24I,
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.678
diff -u -p -r1.678 usbdevs
--- usbdevs11 Oct 2017 17:19:50 -1.678
+++ usbdevs24 Oct 2017 17:26:22 -
@@ -2944,6 +2944,7 @@ product MELCO WLIUCGNM20x01eeWLI-UC-G
 /* MetaGeek tagged products */
 product MECANIQUE WISPY0x083eMetaGeek Wi-Spy
 product MECANIQUE TELLSTICK0x0c30Telldus Tellstick
+product MECANIQUE AVRPROGRAMMER0x0c9fSparkfun Tiny AVR programmer

 /* MetaGeek products */
 product METAGEEK WISPY24I0x2400Wi-Spy 2.4i


--
Kind regards,
Ville Valkonen



Re: snapshot installs

2016-12-30 Thread Ville Valkonen
On Dec 30, 2016 20:32, "Theo de Raadt"  wrote:

I'm wondering if anyone doing an install/upgrade has noticed any
behaviour changes in the last week...

There's a secret diff being tested :-)


Hello,

so far I haven't noticed anything peculiar. Two or three distinct machines,
two for surfing and one acting as a server.

Obviously quite well hidden and secret diff :)

--
Regards,
Ville


Re: Firefox, malloc(3) and threads

2016-01-24 Thread Ville Valkonen
On 24 January 2016 at 20:47, Adam Wolk <adam.w...@tintagel.pl> wrote:
> On Fri, 22 Jan 2016 22:46:39 +0100 (CET)
> Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>
>> Firefox makes a lot of concurrent malloc(3) calls.  The locking to
>> make malloc(3) thread-safe is a bit...suboptimal.  This diff makes
>> things better by using a mutex instead of spinlock.  If you're running
>> Firefox you want to try it; it makes video watchable on some machines.
>> If you're not running Firefox you want to try it; to make sure it
>> doesn't break things.
>>
>> Enjoy,
>>
>> Mark
>>  '
>
> Applied to a Jan 15h snapshot sources. Youtube is not fully 'watchable'
> on firefox but feels significantly better. I can also now watch full
> screen youtube videos on chromium 1920x1080 with no stutter (lenovo
> g50-70).
>
> Generally gnome 3 feels a bit snappier especially on first load,
> bringing up the menu searching for 'terminal' leads to a faster
> rendering of the results. This might be just 'imagined' by me.
>
> On a more measurable front. I ran the octane benchmark against firefox
> post and before the patch. It resulted in a slight improvement from
> 12486 to 12826 score [1].
>
> cpu0: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 1895.93 MHz
> cpu1: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 1895.62 MHz
> cpu2: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 1895.62 MHz
> cpu3: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 1895.62 MHz
> inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x0b
> running Intel Haswell Mobile for the gfx card.
>
> Regards,
> Adam
>
> [1] - https://twitter.com/mulander/status/691327370985345024


Hi,

pretty much the same results here, though running Lenovo X250 with i7-5600U.

Dankuwel Mark, nice finding.

--
Regards,
Ville Valkonen



[PATCH] Missing break in audio.c

2016-01-13 Thread Ville Valkonen
Hello,

looks like there's a missing break in audio.c, since error gets assigned
twice and not read in between.

--- sys/dev/audio.c.oldWed Jan 13 17:55:32 2016
+++ sys/dev/audio.cWed Jan 13 17:55:48 2016
@@ -1704,6 +1704,7 @@ audioclose(dev_t dev, int flags, int ifmt, struct proc
 case AUDIO_DEV_MIXER:
 case AUDIO_DEV_AUDIOCTL:
 error = 0;
+break;
 default:
 error = ENXIO;
 }

--
Kind regards,
Ville Valkonen
--- sys/dev/audio.c.old	Wed Jan 13 17:55:32 2016
+++ sys/dev/audio.c	Wed Jan 13 17:55:48 2016
@@ -1704,6 +1704,7 @@ audioclose(dev_t dev, int flags, int ifmt, struct proc
 	case AUDIO_DEV_MIXER:
 	case AUDIO_DEV_AUDIOCTL:
 		error = 0;
+		break;
 	default:
 		error = ENXIO;
 	}


[PATCH] unsignedness comparison in brconfig.c

2016-01-13 Thread Ville Valkonen
Hello,

no need to check if unsigned value is smaller than zero. Please see the
attached patch.

Gmail likely mangles the inlined patch but here it goes:
--- brconfig.c.oldWed Jan 13 16:35:39 2016
+++ brconfig.cWed Jan 13 16:36:26 2016
@@ -563,7 +563,7 @@ bridge_ifcost(const char *ifname, const char *val)
 errno = 0;
 v = strtoul(val, , 0);
 if (val[0] == '\0' || endptr[0] != '\0' ||
-v < 0 || v > 0xUL ||
+v > 0xUL ||
 (errno == ERANGE && v == ULONG_MAX))
 errx(1, "invalid arg for ifcost: %s", val);


--
Regards,
Ville Valkonen
--- brconfig.c.old	Wed Jan 13 16:35:39 2016
+++ brconfig.c	Wed Jan 13 16:36:26 2016
@@ -563,7 +563,7 @@ bridge_ifcost(const char *ifname, const char *val)
 	errno = 0;
 	v = strtoul(val, , 0);
 	if (val[0] == '\0' || endptr[0] != '\0' ||
-	v < 0 || v > 0xUL ||
+	v > 0xUL ||
 	(errno == ERANGE && v == ULONG_MAX))
 		errx(1, "invalid arg for ifcost: %s", val);
 


Re: patch 1/4 add generic keyboard backlight support

2015-12-11 Thread Ville Valkonen
On 11 December 2015 at 10:36, Joerg Jung <m...@umaxx.net> wrote:

> Ping. Anyone?
>
> > On 07 Dec 2015, at 23:39, Joerg Jung <m...@umaxx.net> wrote:
> >
> > Hi,
> >
> > here comes a series of small diffs which add generic support for
> > keyboard backlights.
> >
> > Please find below the first diff, which adds new ioctls to wskbd(4) to
> > control keyboard backlights.
> >
> > In contrast to an earlier diff from jcs, I have chosen to use a struct
> > in favor of a simple (unsigned) int as depending on the vendor
> > (Thinkpad, Apple, ...) different min/max values for the brightness of
> > the keyboard backlight are possible.
> >
> > Comments, OK?
> >
> > Thanks,
> > Regards,
> > Joerg
> >
> >
> >
> > Index: wsconsio.h
> > ===
> > RCS file: /cvs/src/sys/dev/wscons/wsconsio.h,v
> > retrieving revision 1.72
> > diff -u -p -r1.72 wsconsio.h
> > --- wsconsio.h30 Aug 2015 10:05:09 -  1.72
> > +++ wsconsio.h7 Dec 2015 21:03:45 -
> > @@ -180,6 +180,13 @@ struct wskbd_map_data {
> > #define WSKBDIO_GETENCODING   _IOR('W', 15, kbd_t)
> > #define WSKBDIO_SETENCODING   _IOW('W', 16, kbd_t)
> >
> > +/* Get/set keyboard backlight.  Not applicable to all keyboard types. */
> > +struct wskbd_backlight {
> > + unsigned int min, max, curval;
> > +};
> > +#define  WSKBDIO_GETBACKLIGHT_IOR('W', 17, struct
> wskbd_backlight)
> > +#define  WSKBDIO_SETBACKLIGHT_IOW('W', 18, struct
> wskbd_backlight)
> > +
> > /* internal use only */
> > #define WSKBDIO_SETMODE   _IOW('W', 19, int)
> > #define WSKBDIO_GETMODE   _IOR('W', 20, int)
> > Index: wskbd.c
> > ===
> > RCS file: /cvs/src/sys/dev/wscons/wskbd.c,v
> > retrieving revision 1.82
> > diff -u -p -r1.82 wskbd.c
> > --- wskbd.c   10 Sep 2015 18:14:52 -  1.82
> > +++ wskbd.c   7 Dec 2015 21:03:45 -
> > @@ -230,6 +230,9 @@ int   wskbd_mux_close(struct wsevsrc *);
> > int   wskbd_do_open(struct wskbd_softc *, struct wseventvar *);
> > int   wskbd_do_ioctl(struct device *, u_long, caddr_t, int, struct proc
> *);
> >
> > +int  (*wskbd_get_backlight)(struct wskbd_backlight *);
> > +int  (*wskbd_set_backlight)(struct wskbd_backlight *);
> > +
> > struct cfdriver wskbd_cd = {
> >   NULL, "wskbd", DV_TTY
> > };
> > @@ -1010,6 +1013,7 @@ wskbd_displayioctl(struct device *dev, u
> >   case WSKBDIO_SETDEFAULTKEYREPEAT:
> >   case WSKBDIO_SETMAP:
> >   case WSKBDIO_SETENCODING:
> > + case WSKBDIO_SETBACKLIGHT:
> >   if ((flag & FWRITE) == 0)
> >   return (EACCES);
> >   }
> > @@ -1155,6 +1159,18 @@ getkeyrepeat:
> >   wsmux_set_layout(sc->sc_base.me_parent, enc);
> > #endif
> >   return (0);
> > +
> > + case WSKBDIO_GETBACKLIGHT:
> > + if (wskbd_get_backlight != NULL)
> > + return (*wskbd_get_backlight)((struct
> wskbd_backlight *)data);
> > +     error = ENOTTY;
> > + break;
> > +
> > + case WSKBDIO_SETBACKLIGHT:
> > + if (wskbd_set_backlight != NULL)
> > + return (*wskbd_set_backlight)((struct
> wskbd_backlight *)data);
> > + error = ENOTTY;
> > + break;
> >   }
> >
> >   /*
> >
>

Hello Joerg,

not sure if this diff has been applied in the snapshots but lately
brightness keys started to work on Lenovo X250. Could be completely
unrelated, though.

--
Regards,
Ville Valkonen


Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-08 Thread Ville Valkonen
Hello Maxime,

On Aug 7, 2015 10:56 PM, Maxime Villard m...@m00nbsd.net wrote:

 Well, I guess I'll have to admit that I find your attitude extremely
 disrespectful. But I don't tend to feel particularly offended by this
 kind of things, so it probably does not matter.



 Le 21/07/2015 12:31, sam a écrit :

 On Tue, 21 Jul 2015 11:31:44 +0200
 Maxime Villard m...@m00nbsd.net wrote:

 Found by The Brainy Code Scanner.

 It is not the last bug Brainy has found, but it is the last one I
 report. I don't have time for that.


 How about you release the Brainy Code Scanner then?

 I have so many bugs; in fact, there are so many, I don't even have the
 time to report them! My scanner is so good!

 Or perhaps you should report 'just' the relatively important ones?


 I think my work does (or used to) benefit to a lot of users, developers
 and vendors here; a lot of people, including you.

 Nobody supports my work, and I've never asked for anything here about
 that. Even though I almost never receive a simple thank you for all
 the bugs and vulnerabilities I've so far reported, I still expect a
 spiritual thank you for my work.

 But I certainly do not expect that kind of emails you just sent, somehow
 trying to either make fun of me or disregard what I'm willing to spend
 my spare time on for you.

 Developing, improving and maintaining Brainy takes time and energy, as
 well as investigating and packaging the bugs and vulnerabilities it
 finds. I've so far sent some reports here just because I'm friendly
 enough, and because modifying a few things for Brainy to properly
 understand the OpenBSD code does not require a Herculean work.

 Now, I believe that this effort is too much for my spare time. If you
 want to say thanks to me for reporting this vulnerability, dear Sam,
 it's never too late.

 Maxime

here's my sincerest and humblest appreciation towards you: thanks!

And I'm glad you've spend time to study and report the issues.

--
Regards,
Ville


Re: OpenBSD::Tame perl wrapper for tame(2)

2015-07-21 Thread Ville Valkonen
On Jul 21, 2015 11:21 PM, li...@wrant.com wrote:

  Wrant..  Go away.

 On my way out can I gently kick the usual ruby wrapper to death?
 Several times. I'd come for more.

  Your attitude is offensive  to all of us who work on this project.

 Why is open speech offensive, we're not that old already?

Your contributions to the lists are rants or useless noise. What's your
motivation and do you really gain something by doing that?

--
Regards,
Ville


Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-07-21 Thread Ville Valkonen
On Jul 21, 2015 9:32 AM, Maxime Villard m...@m00nbsd.net wrote:

 Hi,
 I put here a bug among others:

 - sys/kern/kern_exec.c -

 char *pathbuf = NULL;

 [...]

 pathbuf = pool_get(namei_pool, PR_WAITOK);

 [...]

 /* setup new registers and do misc. setup. */
 if (pack.ep_emul-e_fixup != NULL) {
 if ((*pack.ep_emul-e_fixup)(p, pack) != 0)
 goto free_pack_abort;
 }

 [...]

 free_pack_abort:
 free(pack.ep_hdr, M_EXEC, 0);
 exit1(p, W_EXITCODE(0, SIGABRT), EXIT_NORMAL);

 /* NOTREACHED */
 atomic_clearbits_int(pr-ps_flags, PS_INEXEC);
 if (pathbuf != NULL)
 pool_put(namei_pool, pathbuf);

 return (0);
 }

 

 'pathbuf' is leaked.

 This path being obviously reachable from userland, it is easy for a
 local (un)privileged user to cause the kernel to run out of memory and
 become unresponsive. OpenBSD 5.7 is affected, and quite certainly
 previous releases.

 Exploit here:

 http://m00nbsd.net/garbage/OpenBSD_execve-DoS.txt

 You can see with vmstat -m that the namei pool becomes enormous.

 Found by The Brainy Code Scanner.

 It is not the last bug Brainy has found, but it is the last one I
 report. I don't have time for that.

 Maxime

Why such a dramatic tone?

--
Ville


Typo in etc.i386/sysctl.conf

2015-06-16 Thread Ville Valkonen
Hello,

a simple typo in etc.i386/sysctl.conf. Simple enough to fix manually
even Gmail mangles the diff:
--- etc/etc.i386/sysctl.confTue Jun 16 22:58:11 2015
+++ etc/etc.i386/sysctl.conf.orig   Tue Jun 16 22:57:55 2015
@@ -1,7 +1,7 @@
 #machdep.allowaperture=2   # See xf86(4)
 #machdep.apmhalt=1 # 1=powerdown hack, try if halt -p doesn't work
 #machdep.kbdreset=1# permit console CTRL-ALT-DEL to do a nice halt
-#machdep.lidsuspend=0  # do not suspend laptop upon lid closing
+#machdep.lidsuspend=0  # do not supsend laptop upon lid closing
 #machdep.userldt=1 # allow userland programs to play with ldt,
# required by some ports
 #kern.emul.linux=1 # enable running Linux binaries

--
Regards,
Ville Valkonen



Re: Typo in etc.i386/sysctl.conf

2015-06-16 Thread Ville Valkonen
On 16 June 2015 at 23:02, Ville Valkonen weezeld...@gmail.com wrote:
 Hello,

 a simple typo in etc.i386/sysctl.conf. Simple enough to fix manually
 even Gmail mangles the diff:
 --- etc/etc.i386/sysctl.confTue Jun 16 22:58:11 2015
 +++ etc/etc.i386/sysctl.conf.orig   Tue Jun 16 22:57:55 2015
 @@ -1,7 +1,7 @@
  #machdep.allowaperture=2   # See xf86(4)
  #machdep.apmhalt=1 # 1=powerdown hack, try if halt -p doesn't 
 work
  #machdep.kbdreset=1# permit console CTRL-ALT-DEL to do a nice 
 halt
 -#machdep.lidsuspend=0  # do not suspend laptop upon lid closing
 +#machdep.lidsuspend=0  # do not supsend laptop upon lid closing
  #machdep.userldt=1 # allow userland programs to play with ldt,
 # required by some ports
  #kern.emul.linux=1 # enable running Linux binaries

 --
 Regards,
 Ville Valkonen

..and managed to get this wrong way around. Great.



Re: Journal Implementation

2015-06-02 Thread Ville Valkonen
Hi,

On Jun 3, 2015 3:17 AM, Walter Neto wsouz...@gmail.com wrote:

 Thanks guys..

 I will read all the tips, and start to code..

 Once I have a diff I share..

  On Jun 2, 2015, at 9:06 PM, Walter Neto wsouz...@gmail.com wrote:
 
 
  On Jun 2, 2015, at 5:03 PM, Paul de Weerd we...@weirdnet.nl wrote:
 
  On Tue, Jun 02, 2015 at 07:33:58PM +, Stefan wrote:
  | http://www.openbsd.org/faq/faq8.html#Journaling
 
  Right, that doesn't help, it's not a tip for someone interested in
  *developing a journaling system for UFS*...  You can rest assured
  they're already aware that OpenBSD doesn't support journaling.
 
  | On Tue, Jun 2, 2015, 2:31 PM Walter Neto wsouz...@gmail.com wrote:
  |  Hy..
  | 
  |  I want to help OpenBSD developing a journaling system for UFS.
  | 
  |  Someone can give me a tip?
 
  Please have a look at this implementation from the FFS author:
 
   http://www.mckusick.com/softdep/suj.pdf
 
  I believe the code is available in FreeBSD.  All it takes is porting.
 
  Before you start your work, keep in mind that there's no guarantee
  that it will be incorporated in OpenBSD.  But, if you present your
  case with proper diffs, you should at least get some attention.
 
  Thank you Paul!
  I intend to help the OpenBSD project, cause is the OS wich I like best,
and
  the feature is the one I need now.
 
  So, I will do my best!
 
 
  Good luck!
 
  Paul 'WEiRD' de Weerd
 
  --
  [++-]+++.+++[---].+++[+
  +++-].++[-]+.--.[-]
 http://www.weirdnet.nl/

have a look on Bitrig, they have implemented NetBSD's journaling and is an
OpenBSD fork.

--
Regards,
Ville


Re: Allow resuming with closed lid

2015-01-30 Thread Ville Valkonen
Hello Mike and Max,

my work laptop is running Windows and on there one must press power button
to wake up the machine. If I connect the dots right, current behaviour was
implemented to prevent a hot bag problem. Mimicking the Windows behaviour
would also prevent laptop wake ups on a bumpy road.

Would it make any sense to mimic this behaviour in obsd?

--
Kind regards,
Ville

On 30 January 2015 at 05:27, Mike Larkin mlar...@azathoth.net wrote:

 On Fri, Jan 30, 2015 at 12:42:04AM +0100, Max Fillinger wrote:
  Currently, there's code in acpi.c that sends the system back to sleep
  when resuming with closed lid and machdep.lidsuspend=1. I often use my
  laptop in a docking station with an external monitor and keep the lid
  closed, and I'd like to be able to resume just by pushing the power
  button on the docking station. (Also, I first thought something was
  broken when pushing the button only made the suspend-indicator light
  blink for a moment.)
 
  If checking for open lids is necessary in some cases, then I can
  certainly live with lidsuspend=0, but otherwise I'd prefer if it was
  possible to resume with a closed lid. I removed the check and didn't
  notice any problems. The diff below removes the check and also the
  function acpibtn_numopenlids which is not used anywhere else.
 

 This was put in for a reason. I would suggest you go read the commit
 logs and understand why, before proposing reverting functionality
 you obviously have not researched.

 -ml

 
 
  Index: sys/dev/acpi/acpi.c
  ===
  RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
  retrieving revision 1.281
  diff -u -p -r1.281 acpi.c
  --- sys/dev/acpi/acpi.c   17 Jan 2015 04:18:49 -  1.281
  +++ sys/dev/acpi/acpi.c   29 Jan 2015 22:53:42 -
  @@ -2161,7 +2161,6 @@ int
   acpi_sleep_state(struct acpi_softc *sc, int state)
   {
extern int perflevel;
  - extern int lid_suspend;
int error = ENXIO;
int s;
 
  @@ -2305,10 +2304,6 @@ fail_alloc:
 
acpi_record_event(sc, APM_NORMAL_RESUME);
acpi_indicator(sc, ACPI_SST_WORKING);
  -
  - /* If we woke up but all the lids are closed, go back to sleep */
  - if (acpibtn_numopenlids() == 0  lid_suspend != 0)
  - acpi_addtask(sc, acpi_sleep_task, sc, state);
 
   fail_tts:
return (error);
  Index: sys/dev/acpi/acpibtn.c
  ===
  RCS file: /cvs/src/sys/dev/acpi/acpibtn.c,v
  retrieving revision 1.41
  diff -u -p -r1.41 acpibtn.c
  --- sys/dev/acpi/acpibtn.c27 Jan 2015 19:40:14 -  1.41
  +++ sys/dev/acpi/acpibtn.c29 Jan 2015 22:53:42 -
  @@ -74,37 +74,6 @@ struct cfdriver acpibtn_cd = {
 
   const char *acpibtn_hids[] = { ACPI_DEV_LD, ACPI_DEV_PBD, ACPI_DEV_SBD,
 0 };
 
  -/*
  - * acpibtn_numopenlids
  - *
  - * Return the number of _LID devices that are in the open state.
  - * Used to determine if we should go back to sleep/hibernate if we
  - * woke up with the all the lids still closed for some reason. If
  - * the machine has no lids, returns -1.
  - */
  -int
  -acpibtn_numopenlids(void)
  -{
  - struct acpi_lid *lid;
  - int64_t val;
  - int ct = 0;
  -
  - /* If we have no lids ... */
  - if (SLIST_EMPTY(acpibtn_lids))
  - return (-1);
  -
  - /*
  -  * Determine how many lids are open. Assumes _LID evals to
  -  * non-0 or 0, for on / off (which is what the spec says).
  -  */
  - SLIST_FOREACH(lid, acpibtn_lids, abl_link)
  - if (!aml_evalinteger(lid-abl_softc-sc_acpi,
  - lid-abl_softc-sc_devnode, _LID, 0, NULL, val) 
  - val != 0)
  - ct++;
  - return (ct);
  -}
  -
   int
   acpibtn_setpsw(struct acpibtn_softc *sc, int psw)
   {
  Index: sys/dev/acpi/acpidev.h
  ===
  RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
  retrieving revision 1.36
  diff -u -p -r1.36 acpidev.h
  --- sys/dev/acpi/acpidev.h23 Nov 2014 20:33:47 -  1.36
  +++ sys/dev/acpi/acpidev.h29 Jan 2015 22:53:42 -
  @@ -337,5 +337,4 @@ struct acpiec_softc {
 
   void acpibtn_disable_psw(void);
   void acpibtn_enable_psw(void);
  -int  acpibtn_numopenlids(void);
   #endif /* __DEV_ACPI_ACPIDEV_H__ */
 




Re: lynx: disable old protocols

2014-07-20 Thread Ville Valkonen
Thank you Bob and Stuart for the answers.

What Bob proposes is a bit cumbersome since it involves remembering
the full URL path.

Stuart's suggestion really addresses the problem I'm experiencing. I
admit there's only a bunch of cases where I haven't had my laptop
within me, or no nearby computer with a monitor and a working network
connection. Thanks for looking into this.

--
Thanks a munch,
Ville

On Sat, Jul 19, 2014 at 12:28:17PM +0100, Stuart Henderson wrote:
 Personally I remember a few nearby mirror URLs, but I do think this could
 be improved - we could add a sample pkg.conf file to /etc/examples with
 a list of mirrors updated from mirrors.dat. Unless there are objections to
 that idea, I'll look at modifying the scripts for this.

On 19 July 2014 01:36, Bob Beck b...@obtuse.com wrote:
 ftp -o - http://ftp.openbsd.org/pub/OpenBSD/snapshots/ftplist | some
 script, or maybe your eyes and pick one.

 On Fri, Jul 18, 2014 at 4:29 PM, Ville Valkonen weezeld...@gmail.com wrote:
 On 17 July 2014 00:10, Stuart Henderson st...@openbsd.org wrote:
 On 2014/07/16 16:00, Jean-Philippe Ouellet wrote:
 Oh come on... It's not like the URLs are some giant uuid-based madness
 or something. All the mirrors have the same simple layout. If you install
 lots of boxes regularly, it doesn't take long to memorize the name of
 your closest mirror. If you don't install lots of stuff, then just set
 installpath in your pkg.conf and forget about it.

 If you choose your mirror from the list in the installer, this is already
 set automatically in pkg.conf.

 Hello Stuart,

 what would you suggest for situations where installXX.iso is burned to
 a CD to avoid downloading sets from the net due a slow Internet
 connection? When sets are installed from the CD it doesn't set
 PKG_PATH. I couldn't find any mirror list from the ISO image by
 grepping.

 Previously I've used lynx to navigate on the project's website and
 copypaste mirror URL with tmux.

 Thanks in advance,
 Ville




Re: lynx: disable old protocols

2014-07-18 Thread Ville Valkonen
On 17 July 2014 00:10, Stuart Henderson st...@openbsd.org wrote:
 On 2014/07/16 16:00, Jean-Philippe Ouellet wrote:
 Oh come on... It's not like the URLs are some giant uuid-based madness
 or something. All the mirrors have the same simple layout. If you install
 lots of boxes regularly, it doesn't take long to memorize the name of
 your closest mirror. If you don't install lots of stuff, then just set
 installpath in your pkg.conf and forget about it.

 If you choose your mirror from the list in the installer, this is already
 set automatically in pkg.conf.

Hello Stuart,

what would you suggest for situations where installXX.iso is burned to
a CD to avoid downloading sets from the net due a slow Internet
connection? When sets are installed from the CD it doesn't set
PKG_PATH. I couldn't find any mirror list from the ISO image by
grepping.

Previously I've used lynx to navigate on the project's website and
copypaste mirror URL with tmux.

Thanks in advance,
Ville



Re: PATCH: misc mkstemp and fdopen fixes

2014-07-11 Thread Ville Valkonen
, fname);
 +   }
 if (unlink(fname) == -1)
 err(1, %s: cannot unlink, fname);
 }
 Index: usr.bin/rwall/rwall.c
 ===
 RCS file: /cvs/src/usr.bin/rwall/rwall.c,v
 retrieving revision 1.12
 diff -u -p -d -r1.12 rwall.c
 --- usr.bin/rwall/rwall.c   27 Oct 2009 23:59:43 -  1.12
 +++ usr.bin/rwall/rwall.c   11 Jul 2014 09:14:13 -
 @@ -112,8 +112,14 @@ makemsg(char *fname)
 char *whom, hostname[MAXHOSTNAMELEN], lbuf[100], tmpname[MAXPATHLEN];

 snprintf(tmpname, sizeof(tmpname), %s/wall.XX, _PATH_TMP);
 -   if ((fd = mkstemp(tmpname)) == -1 || !(fp = fdopen(fd, r+)))
 +   if ((fd = mkstemp(tmpname)) == -1 ||
 +   (fp = fdopen(fd, r+)) == NULL) {
 +   if (fd != -1) {
 +   unlink(tmpname);
 +   close(fd);
 +   }
 err(1, can't open temporary file);
 +   }
 (void)unlink(tmpname);

 if (!(whom = getlogin()))
 Index: usr.bin/sort/sort.c
 ===
 RCS file: /cvs/src/usr.bin/sort/sort.c,v
 retrieving revision 1.41
 diff -u -p -d -r1.41 sort.c
 --- usr.bin/sort/sort.c 13 Nov 2013 15:07:27 -  1.41
 +++ usr.bin/sort/sort.c 11 Jul 2014 09:14:13 -
 @@ -282,8 +282,13 @@ main(int argc, char *argv[])
 (void)umask(um);
 if ((outfd = mkstemp(toutpath)) == -1 ||
 fchmod(outfd, DEFFILEMODE  ~um) == -1 ||
 -   (outfp = fdopen(outfd, w)) == NULL)
 +   (outfp = fdopen(outfd, w)) == NULL) {
 +   if (outfd != -1) {
 +   unlink(toutpath);
 +   close(outfd);
 +   }
 err(2, %s, toutpath);
 +   }
 outfile = toutpath;

 (void)atexit(cleanup);
 Index: usr.bin/sort/tmp.c
 ===
 RCS file: /cvs/src/usr.bin/sort/tmp.c,v
 retrieving revision 1.9
 diff -u -p -d -r1.9 tmp.c
 --- usr.bin/sort/tmp.c  27 Oct 2009 23:59:43 -  1.9
 +++ usr.bin/sort/tmp.c  11 Jul 2014 09:14:13 -
 @@ -65,8 +65,10 @@ ftmp(void)
 (void)sigprocmask(SIG_BLOCK, set, oset);
 if ((fd = mkstemp(path))  0)
 err(2, %s, path);
 -   if (!(fp = fdopen(fd, w+)))
 +   if (!(fp = fdopen(fd, w+))) {
 +   (void)unlink(path);
 err(2, %s, path);
 +   }
 (void)unlink(path);

 (void)sigprocmask(SIG_SETMASK, oset, NULL);
 Index: usr.bin/ssh/moduli.c
 ===
 RCS file: /cvs/src/usr.bin/ssh/moduli.c,v
 retrieving revision 1.28
 diff -u -p -d -r1.28 moduli.c
 --- usr.bin/ssh/moduli.c24 Oct 2013 00:49:49 -  1.28
 +++ usr.bin/ssh/moduli.c11 Jul 2014 09:14:14 -
 @@ -457,6 +457,7 @@ write_checkpoint(char *cpfile, u_int32_t
 }
 if ((fp = fdopen(r, w)) == NULL) {
 logit(write_checkpoint: fdopen: %s, strerror(errno));
 +   unlink(tmp);
 close(r);
 return;
 }
 Index: usr.bin/tic/tic.c
 ===
 RCS file: /cvs/src/usr.bin/tic/tic.c,v
 retrieving revision 1.31
 diff -u -p -d -r1.31 tic.c
 --- usr.bin/tic/tic.c   28 Nov 2013 18:24:55 -  1.31
 +++ usr.bin/tic/tic.c   11 Jul 2014 09:14:15 -
 @@ -460,11 +460,18 @@ matches(char **needle, const char *hayst
  static FILE *
  open_tempfile(char *name)
  {
 -FILE *result = 0;
 +FILE *result;
  #if HAVE_MKSTEMP
 -int fd = mkstemp(name);
 -if (fd = 0)
 -   result = fdopen(fd, w);
 +int fd;
 +
 +if ((fd = mkstemp(name)) == -1 ||
 +(result = fdopen(fd, w)) == NULL) {
 +if (fd != -1) {
 +unlink(name);
 +close(fd);
 +}
 +return (NULL);
 +}
  #else
  if (tmpnam(name) != 0)
 result = fopen(name, w);
 Index: usr.sbin/user/user.c
 ===
 RCS file: /cvs/src/usr.sbin/user/user.c,v
 retrieving revision 1.98
 diff -u -p -d -r1.98 user.c
 --- usr.sbin/user/user.c23 Nov 2013 17:14:05 -  1.98
 +++ usr.sbin/user/user.c11 Jul 2014 09:14:31 -
 @@ -721,6 +721,8 @@ setdefaults(user_t *up)
 }
 if ((fp = fdopen(fd, w)) == NULL) {
 warn(can't fdopen `%s' for writing, CONFFILE);
 +   unlink(template);
 +   close(fd);
 return 0;
 }
 ret = 1;

Hello Doug,

not sure whether it's my eyes or the Gmail client but looks like you
are using spaces for indention. Preferred way is to use tabs.

--
Kind regards,
Ville

Re: Amd64 relocation R_X86_64_32S in a static lib

2013-11-06 Thread Ville Valkonen
On 7 November 2013 04:24, Philip Guenther guent...@gmail.com wrote:
 On Wed, 6 Nov 2013, Torbjorn Granlund wrote:
 ...
 The change makes be quite worried, since it *seems* to be done without
 proper understanding of the issues involved.

 Appearances can be deceiving.


 Furthermore, the ABI change has not been properly announced,

 I guess the release announcement wasn't enough?

+ it was mentioned in current.html (http://www.openbsd.org/faq/current.html)

--
Regards,
Ville



Re: memset.S for amd64

2013-09-19 Thread Ville Valkonen
(Pardon top-posting)

I can spot few differences:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/lib/libkern/arch/amd64/memset.S?rev=1.3;content-type=text%2Fplain
and
http://svnweb.freebsd.org/base/release/8.2.0/lib/libc/amd64/string/memset.S?revision=218742view=markup

though I am not familiar with assembly.

--
Ville

On 19 September 2013 14:47, mxb m...@alumni.chalmers.se wrote:

 This file is already in base.
 /usr/src/sys/lib/libkern/arch/amd64/memset.S


 On 18 sep 2013, at 20:28, Edd Barrett vex...@gmail.com wrote:

 On Wed, Sep 18, 2013 at 07:08:31PM +0100, Edd Barrett wrote:
 In short, each experiment warms up by setting and checking a load of buffers
 before setting as many buffers as possible given a one minute timeframe. The
 experiments were run with varying buffer sizes under both memset.S and
 memset.c.

 Forgot to say, each experiment was repeated 5 times (each bufsz/
 memset combination) and averages were taken.

 See the Python scripts in the repo for details.

 --
 Best Regards
 Edd Barrett

 http://www.theunixzoo.co.uk



Re: Iso image integrity verification

2013-09-11 Thread Ville Valkonen
On 11 September 2013 20:42, Valentin Zagura put...@gmail.com wrote:
 The idea was to display a checksum of the files on such a https page.
 Like for example https://www.freebsd.org/releases/9.1R/announce.html at the
 bottom of the page.

Not sure whether this is already proposed but here's my two cents: why
not to check SHA256 sums from the various mirrors and perform the
comparison?

--
Cheers,
Ville Valkonen



Re: drm bits on 54.html

2013-08-10 Thread Ville Valkonen
On 10 August 2013 12:09, Brad Smith b...@comstyle.com wrote:
 - Original message -
 On Sat, Aug 10, 2013 at 11:58 AM, Brad Smith b...@comstyle.com wrote:
  - Original message -
   Hi tech@.
  
   54.html says:
  
Now mostly in sync with Linux 3.8.13
  
   But there's no such thing as Linux X.X.X, there's a Linux kernel
   X.X.X.
 
  But there is. The later is redundant. Linux is a kernel.

 In geek world, maybe, but not in Real World (tm)

 http://en.wikipedia.org/wiki/Linux

 Yes, real world so often uses names and terms improperly. whats new.

In real world hacking is cracking :(



Re: CVS: cvs.openbsd.org: src

2013-06-08 Thread Ville Valkonen
Hi, did you compile the recent Xenocara too?
On Jun 8, 2013 9:30 AM, Scott McEachern sc...@blackstaff.ca wrote:

 On 06/07/13 16:46, Mark Kettenis wrote:

 CVSROOT:/cvs
 Module name:src
 Changes by: kette...@cvs.openbsd.org2013/06/07 14:46:15

 Modified files:
 sys/uvm: uvm_device.c uvm_device.h
 sys/dev/pci/drm: drm.h drmP.h drm_drv.c
 sys/dev/pci/drm/i915: i915_gem.c

 Log message:
 Add proper mmap(2) support for drm(4)/inteldrm(4).  This changes the
 DRM_I915_GEM_MMAP and DRM_I915_GEM_MMAP_GTT ioctls to be compatible with
 Linux.  This also is the first step that moves us away from accessing all
 graphics memory through the GTT, which should make things faster.

 ok tedu@ (for the uvm bits)


 I just built a new kernel using -current sources, including this change,
 in preparation to build the system.  It didn't work out very well and I had
 to revert to obsd.

 The kernel boot display looks normal, going from 25-40 rows properly,
 however, once X starts the puffy OpenBSD 5.3 logo is garbled beyond
 recognition.  The surrounding text of the hostname and name/password stuff
 looks fine.  After logging in and spectrwm starts, the display is
 completely distorted and unusable.

 Just thought I'd let you know.  dmesg from the previous (working) kernel:

 OpenBSD 5.3-current (GENERIC.MP) #1: Wed Jun  5 05:06:14 EDT 2013
 r...@elminster.blackstaff.ca:/**usr/src/sys/arch/amd64/**compile/
 GENERIC.MP
 real mem = 16835637248 (16055MB)
 avail mem = 16379756544 (15620MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (112 entries)
 bios0: vendor American Megatrends Inc. version 0408 date 06/05/2012
 bios0: ASUSTeK COMPUTER INC. P8Z77-V PREMIUM
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S1 S3 S4 S5
 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT BGRT
 acpi0: wakeup devices PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4) RP01(S4)
 PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4)
 PXSX(S4) RP06(S4) PXSX(S4) [...]
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3606.22 MHz
 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
 cpu0: apic clock running at 103MHz
 cpu1 at mainbus0: apid 2 (application processor)
 cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 1, package 0
 cpu2 at mainbus0: apid 4 (application processor)
 cpu2: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu2: 256KB 64b/line 8-way L2 cache
 cpu2: smt 0, core 2, package 0
 cpu3 at mainbus0: apid 6 (application processor)
 cpu3: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu3: 256KB 64b/line 8-way L2 cache
 cpu3: smt 0, core 3, package 0
 cpu4 at mainbus0: apid 1 (application processor)
 cpu4: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu4: 256KB 64b/line 8-way L2 cache
 cpu4: smt 1, core 0, package 0
 cpu5 at mainbus0: apid 3 (application processor)
 cpu5: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 

[PATCH] amd.8 default configuration file

2013-06-05 Thread Ville Valkonen
Hi,

although amd's default configuration file placement is probably quite
self-explanatory, I thought it would be worth to mention that in the
man page. FreeBSD and NetBSD do the same.

As Gmail (a web client) mangles the patches, here's the link for it:
http://weezel.fsck.fi/amd8_defaultconfig.patch

--
Sincerely,
Ville Valkonen



PATCH: merge.c white space cleanup

2013-01-24 Thread Ville Valkonen
Hi,

save a few precious bytes by removing unnecessary white spaces from
libc/merge.c.

URL: http://weezel.fsck.fi/merge.patch

--
Sincerely,
Ville Valkonen



Re: Scheduler improvements

2012-10-08 Thread Ville Valkonen
Hi,

Seems to be a bit snappier, though more thorough testing needed. Many web pages
became more usable after the patch (chrome as browser) and some gains in
desktop too. System is amd64 @ Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz and
4G RAM.

--
cheers,
Ville



Re: cwm tiling

2012-06-09 Thread Ville Valkonen
+1
On Jun 9, 2012 5:46 AM, Christiano F. Haesbaert christiano...@gmail.com
wrote:

 On Jun 8, 2012 9:22 PM, Jérémie Courrèges-Anglas jca+o...@wxcvbn.org
 wrote:
 
  Antoine Jacoutot ajacou...@bsdfrog.org writes:
   I for one would love cwm to have tiling management.
   I don't care avout the alternative, they are not in base.
 
  Same here.
 

 I might migrate to cwm just for the tilling.

  --
  Jérémie Courrèges-Anglas
  GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494



Atom D-2700 support

2012-03-18 Thread Ville Valkonen
(Sorry if this is a duplicate but I couldn't the previous try from Gmane)

Hello,

I had a discussion with Joerg Zinke whether this patch have been
applied into the upstream. I sent it to @tech (see details below) some
time ago but did not receive any feedback. As suggested by Joerg, I
also sent reminder to @jsg (no reply yet).

So, if some kernel developer could review and commit this, I and Joerg
would be very happy at least :)

Best wishes,
Ville


On 11 March 2012 18:30, Ville Valkonen weezelding[ at ]gmail.com wrote:
 Hello Joerg,

 I haven't received any feedback from the patch yet. Apparently the
 timing was a bit bad since the repository was about to become locked
 at that time.

 Here's the previous discussion regarding the topic (@misc):
 http://marc.info/?l=openbsd-miscm=132886488701795w=2

 After compile and testing it few days I also sent it to I to @tech:
 http://marc.info/?l=openbsd-techm=132886685402343w=2

 In summary: here's my second take for the patch and if it's not enough
 well tested just let me know what else needs to be done.

 Kind regards,
 Ville Valkonen

 On 11 March 2012 13:57, Joerg Zinke mail[ at ]umaxx.net wrote:
 Hi,

 did you got any feedback on this diff?

 This looks good to me and seems to be required for the Soekris 6501 as well.
 But since this Kernel region is not my department I'm afraid to OK it.

 Maybe you want to resubmit it, or remind jsg@ to commit it?

 Thanks,
 Regards,
 Joerg

 On Fri, Feb 10, 2012 at 11:38:56AM +0200, Ville Valkonen wrote:
 Hello,

 This patch adds support for the Intel Atom D-2700 processor. The patch
 is originally from Jonathan Gray (jsg[ at ]jsg.id.au), tested by me.

 Patch:
 Index: sys/arch/i386/i386/machdep.c
 ===
 RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
 retrieving revision 1.506
 diff -u -p -r1.506 machdep.c
 --- sys/arch/i386/i386/machdep.c2 Nov 2011 23:53:44 -   
 1.506
 +++ sys/arch/i386/i386/machdep.c4 Feb 2012 13:37:48 -
 @@ -2075,6 +2075,8 @@ p3_get_bus_clock(struct cpu_info *ci)
}
break;
case 0x1c: /* Atom */
 +   case 0x26: /* Atom Z6xx */
 +   case 0x36: /* Atom [DN]2xxx */
msr = rdmsr(MSR_FSB_FREQ);
bus = (msr  0)  0x7;
switch (bus) {
 @@ -2131,6 +2133,7 @@ p3_get_bus_clock(struct cpu_info *ci)
break;
case 0x2a: /* Core i5/i7 2nd Generation */
case 0x2d: /* Xeon E5 */
 +   case 0x2f: /* Xeon E7 */
/* BUS100 */
break;
case 0x1d: /* Xeon MP 7400 */
 Index: sys/arch/amd64/amd64/est.c
 ===
 RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
 retrieving revision 1.25
 diff -u -p -r1.25 est.c
 --- sys/arch/amd64/amd64/est.c  19 Apr 2011 22:14:54 -  1.25
 +++ sys/arch/amd64/amd64/est.c  4 Feb 2012 13:37:48 -
 @@ -198,6 +198,8 @@ p3_get_bus_clock(struct cpu_info *ci)
}
break;
case 0x1c: /* Atom */
 +   case 0x26: /* Atom Z6xx */
 +   case 0x36: /* Atom [DN]2xxx */
msr = rdmsr(MSR_FSB_FREQ);
bus = (msr  0)  0x7;
switch (bus) {
 @@ -228,6 +230,7 @@ p3_get_bus_clock(struct cpu_info *ci)
break;
case 0x2a: /* Core i5/i7 2nd Generation */
case 0x2d: /* Xeon E5 */
 +   case 0x2f: /* Xeon E7 */
/* BUS100 */
break;
case 0x1d: /* Xeon MP 7400 */


 ##
 ## Dmesg after patching
 ##
 OpenBSD 5.1 (severi) #0: Fri Feb 10 01:53:24 EET 2012
 weezel@severi.local:/usr/src/sys/arch/i386/compile/severi
 cpu0: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel
 686-class) 2.13 GHz
 cpu0: 
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
 real mem  = 2134732800 (2035MB)
 avail mem = 2089684992 (1992MB)
 User Kernel Config
 UKC disable acpiec
 475 acpiec* disabled
 UKC quit
 Continuing...
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 10/20/10, SMBIOS rev. 2.7 @
 0xe9670 (51 entries)
 bios0: vendor American Megatrends Inc. version 4.6.4 date 12/01/2011
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S1 S4 S5
 acpi0: tables DSDT FACP APIC MCFG HPET SSDT
 acpi0: wakeup devices P0P8(S4) PS2K(S1) PS2M(S1) USB0(S4) USB1(S4)
 USB2(S4) USB3(S4) USB7(S4) PXSX(S4) RP01(S4) PXSX(S4) RP03(S4)
 PXSX(S4) RP04(S4) PXSX(S4) RP02(S4) PWRB(S1)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: apic clock running at 133MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel
 686-class) 2.13

typo in sysctl.8

2012-03-11 Thread Ville Valkonen
Fix typo in sysctl.8. Sysctl machdep prints osfxsr but I couldn't find
this from the man page. Also grepping through /usr/include found
osfxsr matches but no osxsfr.

--- sysctl.8.orig   Sun Mar 11 13:24:29 2012
+++ sysctl.8Sun Mar 11 13:25:13 2012
@@ -353,7 +353,7 @@ and a few require a kernel compiled with non-standard
 .It machdep.apmhalt Ta integer Ta yes
 .It machdep.kbdreset Ta integer Ta yes
 .It machdep.userldt Ta integer Ta yes
-.It machdep.osxsfr Ta integer Ta no
+.It machdep.osfxsr Ta integer Ta no
 .It machdep.sse Ta integer Ta no
 .It machdep.sse2 Ta integer Ta no
 .It machdep.xcrypt Ta integer Ta no



Add support for the Intel Atom D-7200 processor

2012-02-10 Thread Ville Valkonen
Hello,

This patch adds support for the Intel Atom D-2700 processor. The patch
is originally from Jonathan Gray (jsg[ at ]jsg.id.au), tested by me.

Patch:
Index: sys/arch/i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.506
diff -u -p -r1.506 machdep.c
--- sys/arch/i386/i386/machdep.c2 Nov 2011 23:53:44 -   1.506
+++ sys/arch/i386/i386/machdep.c4 Feb 2012 13:37:48 -
@@ -2075,6 +2075,8 @@ p3_get_bus_clock(struct cpu_info *ci)
   }
   break;
   case 0x1c: /* Atom */
+   case 0x26: /* Atom Z6xx */
+   case 0x36: /* Atom [DN]2xxx */
   msr = rdmsr(MSR_FSB_FREQ);
   bus = (msr  0)  0x7;
   switch (bus) {
@@ -2131,6 +2133,7 @@ p3_get_bus_clock(struct cpu_info *ci)
   break;
   case 0x2a: /* Core i5/i7 2nd Generation */
   case 0x2d: /* Xeon E5 */
+   case 0x2f: /* Xeon E7 */
   /* BUS100 */
   break;
   case 0x1d: /* Xeon MP 7400 */
Index: sys/arch/amd64/amd64/est.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
retrieving revision 1.25
diff -u -p -r1.25 est.c
--- sys/arch/amd64/amd64/est.c  19 Apr 2011 22:14:54 -  1.25
+++ sys/arch/amd64/amd64/est.c  4 Feb 2012 13:37:48 -
@@ -198,6 +198,8 @@ p3_get_bus_clock(struct cpu_info *ci)
   }
   break;
   case 0x1c: /* Atom */
+   case 0x26: /* Atom Z6xx */
+   case 0x36: /* Atom [DN]2xxx */
   msr = rdmsr(MSR_FSB_FREQ);
   bus = (msr  0)  0x7;
   switch (bus) {
@@ -228,6 +230,7 @@ p3_get_bus_clock(struct cpu_info *ci)
   break;
   case 0x2a: /* Core i5/i7 2nd Generation */
   case 0x2d: /* Xeon E5 */
+   case 0x2f: /* Xeon E7 */
   /* BUS100 */
   break;
   case 0x1d: /* Xeon MP 7400 */


##
## Dmesg after patching
##
OpenBSD 5.1 (severi) #0: Fri Feb 10 01:53:24 EET 2012
weezel@severi.local:/usr/src/sys/arch/i386/compile/severi
cpu0: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel
686-class) 2.13 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
real mem  = 2134732800 (2035MB)
avail mem = 2089684992 (1992MB)
User Kernel Config
UKC disable acpiec
475 acpiec* disabled
UKC quit
Continuing...
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/20/10, SMBIOS rev. 2.7 @
0xe9670 (51 entries)
bios0: vendor American Megatrends Inc. version 4.6.4 date 12/01/2011
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT
acpi0: wakeup devices P0P8(S4) PS2K(S1) PS2M(S1) USB0(S4) USB1(S4)
USB2(S4) USB3(S4) USB7(S4) PXSX(S4) RP01(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) PXSX(S4) RP02(S4) PWRB(S1)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel
686-class) 2.13 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel
686-class) 2.13 GHz
cpu2: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz (GenuineIntel
686-class) 2.13 GHz
cpu3: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,DS-CPL,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (P0P8)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus 4 (RP04)
acpiprt5 at acpi0: bus 2 (RP02)
acpiec at acpi0 not configured
acpicpu0 at acpi0: C1
acpicpu1 at acpi0: C1
acpicpu2 at acpi0: C1
acpicpu3 at acpi0: C1
acpitz0 at acpi0: critical temperature is 75 degC
acpipwrres0 at acpi0: FN00
acpitz1 at acpi0: critical temperature is 127 degC
acpitz2 at acpi0: critical temperature is 100 degC
acpibat0 at acpi0: BAT0 model CRB Battery 0 serial Battery 0
type Fake oem