On 13 June 2018 at 04:16, Eitan Adler wrote:
> On 13 June 2018 at 03:35, Konstantin Belousov wrote:
>> Today I noted that AMD published the public errata document for Ryzens,
>> https://developer.amd.com/wp-content/resources/55449_1.12.pdf
>>
>> Some of the issues listed there looks quite
On 2018-Jun-18, at 6:03 PM, Mark Millard wrote:
> On 2018-Jun-18, at 4:08 PM, Bryan Drewery wrote:
>
>> On 6/18/2018 3:27 PM, Li-Wen Hsu wrote:
>>> ranlib -D libpcap.a
>>> ranlib: fatal: Failed to open 'libpcap.a'
>>
>> Where is this error even coming from? It's not in the usr.bin/ar code
>>
On 2018-Jun-18, at 4:08 PM, Bryan Drewery wrote:
> On 6/18/2018 3:27 PM, Li-Wen Hsu wrote:
>> ranlib -D libpcap.a
>> ranlib: fatal: Failed to open 'libpcap.a'
>
> Where is this error even coming from? It's not in the usr.bin/ar code
> and ranlib does not cause it.
>
> # ranlib -D uh
>
On 15 Jun, Rick Macklem wrote:
> Hi,
>
> For the pNFS service MDS machine, the nfsd can't be started until all nfs
> mounts
> in /etc/fstab are done.
> I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient
> to do this?
>
> I don't think delaying the startup of the nfsd
On 18 June 2018 at 19:29, Bryan Drewery wrote:
>
> The error is coming from libarchive which had a change between those
> revisions:
>
>>
>> r328332 | mm | 2018-01-24 06:24:17 -0800 (Wed, 24 Jan 2018) | 14 lines
Li-Wen
On 6/18/2018 3:27 PM, Li-Wen Hsu wrote:
> On Mon, Jun 18, 2018 at 5:04 PM Mark Millard via freebsd-toolchain
> wrote:
>>
>> On 2018-Jun-18, at 12:42 PM, Bryan Drewery wrote:
>>
>>> On 6/15/2018 10:55 PM, Mark Millard wrote:
In watching ci.freebsd.org builds I've seen a notable
number
On 6/18/2018 3:27 PM, Li-Wen Hsu wrote:
> ranlib -D libpcap.a
> ranlib: fatal: Failed to open 'libpcap.a'
Where is this error even coming from? It's not in the usr.bin/ar code
and ranlib does not cause it.
# ranlib -D uh
ranlib: warning: uh: no such file
--
Regards,
Bryan Drewery
On 6/18/2018 3:31 PM, Li-Wen Hsu wrote:
> On Mon, Jun 18, 2018 at 6:27 PM Bryan Drewery wrote:
>>
>> On 6/18/2018 1:45 PM, Konstantin Belousov wrote:
>>> On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote:
On 6/15/2018 10:55 PM, Mark Millard wrote:
> In watching ci.freebsd.org
On Mon, Jun 18, 2018 at 5:04 PM Mark Millard via freebsd-toolchain
wrote:
>
> On 2018-Jun-18, at 12:42 PM, Bryan Drewery wrote:
>
> > On 6/15/2018 10:55 PM, Mark Millard wrote:
> >> In watching ci.freebsd.org builds I've seen a notable
> >> number of one time failures, such as (example from
> >>
On Mon, Jun 18, 2018 at 6:27 PM Bryan Drewery wrote:
>
> On 6/18/2018 1:45 PM, Konstantin Belousov wrote:
> > On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote:
> >> On 6/15/2018 10:55 PM, Mark Millard wrote:
> >>> In watching ci.freebsd.org builds I've seen a notable
> >>> number of
On 6/18/2018 1:45 PM, Konstantin Belousov wrote:
> On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote:
>> On 6/15/2018 10:55 PM, Mark Millard wrote:
>>> In watching ci.freebsd.org builds I've seen a notable
>>> number of one time failures, such as (example from
>>> powerpc64):
>>>
>>>
Hi,
On 06/18/18 17:42, Rick Macklem wrote:
Steve Wills wrote:
Would it be possible or reasonable to use the client ID to log a message
telling the admin to enable a sysctl to enable the hacks?
Yes. However, this client implementation id is only seen by the server
when the client makes a mount
Steve Wills wrote:
>Would it be possible or reasonable to use the client ID to log a message
>telling the admin to enable a sysctl to enable the hacks?
Yes. However, this client implementation id is only seen by the server
when the client makes a mount attempt.
I suppose it could log the message
My thoughts on this are mixed.
You need certain workarounds, but they sound like they need to be on a
per-client-type basis.
On the one hand, you don't want to chat with different clients differently,
but on the other you want it to work.
I'd suggest a two-tiered approach.
First, have a sysctl
Would it be possible or reasonable to use the client ID to log a message
telling the admin to enable a sysctl to enable the hacks?
Steve
On 06/17/18 08:35, Rick Macklem wrote:
Hi,
Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in ESXi 6.5u1
(VMware) against the FreeBSD
On 2018-Jun-18, at 12:42 PM, Bryan Drewery wrote:
> On 6/15/2018 10:55 PM, Mark Millard wrote:
>> In watching ci.freebsd.org builds I've seen a notable
>> number of one time failures, such as (example from
>> powerpc64):
>>
>> --- all_subdir_lib/libufs ---
>> ranlib -D libufs.a
>> ranlib:
On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote:
> On 6/15/2018 10:55 PM, Mark Millard wrote:
> > In watching ci.freebsd.org builds I've seen a notable
> > number of one time failures, such as (example from
> > powerpc64):
> >
> > --- all_subdir_lib/libufs ---
> > ranlib -D libufs.a
Hi,
I realized that the subject line "ESXi NFSv4.1 client id is nasty" wouldn't have
indicated that I was looking for comments w.r.t. how to handle this poorly
behaved client.
Please go to the "ESXi NFSv4.1 client id is nasty" thread and comment.
(It should be in the archive, if you already
On 6/15/2018 10:55 PM, Mark Millard wrote:
> In watching ci.freebsd.org builds I've seen a notable
> number of one time failures, such as (example from
> powerpc64):
>
> --- all_subdir_lib/libufs ---
> ranlib -D libufs.a
> ranlib: fatal: Failed to open 'libufs.a'
> *** [libufs.a] Error code 70
>
Something changed in /boot/gptzfsboot between r334610 and r335314. I
built current this morning and my system is un-bootable. I am using
redundant ZFS disks and only copied the updated /boot/gptzfsboot file to
my ada0 drive. I was able to boot the ada1 drive that still had the
gptzfsboot file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Mon, 18 Jun 2018 07:42:20 -0600
Warner Losh schrieb:
> On Mon, Jun 18, 2018, 3:01 AM Olivier Cochard-Labbé
> wrote:
>
> > On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann
> > wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash:
On 6/13/2018 6:35 AM, Konstantin Belousov wrote:
>
> Please report the results. If the script helps, I will code the kernel
> change to apply the workarounds.
The hard lockups I was seeing on Ryzen and Epyc boxes are now gone with
the microcode and script below.
Not sure if its one or some
On Mon, Jun 18, 2018, 3:01 AM Olivier Cochard-Labbé
wrote:
> On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann
> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Running CURRENT as routing and firewalling appliance on a PCengines APU
> > 2C4 with the
> > latest (official)
On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Running CURRENT as routing and firewalling appliance on a PCengines APU
> 2C4 with the
> latest (official) SEABios available for this product, NanoBSD (FreeBSD
> CURRENT FreeBSD
>
24 matches
Mail list logo
