Re: Port httpd(8) 'strip' directive to relayd(8)

[Olivier Cherrier]

Hello tech@,

Is there any interest for this feature to be commited?
I find it very useful. Thank you Denis!

-- 
Olivier Cherrier
Phone: +352691570680
mailto:o...@symacx.com

On Sun, Oct 25, 2020 at 11:28:10AM +0100, open...@ledeuns.net wrote:
> Date: Sun, 25 Oct 2020 11:28:10 +0100
> From: Denis Fondras 
> To: Hiltjo Posthuma 
> Cc: tech@openbsd.org
> Subject: Re: Port httpd(8) 'strip' directive to relayd(8)
> 
> Previous one had a typo... :/
> 
> On Sat, Oct 24, 2020 at 08:01:36PM +0200, Hiltjo Posthuma wrote:
> > Thanks for working on this.  I haven't tested the patch yet except 
> > compiling,
> > but this feature would be very nice to have imho.
> > 
> > I find the current "path replace" syntax confusing and it doesn't work for 
> > this
> > use-case.
> > 
> > Some comments below:
> > 
> 
> Thank you for the comments Hiltjo.
> 
> Here is an updated diff :
> 
> Index: parse.y
> ===
> RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
> retrieving revision 1.246
> diff -u -p -r1.246 parse.y
> --- parse.y   14 Sep 2020 11:30:25 -  1.246
> +++ parse.y   25 Oct 2020 09:20:53 -
> @@ -175,8 +175,8 @@ typedef struct {
>  %token   LOOKUP METHOD MODE NAT NO DESTINATION NODELAY NOTHING ON PARENT 
> PATH
>  %token   PFTAG PORT PREFORK PRIORITY PROTO QUERYSTR REAL REDIRECT RELAY 
> REMOVE
>  %token   REQUEST RESPONSE RETRY QUICK RETURN ROUNDROBIN ROUTE SACK 
> SCRIPT SEND
> -%token   SESSION SNMP SOCKET SPLICE SSL STICKYADDR STYLE TABLE TAG 
> TAGGED TCP
> -%token   TIMEOUT TLS TO ROUTER RTLABEL TRANSPARENT TRAP URL WITH TTL 
> RTABLE
> +%token   SESSION SNMP SOCKET SPLICE SSL STICKYADDR STRIP STYLE TABLE TAG 
> TAGGED
> +%token   TCP TIMEOUT TLS TO ROUTER RTLABEL TRANSPARENT TRAP URL WITH TTL 
> RTABLE
>  %token   MATCH PARAMS RANDOM LEASTSTATES SRCHASH KEY CERTIFICATE 
> PASSWORD ECDHE
>  %token   EDH TICKETS CONNECTION CONNECTIONS CONTEXT ERRORS STATE CHANGES 
> CHECKS
>  %token   WEBSOCKETS
> @@ -1569,6 +1569,20 @@ ruleopts   : METHOD STRING 
> {
>   rule->rule_kv[keytype].kv_option = $2;
>   rule->rule_kv[keytype].kv_type = keytype;
>   }
> + | PATH STRIP NUMBER {
> + char*strip = NULL;
> +
> + if ($3 < 0 || $3 > INT_MAX) {
> + yyerror("invalid strip number");
> + YYERROR;
> + }
> + if (asprintf(, "%lld", $3) <= 0)
> + fatal("can't parse strip");
> + keytype = KEY_TYPE_PATH;
> + rule->rule_kv[keytype].kv_option = KEY_OPTION_STRIP;
> + rule->rule_kv[keytype].kv_value = strip;
> + rule->rule_kv[keytype].kv_type = keytype;
> + }
>   | QUERYSTR key_option STRING value  {
>   switch ($2) {
>   case KEY_OPTION_APPEND:
> @@ -2506,6 +2520,7 @@ lookup(char *s)
>   { "ssl",SSL },
>   { "state",  STATE },
>   { "sticky-address", STICKYADDR },
> + { "strip",  STRIP },
>   { "style",  STYLE },
>   { "table",  TABLE },
>   { "tag",TAG },
> Index: relay.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
> retrieving revision 1.251
> diff -u -p -r1.251 relay.c
> --- relay.c   14 May 2020 17:27:38 -  1.251
> +++ relay.c   25 Oct 2020 09:20:53 -
> @@ -214,6 +214,9 @@ relay_ruledebug(struct relay_rule *rule)
>   case KEY_OPTION_LOG:
>   fprintf(stderr, "log ");
>   break;
> + case KEY_OPTION_STRIP:
> + fprintf(stderr, "strip ");
> + break;
>   case KEY_OPTION_NONE:
>   break;
>   }
> @@ -227,13 +230,15 @@ relay_ruledebug(struct relay_rule *rule)
>   break;
>   }
>  
> + int kvv = (kv->kv_option == KEY_OPTION_STRIP ||
> +  kv->kv_value == NULL);
>   fprintf(stderr, "

Re: macppc G5 pmap fix

[Olivier Cherrier]

On Sun, Jul 12, 2020 at 11:33:33AM +0200, mark.kette...@xs4all.nl wrote:
> 
> While working on the OpenBSD/powerpc64 pmap I noticed that the code we
> use for the G5 machines has a bug and doesn't remove execute
> permission from mappings when it should.
> 
> Since I don't have a G5 machine readily available, can somebody test
> this diff for me?
 
Hello Mark,

I'm running with it on my G5 and it seems happy.

$ sysctl hw.{machine,model,vendor,product} 
hw.machine=macppc
hw.model=970FX (Revision 0x300)
hw.vendor=Apple Computer, Inc.
hw.product=PowerMac8,1

Thanks,
Best.

-- 
Olivier Cherrier
Phone: +352691570680
mailto:o...@symacx.com

Re: preliminary kabylake support for inteldrm

[Olivier Cherrier]

Hi Robert,

Snapshot works pretty well on my new laptop (Intel HD Graphics 510).
Resuming is working great! No regression. Thank you!
dmesg is attached.


There are those error messages :
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load 
firmware i915/skl_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error 
-8 (ignored)
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load 
firmware i915/skl_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error 
-8 (ignored)


Thanks,
Best
oc


Or Wed, Sep 27, 2017 at 12:07:42AM +0200, rob...@openbsd.org wrote:
> Date: Wed, 27 Sep 2017 00:07:42 +0200
> From: Robert Nagy 
> To: tech@openbsd.org
> Subject: Re: preliminary kabylake support for inteldrm
> 
> 
> Hi
> 
> This is an updated diff for preliminary kabylake support for 6.2,
> this needs extensive testing on all inteldrm variants.
> 
> This diff is also in snapshots now so please, test, test test!
> 
> Thank you
OpenBSD 6.2 (GENERIC.MP) #111: Tue Sep 26 11:09:09 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4188946432 (3994MB)
avail mem = 4054966272 (3867MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x87ee6000 (43 entries)
bios0: vendor American Megatrends Inc. version "5.11" date 06/03/2016
bios0: Notebook N24_25JU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT DBGP DBG2 SSDT UEFI 
SSDT DMAR ASF!
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) 
PXSX(S4) RP01(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) Pentium(R) CPU 4405U @ 2.10GHz, 2112.00 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,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 211200 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
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) Pentium(R) CPU 4405U @ 2.10GHz, 2112.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Pentium(R) CPU 4405U @ 2.10GHz, 2112.00 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,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Pentium(R) CPU 4405U @ 2.10GHz, 2112.00 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,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP17)
acpiprt5 at acpi0: bus -1 (RP18)
acpiprt6 at acpi0: bus -1 (RP19)
acpiprt7 at acpi0: bus -1 (RP20)
acpiprt8 at acpi0: bus 1 (RP01)
acpiprt9 at acpi0: bus 2 (RP02)
acpiprt10 at acpi0: bus -1 (RP03)
acpiprt11 at acpi0: bus -1 (RP04)
acpiprt12 at acpi0: bus -1 (RP05)
acpiprt13 at acpi0: bus -1 (RP06)
acpiprt14 at acpi0: bus -1 (RP07)
acpiprt15 at acpi0: bus -1 (RP08)
acpiprt16 at acpi0: bus 3 

