The subject says it all :)
What is the best way to allocate kernel memory with non-cacheable bit set? Or,
better yet, is it possible to change caching bit on an already kmalloc'ed
memory block? Will something like this work?
pt_entry_t pte;
pte = (pt_entry_t)vtopte(vaddr);
*pte |= PG
In message <[EMAIL PROTECTED]> Nate Williams writes:
: [ Culled the list way down, and moved it to -hackers ]
:
: > We could also look into providing an "update" command or something
: > which would pull either sources or binaries over from a snapshot box
: > and make the process of getting up to
> I think that we can do a lot with cvsupd. I've used cvsupd to grab
> binaries on an experimental basis and it seems to work great. I've
Hmmm. Does cvsupd also move a target out of the way if it already
exists and it's in the process of replacing it? What if the target is
chflag'd but can be
> > I think that we can do a lot with cvsupd. I've used cvsupd to grab
> > binaries on an experimental basis and it seems to work great. I've
>
> Hmmm. Does cvsupd also move a target out of the way if it already
> exists and it's in the process of replacing it? What if the target is
> chflag'
In message <[EMAIL PROTECTED]> Jordan Hubbard writes:
: > I think that we can do a lot with cvsupd. I've used cvsupd to grab
: > binaries on an experimental basis and it seems to work great. I've
:
: Hmmm. Does cvsupd also move a target out of the way if it already
: exists and it's in the pro
Used ABBR on SCSI disks all the time, very nice.
Remember reading on hackers somewhere that newer drives like IBM supported
this feature. I'm getting a few bad blocks on a 75GB IBM drive (at least
according to the ata driver), and rather than replacing it and moves on,
the disk basically dies.
Jaye Mathisen wrote:
>
> Used ABBR on SCSI disks all the time, very nice.
>
> Remember reading on hackers somewhere that newer drives like IBM supported
> this feature. I'm getting a few bad blocks on a 75GB IBM drive (at least
> according to the ata driver), and rather than replacing it and mo
Hi, excluding the extra kernel calls of open()/close() on /dev/zero,
which one of the following would be more efficient:
1) Using mmap on /dev/zero
2) Using mmap with MAP_ANON flag
The purpose is, ofcourse, to share the memory (R&W) among all child
processes.
It seems that mmap on /dev/zero i
On Wed, 4 Oct 2000, FengYue wrote:
> It seems that mmap on /dev/zero is more portable.
no really, It won't work at all correctly on linux, and on Tru64 it does
the totally wrong thing, but the (fd = -1, MAP_ANONYMOUS) does the right
thing on tru64.
It's disappointing that this works so unporta
On Wed, 4 Oct 2000, Jaye Mathisen wrote:
> Remember reading on hackers somewhere that newer drives like IBM supported
> this feature. I'm getting a few bad blocks on a 75GB IBM drive (at least
> according to the ata driver), and rather than replacing it and moves on,
> the disk basically dies.
>
> > Or do I just write nul's to the block or 0's, and it's supposed to do it
> > automatically? or do I just punt.
>
> 'dd if=/dev/zero of=/dev/ad1 bs=4k' works great; takes about an hour to
> scrub the entire disk. Run until clean. Running it right now in fact.
Err, Umm, I wouldn't assume th
Neil Blakey-Milner wrote:
>
> Hi,
>
> With these patches, and the new tiny util 'sourceconf', we can make
> /etc/defaults/rc.conf and /etc/defaults/periodic.conf configuration
> files again, such that they can be parsed by things other than 'sh'.
I have been very sick the last few days,
12 matches
Mail list logo
