Re: DDD hangs on start on 11.1-R

On Sat, 3 Mar 2018 18:09+0100, Holm Tiffe wrote: > can anyone get ddd get to work in 11.1-R or stable? I've more or less given up on devel/ddd, since it relies on the old pty subsystem, now replaced by the new pts subsystem, to communicate with gdb. I build custom kernels containing "device

Re: DEQNA support in stable ???! Errrr.....

Warner Losh wrote: >On Sun, Mar 4, 2018 at 3:45 PM, Pete French >wrote: >> >> Unless my memory fails me DEQNA is the Dec Q-bus network adapter >> for MicroVaxen isn't it ? The mini version of the DEUNA interface for >> the full size Vax/11 machines. Now, I woudn't be

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

NAGY Andreas wrote: [stuff snipped] >In the source I saw nfs_async = 0; is it right that NFS will work in async >mode if I >compile the kernel with nfs_async = 1? > >I know the risk of running it async, but is it not the same risk having the >datastore >connected via iSCSI which standard is also

Re: DEQNA support in stable ???! Errrr.....

On Sun, Mar 4, 2018 at 3:45 PM, Pete French wrote: > Just perusing the commits on a sunday evenong and I happened across > this one: https://freshbsd.org/commit/freebsd/r313276 > > "Use kldload -n when loading if_deqna > > This fixes if_deqna from being

DEQNA support in stable ???! Errrr.....

Just perusing the commits on a sunday evenong and I happened across this one: https://freshbsd.org/commit/freebsd/r313276 "Use kldload -n when loading if_deqna This fixes if_deqna from being loaded by accident twice if it's already loaded in the kernel." Unless my memory fails

Re: "Cross" building for same architecture, different CPUTYPE

* Warner Losh wrote: On Sun, Mar 4, 2018 at 10:43 AM, Dimitry Andric > wrote: Again, this depends on how exactly you are overriding CPUTYPE. I'd suggest *NOT* setting CPUTYPE and instead using TARGET_CPUTYPE to do these sorts of things. CPUTYPE

RE: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

Okay, the slow write was not a NFS problem, it was the hw raid controller which switched to write through because of a broken battery. In the source I saw nfs_async = 0; is it right that NFS will work in async mode if I compile the kernel with nfs_async = 1? I know the risk of running it

Re: "Cross" building for same architecture, different CPUTYPE

* Dimitry Andric wrote: On 4 Mar 2018, at 18:29, Christian Ullrich wrote: I have CPUTYPE?=core-avx2 in make.conf, but that should be irrelevant here. Actually, that *is* relevant for the stages after bootstrap-tools, build-tools and cross-tools. E.g. 4.x and later.

Re: "Cross" building for same architecture, different CPUTYPE

On Sun, Mar 4, 2018 at 10:43 AM, Dimitry Andric wrote: > Again, this depends on how exactly you are overriding CPUTYPE. I'd suggest *NOT* setting CPUTYPE and instead using TARGET_CPUTYPE to do these sorts of things. CPUTYPE is known to only work on native builds and is tricky

Re: "Cross" building for same architecture, different CPUTYPE

On 4 Mar 2018, at 18:29, Christian Ullrich wrote: > > I'm trying to buildworld/buildkernel of stable/11 r330373 for an Intel Atom > CPU (CPUTYPE=slm) on a (slightly faster, CPUTYPE=core-avx2) build machine. > That works fine, but make installkernel on the Atom box fails

"Cross" building for same architecture, different CPUTYPE

Hello, I'm trying to buildworld/buildkernel of stable/11 r330373 for an Intel Atom CPU (CPUTYPE=slm) on a (slightly faster, CPUTYPE=core-avx2) build machine. That works fine, but make installkernel on the Atom box fails with a SIGILL (signal 4) in the "install" command (sorry, no log or

RE: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

Thanks, got it working with your patch. So far I did not see any issue with the mount. Only in the vmkernel.log there are often following entrees: WARNING: NFS41: NFS41ValidateDelegation:608: Server returned improper reason for no delegation: 2 Actually I have only a single link between the