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 with interrupts
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 with interrupts
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 Shawn
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) from uhub9
>> u
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,
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 on
> >> boot. reverting to r312235 bo
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 e
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 cpu_new_callout(
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
https://lists.freebsd.org/mailman/listinfo/freebsd-curren
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)
state->
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 s
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 after
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 patch fixes this issue
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 10
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 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 boot. Those changes at runtime probably have existing callouts
active and your change will no
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 set
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
options=653dbb
ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xff00 broadcast
192.168.0.255 nd6 options=29
> 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
> 1500
> options=653dbb
> ether xx:xx:xx:xx:xx:xx inet 192.168.0.11
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 crash
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" reveals that some timers have been running loose.
>
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 not
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
_
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 comp
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
> >
> > ~30 second delay and boot continues like normal
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 boo
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
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 30-second delay after this print:
> > >
> > > > Ti
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 b
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
> > > sky writes:
> > > > Hi,
> > > >
> > > > When
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 th
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 client
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 /sb
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 ==
34 matches
Mail list logo
