Re: nvd0 lockup while compiling ports

2017-10-04 Thread Warner Losh
On Wed, Oct 4, 2017 at 6:03 AM, Gerhard Schmidt wrote: > Hi, > > I've got a new Workstation last week with the Main HD as M2 Card. > > FreeBSD recognizes the card as nvd0 > nvd0: NVMe namespace > nvd0: 488386MB (1000215216 512 byte sectors) > > When compiling some ports (in this example VirtualB

Re: my build time impact of clang 5.0

2017-10-04 Thread Matt Smith
On Oct 04 13:03, krad wrote: have you tried meta builds and pkgbase? I was going to say this. Because my build times have increased so massively on my underpowered server I've switched to doing incremental builds. Set WITH_META_MODE=yes in /etc/src-env.conf and add kld_list="filemon" to /etc

Re: my build time impact of clang 5.0

2017-10-04 Thread krad
have you tried meta builds and pkgbase? On 3 October 2017 at 16:38, Dan Mack wrote: > Jakub Lach writes: > > > On the other hand, I'm having tremendous increases in Unixbench scores > > comparing to > > 11-STABLE in the April (same machine, clang 4 then, clang 5 now) (about > > 40%). > > > > I

nvd0 lockup while compiling ports

2017-10-04 Thread Gerhard Schmidt
Hi, I've got a new Workstation last week with the Main HD as M2 Card. FreeBSD recognizes the card as nvd0 nvd0: NVMe namespace nvd0: 488386MB (1000215216 512 byte sectors) When compiling some ports (in this example VirtualBox-ose) I experiencing lockups on the Harddisk when many files are delet

iSCSI: LUN modification error: LUN XXX is not managed by the block backend and LUN device confusion

2017-10-04 Thread Eugene M. Zheganin
Hi, I got one more problem while dealing iSCSI targets in the production (yeah, I'm boring and stubborn). The environment is as in previous questions (a production site, hundreds of VMs and hundreds of disks). I've encountered this issue before, but this time i decided to ask whether it's po

Re: ctld: only 579 iSCSI targets can be created

2017-10-04 Thread Eugene M. Zheganin
Hi. On 02.10.2017 15:03, Edward Napierala wrote: Thanks for the packet trace. What happens there is that the Windows initiator logs in, requests Discovery ("SendTargets=All"), receives the list of targets, as expected, and then... sends "SendTargets=All" again, instead of logging off. This r