Vaibhave Agarwal wrote:
On Sun, 6 Nov 2005, John Baldwin wrote:
We don't detect the local APIC via MSR's or the APIC bit in cpu_features, but
rely on a working MP Table or MADT table to setup both the local APIC(s) and
I/O APIC(s). Does your machine have a valid MP Table or an APIC table in
On Thu, 5 Jun 2003, Shaun Jurrens wrote:
> On Wed, Jun 04, 2003 at 06:32:46PM +0200, Palle Girgensohn wrote:
> #> Hi Shaun,
> #>
> #> Thanks for the input! Glad to hear I'm not the only one
> #>
> #> In my case, both the SCSI and NIC are integrated on the motherboard, so I
> #> cannot really move t
On Tue, 7 Jan 2003, Bosko Milekic wrote:
> On Tue, Jan 07, 2003 at 02:15:02PM -0800, Nate Lawson wrote:
> > The short of it is that if a tx packet is < 64 bytes (min ethernet frame
> > len), data can be leaked if the driver transmits 64 bytes. It seems our
> > use of mbu
The short of it is that if a tx packet is < 64 bytes (min ethernet frame
len), data can be leaked if the driver transmits 64 bytes. It seems our
use of mbufs would prevent leakage but I haven't examined any drivers to
verify this.
http://www.atstake.com/research/advisories/2003/atstake_etherleak_
On Mon, 6 Jan 2003, Kyunghwan Kim wrote:
> On Mon, Jan 06, 2003 at 10:58:25AM +0100, Harti Brandt wrote:
> > On Fri, 3 Jan 2003, Nate Lawson wrote:
> > NL>I was looking into some "could sleep messages" and found some bogus
> > NL>locking in the attach routine
I was looking into some "could sleep messages" and found some bogus
locking in the attach routine of many drivers. Several init a mtx in
their softc and then lock/unlock it in their attach routine. This, of
course, does nothing to provide exclusive access to a device. I assume
there is going to
On Wed, 16 Oct 2002, Poul-Henning Kamp wrote:
> almost 7 years ago, this commit introduced the _IP_VHL hack in our
> IP-stack:
>
> ] revision 1.7
> ] date: 1995/12/21 21:20:27; author: wollman; state: Exp; lines: +5 -1
> ] If _IP_VHL is defined, declare a single ip_vhl member in struct ip rath
On Tue, 8 Oct 2002, Terry Lambert wrote:
> I've often thought that an interning process for atoms was actually
> a good idea for the kernel.
>
> The place I first thought of using this approach is for FS ID's. As
> things currently sit, there are header files that need to be hacked
> to add new
On Mon, 7 Oct 2002, Julian Elischer wrote:
> On Mon, 7 Oct 2002, Terry Lambert wrote:
> > On Mon, 7 Oct 2002, Julian Elischer wrote:
> > > Your tags have a single 16 bit tag ID field.
> > > This is insufficient for my needs.
> > > I need to be able to store the API cookie which is a 32 bit
> > > u
On Sun, 6 Oct 2002, Sam Leffler wrote:
> http://www.freebsd.org/~sam/mtag.patch
>
> has changes to -current to replace the "aux mbuf" with a more general
> mechanism borrowed from openbsd. Rather than dangling mbuf's off a packet
> when auxiliary information needs to be associated with a packet
10 matches
Mail list logo
