/usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run
make -C /usr/src check-old.
make -C /usr/src delete-old removes the file, but
make -C /usr/src installworld adds it.
System is base/head r309889.
Please make up your mind.
--
+---+
On Fri, Dec 16, 2016 at 03:17:19AM +0100, Luigi Rizzo wrote:
> TL;DR; is there any way a userspace thread in FreeBSD can tell
> on which CPU it is (was) running ? I know the thread can migrate
> at any time but as long as the event is rare I can live with
> the occasionally wrong information.
> Li
I found the attached patch (which augments ITOOLS in src/Makefile.inc1
with "env" and "mktemp") necessary to complete "make installworkd"
when updtaing from:
FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #197
r310104M/310111:1200018: Thu Dec 15 04:20:23 PST 2016
r...@fr
On 12/16/2016 04:31, Trond Endrestøl wrote:
> /usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run
> make -C /usr/src check-old.
>
> make -C /usr/src delete-old removes the file, but
> make -C /usr/src installworld adds it.
>
> System is base/head r309889.
>
> Please make up your mi
On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
> On 16 Dec 2016, at 03:10, Alan Somers wrote:
> >
> > What about pthread_setaffinity(3) and friends? You can use it to pin
> > a thread to a single CPU, and know that it will never migrate.
>
> This is not a useable solution for a
On 16 December 2016 at 11:45, Luigi Rizzo wrote:
> On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
>> On 16 Dec 2016, at 03:10, Alan Somers wrote:
>> >
>> > What about pthread_setaffinity(3) and friends? You can use it to pin
>> > a thread to a single CPU, and know that it will n
On Friday, December 16, 2016 12:10:01 PM Adrian Chadd wrote:
> On 16 December 2016 at 11:45, Luigi Rizzo wrote:
> > On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
> >> On 16 Dec 2016, at 03:10, Alan Somers wrote:
> >> >
> >> > What about pthread_setaffinity(3) and friends? You c
On Thursday, December 15, 2016 03:57:58 PM Adrian Chadd wrote:
> heh, an updated BIOS that solves the problem will solve the problem. :)
>
> I think you have enough information to provide to supermicro. Ie,
> "SMAP says X, when physical memory pages at addresses X are accessed,
> they don't behave
On 12/12/16 23:08, Lewis ingraham wrote:
Hi FreeBSD Current Team, I need help with a few things:
1. I tried getting help from all kinds of irc chats but still no dice.
2. I cannot get my soundcard to work on FreeBSD. It is the Soundblaster
Z(SB1500, SB1502) with the CA0132 codec.
I really LO
On Wednesday, December 14, 2016 04:50:21 PM Mark Johnston wrote:
> On Wed, Dec 14, 2016 at 03:48:04PM -0800, Steven G. Kargl wrote:
> > On Wed, Dec 14, 2016 at 02:10:48PM -0800, Mark Johnston wrote:
> > > On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote:
> > > > On Wed, Dec 14, 2016 at
On Fri, Dec 16, 2016 at 03:19:09PM -0800, John Baldwin wrote:
>
> So the hack in pause() is probably not as necessary now. In particular, I
> think we only need it for thread0, not for other threads. The patch below
> worked for me with SPEW's config:
>
> Index: kern_synch.c
> =
Hello!
I've had this odd behavior [1] on one of my machines with vt(4)
misbehaving in graphics mode following the beastie loader's screen.
Any ideas what might cause something like this, or if it's just
something unsupported? I have a PR open at [2] with pciconf -lv
output.
Thanks,
Kyle Evans
In message
, Kyle Evans writes:
>I've had this odd behavior [1] on one of my machines with vt(4)
>misbehaving in graphics mode following the beastie loader's screen.
>
>Any ideas what might cause something like this,
I've seen it too. I think beastie sets a scrolling region and
doesn'
13 matches
Mail list logo