Re: cwm: remove ssh auto-completion

[Olivier Cherrier]

On Fri, Jul 07, 2017 at 12:44:35PM -0400, o...@demirmen.com wrote:
> Hi cwm users,
> 
> In converting this to use getline(3) over fgetln(3), I'm asking the question 
> if
> this (imho) mis-feature belongs in a window manager. I've hinted at wanting to
> remove it in the past but there was opposition.  As a compromise, we could 
> just
> leave the 'ssh>' menu available, but it will not be pre-populated (nor
> auto-completed) by what's in ~/.ssh/known_hosts; just type in the
> host/ip/whatever at the menu prompt. cwm(1) does a very rudimentary pass at
> parsing the known_hosts file, and there's no reason to hoist code from ssh(1)
> just to get auto-completion in a window manager menu.
> 
> Below is the minimal code part in kbfunc_menu_ssh().
> 
> Preferably, I'd like to remove the whole ssh menu, but can live with the below
> if it's useful to others.
> 
> Thoughts?

Hi Okan,

I use it alot and find it very light and useful.

Thanks,
Best
Olivier

Re: 11n support for athn(4)

[Olivier Cherrier]

N BIT MAPS (SALVAGED)
/dev/wd0e (9a03e090a85ec7ef.e): 686 files, 73701 used, 531330 free (482 frags, 
66356 blocks, 0.1% fragmentation)
/dev/wd0e (9a03e090a85ec7ef.e): MARKING FILE SYSTEM CLEAN
mount_mfs: reduced number of fragments per cylinder group from 16880 to 16744 
to enlarge last cylinder group
setting tty flags
pf enabled
net.inet.ip.forwarding: 0 -> 1
net.inet6.ip6.forwarding: 0 -> 1
starting network
reordering libraries: done.
starting early daemons: syslogd pflogd nsd unbound ntpd.
starting RPC daemons:.
savecore: no core dump
acpidump: Can't find ACPI information
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd dhcpd smtpd ftpproxy sndiod.
starting package daemons: pflogd1(failed).
starting local daemons: cron.
Sun Jan 15 23:06:28 CET 2017

