Hi,
Here at genua, trying to build libpcap sometimes breaks in
libpcap with the following error message:
| Using $< in a non-suffix rule context is a GNUmake idiom \
|(/data/git/ehrhardt/genuos/os/mk/bsd.dep.mk:47)
The bug is in bsd.dep.mk where ${.IMPSRC} (aka $<) is used
in a
Hi,
before I post the next iteration of the patch, I'd like
some more advice on some of the points you commented (inline):
On Sun, Feb 14, 2016 at 03:34:19PM +1100, Jonathan Gray wrote:
> On Mon, Feb 08, 2016 at 01:53:20PM +0100, Christian Ehrhardt wrote:
> > retrieving revision 1.329
Hi,
On Mon, Feb 08, 2016 at 02:35:32PM +, Stuart Henderson wrote:
> On 2016/02/08 13:53, Christian Ehrhardt wrote:
> > If you own a skylake based onboard NIC, please give this diff a try.
>
> The most important bit, especially at this point in the release cycle,
> is wh
Hi everyone,
based on the latest release of the Intel driver for FreeBSD (em-7.5.2),
I've adapted the em(4) driver to support the skylake based i219
onboard ethernet chips.
I do not have access to relevant specs, everything below is
based on reading the Intel code referenced above.
The diff
Hi,
On Wed, Jul 24, 2013 at 11:52:38AM +0200, Mark Kettenis wrote:
Taking this to tech@ in the hope some more people will look into this.
Ok. And thanks for picking this up.
On Thu, Jul 04, 2013 at 09:56:56AM -0700, Scott Vanderbilt wrote:
I've been trying to build userland repeatedly
Hi,
On Fri, Sep 21, 2012 at 08:34:56PM +0200, Mark Kettenis wrote:
Any chance of having a diff with the amd64 bits as well?
Included below.
Also:
+ if (pba-pba_busex == NULL) {
+ printf(cannot attach ACPI discovered busses\n);
+ return;
+ }
Instead of
Hi,
thanks to Mark, we have enough PCI bus number accounting, now to allow us
to attach ACPI bus numbers via ACPI. A patch to do this is below.
regards Christian
Index: arch/i386/i386/mainbus.c
===
RCS file:
Hi,
On Thu, Sep 13, 2012 at 11:00:12PM +0200, Mark Kettenis wrote:
However, there might be a different solution:
We could track attached busses (not just host bridge busses but all busses)
in the pci code (or via MD code and hooks but I think that would be a
generic thing) and do nothing
Hi,
On Fri, Sep 14, 2012 at 10:31:05AM +0200, Christian Ehrhardt wrote:
On Thu, Sep 13, 2012 at 11:00:12PM +0200, Mark Kettenis wrote:
However, there might be a different solution:
We could track attached busses (not just host bridge busses but all
busses)
in the pci code (or via MD
Hi,
On Mon, Sep 10, 2012 at 01:22:35PM +0200, Christian Ehrhardt wrote:
Yup. Since we have code to detect additional host bridges some of
them may already have been attached. And it would be a good way to
defend against ACPI lying to us. However, please keep the ACPI hooks
out
Hi,
first of all: Thanks for your reply!
On Sat, Sep 08, 2012 at 04:04:41PM +0200, Mark Kettenis wrote:
most modern x86 hardware includes more than one PCI root segement.
E.g. a hardware that I have here has three PCI root segemnts with bus
numbers 0, 0x7f, 0x80 and 0xff respectively.
Hi again,
On Thu, Sep 06, 2012 at 11:24:01AM +0200, Christian Ehrhardt wrote:
most modern x86 hardware includes more than one PCI root segement.
E.g. a hardware that I have here has four PCI root segemnts with bus
numbers 0, 0x7f, 0x80 and 0xff respectively. (0x7f and 0xff host the
uncore
Hi,
most modern x86 hardware includes more than one PCI root segement.
E.g. a hardware that I have here has three PCI root segemnts with bus
numbers 0, 0x7f, 0x80 and 0xff respectively. (0x7f and 0xff host the
uncore devices of each processor).
These segments are already detected by APCI but
Hi!
the ix(4)-Driver stores a pointer to the pci_attach_args structure (as
passed to ixgbe_attach) in its softc. However, the pci_attach_args
structure lives on the stack somewhere in autoconf, i.e. its contents are
undefined after ixgbe_attach returns.
However, the pointer to that data remains
Hi,
while reading through uvm code I stubled accross a piece of code that
appears to be buggy. Here's the proposed patch, rational follows:
Index: uvm_vnode.c
===
RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.71
Hi,
On Mon, Apr 18, 2011 at 10:00:02PM -0700, Philip Guenther wrote:
The sti was introduced in revision 1.97 of locore.s in March 2006 by
mickey@. Commit message:
| prevent the faults on iret to run w/ disabled intrs and cause
| deadlocks; niklas toby tom ok
Maybe mickey or one of
Hi,
we are seeing kernel hangs (hard reset required) under high interrupt
load (triggered by ix(4) cards). I've traced this back to an overflow
of the kernel stack. This is how the stack looks at the time of the
overflow (manual backtrace, as ddb won't show the final part):
EBP
17 matches
Mail list logo
