[In part this note shows that the issue is not specific to
cross builds: -a arm64.aarch64 is not essential. But it
also shows just where the /sys/param.h comes from.]
On 2019-Nov-24, at 15:22, Mark Millard wrote:
> On 2019-Nov-24, at 15:11, Ben Woods wrote:
>
>> On Sun, 24 Nov 2019 at 1:27
Ignore my previous e-mail.
I just saw, the 'SVN r355491 breaks libprocstat' thread.
(Forgot to check my 'current' e-mail folder, to which I recently began
filtering e-mail. Apologies for the noise.)
___
freebsd-current@freebsd.org mailing list
On Sat, 7 Dec 2019 20:05-, Graham Perrin wrote:
> --- lib/libprocstat__L ---
> /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named 'next'
> in 'struct vm_map_entry'
> for (entryp = map->header.next;
> ~~~ ^
>
On Sat, 7 Dec 2019 20:25+0100, Trond Endrestøl wrote:
> On Sat, 7 Dec 2019 12:57-0500, Michael Butler wrote:
>
> > This member removal has other consequences. As follows ..
> >
> > --- lib/libprocstat__L ---
> > Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
> > --- libprocstat.o
--- _libinstall ---
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libmlx5.a
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/
sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 -S
libmlx5.so.1 /usr/obj/usr/src/amd64.amd64/tmp/lib/
sh /usr/src/tools/install.sh -o root -g wheel -m 444
On Sat, 7 Dec 2019 12:57-0500, Michael Butler wrote:
> This member removal has other consequences. As follows ..
>
> --- lib/libprocstat__L ---
> Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
> --- libprocstat.o ---
> /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no
This member removal has other consequences. As follows ..
--- lib/libprocstat__L ---
Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
--- libprocstat.o ---
/usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
'next' in 'struct vm_map_entry'
for
Hi Bob,
On 06.12.2019 23:57, bob prohaska wrote:
> For what it's worth, there does seem to be something amiss with USB.
>
> An RPI2 at r355446 is having difficulty finding its USB devices
> on a hands-off reboot. The problem wasn't apparent until this most
> recent upgrade. Here's the console
Hi,
I use a 5-hdd bunch connected via USB3 in JBOD mode; that 5 hdd builds a
zpool and are listed during boot process as da0 to da4.
Here is my /boot/loader.conf file:
.../...
hw.snd.default_device=2
dev.pcm.1.play.vchans=2
fuse_load="YES"
kern.cam.boot_delay=12000
kern.vty=vt
sysctl
On Fri, 6 Dec 2019 18:15:32 -0500
Alexander Motin wrote:
> On 06.12.2019 17:52, Steve Kargl wrote:
[snip]
> > For the record add kern.cam.boot_delay to /boot/loader.conf with the
> > values 0, 1, and "1" did not allow the system to boot.
>
> boot_delay value is measured in milliseconds, so
10 matches
Mail list logo