OpenBSD/i386 (alix.symacx.com) (tty00)

login: 

Script done on Mon Dec 26 11:57:53 2016



Thank you,
Best

-- 
Olivier Cherrier
Phone: +352691754777
mailto:o...@symacx.com

Re: pool related crashes, but "kernel did no panic"

[Olivier Cherrier]

On Wed, Apr 27, 2016 at 09:13:40AM +, alexey.susli...@gmail.com wrote:
> Hi tech@.
> 
> (Maybe related to http://marc.info/?l=openbsd-bugs=146174654219490=2).
 
;-)

> Crashing server acts as a carp backup (master has same hardware config but
> don't crash, in contrast to backup). Will post additional information if
> necessary.

In my case, the server is acting as a backup for 2 carp devices and also
as a master for 2 other carp devices.
But indeed, it is always the same node (part of a 2 nodes setup) that is
crashing.  This node just crached again a few minutes ago. It seems
upgrading it to 5.9 makes the bug more frequent. So I am keeping the
other node with «OpenBSD 5.8-current (GENERIC.MP) #1661: Tue Nov 24
20:16:36 MST 2015» for now.


Here is frech output:

ddb{2}> trace
Debugger() at Debugger+0x9
panic() at panic+0xfe
pool_runqueue() at pool_runqueue
pool_get() at pool_get+0xb5
m_clget() at m_clget+0x51
m_dup_pkt() at m_dup_pkt+0x88
carp_input() at carp_input+0x17c
if_input_process() at if_input_process+0xcd
taskq_thread() at taskq_thread+0x6c
end trace frame: 0x0, count: -9
ddb{2}> show panic
pool_do_get: mcl2k free list modified: page 0xff00f1ec7000; item
addr 0xfff
fff00f1eca800; offset 0x0=0x0 != 0xaaa0cffd8d1e5cb4
ddb{2}> show register
rdi  0x1
rsi0x292
rbp   0x800022519b50
rbx   0x817195a0systqmp+0x1860
rdx0
rcx   0x8004f000
rax  0x1
r80x800022519a70
r9 0
r10   0x800022519a20
r11  0x8
r120x100
r13   0x800022519b60
r14  0x2
r15  0x2
rip   0x81349a09Debugger+0x9
cs   0x8
rflags 0x282
rsp   0x800022519b40
ss  0x10
Debugger+0x9:   leave
ddb{2}>


--
oc

Re: smu(4) fan speed

[Olivier Cherrier]

On Sun, Apr 17, 2016 at 07:27:39AM +0200, mar...@nazgul.ch wrote:
> Thanks for pointing this out.  But my issue here happens even one step
> before, when the driver can't set the initial unmanage/safe/average
> value because on my machine this property is called 'safe-value' instead
> of 'unmanage-value'.  Could you send the eeprom -p of your machine as
> well?  I wonder if the property there is called 'unmanage-value' or
> 'unmanaged-value'.
 
Here it is (attached).

> Anyway, taken in to account of the 'safe-value' property as well, the
> below diff works perfectly fine in my case:
> 
>   $ sysctl -a | grep smu
>   hw.sensors.smu0.temp0=33.87 degC (CPU T-Diode)
>   hw.sensors.smu0.fan0=999 RPM (Rear Fan 0)
>   hw.sensors.smu0.fan1=1002 RPM (Rear fan 1)
>   hw.sensors.smu0.fan2=1002 RPM (Front Fan)
>   hw.sensors.smu0.volt0=12.17 VDC (CPU Voltage)
>   hw.sensors.smu0.power0=11.31 W (Slots Power)
>   hw.sensors.smu0.current0=1.07 A (CPU Current)
> 
> This diff doesn't change the current behaviour but takes 'safe-value'
> in to account.

With this diff, the fans go at their maximun speed and stay like that:
$ sysctl hw.sensors
hw.sensors.smu0.temp0=31.75 degC (CPU T-Diode)
hw.sensors.smu0.fan0=4018 RPM (System Fan)
hw.sensors.smu0.fan1=4018 RPM (CPU fan)
hw.sensors.smu0.fan2=4018 RPM (Hard Drive)
hw.sensors.smu0.volt0=11.88 VDC (CPU Voltage)
hw.sensors.smu0.current0=0.59 A (CPU Current)
hw.sensors.lmtemp0.temp0=31.00 degC

In this version (the patch you sent), nothing is responsible of setting the
fan speeds according to the temp; isn't it ?

Thanks,
Best

-- 
Olivier Cherrier
mailto:o...@symacx.com
Node 0xff88e0c0
model: 'PowerMac8,1'
compatible: 'PowerMac8,1' + 'MacRISC4' + 'Power Macintosh'
serial-number: 'PNZ' + 'W84431G7PNZ'
customer-sw-config: '   '
pid#: 0201
scb#: 0001
display-config-info: 0831.
name: 'device-tree'
copyright: 'Copyright 1983-2004 Apple Computer, Inc. All Rights Reserved'
device_type: 'bootrom'
system-id: '0'
#address-cells: 0002
#size-cells: 0001
clock-frequency: 10fcc140
AAPL,add-fcode-file: ff867be0
graphic-options: 0012

Node 0xff890a20
name: 'cpus'
#address-cells: 0001
#size-cells: 

Node 0xff890c88
name: 'PowerPC,G5'
device_type: 'cpu'
reg: 
cpu-version: 003c0300
cpu#: 
soft-reset: 0071
state: 'running'
clock-frequency: 6b49d200
bus-frequency: 23c34600
config-bus-frequency: 3b9aca00
timebase-frequency: 01fca055
reservation-granule-size: 0080
tlb-sets: 0100
tlb-size: 1000
d-cache-size: 8000
i-cache-size: 0001
d-cache-sets: 0080
i-cache-sets: 0200
i-cache-block-size: 0080
d-cache-block-size: 0080
graphics: 
performance-monitor: 
altivec: 
data-streams: 
dcbz: 0080
general-purpose: 
64-bit: 
32-64-bridge: 
existing: .8000.8000.8000
available: 3000.7fffd000.d000.2000
translations: 
.3000...0010.3000.1000..3000.0010.4000.1000..4000.0010.5000.3000..5000.0010.8000.5000..8000.0010.d000.5000..d000.0010.00012000.3000..00012000.0010.00015000.2000..00015000.0010.00017000.1000..00017000.0010.00018000.5000..00018000.0010.0001d000.1000..0001d000.0010.0002.0001a000..0002.0002.0010.00c0..0010.0010.8000.0008..8000.0028.80081000.1000..80081000.0028.80082000.1000..80082000.0028.8010.1000..8010.0028.80102000.2000..80102000.0028.80104000.4000..80104000.0028.8040.0020..8040.0028.9000.0002..9000.0028.9100.0100..9100.0028.a000.0800..a000.0028.f000.0001..f000.0028.f080.1000..f080.0028.f0c0.1000..f0c0.0028.f200.0280..f200.0028.f400.0040..f400.0028.f800.0100..f800.0028.f807.1000..f807.0028.ff7f.0001..1fbf.0010.ff80.0040..1fc0.0010.fff04000.00

Re: smu(4) fan speed

[Olivier Cherrier]

On Sat, Apr 16, 2016 at 08:11:27PM +0200, mar...@nazgul.ch wrote:
> On Sat, Apr 16, 2016 at 07:34:59PM +0200, Mark Kettenis wrote:
> 
> > > Date: Fri, 15 Apr 2016 20:41:53 +0200
> > > From: Marcus Glocker 
> > > 
> > > Yesterday I've installed macppc -current on a G5.
> > > Since OF_getprop() for the 'unmanage-value' parameter fails on it,
> > > smu(4) sets the fan speed to 'max-value' instead, which is 3200RPM
> > > in my case.  This makes the G5 sound louder than my vacuum cleaner.
> > > 
> > > First I thought 'unmanage-value' is a typo and it should be
> > > 'unmanaged-value' like in the FreeBSD driver, but unfortunately it
> > > still did fail.  I saw that the FreeBSD driver doesn't set the fan
> > > speed at all initially in their driver.  When I do the same on the
> > > G5, the fan speed goes to a decent of ~1000RPM:
> > > 
> > >   hw.sensors.smu0.fan0=999 RPM (Rear Fan 0)
> > >   hw.sensors.smu0.fan1=999 RPM (Rear fan 1)
> > >   hw.sensors.smu0.fan2=999 RPM (Front Fan)
> > > 
> > > I don't know what the right way is to fix this, but skipping to set
> > > the fan speed when the 'unmanage-value' isn't available seems to work
> > > fine in this case.
> > 
> > On what hardware are you running this?
> 
> model: 'PowerMac9,1'
> compatible: 'PowerMac9,1' + 'MacRISC4' + 'Power Macintosh'
> 

And what about trying this ?

http://marc.info/?t=14542807061=1=2

(It works well for the iMac G5).

Thanks,
Best
oc

Re: fan control on macppc G5 smu

[Olivier Cherrier]

On Fri, Mar 18, 2016 at 01:02:43PM +0100, m...@openbsd.org wrote:
> 
> Could you test the diff below and tell me if it also helps?  It is
> adapted from a submission from Dominic Marks:
>   https://marc.info/?l=openbsd-ppc=142836014007157=2
 
Indeed it does more or less the same thing.
So, it helps.


But I would say it doesn't slow down enough the fan speed to be really
silent when the machine is idle.


For instance, with the patch I sent (when idle) :
hw.sensors.smu0.temp0=39.19 degC (CPU T-Diode)
hw.sensors.smu0.fan0=1128 RPM (System Fan)
hw.sensors.smu0.fan1=1128 RPM (CPU fan)
hw.sensors.smu0.fan2=1128 RPM (Hard Drive)
hw.sensors.smu0.volt0=11.88 VDC (CPU Voltage)
hw.sensors.smu0.current0=0.62 A (CPU Current)
hw.sensors.lmtemp0.temp0=33.00 degC

With a speed around 1100 RPM, it is almost silent and it is similar as if
it were running MacOS X.


With the patch you sent, we get (when idle) :
hw.sensors.smu0.temp0=39.02 degC (CPU T-Diode)
hw.sensors.smu0.fan0=1520 RPM (System Fan)
hw.sensors.smu0.fan1=1520 RPM (CPU fan)
hw.sensors.smu0.fan2=1520 RPM (Hard Drive)
hw.sensors.smu0.volt0=11.88 VDC (CPU Voltage)
hw.sensors.smu0.current0=0.62 A (CPU Current)
hw.sensors.lmtemp0.temp0=37.00 degC
... and it's a bit noisy and borring on a desk.


Maybe CPU_TEMP_MIN could be bumped a little bit ?


Thanks !
Best
oc

Re: Testers needed for softraid diff

[Olivier Cherrier]

 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-5300CL5
iic1 at nviic0
ohci0 at pci0 dev 2 function 0 NVIDIA nForce4 USB rev 0xa2: apic 2 int 12, 
version 1.0, legacy support
ehci0 at pci0 dev 2 function 1 NVIDIA nForce4 USB rev 0xa4: apic 2 int 10
ehci0: timed out waiting for BIOS
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 NVIDIA EHCI root hub rev 2.00/1.00 addr 1
auich0 at pci0 dev 4 function 0 NVIDIA nForce4 AC97 rev 0xa2: apic 2 int 5, 
nForce4 AC97
ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0)
audio0 at auich0
pciide0 at pci0 dev 6 function 0 NVIDIA nForce4 IDE rev 0xf3: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 7 function 0 NVIDIA nForce4 SATA rev 0xf3: DMA
pciide1: using apic 2 int 11 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: ST3320620AS
wd0: 16-sector PIO, LBA48, 305245MB, 625142448 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
wd1 at pciide1 channel 1 drive 0: ST3320620AS
wd1: 16-sector PIO, LBA48, 305245MB, 625142448 sectors
wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 6
pciide2 at pci0 dev 8 function 0 NVIDIA nForce4 SATA rev 0xf3: DMA
pciide2: using apic 2 int 10 for native-PCI interrupt
wd2 at pciide2 channel 1 drive 0: WDC WD20EARS-00MVWB0
wd2: 16-sector PIO, LBA48, 1907729MB, 3907029168 sectors
wd2(pciide2:1:0): using PIO mode 4, Ultra-DMA mode 6
ppb0 at pci0 dev 9 function 0 NVIDIA nForce4 PCI-PCI rev 0xa2
pci1 at ppb0 bus 1
nfe0 at pci0 dev 10 function 0 NVIDIA CK804 LAN rev 0xa3: apic 2 int 11, 
address 00:04:61:46:d6:1e
eephy0 at nfe0 phy 1: 88E1116 Gigabit PHY, rev. 1
ppb1 at pci0 dev 11 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci2 at ppb1 bus 2
ppb2 at pci0 dev 12 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci3 at ppb2 bus 3
ppb3 at pci0 dev 13 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci4 at ppb3 bus 4
ppb4 at pci0 dev 14 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci5 at ppb4 bus 5
vga1 at pci5 dev 0 function 0 ATI Radeon HD 4350 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 2 int 12
drm0 at radeondrm0
azalia0 at pci5 dev 0 function 1 ATI Radeon HD 4000 HD Audio rev 0x00: apic 2 
int 3
azalia0: no supported codecs
pchb0 at pci0 dev 24 function 0 AMD AMD64 0Fh HyperTransport rev 0x00
pchb1 at pci0 dev 24 function 1 AMD AMD64 0Fh Address Map rev 0x00
pchb2 at pci0 dev 24 function 2 AMD AMD64 0Fh DRAM Cfg rev 0x00
kate0 at pci0 dev 24 function 3 AMD AMD64 0Fh Misc Cfg rev 0x00: core rev 
BH-F2
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: probed fifo depth: 15 bytes
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 NVIDIA OHCI root hub rev 1.00/1.00 addr 1
mtrr: Pentium Pro MTRR support
uhidev0 at uhub1 port 1 configuration 1 interface 0 Sun Microsystems Type 6 
Mouse rev 1.00/1.02 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons
wsmouse0 at ums0 mux 0
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
scsibus1 at softraid0: 256 targets
softraid0: not all chunks were provided; attempting to bring volume 0 online
softraid0: trying to bring up sd0 degraded
sd0 at scsibus1 targ 0 lun 0: OPENBSD, SR RAID 1, 004 SCSI2 0/direct fixed
sd0: 305082MB, 512 bytes/sec, 624809665 sec total
sd1 at scsibus1 targ 1 lun 0: OPENBSD, SR RAID 1, 004 SCSI2 0/direct fixed
sd1: 305082MB, 512 bytes/sec, 624809072 sec total
root on wd0a swap on wd0b dump on wd0b


