Re: -Wshorten-64-to-32
On Wed, Apr 03, 2013 at 02:16:30PM +0100, Pedro Martelletto wrote: > Hi, > > Apple has added a -Wshorten-64-to-32 option to GCC. It generates a > warning if a value is implicitly converted from a 64-bit to a 32-bit > type. I found it useful, looked at the code and ported it to OpenBSD. > > I don't think this is worth integrating. Use at your own discretion. :) clang comes with -Wshorten-64-to-32 as well, not included as part of -Wall but is with -Weverything.
time_t in icmp6
Hi, This makes icmp6 ready for 64 bit time_t by adding a range check and an explicit cast. ok? bluhm Index: netinet6/icmp6.c === RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/icmp6.c,v retrieving revision 1.123 diff -u -p -r1.123 icmp6.c --- netinet6/icmp6.c28 Mar 2013 16:45:16 - 1.123 +++ netinet6/icmp6.c3 Apr 2013 22:13:36 - @@ -1819,11 +1819,15 @@ ni6_store_addrs(struct icmp6_nodeinfo *n if (ifa6->ia6_lifetime.ia6t_expire == 0) ltime = ND6_INFINITE_LIFETIME; else { - if (ifa6->ia6_lifetime.ia6t_expire > - time_second) - ltime = htonl(ifa6->ia6_lifetime.ia6t_expire - time_second); - else + time_t diff = ifa6->ia6_lifetime.ia6t_expire - + time_second; + + if (diff <= 0) ltime = 0; + else if (diff >= ND6_INFINITE_LIFETIME) + ltime = ND6_INFINITE_LIFETIME; + else + ltime = htonl((u_int32_t)diff); } bcopy(
Re: 5.3 -current installation problem
Quoting Mark Kettenis : Date: Wed, 03 Apr 2013 14:07:24 -0400 From: RD Thrush I have a similar problem which results in a panic (dmesg appended). This machine has a radeon (asus 7770) pcie adapter in addition to the integrated intel hd4000. The latter adapter seems to elicit the panic. If I set the bios to make the hd4000 the primary display, the panic will repeatably occur. vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: apic 2 int 16 extent_create: extent `agpgtt', start 0xd000, end 0xdfffefff Can you send me a dmesg from a kernel that has the diff below in it? Index: agp_i810.c === RCS file: /cvs/src/sys/dev/pci/agp_i810.c,v retrieving revision 1.74 diff -u -p -r1.74 agp_i810.c --- agp_i810.c 18 Mar 2013 12:02:56 - 1.74 +++ agp_i810.c 3 Apr 2013 20:20:49 - @@ -572,13 +572,13 @@ agp_i810_attach(struct device *parent, s goto out; } -#ifdef DEBUG +//#ifdef DEBUG if (isc->stolen > 0) { printf(": detected %dk stolen memory", isc->stolen * 4); } else printf(": no preallocated video memory\n"); -#endif +//#endif /* GATT address is already in there, make sure it's enabled */ gatt->ag_physical = READ4(AGP_I810_PGTBL_CTL) & ~1; $ sysctl kern.version kern.version=OpenBSD 5.3-current (GENERIC.MP) #0: Wed Apr 3 16:02:34 CDT 2013 r...@server4.foretell.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP Thanks very much. Here is the dmesg with your patch. Hope this is useful. Vijay Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9 OpenBSD 5.3-current (GENERIC.MP) #0: Wed Apr 3 16:02:34 CDT 2013 r...@server4.foretell.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8246112256 (7864MB) avail mem = 8018894848 (7647MB) User Kernel Config UKC> disable inteldrm 4 inteldrm* disabled UKC> quit Continuing... mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb8c0 (104 entries) bios0: vendor American Megatrends Inc. version "0804" date 10/15/2012 bios0: ASUSTeK COMPUTER INC. P8H77-M acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) P0P1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4) PWRB(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-2700K CPU @ 3.50GHz, 3500.35 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,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz, 3499.89 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,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz, 3499.89 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,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz, 3499.89 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,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz, 3499.89 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,NXE,LONG,LAHF,PERF,ITSC cpu4:
Re: Show only usable commands in rc.subr usage
This makes a lot of sense to me. Penned by Vadim Zhukov on 20130403 12:59.08, we have: | Third iteration, after input from ajacoutot@, todd@ and marc@. | | Now rc_restart becomes unavailable if either start or stop is disabled. | | | Index: rc.subr | === | RCS file: /cvs/src/etc/rc.d/rc.subr,v | retrieving revision 1.68 | diff -u -p -r1.68 rc.subr | --- rc.subr 19 Nov 2012 07:10:59 - 1.68 | +++ rc.subr 3 Apr 2013 17:55:00 - | @@ -24,8 +24,18 @@ rc_err() { | exit 1 | } | | +rc_is_supported() { | + local _enotsup | + eval _enotsup=\${rc_${1}} | + [ X"${_enotsup}" != X"NO" ] | +} | + | rc_usage() { | - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" | + local _a _allsup | + for _a in start stop restart reload check; do | + rc_is_supported ${_a} && _allsup="${_allsup:+$_allsup|}${_a}" | + done | + rc_err "usage: $0 [-df] (${_allsup})" | } | | rc_write_runfile() { | @@ -95,14 +105,17 @@ rc_wait() { | } | | rc_cmd() { | - local _bg _enotsup _n | + local _bg _n | | [ "$(id -u)" -eq 0 ] || \ | [ X"${rc_usercheck}" != X"NO" -a X"$1" = "Xcheck" ] || \ | rc_err "$0: need root privileges" | | - eval _enotsup=\${rc_${1}} | - if [ X"${_enotsup}" = X"NO" ]; then | + if ! (rc_is_supported start && rc_is_supported stop); then | + rc_restart=NO | + fi | + | + if ! rc_is_supported $1; then | [ -n "${INRC}" ] && exit 1 | rc_err "$0: $1 is not supported" | fi -- Todd Fries .. t...@fries.net |\ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net | "..in support of free software solutions." \ sip:4052279...@ekiga.net \ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: 5.3 -current installation problem
> Date: Wed, 03 Apr 2013 14:07:24 -0400 > From: RD Thrush > > I have a similar problem which results in a panic (dmesg appended). > This machine has a radeon (asus 7770) pcie adapter in addition to > the integrated intel hd4000. The latter adapter seems to elicit the > panic. If I set the bios to make the hd4000 the primary display, > the panic will repeatably occur. > vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 > intagp0 at vga1 > agp0 at intagp0: aperture at 0xd000, size 0x1000 > inteldrm0 at vga1 > drm0 at inteldrm0 > inteldrm0: apic 2 int 16 > extent_create: extent `agpgtt', start 0xd000, end 0xdfffefff Can you send me a dmesg from a kernel that has the diff below in it? Index: agp_i810.c === RCS file: /cvs/src/sys/dev/pci/agp_i810.c,v retrieving revision 1.74 diff -u -p -r1.74 agp_i810.c --- agp_i810.c 18 Mar 2013 12:02:56 - 1.74 +++ agp_i810.c 3 Apr 2013 20:20:49 - @@ -572,13 +572,13 @@ agp_i810_attach(struct device *parent, s goto out; } -#ifdef DEBUG +//#ifdef DEBUG if (isc->stolen > 0) { printf(": detected %dk stolen memory", isc->stolen * 4); } else printf(": no preallocated video memory\n"); -#endif +//#endif /* GATT address is already in there, make sure it's enabled */ gatt->ag_physical = READ4(AGP_I810_PGTBL_CTL) & ~1;
Re: Show only usable commands in rc.subr usage
Vadim Zhukov wrote: >Third iteration, after input from ajacoutot@, todd@ and marc@. > >Now rc_restart becomes unavailable if either start or stop is disabled. > > >Index: rc.subr >=== >RCS file: /cvs/src/etc/rc.d/rc.subr,v >retrieving revision 1.68 >diff -u -p -r1.68 rc.subr >--- rc.subr19 Nov 2012 07:10:59 - 1.68 >+++ rc.subr3 Apr 2013 17:55:00 - >@@ -24,8 +24,18 @@ rc_err() { > exit 1 > } > >+rc_is_supported() { >+ local _enotsup >+ eval _enotsup=\${rc_${1}} ${1} just hurts my eyes too much... :-) Bikeshedding my way. Tin roof. /A >+ [ X"${_enotsup}" != X"NO" ] >+} >+ > rc_usage() { >- rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" >+ local _a _allsup >+ for _a in start stop restart reload check; do >+ rc_is_supported ${_a} && _allsup="${_allsup:+$_allsup|}${_a}" >+ done >+ rc_err "usage: $0 [-df] (${_allsup})" > } > > rc_write_runfile() { >@@ -95,14 +105,17 @@ rc_wait() { > } > > rc_cmd() { >- local _bg _enotsup _n >+ local _bg _n > > [ "$(id -u)" -eq 0 ] || \ > [ X"${rc_usercheck}" != X"NO" -a X"$1" = "Xcheck" ] || \ > rc_err "$0: need root privileges" > >- eval _enotsup=\${rc_${1}} >- if [ X"${_enotsup}" = X"NO" ]; then >+ if ! (rc_is_supported start && rc_is_supported stop); then >+ rc_restart=NO >+ fi >+ >+ if ! rc_is_supported $1; then > [ -n "${INRC}" ] && exit 1 > rc_err "$0: $1 is not supported" > fi
Re: 5.3 -current installation problem
On 04/03/13 09:52, Mark Kettenis wrote: >> Date: Wed, 3 Apr 2013 14:08:20 +0100 >> From: Stuart Henderson >> >> moving this to tech@ - original message with dmesg is at >> http://marc.info/?l=openbsd-misc&m=136498447228598&w=2 - summary: >> asus P8H77-M, intel 7 series chipset, "Intel HD Graphics 3000" >> running i386 or amd64, fails during boot with recent kernels unless >> inteldrm disabled. > > /var/log/Xorg.0.log, from before you upgraded the machine, might > provide us some clues. And defenitely also provide pcidump -vxx output. > > But ultimately having serial console output is pretty much a > requirement for being able to debug this properly. I have a similar problem which results in a panic (dmesg appended). This machine has a radeon (asus 7770) pcie adapter in addition to the integrated intel hd4000. The latter adapter seems to elicit the panic. If I set the bios to make the hd4000 the primary display, the panic will repeatably occur. I have also appended pcidump -vxx when the bios primary adapter is *not* set to the hd4000. X will run on the radeon adapter in vesa mode. I can provide the associated Xorg.0.log. ## serial console - dmesg including panic ## booting hd0a:bsd: 6049532+1730828+1021088+0+639040 [80+550560+367349]=0xde2528 entry point at 0x10001e0 [7205c766, 3404, 24448b12, 9978a304] [ using 918760 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.3-current (GENERIC.MP) #60: Tue Apr 2 18:53:53 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16818126848 (16039MB) avail mem = 16362725376 (15604MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba40 (112 entries) bios0: vendor American Megatrends Inc. version "1002" date 02/04/2013 bios0: ASUSTeK COMPUTER INC. P8Q77-M acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT BGRT DMAR ASF! acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(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) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(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-3770 CPU @ 3.40GHz, 3400.45 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu4: 256KB 64b/line 8-way L2 cache cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,A
Re: Show only usable commands in rc.subr usage
Third iteration, after input from ajacoutot@, todd@ and marc@. Now rc_restart becomes unavailable if either start or stop is disabled. Index: rc.subr === RCS file: /cvs/src/etc/rc.d/rc.subr,v retrieving revision 1.68 diff -u -p -r1.68 rc.subr --- rc.subr 19 Nov 2012 07:10:59 - 1.68 +++ rc.subr 3 Apr 2013 17:55:00 - @@ -24,8 +24,18 @@ rc_err() { exit 1 } +rc_is_supported() { + local _enotsup + eval _enotsup=\${rc_${1}} + [ X"${_enotsup}" != X"NO" ] +} + rc_usage() { - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" + local _a _allsup + for _a in start stop restart reload check; do + rc_is_supported ${_a} && _allsup="${_allsup:+$_allsup|}${_a}" + done + rc_err "usage: $0 [-df] (${_allsup})" } rc_write_runfile() { @@ -95,14 +105,17 @@ rc_wait() { } rc_cmd() { - local _bg _enotsup _n + local _bg _n [ "$(id -u)" -eq 0 ] || \ [ X"${rc_usercheck}" != X"NO" -a X"$1" = "Xcheck" ] || \ rc_err "$0: need root privileges" - eval _enotsup=\${rc_${1}} - if [ X"${_enotsup}" = X"NO" ]; then + if ! (rc_is_supported start && rc_is_supported stop); then + rc_restart=NO + fi + + if ! rc_is_supported $1; then [ -n "${INRC}" ] && exit 1 rc_err "$0: $1 is not supported" fi
Re: Show only usable commands in rc.subr usage
03.04.2013 21:30 пользователь "Todd T. Fries" написал: > > Penned by Antoine Jacoutot on 20130403 10:24.19, we have: > | On Wed, Apr 03, 2013 at 05:14:10PM +0200, Alexander Hall wrote: > | > On 04/03/13 13:42, Vadim Zhukov wrote: > | > > This patch makes rc.subr show only supported operations in usage. > | > > This avoids some sort of confusion when, e.g., /etc/rc.d/smtpd > | > > shows that "reload" command is allowed, but when you try it, > | > > you get "reload not supported" error. > | > > > | > > okay? > | > > | > I approve of the idea. Nits inline. > | > | No need to check for 'check' => this is a mandatory action. > | No need to check for 'restart' => it is 'start'+'stop' > > amd does not support stop. Good point. New diff is on the way. > | > >WBR, > | > > Vadim Zhukov > | > > > | > > > | > > Index: rc.subr > | > > === > | > > RCS file: /cvs/src/etc/rc.d/rc.subr,v > | > > retrieving revision 1.68 > | > > diff -u -p -r1.68 rc.subr > | > > --- rc.subr 19 Nov 2012 07:10:59 - 1.68 > | > > +++ rc.subr 3 Apr 2013 11:35:58 - > | > > @@ -25,7 +25,13 @@ rc_err() { > | > > } > | > > > | > > rc_usage() { > | > > - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" > | > > + local _a _allsup _enotsup > | > > + for _a in start check reload restart stop; do > | > > + eval _enotsup=\${rc_${_a}} > | > > + [ X"${_enotsup}" != X"NO" ] && _allsup="$_allsup $_a" > | > > | > maybe > | > [ X"${_enotsup}" != X"NO" ] && _allsup="${_allsup+$_allsup|}$_a" > | > > | > > + done > | > > | > > + _allsup="`echo $_allsup | sed -e 's/ /|/g'`" > | > > | > and skip the line above > | > > | > > + rc_err "usage: $0 [-df] {${_allsup}}" > | > > } > | > > > | > > rc_write_runfile() { > | > > > | > > | > Also, you mix $var and ${var} notation. While I prefer the former > | > unless ${...} is needed for clarity or functionality, we should at > | > least be consequent where possible. > | > > | > /Alexander > | > | -- > | Antoine > > -- > Todd Fries .. t...@fries.net > > > |\ 1.636.410.0632 (voice) > | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) > | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) > | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net > | "..in support of free software solutions." \ sip:4052279...@ekiga.net > \ > > 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A > http://todd.fries.net/pgp.txt
Re: Show only usable commands in rc.subr usage
On Wed, Apr 03, 2013 at 12:30:05PM -0500, Todd T. Fries wrote: > Penned by Antoine Jacoutot on 20130403 10:24.19, we have: > | On Wed, Apr 03, 2013 at 05:14:10PM +0200, Alexander Hall wrote: > | > On 04/03/13 13:42, Vadim Zhukov wrote: > | > > This patch makes rc.subr show only supported operations in usage. > | > > This avoids some sort of confusion when, e.g., /etc/rc.d/smtpd > | > > shows that "reload" command is allowed, but when you try it, > | > > you get "reload not supported" error. > | > > > | > > okay? > | > > | > I approve of the idea. Nits inline. > | > | No need to check for 'check' => this is a mandatory action. > | No need to check for 'restart' => it is 'start'+'stop' > > amd does not support stop. What does it have to do with anything? :) > > | > >WBR, > | > > Vadim Zhukov > | > > > | > > > | > > Index: rc.subr > | > > === > | > > RCS file: /cvs/src/etc/rc.d/rc.subr,v > | > > retrieving revision 1.68 > | > > diff -u -p -r1.68 rc.subr > | > > --- rc.subr 19 Nov 2012 07:10:59 - 1.68 > | > > +++ rc.subr 3 Apr 2013 11:35:58 - > | > > @@ -25,7 +25,13 @@ rc_err() { > | > > } > | > > > | > > rc_usage() { > | > > - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" > | > > + local _a _allsup _enotsup > | > > + for _a in start check reload restart stop; do > | > > + eval _enotsup=\${rc_${_a}} > | > > + [ X"${_enotsup}" != X"NO" ] && _allsup="$_allsup $_a" > | > > | > maybe > | > [ X"${_enotsup}" != X"NO" ] && _allsup="${_allsup+$_allsup|}$_a" > | > > | > > + done > | > > | > > + _allsup="`echo $_allsup | sed -e 's/ /|/g'`" > | > > | > and skip the line above > | > > | > > + rc_err "usage: $0 [-df] {${_allsup}}" > | > > } > | > > > | > > rc_write_runfile() { > | > > > | > > | > Also, you mix $var and ${var} notation. While I prefer the former > | > unless ${...} is needed for clarity or functionality, we should at > | > least be consequent where possible. > | > > | > /Alexander > | > | -- > | Antoine > > -- > Todd Fries .. t...@fries.net > > > |\ 1.636.410.0632 (voice) > | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) > | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) > | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net > | "..in support of free software solutions." \ sip:4052279...@ekiga.net > \ > > 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A > http://todd.fries.net/pgp.txt > -- Antoine
Re: Show only usable commands in rc.subr usage
Penned by Antoine Jacoutot on 20130403 10:24.19, we have: | On Wed, Apr 03, 2013 at 05:14:10PM +0200, Alexander Hall wrote: | > On 04/03/13 13:42, Vadim Zhukov wrote: | > > This patch makes rc.subr show only supported operations in usage. | > > This avoids some sort of confusion when, e.g., /etc/rc.d/smtpd | > > shows that "reload" command is allowed, but when you try it, | > > you get "reload not supported" error. | > > | > > okay? | > | > I approve of the idea. Nits inline. | | No need to check for 'check' => this is a mandatory action. | No need to check for 'restart' => it is 'start'+'stop' amd does not support stop. | > >WBR, | > > Vadim Zhukov | > > | > > | > > Index: rc.subr | > > === | > > RCS file: /cvs/src/etc/rc.d/rc.subr,v | > > retrieving revision 1.68 | > > diff -u -p -r1.68 rc.subr | > > --- rc.subr 19 Nov 2012 07:10:59 - 1.68 | > > +++ rc.subr 3 Apr 2013 11:35:58 - | > > @@ -25,7 +25,13 @@ rc_err() { | > > } | > > | > > rc_usage() { | > > - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" | > > + local _a _allsup _enotsup | > > + for _a in start check reload restart stop; do | > > + eval _enotsup=\${rc_${_a}} | > > + [ X"${_enotsup}" != X"NO" ] && _allsup="$_allsup $_a" | > | > maybe | > [ X"${_enotsup}" != X"NO" ] && _allsup="${_allsup+$_allsup|}$_a" | > | > > + done | > | > > + _allsup="`echo $_allsup | sed -e 's/ /|/g'`" | > | > and skip the line above | > | > > + rc_err "usage: $0 [-df] {${_allsup}}" | > > } | > > | > > rc_write_runfile() { | > > | > | > Also, you mix $var and ${var} notation. While I prefer the former | > unless ${...} is needed for clarity or functionality, we should at | > least be consequent where possible. | > | > /Alexander | | -- | Antoine -- Todd Fries .. t...@fries.net |\ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net | "..in support of free software solutions." \ sip:4052279...@ekiga.net \ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: Show only usable commands in rc.subr usage
On Wed, Apr 03, 2013 at 08:17:27PM +0400, Vadim Zhukov wrote: > Second iteration after input from halex@ (${...+} trick is cool!). ok aja@ with nitpicks Please sort the list this way: start, stop, restart, reload, check Please make the output this way: rc_err "usage: $0 [-df] (${_allsup})" i.e. {} -> () which is more standard imho > Index: rc.subr > === > RCS file: /cvs/src/etc/rc.d/rc.subr,v > retrieving revision 1.68 > diff -u -p -r1.68 rc.subr > --- rc.subr 19 Nov 2012 07:10:59 - 1.68 > +++ rc.subr 3 Apr 2013 15:50:32 - > @@ -25,7 +25,12 @@ rc_err() { > } > > rc_usage() { > - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" > + local _a _allsup _enotsup > + for _a in start check reload restart stop; do > + eval _enotsup=\${rc_${_a}} > + [ X"${_enotsup}" != X"NO" ] && > _allsup="${_allsup+$_allsup|}${_a}" > + done > + rc_err "usage: $0 [-df] {${_allsup}}" > } > > rc_write_runfile() { > -- Antoine
Re: Show only usable commands in rc.subr usage
Second iteration after input from halex@ (${...+} trick is cool!). Index: rc.subr === RCS file: /cvs/src/etc/rc.d/rc.subr,v retrieving revision 1.68 diff -u -p -r1.68 rc.subr --- rc.subr 19 Nov 2012 07:10:59 - 1.68 +++ rc.subr 3 Apr 2013 15:50:32 - @@ -25,7 +25,12 @@ rc_err() { } rc_usage() { - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" + local _a _allsup _enotsup + for _a in start check reload restart stop; do + eval _enotsup=\${rc_${_a}} + [ X"${_enotsup}" != X"NO" ] && _allsup="${_allsup+$_allsup|}${_a}" + done + rc_err "usage: $0 [-df] {${_allsup}}" } rc_write_runfile() {
Re: Show only usable commands in rc.subr usage
03.04.2013 19:24 пользователь "Antoine Jacoutot" написал: > > On Wed, Apr 03, 2013 at 05:14:10PM +0200, Alexander Hall wrote: > > On 04/03/13 13:42, Vadim Zhukov wrote: > > > This patch makes rc.subr show only supported operations in usage. > > > This avoids some sort of confusion when, e.g., /etc/rc.d/smtpd > > > shows that "reload" command is allowed, but when you try it, > > > you get "reload not supported" error. > > > > > > okay? > > > > I approve of the idea. Nits inline. I'll send a new diff ASAP. > No need to check for 'check' => this is a mandatory action. > No need to check for 'restart' => it is 'start'+'stop' I've took logic from the rc_cmd(), it doesn't go smart either. Should it be fixed, too? Should we add general explicit check (to rc_cmd()?) that "check" and "restart" are not disabled? > > >WBR, > > > Vadim Zhukov > > > > > > > > > Index: rc.subr > > > === > > > RCS file: /cvs/src/etc/rc.d/rc.subr,v > > > retrieving revision 1.68 > > > diff -u -p -r1.68 rc.subr > > > --- rc.subr 19 Nov 2012 07:10:59 - 1.68 > > > +++ rc.subr 3 Apr 2013 11:35:58 - > > > @@ -25,7 +25,13 @@ rc_err() { > > > } > > > > > > rc_usage() { > > > - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" > > > + local _a _allsup _enotsup > > > + for _a in start check reload restart stop; do > > > + eval _enotsup=\${rc_${_a}} > > > + [ X"${_enotsup}" != X"NO" ] && _allsup="$_allsup $_a" > > > > maybe > > [ X"${_enotsup}" != X"NO" ] && _allsup="${_allsup+$_allsup|}$_a" > > > > > + done > > > > > + _allsup="`echo $_allsup | sed -e 's/ /|/g'`" > > > > and skip the line above > > > > > + rc_err "usage: $0 [-df] {${_allsup}}" > > > } > > > > > > rc_write_runfile() { > > > > > > > Also, you mix $var and ${var} notation. While I prefer the former > > unless ${...} is needed for clarity or functionality, we should at > > least be consequent where possible. > > > > /Alexander > > -- > Antoine
Re: Show only usable commands in rc.subr usage
On Wed, Apr 03, 2013 at 05:14:10PM +0200, Alexander Hall wrote: > On 04/03/13 13:42, Vadim Zhukov wrote: > > This patch makes rc.subr show only supported operations in usage. > > This avoids some sort of confusion when, e.g., /etc/rc.d/smtpd > > shows that "reload" command is allowed, but when you try it, > > you get "reload not supported" error. > > > > okay? > > I approve of the idea. Nits inline. No need to check for 'check' => this is a mandatory action. No need to check for 'restart' => it is 'start'+'stop' > >WBR, > > Vadim Zhukov > > > > > > Index: rc.subr > > === > > RCS file: /cvs/src/etc/rc.d/rc.subr,v > > retrieving revision 1.68 > > diff -u -p -r1.68 rc.subr > > --- rc.subr 19 Nov 2012 07:10:59 - 1.68 > > +++ rc.subr 3 Apr 2013 11:35:58 - > > @@ -25,7 +25,13 @@ rc_err() { > > } > > > > rc_usage() { > > - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" > > + local _a _allsup _enotsup > > + for _a in start check reload restart stop; do > > + eval _enotsup=\${rc_${_a}} > > + [ X"${_enotsup}" != X"NO" ] && _allsup="$_allsup $_a" > > maybe > [ X"${_enotsup}" != X"NO" ] && _allsup="${_allsup+$_allsup|}$_a" > > > + done > > > + _allsup="`echo $_allsup | sed -e 's/ /|/g'`" > > and skip the line above > > > + rc_err "usage: $0 [-df] {${_allsup}}" > > } > > > > rc_write_runfile() { > > > > Also, you mix $var and ${var} notation. While I prefer the former > unless ${...} is needed for clarity or functionality, we should at > least be consequent where possible. > > /Alexander -- Antoine
Re: Show only usable commands in rc.subr usage
On 04/03/13 13:42, Vadim Zhukov wrote: > This patch makes rc.subr show only supported operations in usage. > This avoids some sort of confusion when, e.g., /etc/rc.d/smtpd > shows that "reload" command is allowed, but when you try it, > you get "reload not supported" error. > > okay? I approve of the idea. Nits inline. > -- >WBR, > Vadim Zhukov > > > Index: rc.subr > === > RCS file: /cvs/src/etc/rc.d/rc.subr,v > retrieving revision 1.68 > diff -u -p -r1.68 rc.subr > --- rc.subr 19 Nov 2012 07:10:59 - 1.68 > +++ rc.subr 3 Apr 2013 11:35:58 - > @@ -25,7 +25,13 @@ rc_err() { > } > > rc_usage() { > - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" > + local _a _allsup _enotsup > + for _a in start check reload restart stop; do > + eval _enotsup=\${rc_${_a}} > + [ X"${_enotsup}" != X"NO" ] && _allsup="$_allsup $_a" maybe [ X"${_enotsup}" != X"NO" ] && _allsup="${_allsup+$_allsup|}$_a" > + done > + _allsup="`echo $_allsup | sed -e 's/ /|/g'`" and skip the line above > + rc_err "usage: $0 [-df] {${_allsup}}" > } > > rc_write_runfile() { > Also, you mix $var and ${var} notation. While I prefer the former unless ${...} is needed for clarity or functionality, we should at least be consequent where possible. /Alexander
Re: carp init delay
On 4/3/13 3:54 PM, Stuart Henderson wrote: On 2013/04/03 15:43, Camiel Dobbelaar wrote: On 4/3/13 3:34 PM, Stuart Henderson wrote: In some cases when a network port comes up, it does not indicate that the network is ready. But on linkup, carp(4) will try to get out of the INIT state as soon as possible. And because all is quiet it will decide to become master. Anyone else observe/fix this by other means? Opinions? slightly messy, though at least this also applies to the case with things other than carp which could also have problems: add "!sleep 5" or something in hostname.if for the physical interface... Yes, I already use that. That solves the case where the system with the carp interfaces itself is rebooted. But not the other cases. Hence I'd like that sleep applied always, instead of only when /etc/netstart is run. :-) Ah, I see what you mean. Still there are things other than carp where this might also apply - for example the pfsync initial_bulk that gets handled via if_linkstatehooks (but maybe also userland things).. Pausing carp may help the pfsync case too? Wasn't the major problem there caused by the freshly booted backup going to master too soon and cancelling the bulk update?
Re: carp init delay
When the system with the carp interfaces comes up, a sleep in the hostname.if file works. An arping might be an optimization of that. But I'd like carp to react properly to events *outside* the system. When I unplug/plug a network cable, spanning tree can kick in again on the switch. *Then* I'd like carp to pause. Or the example I mentioned earlier when a switch is powered off and on. I think handling that belongs in the kernel, and not some userland voodoo (ifstated/cron scripts) to clean it up. :-) On 4/3/13 3:37 PM, sven falempin wrote: my 2 cents: timing is always a problem, maybe you could arping the next hop and then activate the carp ? On Wed, Apr 3, 2013 at 9:34 AM, Stuart Henderson wrote: On 2013/04/03 14:54, Camiel Dobbelaar wrote: In some cases when a network port comes up, it does not indicate that the network is ready. But on linkup, carp(4) will try to get out of the INIT state as soon as possible. And because all is quiet it will decide to become master. This then leads to master-master situations. Here are two examples when this can happen, there are probably more: (1) spanning tree may be in effect, and not yet forwarding (2) a powering-up or rebooting switch that activates its ports immediately, but does not forward anything while not completely up yet (this may be an openbsd bridge too) I wonder if carp(4) needs an extra knob (*shudder*) to pause in the INIT state while the rest of the network gets ready after a linkup. I see in the source code there are already two mechanisms/workarounds that are related, but a pause may be a bit more generic: - sc_suppress - sc_delayed_arp Anyone else observe/fix this by other means? Opinions? slightly messy, though at least this also applies to the case with things other than carp which could also have problems: add "!sleep 5" or something in hostname.if for the physical interface...
Re: carp init delay
On 2013/04/03 15:43, Camiel Dobbelaar wrote: > > > On 4/3/13 3:34 PM, Stuart Henderson wrote: > >>In some cases when a network port comes up, it does not indicate that > >>the network is ready. But on linkup, carp(4) will try to get out of > >>the INIT state as soon as possible. And because all is quiet it will > >>decide to become master. > >>Anyone else observe/fix this by other means? Opinions? > >> > >> > >slightly messy, though at least this also applies to the case with > >things other than carp which could also have problems: add "!sleep 5" > >or something in hostname.if for the physical interface... > > Yes, I already use that. That solves the case where the system with > the carp interfaces itself is rebooted. > > But not the other cases. Hence I'd like that sleep applied always, > instead of only when /etc/netstart is run. :-) Ah, I see what you mean. Still there are things other than carp where this might also apply - for example the pfsync initial_bulk that gets handled via if_linkstatehooks (but maybe also userland things)..
Re: 5.3 -current installation problem
> Date: Wed, 3 Apr 2013 14:08:20 +0100 > From: Stuart Henderson > > moving this to tech@ - original message with dmesg is at > http://marc.info/?l=openbsd-misc&m=136498447228598&w=2 - summary: > asus P8H77-M, intel 7 series chipset, "Intel HD Graphics 3000" > running i386 or amd64, fails during boot with recent kernels unless > inteldrm disabled. /var/log/Xorg.0.log, from before you upgraded the machine, might provide us some clues. And defenitely also provide pcidump -vxx output. But ultimately having serial console output is pretty much a requirement for being able to debug this properly. > On 2013/04/03 07:54, Vijay Sankar wrote: > > Quoting Stuart Henderson : > > > > >On 2013-04-03, Vijay Sankar wrote: > > >>The following system runs -current from January 2013 without any > > >>problems. But attempts to install from the past few snapshots have > > >>failed. > > >> > > >>Installation of April 2, 2013 -current went through without any issues > > >>but upon first reboot, the console was blank, I could not access the > > >>system using SSH and it does not respond to pings. > > > > > >How far do you get before the console goes blank, does the kernel start > > >and print text, and then go blank part-way through booting? > > > > > >To help narrow things down, do you get further if at the boot loader > > >you do this: > > > > > >boot -c > > >disable inteldrm > > >quit > > > > > >It looks like there is a header for a serial port on the motherboard, > > >if you have a connector somewhere and can hook it up via null modem to > > >another machine you might get more information (e.g. if it panics while > > >switching video mode you'll be able to get a trace). > > > > > > > > > > Thank you so much. That was exactly it. For the past two days, I was > > poring through all the messages re. UEFI boot and so on and was going > > in the wrong direction. Once I disabled inteldrm I am able to use the > > system now without any problems. > > > > Not sure whether this is worthy of your time but if there are any > > logs or debug information I can provide, I will be happy to do that. > > > > Thanks again, > > > > Vijay > > The most useful thing if it's possible (short of getting a system to > a developer working in this area), would probably be to get a serial > console on the machine and capture a boot log with "option DRMDEBUG" > in kernel config. Though maybe someone on tech@ will have an idea of > something else to try. > >
Re: carp init delay
On 4/3/13 3:34 PM, Stuart Henderson wrote: In some cases when a network port comes up, it does not indicate that the network is ready. But on linkup, carp(4) will try to get out of the INIT state as soon as possible. And because all is quiet it will decide to become master. Anyone else observe/fix this by other means? Opinions? slightly messy, though at least this also applies to the case with things other than carp which could also have problems: add "!sleep 5" or something in hostname.if for the physical interface... Yes, I already use that. That solves the case where the system with the carp interfaces itself is rebooted. But not the other cases. Hence I'd like that sleep applied always, instead of only when /etc/netstart is run. :-)
Re: carp init delay
my 2 cents: timing is always a problem, maybe you could arping the next hop and then activate the carp ? On Wed, Apr 3, 2013 at 9:34 AM, Stuart Henderson wrote: > On 2013/04/03 14:54, Camiel Dobbelaar wrote: > > > > In some cases when a network port comes up, it does not indicate that > > the network is ready. But on linkup, carp(4) will try to get out of > > the INIT state as soon as possible. And because all is quiet it will > > decide to become master. > > > > This then leads to master-master situations. > > > > Here are two examples when this can happen, there are probably more: > > > > (1) spanning tree may be in effect, and not yet forwarding > > > > (2) a powering-up or rebooting switch that activates its ports > > immediately, but does not forward anything while not completely up > > yet (this may be an openbsd bridge too) > > > > I wonder if carp(4) needs an extra knob (*shudder*) to pause in the > > INIT state while the rest of the network gets ready after a linkup. > > > > I see in the source code there are already two mechanisms/workarounds > > that are related, but a pause may be a bit more generic: > > - sc_suppress > > - sc_delayed_arp > > > > Anyone else observe/fix this by other means? Opinions? > > > > > > slightly messy, though at least this also applies to the case with > things other than carp which could also have problems: add "!sleep 5" > or something in hostname.if for the physical interface... > > -- - () ascii ribbon campaign - against html e-mail /\
Re: carp init delay
On 2013/04/03 14:54, Camiel Dobbelaar wrote: > > In some cases when a network port comes up, it does not indicate that > the network is ready. But on linkup, carp(4) will try to get out of > the INIT state as soon as possible. And because all is quiet it will > decide to become master. > > This then leads to master-master situations. > > Here are two examples when this can happen, there are probably more: > > (1) spanning tree may be in effect, and not yet forwarding > > (2) a powering-up or rebooting switch that activates its ports > immediately, but does not forward anything while not completely up > yet (this may be an openbsd bridge too) > > I wonder if carp(4) needs an extra knob (*shudder*) to pause in the > INIT state while the rest of the network gets ready after a linkup. > > I see in the source code there are already two mechanisms/workarounds > that are related, but a pause may be a bit more generic: > - sc_suppress > - sc_delayed_arp > > Anyone else observe/fix this by other means? Opinions? > > slightly messy, though at least this also applies to the case with things other than carp which could also have problems: add "!sleep 5" or something in hostname.if for the physical interface...
-Wshorten-64-to-32
Hi, Apple has added a -Wshorten-64-to-32 option to GCC. It generates a warning if a value is implicitly converted from a 64-bit to a 32-bit type. I found it useful, looked at the code and ported it to OpenBSD. I don't think this is worth integrating. Use at your own discretion. :) -p. Index: gcc/gcc/c-common.c === RCS file: /cvs/src/gnu/gcc/gcc/c-common.c,v retrieving revision 1.4 diff -u -p -r1.4 c-common.c --- gcc/gcc/c-common.c 15 Sep 2011 12:19:12 - 1.4 +++ gcc/gcc/c-common.c 3 Apr 2013 12:38:19 - @@ -552,6 +552,8 @@ static bool nonnull_check_p (tree, unsig static bool get_nonnull_operand (tree, unsigned HOST_WIDE_INT *); static int resort_field_decl_cmp (const void *, const void *); +static void warnings_for_convert_and_check (tree, tree, tree); + /* Table of machine-independent attributes common to all C-like languages. */ const struct attribute_spec c_common_attribute_table[] = { @@ -1073,6 +1075,26 @@ vector_types_convertible_p (tree t1, tre == INTEGRAL_TYPE_P (TREE_TYPE (t2))); } +void +warnings_for_convert_and_check (tree type, tree expr, tree result ATTRIBUTE_UNUSED) +{ + if (warn_shorten_64_to_32 + && TYPE_PRECISION (TREE_TYPE (expr)) == 64 + && TYPE_PRECISION (type) == 32) + { + /* As a special case, don't warn when we are working with small + constants as the enum forming code shortens them into smaller + types. */ + if (TREE_CODE (expr) == INTEGER_CST) +{ + bool unsignedp = tree_int_cst_sgn (expr) >= 0; + if (min_precision (expr, unsignedp) <= TYPE_PRECISION (type)) +return; +} + warning (0, "implicit conversion shortens 64-bit value into a 32-bit value"); + } +} + /* Convert EXPR to TYPE, warning about conversion problems with constants. Invoke this function on every expression that is converted implicitly, i.e. because of language rules and not because of an explicit cast. */ @@ -1109,6 +1131,8 @@ convert_and_check (tree type, tree expr) else unsigned_conversion_warning (t, expr); } + if (!skip_evaluation && !TREE_OVERFLOW (expr) && t != error_mark_node) +warnings_for_convert_and_check (type, expr, t); return t; } Index: gcc/gcc/c.opt === RCS file: /cvs/src/gnu/gcc/gcc/c.opt,v retrieving revision 1.4 diff -u -p -r1.4 c.opt --- gcc/gcc/c.opt 15 Sep 2011 12:19:12 - 1.4 +++ gcc/gcc/c.opt 3 Apr 2013 12:38:19 - @@ -161,6 +161,10 @@ Wconversion C ObjC C++ ObjC++ Var(warn_conversion) Warn about possibly confusing type conversions +Wshorten-64-to-32 +C Var(warn_shorten_64_to_32) +Warn if a value is implicitly converted from a 64-bit to a 32-bit type + Wctor-dtor-privacy C++ ObjC++ Var(warn_ctor_dtor_privacy) Warn when all constructors and destructors are private
carp init delay
In some cases when a network port comes up, it does not indicate that the network is ready. But on linkup, carp(4) will try to get out of the INIT state as soon as possible. And because all is quiet it will decide to become master. This then leads to master-master situations. Here are two examples when this can happen, there are probably more: (1) spanning tree may be in effect, and not yet forwarding (2) a powering-up or rebooting switch that activates its ports immediately, but does not forward anything while not completely up yet (this may be an openbsd bridge too) I wonder if carp(4) needs an extra knob (*shudder*) to pause in the INIT state while the rest of the network gets ready after a linkup. I see in the source code there are already two mechanisms/workarounds that are related, but a pause may be a bit more generic: - sc_suppress - sc_delayed_arp Anyone else observe/fix this by other means? Opinions?
Re: 5.3 -current installation problem
moving this to tech@ - original message with dmesg is at http://marc.info/?l=openbsd-misc&m=136498447228598&w=2 - summary: asus P8H77-M, intel 7 series chipset, "Intel HD Graphics 3000" running i386 or amd64, fails during boot with recent kernels unless inteldrm disabled. On 2013/04/03 07:54, Vijay Sankar wrote: > Quoting Stuart Henderson : > > >On 2013-04-03, Vijay Sankar wrote: > >>The following system runs -current from January 2013 without any > >>problems. But attempts to install from the past few snapshots have > >>failed. > >> > >>Installation of April 2, 2013 -current went through without any issues > >>but upon first reboot, the console was blank, I could not access the > >>system using SSH and it does not respond to pings. > > > >How far do you get before the console goes blank, does the kernel start > >and print text, and then go blank part-way through booting? > > > >To help narrow things down, do you get further if at the boot loader > >you do this: > > > >boot -c > >disable inteldrm > >quit > > > >It looks like there is a header for a serial port on the motherboard, > >if you have a connector somewhere and can hook it up via null modem to > >another machine you might get more information (e.g. if it panics while > >switching video mode you'll be able to get a trace). > > > > > > Thank you so much. That was exactly it. For the past two days, I was > poring through all the messages re. UEFI boot and so on and was going > in the wrong direction. Once I disabled inteldrm I am able to use the > system now without any problems. > > Not sure whether this is worthy of your time but if there are any > logs or debug information I can provide, I will be happy to do that. > > Thanks again, > > Vijay The most useful thing if it's possible (short of getting a system to a developer working in this area), would probably be to get a serial console on the machine and capture a boot log with "option DRMDEBUG" in kernel config. Though maybe someone on tech@ will have an idea of something else to try.
Show only usable commands in rc.subr usage
This patch makes rc.subr show only supported operations in usage. This avoids some sort of confusion when, e.g., /etc/rc.d/smtpd shows that "reload" command is allowed, but when you try it, you get "reload not supported" error. okay? -- WBR, Vadim Zhukov Index: rc.subr === RCS file: /cvs/src/etc/rc.d/rc.subr,v retrieving revision 1.68 diff -u -p -r1.68 rc.subr --- rc.subr 19 Nov 2012 07:10:59 - 1.68 +++ rc.subr 3 Apr 2013 11:35:58 - @@ -25,7 +25,13 @@ rc_err() { } rc_usage() { - rc_err "usage: $0 [-df] {start|check|reload|restart|stop}" + local _a _allsup _enotsup + for _a in start check reload restart stop; do + eval _enotsup=\${rc_${_a}} + [ X"${_enotsup}" != X"NO" ] && _allsup="$_allsup $_a" + done + _allsup="`echo $_allsup | sed -e 's/ /|/g'`" + rc_err "usage: $0 [-df] {${_allsup}}" } rc_write_runfile() {