Re: Strange issue after early AP startup

Hi, On 01/18/17 02:18, John Baldwin wrote: Also, I think you could set nextcallopt to 'now' rather than 'now + 1'. There is a check in loadtimer() if next == now, and then the event timer is not started ?? } else { new = getnextevent(); eq = (new ==

ISO image: where is the CLANG compiler?

I ran into a very nasty situation where I need to save/restore/reinstall a in-installworld-crashed recent current. While the /usr/obj and /usr/src as well as /etc folders are intact (residing on a Samsung 850 pro SSD with UFS and journaling), /boot/kernel vanished and most binaries in /bin and

Re: recent change to vim defaults?

On 17/01/2017 12:07 AM, ohauer wrote: I suspect you mean the /usr/local/etc/vim/vimrc and gvimrc files. That was the first place I've tried to overwrite it, but without luck (even with set mouse=) but it works in ~/.vimrc what to put IN the file? -- olli -- send with broken GMX mailer

Re: Strange issue after early AP startup

On Tuesday, January 17, 2017 05:08:58 PM Cy Schubert wrote: > In message <1492450.xzfnz8z...@ralph.baldwin.cx>, John Baldwin writes: > > On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote: > > > In message , Hans > > > Petter > > > Sela >

Re: Strange issue after early AP startup

On Tuesday, January 17, 2017 10:35:06 PM Hans Petter Selasky wrote: > On 01/17/17 22:28, Hans Petter Selasky wrote: > > + state->nextcall = SBT_MAX; > > + state->nextcallopt = now + 1; > > BTW: What locks are protecting the update of these fields? Can

Re: Strange issue after early AP startup

On Tuesday, January 17, 2017 10:28:47 PM Hans Petter Selasky wrote: > On 01/17/17 20:46, Ian Lepore wrote: > >>> Does this matter for the first tick? How often is configtimer() called? > >> > > >> > As I said, it is called at runtime when profclock is started / stopped, > >> > not > >> > just at

Re: Strange issue after early AP startup

In message <1492450.xzfnz8z...@ralph.baldwin.cx>, John Baldwin writes: > On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote: > > In message , Hans Petter > > Sela > > sky writes: > > > Hi, > > > > > > When booting I observe an additional

Re: NFS 4.1

The vmware client will not work with the FreeBSD server at this time. It does a ReclaimComplete with file system boolean set ``true``. This isn`t supported by the FreeBSD server at this time. (vmware is the only client that does this, as far as I am know.) The fix is probably simple, but since I

Re: Strange issue after early AP startup

On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote: > In message , Hans Petter > Sela > sky writes: > > Hi, > > > > When booting I observe an additional 30-second delay after this print: > > > > > Timecounters tick every 1.000 msec > >

Re: Strange issue after early AP startup

On Tuesday, January 17, 2017 08:31:28 PM Hans Petter Selasky wrote: > Hi, > > On 01/17/17 20:00, John Baldwin wrote: > >> > >> Does this matter for the first tick? How often is configtimer() called? > > > > As I said, it is called at runtime when profclock is started / stopped, not > > just at

Help! Howto installworld crashed system with USB image?

Within the past several hours, FreeBSD crashed due to serious bugs and some boxes of ours hang with the uncomplete workaround with EARLY_AP_STARTUP. During a recompilation and installworld/installkernel, one of my workstations suddenly crashed and spontaneously rebooted. After that, the loader

Re: Strange issue after early AP startup

On 01/17/17 22:28, Hans Petter Selasky wrote: + state->nextcall = SBT_MAX; + state->nextcallopt = now + 1; BTW: What locks are protecting the update of these fields? Can they be written simultaneously by configtimer() and cpu_new_callout()? --HPS

Re: Strange issue after early AP startup

On 01/17/17 20:46, Ian Lepore wrote: Does this matter for the first tick? How often is configtimer() called? > > As I said, it is called at runtime when profclock is started / stopped, not > just at boot. Those changes at runtime probably have existing callouts > active and your change will

Re: Strange issue after early AP startup

In message , Hans Petter Sela sky writes: > Hi, > > When booting I observe an additional 30-second delay after this print: > > > Timecounters tick every 1.000 msec > > ~30 second delay and boot continues like normal. > > Checking "vmstat -i"

r312349 crashes: null filesizes: rescue with usb stick impossible due to lack of CC

FreeBSD crashes (r312349): during installworld and installkernel, the running system crashed and left me with a nullyfied Samsung 850 PRO SSD, means: almost every binary in /bin, /sbin, /usr/bin, /usr/sbin has filesize NULL, execpt /bin/sh. Booting is impossible. Since it is unknown what the

Re: r312348: igb broken: reporting wrong linkspeed!

> On Jan 17, 2017, at 11:54, Hartmann, O. wrote: > > 12-CURRENT (FreeBSD 12.0-CURRENT #74 r312348: Tue Jan 17 19:54:58 CET > 2017 am64) reports the wrong linkspeed on a dualport Intel i350 NIC: > > igb0: flags=8843 metric 0 mtu >

r312348: igb broken: reporting wrong linkspeed!

12-CURRENT (FreeBSD 12.0-CURRENT #74 r312348: Tue Jan 17 19:54:58 CET 2017 am64) reports the wrong linkspeed on a dualport Intel i350 NIC: igb0: flags=8843 metric 0 mtu 1500

Re: Strange issue after early AP startup

On Tue, 2017-01-17 at 11:00 -0800, John Baldwin wrote: > >  > You could > >  > do that by setting it to 'cc_firstevent' of the associated CPU, but in > >  > practice 'state->nextcall' should already be set to that (it is  > > initalized > >  > to SBT_MAX in cpu_initclocks_bsp() and is then only

Re: Strange issue after early AP startup

Hi, On 01/17/17 20:00, John Baldwin wrote: Does this matter for the first tick? How often is configtimer() called? As I said, it is called at runtime when profclock is started / stopped, not just at boot. Those changes at runtime probably have existing callouts active and your change will

Re: Strange issue after early AP startup

On Tuesday, January 17, 2017 07:04:15 PM Hans Petter Selasky wrote: > On 01/17/17 16:50, John Baldwin wrote: > > On Monday, January 16, 2017 10:10:16 PM Hans Petter Selasky wrote: > >> On 01/16/17 20:31, John Baldwin wrote: > >>> On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky

Re: NFS 4.1

Thanks for the reply Russell, I'm looking to set up a 4.1 server in order to host vmware images. I have set up an exports but I get an error stating NFS 4 is not supported when trying to attach it in VM storage. Is there any documentation for setting this up? Thanks Mike On Tue, Jan 17, 2017 at

Re: TSC as timecounter makes system lag

On Tue, Jan 17, 2017 at 10:05 PM, Hans Petter Selasky wrote: > I've seen something similar. Does the attached patch make any difference? > > Can you dump: > > vmstat -i > > Just after boot w/ and w/o the attached patch, when the keystroke did not > repeat smoothly. > > Your

Re: Strange issue after early AP startup

On 01/17/17 16:50, John Baldwin wrote: > On Monday, January 16, 2017 10:10:16 PM Hans Petter Selasky wrote: >> On 01/16/17 20:31, John Baldwin wrote: >>> On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote: Hi, When booting I observe an additional 30-second delay

Re: NFS 4.1

On 01/17/17 10:38, Michael Ware wrote: Good day, Does anyone know if NFS 4.1 (not 4.0) is available in FreeBSD 11? I have not been able to find any documentation around this. Thanks Yes, though I'm not sure what specific feature you're looking for. FreeBSD interoperates with my linux NFS 4.1

Re: Strange issue after early AP startup

On 01/17/17 16:50, John Baldwin wrote: Index: kern_clocksource.c === --- kern_clocksource.c (revision 312301) +++ kern_clocksource.c (working copy) @@ -503,7 +503,12 @@ configtimer(int start)

NFS 4.1

Good day, Does anyone know if NFS 4.1 (not 4.0) is available in FreeBSD 11? I have not been able to find any documentation around this. Thanks -- Mike ___ freebsd-current@freebsd.org mailing list

Re: Strange issue after early AP startup

On 01/17/17 16:50, John Baldwin wrote: (One odd thing is that even in your case the first call to handleevents(), the 'now => state->nextcallout' check in handleevents() should be true which resets both nextcall and nextcallopt and invokes callout_process().) Hi, I suspect the

Re: Strange issue after early AP startup

On Monday, January 16, 2017 10:10:16 PM Hans Petter Selasky wrote: > On 01/16/17 20:31, John Baldwin wrote: > > On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote: > >> Hi, > >> > >> When booting I observe an additional 30-second delay after this print: > >> > >>> Timecounters tick

Re: Panic on boot current amd64

Am Tue, 17 Jan 2017 06:45:42 -0700 Sean Bruno schrieb: > On 01/17/17 02:10, O. Hartmann wrote: > > Am Mon, 16 Jan 2017 10:33:35 -0800 > > Manfred Antar schrieb: > > > >> From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get > >> panic

Re: TSC as timecounter makes system lag

On 01/16/17 15:34, Jia-Shiun Li wrote: Yes. I noticed this because systat refreshes looked slower, and keystroke did not repeat smoothly for 30/s. I've seen something similar. Does the attached patch make any difference? Can you dump: vmstat -i Just after boot w/ and w/o the attached patch,

Re: Panic on boot current amd64

On 01/17/17 02:10, O. Hartmann wrote: > Am Mon, 16 Jan 2017 10:33:35 -0800 > Manfred Antar schrieb: > >> From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get >> panic on boot. >> reverting to r312235 boot ok >> >> random: harvesting attach, 8 bytes (4 bits)

Re: r311568 makes freerdp very slow

On Fri, January 13, 2017 22:46, Jakob Alvermark wrote: > On Fri, January 13, 2017 19:44, John Baldwin wrote: > >> On Friday, January 13, 2017 09:58:01 AM Jakob Alvermark wrote: >> >> >>> On Thu, January 12, 2017 19:26, John Baldwin wrote: >>> >>> On Thursday, January 12, 2017 12:42:11 PM

Re: Panic on boot current amd64

Am Mon, 16 Jan 2017 10:33:35 -0800 Manfred Antar schrieb: > From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get > panic on boot. > reverting to r312235 boot ok > > random: harvesting attach, 8 bytes (4 bits) from uhub9 > ugen1.3: at usbus1 > kernel trap 12

Re: Panic on boot current amd64

Am Mon, 16 Jan 2017 10:33:35 -0800 Manfred Antar schrieb: > From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get > panic on boot. > reverting to r312235 boot ok > > random: harvesting attach, 8 bytes (4 bits) from uhub9 > ugen1.3: at usbus1 > kernel trap 12