Thanks,

-- 
Olivier Cherrier - Symacx.com
mailto:o...@symacx.com

Re: namecache diff - again

[Olivier Cherrier]

On Mon, Aug 10, 2009 at 11:43:34AM -0600, b...@openbsd.org wrote:
   After having fast recycle kick my butt for two days finding
 vnode reuse bugs.. here is the new diff. this does appear stable on 
 my machines.
 
   Note that it disables some functionality in procmap, temporarily,
 although looking at it it may have already been pre-broken. miod has
 promised to revisit this with me later.
 
   Please test for me. and let know what arch'es you ran on.

Hi,

I tested it on one machine (sparc64). It crashes on boot. Here is the
dmesg.boot which contains trace of ddb.

Thanks,

-- 
Olivier Cherrier - Symacx.com
mailto:o...@symacx.com
console is keyboard/display
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2009 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.6-current (GENERIC) #2: Mon Sep 15 22:59:32 CEST 2008
o...@blade1000.symacx.com:/usr/src/sys/arch/sparc64/compile/GENERIC
real mem = 2147483648 (2048MB)
avail mem = 2069307392 (1973MB)
mainbus0 at root: SUNW,Sun-Blade-1000 (UltraSPARC-III) 
cpu0 at mainbus0: SUNW,UltraSPARC-III (rev 5.4) @ 750 MHz
cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 8192K external (512 
b/l)
memory-controller at mainbus0 not configured
schizo0 at mainbus0: Schizo, version 4, ign 200, bus B 0 to 0
schizo0: dvma map c000-
pci0 at schizo0
ebus0 at pci0 dev 5 function 0 Sun RIO EBus rev 0x01
flashprom at ebus0 addr 0-1f not configured
bbc0 at ebus0 addr 0-f: AID 0x00
ppm0 at ebus0 addr e-28, 728000-728003, 30002e-30002f, 300600-300607
pcfiic0 at ebus0 addr 2e-2f, 2d-2d ivec 0x23
iic0 at pcfiic0
pcfiic1 at ebus0 addr 30-31 ivec 0x23
iic1 at pcfiic1
admtemp0 at iic1 addr 0x18: max1617
tda0 at iic1 addr 0x24
scm001 at iic1 addr 0x20 not configured
firei at iic1 addr 0x30 not configured
beep0 at ebus0 addr 32-37: clock 75MHz
audioce0 at ebus0 addr 20-2000ff, 702000-70200f, 704000-70400f, 
722000-722003 ivec 0x20 ivec 0x21: nvaddrs 0
audio0 at audioce0
rtc0 at ebus0 addr 300070-300071 ivec 0x24: ds1287
gpio at ebus0 addr 300600-300607 not configured
pmc0 at ebus0 addr 300700-300701
floppy at ebus0 addr 3023f0-3023f7, 706000-70600f, 72-720003 ivec 0x25 
not configured
lpt0 at ebus0 addr 300278-300287, 30002e-30002f, 70-7f ivec 0x1c: polled
sab0 at ebus0 addr 40-40007f ivec 0x22: rev 3.2
sabtty0 at sab0 port 0
sabtty1 at sab0 port 1
gem0 at pci0 dev 5 function 1 Sun ERI Ether rev 0x01: ivec 0x21d, address 
00:03:ba:02:92:09
luphy0 at gem0 phy 1: LU6612 10/100 PHY, rev. 1
Sun FireWire rev 0x01 at pci0 dev 5 function 2 not configured
ohci0 at pci0 dev 5 function 3 Sun USB rev 0x01: ivec 0x21f, version 1.0, 
legacy support
siop0 at pci0 dev 6 function 0 Symbios Logic 53c875 rev 0x37: ivec 0x218, 
using 4K of on-board RAM
scsibus0 at siop0: 16 targets, initiator 7
st0 at scsibus0 targ 4 lun 0: EXABYTE, EXB-8505SMBANSH2, 07T0 SCSI2 
1/sequential removable
siop1 at pci0 dev 6 function 1 Symbios Logic 53c875 rev 0x37: ivec 0x219, 
using 4K of on-board RAM
scsibus1 at siop1: 16 targets, initiator 7
sd0 at scsibus1 targ 1 lun 0: FUJITSU, MAB3045S SUN4.2G, 1705 SCSI2 0/direct 
fixed
sd0: 4094MB, 512 bytes/sec, 8385121 sec total
sd1 at scsibus1 targ 2 lun 0: FUJITSU, MAG3091L SUN9.0G,  SCSI2 0/direct 
fixed
sd1: 8637MB, 512 bytes/sec, 17689267 sec total
sd2 at scsibus1 targ 4 lun 0: IBM-PCCO, DDRS-34560Y !#, S97B SCSI2 0/direct 
fixed
sd2: 4303MB, 512 bytes/sec, 8813870 sec total
sd3 at scsibus1 targ 5 lun 0: IBM-PCCO, DDRS-34560Y !#, S97B SCSI2 0/direct 
fixed
sd3: 4303MB, 512 bytes/sec, 8813870 sec total
sd4 at scsibus1 targ 6 lun 0: FUJITSU, MAB3045S SUN4.2G, 1705 SCSI2 0/direct 
fixed
sd4: 4094MB, 512 bytes/sec, 8385121 sec total
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 Sun OHCI root hub rev 1.00/1.00 addr 1
schizo1 at mainbus0: Schizo, version 4, ign 200, bus A 0 to 0
schizo1: dvma map c000-
pci1 at schizo1
isp0 at pci1 dev 4 function 0 QLogic ISP2200 rev 0x05: ivec 0x204
isp0: Board Type 2200, Chip Revision 0x5, loaded F/W Revision 2.2.6
scsibus2 at isp0: 512 targets, WWPN 2103ba029209, WWNN 2103ba029209
sd5 at scsibus2 targ 0 lun 0: SEAGATE, ST318304FSUN18G, 0726 SCSI3 0/direct 
fixed
sd5: 17274MB, 512 bytes/sec, 35378533 sec total
sd6 at scsibus2 targ 1 lun 0: SEAGATE, ST318304FSUN18G, 0726 SCSI3 0/direct 
fixed
sd6: 17274MB, 512 bytes/sec, 35378533 sec total
upa0 at mainbus0
creator0 at upa0: Elite3D, model SUNW,540-3623, dac 0
wsdisplay0 at creator0 mux 1: console (std, sun emulation)
ppm at mainbus0 not configured
uhidev0 at uhub0 port 1 configuration 1 interface 0 Sun Microsystems Type 6 
Mouse rev 1.00/1.02 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons
wsmouse0 at ums0 mux 0
uhidev1 at uhub0 port 2 configuration 1 interface 0 Sun Microsystems Type 6 
Keyboard rev 1.00/1.01 addr 3
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 modifier keys, 6 key codes, country code 33

