Wondering: would it make sense for savecore to run asynchronously,
rather than waiting for it to complete before continuing with the rest
of system startup?
does this work for you:
echo "savecore_flags='&'" >> /etc/rc.conf
?
traditionally savecore runs early before swapping start
what is the purpose of this change?
struct lwp is approx 700-1000 bytes on our platforms.
that's a significant chunk to remove from kernel stacks isn't it?
.mrg.
On Sat, Jan 30, 2010 at 08:45:48PM +0100, Frank Wille wrote:
> Therefore I would like to change ddb/db_write_cmd.c as in the following
> patch:
> [...]
>
> Any objections? Do we absolutely need to print the old value here?
I think it's somewhat desirable to. Wouldn't
another alternative would be to add a flag to write, eg "write/n".
.mrg.
i like the look of this.
have you tested it on anything besides sparc64 yet?
.mrg.
1. The firmware is large, with about 60k. Does anybody have experience
with using a compressed firmware image in the driver, which is uncompressed
on the fly, while uploading it to the chip? How would I do that?
(This would probably make sense for most firmware, so a common interfac
>* The design capacity should be the maximum of the last known full
> charge capacity, which is the maximum of the present capacity.
> This is useful for checking the overall "health" of deteriorating
> (lithium-ion) batteries.
I disagree. Both batteries f
i don't see how changing the size of paddr_t affects userland except
for kvm and kvm is already special case and can/should be able to
handle it. sparc deals with things like this already.
.mrg.
On Wed, Feb 24, 2010 at 12:18:13AM +0100, Jean-Yves Migeon wrote:
> On 02/23/10 20:15, Manuel Bouyer wrote:
> > On Tue, Feb 23, 2010 at 04:57:55PM +0100, Jean-Yves Migeon wrote:
> >> Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and
> >> non-PAE.
> >
> > Y
i don't think we're going to *give up* static kernel configs,
regardless of how far we come modularwise.
.mrg.
* An inline function accesses the space directly if
__SLIM_SPARC_BUS_SPACE is #defined, however, it looks to me like that
#define is never used.
not sure why it is in __ land, but this was originally useful for
the older platforms with a tuned kernel.
I've committed the Function Boundary Trace provider to NetBSD
this is really great! thank you for working on this.
.mrg.
yeah.
while i agree with joerg that these operations aren't well defined, we
can do something a bit more sane like this patch.
i think it's OK.
.mrg.
i don't understand why you think framebuffers are mapped uncacheable.
your proposal appears to provide no benefit for anything currently
supported, and i'm not sure why bus_space_physload() needs to be
in the bus_space domain, rather than plain UVM. your XIP use-case
may be valid -- i haven't co
"int prot" is the device's characteristic. Audio mic devices would use
VM_PROT_READ. Framebuffers would use VM_PROT_WRITE. We need to introduce
BUS_SPACE_PROT_* symbols too.
i don't see why you think that reads from fb devices never occur.
i'm also unsure how audio devices matter f
On Fri, Mar 26, 2010 at 6:49 AM, David Holland
wrote:
> On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote:
> > > > % grep ':.*,' sys/conf/files | wc -l
> > > > 86
> > >
> > > And? I don't understand your point. There are a lot more than 86
> > > en
To manage dependency nicely.
When a module A dpend on B, you write "define A: B", where B has to be
already "define"'ed in the current syntax. We're managing such
ordering "by hand" in sys/conf/files. By splitting files & use
"include", we don't need to manage such a mess b
(I'll learn TTE then reply again.)
for everyone:
TTE is sparc64 for PTE. "translation table entry". defined in
sparc64/include/pte.h :-)
I'm running NetBSD/i386 5.99.24 on an MSI board with an ATI Radeon
2400 XT plugged in. To have 2d acceleration and XVideo, I load
radeondrm.kmod at boottime. It usually works, but after restarting
X sufficiently often, it suddenly stops; that is, either display
is corrupted, or X
I would like to add the MI function prototypes underneath the
#include:
#include
/* MI function prototypes */
bus_space_tag_t bus_space_tag_create(bus_space_tag_t, /* TBD */);
void bus_space_tag_destroy(bus_space_tag_t);
i'm extremely wary of you adding "TBD" code to
On Sat, Apr 03, 2010 at 01:16:46PM +1100, matthew green wrote:
>
>I would like to add the MI function prototypes underneath the
>#include:
>
>#include
>
>/* MI function prototypes */
>bus_space_tag_t bus_space_ta
On Sat, Apr 03, 2010 at 01:16:46PM +1100, matthew green wrote:
>
>I would like to add the MI function prototypes underneath the
>#include:
>
>#include
>
>/* MI function prototypes */
On Thu, Apr 01, 2010 at 09:52:07AM +0200, Nicolas Joly wrote:
[...]
> The attached patch introduce a new function clock_getres1() function
> which has most of the corresponding syscall logic except for the
> copyout call.
>
> This has the benefit to have all emulations can us
would you try this variant? it handles the case where MEXTMALLOC()
would fail to allocate external storage, and seems to work on my
iwn(4). i'll commit this if you confirm it works.
thanks.
.mrg.
Index: if_iwn.c
===
RCS file: /
On Sat, 10 Apr 2010, matthew green wrote:
> would you try this variant? it handles the case where MEXTMALLOC()
> would fail to allocate external storage, and seems to work on my
> iwn(4). i'll commit this if you confirm it works.
> *** if_iwn.c 5
On Fri April 9 2010 20:49:48 matthew green wrote:
> would you try this variant? it handles the case where MEXTMALLOC()
> would fail to allocate external storage, and seems to work on my
> iwn(4). i'll commit this if you confirm it works.
I can confirm that t
On Sat, Apr 10, 2010 at 12:49:48PM +1000, matthew green wrote:
>
> would you try this variant? it handles the case where MEXTMALLOC()
> would fail to allocate external storage, and seems to work on my
> iwn(4). i'll commit this if you confirm it works.
In my tree, I've changed bus_space_tag_t from an integer type to a
pointer to a struct. Now, some debugging code in MI drivers will not
compile because it tries to printf bus_space_tag_t's using the format
"%x".
I don't see the use of printing a bus_space_tag_t, so I am changin
(2) what linux kernel version do we want to claim to be in uname?
it would be good for this to be at least as recent as the
kernel matching what we choose in (1). but it would good to avoid
going too wild with this, to keep the amount of new emul code
that's need
FWIW, i just noticed this in subr_extent.c. gross, but what you want :-)
.mrg.
#include
#define KMEM_IS_RUNNING (kmem_map != NULL)
what's PAT? could you add a comment to pat.c, explaining what this
code is for?
please make sure that pat_init() definition is in column 1 (aka KNF).
(not sure the point of pat.h, i'd just merge it it into cpu.h or
similar.)
.mrg.
> I'm working on porting the OpenAFS client over to NetBSD 5.0.2. In
> trying to compile the LKM for it, the files cpu.h and intr.h in
> /usr/include/x86/ are included. These headers include additional
> headers. The problem, however, is that a couple of the headers they
> try to include are not i
> - fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
>this will affect native processes as well as linux ones,
>but it seems appropriate.
if you're going to do this, you may as well just make RLIMIT_AS and
RLIMIT_DATA refer to the same thing (and make that RLIMIT_AS.)
when implem
> On Sat, Jun 05, 2010 at 01:02:12PM +1000, matthew green wrote:
> >
> > > - fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
> > >this will affect native processes as well as linux ones,
> > >but it seems appropriate.
> >
> >
> I would like to enable the built-in modules much earlier, at least early
> enough to have them available during auto-configuration. The attached
> patch accomplishes this. I have briefly tested the patch, and it seems
> not to have any unwanted side-effects, but I would appreciate feedback
> On Thu, Jun 17, 2010 at 12:07:43PM -0400, Matthew Mondor wrote:
> > On Thu, 17 Jun 2010 10:25:59 +
> > Andrew Doran wrote:
> >
> > > This is mainly down the fact that we need kernel_lock to bracket "legacy"
> > > sections of code that aren't preemption safe. I think MULTIPROCESSOR
> > > s
> Somebody should fix the driver so that zshard() does not call
> device_lookup_private(). It seems entirely unnecessary.
i don't see how without simply revert the change to convert to
using device_lookup_private().
the interrupt comes in and you have to look at all of the zs
devices on the sys
> > Somebody should fix the driver so that zshard() does not call
> > device_lookup_private(). It seems entirely unnecessary.
>
> There is a dumb hack in sun3 derived zs driver.
>
> All zs devices on sun machines have the same interrupt sources
> so ancient zs drivers tried to reduce overhead o
> It looks multiple interrupt handlers against the same interrupt level
> are properly queued and handled in sparc/intr.c:ih_insert(), so
> no need to prepare own queue in zs.c.
this patch must be tested on a system with both serial usage and
zskbd/zsms working, and if possible, on a system with
> > It looks multiple interrupt handlers against the same interrupt level
> > are properly queued and handled in sparc/intr.c:ih_insert(), so
> > no need to prepare own queue in zs.c.
>
> this patch must be tested on a system with both serial usage and
> zskbd/zsms working, and if possible, on a
> On Sun, 20 Jun 2010 12:38:18 +1000
> matthew green wrote:
>
> > it would still be nice to have a good multi-zs user test to make sure.
> Would a Ultra2 or a SPARCstation 10 / 20 fit that bill?
> I could throw a test kernel at that hardware easily.
looks like sparc64 a
> > >> the macppc and news68k zshard()'s get the actual zsc_softc * as
> > >> the (void *arg), but sparc does not.
> > >
> > >So we should make sparc zs do so.
> > >
> > >It looks multiple interrupt handlers against the same interrupt level
> > >are properly queued and handled in sparc/intr.c:ih_i
> At 1:03 Uhr +0900 26.6.2010, Izumi Tsutsui wrote:
> >> The patch fixes the panic on my ss20 - an UP kernel makes it to multi-user,
> >> and I can log in, and access the machine from the network. There's pppoe,
> >> netatalk and samba breakage, but that may be due to version skew with the
> >> ne
> On Thu, Jul 01, 2010 at 01:32:47AM +0200, Rhialto wrote:
> > On Wed 30 Jun 2010 at 08:57:44 -0700, Chuck Silvers wrote:
> > >- the assembler apparently now uses a different opcode for reloading
> > > %gs
> > > than it used to, so the check for this instruction in INTRFASTEXIT
> > >
RCU patent expires in 25 months, right? soon we don't have to care,
regardless of the jurisdiction.
it seems to me the root problem is that module_mutex is held while
calling into the module startup routines.
thus, the right solution is to remove this requirement.
.mrg.
> On Mon, 26 Jul 2010, matthew green wrote:
>
> >
> > it seems to me the root problem is that module_mutex is held while
> > calling into the module startup routines.
> >
> > thus, the right solution is to remove this requirement.
>
> Yes, that's w
> According to the mutex(9) man page:
>
> mutex_owned(mtx)
>
> For adaptive mutexes, return non-zero if the current LWP holds
> the mutex. ...
this is an incomplete reading of the manual page, and you can not
use mutex_owned() the way you are trying to (regardless of what
p
> On Mon Aug 02 2010 at 16:30:03 +1000, matthew green wrote:
> > this is an incomplete reading of the manual page, and you can not
> > use mutex_owned() the way you are trying to (regardless of what
> > pooka posted.) you can't even using it in various forms of assert
i think this looks good enough. wait for some others eyes, though.
please commit the module_autoload() changes separately.
.mrg.
> On Tue Aug 03 2010 at 02:17:43 +1000, matthew green wrote:
> > > Now, on to sensible stuff. I'm quite certain that warning was written
> > > to make people avoid writing bad code without understanding locking --
> > > if you need to used mutex_owned() to
> On Mon, Aug 09, 2010 at 02:38:32AM -0400, Matthew Mondor wrote:
> > On Sun, 8 Aug 2010 17:23:23 -0700 (PDT)
> > Paul Goyette wrote:
> >
> > > Should these be changed? Are there any adverse effects from having a
> > > wmesg longer than 8 characters?
> >
> > It seems to me that the exporter o
> On Wed, Aug 11, 2010 at 11:49:10PM +0200, Jean-Yves Migeon wrote:
> [..]
>
> > I will commit the attached patch on Saturday, unless someone objects.
> >
> [..]
>
> > Index: external/bsd/drm/dist/shared-core/radeon_cs.c
> > ===
>
> On Thu, 12 Aug 2010, Bernd Ernesti wrote:
> >>if (dev_priv == NULL) {
> >>DRM_ERROR("called with no initialization\n");
> >> - DRM_SPINUNLOCK(&dev_priv->cs.cs_mutex);
> ...
> > Hmm, you didn't mention why you are doing that in your initial mail.
>
> Use of pointer after
> hello,
>
> netbsd crashs at Dell M710. You can have a look at the screeshot at
> http://6bone.informatik.uni-leipzig.de/Dell-M710.bmp
>
> Any Ideas what could be the problem?
can you type "bt" at the db prompt and show us the backtrace?
.mrg.
thanks for looking into this problem. we need a solution.
would device_lookup() and device_lookup_private() take a reference
on this count automatically? or maybe some new API that does it,
to avoid the need to audit every driver at once.
> On Jan 6, 1:19am, matthew green wrote:
> }
> } would device_lookup() and device_lookup_private() take a reference
> } on this count automatically? or maybe some new API that does it,
> } to avoid the need to audit every driver at once.
>
> What would release the r
> I have 5.1_RC3/i386 running quite happily on a couple of slightly
> older Dell PowerEdge r610's. I went to install it on a new R610 and
> the system dies immediately
>
>[...]
> Intel 686-class, 2660Hz 0x20bc2
> Fatal protection fault in supervisor mode
> Stopped in pid 0.1(system) at net
> ...and I'm not convinced of this, primarily because (from a practical
> point of view) X is unavoidable and unfixable, whereas modules are
> neither.
actually, with DRM (and KMS) i believe we will be able to run the
X server as non-root.
.mrg.
hi folks.
i recently tried running raidframe on a pair of 3TB disks. when
attached via USB, the reported 4K sectors and were signifcantly
more work required to get going, but when attached directly to
the sata ports, they come up support 512 sector accesses.
with a lot of help from mlelstv@ i'
> >+if (c_label->version == RF_COMPONENT_LABEL_VERSION)
> >+c_label->partitionSizeHi =
> >+raidPtr->Disks[fcol].partitionSize >> 32;
>
> All these tests should really be:
>
> + if (c_label->version > RF_COMPONENT_LABEL_VERSION_1)
> + c_label->parti
> On Oct 22, 7:26am, m...@eterna.com.au (matthew green) wrote:
> -- Subject: re: [patch] - add support for >2TB raid devices
>
> |
> | > >+if (c_label->version == RF_COMPONENT_LABEL_VERSION)
> | > >+c_label->partitionSizeHi =
>
after talking some more with greg oster, i've gone with a suggestion
from him to not bump the version, since the new field will be zero
in all existing labels already, so it can be safely always included
for now. the only problem we envision is an old kernel seeing a new
large set and cutting it
> - AMAP_SHARED itself is a fine concept; it's used by shared memory.
>
> sys/kern/sysv_shm.c:
> 452 error = uvm_map(&vm->vm_map, &attach_va, size, uobj, 0,
> 0,
> 453 UVM_MAPFLAG(prot, prot, UVM_INH_SHARE,
> UVM_ADV_RANDOM, flags));
>
> (Note UV
> > > - For highly tuned, XIP'ed systems, programs should be designed to
> > > avoid .data, because they're COW'ed to page cache sooner or later.
> >
> > why is this a problem?
> >
> > if the data is needed, and it will be written to, then these pages
> > will be allocated (COW'd) eventually,
> > > > > - For highly tuned, XIP'ed systems, programs should be designed to
> > > > > avoid .data, because they're COW'ed to page cache sooner or later.
> > > >
> > > > why is this a problem?
> > > >
> > > > if the data is needed, and it will be written to, then these pages
> > > > will be al
hi folks.
the following patch let's me access both 512 byte and 4K
sector disks at the same time, as long as they are in
separate raids. the existing rf code assumes/enforces
this part, i just made it support other sets concurrently.
the main change is moving the parity bitmap to the sector
af
> I'll merge this in a few days. I believe I've given enough reasonings
> to back this design in various places.
do not do this.
this code has currently seen review that was less than favourable
and you have not given much consideration to the flaws. unless
this actual patch is given review an
FWIW, there *are* sparc implementations of the mutex vector
functions, but we had to disable them because of lossage we
we not able to (yet) track down. they mostly work, so may
be useful for at least reading.
.mrg.
> The (my) problem is that rwlocks must use CAS as well, and I'm starting
> to think that I have to use CAS for the mutex code as well, as I can't
> seem to get mutexs work reliably without using the default
> implementation. The mutexes are used and abused in ways that seems to
> make a lot o
> - hppa seems to have a mutex implemented without cas. is it broken?
FWIW, the sparc implementation is only broken on SMP.
.mrg.
> Done. Now I just need to fix hppa so that it will be happy again (as far
> as I can tell, that's the only archtecture that defines it's own mutex
> operations, apart from VAX).
i should see about re-enabling the sparc code at least for UP.
please have a look there, too...
.mrg.
hi.
my devbox just crashed with this:
panic: kernel diagnostic assertion "pg == NULL || pg == PGO_DONTCARE" failed:
file "/usr/src/sys/miscfs/genfs/genfs_io.c", line 243
but i don't understand the KASSERT(). it seems that this sequence
of events will always trigger:
nfound =
> On Sun 19 Dec 2010 at 19:32:49 +, David Laight wrote:
> > I suspect the only form that will work is soemthing like:
> >
> > int ioctl(int, unsigned long, void *);
> > #define ioctl(fd, cmd, arg) ioctl(fd, cmd, (void *)(intptr_t)(arg))
>
> Easier: the aforementioned constant FLUSHR (and all
> On Sun, Jan 02, 2011 at 09:19:51PM +, Eduardo Horvath wrote:
> > TRYEMULROOT should only open existing objects on the emul path, it should
> > never create anything new, so you would never want to use it for mkdir.
> > I don't know if that means you need to pass an extra flag to
> >
i am not aware of anyone working on nouveau in netbsd. i would
copy the latest files from freebsd and see what happens, but when
i had a look at making it build from the sources in -current
several months ago it was more than i felt upto at the time.
i have enough trouble keeping radeondrm upd
> It would be nice if ELF kernel image holds "modules_enabled" value in
> note section which allows LIBSA to tell whether the target kernel is
> MODULAR or not.
modular kernels don't *have* to have modules loaded via the boot
loader. so what i think you're really after is a flag that says
"we wa
> Hello NetBSD folks,
> I just ran into this issue today (variable length unsigned long
> used in chflags syscalls) on FreeBSD and I wasn't sure if anyone was
> aware of the issue yet on NetBSD [1] . Just wanted to let you guys
> know so that maybe the 3 major BSDs could get on the same page a
i like this look of this much better than prior patches. thanks
for doing this properly.
i just have one minor suggestion. i don't see the point in the two
new files with one function proto and a 5 line function. can you
please move them into wsdisplay.c and wsdisplayvar.h? thanks.
.mrg.
> On Tue, Jan 18, 2011 at 11:22:33AM +0100, Christoph Egger wrote:
> >
> > > i like this look of this much better than prior patches. thanks
> > > for doing this properly.
> > >
> > > i just have one minor suggestion. i don't see the point in the
> > > two new files with one function proto and
> > The scheme sys/dev//wsdisplay_.[ch] where
> > is pci, sbus, etc. is fine with me.
>
> When trying to do that I uncovered a problem with doing it:
>
> In sys/dev/pci/files.pci I can't do 'wsdisplay & pci'
> because 'wsdisplay' is defined in sys/dev/wscons/files.wscons.
>
> So I will leave
> > Benefits I've thought about:
> > - The kmem pools use pool_caches therefor scalability will be much
> > better as the old malloc has a single lock for all access, the pools
> > have one each with a per cpu cache layer.
> > - The old malloc only returns oversized allocations back to the kmem
>
> >> I see there is a compile time constant CACHE_LINE_SIZE in
> >> which currently seems to be always be set to 64, but
> >> I'm pretty certain that is not necessarily a correct value.
> >
> > You are correct; to cite the one example I currently have swapped into
> > my brain, the Super-H used
> It looks like there is two place where partitionSizeHi is ignored in
> rf_netbsdkintf.c. I guess we should define access macros for it (and
> also for numBlocks) to prevent further mistakes.
i like this idea.
> The patch below is against netbsd-5 branch.
looks good to me. thanks for looking
> - Userland fix is added.
> - rf_reasonable_label() is also changed to use accessor. Initially I
> thought it is a special case since the comment in
> rf_fix_old_label_size implies that the numBlocksHi may be garbarge
> when the function is called, but even if it is garbage the result of
>
> On Sat Feb 19 2011 at 23:21:35 +0100, Manuel Bouyer wrote:
> > This branch is for the developement of a modernized disk quota system.
> > The 2 main changes are: a new quotactl(2) interface and a new on-disk
> > format, compatible with journaled ffs.
>
> Hmm, I'm wondering if the new quotactl s
> > > > It doesn't make much sense to play __RENAME() games with it since
> > > > any old code will not compile against the new quotactl signature.
> > >
> > > that seems reasonable to me.
> >
> > What do you propose then ? quotactl is the best name I can find for this
> > syscall ...
>
> quota
> > > > that seems reasonable to me.
> > >
> > > What do you propose then ? quotactl is the best name I can find for this
> > > syscall ...
> >
> > quotactl2? quotapctl? quota_pctl? quotactl_the_next_generation?
> > ... quota_king?
>
> All are
> >
> > Considering that quotactl is not used
> > > Agreed. So let's keep quotactl(2) ... it's fine and is working.
> >
> > i'd rather use quotactl2() than the old name.
> >
> > other ideas:
> >
> > quotapropctl()
> > quotaprop()
> >
> > and i'd be ok with quotapctl() as well.
>
> I still don't understand what problem we're t
this patch causes the raid on my ultra60 to no longer autoconfigure
attach. it took me a while to figure it out, because i also broke
accesses to sd0 in the same update, but after some testing i've
determined that without this change in -current, my u60 sees the
RAID1 at boot time fine and boots
this patch seems to fix my problem. i've moved the call to fix
the label into rf_reasonable_label() itself, right before the
valid return, and made the fix up also fix the partitionSizeHi.
greg, what do you think?
.mrg.
Index: rf_netbsdkintf.c
> > this patch seems to fix my problem. i've moved the call to fix
> > the label into rf_reasonable_label() itself, right before the
> > valid return, and made the fix up also fix the partitionSizeHi.
> >
> > greg, what do you think?
>
> Looks good to me. Go for it.
oh, it isn't. supposed to
this seems reasonable to me. why don't you stick it in libutil?
> As this is needed to get netatalk to build again on HEAD, I'd like
> to commit this in the next few days.
this is what i'm talking about about using a different name for
the new syscall that takes totally different arguments.
is
> On Sat, Mar 19, 2011 at 09:40:18AM +1100, matthew green wrote:
> >
> > this seems reasonable to me. why don't you stick it in libutil?
> >
> > > As this is needed to get netatalk to build again on HEAD, I'd like
> > > to commit this in the
> On Fri, 25 Mar 2011, Andrew Doran wrote:
>
> > On Fri, Mar 25, 2011 at 12:16:32AM -0700, Erik Fair wrote:
> >
> > > It will be interesting to see if this class of problem shows up again when
> > > NetBSD is supported on the UltraSPARC "Niagra" CPUs.
> >
> > Agree. Although as it stands 24 co
> Thinking about some first steps. We have a bunch of global counters and
> statistics stored in struct uvmexp. For example: pga_zerohit, cpuhit,
> colorhit etc.
[ .. ]
> Then there are filepages, execpages, anonpages, zeropages, etc. The same
> could naively be done for these as a short term s
> On Fri, Apr 01, 2011 at 08:35:52AM +0200, Lars Heidieker wrote:
> > this is a part of the changes to the kernel memory management.
> > It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> > essentially removing the MALLOC_TYPE from it.
>
> Are there tools for figuring out where
> Ignoring the free page allocator which abuses pg->offset, is there any
> reason we cannot fold pg->flags into pg->offset? The lower PAGE_SHIFT bits
> of pg->offset are not used.
is this about making vm_page smaller? if so, and it works, i guess that
seems fine, but how many bits do you want t
> On Sun, Apr 03, 2011 at 07:35:04PM +1000, matthew green wrote:
> >
> > > Ignoring the free page allocator which abuses pg->offset, is there any
> > > reason we cannot fold pg->flags into pg->offset? The lower PAGE_SHIFT
> > > bits
> > &
> On Thu, Mar 31, 2011 at 03:53:22PM -0400, Thor Lancelot Simon wrote:
> >
> > 2) About 200 xfers/sec (about 3MB/sec worth) is still going on
> >to the SSD for much of the build process. It's all writes.
> >All build directories (obj, dest, tools, release) are on
> >a
1 - 100 of 510 matches
Mail list logo
