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;
> > + }
>
>
> Date: Fri, 21 Sep 2012 13:48:48 +0200
> From: Christian Ehrhardt
>
> 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
Hi Christian,
Any chance of having a diff wi
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: /cvs/src/sys/arch
> Date: Fri, 14 Sep 2012 10:31:05 +0200
> From: Christian Ehrhardt
>
> 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
Christian Ehrhardt genua.de> writes:
> > However, host bridges that are handled e.g. in arch/i386/pci/pchb.c
> > can appear downstream of another bridge but use bus numbers that are
> > outside of the upstream bridge's bus number range.
What I understood from the discussion, there is a possibili
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 cod
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 n
> Date: Mon, 10 Sep 2012 13:22:35 +0200
> From: Christian Ehrhardt
>
> 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
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 o
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.
> Date: Thu, 6 Sep 2012 11:24:01 +0200
> From: Christian Ehrhardt
>
> 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
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 this
13 matches
Mail list logo
