Re: My problems with stability on -current

2011-05-10 Thread Doug Barton
I had an interesting result doing nothing but switching from HPET to 
LAPIC ... no crash. Still on the same version of -current (r221566) the 
only thing I've done is to add kern.eventtimer.timer="LAPIC" to 
/boot/loader.conf, and so far I haven't been able to get it to crash no 
matter how much I compile, or how much other stuff I do in the 
background. I _can_ get the system heavily loaded enough so that the 
mouse can drag across the screen, windows take visible time to repaint, 
etc. That happens with a load average of 4+ on this core 2 duo. But 
other than that (which is not altogether unreasonable) the system has 
been very stable for a couple of days now.


Does that suggest a next step in terms of what to test?

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: My problems with stability on -current

2011-05-10 Thread Jason Hellenthal

Alexander,

On Tue, May 10, 2011 at 11:05:04AM +0300, Alexander Motin wrote:
> Hi.
> 
> On 10.05.2011 05:05, Jason Hellenthal wrote:
> > On Tue, May 10, 2011 at 04:29:25AM +0300, Alexander Motin wrote:
> >> On 10.05.2011 02:48, Doug Barton wrote:
> >>>
> >>> Ok, so kern.eventtimer.timer="LAPIC" in /boot/loader.conf should do
> >>> that, right?
> >>
> >> Yes. You can do it in run-time also.
> >
> > Not quite absolutely sure here but IIRC the last time I tried setting that
> > via loader.conf in 8-STABLE it was not being set so I eventually added it
> > to sysctl.conf. Just for reference I never looked into it further.
> 
> There is no kern.eventtimer sysctls on 8-STABLE yet, so not sure what 
> you were setting.
> 

Ugh! yeah I had that mixed up with kern.timecounter. Somehow transcribed 
the two.

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpidR443gME7.pgp
Description: PGP signature


[Call for Test] unionfs intermediate umount feature

2011-05-10 Thread Daichi GOTO
Hi unionfs users ;)

We have developed new unionfs feature, "intermediate umount".
You can do like this:

  # mount_unionfs /test2 /test1
  # mount_unionfs /test3 /test1
  # df
  :/test2  x x x  xx%  /test1
  :/test3  x x x  xx%  /test1
  # umount ':/test2'
  # df
  :/test3  x x x  xx%  /test1
  #

patch for current:

http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-intermediate-umount.diff

First, I want to know your opinion. Thanks :)

-
Daichi GOTO___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: COUNT_IPIS vs CPU_FOREACH

2011-05-10 Thread Andriy Gapon
on 09/05/2011 16:35 John Baldwin said the following:
> On Saturday, May 07, 2011 5:37:26 am Andriy Gapon wrote:
>>
>> I believe that the following change is needed to fix COUNT_IPIS option.
>> Right now it seems to be a noop.
>>
>>
>> mp_ipi_intrcnt: CPU_FOREACH can't be used this early
>>
>> ... because all_cpus is not set yet.
> 
> Have you tested this?
> 
> all_cpus is set by start_all_aps() from cpu_mp_start() which runs at 
> SI_SUB_CPU.   This SYSINIT runs later at SI_SUB_INTR.
> 
> So I think CPU_FOREACH() should be fine here.

I think that you are right, it seems that I've screwed up my original
(pre-patch) testing - installed my experimental kernel to a wrong place.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: My problems with stability on -current

2011-05-10 Thread Andriy Gapon
on 10/05/2011 05:05 Jason Hellenthal said the following:
> 
> Alexander,
> 
> On Tue, May 10, 2011 at 04:29:25AM +0300, Alexander Motin wrote:
>> On 10.05.2011 02:48, Doug Barton wrote:
>>>
>>> Ok, so kern.eventtimer.timer="LAPIC" in /boot/loader.conf should do
>>> that, right?
>>
>> Yes. You can do it in run-time also.
> 
> Not quite absolutely sure here but IIRC the last time I tried setting that 
> via loader.conf in 8-STABLE it was not being set so I eventually added it 
> to sysctl.conf. Just for reference I never looked into it further.

Perhaps you are confusing selection of eventtimer with choice of timecounter?
For the latter indeed there is no tunable, which is a small annoyance.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: My problems with stability on -current

2011-05-10 Thread Alexander Motin

Hi.

On 10.05.2011 05:05, Jason Hellenthal wrote:

On Tue, May 10, 2011 at 04:29:25AM +0300, Alexander Motin wrote:

On 10.05.2011 02:48, Doug Barton wrote:


Ok, so kern.eventtimer.timer="LAPIC" in /boot/loader.conf should do
that, right?


Yes. You can do it in run-time also.


Not quite absolutely sure here but IIRC the last time I tried setting that
via loader.conf in 8-STABLE it was not being set so I eventually added it
to sysctl.conf. Just for reference I never looked into it further.


There is no kern.eventtimer sysctls on 8-STABLE yet, so not sure what 
you were setting.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: geom kernel proc

2011-05-10 Thread Julian Elischer

On 5/9/11 3:00 PM, Andrew Thompson wrote:

Hi,


I have a cosmetic patch that moves the geom kprocs to kthreads

from

PID  TT  STAT  TIME COMMAND
 2  ??  DL 2:38.03 [g_event]
 3  ??  DL49:43.61 [g_up]
 4  ??  DL57:10.71 [g_down]

to

% procstat -t 13
   PIDTID COMM TDNAME   CPU  PRI STATE   WCHAN
13 100021 geom g_event1   92 sleep   -
13 100022 geom g_up   3   92 sleep   -
13 100023 geom g_down 3   92 sleep   -

Any objections?


Andrew


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

sounds ok to me.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"