On Oct 5, 2012, at 10:08 AM, John Baldwin wrote:
On Thursday, October 04, 2012 1:20:52 pm Carl Delsey wrote:
I noticed that the bus_space_*_8 functions are unimplemented for x86.
Looking at the code, it seems this is intentional.
Is this done because on 32-bit systems we don't know, in
I was trying to co-relate the o/p from top to that I get from vmstat -z. I
don't have any user programs that wires memory. Given that, I'm assuming the
wired memory count shown by top is memory used by kernel. Now I would like
find out how the kernel is using this wired memory. So, I look at
Not necessarily. If I understand correctly what Tim means, he's talking
about an in-memory compression of several blocks by several separate
threads, and then - after all the threads have compressed their
respective blocks - writing out the result to the output file in order.
Of course, this
[snip]
any fix?
You have found the fix. Remove the WITHOUT_ options from the build
that keep it from completing. You'll be able to add them at installworld
time w/o a hassle. nanobsd uses this to keep things down, while still
being able to build the system.
Warner
where can
On Oct 9, 2012, at 3:46 AM, Daniel Braniss da...@cs.huji.ac.il wrote:
[snip]
any fix?
You have found the fix. Remove the WITHOUT_ options from the build
that keep it from completing. You'll be able to add them at installworld
time w/o a hassle. nanobsd uses this to keep things down,
On Oct 4, 2012, at 12:36 AM, Rick Macklem rmack...@uoguelph.ca wrote:
Garrett Wollman wrote:
On Wed, 3 Oct 2012 09:21:06 -0400 (EDT), Rick Macklem
rmack...@uoguelph.ca said:
Simple: just use a sepatate mutex for each list that a cache entry
is on, rather than a global lock for everything.
On Oct 9, 2012, at 5:12 PM, Nikolay Denev nde...@gmail.com wrote:
On Oct 4, 2012, at 12:36 AM, Rick Macklem rmack...@uoguelph.ca wrote:
Garrett Wollman wrote:
On Wed, 3 Oct 2012 09:21:06 -0400 (EDT), Rick Macklem
rmack...@uoguelph.ca said:
Simple: just use a sepatate mutex for each
Hi list,
I'm looking at this possible divide-by zero in dhclient:
http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-07-amd64/report-nBhqE2.html.gz#EndPath
In this specific case, it's obvious from the intention of the code that
ip-client-interval is always 0, but it's not obvious to me in
On Tue, 2012-10-09 at 17:35 +0200, Erik Cederstrand wrote:
Hi list,
I'm looking at this possible divide-by zero in dhclient:
http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-07-amd64/report-nBhqE2.html.gz#EndPath
In this specific case, it's obvious from the intention of the code
On Oct 9, 2012, at 4:46 AM, Daniel Braniss wrote:
[snip]
any fix?
You have found the fix. Remove the WITHOUT_ options from the build
that keep it from completing. You'll be able to add them at installworld
time w/o a hassle. nanobsd uses this to keep things down, while still
On Monday, October 08, 2012 4:59:24 pm Warner Losh wrote:
On Oct 5, 2012, at 10:08 AM, John Baldwin wrote:
On Thursday, October 04, 2012 1:20:52 pm Carl Delsey wrote:
I noticed that the bus_space_*_8 functions are unimplemented for x86.
Looking at the code, it seems this is
Nikolay Denev wrote:
On Oct 4, 2012, at 12:36 AM, Rick Macklem rmack...@uoguelph.ca
wrote:
Garrett Wollman wrote:
On Wed, 3 Oct 2012 09:21:06 -0400 (EDT), Rick Macklem
rmack...@uoguelph.ca said:
Simple: just use a sepatate mutex for each list that a cache
entry
is on, rather than
On Oct 8, 2012, at 3:21 AM, Wojciech Puchar wrote:
Not necessarily. If I understand correctly what Tim means, he's talking
about an in-memory compression of several blocks by several separate
threads, and then - after all the threads have compressed their
but gzip format is single stream.
13 matches
Mail list logo
