on 03/06/2011 20:57 Robert N. M. Watson said the following:
>
> On 3 Jun 2011, at 16:13, Andriy Gapon wrote:
>
>> I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I
>> am very interested to learn about your usecase for it.
>
> The issue that
on 03/06/2011 18:28 Nathan Whitehorn said the following:
> On 06/03/11 10:13, Andriy Gapon wrote:
>>
>> I wonder if anybody uses kdb_stop_cpus with non-default value.
>> If, yes, I am very interested to learn about your usecase for it.
>>
>> I think that the defaul
n a hang if another cpu has interrupts disabled
> and is spinning, since the IPI won't be received and the KDB will wait
> indefinitely. We probably need to add a timeout, but this is a useful
> stopgap in the mean time.
But that was before we started using hard stop in
otlogs:
> http://people.freebsd.org/~mr/boot_fail2.txt
> http://people.freebsd.org/~mr/boot_success2.txt
>
> As you can see, in the failing case ZFS tries to attach to ada[0123]
> whereas in the succeeding case ZFS attaches to ada[0123]p3 (which are the
> correct devices)
Maybe try to e
on 31/05/2011 16:34 Attilio Rao said the following:
> 2011/5/31 Andriy Gapon :
>> on 29/05/2011 06:06 Attilio Rao said the following:
>>> 2011/5/28 Attilio Rao :
>>>> 2011/5/25 Andriy Gapon :
>>>>> The patch is here:
>>>>> http://peo
on 29/05/2011 06:06 Attilio Rao said the following:
> 2011/5/28 Attilio Rao :
>> 2011/5/25 Andriy Gapon :
>>> The patch is here:
>>> http://people.freebsd.org/~avg/cpu-offline-sysctl.diff
>>> It should implement the strategy described above.
>>>
e. You get to use
> sysinstall and don't have to manually install the OS.
There is no sysinstall :-) [in the latest CURRENT]
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To uns
ally forgot - what about lockd and statd?
Do I still need them with newnfs and NFSv3 to get fcntl/flock working?
And do those actually work? :-)
I understand that with NFSv4 I don't need those anymore.
--
Andriy Gapon
___
freebsd-current@
st don't compile/install this module (I have
MODULES_OVERRIDE), so no problem here.
--
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"
an example here.
Also, for my future tests, I would like to get some pointers on getting started
with NFSv4 in FreeBSD.
Thanks!
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubs
Arnaud has forgot to set
UNAME_m="i386"
UNAME_p="i386"
in the environment of his build shell within the jail.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
on 23/05/2011 19:28 Andriy Gapon said the following:
> I propose the following path for moving forward.
> - use hint.lapic.X.disabled to disable individual CPUs by their APIC ID
> - use machdep.hyperthreading_allowed tunable to disable second logical CPU on
> each
> real core
", but when used as "march" option, PentiumPro
instruction set will be used, so the code will run on all i686
family chips.
> Why not go along a supported way, and do a cross-build?
There is nothing wrong about the day he does it.
And a classic cross-build won't help with setting i586 or lower that he needs:
i586, pentium
Intel Pentium CPU with no MMX support.
Just my 2 cents.
--
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"
on 19/05/2011 19:58 Andriy Gapon said the following:
> on 18/05/2011 20:04 Attilio Rao said the following:
>> 2011/5/18 Garrett Cooper :
>>> We use this internally at work still with a software config that uses 4BSD
>>> so
>>> as long as there is an equivalen
> I thought Andriy attached a patch to the tree, but it doesn't seem so...
> anyway, yes, I think that adding tunables for this is very reasonable and not
> as dangerous as the current mechanism.
I agree.
I haven't sent a patch, because I don't have it yet :)
I decided to so
argeSMP project
Once we grow correct code for offlining CPUs, then we could re-introduce the
sysctls without any problems.
While the offlining code doesn't seem terribly hard to develop, it's a big piece
of work and requires time and
048576, medsize = 65536, minsize = 2048
> startsize block-len state done remaining%
> done
> 0 1048576 243052544 0 0 243052544
> 0.0
> 0 1048576 failed (Device not configured)
--
Andriy Gapon
_
y media you try?
2. does the same not happen with the media you tried with any other drive?
--
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"
on 17/05/2011 10:19 Andriy Gapon said the following:
> So I am going to commit this.
> If it breaks anything for anyone and the problem would not be really trivial,
> the I'll just revert the change.
>
r222051.
Please take this commit in consideration if you run into any USB-
on 17/05/2011 18:51 John Baldwin said the following:
> On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote:
>> on 17/05/2011 16:58 John Baldwin said the following:
>>> No, it doesn't quite work that way. It wouldn't work on Alpha for example.
>>>
>
v = *p; \
> mips_sync();\
> return (v); \
> } \
I should have checked this myself.
Thank you for patiently explaining these things to me.
--
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"
on 17/05/2011 14:56 John Baldwin said the following:
> On 5/17/11 4:03 AM, Andriy Gapon wrote:
>> Couldn't [Shouldn't] the whole:
>>
>>>>> /* Ensure we have up-to-date values. */
>>>>> atomic_add_acq_int(&smp_rv_waiters[
on 16/05/2011 23:09 John Baldwin said the following:
> On Monday, May 16, 2011 3:27:47 pm Andriy Gapon wrote:
>> on 16/05/2011 21:21 John Baldwin said the following:
>>> How about this:
>> ...
>>> /*
>>> * Shared mutex to restrict busywaits between s
t revert the change.
--
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"
ocal_teardown_func = smp_rv_teardown_func;
I want to ask once again - please pretty please convince me that the above
cpu_spinwait() loop is really needed and, by extension, that the assignments
should be moved behind it.
Please :)
--
Andriy Gapon
___
freebsd
on 15/05/2011 18:16 John Baldwin said the following:
> On 5/15/11 10:53 AM, Andriy Gapon wrote:
>> on 15/05/2011 10:12 Andriy Gapon said the following:
>>> on 14/05/2011 18:25 John Baldwin said the following:
>>>> Hmmm, so this is not actually sufficient. NetApp ran
t; generation
> version?
No reason. And I even haven't said that I prefer it :-)
I just wanted to show and explain it as apparently there was some
misunderstanding about it. I think that generation count approach could even
have a little bit better performance while
on 15/05/2011 10:12 Andriy Gapon said the following:
> on 14/05/2011 18:25 John Baldwin said the following:
>> Hmmm, so this is not actually sufficient. NetApp ran into a very similar
>> race
>> with virtual CPUs in BHyVe. In their case because virtual CPUs are threa
on 15/05/2011 07:33 Max Laier said the following:
> On Saturday 14 May 2011 11:25:36 John Baldwin wrote:
>> On 5/13/11 9:43 AM, Andriy Gapon wrote:
>>> This is a change in vein of what I've been doing in the xcpu branch and
>>> it's supposed to fix the issu
my patch no
slave CPU actually waits/spins on smp_rv_waiters[2]? It's always only master
CPU (and under smp_ipi_mtx).
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe
on 14/05/2011 18:25 John Baldwin said the following:
> On 5/13/11 9:43 AM, Andriy Gapon wrote:
>>
>> This is a change in vein of what I've been doing in the xcpu branch and it's
>> supposed to fix the issue by the recent commit that (probably
>> unintentional
Having
the check at the start should trigger the synchronization only when it is really
required.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
on 13/05/2011 18:50 Max Laier said the following:
> On Friday 13 May 2011 11:28:33 Andriy Gapon wrote:
>> on 13/05/2011 17:41 Max Laier said the following:
>>> this ncpus isn't the one you are looking for.
>>
>> Thank you!
>>
>> Here's an up
on 13/05/2011 17:41 Max Laier said the following:
> this ncpus isn't the one you are looking for.
Thank you!
Here's an updated patch:
Index: sys/kern/subr_smp.c
===
--- sys/kern/subr_smp.c (revision 221835)
+++ sys/kern/subr_smp.c (
smp_no_rendevous_barrier)
- while (atomic_load_acq_int(&smp_rv_waiters[2]) < ncpus)
+ while (atomic_load_acq_int(&smp_rv_waiters[1]) < ncpus)
cpu_spinwait();
/* release lock */
--
Andriy Gapon
__
roach suggested by pjd. The only minor drawback is very
small code duplication.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "f
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_intrcn
ference 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://list
/Combinatorial Algorithms: Theory and
> Pratice/ in 77.
>
> The code in systm.h appears to be a slightly less optimized version of the
> algorithm presented in SWAR or Hacker's Delight.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing
on 07/05/2011 23:22 Stefan Bethke said the following:
>
> Am 07.05.2011 um 12:47 schrieb Kostik Belousov:
>
>> On Sat, May 07, 2011 at 12:58:11PM +0300, Andriy Gapon wrote:
>>>
>>> I think that the SWAR reference should be more concise and should lead an
>>
0F0F) % 255)
- * #define BX_(x) ((x) - (((x)>>1)&0x)\
- * - (((x)>>2)&0x)\
- * - (((x)>>3)&0x))
+ * Population count algorithm using SWAR approach
+ * - &quo
k) | pc->pc_cpumask;
- smp_rendezvous_cpus(map, dtrace_gethrtime_init_sync,
+ smp_rendezvous_cpus(map, NULL,
dtrace_gethrtime_init_cpu,
smp_no_rendevous_barrier, (void *)(uintptr_t)
d:invltlb", i);
intrcnt_add(buf, &ipi_invltlb_counts[i]);
snprintf(buf, sizeof(buf), "cpu%d:invlrng", i);
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mai
on 06/05/2011 16:00 John Baldwin said the following:
> On Friday, May 06, 2011 4:55:00 am Andriy Gapon wrote:
>>
>> I would like to ask for a review and/or testing of the following patch:
>> http://people.freebsd.org/~avg/dev_dsp_mmap.diff
>>
>> It's s
on 06/05/2011 16:38 Andriy Gapon said the following:
> on 06/05/2011 16:32 Kostik Belousov said the following:
>> Your patch hardcodes an assumption that sndbufs are always
>> contiguous. I was unable to convince myself that this is true.
>
> I think that this should be true
on 06/05/2011 16:32 Kostik Belousov said the following:
> On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote:
>>
>> I would like to ask for a review and/or testing of the following patch:
>> http://people.freebsd.org/~avg/dev_dsp_mmap.diff
>>
>> It
ld do the right thing:
fd = open(/dev/dsp, O_RDWR);
mmap(PROT_READ, fd);
mmap(PROT_WRITE, fd);
Thank you!
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any ma
for alias name.
>
> GEOM_PART uses g_alias_create() to create aliases for labeled partitions
> (gpt/gptid, apm and pc98).
>
> How it looks like:
> http://paste.org.ru/?5exeve
>
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing
070...@freebsd.org>
Date: Tue, 26 Apr 2011 19:50:02 +0300
From: Andriy Gapon
To: multime...@freebsd.org
Subject: SNDCTL_DSP_GETIPTR implementation
Guys,
I reading this http://manuals.opensound.com/developer/SNDCTL_DSP_GETOPTR.html
It says: "In mmap mode (only) the ptr field tells the location whe
code is of much use if a user has to set some
tunable to actually use it over HPET or ACPI-fast. I thought that the whole
point was in automatically choosing the best timecounter. I would go the
opposite way - if automatic selection of TSC causes any trouble then provide a
way to disable it.
but your DSDT has to
[correctly] define TZ object.
> The hardware is likely to be there for any reasonably modern Dell desktop. Do
> you have coretemp loaded?
I think that coretemp works directly with CPU and is not related to the problem
at hand.
--
Andriy Gapon
_
usb_probe is called
> again is a kludge, specifically for the description.
I am not sure that I understood this part.
> I guess that documenting this kludge and updating the comment to state this
> fact would be sufficient to solve the problem.
I don't see how this follows from wh
legacy method will keep working with Bulldozer, but I am
not
completely sure. Anyway, I hope to find some time to improve our topology
detection code so that it doesn't assume uniformity and also takes into account
cache topology. And then this change will be more useful.
--
Andriy
You have to be familiar with assembly and know basic behavior of BIOS booting
(supposing we talk about x86) and FreeBSD boot blocks, e.g. what is loaded at
what address.
Here's an example of something related:
http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008580.htm
on 08/04/2011 08:51 Andriy Gapon said the following:
> on 07/04/2011 13:59 Alexander Motin said the following:
>> Any objections? Or SCSI/IDE there expected to mean command set?
>>
>
> Sorry for saying something potentially stupid, but... do we actually have any
> reason
rsp),%r9/* user stack pointer */
> + movq %r9,%rsp /* original %rsp */
> + swapgs
> + sysretq
> +3: /* Requested full context restore, use doreti for that. */
> MEXITCOUNT
> jmp doreti
>
--
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"
on 07/04/2011 13:59 Alexander Motin said the following:
> Any objections? Or SCSI/IDE there expected to mean command set?
>
Sorry for saying something potentially stupid, but... do we actually have any
reason to make that distinction from any practical point?
--
Andriy
ware until all APs are started properly.
Great! Thank you for the info and your work.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to &qu
APM enabled.\n");
}
+ if (tsc_is_invariant)
+ tsc_timecounter.tc_quality = 1200;
+
#ifdef SMP
/*
* We can not use the TSC in SMP mode unless the TSCs on all CPUs
--
Andriy Gapon
___
freebsd-current@free
on 06/04/2011 16:28 Hans Petter Selasky said the following:
> On Wednesday 06 April 2011 15:21:19 Andriy Gapon wrote:
>> on 06/04/2011 10:33 Hans Petter Selasky said the following:
>
>>
>> Which drivers I have missed?
>> Thanks!
>
> Run a kernel test compile
ead updating your
> patch to cover all USB drivers using use_generic.
Which drivers I have missed?
Thanks!
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any m
on 05/04/2011 15:55 Hans Petter Selasky said the following:
> On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote:
>>
>> I believe that newbus already supports ordering of children on a bus.
>>
>> BTW, does USB have to pass anything from probe to attach?
>
> Most
on 05/04/2011 14:21 Hans Petter Selasky said the following:
> On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote:
>> on 03/04/2011 13:46 Andriy Gapon said the following:
>>> Mostly out of curiosity (but not only because of that) I wonder why the
>>> use_generic flag
on 03/04/2011 13:46 Andriy Gapon said the following:
>
> Mostly out of curiosity (but not only because of that) I wonder why the
> use_generic flag and two probing passes are needed in USB driver probing code.
> That is, why the standard approach of using different probing return v
systems are, it's better
to
be slow and cautious.
All the ideas that I suggested were more for the "next step" than for now.
Thank you for the work!
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/m
t could have been recently fixed.
--
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"
me.
Please see recent messages in its archive, perhaps they could help you.
--
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"
uld be a subcase of the other
--
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"
1 buildkernel
The makeoptions line above should be completely equivalent to your suggestion
for
kernel builds.
--
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"
on 23/03/2011 13:55 Andriy Gapon said the following:
> on 23/03/2011 12:23 Anton Yuzhaninov said the following:
>> On this page:
>> http://wiki.freebsd.org/DTrace
>>
>> written, that for 9-current is sufficient to rebild kernel with this
>> options:
>>
ons work for me here.
> full build log:
> https://hius.citrin.ru/a/2011-03-23-buildkernel.log
>
> FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r219710M
>
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/ma
ention - not everyone has as
good mastery of English as you do. And sometimes some people are more prone to
doubts.
Maybe you can give Aleksandr some help with the code in addition to your advice?
--
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"
SD: head/usr.sbin/powerd/powerd.c 211415 2010-08-17 09:11:38Z brucec $)
> also shows it attempting to work with dev.cpu.0.freq.
>
> Am I managing to overlook something fairly significant here?
>
> The hardware in question is a Dell Precis
eebsd/
>>
>
> Man pages are available on-line.
>
> http://www.freebsd.org/cgi/man.cgi?query=pthread_setaffinity_np&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&format=html
>
And the actual functions that should be used on modern FreeBSD are
cpuset_setaffinity and cpuset_
d very much like the issues that John
Baldwin has been trying to solve a short while ago. My recollection is that he
committed some improvements for real time priority processes. Perhaps he'll
have
some additional insights based on his observations and testing.
--
Andriy Gapon
_
formation.
Primarily est uses ACPI interface to do its work. Hardcoded MSR tables are only
the last resort mechanism, and indeed those support only a handful of models.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.free
he commit resulted in some signals being lost
sometimes, in particular SIGCHLD.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-cu
I agree.
I am going on vacation and I don't want to risk, so it looks like I will be able
to commit your patch after the holidays. Unless someone else beats me to it.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freeb
on 21/12/2010 11:27 Artem Belevich said the following:
> On Tue, Dec 21, 2010 at 1:26 AM, Artem Belevich wrote:
>> On Mon, Dec 20, 2010 at 3:15 AM, Andriy Gapon wrote:
>>> It would be nice to get the i386 counterpart too when this goes into the
>>> tree.
>>
&
es on. I'll try to get one set up under
> VirtualBox later, but for now the patch is for 8-STABLE/amd64 only.
It would be nice to get the i386 counterpart too when this goes into the tree.
Thanks!
--
Andriy Gapon
___
freebsd-current@freebsd.or
ouldn't have been the panic though ("bio_completed can't be greater than
bio_length").
It's a possible geom or ad driver problem.
What is your geom topology on this system?
Changing cc: from fs@ to g...@.
--
Andriy Gapon
___
free
rces?
But the lock up is totally unexpected, try to debug it.
--
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"
attempts though.
>>>>
>>>> Hi,
>>>>
>>>> Can you reproduce the panic using a kernel built with INVARIANTS options
>>>> and DEBUG_MEMGUARD .
>>>
>>> I rebuilt my kernel with options you mentioned ( have added
>>>
on 06/12/2010 21:27 Jung-uk Kim said the following:
> On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote:
>> on 06/12/2010 21:01 Jung-uk Kim said the following:
>>> :-) Don't get me wrong, I generally agree with you *iff* it does
>>> : not
>>>
>>
have a stable source "cpu ticks", and then everything else
should just work?
BTW, if someone comes up with a patch for more or less correct accounting when
"cpu ticks" frequency is allowed to change, then I am all for it.
But, IMO, it's just easier to us
be it's okay.
Overlooked this point - TSC can be very well used as a timecounter.
And in that case non-invariant TSC would veto P-state changes, which is the
proper
thing to do, IMO.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://
me for execution
> of expf.
Just guessing - could you try setting sysctl kern.eventtimer.periodic=1 if it's
not 1 already?
And cc-ing Alexander, just in case.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mai
on 06/12/2010 20:34 Jung-uk Kim said the following:
> On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote:
>> on 06/12/2010 19:42 Jung-uk Kim said the following:
>>> Sigh... Please see the history of calcru() in
>>> sys/kern/kern_resource.c. Most impor
on 06/12/2010 20:01 John Baldwin said the following:
> Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could
> be a factor? It might change when statclock() is called.
But I think that that code was committed more than 7-10 days ago, which Steve
mentioned.
--
achines have invariant TSC and, in Intel's
words, that's an architectural path going forward.
So, I don't think that I propose a dramatic change.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/
ng_pppoe.
> while I like mpd, I should point out that the regular 'in source' ppp that
> comes
> with
> freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x 7 on my
> gateway
> as I never got around to installing mpd and it "d
just incorrect.
kern.timecounter.hardware is not going to be changed as frequently as P-states,
if ever.
--
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"
on 03/12/2010 22:03 Jung-uk Kim said the following:
> On Friday 03 December 2010 01:14 pm, Andriy Gapon wrote:
>> on 03/12/2010 20:05 Jung-uk Kim said the following:
>>> On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote:
>>>> FreeBSD uses cpu_ticks [function
on 03/12/2010 20:05 Jung-uk Kim said the following:
> On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote:
>> FreeBSD uses cpu_ticks [function pointer] in a few places for a few
>> things like process CPU time accounting. On x86 cpu_ticks always
>> points to rdtsc. If
f
What do you think?
P.S. it's probably a good idea to merge i386 and amd64 tsc.c files into a common
x86 version, which would be the same as i386 version, which seems to be generic
enough.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
on 26/11/2010 21:08 Alexander Best said the following:
> On Fri Nov 26 10, Andriy Gapon wrote:
>> on 26/11/2010 00:25 Alexander Best said the following:
>>> hi there,
>>>
>>> i've tripped over two issues with the cdfs:
>>
>> What's cdfs? :
on 26/11/2010 15:48 Bruce Cran said the following:
> On Fri, 26 Nov 2010 15:28:00 +0200
> Andriy Gapon wrote:
>
>> What's cdfs? :-/
>
> Apparently it's another name for ISO 9660 -
> http://en.wikipedia.org/wiki/ISO_9660 - which we call cd9660.
Hen
981027 bytes (in my case).
Likely we don't support multi-extent files at the moment.
P.S. version of mkisofs could have been important too
--
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"
t two are generated from single lists, the last two are
>>> combined, with different preference order.
>
> oh...and i think it would be a good idea to move from ";" as comment character
> to "#". that way we wouldn't need to run a script, but could include
on 22/11/2010 16:30 John Baldwin said the following:
> No. Especially since the structure is private it can always be revived if a
> use is found for it. You can probably leave the taskqueue_create() API the
> same for now though.
>
OK. Committed.
Thank you!
--
901 - 1000 of 1235 matches
Mail list logo
