I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
to see what's required for IP-Filter (hoping for a clean interface)
and the response is "sigh". The old ipfw mechanism needs to be
abandoned, IMHO.
For those that aren't aware, pfil(9) in NetBSD used to provide two
lists fo
Hi ...
I want to read the status register of the lpt port in NIBBLE mode. I want to
do this wether there is a printer connected or not.
What would be the best way to accomplish this ??
Should I use the ppi0 device with the PPIGSTATUS ioctl call, because
if there is no printer connected I can'
> I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
> to see what's required for IP-Filter (hoping for a clean interface)
> and the response is "sigh". The old ipfw mechanism needs to be
> abandoned, IMHO.
can you comment a bit more ? I am a bit unclear on what
exactly is t
In some mail from Luigi Rizzo, sie said:
>
> > I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
> > to see what's required for IP-Filter (hoping for a clean interface)
> > and the response is "sigh". The old ipfw mechanism needs to be
> > abandoned, IMHO.
>
> can you comm
> > The issue of one vs. multiple lists (per direction, interface,
> > protocol, you name it) has been discussed some time ago. For sure
> > multiple lists are a (minor, given that we can start the ipfw lists
> > with a few of "skipto") performance improvement over a single one,
> > at the possib
In some mail from Luigi Rizzo, sie said:
>
> > > The issue of one vs. multiple lists (per direction, interface,
> > > protocol, you name it) has been discussed some time ago. For sure
> > > multiple lists are a (minor, given that we can start the ipfw lists
> > > with a few of "skipto") performa
> Changing routing information is not a problem. For starters,
> with inbound packets, there is none.
for outbound there is, and one of the biggest problems i had
with dummynet (as an example) was that some code passed
around route structures held in the stack, so you couldn't just keep
a refere
- Original Message -
From: "Wes Peters" <[EMAIL PROTECTED]>
To: "Jon Hamilton" <[EMAIL PROTECTED]>
Cc: "Lyndon Nerenberg" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, February 19, 2000 1:14 AM
Subject: Re: Crypto progress! (And a Bg TODO list)
> And how exactly are they s
- Original Message -
From: "Soren Schmidt" <[EMAIL PROTECTED]>
To: "Jose Gabriel Marcelino" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, February 19, 2000 10:33 AM
Subject: Re: Big ATA problems
> It seems Jose Gabriel Marcelino wrote:
>
> Well, rebuild the loader, that hel
Thus spake Jason Allum ([EMAIL PROTECTED]):
> > It seems Jose Gabriel Marcelino wrote:
> > Well, rebuild the loader, that helped Bryan, apparently it has
> > nothing to do with the ata driver
> i've had no troubles on my ata-based dell precision 410, running -current
> (circa -11pm last night
my bad!
those were meant for -current... sorry for the mis-post.
- jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Firstly, the cross-post to -hackers seems appropriate but
my apologies if it isn't.
I am now certain that there is a bug in ioctl() (at least for
setting the mixer).
This started out as an attempt to fix a bug in xmms, but making a
debug version of mixer(8) showed it to be affected the same way.
On Fri, 18 Feb 2000, Bruce Gingery wrote:
> So I'll leave it up to you. There should be info at least in
> a FAQ somewhere that indicates that bad RAM is not something
> that can be ruled out until tested adequately, and perhaps a
> checklist of symptoms that (virtually) ALWAYS
:Madhu Talluri's paper on page tables for 64 bit address spaces claims that
:having collision chains is expensive - for 8 bytes of mapping information,
:the pointer and tag storage overhead is 16 bytes.
:
:Though page table space is important, in the age of big memory computers,
:I think performa
:Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces
:and it turns out that hash tables perform quite poorly. I'd suggest GPTs
:instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW.
:Both have the advantage of supporting multiple page sizes that
In some mail from Luigi Rizzo, sie said:
>
> > Changing routing information is not a problem. For starters,
> > with inbound packets, there is none.
>
> for outbound there is, and one of the biggest problems i had
> with dummynet (as an example) was that some code passed
> around route structur
mixer uses 100 levels for each "device" (master volume, pcm, synth,
etc), but your hardware maybe uses 64 (or 128). mixer needs to be
universal.. so does the ioctl() and the interface to the hardware
mixer. Look at the sources in the kernel :)... maybe you'll find something
like this (which loos
> :Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces
> :and it turns out that hash tables perform quite poorly. I'd suggest GPTs
> :instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW.
> :Both have the advantage of supporting multiple page siz
hi *
this might be a little offtopic...
i just messaged the guys from yamaha japan for specs on their pci audio
chipsets to get some decent documentation to start torturing those ymf744
soundcards. no response. i mailed again. same result. do they actually
read their mail or is this an uncommon
On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote:
> One more thing about GPTs (I thought I'll leave that till last. ;)
> Jochen Liedtke holds a German patent on them, although he will
> probably be fairly easily convinced to give FreeBSD rights to use
> them. I'll be happy to ask
> On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote:
> > One more thing about GPTs (I thought I'll leave that till last. ;)
> > Jochen Liedtke holds a German patent on them, although he will
> > probably be fairly easily convinced to give FreeBSD rights to use
> > them. I'll be ha
John and Jennifer Reynolds wrote:
>
> Hi all,
>
> I was tinkering with mergemaster tonight adding in something that seems useful
> to me. I track -stable and have found mergemaster very valuable--however,
> sometimes choosing 'd' over and over again for things I don't want touched
> (like root's
Chuck Robey wrote:
>
> On Fri, 18 Feb 2000, Bruce Gingery wrote:
>
> > So I'll leave it up to you. There should be info at least in
> > a FAQ somewhere that indicates that bad RAM is not something
> > that can be ruled out until tested adequately, and perhaps a
> > checklist of
On Sun, Feb 20, 2000 at 01:48:49PM +1100, Patryk Zadarnowski wrote:
> > It looks like the hardware has to implement GPTs and know how to
> > walk them. How can FreeBSD use them without hardware support ?
>
> No it doesn't. We've got software GPT implementations for both MIPS64 and
> Alpha, and th
> On Sun, Feb 20, 2000 at 01:48:49PM +1100, Patryk Zadarnowski wrote:
> > > It looks like the hardware has to implement GPTs and know how to
> > > walk them. How can FreeBSD use them without hardware support ?
> >
> > No it doesn't. We've got software GPT implementations for both MIPS64 and
> > A
:And don't forget that with VHPT you'll be getting nested TLB faults quite
:frequently in a sparsely-populated page table (think shared libraries).
:
:Efficiency-wise, Kevin has shown that you only need a fairly small VPHT, and
:it is global, so you ammortise the cost across all running tasks. Fu
26 matches
Mail list logo
