Re: Pass -U to pgrep and pkill in rc.subr(8)
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
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 > > >
Re: uhidpp(4): logitech hid++ device driver
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
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
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 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
Re: uhidpp(4): logitech hid++ device driver
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 WI
[PATCH] Extra lines in ssh-pkcs11-client.c file
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
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->sc_ic;
> > + struct ieee80211_key *k = &ni->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->ni_rx_ba[tid] : NULL;
> > + prsc = &k->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
> > +
Re: iwm(4) WPA2 crypto hardware offload
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->sc_ic;
> + struct ieee80211_key *k = &ni->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->ni_rx_ba[tid] : NULL;
> + prsc = &k->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;
> + }
> + }
> +
[PATCH] Parallelize sysupgrade downloads
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
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
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
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, &ttyctx);
- tty_write(tty_cmd_linefeed, &ttyctx);
+ 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
uot;Intel 9 Series Thermal" 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
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
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
On 24 January 2016 at 20:47, Adam Wolk wrote: > On Fri, 22 Jan 2016 22:46:39 +0100 (CET) > Mark Kettenis 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
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
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, &endptr, 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, &endptr, 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
On 11 December 2015 at 10:36, Joerg Jung wrote:
> Ping. Anyone?
>
> > On 07 Dec 2015, at 23:39, Joerg Jung 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()
Hello Maxime, On Aug 7, 2015 10:56 PM, "Maxime Villard" 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 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)
On Jul 21, 2015 11:21 PM, 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()
On Jul 21, 2015 9:32 AM, "Maxime Villard" 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
Re: Typo in etc.i386/sysctl.conf
On 16 June 2015 at 23:02, Ville Valkonen 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.
Typo in etc.i386/sysctl.conf
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: Journal Implementation
Hi, On Jun 3, 2015 3:17 AM, "Walter Neto" 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 wrote: > > > > > >> On Jun 2, 2015, at 5:03 PM, Paul de Weerd 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 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
Typo in faq4.html
Hello, if I haven't completely mistaken, the correct form is unattended: --- faq4.html.orig 2015-02-05 13:04:57.444046000 +0200 +++ faq4.html 2015-02-05 13:05:12.268171000 +0200 @@ -2240,7 +2240,7 @@ applications which can use much, much mo While this directory is world-writable, when it is a separate partition, OpenBSD defaults to mounting it nodev and nosuid, which minimizes how it can be used to abuse your system. -Files left unattened here will be purged automatically, this is NOT for +Files left unattended here will be purged automatically, this is NOT for long term storage! /var: -- Regards, Ville
Re: Allow resuming with closed lid
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 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
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 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 wrote: >> On 17 July 2014 00:10, Stuart Henderson 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 >> copy&paste mirror URL with tmux. >> >> Thanks in advance, >> Ville >>
Re: lynx: disable old protocols
On 17 July 2014 00:10, Stuart Henderson 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 copy&paste mirror URL with tmux. Thanks in advance, Ville
Re: PATCH: misc mkstemp and fdopen fixes
file(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 Valkonen
Re: Amd64 relocation R_X86_64_32S in a static lib
On 7 November 2013 04:24, Philip Guenther 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
(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=218742&view=markup though I am not familiar with assembly. -- Ville On 19 September 2013 14:47, mxb 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 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
On 11 September 2013 20:42, Valentin Zagura 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
On 10 August 2013 12:09, Brad Smith wrote: > - Original message - >> On Sat, Aug 10, 2013 at 11:58 AM, Brad Smith 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
Hi, did you compile the recent Xenocara too? On Jun 8, 2013 9:30 AM, "Scott McEachern" 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,S
[PATCH] amd.8 default configuration file
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
Hi, save a few precious bytes by removing unnecessary white spaces from libc/merge.c. http://weezel.fsck.fi/merge.patch> -- Sincerely, Ville Valkonen
Re: Scheduler improvements
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
+1 On Jun 9, 2012 5:46 AM, "Christiano F. Haesbaert" wrote: > On Jun 8, 2012 9:22 PM, "Jérémie Courrèges-Anglas" > wrote: > > > > Antoine Jacoutot 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
(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 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-misc&m=132886488701795&w=2
>
> After compile and testing it few days I also sent it to I to @tech:
> http://marc.info/?l=openbsd-tech&m=132886685402343&w=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 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,M
typo in sysctl.8
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
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 Batt