Re: VIA EHCI controller workaround needs testing.

[Olivier Cherrier]

On Mon, Jun 29, 2009 at 03:46:35PM -0400, b...@comstyle.com wrote:
 The following diff adds a workaround for an issue with the VIA VT6202
 EHCI controller hogging the PCI bus and causing poor performance for
 IDE and possibly other devices in the system.
 
 Please test if your system has a VIA VT6202 EHCI controller and
 provide a dmesg. If the workaround is being applied for the
 chipset you have then a message will be printed (this is temporary
 only to verify it is being applied for the appropriate revision
 of the chipset).
 
Hi,

On this via board which is equiped with a VIA VT6202 EHCI controller it 
does not seem to recognize it.
(Current kernel with your diff applied).

-- 
Olivier Cherrier
mailto:o...@symacx.com
Domain /dev/pci0:
 0:0:0: VIA CN700 Host
0x: Vendor ID: 1106 Product ID: 0314
0x0004: Command: 0006 Status ID: 2230
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00
0x000c: BIST: 00 Header Type: 80 Latency Timer: 08 Cache Line Size: 00
0x0010: BAR mem prefetchable 32bit addr: 0xe800
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1106 Product ID: 0314
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
0x0080: Capability 0x02: AGP
0x0050: Capability 0x01: Power Management
 0:0:1: VIA CN700 Host
0x: Vendor ID: 1106 Product ID: 1314
0x0004: Command: 0006 Status ID: 0200
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID:  Product ID: 
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
 0:0:2: VIA CN700 Host
0x: Vendor ID: 1106 Product ID: 2314
0x0004: Command: 0006 Status ID: 0200
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID:  Product ID: 
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
 0:0:3: VIA PT890 Host
0x: Vendor ID: 1106 Product ID: 3208
0x0004: Command: 0006 Status ID: 0200
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID:  Product ID: 
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
 0:0:4: VIA CN700 Host
0x: Vendor ID: 1106 Product ID: 4314
0x0004: Command: 0006 Status ID: 0200
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID:  Product ID: 
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
 0:0:7: VIA CN700 Host
0x: Vendor ID: 1106 Product ID: 7314
0x0004: Command: 0006 Status ID: 0200
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty (

Re: rl(4) diff for promisc mode/multicast code needs testing.

[Olivier Cherrier]

nfs_boot: server_addr=192.168.1.2 hostname=esther
root on c3:/home/esther
nfs_boot: bootparam get swap: 60
WARNING: no swap
swapmount: no device


-- 
Olivier Cherrier
mailto:o...@symacx.com