Re: svn commit: r328159 - head/sys/modules
On 2018-Jan-18 21:07:19 -0800, Conrad Meyer wrote: >The spec says the behavior is undefined; not that the compiler has to >produce a warning or error message. The compiler *does* get to >arbitrarily decide what it wants to do when it encounters UB. It is >wholly free to implement this particular UB with the logical result >and no warning/error. IMO, the fact that our compiler produces a warning message when it encounters undefined behaviour is A Good Thing. Relying on implementation-specific behaviour leads to brittle code - a compiler update or reusing the code with a different compiler could completely change the behaviour. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r353640 - head/sys/kern
On 2019-Oct-16 13:21:02 +, Andrew Turner wrote: >Author: andrew >Date: Wed Oct 16 13:21:01 2019 >New Revision: 353640 >URL: https://svnweb.freebsd.org/changeset/base/353640 > >Log: > Stop leaking information from the kernel through timespec > > The timespec struct holds a seconds value in a time_t and a nanoseconds > value in a long. On most architectures these are the same size, however > on 32-bit architectures other than i386 time_t is 8 bytes and long is > 4 bytes. > > Most ABIs will then pad a struct holding an 8 byte and 4 byte value to > 16 bytes with 4 bytes of padding. When copying one of these structs the > compiler is free to copy the padding if it wishes. Are there any other structs passed from kernel to userland that include padding? -- Peter Jeremy signature.asc Description: PGP signature
svn commit: r354094 - head/sys/arm64/rockchip
Author: peterj
Date: Fri Oct 25 19:38:02 2019
New Revision: 354094
URL: https://svnweb.freebsd.org/changeset/base/354094
Log:
Fix use of uninitialised variable.
The RK805 regs array was being allocated before it's required size was
known, causing the driver to use memory it didn't own. That memory
was subsequently allocated and used elsewhere causing later fatal data
aborts in rk805_map().
Whilst I'm here, add a sanity check to catch unsupported PMICs (this
shouldn't ever get hit because the probe should have failed).
Reviewed by: manu
MFC after:1 week
Sponsored by: Google
Modified:
head/sys/arm64/rockchip/rk805.c
Modified: head/sys/arm64/rockchip/rk805.c
==
--- head/sys/arm64/rockchip/rk805.c Fri Oct 25 18:56:46 2019
(r354093)
+++ head/sys/arm64/rockchip/rk805.c Fri Oct 25 19:38:02 2019
(r354094)
@@ -467,9 +467,6 @@ rk805_attach(device_t dev)
if (config_intrhook_establish(&sc->intr_hook) != 0)
return (ENOMEM);
- sc->regs = malloc(sizeof(struct rk805_reg_sc *) * sc->nregs,
- M_RK805_REG, M_WAITOK | M_ZERO);
-
sc->type = ofw_bus_search_compatible(dev, compat_data)->ocd_data;
switch (sc->type) {
case RK805:
@@ -480,7 +477,13 @@ rk805_attach(device_t dev)
regdefs = rk808_regdefs;
sc->nregs = nitems(rk808_regdefs);
break;
+ default:
+ device_printf(dev, "Unknown type %d\n", sc->type);
+ return (ENXIO);
}
+
+ sc->regs = malloc(sizeof(struct rk805_reg_sc *) * sc->nregs,
+ M_RK805_REG, M_WAITOK | M_ZERO);
rnode = ofw_bus_find_child(ofw_bus_get_node(dev), "regulators");
if (rnode > 0) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r351187 - head/sys/arm64/rockchip
dug into this further yet. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r351187 - head/sys/arm64/rockchip
On 2019-Aug-27 11:56:38 +0200, Michal Meloun wrote: > > >On 25.08.2019 9:28, Peter Jeremy wrote: >> On 2019-Aug-18 09:19:33 +, Michal Meloun >> wrote: >>> Improve rk_pinctrl driver: >> >> Sorry for the late notice but this breaks my Rock64 (RK3328). >> >Sorry for late response. >Seems like this is caused by unnoticed dependency between patches in >my worktree, sorry for this. I hope that r351543 solves it. >Can you, please, try r351543 on Rock64 because I haven't any rk3328 >based board for real test? r351543 + r351551 fixes it for me. Thanks for that. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r345625 - in head: contrib/elftoolchain/readelf lib/libc lib/libthr libexec/rtld-elf sys/sys
On 2019-Mar-28 09:41:49 -0300, Renato Botelho wrote: >On 3/28/19 4:25 AM, Oliver Pinter wrote: >> On Thursday, March 28, 2019, Ed Maste wrote: >> >>> Author: emaste >>> Date: Thu Mar 28 02:12:32 2019 >>> New Revision: 345625 >>> URL: https://svnweb.freebsd.org/changeset/base/345625 >>> >> Seems like this and the other hunk belongs to a different patch. >Indeed. It broke the build for me No, r345638 broke the build by only reverting one of the two extraneous hunks from this commit. -- Peter Jeremy signature.asc Description: PGP signature
svn commit: r346266 - head/sys/arm/conf
Author: peterj Date: Tue Apr 16 09:44:46 2019 New Revision: 346266 URL: https://svnweb.freebsd.org/changeset/base/346266 Log: Specify correct Ethernet phy for RPI-B Correct a typo in the RPI-B ethernet config - the RPi-B includes a SMC LAN9512 USB bridge and Ethernet 10/100 NIC/phy. The phy part of this is supported by smscphy. Tested On: RPi1 Model B Approved by: grog, jhb (mentors) MFC after:3 days Modified: head/sys/arm/conf/RPI-B Modified: head/sys/arm/conf/RPI-B == --- head/sys/arm/conf/RPI-B Tue Apr 16 09:42:42 2019(r346265) +++ head/sys/arm/conf/RPI-B Tue Apr 16 09:44:46 2019(r346266) @@ -77,7 +77,7 @@ deviceda device umass # USB ethernet support -device smcphy +device smscphy device mii device smsc ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r346265 - head/sys/arm/broadcom/bcm2835
Author: peterj
Date: Tue Apr 16 09:42:42 2019
New Revision: 346265
URL: https://svnweb.freebsd.org/changeset/base/346265
Log:
Fix cpufreq(4) on RPI-B
Since r324184 the root node compatible for the original Raspberry Pi
is "brcm,bcm2835", add it to the compatible list of bcm2835_cpufreq.
Tested On: RPi1 Model B
Note that the default Das U-Boot FDT does not include a cpus clause
so actually adding a bcm2835_cpufreq device requires adding a FDT
overlay defining the cpu.
Approved by: grog, jhb (mentors)
MFC after:3 days
Modified:
head/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c
Modified: head/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c
==
--- head/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c Tue Apr 16 05:11:39
2019(r346264)
+++ head/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c Tue Apr 16 09:42:42
2019(r346265)
@@ -126,6 +126,7 @@ static struct ofw_compat_data compat_data[] = {
{ "broadcom,bcm2835-vc",1 },
{ "broadcom,bcm2708-vc",1 },
{ "brcm,bcm2709", 1 },
+ { "brcm,bcm2835", 1 },
{ "brcm,bcm2836", 1 },
{ "brcm,bcm2837", 1 },
{ NULL, 0 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r352275 - in head/lib/libedit: . TEST edit readline
On 2019-Sep-13 16:33:15 -0400, Charlie Li wrote: >Baptiste Daroussin wrote: >> Author: bapt >> Date: Fri Sep 13 06:50:02 2019 >> New Revision: 352275 >> URL: https://svnweb.freebsd.org/changeset/base/352275 >> >> Log: >> Update libedit to a snapshot from 2019-09-10 >> Reviewed by: Yuichiro Naito >> MFC after: 3 weeks >> Differential Revision: https://reviews.freebsd.org/D21584 >> >I posted in phab but repeating here, this breaks the build on (at least) >aarch64: It breaks the build on arm and arm64 only. wint_t is int on all platforms: sys/sys/_types.h: typedef int __ct_rune_t;/* arg type for ctype funcs */ typedef __ct_rune_t __wint_t; /* wint_t (see above) */ but wchar_t varies between unsigned and signed: $ grep '__wchar_t' sys/*/include/_types.h sys/arm/include/_types.h:typedefunsigned int___wchar_t; sys/arm64/include/_types.h:typedef unsigned int___wchar_t; sys/mips/include/_types.h:typedef int ___wchar_t; sys/powerpc/include/_types.h:typedefint ___wchar_t; sys/riscv/include/_types.h:typedef int ___wchar_t; sys/sparc64/include/_types.h:typedefint ___wchar_t; sys/x86/include/_types.h:typedefint ___wchar_t; Looking back into history, it looks like the "unsigned" is part of the ARM EABI. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r349151 - in head: lib/libufs stand/libsa sys/conf sys/dev/iscsi sys/dev/iscsi_initiator sys/dev/liquidio sys/dev/usb/net sys/fs/ext2fs sys/fs/nandfs sys/geom/part sys/geom/raid sys/ke
On 2019-Jun-17 19:49:09 +, Xin LI wrote: >Author: delphij >Date: Mon Jun 17 19:49:08 2019 >New Revision: 349151 >URL: https://svnweb.freebsd.org/changeset/base/349151 > >Log: > Separate kernel crc32() implementation to its own header (gsb_crc32.h) and > rename the source to gsb_crc32.c. I'm not sure how but this breaks my Rock64. r349150 boots without problem but r349151 panics during the probe: ... rockchip_dwmmc0: mem 0xff50-0xff503fff irq 40 on ofwbus0 rockchip_dwmmc0: Hardware version ID is 270a mmc0: on rockchip_dwmmc0 rockchip_dwmmc1: mem 0xff52-0xff523fff irq 42 on ofwbus0 rockchip_dwmmc1: Hardware version ID is 270a panic: Duplicate alloc of 0xfd89cf50 from zone 0xfd817540(16) slab 0xfd89cf90(0) cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0x00535a14 lr = 0x000df10c sp = 0x000104d0 fp = 0x000106e0 db_trace_self_wrapper() at vpanic+0x18c pc = 0x000df10c lr = 0x00277edc sp = 0x000106f0 fp = 0x00010790 vpanic() at panic+0x44 pc = 0x00277edc lr = 0x00277c8c sp = 0x000107a0 fp = 0x00010820 panic() at uma_dbg_alloc+0x144 pc = 0x00277c8c lr = 0x004fa174 sp = 0x00010830 fp = 0x00010850 uma_dbg_alloc() at uma_zalloc_arg+0x9b0 pc = 0x004fa174 lr = 0x004f9624 sp = 0x00010860 fp = 0x000108e0 uma_zalloc_arg() at malloc+0x9c pc = 0x004f9624 lr = 0x00252750 sp = 0x000108f0 fp = 0x00010920 malloc() at bounce_bus_dmamem_alloc+0x4c pc = 0x00252750 lr = 0x00533828 sp = 0x00010930 fp = 0x00010960 bounce_bus_dmamem_alloc() at dwmmc_attach+0x5fc pc = 0x00533828 lr = 0x00556f14 sp = 0x00010970 fp = 0x000109e0 dwmmc_attach() at device_attach+0x3f4 pc = 0x00556f14 lr = 0x002aba50 sp = 0x000109f0 fp = 0x00010a40 device_attach() at bus_generic_new_pass+0x12c pc = 0x002aba50 lr = 0x002ad804 sp = 0x00010a50 fp = 0x00010a80 bus_generic_new_pass() at bus_generic_new_pass+0xe4 pc = 0x002ad804 lr = 0x002ad7bc sp = 0x00010a90 fp = 0x00010ac0 bus_generic_new_pass() at bus_generic_new_pass+0xe4 pc = 0x002ad7bc lr = 0x002ad7bc sp = 0x00010ad0 fp = 0x00010b00 bus_generic_new_pass() at bus_set_pass+0x8c pc = 0x002ad7bc lr = 0x002a91ac sp = 0x00010b10 fp = 0x00010b40 bus_set_pass() at mi_startup+0x238 pc = 0x002a91ac lr = 0x0021246c sp = 0x00010b50 fp = 0xffff00010bb0 ... -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r349151 - in head: lib/libufs stand/libsa sys/conf sys/dev/iscsi sys/dev/iscsi_initiator sys/dev/liquidio sys/dev/usb/net sys/fs/ext2fs sys/fs/nandfs sys/geom/part sys/geom/raid sys/ke
On 2019-Jun-22 17:17:03 +1000, Peter Jeremy wrote: >On 2019-Jun-17 19:49:09 +, Xin LI wrote: >>Author: delphij >>Date: Mon Jun 17 19:49:08 2019 >>New Revision: 349151 >>URL: https://svnweb.freebsd.org/changeset/base/349151 >> >>Log: >> Separate kernel crc32() implementation to its own header (gsb_crc32.h) and >> rename the source to gsb_crc32.c. > >I'm not sure how but this breaks my Rock64. r349150 boots without problem >but r349151 panics during the probe: >... And the problem went away somewhere between r349269 and r349288. Since there's nothing obvious there either, I presume this is something more subtle like a race condition that has been provoked by the code changes. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r362589 - in head/lib/csu: aarch64 arm i386 riscv
On 2020-Jun-24 17:54:25 +, John Baldwin wrote: >Author: jhb >Date: Wed Jun 24 17:54:24 2020 >New Revision: 362589 >URL: https://svnweb.freebsd.org/changeset/base/362589 > >Log: > Always compile the brand and ignore init ELF notes standalone. I'm not sure if this is self-inflicted but I'm now seeing linker failures trying to build in /usr/src/lib/csu/aarch64: ld -o Scrt1.o -r Scrt1_c.o crt1_s.o crtbrand.o ignore_init_note.o Scrt1.s ld: error: Scrt1.s:1: unknown directive: .text >>> .text >>> ^ *** Error code 1 This is running r362580 and trying to buildworld r352310 on arm64. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r362589 - in head/lib/csu: aarch64 arm i386 riscv
On 2020-Jun-26 10:25:36 +1000, Peter Jeremy wrote: >On 2020-Jun-24 17:54:25 +, John Baldwin wrote: >>Author: jhb >>Date: Wed Jun 24 17:54:24 2020 >>New Revision: 362589 >>URL: https://svnweb.freebsd.org/changeset/base/362589 >> >>Log: >> Always compile the brand and ignore init ELF notes standalone. > >I'm not sure if this is self-inflicted but I'm now seeing linker failures >trying to build in /usr/src/lib/csu/aarch64: >ld -o Scrt1.o -r Scrt1_c.o crt1_s.o crtbrand.o ignore_init_note.o Scrt1.s >ld: error: Scrt1.s:1: unknown directive: .text >>>> .text >>>> ^ >*** Error code 1 > >This is running r362580 and trying to buildworld r352310 on arm64. Sorry - that latter revision is obviously wrong. I was building r362612. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r362736 - head/sys/arm64/rockchip
On 2020-Jun-28 21:11:10 +, Oleksandr Tymoshenko wrote: >Log: > Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC > > For 1000Mb mode to work reliably TX/RX delays need to be configured > between the TX/RX clock and the respective signals on the PHY > to compensate for differing trace lengths on the PCB. This breaks (at least) diskless booting on my Rock64. During boot, I normally see: regulator: shutting down unused regulators uhub1: 1 port with 1 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered dwc0: link state changed to DOWN NFS ROOT: 192.168.12.200:/tank/rock64 dwc0: link state changed to UP Warning: no time-of-day clock registered, system time will not be set accurately Warning: no time-of-day clock registered, system time will not be set accurately start_init: trying /sbin/init With r362736, I see: setting RK3328 RX/TX delays: 24/36 ... regulator: shutting down unused regulators uhub0: 1 port with 1 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub2: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered dwc0: link state changed to DOWN NFS ROOT: 192.168.12.200:/tank/rock64 dwc0: link state changed to UP dwc0: link state changed to DOWN dwc0: link state changed to UP [Nothing further until I push the reset button] The system doesn't respond to pings so I suspect the network is dead. Normally, it runs 1000baseT . -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r362736 - head/sys/arm64/rockchip
On 2020-Jul-01 18:57:47 +1000, Peter Jeremy wrote: >On 2020-Jun-28 21:11:10 +, Oleksandr Tymoshenko wrote: >>Log: >> Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC >> >> For 1000Mb mode to work reliably TX/RX delays need to be configured >> between the TX/RX clock and the respective signals on the PHY >> to compensate for differing trace lengths on the PCB. > >This breaks (at least) diskless booting on my Rock64. I've studied the RK3328 TRM[1] and the RK3328 code following r362736 matches[2] the GRF_MAC_CON0/1 documentation on p201-203 (though p574 says the delay line is configured via GRF_SOC_CON3 - which doesn't match the documentation on GRF_SOC_CON3 on p175-177). That suggests that the delay values in the FDT are incorrect. Unfortunately, the TRM doesn't include any details on how to configure the delay values so it's difficult to adjust the numbers in the FDT. One possible explanation I have is that there are (at least) 2 different Rock64 variants. Later versions have increased the RGMII bus voltage to improve GigE reliability. I initially had problems with GigE reliability and mod'd my Rock64[3] to use the higher RGMII bus voltage - which made it rock solid at GigE. It's possible that different variants need different delay values, due to different track skew or different driver behaviour at different bus voltages. [1] Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf [2] There's one typo: RK3328_GRF_MAC_CON0_TX_MASK instead of RK3328_GRF_MAC_CON0_RX_MASK but the values are the same). [3] Move 1 resistor to change a pull-up to a pull-down -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r362736 - head/sys/arm64/rockchip
On 2020-Jul-02 17:26:23 -0700, Oleksandr Tymoshenko wrote: >Could you try kernel with this patch? It's mostly debug output, >with one possible clock-related fix. > >https://people.freebsd.org/~gonzo/patches/rk3328-gmac-debug.patch It's still not working for me. I get the following: dwc0: mem 0xff54-0xff54 irq 44 on ofwbus0 setting RK3328 RX/TX delays: 24/36 >>> RK3328_GRF_MAC_CON1 (0413): >>> gmac2io_gmii_clk_sel: 0x0 >>> gmac2io_rmii_extclk_sel: 0x1 >>> gmac2io_rmii_mode: 0x0 >>> gmac2io_rmii_clk_sel: 0x0 >>> gmac2io_phy_intf_sel: 0x1 >>> gmac2io_flowctrl: 0x0 >>> gmac2io_rxclk_dly_ena: 0x1 >>> gmac2io_txclk_dly_ena: 0x1 >>> RK3328_GRF_MAC_CON0 (0c24): miibus0: on dwc0 rgephy0: PHY 0 on miibus0 rgephy0: OUI 0x00e04c, model 0x0011, rev. 6 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto >I have Rock64 v2, which, as you mentioned, has a known issue with GigE, so >my tests are not reliable. I'll try to get another RK3328 board for tests, >but it may take some time. I've asked on -arm if anyone else has tried this on a Rock64 v2 or v3. >If the clock fix doesn't help, I'll make >delays configuration run-time configurable with off by default until >more hardware is tested. That sounds like a good way forward - maybe boot and run-time configurable. It's a pity that there doesn't seem to be any documentation on what the numbers represent (or what the "default" value is) - which means that actually adjusting the delay numbers would be very time consuming. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r355487 - in head/sys: arm64/arm64 arm64/include conf
On 2019-Dec-09 08:38:01 -0600, Kyle Evans wrote:
...
>> +static vm_offset_t
>> +freebsd_parse_boot_param(struct arm64_bootparams *abp)
>> +{
>> + vm_offset_t lastaddr = 0;
>> + void *kmdp;
>> +#ifdef DDB
>> + vm_offset_t ksym_start;
>> + vm_offset_t ksym_end;
>> +#endif
>> +
>> + if (abp->modulep == 0)
>> + return (0);
>> +
>> + preload_metadata = (caddr_t)(uintptr_t)(abp->modulep);
>> + kmdp = preload_search_by_type("elf kernel");
>> + if (kmdp == NULL)
>> + return (0);
>> +
>> + boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int);
>> + loader_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *);
>> + init_static_kenv(static_kenv, 0);
>
>This should read "loader_envp" instead of "static_kenv" -- as written,
>it stomps over the kenv provided by loader.
Which breaks diskless booting and NFS root. Changing static_kenv to
loader_envp unbreaks the kernel.
--
Peter Jeremy
signature.asc
Description: PGP signature
Re: svn commit: r361491 - in head/sys: geom kern sys ufs/ffs ufs/ufs
On 2020-May-25 23:47:32 +, Chuck Silvers wrote: >Author: chs >Date: Mon May 25 23:47:31 2020 >New Revision: 361491 >URL: https://svnweb.freebsd.org/changeset/base/361491 > >Log: > This commit enables a UFS filesystem to do a forcible unmount when > the underlying media fails or becomes inaccessible. For example > when a USB flash memory card hosting a UFS filesystem is unplugged. This breaks the build when FFS is not built into the kernel but GEOM is (eg for a ZFS-only system). Specifically, ffs_subr.c is marked "optional ffs | geom_label" and this commit added a dependency on M_UFSMNT (defined in sys/ufs/ufs/ufs_vfsops.c) to ffs_subr.c. The geom_label dependency exists because sys/geom/label/g_label_ufs.c relies on ffs_sbget() (defined in ffs_subr.c) to taste UFS partitions. I'm not sure of the best fix here - ideally, the new functions this commit adds to ffs_subr.c would be moved to a different file (though it's not immediately clear which file that would be. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r359647 - in head/sys: arm64/broadcom arm64/broadcom/brcmmdio conf dev/mdio
On 2020-Apr-06 05:48:58 +, Wojciech Macek wrote: >Log: > Add MDIO PHY driver for NS2 ARM64 platform. ... >Modified: head/sys/conf/files.arm64 >== >--- head/sys/conf/files.arm64 Mon Apr 6 04:06:15 2020(r359646) >+++ head/sys/conf/files.arm64 Mon Apr 6 05:48:58 2020(r359647) >@@ -176,6 +176,9 @@ arm64/arm64/undefined.cstandard > arm64/arm64/unwind.c optionalddb | kdtrace_hooks | stack > arm64/arm64/vfp.c standard > arm64/arm64/vm_machdep.c standard >+arm64/broadcom/brcmmdio/mdio_mux_iproc.c optionalfdt >+arm64/broadcom/brcmmdio/mdio_nexus_iproc.coptionalfdt >+arm64/broadcom/brcmmdio/mdio_ns2_pcie_phy.c optionalfdt pci I don't believe this is correct. These files are only relevant to a subset of Broadcom SoCs and (IMO) should not be included merely with "options FDT", rather they should be conditional on the relevant Broadcom SoCs. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r219679 - head/sys/i386/include
On 2011-Mar-16 16:34:04 -0400, Jung-uk Kim wrote: >On Wednesday 16 March 2011 01:45 pm, Roman Divacky wrote: >> if we drop i486 I think it makes sense to require something that >> has at least SSE2, thus we can have the same expectations as on >> amd64. I think it's stil a bit early for that - especially the SSE2 requirement. >This is a proof-of-concept patch for sys/x86/isa/clock.c: > >http://people.freebsd.org/~jkim/clock.diff > >You see the complexity, just because I wanted to load 64-bit value >atomically... :-( An alternative approach is to have _fetch_frequency() be uint64_t (*_fetch_frequency)(uint64_t *); if i386 and I486 are defined (otherwise it's just the #define (*(p))) then initialise it to either atomic_fetch_quad_i386 or atomic_fetch_quad_i586 as part of the CPU detection process. This is the way bcopy() is/was handled on Pentium. Another approach would be to always have cmpxchg8b instructions (followed by a suitably large NOP) always inlined in the code and if it traps, patch the code to call a function that emulates it. -- Peter Jeremy pgpSimCdanXum.pgp Description: PGP signature
Re: svn commit: r219700 - head/sys/x86/x86
On 2011-Mar-16 16:44:08 +, Jung-uk Kim wrote: >Log: > Revert r219676. Thanks also. For extra kudos, how about adding a similar function to allow the HPET frequency to be over-ridden. That is currently the only timecounter that does not allow the user to compensate for incorrect hardware frequencies. -- Peter Jeremy pgpeyEkoSy8te.pgp Description: PGP signature
Re: svn commit: r219700 - head/sys/x86/x86
On 2011-Mar-25 21:02:03 +1100, Bruce Evans wrote: >On Thu, 24 Mar 2011, Warner Losh wrote: >> ntpd requires that the time counter be within 128ppm of true. If the time >> counter guess is off by more than that, you lose: ntpd won't work. I suspect Warner may be confusing the frequency tolerance with the time tolerance here. RFC5905 gives a lock range of +/-500ppm and +/-128msec and the FreeBSD ntpd implements those ranges. The actual timecounter needs to be well within the lock range to prevent the PLL saturating during transient events - I thought the timecounter limit was +/-300ppm but RFC1305 talks about a +/-100ppm limit in order to support an adjustment skew of +/-300ppm. >Is ntpd really that broken? What does it do if the drift file has the >correct compensation to within 128 ppm? RFC1305 includes a fairly detailed description of why the various limits were chosen in its appendices (though this wasn't transferred over to RFC5905). The drift file specifies the PLL frequency offset, capped at +/-500ppm. If the actual drift is outside that value then the PLL will remain stuck at the limit and ntpd will regularly step the time. >I use an old version of ntpd in which I've observed a positive feedback >loop when -x is used to prevent steps and the slew wants to be more than >128 ppm due to a transient. Some versions of ntpd appear to have a bug where, in an environment with significant jitter in peer/server time, the PLL can saturate at +/-500ppm and not recover. This is definitely true of the ntpd in Tru64 5.1 and (from memory) was true of ntpd in some versions of FreeBSD. -- Peter Jeremy pgpxA2RsEkndD.pgp Description: PGP signature
Re: svn commit: r206129 - head/sys/kern
On 2010-Apr-03 08:39:00 +, Andriy Gapon wrote: >Author: avg >Date: Sat Apr 3 08:39:00 2010 >New Revision: 206129 >URL: http://svn.freebsd.org/changeset/base/206129 > >Log: > vn_stat: take into account va_blocksize when setting st_blksize > > As currently st_blksize is always PAGE_SIZE, it is playing safe to not > use any smaller value. For some cases this might not be optimal, but > at least nothing should get broken. I haven't verified it but, based on a quick look at the change, I suspect this will trigger the problem in bin/16. Quick summary: db(3) has restrictions on its internal bucket size but initializes it from st_blksize with no sanity checking and ZFS can report blocksizes outside the allowed bucket size range for db(3). -- Peter Jeremy pgpXUKXHXhEFM.pgp Description: PGP signature
Re: svn commit: r206129 - head/sys/kern
On 2010-Apr-05 00:27:42 +0300, Kostik Belousov wrote: >On Mon, Apr 05, 2010 at 12:11:06AM +0300, Andriy Gapon wrote: >> on 05/04/2010 00:03 Peter Jeremy said the following: >> > On 2010-Apr-03 08:39:00 +, Andriy Gapon wrote: >> >> vn_stat: take into account va_blocksize when setting st_blksize ... >> > I haven't verified it but, based on a quick look at the change, I >> > suspect this will trigger the problem in bin/16. Quick summary: >> > db(3) has restrictions on its internal bucket size but initializes it >> > from st_blksize with no sanity checking and ZFS can report blocksizes >> > outside the allowed bucket size range for db(3). >> >> Thank you for pointing this out. >> If no one objects or provides a better patch, I will commit yours. > >I do not think this is very satisfying solution. Pre-patched libc >still suffer from the problem. You cannot run stable/8 libc on this >kernel. Firstly, has someone with a post-r206129 kernel verified that it does actually trigger the issue I reported in bin/16? I'm not in a position to do so easily and it's possible that the problem is masked elsewhere. Also, Kostik's comment is a slight exaggeration: You can't create a db(3) database from scratch in a ZFS filesystem using db(3) defaults. Note that as of now, it's exactly the same situation as running -current libc with a post-r206129 kernel. -current is expected to include occasions of bumpiness so I don't see this as an immediate reason to revert r206129 - though if buildworld or installworld are affected, it at least needs a heads-up. OTOH, I think some care needs to taken over any MFC of this change. At the very least, the db(3) problem needs to be fixed and there probably needs to be an extended shakedown of r206129 to ensure that there aren't any other similar nasties lurking elsewhere. The problem I reported in bin/16 is a bug in a userland utility and IMHO, it's not the kernel's responsibility to work around userland bugs. -- Peter Jeremy pgpxiNnThP5Vy.pgp Description: PGP signature
Re: svn commit: r206129 - head/sys/kern
On 2010-Apr-05 11:27:07 +0300, Andriy Gapon wrote: >> Firstly, has someone with a post-r206129 kernel verified that it >> does actually trigger the issue I reported in bin/16? I'm not >> in a position to do so easily and it's possible that the problem >> is masked elsewhere. > >Sorry for my lack of knowledge, but what is the best way to test this? >As I understand, a new db needs to be initialized in an existing file? You should be able to demonstrate the problem by using dbopen() to create a new DB_HASH file with NULL openinfo. I've updated bin/16 with a scenario that I believe will demonstrate the problem on FreeBSD - basically, run the db-hash.t test in perl and it should core-dump after test 21. -- Peter Jeremy pgpXwfhOJDmo8.pgp Description: PGP signature
Re: svn commit: r206814 - head/sys/vm
On 2010-Apr-18 21:29:28 +, Alan Cox wrote: > Remove a nonsensical test from vm_pageout_clean(). A page can't be in the > inactive queue and have a non-zero wire count. Should this test be turned into a KASSERT()? -- Peter Jeremy pgpUBaNmfHIN6.pgp Description: PGP signature
Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules
On 2011-Jun-28 11:57:25 +, "Bjoern A. Zeeb" wrote: >Author: bz >Date: Tue Jun 28 11:57:25 2011 >New Revision: 223637 >URL: http://svn.freebsd.org/changeset/base/223637 > >Log: > Update packet filter (pf) code to OpenBSD 4.5. This is very belated but I've just found the following preprocessor conditionals in sys/contrib/pf/net/pfvar.h as a result of this commit (covering lines 214..282): #ifdef __FreeBSD__ ... #ifdef __FreeBSD__ ... #else ... #endif /* __FreeBSD__ */ ... #endif /* __FreeBSD__ */ Was there a mismerge here? -- Peter Jeremy pgppOpwYJHEVh.pgp Description: PGP signature
Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules
On 2011-Jun-28 11:57:25 +, "Bjoern A. Zeeb" wrote: >Author: bz >Date: Tue Jun 28 11:57:25 2011 >New Revision: 223637 >URL: http://svn.freebsd.org/changeset/base/223637 > >Log: > Update packet filter (pf) code to OpenBSD 4.5. Further to my mail last Wednesday, I've found nested "#ifdef __FreeBSD__" conditionals in pf_ioctl.c as well - it looks like conditional code was added to support network stack virtualisation without noting that the code was already protectd by a "#ifdef __FreeBSD__". And cross-checking the $OpenBSD$ tags in the FreeBSD repo against the OpenBSD CVSweb throws up consistent off-by-one errors - as an example, src/sys/contrib/pf/net/if_pfsync.h in FreeBSD 9.0 states "$OpenBSD: if_pfsync.h,v 1.35 2008/06/29 08:42:15 mcbride Exp $" but the actual content matches if_pfsync.h v1.36 in OpenBSD CVSweb. Is it possible that the pf code was checked out of an OpenBSD repo without the correct $OpenBSD$ tag expansion? This caused me a degree of confusion whilst trying to correlate the FreeBSD code with the OpenBSD code to try and update bin/124825 -- Peter Jeremy pgpETpzB0eUVO.pgp Description: PGP signature
Re: svn commit: r223129 - head/release
On 2011-Jun-15 23:38:15 +, Nathan Whitehorn wrote: >Log: > Do not install the rescue tools onto the install CD. Since it is read > only, they are very unlikely to be needed and take up a great deal of > space. If I've correctly understood this change, I'm not sure this is a positive move. Based on a quick test, removing /rescue saves about 4MB (in reality, the saving should be less because /rescue removes the need for /stand). OTOH, it renders the install CD useless as a recovery "fixit" disk - whilst the CD is unlikely to need recovery itself, it was useful for recovering hard disks -- Peter Jeremy pgpCRNIuE4pIQ.pgp Description: PGP signature
Re: svn commit: r222866 - head/sys/x86/x86
On 2011-Jun-18 22:05:06 +1000, Bruce Evans wrote: >My clock measurement program (mostly an old program by Wollman) shows >the following histogram of times for a non-invariant TSC timecounter >on a 2GHz UP system: > >% min 273, max 265102, mean 273.998217, std 79.069534 >% 1th: 273 (1727219 observations) >% 2th: 274 (265607 observations) >% 3th: 275 (6984 observations) >% 4th: 280 (11 observations) >% 5th: 290 (8 observations) > >The variance is small, and differences of a single nS can be seen clearly. Unfortunately, Intel broke this in their P-state invariant TSC implementation. Rather than incrementing the TSC by one at the CPU core frequency, they increment by the core multiplier at the FSB frequency. This gives a result like the following on my Atom N270: delta samples 2449637124 3650312540 48 44658 60 77 This makes it virtually impossible to measure short periods. Luckily, AMD seem to have gotten this right. -- Peter Jeremy pgpE3vKHLWVpS.pgp Description: PGP signature
Re: svn commit: r223722 - in head/sys: kern sys
On 2011-Jul-02 11:13:57 -0400, Ben Kaduk wrote: >On Sat, Jul 2, 2011 at 9:54 AM, Ed Schouten wrote: >> Reintroduce the cioctl() hook in the TTY layer for digi(4). Thanks Ed. >> The cioctl() hook can be used by drivers to add ioctls to the *.init and >> *.lock devices. This commit breaks the ttydevsw ABI, since this > >Aren't __FreeBSD_version bumps cheap, these days? A __FreeBSD_version bump can help a driver determine whether specific functionality is available in the kernel but that doesn't solve this particular issue. A struct ttydevsw is allocated and populated by a TTY device driver and passed to the generic TTY code to define callbacks from the generic code into the driver. Consider the case where a module compiled with an old struct ttydevsw definition is loaded into a new kernel - the generic TTY code will attempt to reference ttydevsw fields that aren't defined by the driver, with results that won't be pretty. -- Peter Jeremy pgp9M1Qw5KA3e.pgp Description: PGP signature
Re: svn commit: r210124 - head/sys/amd64/amd64
On 2010-Jul-15 16:25:51 +, Alan Cox wrote: >Log: > Optimize pmap_remove()'s handling of PG_G mappings. Specifically, ... > calls pmap_invalidate_page(). Altogether, these changes eliminate 53% > of the TLB shootdowns for a "buildworld" on a ZFS file system. On > FFS, the reduction is 3%. I have no feeling for the cost of a TLB shootdown. What is the likely impact on buildworld on a ZFS filesystem? Barely noticable or several percent faster? -- Peter Jeremy pgpHEoJJFEwje.pgp Description: PGP signature
Re: svn commit: r210175 - head/usr.sbin/sysinstall
On 2010-Aug-16 00:06:35 +0200, Marc Fonvieille wrote: >We still support PLIP (with a laplink cable) since a plip0 interface >is displayed on this screen during installation if you have a parallel >port on the motherboard. Has anyone actually verified that it still works? I know I haven't used it for more than a decade. -- Peter Jeremy pgpZ37kea4Ghc.pgp Description: PGP signature
Re: svn commit: r211318 - head/usr.sbin/sysinstall
On 2010-Aug-18 19:30:13 +, Alexey Dokuchaev wrote: >Actually, I did; but the last hunk is just a whitespace change, >irrelevant to the commit message (just as most of the other hunks). >No wonder I missed the hunk before the last one. Probably a good example of why the Project's guidelines require the separation of whitespace and functional changes. -- Peter Jeremy pgpGEmQhdQqnI.pgp Description: PGP signature
Re: svn commit: r212964 - head/sys/kern
[Pruning CC list and re-adding freebsd-arch on the (forlorn) hope that this thread will move to where it belongs] On 2010-Sep-23 07:31:13 -0700, Matthew Jacob wrote: >It turns out that the big issue here was more the savecore time coming >back up rather than the time of dumping. In my experience, the problem isn't so much the savecore time as the time to run /usr/bin/crashinfo. Whilst savecore needs to run early (before anything tramples on the crashdump in swap), the latter could run at any time. It would seem reasonable to either run crashinfo in the background or as a batchjob triggered by /etc/rc.d/savecore. On 2010-Sep-23 18:59:53 +0100, Gavin Atkinson wrote: >I appreciate the issue about filling partitions is a valid one. Would a >possible compromise be that on release media, crashinfo(8) or similar will >default to only keeping the most recent coredump or similar? Given /var >now defaults to 4GB, Defaulting to keeping a single core is probably >acceptable. savecore already has support for a 'minfree' file to prevent crashdumps filling the crashdir. Maybe the default install should include a minfree set to (say) 512MB. -- Peter Jeremy pgpInTLkBu2c7.pgp Description: PGP signature
Re: svn commit: r214489 - head/usr.sbin/bsnmpd/modules/snmp_hostres
On 2010-Oct-28 20:18:26 +, Ulrich Spoerlein wrote: > Fix CPU load reporting independent of scheduler used. That's good. > I'm unsure if some MIB standard states this must be the load average > for, eg. 300s, it looks like net-snmp isn't even bothering to implement > the CPU load reporting at all. I'd be very surprised if there was because (eg) HP Tru64 uses different load average times. -- Peter Jeremy pgppZGrPIN8VV.pgp Description: PGP signature
Re: svn commit: r217538 - in head/sys/dev: buslogic cs
On 2011-Jan-18 15:23:16 +, John Baldwin wrote:
>Log:
> Remove some always-true comparisons.
...
>--- head/sys/dev/cs/if_cs.cTue Jan 18 14:58:44 2011(r217537)
>+++ head/sys/dev/cs/if_cs.cTue Jan 18 15:23:16 2011(r217538)
>@@ -364,7 +364,7 @@ cs_cs89x0_probe(device_t dev)
>
> if (!error && !(sc->flags & CS_NO_IRQ)) {
> if (chip_type == CS8900) {
>- if (irq >= 0 || irq < 16)
>+ if (irq < 16)
> irq = cs8900_irq2eeint[irq];
> else
> irq = 255;
Irrespective of the signedness or otherwise of "irq", I'm fairly
certain that '||' should have been '&&' before.
--
Peter Jeremy
pgpXUXIcy88ql.pgp
Description: PGP signature
Re: svn commit: r218238 - head/sys/dev/ath
On 2011-Feb-04 09:23:01 -0700, Warner Losh wrote:
>On 02/03/2011 16:07, Bruce Cran wrote:
>> On Thu, Feb 03, 2011 at 08:26:26PM +, Adrian Chadd wrote:
>>> if (ni != NULL) {
>>> +#if NOTYET
>>> /* tag AMPDU aggregates for reorder processing */
>> This seems to have broken the build because NOTYET isn't defined.
>
>ANSI C states that all undefined preprocessor variables shall expand to
>0. If we have a warning on that complains, we should turn it off.
Well, bde@ considers it a style bug so from that point of view, the
warning is useful. Also, given that the normal way of stating that
is "#ifdef NOTYET", keeping the warning may help catch code where
the preprocessor variable was supposed to have been defined but has
been misspelt - consider "#if _FreeBSD_version > 800100".
--
Peter Jeremy
pgpMZbmjz1CEH.pgp
Description: PGP signature
Re: svn commit: r224875 - head
On 2011-Aug-15 07:30:48 +, Robert Watson wrote: >Log: > Bump __FreeBSD_version to reflect the availability of capabilities, but > also capability-related changes to fget(9). This is likely not part of > a formal KPI, but the nvidia driver (at least) uses it. Maybe I missed it somewhere but I don't see the version bump anywhere. SVN reports this commit only affects UPDATING. -- Peter Jeremy pgpARYKn6IgMs.pgp Description: PGP signature
Re: svn commit: r221233 - head/sbin/fsck_ffs
On 2011-Apr-29 23:00:23 +, Dag-Erling Smorgrav wrote: >Log: > Add an -E option to mirror newfs's. The idea is that if you have a system ... > MFC after: 3 weeks It's now nearly 4 months later. Was there a technical issue why this wasn't MFC'd or was it just lack of time or oversight? -- Peter Jeremy pgpgEsUmew6wj.pgp Description: PGP signature
Re: svn commit: r226046 - in head: crypto/openssh crypto/openssh/openbsd-compat secure/usr.sbin/sshd
On 2011-Oct-12 14:05:16 +0200, Dag-Erling Smørgrav wrote: >"Bjoern A. Zeeb" writes: >> Mergemaster brought up this change: >> >> +# The default is to check both .ssh/authorized_keys and >> .ssh/authorized_keys2 >> +# but this is overridden so installations will only check >> .ssh/authorized_keys >> +AuthorizedKeysFile .ssh/authorized_keys >> >> This will break setups that have authorized_keys2 files (only) and needs to >> be reverted I think? This is probably a reasonable change in head but, IMHO, it shouldn't be MFC'd. >authorized_keys2 has been deprecated for ~10 years now. I find authorized_keys2 very handy at $work. I have one set of keys that are centrally managed and common across all hosts and a second set of keys that are local to each disjoint subgroup of hosts and managed within each group. Using both authorized_keys and authorized_keys2 substantially simplifies the overall key management. -- Peter Jeremy pgpAdDLGTL3l9.pgp Description: PGP signature
Re: svn commit: r227156 - head/usr.bin/cmp
On 2011-Nov-06 08:14:16 +, Ed Schouten wrote: >Log: > Add missing static keywords to cmp(1) > >Modified: > head/usr.bin/cmp/extern.h > >Modified: head/usr.bin/cmp/extern.h >== >--- head/usr.bin/cmp/extern.h Sun Nov 6 08:14:09 2011(r227155) >+++ head/usr.bin/cmp/extern.h Sun Nov 6 08:14:16 2011(r227156) >@@ -42,4 +42,4 @@ void c_special(int, const char *, off_t, > void diffmsg(const char *, const char *, off_t, off_t); > void eofmsg(const char *); > >-extern int lflag, sflag, xflag; >+extern int lflag, sflag, xflag, zflag; That's an interesting spelling of "static". I presume this is a general cleanup of identifier visibility to prevent unexpected aliasing - in which case a more general log message may have nicer. -- Peter Jeremy pgp1NnvPnC9Bj.pgp Description: PGP signature
Re: svn commit: r227474 - head/sys/amd64/include
On 2011-Nov-12 20:16:07 +, David Chisnall wrote:
> Fix SIGATOMIC_M{IN,AX} on x86-64.
Thanks for that. I have two comments:
1) Could you please wrap your log messages so that lines do not exceed
80 characters.
> /* Limits of sig_atomic_t. */
>-#define SIG_ATOMIC_MIN INT32_MIN
>-#define SIG_ATOMIC_MAX INT32_MAX
>+#define SIG_ATOMIC_MIN LONG_MIN
>+#define SIG_ATOMIC_MAX LONG_MAX
2) As far as I can see, all other defines in _stdint.h, across all
architectures, have explicit lengths, so I believe this would be
better specified as:
#define SIG_ATOMIC_MIN INT64_MIN
#define SIG_ATOMIC_MAX INT64_MAX
--
Peter Jeremy
pgp1lKweyNDep.pgp
Description: PGP signature
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On 2018-Jul-06 09:47:00 -0600, Warner Losh wrote: >On UP systems, these additional opcodes are harmless. They take a few extra >cycles (since they lock an uncontested bus) and add a couple extra memory >barriers (which will be NOPs). On MP systems, atomics now work by default. Atomics in modules used to work by default (at least on x86) - they were explicitly not inlined so that modules on UP systems didn't have to include the lock and barrier instructions that were very expensive on some systems 20 years ago. That said, those systems are (hopefully) all dead now so moving to inlining SMP versions of atomic operations in modules is probably the correct decision now. -- Peter Jeremy signature.asc Description: PGP signature
svn commit: r336406 - head
Author: peterj Date: Tue Jul 17 11:35:40 2018 New Revision: 336406 URL: https://svnweb.freebsd.org/changeset/base/336406 Log: Retrospectively document SVN branch point for stable-11 Approved by: jhb (mentor) Differential Revision:https://reviews.freebsd.org/D16262 Modified: head/UPDATING Modified: head/UPDATING == --- head/UPDATING Tue Jul 17 11:33:23 2018(r336405) +++ head/UPDATING Tue Jul 17 11:35:40 2018(r336406) @@ -654,6 +654,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW: Remove the openbsd_poll system call. __FreeBSD_version has been bumped because of this. +20160708: + The stable/11 branch has been created from head@r302406. + 20160622: The libc stub for the pipe(2) system call has been replaced with a wrapper that calls the pipe2(2) system call and the pipe(2) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r345625 - in head: contrib/elftoolchain/readelf lib/libc lib/libthr libexec/rtld-elf sys/sys
On 2019-Mar-28 09:41:49 -0300, Renato Botelho wrote: >On 3/28/19 4:25 AM, Oliver Pinter wrote: >> On Thursday, March 28, 2019, Ed Maste wrote: >> >>> Author: emaste >>> Date: Thu Mar 28 02:12:32 2019 >>> New Revision: 345625 >>> URL: https://svnweb.freebsd.org/changeset/base/345625 >>> >> Seems like this and the other hunk belongs to a different patch. >Indeed. It broke the build for me No, r345638 broke the build by only reverting one of the two extraneous hunks from this commit. -- Peter Jeremy signature.asc Description: PGP signature
svn commit: r346265 - head/sys/arm/broadcom/bcm2835
Author: peterj
Date: Tue Apr 16 09:42:42 2019
New Revision: 346265
URL: https://svnweb.freebsd.org/changeset/base/346265
Log:
Fix cpufreq(4) on RPI-B
Since r324184 the root node compatible for the original Raspberry Pi
is "brcm,bcm2835", add it to the compatible list of bcm2835_cpufreq.
Tested On: RPi1 Model B
Note that the default Das U-Boot FDT does not include a cpus clause
so actually adding a bcm2835_cpufreq device requires adding a FDT
overlay defining the cpu.
Approved by: grog, jhb (mentors)
MFC after:3 days
Modified:
head/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c
Modified: head/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c
==
--- head/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c Tue Apr 16 05:11:39
2019(r346264)
+++ head/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c Tue Apr 16 09:42:42
2019(r346265)
@@ -126,6 +126,7 @@ static struct ofw_compat_data compat_data[] = {
{ "broadcom,bcm2835-vc",1 },
{ "broadcom,bcm2708-vc",1 },
{ "brcm,bcm2709", 1 },
+ { "brcm,bcm2835", 1 },
{ "brcm,bcm2836", 1 },
{ "brcm,bcm2837", 1 },
{ NULL, 0 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r346266 - head/sys/arm/conf
Author: peterj Date: Tue Apr 16 09:44:46 2019 New Revision: 346266 URL: https://svnweb.freebsd.org/changeset/base/346266 Log: Specify correct Ethernet phy for RPI-B Correct a typo in the RPI-B ethernet config - the RPi-B includes a SMC LAN9512 USB bridge and Ethernet 10/100 NIC/phy. The phy part of this is supported by smscphy. Tested On: RPi1 Model B Approved by: grog, jhb (mentors) MFC after:3 days Modified: head/sys/arm/conf/RPI-B Modified: head/sys/arm/conf/RPI-B == --- head/sys/arm/conf/RPI-B Tue Apr 16 09:42:42 2019(r346265) +++ head/sys/arm/conf/RPI-B Tue Apr 16 09:44:46 2019(r346266) @@ -77,7 +77,7 @@ deviceda device umass # USB ethernet support -device smcphy +device smscphy device mii device smsc ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r347151 - in head: libexec/rtld-elf sys/compat/linux sys/fs/deadfs sys/fs/nfsclient sys/fs/nullfs sys/fs/unionfs sys/kern sys/sys sys/ufs/ufs sys/vm
On 2019-May-05 11:20:44 +, Konstantin Belousov wrote: >Log: > Switch to use shared vnode locks for text files during image activation. This seems to have broken diskless booting on my Rock64 (aarch64). Reverting just this commit fixes the problem. I haven't dug into it yet. dwc0: link state changed to DOWN NFS ROOT: 192.168.12.200:/tank/rock64 dwc0: link state changed to UP Warning: no time-of-day clock registered, system time will not be set accurately Warning: no time-of-day clock registered, system time will not be set accurately exclusive lock of (rw) vm object @ /usr/src/sys/fs/nfsclient/nfs_clvnops.c:3431 while share locked from /usr/src/sys/vm/vm_map.c:521 panic: share->excl cpuid = 3 time = 5 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0x00530cd4 lr = 0x000dedb8 sp = 0x56b1d360 fp = 0x56b1d570 db_trace_self_wrapper() at vpanic+0x18c pc = 0x000dedb8 lr = 0x00275b58 sp = 0x56b1d580 fp = 0x56b1d620 vpanic() at panic+0x44 pc = 0x00275b58 lr = 0x00275920 sp = 0x56b1d630 fp = 0x56b1d6b0 panic() at witness_checkorder+0x1c0 pc = 0x00275920 lr = 0x002d8b1c sp = 0x56b1d6c0 fp = 0x56b1d730 witness_checkorder() at _rw_wlock_cookie+0x74 pc = 0x002d8b1c lr = 0x00270aac sp = 0x56b1d740 fp = 0x56b1d760 _rw_wlock_cookie() at nfs_set_text+0x34 pc = 0x00270aac lr = 0x001dee30 sp = 0x56b1d770 fp = 0x56b1d790 nfs_set_text() at vop_sigdefer+0x68 pc = 0x001dee30 lr = 0x0032b5c0 sp = 0x56b1d7a0 fp = 0x56b1d7c0 vop_sigdefer() at VOP_SET_TEXT_APV+0xd4 pc = 0x0032b5c0 lr = 0x005665ac sp = 0x56b1d7d0 fp = 0x56b1d7f0 VOP_SET_TEXT_APV() at vm_map_entry_set_vnode_text+0x104 pc = 0x005665ac lr = 0x0050044c sp = 0x56b1d800 fp = 0x56b1d850 vm_map_entry_set_vnode_text() at vmspace_fork+0x998 pc = 0x0050044c lr = 0x00506a94 sp = 0x56b1d860 fp = 0x56b1d8b0 vmspace_fork() at fork1+0x498 pc = 0x00506a94 lr = 0x002362cc sp = 0x56b1d8c0 fp = 0x56b1d960 fork1() at sys_fork+0x30 pc = 0x002362cc lr = 0x00235e10 sp = 0x56b1d970 fp = 0x56b1d9b0 sys_fork() at do_el0_sync+0x508 pc = 0x00235e10 lr = 0x0054b694 sp = 0x56b1d9c0 fp = 0x56b1da70 do_el0_sync() at handle_el0_sync+0x84 pc = 0x0054b694 lr = 0x00533200 sp = 0x56b1da80 fp = 0x56b1db90 handle_el0_sync() at 0x221420 pc = 0x00533200 lr = 0x00221420 sp = 0x56b1dba0 fp = 0xe760 KDB: enter: panic [ thread pid 1 tid 12 ] Stopped at 0x28d598: undefined 54000042 db> -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r347151 - in head: libexec/rtld-elf sys/compat/linux sys/fs/deadfs sys/fs/nfsclient sys/fs/nullfs sys/fs/unionfs sys/kern sys/sys sys/ufs/ufs sys/vm
On 2019-May-06 12:09:20 +0300, Konstantin Belousov wrote: >On Mon, May 06, 2019 at 06:56:41PM +1000, Peter Jeremy wrote: >> On 2019-May-05 11:20:44 +, Konstantin Belousov wrote: >> >Log: >> > Switch to use shared vnode locks for text files during image activation. >> >> This seems to have broken diskless booting on my Rock64 (aarch64). >> Reverting just this commit fixes the problem. I haven't dug into it yet. ... >This should be fixed by r347181. I saw r347181 just after I sent my mail. Upgrading to r347182 does fix the problem, thank you. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r347890 - in head/sys/dev: aac bge
On 2019-May-16 20:41:29 +, Tycho Nightingale wrote: >Author: tychon >Date: Thu May 16 20:41:28 2019 >New Revision: 347890 >URL: https://svnweb.freebsd.org/changeset/base/347890 > >Log: > reinstate 4GB DMA boundary workarounds for bge and aac > > Reviewed by: kib > Sponsored by:Dell EMC Isilon > Differential Revision: https://reviews.freebsd.org/D20277 My main concern with this commit is that there is nothing in the commit message explaining why this has been done. D20277 implies that this is effectively reverting a couple of other commits because these devices have 64-bit issues - the commit log should document this. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r347984 - in head/sys: amd64/vmm/io arm/allwinner arm/allwinner/a10 arm/allwinner/clkng arm/arm arm/broadcom/bcm2835 arm/freescale/imx arm/mv arm/mv/armada arm/nvidia arm/nvidia/tegra1
On 2019-May-20 00:38:23 +, Conrad Meyer wrote: >Author: cem >Date: Mon May 20 00:38:23 2019 >New Revision: 347984 >URL: https://svnweb.freebsd.org/changeset/base/347984 > >Log: > Extract eventfilter declarations to sys/_eventfilter.h ... > No functional change (intended). Of course, any out of tree modules that > relied on header pollution for sys/eventhandler.h, sys/lock.h, or > sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped. This seems to have broken at least netmap and netdump for me: /usr/src/sys/dev/netmap/netmap_freebsd.c:191:3: error: implicit declaration of function 'EVENTHANDLER_REGISTER' is invalid in C99 [-Werror,-Wimplicit-function-declaration] EVENTHANDLER_REGISTER(ifnet_arrival_event, ^ ... /usr/src/sys/netinet/netdump/netdump_client.c:1458:22: error: implicit declaration of function 'EVENTHANDLER_REGISTER' is invalid in C99 [-Werror,-Wimplicit-function-declaration] nd_detach_cookie = EVENTHANDLER_REGISTER(ifnet_departure_event, ^ -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r312910 - in head: . etc/etc.pc98 etc/rc.d lib/libsysdecode libexec release release/doc release/doc/en_US.ISO8859-1/hardware release/doc/en_US.ISO8859-1/readme release/doc/share/exampl
On 2017-Feb-01 23:26:21 +, Alexey Dokuchaev wrote: >Well, we're doing something more than devoid any support claims: we're >deliberately breaking it, often for little to no reason. Things like >r431746 are disgrace to FreeBSD and utter disrespect to our users. :-( Actually, that's an excellent commit and I commend amdmi3 on it. It will help both our users and our developers. It clearly states to users that their system is unsupported and explains how they can bypass the check if they know what they are doing. That's far better than users getting strange build or runtime failures that require investigation and potentially emails to work out what's wrong. >That's largely irrelevant and hardly ever causing problems. All needed >make(1) implementations are available in ports; I can still build modern >ports in 8.x tinderbox with WITH_PKGNG=yes/PKGSUFFIX=.txz. And you are doing so in the clear knowledge that what you are doing is not supported by the FreeBSD Project. -- Peter Jeremy signature.asc Description: PGP signature
svn commit: r343953 - head/lib/msun/src
Author: peterj
Date: Sun Feb 10 08:46:07 2019
New Revision: 343953
URL: https://svnweb.freebsd.org/changeset/base/343953
Log:
Replace calls to sin(x) and cos(x) with a single call to sincos().
Replace calls to sinf(x) and cosf(x) with a single call to sincosf().
Submitted by: Steve Kargl
Reviewed by: bde
Approved by: grog
MFC after:3 days
Modified:
head/lib/msun/src/e_j0.c
head/lib/msun/src/e_j0f.c
head/lib/msun/src/e_j1.c
head/lib/msun/src/e_j1f.c
head/lib/msun/src/e_jn.c
Modified: head/lib/msun/src/e_j0.c
==
--- head/lib/msun/src/e_j0.cSun Feb 10 08:41:52 2019(r343952)
+++ head/lib/msun/src/e_j0.cSun Feb 10 08:46:07 2019(r343953)
@@ -93,8 +93,7 @@ __ieee754_j0(double x)
if(ix>=0x7ff0) return one/(x*x);
x = fabs(x);
if(ix >= 0x4000) { /* |x| >= 2.0 */
- s = sin(x);
- c = cos(x);
+ sincos(x, &s, &c);
ss = s-c;
cc = s+c;
if(ix<0x7fe0) { /* Make sure x+x does not overflow. */
@@ -173,8 +172,7 @@ __ieee754_y0(double x)
* sin(x) +- cos(x) = -cos(2x)/(sin(x) -+ cos(x))
* to compute the worse one.
*/
-s = sin(x);
-c = cos(x);
+sincos(x, &s, &c);
ss = s-c;
cc = s+c;
/*
Modified: head/lib/msun/src/e_j0f.c
==
--- head/lib/msun/src/e_j0f.c Sun Feb 10 08:41:52 2019(r343952)
+++ head/lib/msun/src/e_j0f.c Sun Feb 10 08:46:07 2019(r343953)
@@ -55,8 +55,7 @@ __ieee754_j0f(float x)
if(ix>=0x7f80) return one/(x*x);
x = fabsf(x);
if(ix >= 0x4000) { /* |x| >= 2.0 */
- s = sinf(x);
- c = cosf(x);
+ sincosf(x, &s, &c);
ss = s-c;
cc = s+c;
if(ix<0x7f00) { /* Make sure x+x does not overflow. */
@@ -128,8 +127,7 @@ __ieee754_y0f(float x)
* sin(x) +- cos(x) = -cos(2x)/(sin(x) -+ cos(x))
* to compute the worse one.
*/
-s = sinf(x);
-c = cosf(x);
+sincosf(x, &s, &c);
ss = s-c;
cc = s+c;
/*
Modified: head/lib/msun/src/e_j1.c
==
--- head/lib/msun/src/e_j1.cSun Feb 10 08:41:52 2019(r343952)
+++ head/lib/msun/src/e_j1.cSun Feb 10 08:46:07 2019(r343953)
@@ -94,8 +94,7 @@ __ieee754_j1(double x)
if(ix>=0x7ff0) return one/x;
y = fabs(x);
if(ix >= 0x4000) { /* |x| >= 2.0 */
- s = sin(y);
- c = cos(y);
+ sincos(y, &s, &c);
ss = -s-c;
cc = s-c;
if(ix<0x7fe0) { /* make sure y+y not overflow */
@@ -159,8 +158,7 @@ __ieee754_y1(double x)
/* y1(x<0) = NaN and raise invalid exception. */
if(hx<0) return vzero/vzero;
if(ix >= 0x4000) { /* |x| >= 2.0 */
-s = sin(x);
-c = cos(x);
+sincos(x, &s, &c);
ss = -s-c;
cc = s-c;
if(ix<0x7fe0) { /* make sure x+x not overflow */
Modified: head/lib/msun/src/e_j1f.c
==
--- head/lib/msun/src/e_j1f.c Sun Feb 10 08:41:52 2019(r343952)
+++ head/lib/msun/src/e_j1f.c Sun Feb 10 08:46:07 2019(r343953)
@@ -56,8 +56,7 @@ __ieee754_j1f(float x)
if(ix>=0x7f80) return one/x;
y = fabsf(x);
if(ix >= 0x4000) { /* |x| >= 2.0 */
- s = sinf(y);
- c = cosf(y);
+ sincosf(y, &s, &c);
ss = -s-c;
cc = s-c;
if(ix<0x7f00) { /* make sure y+y not overflow */
@@ -114,8 +113,7 @@ __ieee754_y1f(float x)
if(ix==0) return -one/vzero;
if(hx<0) return vzero/vzero;
if(ix >= 0x4000) { /* |x| >= 2.0 */
-s = sinf(x);
-c = cosf(x);
+sincosf(x, &s, &c);
ss = -s-c;
cc = s-c;
if(ix<0x7f00) { /* make sure x+x not overflow */
Modified: head/lib/msun/src/e_jn.c
==
--- head/lib/msun/src/e_jn.cSun Feb 10 08:41:52 2019(r343952)
+++ head/lib/msun/src/e_jn.cSun Feb 10 08:46:07 2019(r343953)
@@ -54,7 +54,7 @@ double
__ieee754_jn(int n, double x)
{
int32_t i,hx,ix,lx, sgn;
- double a, b, temp, di;
+ double a, b, c, s, temp, di;
double z, w;
/* J(-n,x) = (-1)^n * J(n, x), J(n, -x) =
Re: svn commit: r344970 - head
On 2019-Mar-10 09:38:53 -0600, Warner Losh wrote: >On Sun, Mar 10, 2019 at 9:07 AM Alexey Dokuchaev wrote: > >> On Sat, Mar 09, 2019 at 12:00:27PM -0800, Rodney W. Grimes wrote: >> > > New Revision: 344970 >> > > binaries). Failure to do so may leave you with a system that is >> > > hard to boot to recover. A GENERIC kernel will include suitable >> > > - compatibility options to run binaries from older branches. >> > > + compatibility options to run binaries from supported older >> branches. >> > >> > This is probably not the best adjective here, supported only goes back to >> > 11.x, there are COMPAT options that work all the way back to 4. >> >> I concur, this "supported" word sounds like we barely give a fuck. Being >> able to run old (very old) binaries had always been one of our strengths, >> and we should not suggest that it's not anymore. >> > >It isn't saying we don't support older binaries. It sets the limits on what ... >upgrading from. We can (and do) support additional binaries, and having the >clarification here doesn't change that. I think the changed wording implies that we no longer provide compatibity with unsupported branches. I agree that we might in future decide to remove COMPAT_FREEBSDx for unsupported x but until then, I'd prefer wording along the lines of: "A GENERIC kernel will include suitable compatibility options to run binaries from older branches. Note that the ability to run binaries from unsupported branches is not guaranteed." -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 2013-Jun-18 02:53:45 +, Peter Wemm wrote: >Author: peter >Date: Tue Jun 18 02:53:45 2013 >New Revision: 251886 >URL: http://svnweb.freebsd.org/changeset/base/251886 > >Log: > Introduce svnlite so that we can check out our source code again. Somewhat late and to take a tack that wasn't used in the previous thread... This means we now have 2 copies of SQLite in base - there was already an older one in Heimdal. Is there any chance that we could make Heimdal use the newly added SQLite? (I'm not suggesting peter@ does this, just wondering if there's a reason for not getting rid of one copy of SQLite). (I'm concerned in general at the duplication of code in base - we already have about 4 copies of gzip and 2 different IEEE floating point emulators). -- Peter Jeremy pgpHTT8c0y97Z.pgp Description: PGP signature
Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil
On 2014-Feb-21 07:26:49 +, Baptiste Daroussin wrote: >Log: > Import Dragonfly Mail Agent into base system I would like to suggest that 'dma' is a _really_ bad name for any utility. As has been mentioned, 'DMA' has had a well-entrenched meaning for decades and overloading to also refer to a MTA is not going to end well. I'd also query the reason for including Debian-specific code in the FreeBSD base. -- Peter Jeremy pgpmzMVf62Z1f.pgp Description: PGP signature
Re: svn commit: r262282 - in head: contrib/dma contrib/dma/debian contrib/dma/debian/migrate contrib/dma/debian/source contrib/dma/test etc/mtree libexec libexec/dma share/mk tools/build/mk tools/buil
On 2014-Feb-22 13:14:38 +0100, Baptiste Daroussin wrote: >On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote: >> I'd also query the reason for including Debian-specific code in the >> FreeBSD base. >Where have you seen debian specific code? /usr/src/contrib/dma/debian - as far as I can tell, this directory is Debion specific. I thought we stripped out irrelevant code from third party imports but looking wider, there is similarly irrelevant code in a variety of other contrib imports. I'll withdraw that objection. -- Peter Jeremy pgpV04w7lNV4M.pgp Description: PGP signature
svn commit: r275298 - head/share/man/man4
Author: peterj Date: Sun Nov 30 04:50:13 2014 New Revision: 275298 URL: https://svnweb.freebsd.org/changeset/base/275298 Log: Cross reference tap(4) and tun(4) and include a short explanation as to how they differ. This will assist users in selecting which interface is more appropriate for their purposes. Approved by: grog (co-mentor) MFC after:2 week Modified: head/share/man/man4/tap.4 head/share/man/man4/tun.4 Modified: head/share/man/man4/tap.4 == --- head/share/man/man4/tap.4 Sun Nov 30 03:02:20 2014(r275297) +++ head/share/man/man4/tap.4 Sun Nov 30 04:50:13 2014(r275298) @@ -1,7 +1,7 @@ .\" $FreeBSD$ .\" Based on PR#2411 .\" -.Dd November 4, 2014 +.Dd November 30, 2014 .Dt TAP 4 .Os .Sh NAME @@ -34,6 +34,17 @@ or a terminal for and a character-special device .Dq control interface. +A client program transfers Ethernet frames to or from the +.Nm +.Dq control +interface. +The +.Xr tun 4 +interface provides similar functionality at the network layer: +a client will transfer IP (by default) packets to or from a +.Xr tun 4 +.Dq control +interface. .Pp The network interfaces are named .Dq Li tap0 , @@ -314,4 +325,5 @@ VMware .El .Sh SEE ALSO .Xr inet 4 , -.Xr intro 4 +.Xr intro 4 , +.Xr tun 4 Modified: head/share/man/man4/tun.4 == --- head/share/man/man4/tun.4 Sun Nov 30 03:02:20 2014(r275297) +++ head/share/man/man4/tun.4 Sun Nov 30 04:50:13 2014(r275298) @@ -2,7 +2,7 @@ .\" $FreeBSD$ .\" Based on PR#2411 .\" -.Dd February 4, 2007 +.Dd November 30, 2014 .Dt TUN 4 .Os .Sh NAME @@ -35,6 +35,17 @@ or a terminal for and a character-special device .Dq control interface. +A client program transfers IP (by default) packets to or from the +.Nm +.Dq control +interface. +The +.Xr tap 4 +interface provides similar functionality at the Ethernet layer: +a client will transfer Ethernet frames to or from a +.Xr tap 4 +.Dq control +interface. .Pp The network interfaces are named .Dq Li tun0 , @@ -307,6 +318,7 @@ them pile up. .Xr inet 4 , .Xr intro 4 , .Xr pty 4 , +.Xr tap 4 , .Xr ifconfig 8 .Sh AUTHORS This manual page was originally obtained from ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r260188 - head/sys/netinet
On 2014-Jan-02 10:18:40 +, Gleb Smirnoff wrote: >Log: > Fix regression from r249894. Now we pass "gw" as argument to if_output > method, thus for multicast case we need it to point at "dst". > > PR: 185395 > Submitted by:ae Thank you for that. I'd gotten as far as working out that r249894 was the probable cause but not come up with a patch. Given that it breaks IPv4 multicast, I'm surprised no-one else noticed it in the past 8 months. (My excuse is that I only tried to use multicast for the first time yesterday). And, whilst it's _really_ late in the 10.0 release cycle, I'm not sure we want to roll a release with broken multicast. -- Peter Jeremy pgp2NmtUnk4Au.pgp Description: PGP signature
Re: svn commit: r277652 - in head/usr.sbin/pw: . tests
On 2015-Jan-25 18:36:40 +0300, Slawa Olhovchenkov wrote: >On Mon, Jan 26, 2015 at 02:31:05AM +1100, Bruce Evans wrote: > >> On Sun, 25 Jan 2015, Slawa Olhovchenkov wrote: >> > This is not full true for ZFS case. >> > On ZFS nobody is 2^32-2. Can you please provide a reference to this in the code. I can't find anything in the ZFS code to suggest either '-2' or 4294967294 is used as a special GID or UID. The only references I can find are to UID_NOBODY and GID_NOBODY - both of which are defined as 65534 in . >ls -l /usr/ports/packages32/lang >total 2 >lrwxr-xr-x 1 4294967294 wheel 33 Mar 17 2012 perl-threaded-5.12.4_4.tbz -> >../All/perl-threaded-5.12.4_4.tbz >lrwxr-xr-x 1 4294967294 wheel 27 Mar 17 2012 python27-2.7.2_4.tbz -> >../All/python27-2.7.2_4.tbz >lrwxr-xr-x 1 4294967294 wheel 21 Mar 17 2012 tcl-8.5.11.tbz -> >../All/tcl-8.5.11.tbz >lrwxr-xr-x 1 4294967294 wheel 29 Mar 17 2012 tcl-modules-8.5.11.tbz -> >../All/tcl-modules-8.5.11.tbz All this means is that you have some files with that uid. It's not clear how they were created. -- Peter Jeremy pgpqGPRNMM0Af.pgp Description: PGP signature
Re: svn commit: r277652 - in head/usr.sbin/pw: . tests
On 2015-Jan-25 22:29:26 +0300, Slawa Olhovchenkov wrote: >I think this is result of convert (signed short) to (signed int). > >> >ls -l /usr/ports/packages32/lang >> >total 2 >> >lrwxr-xr-x 1 4294967294 wheel 33 Mar 17 2012 perl-threaded-5.12.4_4.tbz >> >-> ../All/perl-threaded-5.12.4_4.tbz >> >lrwxr-xr-x 1 4294967294 wheel 27 Mar 17 2012 python27-2.7.2_4.tbz -> >> >../All/python27-2.7.2_4.tbz >> >lrwxr-xr-x 1 4294967294 wheel 21 Mar 17 2012 tcl-8.5.11.tbz -> >> >../All/tcl-8.5.11.tbz >> >lrwxr-xr-x 1 4294967294 wheel 29 Mar 17 2012 tcl-modules-8.5.11.tbz -> >> >../All/tcl-modules-8.5.11.tbz >> >> All this means is that you have some files with that uid. It's not >> clear how they were created. > >nfs3 export ZFS dataset to VM. VM do write as 'root'. root maped to >nobody. When this is created -- host 9.1, VM -- 6.x. I can reproduce this with FreeBSD 10/r276177 client and server running NFSv3 using the "new" NFS code. It appears to be due to the (broken) initialisation of def_anon in mountd(8) with '(uid_t)-2' - as noted by bde. It's nothing to do with ZFS. -- Peter Jeremy pgp5sYqdZFoIr.pgp Description: PGP signature
Re: svn commit: r279814 - head/sys/arm/conf
On 2015-Mar-09 09:58:36 -0600, Ian Lepore wrote: >Can we not do this, and instead just build all modules? I'm not sure >why we eliminate or override modules on some armv6 socs and not on >others, but I think it's a concept that's past it's sell-by date now. >If there are a few specific modules that aren't good for arm, we should >be fixing that in the modules makefiles. For the most popular ARM SoCs, I'd suggest that about half of the modules don't make sense: There's no ISA or PCI bus available so there's no point in compiling modules that depend on either. -- Peter Jeremy pgptCS0b58IlA.pgp Description: PGP signature
Re: svn commit: r280120 - head/sys/dev/wpi
On 2015-Mar-15 14:35:23 -0700, Adrian Chadd wrote: >.. promise I'm done for now. 69 commits (68 to the same file) and the perfect sequence only broken by pav@ and jilles@. I think you deserve some sort of reward. -- Peter Jeremy pgp3zSX3Ppitu.pgp Description: PGP signature
Re: svn commit: r280727 - in head: share/mk sys/conf
On 2015-Mar-27 13:00:14 +0300, Slawa Olhovchenkov wrote: >On Fri, Mar 27, 2015 at 02:35:12AM +, Warner Losh wrote: > >> Author: imp >> Date: Fri Mar 27 02:35:11 2015 >> New Revision: 280727 >> URL: https://svnweb.freebsd.org/changeset/base/280727 >> >> Log: >> Add support for specifying unsupported / broken options that override >> any defaults or user specified actions on the command line. This would >> be useful for specifying features that are always broken or that >> cannot make sense on a specific architecture, like ACPI on pc98 or >> EISA on !i386 (!x86 usage of EISA is broken and there's no supported >> hardware that could have it in any event). Any items in >> __ALWAYS_NO_OPTIONS are forced to "no" regardless of other settings. > >Alpha 21064 support EISA. As linimon pointed out, FreeBSD no longer supports Alpha. >FreeBSD support Digi EISA card. The digi(4) driver was removed from FreeBSD because it wasn't adapted for TTYng. I had some patches for PCI digi cards (see pr/152253 and pr/158086) but no longer have access to the hardware. I don't recall seeing any references to EISA support and can only find PCA and ISA code. -- Peter Jeremy pgpisKExOD1Q4.pgp Description: PGP signature
Re: svn commit: r303811 - in head/sys: net net80211
On 2016-Aug-07 11:03:23 +0200, Hans Petter Selasky wrote: >On 08/07/16 05:48, Adrian Chadd wrote: >> +#define ETHER_IS_BROADCAST(addr) \ >> +(((addr)[0] & (addr)[1] & (addr)[2] & \ >> + (addr)[3] & (addr)[4] & (addr)[5]) == 0xff) >> >The compiler might be able to produce more optimal code if you use "+" >instead of "&", because there are instructions on x86, that can add >multiple variables at the same time. With "&" you need to process every >one as a single instructions usually I think. > > > +#defineETHER_IS_BROADCAST(addr) \ > > + (((addr)[0] + (addr)[1] + (addr)[2] + \ > > + (addr)[3] + (addr)[4] + (addr)[5]) == (6*0xff)) IMHO, Adrian's code is clearer and micro-optimisations like this belong in the complier, not the code. There are lots of alternative ways you could write the macro and, unless you can demonstrate that the micro- optimisation is worthwhile, you should pick the one that is clearer to the software maintainer. If you want to make a few more assumptions (64-bit unaligned little-endian architecture with at least 2 accessible bytes beyond the address), the following has the added advantage of only referencing (addr) once. (I'm not suggesting it as a replacement though). #define ETHER_IS_BROADCAST(addr) \ ((*(const long *)(addr) & 0x00ffl) == 0x00ffl) -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r303716 - head/crypto/openssh
On 2016-Aug-07 15:25:54 +0300, Andrey Chernov wrote: >You should address your complains to original openssh author instead, it >was his decision to get rid of weak algos. No. It's up to the person who imported the code into FreeBSD to understand why the change was made and to be able to justify it to the FreeBSD community. Firstly, security is not absolute - it's always a cost-benefit tradeoff and different communities may make different tradeoffs. Secondly, the importer needs to be confident that the code is actually an improvement, not an attempt by a bad actor to undermine security. > In my personal opinion, if >your hardware is outdated, just drop it out. This is part of the cost-benefit analysis. Replacing hardware has a real cost. If it's inside a datacentre, where the management LAN is isolated from the rest of the world, there may be virtually no benefit to disabling "weak" ciphers. >We can't turn our security >team into compatibility team, by constantly restoring removed code, such >code quickly becomes outdated and may add new security holes even being >inactive. OTOH, FreeBSD has a documented deprecation process that says things will continue working for a major release after being formally deprecated. I don't believe there was any mention about DSA being deprecated before now so I would expect there to be a clearly documented process to restore the ability for a FreeBSD-11 ssh client to talk to a server using 1024-bit DSA. Note that the handbook still talks about using DSA - that needs updating as well. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf
On 2016-Aug-20 07:51:55 -0700, John Baldwin wrote: >- tty drivers that haven't been updated to new tty and have been disconnected > from the build since 8.0 including digi(4) and cy(4). I know Bruce has > patches for sio(4) that I just haven't merged, so I'm inclined to leave > sio(4), but the other disconnected drivers are candidates I think. I have digi(4) patches but no longer have any digi cards. Judging by the time since they were disconnected, I think they can be deleted. -- Peter Jeremy signature.asc Description: PGP signature
Re: svn commit: r297902 - head
On 2016-Apr-13 01:47:05 +, Steve Wills wrote:
>+.if !defined(SVN) || empty(SVN)
>+. for _P in /usr/bin /usr/local/bin
>+. for _S in svn svnlite
>+. if exists(${_P}/${_S})
>+SVN= ${_P}/${_S}
>+. endif
>+. endfor
>+. endfor
>+.endif
What is the preferred choice here? The given order prefers ports over base
(which makes sense) but then prefers svnlite over svn. I would expect
either the opposite directory order in _P (prefer svnlite in base) or the
opposite command order in _S (prefer svn in ports).
In normal use, this will wind up with either /usr/local/bin/svn or
/usr/bin/svnlite (in that order) but a non-standard configuration could
result in different results.
--
Peter Jeremy
signature.asc
Description: PGP signature
Re: svn commit: r284711 - head/sys/netinet
On 2015-Jun-22 15:24:20 -0700, NGie Cooper wrote: >On Mon, Jun 22, 2015 at 3:20 PM, Ian Lepore wrote: >... >> I think this is a bad idea. "iff" means "if and only if" in mathematics >> and formal logic. Comments are written in English. > >It should have been capitalized if it was an acronym. It's not an acronym. I've only ever seen it written as 'iff'. -- Peter Jeremy pgpwUzM9GtUbM.pgp Description: PGP signature
Re: svn commit: r285439 - head/sys/dev/random
On 2015-Jul-13 08:38:21 +, Mark Murray wrote: >+ /* >+ * Belt-and-braces. >+ * Round up the read length to a crypto block size >multiple, >+ * which is what the underlying generator is expecting. >+ * See the random_buf size requirements in the >Yarrow/Fortuna code. >+ */ >+ read_len += RANDOM_BLOCKSIZE; >+ read_len -= read_len % RANDOM_BLOCKSIZE; Note that if read_len was already a multiple of RANDOM_BLOCKSIZE, this will pad it by an additional RANDOM_BLOCKSIZE. I don't think this matters but it's not what the comment implies. (The comment also goes over 80 columns). -- Peter Jeremy pgpVYCudlMOLy.pgp Description: PGP signature
Re: svn commit: r285644 - head/contrib/sqlite3
On 2015-Jul-16 22:07:14 +, "Pedro F. Giffuni" wrote: >Log: ... > sqlite: clean a couple of invocations of memcpy(3) > > Found almost accidentally by our native gcc when enhanced with > FORTIFY_SOURCE. ... >- memcpy((void *)&aHdr[1], (void *)&pWal->hdr, sizeof(WalIndexHdr)); >+ memcpy((void *)&aHdr[1], (const void *)&pWal->hdr, sizeof(WalIndexHdr)); > walShmBarrier(pWal); >- memcpy((void *)&aHdr[0], (void *)&pWal->hdr, sizeof(WalIndexHdr)); >+ memcpy((void *)&aHdr[0], (const void *)&pWal->hdr, sizeof(WalIndexHdr)); If the compiler complained about that, the compiler is broken. 'const' is a promise to the caller that the given parameter will not be modified by the callee. There's no requirement that the passed argument be const. As bde commented, the casts are all spurious. -- Peter Jeremy pgpPxoiGTYYng.pgp Description: PGP signature
Re: svn commit: r234403 - head/sys/net
On 2012-Apr-18 01:39:14 +, Andrew Thompson wrote: >Log: > Remove KASSERTS, they do not add any value here since the pointer is about to > be derefernced anyway. Could you give a bit more background to this commit. You get a crash in both cases but the KASSERT() at least tells you which variable was NULL without needing to trawl through the crashdump to find what caused the NULL pointer dereference trap. -- Peter Jeremy pgpsXLkOs02z8.pgp Description: PGP signature
Re: svn commit: r234528 - head/lib/libc/stdio
On 2012-Apr-21 06:08:02 +, David Schultz wrote: >Log: > Fix a bug introduced in r187302 that was causing fputws() to enter an > infinite loop pretty much unconditionally. Unfortunately, I suspect you've just turned an unconditional infinite loop into a conditional one. There's still a "wsp = ws;" inside the loop so if you pass in a long string (one that exceeds BUFSIZ bytes when converted to a multi-byte string) then wsp will be non-NULL after the call to __wcsnrtombs(), causing the do loop to loop and then wsp will be re-initialised to ws. I think the fix is to move the "wsp = ws;" outside the loop. > It's remarkable that the > patch that introduced the bug was never tested, but even more > remarkable that nobody noticed for over two years. It took me a while to work out that the problem was libc and not my code. -- Peter Jeremy pgpyUQzHJGejA.pgp Description: PGP signature
Re: svn commit: r233925 - in head: sys/kern sys/sys sys/vm usr.bin/kdump usr.bin/ktrace
On 2012-Apr-05 17:13:14 +, John Baldwin wrote: >Log: > Add new ktrace records for the start and end of VM faults. This gives > a pair of records similar to syscall entry and return that a user can > use to determine how long page faults take. The new ktrace records are > enabled via the 'p' trace type, and are enabled in the default set of > trace points. I've just found a case where this is very useful but I find that the PFLT/PRET entries are clutter much of the time and would suggest that they be off by default. > MFC after: 2 weeks This expired some time ago, do you intend to MFC these changes in the near future? -- Peter Jeremy pgpOmnDjf6jih.pgp Description: PGP signature
svn commit: r240548 - in head: share/misc usr.bin/calendar/calendars
Author: peterj Date: Sun Sep 16 06:44:58 2012 New Revision: 240548 URL: http://svn.freebsd.org/changeset/base/240548 Log: - Add myself as a new src committer. - Sort jhb's mentees - Add grog's (ex-)mentor Approved by: jhb (co-mentor), grog (co-mentor) Modified: head/share/misc/committers-src.dot head/usr.bin/calendar/calendars/calendar.freebsd Modified: head/share/misc/committers-src.dot == --- head/share/misc/committers-src.dot Sun Sep 16 06:01:34 2012 (r240547) +++ head/share/misc/committers-src.dot Sun Sep 16 06:44:58 2012 (r240548) @@ -215,6 +215,7 @@ obrien [label="David E. O'Brien\nobrien@ olli [label="Oliver Fromme\no...@freebsd.org\n2008/02/14"] peadar [label="Peter Edwards\npea...@freebsd.org\n2004/03/08"] peter [label="Peter Wemm\npe...@freebsd.org\n/??/??"] +peterj [label="Peter Jeremy\npet...@freebsd.org\n2012/09/14"] pfg [label="Pedro Giffuni\n...@freebsd.org\n2011/12/01"] philip [label="Philip Paeps\nphi...@freebsd.org\n2004/01/21"] phk [label="Poul-Henning Kamp\n...@freebsd.org\n1994/02/21"] @@ -396,6 +397,7 @@ gnn -> davide grog -> edwin grog -> le +grog -> peterj imp -> akiyama imp -> ambrisko @@ -439,9 +441,11 @@ jhb -> arr jhb -> avg jhb -> jeff jhb -> kbyanc -jhb -> rnoland +jhb -> peterj jhb -> pfg +jhb -> rnoland +jkh -> grog jkh -> imp jkh -> jlemon jkh -> joerg Modified: head/usr.bin/calendar/calendars/calendar.freebsd == --- head/usr.bin/calendar/calendars/calendar.freebsdSun Sep 16 06:01:34 2012(r240547) +++ head/usr.bin/calendar/calendars/calendar.freebsdSun Sep 16 06:44:58 2012(r240548) @@ -119,6 +119,7 @@ 04/03 Tong Liu born in Beijing, People's Republic of China, 1981 04/03 Gabor Pali born in Kunhegyes, Hungary, 1982 04/05 Stacey Son born in Burley, Idaho, United States, 1967 +04/06 Peter Jeremy born in Sydney, New South Wales, Australia, 1961 04/07 Edward Tomasz Napierala born in Wolsztyn, Poland, 1981 04/08 Jordan K. Hubbard born in Honolulu, Hawaii, United States, 1963 04/09 Ceri Davies born in Haverfordwest, Pembrokeshire, United Kingdom, 1976 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r241221 - in head: contrib/tcpdump usr.sbin/tcpdump/tcpdump
On 2012-Oct-05 07:51:21 +, Gleb Smirnoff wrote: >Provide ability for printing and decoding pfsync(4) traffic. This > doesn't mean supporting IFT_PFSYNC (which I hope will eventually > die). This means decoding packets with IP protocol of 240 caught > on any normal interface like Ethernet. You might like to look at bin/124825 as well. -- Peter Jeremy pgpFEsnxzNhtD.pgp Description: PGP signature
svn commit: r241708 - head/etc
Author: peterj Date: Thu Oct 18 22:20:02 2012 New Revision: 241708 URL: http://svn.freebsd.org/changeset/base/241708 Log: Explicitly specify 'np' so that getty(8) does not simulate even parity on local.9600. Whilst the actual binary termios(4) definitions and preceeding comments for local.9600 indicate that parity is disabled, getty(8) internally simulates parity based on the presence or absence of the 'np' flag. PR: conf/76226 Submitted by: peter Approved by: grog (co-mentor) MFC after:1 month Modified: head/etc/gettytab Modified: head/etc/gettytab == --- head/etc/gettytab Thu Oct 18 22:19:00 2012(r241707) +++ head/etc/gettytab Thu Oct 18 22:20:02 2012(r241708) @@ -96,7 +96,7 @@ local.9600|CLOCAL tty @ 9600 Bd:\ :o0#0x0007:o1#0x0002:o2#0x0007:\ :i0#0x0704:i1#0x:i2#0x0704:\ :l0#0x05cf:l1#0x:l2#0x05cf:\ - :sp#9600: + :sp#9600:np: # # Dial in rotary tables, speed selection via 'break' ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r242402 - in head/sys: kern vm
On 2012-Oct-31 18:57:37 +, Attilio Rao wrote: >On 10/31/12, Adrian Chadd wrote: >> Right, but you didn't make it configurable for us embedded peeps who >> still care about memory usage. > >How is this possible without breaking the module/kernel ABI? Memory usage may override ABI compatibility in an embedded environment. >All that assuming you can actually prove a real performance loss even >in the new cases. The issue with padding on embedded systems is memory utilisation rather than performance. -- Peter Jeremy pgpX2JHZy0tEP.pgp Description: PGP signature
Re: svn commit: r242625 - in head/sys: dev/ale dev/ata dev/ata/chipsets dev/ath/ath_hal/ar5212 dev/bge dev/cas dev/dc dev/flash dev/fxp dev/gem dev/lge dev/mii dev/nge dev/pci dev/re dev/sis dev/ste d
On 2012-Nov-05 23:45:00 +0100, Dimitry Andric wrote: >On 2012-11-05 23:36, Adrian Chadd wrote: >> I'm fine with the change, but why didn't you run this by the various >> driver owners first before doing a drive-by commit? > >The change was trivial, and did not cause any binary difference. I see >no reason to bother 20 different maintainers with something like this, >except bureaucratic ones... :) A bit belated but I think you've missed the most important reason why you should warn maintainers: You can be creating additional effort for maintainers. There is an ongoing push to make head more stable by pushing experimental development into "private" branches which can then be merged back to head once the functionality is stable. Whilst there may not be a binary difference, you are creating source changes. If you've changed something that a maintainer is actively working on, they need to take the time to work out if the change is still relevant and whether it impacts the testing they have done. -- Peter Jeremy pgpu5eCghInCr.pgp Description: PGP signature
Re: svn commit: r242102 - in head: contrib/bmake usr.bin/bmake
[A bit delayed] On 2012-Nov-15 02:41:22 -0600, "Matthew D. Fuller" wrote: >On Thu, Nov 15, 2012 at 06:07:27PM +1100 I heard the voice of >Bruce Evans, and lo! it spake thus: >> >> Maybe malloc() would be faster with MALLOC_PRODUCTION. I use >> /etc/malloc.conf -> aj locally. freefall doesn't have >> /etc/malloc.conf. MALLOC_OPTIONS no longer works, and MALLOC_CONF >> is too large for me to understand, so I don't know how to turn off >> non-production features dynamically. > >FWIW, I suspected MALLOC_PRODUCTION in some massive slowdowns I see >from time to time on my -CURRENT box. Most vividly around running >portupgrade-related bits (portupgrade, pkgdb, etc). I got annoyed by >it enough a few weeks ago to write up a quickie to bang malloc() >around and see what happened. Attached, just for grins. Not defining MALLOC_PRODUCTION causes quite significant startup costs for any process that uses malloc() at all. In this case, jemalloc verifies that memory obtained from the kernel is zero-filled, causing (thousands of unnecessary) page faults. For a short-running process that doesn't allocate all the space in the jemalloc arenas, this dominates the runtime - in the case of /bin/echo, I measured 87 page faults with MALLOC_PRODUCTION and 2133 without. -- Peter Jeremy pgphpUgGtnqNK.pgp Description: PGP signature
Re: svn commit: r244112 - head/sys/kern
[pruning the CC list] On 2012-Dec-15 21:52:03 +0100, Pawel Jakub Dawidek wrote: >On Wed, Dec 12, 2012 at 04:02:58PM -0800, Navdeep Parhar wrote: >> A KASSERT() really is for a condition that should never happen. and can't be practically recovered from. >I have sort of mixed feelings about this change, but in reality we have >three cases: > >1. Fatal conditions that shouldn't happen, but may happen for some > reason and we definiately want to stop running (corrupted file system > metadata that can mess up the file system more badly). For those we have > direct panic(9) calls. > >2. Fatal conditions that cannot happen and for those we have KASSERT(9). I don't see the difference between these two cases. In both of them, the system has entered a state that the designer/programmer didn't envisage and can't recover from. The best option is to abort as quickly to minimise further corruption. >3. Non-fatal conditions that cannot happen, which we have no way to > report more gracefully and we do it through KASSERT(9). "Cannot" needs to be quoted here because you can't hit them unless they actually do happen. And: 4. Unexpected conditions that should be non-fatal but no-one has written the code to recover so someone has included a KASSERT(9) as a place-holder. I suspect a lot of the heat in this discussion is associated with points 3 & 4 - unexpected conditions that the code can't cope with. >It is annoying to run INVARIANTS kernel and trigger 3. I had this >problem few times, for example in TCP/IP stack. It turned out to be >non-fatal and KASSERT(9) was there to understand the code better. >I'd much prefer to see it logged than to panic my box. Of course it is >also sometimes hard to judge if it is fatal or not. > >I use plenty of assertions in my code to catch bugs early, but >assertions like any other part of the code might have bugs and during >rapid development they help a lot when the code around is changing a lot >and some earlier assumptions are no longer valid. Many of those >assertions are non-fatal. IMHO, having lots of assertions (ala design-by-contract) can make it easier to understand a function's interfaces. Of course, if there are errors in the interface conditions, you can wind up with spurious panic()s. >For me this problem is pretty complex, because: > >1. It would be nice to have a macro to test non-fatal conditions, This should be fairly trivial to implement - test the specified condition and if it's false print out a rate-limited message and backtrace. > but it > is hard to tell sometimes if it is fatal or not. As a rule of thumb, if the code can't handle the condition not being met then it's fatal - this includes my point 4 above. If the code can recover (which may require it to take drastic action like aborting a process or closing a socket) then it's not fatal. OTOH, IMHO, not holding an expected lock _is_ fatal, even if there's no immediately obvious downside to just continuing. >3. Logging non-fatal "assertions" might make them go unnoticed, but we > currently don't enable kernel dumps by default, so when panic occurs > user has no idea what has happend, especially if he is in X. Logging > would give better chance to actually notice the problem currently. Rebooting does mean that we restore the system to a sane state, even if we don't record the previous state. >In my opinion we should do the following: > >1. Leave the option to make KASSERTs non-fatal, but log big fat warning > that this is development feature and should not be used in production. I disagree with this but not strongly enough to say it should be backed out. IMHO, an active KASSERT() should be fatal. >2. Introduce handy macro that would log the problem, but won't panic the > box for non-fatal conditions, just like we do with LORs. Agreed. >3. Enable kernel dumps by default. The main obstacle to do that was lack > of a way to limit number of kernel dumps, which could lead to filling > /var/ after hitting some panic/reboot cycle. I agree that it's reasonable to enable crashdumps by default. Note that /var/crash/minfree is supposed to stop /var filling up. >My contribution to solve this is implementation of 3: > http://people.freebsd.org/~pjd/patches/savecore.patch Adding a "maxdumps" parameter seems a good idea. The behaviour when it hits the limit is less clear - throwing away the latest crashdump is probably as easy to justify as throwing away the oldest one. A further downside to enabling crashdumps is the time overhead - initially writing the dump, copying it to /var/crash and running crashinfo. This all directly increases the length of the outage. -- Peter Jeremy pgp5wkhrNBmFs.pgp Description: PGP signature
Re: svn commit: r244469 - head/sys/arm/arm
On 2012-Dec-20 00:35:27 +, Olivier Houchard wrote: >Author: cognet >Date: Thu Dec 20 00:35:26 2012 >New Revision: 244469 >URL: http://svnweb.freebsd.org/changeset/base/244469 > >Log: > Use the new allocator in bus_dmamem_alloc(). > >Modified: > head/sys/arm/arm/busdma_machdep-v6.c Do you have any plans to make similar changes to the other busdma_machdep.c files? -- Peter Jeremy pgpZzphQqYmZT.pgp Description: PGP signature
Re: svn commit: r234352 - in head/sys: amd64/linux32 compat/linux i386/linux kern
On 2012-Apr-16 21:22:02 +, Jung-uk Kim wrote: >Log: > - Implement pipe2 syscall for Linuxulator. This syscall appeared in 2.6.27 > but GNU libc used it without checking its kernel version, e. g., Fedora 10. Recent versions of flash are complaining about the lack of pipe2(). Do you have any plans to MFC this? I've had a quick look but there are non-trivial conflicts in kern/sys_pipe.c on both 8.x & 9.x and I don't want to spend time resolving them if you have already done so. -- Peter Jeremy pgppROok72FQy.pgp Description: PGP signature
Re: svn commit: r238722 - in head/lib/msun: . ld128 ld80 man src
On 2012-Jul-24 13:57:12 -0400, David Schultz wrote: >On Tue, Jul 24, 2012, Steve Kargl wrote: >> On Tue, Jul 24, 2012 at 08:43:35AM +, Alexey Dokuchaev wrote: >> > On Mon, Jul 23, 2012 at 07:13:56PM +, Steve Kargl wrote: >> > > Compute the exponential of x for Intel 80-bit format and IEEE 128-bit >> > > format. These implementations are based on >> > I believe some ports could benefit from OSVERSION bump for this one. ... >against. In this case, it would help any ports that have >workarounds for the lack of expl() to compile both before and >after this change. But it's also important not to bump the >version gratuitously if there's no reason to believe the change >might introduce incompatibilities. Hopefully, this is just the first of a series of similar commits over the next 4-5 months so if we bump OSVERSION for this, we are probably looking at another half-dozen or so bumps. Do any ports actually have a hard-wired decision for expl() (or other libm functions)? I would hope most ports that are interested in complex and/or long double functions have some sort of configure-time test that will automatically detect their presence or absence. -- Peter Jeremy pgpiJePWz6zye.pgp Description: PGP signature
Re: svn commit: r239077 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 2012-Aug-05 22:52:46 +0200, Marius Strobl wrote: >Bascially, "options ZFS" is available on at least amd64, i386, pc98, >powerpc64 and sparc64. At least in theory. In practise, it's not usable because: >powerpc). However, this causes linking the kernel to fail due to some >symbols being defined multiple times: ... >I currently can't remember the details but the fix seemed non-trivial >to me, short of creating something like LINT-ZFS kernel config files >similar to the LINT-VIMAGE etc we have. The underlying problem is that there are 2 zlib's in the kernel tree. One is in sys/cddl/contrib/opensolaris/uts/common/zmod/ and the other is sys/net/zlib.c. The real fix is to get rid of one of them and use the remaining one for all subsystems that want zlib. I agree that merging them is non-trivial because they are based on different versions of zlib (1.2.3 & 1.0.4, respectively) and the original files have been munged is different ways. (And there's a third inflate(9) based on unzip-5.12 in sys/kern/inflate.c, as well as another complete zlib-1.2.7 in lib/libz) -- Peter Jeremy pgpHOcGlx1AxP.pgp Description: PGP signature
Re: svn commit: r238536 - head/sys/vm
On 2012-Jul-16 18:13:43 +, Alan Cox wrote: > Various improvements to vm_contig_grow_cache(). Most notably, even when > it can't sleep, it can still move clean pages from the inactive queue to > the cache. Also, when a page is cached, there is no need to restart the > scan. The "next" page pointer held by vm_contig_launder() is still > valid. Finally, add a comment summarizing what vm_contig_grow_cache() > does based upon the value of "tries". > > MFC after: 3 weeks I realise 3 weeks is only just up but I'm wondering if you intend to MFC this (and hopefully r238456) soon. I've had a quick try at merging this back to 8.x but it relies on vm_pageout_page_lock() and vm_page_unlock() which were added in r207694 and I'm not sure about the impact of merging that. -- Peter Jeremy pgpScNm7Hck6X.pgp Description: PGP signature
Re: svn commit: r239301 - in head/sys: kern nlm sys
On 2012-Aug-15 15:56:21 +, Konstantin Belousov wrote:
> Add a sysctl kern.pid_max, which limits the maximum pid the system is
> allowed to allocate, and corresponding tunable with the same
> name. Note that existing processes with higher pids are left intact.
Sorry for not picking this up when you first posted the patch but I
think you need to place a lower bound on max_pid to prevent the system
being rendered unusable.
>Modified: head/sys/kern/kern_fork.c
>==
>--- head/sys/kern/kern_fork.c Wed Aug 15 15:53:27 2012(r239300)
>+++ head/sys/kern/kern_fork.c Wed Aug 15 15:56:21 2012(r239301)
>@@ -209,8 +209,8 @@ sysctl_kern_randompid(SYSCTL_HANDLER_ARG
> pid = randompid;
> error = sysctl_handle_int(oidp, &pid, 0, req);
> if (error == 0 && req->newptr != NULL) {
>- if (pid < 0 || pid > PID_MAX - 100) /* out of range */
>- pid = PID_MAX - 100;
>+ if (pid < 0 || pid > pid_max - 100) /* out of range */
>+ pid = pid_max - 100;
Setting max_pid to a value less than 100 will have an undesirable effect here.
>+static int
>+sysctl_kern_pid_max(SYSCTL_HANDLER_ARGS)
>+{
>+ int error, pm;
>+
>+ pm = pid_max;
>+ error = sysctl_handle_int(oidp, &pm, 0, req);
>+ if (error || !req->newptr)
>+ return (error);
>+ sx_xlock(&proctree_lock);
>+ sx_xlock(&allproc_lock);
>+ /* Only permit the values less then PID_MAX. */
>+ if (pm > PID_MAX)
>+ error = EINVAL;
>+ else
>+ pid_max = pm;
>+ sx_xunlock(&allproc_lock);
>+ sx_xunlock(&proctree_lock);
>+ return (error);
>+}
>+SYSCTL_PROC(_kern, OID_AUTO, pid_max, CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_TUN |
>+CTLFLAG_MPSAFE, 0, 0, sysctl_kern_pid_max, "I",
>+"Maximum allowed pid");
I don't see anything in this code that would prevent setting max_pid
to an unusably low (as in making the system unusable) or even negative
value
>+ TUNABLE_INT_FETCH("kern.pid_max", &pid_max);
>+ if (pid_max > PID_MAX)
>+ pid_max = PID_MAX;
> }
Likewise, this needs a lower bounds check.
--
Peter Jeremy
pgpjSBXtQZhiY.pgp
Description: PGP signature
Re: svn commit: r252373 - head/usr.bin
On 2013-Jun-29 15:31:24 +, Tim Kientzle wrote: >Log: > Enable svnlite on armv6. This breaks building world with gcc on Raspberry Pi: gcc -O -pipe -I/tank/src10r/usr.bin/svn/svn/../../../contrib/subversion/subversion/include -I/tank/src10r/usr.bin/svn/svn/../../../contrib/subversion/subversion -I/tank/src10r/usr.bin/svn/svn/.. -I/tank/src10r/usr.bin/svn/svn/../lib/libapr -I/tank/src10r/usr.bin/svn/svn/../../../contrib/apr/include/arch/unix -I/tank/src10r/usr.bin/svn/svn/../../../contrib/apr/include -I/tank/src10r/usr.bin/svn/svn/../lib/libapr_util -I/tank/src10r/usr.bin/svn/svn/../../../contrib/apr-util/include/private -I/tank/src10r/usr.bin/svn/svn/../../../contrib/apr-util/include -std=gnu99 -Wno-pointer-sign -o svnlite add-cmd.o blame-cmd.o cat-cmd.o changelist-cmd.o checkout-cmd.o cl-conflicts.o cleanup-cmd.o commit-cmd.o conflict-callbacks.o copy-cmd.o delete-cmd.o deprecated.o diff-cmd.o export-cmd.o file-merge.o help-cmd.o import-cmd.o info-cmd.o list-cmd.o lock-cmd.o log-cmd.o merge-cmd.o mergeinfo-cmd.o mkdir-cmd.o move-cmd.o notify.o patch-cmd.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o relocate-cmd.o resolve-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o svn.o switch-cmd.o unlock-cmd.o update-cmd.o upgrade-cmd.o util.o -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_client -lsvn_client -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_wc -lsvn_wc -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_ra -lsvn_ra -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_ra_local -lsvn_ra_local -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_ra_svn -lsvn_ra_svn -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_ra_serf -lsvn_ra_serf -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_repos -lsvn_repos -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_fs -lsvn_fs -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_fs_fs -lsvn_fs_fs -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_fs_util -lsvn_fs_util -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_delta -lsvn_delta -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_diff -lsvn_diff -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_subr -lsvn_subr -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libserf -lserf -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libapr_util -lapr-util -lbsdxml -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libapr -lapr -L/tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsqlite3 -lsqlite3 -lz -lcrypt -lmagic -lcrypto -lssl -lpthread /tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_subr/libsvn_subr.a(named_atomic.o): In function `svn_named_atomic__cmpxchg': named_atomic.c:(.text+0xf0): undefined reference to `__sync_val_compare_and_swap_8' /tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_subr/libsvn_subr.a(named_atomic.o): In function `svn_named_atomic__add': named_atomic.c:(.text+0x174): undefined reference to `__sync_add_and_fetch_8' /tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libsvn_subr/libsvn_subr.a(named_atomic.o): In function `svn_named_atomic__write': named_atomic.c:(.text+0x1c0): undefined reference to `__sync_lock_test_and_set_8' /tank/obj/rpi/arm.armv6/tank/src10r/usr.bin/svn/svn/../lib/libapr/libapr.a(builtins.o): In function `apr_atomic_dec32': builtins.c:(.text+0x90): undefined reference to `__sync_sub_and_fetch_4' *** Error code 1 Stop. make: stopped in /tank/src10r/usr.bin/svn/svn I've split the failures into two categories: __sync_add_and_fetch_8 __sync_lock_test_and_set_8 __sync_val_compare_and_swap_8 these should be defined in /usr/src/sys/arm/arm/stdatomic.c (and compiled into libcompiler_rt.a) but that file only defines 1-, 2- and 4-byte variants for userland armv6 (it looks like it fakes 8-byte variants in the kernel by disabling interrupts). I don't know ARM assembler well enough to know if there's any way to do 64-bit atomic operations. I suspect not. __sync_sub_and_fetch_4 There are references to __sync_sub_and_fetch() but I can't any sign of a definition. It looks like __sync_sub_and_fetch_4 is supposed to be a gcc builtin so I'm not sure why it's being emitted without a definition. -- Peter Jeremy pgps0GUq2Y7ib.pgp Description: PGP signature
svn commit: r247274 - in head: bin/test tools/regression/bin/test
Author: peterj
Date: Mon Feb 25 19:05:40 2013
New Revision: 247274
URL: http://svnweb.freebsd.org/changeset/base/247274
Log:
Enhance test(1) by adding provision to compare any combination of the
access, birth, change and modify times of two files, instead of only
being able to compare modify times. The builtin test in sh(1) will
automagically acquire the same expansion.
Approved by: grog
MFC after:2 weeks
Modified:
head/bin/test/test.1
head/bin/test/test.c
head/tools/regression/bin/test/regress.sh
Modified: head/bin/test/test.1
==
--- head/bin/test/test.1Mon Feb 25 18:07:20 2013(r247273)
+++ head/bin/test/test.1Mon Feb 25 19:05:40 2013(r247274)
@@ -169,15 +169,65 @@ True if
.Ar file
exists and is a socket.
.It Ar file1 Fl nt Ar file2
-True if
+True if both
+.Ar file1
+and
+.Ar file2
+exist and
+.Ar file1
+is newer than
+.Ar file2 .
+.It Ar file1 Fl nt Ns Ar X Ns Ar Y Ar file2
+True if both
+.Ar file1
+and
+.Ar file2
+exist and
.Ar file1
-exists and is newer than
+has a more recent last access time
+.Pq Ar X Ns = Ns Cm a ,
+inode creation time
+.Pq Ar X Ns = Ns Cm b ,
+change time
+.Pq Ar X Ns = Ns Cm c ,
+or modification time
+.Pq Ar X Ns = Ns Cm m
+than the last access time
+.Pq Ar Y Ns = Ns Cm a ,
+inode creation time
+.Pq Ar Y Ns = Ns Cm b ,
+change time
+.Pq Ar Y Ns = Ns Cm c ,
+or modification time
+.Pq Ar Y Ns = Ns Cm m
+of
.Ar file2 .
+Note that
+.Ic -ntmm
+is equivalent to
+.Ic -nt .
.It Ar file1 Fl ot Ar file2
-True if
+True if both
+.Ar file1
+and
+.Ar file2
+exist and
.Ar file1
-exists and is older than
+is older than
.Ar file2 .
+Note that
+.Ar file1
+.Ic -ot
+.Ar file2
+is equivalent to
+.Ar file2
+.Ic -nt
+.Ar file1
+.It Ar file1 Fl ot Ns Ar X Ns Ar Y Ar file2
+Equivalent to
+.Ar file2
+.Ic -nt Ns Ar Y Ns Ar X
+.Ar file1 .
.It Ar file1 Fl ef Ar file2
True if
.Ar file1
Modified: head/bin/test/test.c
==
--- head/bin/test/test.cMon Feb 25 18:07:20 2013(r247273)
+++ head/bin/test/test.cMon Feb 25 19:05:40 2013(r247274)
@@ -63,7 +63,7 @@ error(const char *msg, ...)
"-u"|"-g"|"-k"|"-s"|"-t"|"-z"|"-n"|"-o"|"-O"|"-G"|"-L"|"-S";
binary-operator ::= "="|"!="|"-eq"|"-ne"|"-ge"|"-gt"|"-le"|"-lt"|
- "-nt"|"-ot"|"-ef";
+ "-nt"|"-nt[abcm][abcm]"|"-ot"|"-ot[abcm][abcm])"|"-ef";
operand ::=
*/
@@ -85,8 +85,38 @@ enum token {
FILSUID,
FILSGID,
FILSTCK,
- FILNT,
- FILOT,
+ FILNTAA,
+ FILNTAB,
+ FILNTAC,
+ FILNTAM,
+ FILNTBA,
+ FILNTBB,
+ FILNTBC,
+ FILNTBM,
+ FILNTCA,
+ FILNTCB,
+ FILNTCC,
+ FILNTCM,
+ FILNTMA,
+ FILNTMB,
+ FILNTMC,
+ FILNTMM,
+ FILOTAA,
+ FILOTAB,
+ FILOTAC,
+ FILOTAM,
+ FILOTBA,
+ FILOTBB,
+ FILOTBC,
+ FILOTBM,
+ FILOTCA,
+ FILOTCB,
+ FILOTCC,
+ FILOTCM,
+ FILOTMA,
+ FILOTMB,
+ FILOTMC,
+ FILOTMM,
FILEQ,
FILUID,
FILGID,
@@ -118,9 +148,16 @@ enum token_types {
PAREN
};
+enum time_types {
+ ATIME,
+ BTIME,
+ CTIME,
+ MTIME
+};
+
static struct t_op {
- char op_text[4];
- short op_num, op_type;
+ char op_text[6];
+ char op_num, op_type;
} const ops [] = {
{"-r", FILRD, UNOP},
{"-w", FILWR, UNOP},
@@ -154,8 +191,40 @@ static struct t_op {
{"-gt", INTGT, BINOP},
{"-le", INTLE, BINOP},
{"-lt", INTLT, BINOP},
- {"-nt", FILNT, BINOP},
- {"-ot", FILOT, BINOP},
+ {"-nt", FILNTMM,BINOP},
+ {"-ntaa", FILNTAA,BINOP},
+ {"-ntab", FILNTAB,BINOP},
+ {"-ntac", FILNTAC,BINOP},
+ {"-ntam", FILNTAM,BINOP},
+ {"-ntba", FILNTBA,BINOP},
+ {"-ntbb", FILNTBB,BINOP},
+ {"-ntbc", FILNTBC,BINOP},
+ {"-ntbm", FILNTBM,BINOP},
+ {"-ntca", FILNTCA,BINOP},
+ {"-ntcb", FILNTCB,BINOP},
+ {"-ntcc", FILNTCC,BINOP},
+ {"-ntcm", FILNTCM,BINOP},
+ {"-ntma", FILNTMA,BINOP},
+ {"-ntmb", FILNTMB,BINOP},
+ {"-ntmc", FILNTMC,BINOP},
+ {"-ntmm", FILNTMM,BINOP},
+ {"-ot", FILOTMM,BINOP},
+ {"-otaa", FILOTAA,BINOP},
+ {"-otab", FILOTBB,BINOP},
+ {"-otac", FILOTAC,BINOP},
+ {"-otam", FILOTAM,BINOP},
+ {"-otba", FILOTBA,BINOP},
+ {"-otbb", FILOTBB,BINOP},
+ {"-otbc", FILO
Re: svn commit: r247274 - in head: bin/test tools/regression/bin/test
On 2013-Feb-26 01:02:27 +0100, Jilles Tjoelker wrote: >> Enhance test(1) by adding provision to compare any combination of the >> access, birth, change and modify times of two files, instead of only >> being able to compare modify times. The builtin test in sh(1) will >> automagically acquire the same expansion. > >What do you need this for? If it is not needed very often, this test can >be done more portably (older FreeBSD and GNU) as > [ -n "$(find -L FILE1 -prune -newerXY FILE2 2>/dev/null)" ] In my case I needed to compare the ctime on one set of files with the mtime in another set. I had a think about using find(1) and gave it away as too ugly. That expression needs serious thought to understand and about ½ the tokens in the find(1) are to handle special cases - which is a further indication that it isn't ideal. >I have generally been rather reluctant in adding things to sh(1) and >even more so if they are completely new. Someone proposed something >rather similar (except that it added a time string parser -- even more >code) in PR bin/57054 and I rejected it in 2009. Time parsing is a large can of worms - getting it right is messy (that patch includes 1KLOC of new code and still isn't locale aware). And the work-around of touching a dummy file to the wanted age isn't too horrrible. This is a much smaller patch and there's no equally clean work-around. >> +a=/tmp/test$$.1 >> +b=/tmp/test$$.2 > >Please use mktemp(1). Using $$ for temporary files is insecure on >multiuser systems. In this case, I want filenames that don't exist. I will look at using mktemp(1) to create a temporary directory. >> +sleep 2# Ensure $b is newer than $a >> +touch $b > >Please use touch -t instead of sleeping. I'm impatient while running >tests :) In this case, I want all the timestamps on $b to be later than $a. I initially tried without the sleep but that failed with the builtin test(1) because the FS timestamps weren't sufficiently granular to report the difference. I could create one of the files much earlier during the test and then use a conditional test to only sleep if the timestamps were indistinguishable (this probably needs to use the above find(1) horror to avoid using test(1) to test itself). I agree the other sleep(1)s should be able to be replaced with touch(1) but I ran into problems with my initial efforts to do everything using touch(1). I will revisit it. -- Peter Jeremy pgpB_uIyxsx0n.pgp Description: PGP signature
Re: svn commit: r249484 - head/lib
On Sun, Apr 14, 2013 at 07:13:52PM +, Tim Kientzle wrote: > Install a symlink > /usr/lib/include ==> /usr/include April 1st was several weeks ago. > This fixes -print-file-name=include in clang (and is > arguably a better way to fix the same issue in GCC than > the change I made in r231336). I would disagree that this is a better solution. On 2013-Apr-15 16:33:50 +0400, Gennady Proskurin wrote: >Here is the quote from r231336 commit message: >Implement -print-file-name=include (which is undocumented >but used by some Linux boot loaders). I don't see why base needs to grow an ugly symlink to support a couple of ports. Surely if ports rely on an undocumented features of the toolchain, the correct solution is to fix the ports. -- Peter Jeremy pgpBX5YdK28Ts.pgp Description: PGP signature
Re: svn commit: r204309 - in head/sys: amd64/amd64 amd64/isa conf i386/bios i386/cpufreq i386/i386 i386/isa i386/xen isa modules/bios/smbios modules/bios/vpd modules/cpufreq pc98/pc98 x86 x86/bios x86
On 2010-Feb-26 14:57:36 +0100, Attilio Rao wrote: >For the future, however, probabilly we would need to do something like >pc98 already does wrt i386 (i386/include/ pc98/include/ amd64/include/ >just have files wrappers to the generic one under x86/include/ when >necessary). Not that something like this is also critical for getting i386/amd64 cross compilation to work - one of the blocking issues is that the correct machine/ includes are not available in cross-compilatio mode. -- Peter Jeremy pgpbufYZ0Fc1p.pgp Description: PGP signature
Re: svn commit: r204309 - in head/sys: amd64/amd64 amd64/isa conf i386/bios i386/cpufreq i386/i386 i386/isa i386/xen isa modules/bios/smbios modules/bios/vpd modules/cpufreq pc98/pc98 x86 x86/bios x86
On 2010-Feb-28 16:07:32 -0700, "M. Warner Losh" wrote: >In message: <4b8af55c.6040...@freebsd.org> >Nathan Whitehorn writes: >: M. Warner Losh wrote: >: > In message: <20100228195041.ga68...@server.vk2pj.dyndns.org> >: > Peter Jeremy writes: >: > : On 2010-Feb-26 14:57:36 +0100, Attilio Rao >: > wrote: >: > : >For the future, however, probabilly we would need to do something >: > like >: > : >pc98 already does wrt i386 (i386/include/ pc98/include/ >: > amd64/include/ >: > : >just have files wrappers to the generic one under x86/include/ when >: > : >necessary). >: > : : Not that something like this is also critical for getting >: > i386/amd64 >: > : cross compilation to work - one of the blocking issues is that the >: > : correct machine/ includes are not available in cross-compilatio >: > mode. >: > >: > Huh? >: > >: > I cross build all the time, and the machine/ includes are always >: > right, with or without this patch. Maybe you could explain what you >: > mean here... >: > >: I'm guessing what was meant is that one benefit of a merged tree (like >: we will have with powerpc) is that you can do cc -m32 on a 64-bit host >: to get a 32-bit binary, which is less than trivial now. Yep. >True enough. But we don't have anywhere close to a merged tree on >x86, and won't for the foreseeable future. I don't really want to see >an include32, when all the cross building tools exist in the tree >already (see XDEV in Makefile.inc1)... I agree that we don't want an include32 - all that we need is the machine-dependent directory (i386, amd64, ...). > If you are cross building, you >really need a full cross building environment. The -m32 hacks we have >now are, as you describe, insufficient to the task... For building i386 executables in an amd64 world, we already have almost everything needed - the toolchain is present, the libraries are present, most of the headers are present. The only parts of the environment that aren't installed in default are the machine-dependent headers (and some glue to include the appropriate architecture). I'm not saying that installing the i386 headers will magically make '-m32' work but it's a necessary prerequisite. -- Peter Jeremy pgpoiOkuUSSFf.pgp Description: PGP signature
Re: svn commit: r204974 - head/lib/libc/sparc64/fpu
One bug that crept in somewhere:
On 2010-Mar-10 19:55:48 +, Marius Strobl wrote:
>Modified: head/lib/libc/sparc64/fpu/fpu.c
>@@ -181,15 +182,11 @@ __fpu_dumpfpn(struct fpn *fp)
> }
> #endif
>
>-static int opmask[] = {0, 0, 1, 3};
>+static const int opmask[] = {0, 0, 1, 3, 1};
>
...
>Modified: head/lib/libc/sparc64/fpu/fpu_emu.h
>==
>--- head/lib/libc/sparc64/fpu/fpu_emu.hWed Mar 10 19:55:27 2010
>(r204973)
>+++ head/lib/libc/sparc64/fpu/fpu_emu.hWed Mar 10 19:55:48 2010
>(r204974)
>@@ -140,7 +140,7 @@ struct fpn {
> #define FTYPE_SNG INSFP_s
> #define FTYPE_DBL INSFP_d
> #define FTYPE_EXT INSFP_q
>-#define FTYPE_LNG -1
>+#define FTYPE_LNG 5
FTYPE_* are used as indexes into opmask[]. Somewhere along the line,
FTYPE_LNG has changed from 4 to 5 but the opmask[] initialisers still
assume 4. (It might be worth adding a comment into opmask[] so this
relationship is noted in future).
--
Peter Jeremy
pgpwZwYNidf71.pgp
Description: PGP signature
svn commit: r312984 - in head: lib/libsysdecode libexec/rtld-elf
Author: peterj Date: Mon Jan 30 08:38:32 2017 New Revision: 312984 URL: https://svnweb.freebsd.org/changeset/base/312984 Log: Extend LD_UTRACE by also generating utrace(2) log events for runtime linker errors. Reviewed by: kib, jhb Approved by: jhb(mentor) MFC after:1 week Differential Revision: D9347 Modified: head/lib/libsysdecode/utrace.c head/libexec/rtld-elf/rtld.c head/libexec/rtld-elf/rtld_utrace.h Modified: head/lib/libsysdecode/utrace.c == --- head/lib/libsysdecode/utrace.c Mon Jan 30 08:35:15 2017 (r312983) +++ head/lib/libsysdecode/utrace.c Mon Jan 30 08:38:32 2017 (r312984) @@ -124,6 +124,10 @@ print_utrace_rtld(FILE *fp, void *p) fprintf(fp, "RTLD: %p = dlsym(%p, %s)", ut->mapbase, ut->handle, ut->name); break; + case UTRACE_RTLD_ERROR: + fprintf(fp, "RTLD: error: %s\n", ut->name); + break; + default: return (0); } Modified: head/libexec/rtld-elf/rtld.c == --- head/libexec/rtld-elf/rtld.cMon Jan 30 08:35:15 2017 (r312983) +++ head/libexec/rtld-elf/rtld.cMon Jan 30 08:38:32 2017 (r312984) @@ -764,6 +764,7 @@ _rtld_error(const char *fmt, ...) rtld_vsnprintf(buf, sizeof buf, fmt, ap); error_message = buf; va_end(ap); +LD_UTRACE(UTRACE_RTLD_ERROR, NULL, NULL, 0, 0, error_message); } /* Modified: head/libexec/rtld-elf/rtld_utrace.h == --- head/libexec/rtld-elf/rtld_utrace.h Mon Jan 30 08:35:15 2017 (r312983) +++ head/libexec/rtld-elf/rtld_utrace.h Mon Jan 30 08:38:32 2017 (r312984) @@ -45,6 +45,7 @@ #defineUTRACE_FINI_CALL10 #defineUTRACE_DLSYM_START 11 #defineUTRACE_DLSYM_STOP 12 +#defineUTRACE_RTLD_ERROR 13 #defineRTLD_UTRACE_SIG_SZ 4 #defineRTLD_UTRACE_SIG "RTLD" ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
