On Thu, 24 May 2007, Jeff Garzik wrote:
>
> The latest Intel chipset I have (ICH9) is legacy free: no serial port and no
> PS/2 ports. I had to disable the Linux PS2 input drivers completely, just to
> get the thing to boot.
Ahh, that would be a bug. Can you help trying to debug where it
Linus Torvalds wrote:
Things like: A20 gate, 15-16MB holes, i387 FP exception on irq 13 are
totally pointless in this day and age. Things like the DMA controller are
getting there, along with PS/2 keyboard support.
The latest Intel chipset I have (ICH9) is legacy free: no serial port
and
Linus Torvalds wrote:
Things like: A20 gate, 15-16MB holes, i387 FP exception on irq 13 are
totally pointless in this day and age. Things like the DMA controller are
getting there, along with PS/2 keyboard support.
The latest Intel chipset I have (ICH9) is legacy free: no serial port
and
On Thu, 24 May 2007, Jeff Garzik wrote:
The latest Intel chipset I have (ICH9) is legacy free: no serial port and no
PS/2 ports. I had to disable the Linux PS2 input drivers completely, just to
get the thing to boot.
Ahh, that would be a bug. Can you help trying to debug where it locks
Jesse Barnes wrote:
On Wednesday, May 23, 2007 8:20:14 Linus Torvalds wrote:
On Wed, 23 May 2007, Linus Torvalds wrote:
Sure. I think mmconfig is perfectly sane if it falls back to conf1
accesses for legacy stuff..
.. but without a regression, it's obviously a post-2.6.22 thing, I guess I
On Wednesday, May 23, 2007 8:20:14 Linus Torvalds wrote:
> On Wed, 23 May 2007, Linus Torvalds wrote:
> > Sure. I think mmconfig is perfectly sane if it falls back to conf1
> > accesses for legacy stuff..
>
> .. but without a regression, it's obviously a post-2.6.22 thing, I guess I
> should make
On Wed, 23 May 2007, Linus Torvalds wrote:
>
> Sure. I think mmconfig is perfectly sane if it falls back to conf1
> accesses for legacy stuff..
.. but without a regression, it's obviously a post-2.6.22 thing, I guess I
should make that clear, just because I think people send me patches after
On Wed, 23 May 2007, Jesse Barnes wrote:
>
> So what do you think? You ok with enabling mmconfig if it's available as
> long
> as we use type 1 accesses for non-extended stuff? If so, I think the patches
> are pretty much ready...
Sure. I think mmconfig is perfectly sane if it falls back
On Wednesday, May 23, 2007 5:21:13 Linus Torvalds wrote:
> On Wed, 23 May 2007, Jesse Barnes wrote:
> > After I sent my last message I realized the same thing... though I
> > occasionally hear people talk about removing it (I seriously doubt that
> > will ever happen). I don't even think there's
On Wed, 23 May 2007, Jesse Barnes wrote:
>
> After I sent my last message I realized the same thing... though I
> occasionally hear people talk about removing it (I seriously doubt that
> will ever happen). I don't even think there's a way to disable type 1
> config access on Intel
On Sunday, April 29, 2007 7:14 pm Robert Hancock wrote:
> This path adds validation of the MMCONFIG table against the ACPI
> reserved motherboard resources. If the MMCONFIG table is found to be
> reserved in ACPI, we don't bother checking the E820 table. The PCI
> Express firmware spec apparently
On Wednesday, May 23, 2007 4:15 pm Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Wednesday, May 23, 2007 4:04 pm David Miller wrote:
> >> From: Linus Torvalds <[EMAIL PROTECTED]>
> >> Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
> >>
> >>> That crap should be seen for the crap it is! Dammit,
On Wed, 23 May 2007 17:09:37 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Jesse Barnes wrote:
> > Apparently Vista will move away from using type 1 config space accesses
> > though, so if we keep using it, we'll probably run into some lame board
>
> Yep.
>
>
> > that assumes you're using
Jesse Barnes wrote:
On Wednesday, May 23, 2007 4:04 pm David Miller wrote:
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
That crap should be seen for the crap it is! Dammit, how hard can
it be to just admit that mmconfig isn't that great?
I knew
On Wednesday, May 23, 2007 4:04 pm David Miller wrote:
> From: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
>
> > That crap should be seen for the crap it is! Dammit, how hard can
> > it be to just admit that mmconfig isn't that great?
>
> I knew mmconfig was
On Wednesday, May 23, 2007 4:04 pm Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
> >> There was a big discussion about this back in 2002, in which Linus
> >> wasn't overly enthused about disabling the decode during probing
> >> due to risk
Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value anyway
before moving on to the 32 bit probe which is where I think the problem
is.
Well, the
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
> That crap should be seen for the crap it is! Dammit, how hard can it
> be to just admit that mmconfig isn't that great?
I knew mmconfig was broken conceptually the first time I started
seeing write posting
Jesse Barnes wrote:
On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
There was a big discussion about this back in 2002, in which Linus
wasn't overly enthused about disabling the decode during probing due
to risk of causing problems with some devices:
http://lkml.org/lkml/2002/12/19/145
On Wednesday, May 23, 2007 3:48 pm Linus Torvalds wrote:
> On Thu, 24 May 2007, Olivier Galibert wrote:
> > Isn't that a mac-intel instant killer? AFAIK they don't have
> > type1, period.
>
> mac-intel are totally standard Intel chipsets. They have all of
> conf1/conf2/mmconfig afaik.
>
> I just
On Thu, 24 May 2007, Olivier Galibert wrote:
>
> Isn't that a mac-intel instant killer? AFAIK they don't have type1,
> period.
mac-intel are totally standard Intel chipsets. They have all of
conf1/conf2/mmconfig afaik.
I just happily booted my mac-mini with "pci=nommconf", nothing bad
On Wednesday, May 23, 2007 3:24 pm Olivier Galibert wrote:
> On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote:
> > On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
> > > Ehh. Even for PCIe, why not use the normal accesses for the first
> > > 256 bytes? Problem solved.
> >
> >
On Wednesday, May 23, 2007 3:16 pm Linus Torvalds wrote:
> On Wed, 23 May 2007, Jesse Barnes wrote:
> > > How are those boards going to set up mmconfig? The whole standard
> > > is broken, since there is no way to set it up.
> > >
> > > Trust the firmware? What a piece of crap!
> >
> > What do you
On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote:
> On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
> > Ehh. Even for PCIe, why not use the normal accesses for the first 256
> > bytes? Problem solved.
>
> Ok, this patch also works. We still need to enable mmconfig space for
On Wed, 23 May 2007, Jesse Barnes wrote:
> >
> > How are those boards going to set up mmconfig? The whole standard is
> > broken, since there is no way to set it up.
> >
> > Trust the firmware? What a piece of crap!
>
> What do you mean? You set it up the normal way, by poking at config
>
On Wednesday, May 23, 2007 2:54 pm Linus Torvalds wrote:
> On Wed, 23 May 2007, Jesse Barnes wrote:
> > > You told it to not forward memory. Why complain when it does as
> > > told?
> >
> > Well, because that's not actually very useful functionality, and
> > likely makes software that seems
On Wed, 23 May 2007, Jesse Barnes wrote:
> > You told it to not forward memory. Why complain when it does as told?
>
> Well, because that's not actually very useful functionality, and likely
> makes software that seems "obviously" correct wrt the PCI spec break.
I agree that a chip that
Jesse Barnes wrote:
On Wednesday, May 23, 2007 2:35 pm Alan Cox wrote:
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space
in PCI-Express, rather than being locked into the 256-byte legacy
PCI config space.
Mostly for
On Wednesday, May 23, 2007 2:35 pm Alan Cox wrote:
> > One of the reasons why hardware vendors want to move away from
> > traditional accesses is to be able to use the larger config space
> > in PCI-Express, rather than being locked into the 256-byte legacy
> > PCI config space.
>
> Mostly for
Alan Cox wrote:
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space in
PCI-Express, rather than being locked into the 256-byte legacy PCI
config space.
Mostly for treacherous computing extensions where subsets of
> One of the reasons why hardware vendors want to move away from
> traditional accesses is to be able to use the larger config space in
> PCI-Express, rather than being locked into the 256-byte legacy PCI
> config space.
Mostly for treacherous computing extensions where subsets of the config
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
> > Not for systems with PCIe... and the platforms I've been having
> > trouble with have PCIe slots, so I'd really like mmconfig to be
> > used at least on machines with PCIe bridges. For other machines,
> > it probably doesn't matter
Jesse Barnes wrote:
Apparently Vista will move away from using type 1 config space accesses
though, so if we keep using it, we'll probably run into some lame board
Yep.
that assumes you're using mmconfig at some point in the near future.
But then again, we're often on that less tested
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
> On Wed, 23 May 2007, Jesse Barnes wrote:
> > On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
> > > On Wed, 23 May 2007, Jesse Barnes wrote:
> > > > Fixed it (finally). I don't think moving the 64 bit probing
> > > > around would
On Wed, 23 May 2007, Jesse Barnes wrote:
> On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
> > On Wed, 23 May 2007, Jesse Barnes wrote:
> > > Fixed it (finally). I don't think moving the 64 bit probing around
> > > would make a difference, since we'd restore its original value
> > >
On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
> On Wed, 23 May 2007, Jesse Barnes wrote:
> > Fixed it (finally). I don't think moving the 64 bit probing around
> > would make a difference, since we'd restore its original value
> > anyway before moving on to the 32 bit probe which is
On Wed, 23 May 2007, Alan Cox wrote:
>
> > Well, the thing is, I'm pretty sure there is at least one northbridge that
> > stops memory accesses from the CPU when you turn off the MEM bit on it.
> > Oops, you just killed the machine.
>
> CS5520. But it doesn't have 64bit or PCI Express.
That
> Well, the thing is, I'm pretty sure there is at least one northbridge that
> stops memory accesses from the CPU when you turn off the MEM bit on it.
> Oops, you just killed the machine.
CS5520. But it doesn't have 64bit or PCI Express.
Alan
-
To unsubscribe from this list: send the line
On Wed, 23 May 2007, Jesse Barnes wrote:
>
> Fixed it (finally). I don't think moving the 64 bit probing around
> would make a difference, since we'd restore its original value anyway
> before moving on to the 32 bit probe which is where I think the problem
> is.
Well, the thing is, I'm
On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
> There was a big discussion about this back in 2002, in which Linus
> wasn't overly enthused about disabling the decode during probing due
> to risk of causing problems with some devices:
>
> http://lkml.org/lkml/2002/12/19/145
>
> In this
On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
There was a big discussion about this back in 2002, in which Linus
wasn't overly enthused about disabling the decode during probing due
to risk of causing problems with some devices:
http://lkml.org/lkml/2002/12/19/145
In this
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value anyway
before moving on to the 32 bit probe which is where I think the problem
is.
Well, the thing is, I'm pretty
Well, the thing is, I'm pretty sure there is at least one northbridge that
stops memory accesses from the CPU when you turn off the MEM bit on it.
Oops, you just killed the machine.
CS5520. But it doesn't have 64bit or PCI Express.
Alan
-
To unsubscribe from this list: send the line
On Wed, 23 May 2007, Alan Cox wrote:
Well, the thing is, I'm pretty sure there is at least one northbridge that
stops memory accesses from the CPU when you turn off the MEM bit on it.
Oops, you just killed the machine.
CS5520. But it doesn't have 64bit or PCI Express.
That patch
On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value
anyway before moving on to the 32 bit probe which is where I
On Wed, 23 May 2007, Jesse Barnes wrote:
On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value
anyway before
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing
around would make a
Jesse Barnes wrote:
Apparently Vista will move away from using type 1 config space accesses
though, so if we keep using it, we'll probably run into some lame board
Yep.
that assumes you're using mmconfig at some point in the near future.
But then again, we're often on that less tested
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
Not for systems with PCIe... and the platforms I've been having
trouble with have PCIe slots, so I'd really like mmconfig to be
used at least on machines with PCIe bridges. For other machines,
it probably doesn't matter much. I
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space in
PCI-Express, rather than being locked into the 256-byte legacy PCI
config space.
Mostly for treacherous computing extensions where subsets of the config
space
Alan Cox wrote:
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space in
PCI-Express, rather than being locked into the 256-byte legacy PCI
config space.
Mostly for treacherous computing extensions where subsets of
On Wednesday, May 23, 2007 2:35 pm Alan Cox wrote:
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space
in PCI-Express, rather than being locked into the 256-byte legacy
PCI config space.
Mostly for treacherous
Jesse Barnes wrote:
On Wednesday, May 23, 2007 2:35 pm Alan Cox wrote:
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space
in PCI-Express, rather than being locked into the 256-byte legacy
PCI config space.
Mostly for
On Wed, 23 May 2007, Jesse Barnes wrote:
You told it to not forward memory. Why complain when it does as told?
Well, because that's not actually very useful functionality, and likely
makes software that seems obviously correct wrt the PCI spec break.
I agree that a chip that doesn't do
On Wednesday, May 23, 2007 2:54 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
You told it to not forward memory. Why complain when it does as
told?
Well, because that's not actually very useful functionality, and
likely makes software that seems obviously correct
On Wed, 23 May 2007, Jesse Barnes wrote:
How are those boards going to set up mmconfig? The whole standard is
broken, since there is no way to set it up.
Trust the firmware? What a piece of crap!
What do you mean? You set it up the normal way, by poking at config
space to see
On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote:
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
Ehh. Even for PCIe, why not use the normal accesses for the first 256
bytes? Problem solved.
Ok, this patch also works. We still need to enable mmconfig space for
PCIe
On Wednesday, May 23, 2007 3:16 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
How are those boards going to set up mmconfig? The whole standard
is broken, since there is no way to set it up.
Trust the firmware? What a piece of crap!
What do you mean? You set
On Wednesday, May 23, 2007 3:24 pm Olivier Galibert wrote:
On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote:
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
Ehh. Even for PCIe, why not use the normal accesses for the first
256 bytes? Problem solved.
Ok, this patch
On Thu, 24 May 2007, Olivier Galibert wrote:
Isn't that a mac-intel instant killer? AFAIK they don't have type1,
period.
mac-intel are totally standard Intel chipsets. They have all of
conf1/conf2/mmconfig afaik.
I just happily booted my mac-mini with pci=nommconf, nothing bad
happened,
On Wednesday, May 23, 2007 3:48 pm Linus Torvalds wrote:
On Thu, 24 May 2007, Olivier Galibert wrote:
Isn't that a mac-intel instant killer? AFAIK they don't have
type1, period.
mac-intel are totally standard Intel chipsets. They have all of
conf1/conf2/mmconfig afaik.
I just happily
From: Linus Torvalds [EMAIL PROTECTED]
Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
That crap should be seen for the crap it is! Dammit, how hard can it
be to just admit that mmconfig isn't that great?
I knew mmconfig was broken conceptually the first time I started
seeing write posting bug
Jesse Barnes wrote:
On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
There was a big discussion about this back in 2002, in which Linus
wasn't overly enthused about disabling the decode during probing due
to risk of causing problems with some devices:
http://lkml.org/lkml/2002/12/19/145
Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value anyway
before moving on to the 32 bit probe which is where I think the problem
is.
Well, the
On Wednesday, May 23, 2007 4:04 pm Robert Hancock wrote:
Jesse Barnes wrote:
On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
There was a big discussion about this back in 2002, in which Linus
wasn't overly enthused about disabling the decode during probing
due to risk of causing
On Wednesday, May 23, 2007 4:04 pm David Miller wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
That crap should be seen for the crap it is! Dammit, how hard can
it be to just admit that mmconfig isn't that great?
I knew mmconfig was broken
On Wed, 23 May 2007 17:09:37 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Jesse Barnes wrote:
Apparently Vista will move away from using type 1 config space accesses
though, so if we keep using it, we'll probably run into some lame board
Yep.
that assumes you're using mmconfig at
Jesse Barnes wrote:
On Wednesday, May 23, 2007 4:04 pm David Miller wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
That crap should be seen for the crap it is! Dammit, how hard can
it be to just admit that mmconfig isn't that great?
I knew mmconfig
On Wednesday, May 23, 2007 4:15 pm Robert Hancock wrote:
Jesse Barnes wrote:
On Wednesday, May 23, 2007 4:04 pm David Miller wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
That crap should be seen for the crap it is! Dammit, how hard can
it
On Sunday, April 29, 2007 7:14 pm Robert Hancock wrote:
This path adds validation of the MMCONFIG table against the ACPI
reserved motherboard resources. If the MMCONFIG table is found to be
reserved in ACPI, we don't bother checking the E820 table. The PCI
Express firmware spec apparently
On Wed, 23 May 2007, Jesse Barnes wrote:
After I sent my last message I realized the same thing... though I
occasionally hear people talk about removing it (I seriously doubt that
will ever happen). I don't even think there's a way to disable type 1
config access on Intel chipsets...
On Wednesday, May 23, 2007 5:21:13 Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
After I sent my last message I realized the same thing... though I
occasionally hear people talk about removing it (I seriously doubt that
will ever happen). I don't even think there's a way
On Wed, 23 May 2007, Jesse Barnes wrote:
So what do you think? You ok with enabling mmconfig if it's available as
long
as we use type 1 accesses for non-extended stuff? If so, I think the patches
are pretty much ready...
Sure. I think mmconfig is perfectly sane if it falls back to
On Wed, 23 May 2007, Linus Torvalds wrote:
Sure. I think mmconfig is perfectly sane if it falls back to conf1
accesses for legacy stuff..
.. but without a regression, it's obviously a post-2.6.22 thing, I guess I
should make that clear, just because I think people send me patches after
On Wednesday, May 23, 2007 8:20:14 Linus Torvalds wrote:
On Wed, 23 May 2007, Linus Torvalds wrote:
Sure. I think mmconfig is perfectly sane if it falls back to conf1
accesses for legacy stuff..
.. but without a regression, it's obviously a post-2.6.22 thing, I guess I
should make that
Jesse Barnes wrote:
On Wednesday, May 23, 2007 8:20:14 Linus Torvalds wrote:
On Wed, 23 May 2007, Linus Torvalds wrote:
Sure. I think mmconfig is perfectly sane if it falls back to conf1
accesses for legacy stuff..
.. but without a regression, it's obviously a post-2.6.22 thing, I guess I
Jesse Barnes wrote:
On Tuesday, May 22, 2007, Robert Hancock wrote:
Eww. I don't see where we disable the decode at all while we probe the
BARs on the device. That seems like a bad thing, especially with the way
we probe 64-bit BARs (do the low 32 bits first and then the high 32
bits). This
On Tuesday, May 22, 2007, Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Tuesday, May 22, 2007, Robert Hancock wrote:
> >> Eww. I don't see where we disable the decode at all while we probe
> >> the BARs on the device. That seems like a bad thing, especially with
> >> the way we probe 64-bit
Jesse Barnes wrote:
On Tuesday, May 22, 2007, Robert Hancock wrote:
Eww. I don't see where we disable the decode at all while we probe the
BARs on the device. That seems like a bad thing, especially with the way
we probe 64-bit BARs (do the low 32 bits first and then the high 32
bits). This
On Tuesday, May 22, 2007, Robert Hancock wrote:
> Eww. I don't see where we disable the decode at all while we probe the
> BARs on the device. That seems like a bad thing, especially with the way
> we probe 64-bit BARs (do the low 32 bits first and then the high 32
> bits). This means the base
Jesse Barnes wrote:
On Monday, May 21, 2007, Jesse Barnes wrote:
Yeah, I've got that data... just a sec while I make sure it's
reproducable...
Aha, I hadn't decoded the devfn before, looks like it's dying on an
access to the graphics device (bus 0, slot 2, device 0):
...
pci_mmcfg_read: 0, 0,
Jesse Barnes wrote:
On Monday, May 21, 2007, Jesse Barnes wrote:
Yeah, I've got that data... just a sec while I make sure it's
reproducable...
Aha, I hadn't decoded the devfn before, looks like it's dying on an
access to the graphics device (bus 0, slot 2, device 0):
...
pci_mmcfg_read: 0, 0,
On Tuesday, May 22, 2007, Robert Hancock wrote:
Eww. I don't see where we disable the decode at all while we probe the
BARs on the device. That seems like a bad thing, especially with the way
we probe 64-bit BARs (do the low 32 bits first and then the high 32
bits). This means the base address
Jesse Barnes wrote:
On Tuesday, May 22, 2007, Robert Hancock wrote:
Eww. I don't see where we disable the decode at all while we probe the
BARs on the device. That seems like a bad thing, especially with the way
we probe 64-bit BARs (do the low 32 bits first and then the high 32
bits). This
On Tuesday, May 22, 2007, Robert Hancock wrote:
Jesse Barnes wrote:
On Tuesday, May 22, 2007, Robert Hancock wrote:
Eww. I don't see where we disable the decode at all while we probe
the BARs on the device. That seems like a bad thing, especially with
the way we probe 64-bit BARs (do the
Jesse Barnes wrote:
On Tuesday, May 22, 2007, Robert Hancock wrote:
Eww. I don't see where we disable the decode at all while we probe the
BARs on the device. That seems like a bad thing, especially with the way
we probe 64-bit BARs (do the low 32 bits first and then the high 32
bits). This
On Monday, May 21, 2007, Jesse Barnes wrote:
> Yeah, I've got that data... just a sec while I make sure it's
> reproducable...
>
> Aha, I hadn't decoded the devfn before, looks like it's dying on an
> access to the graphics device (bus 0, slot 2, device 0):
>
> ...
> pci_mmcfg_read: 0, 0, 0x10,
On Monday, May 21, 2007, Robert Hancock wrote:
> > If I leave it enabled, several config cycles work fine, but the box
> > eventually hangs after probing 24 devices or so. I don't see anything
> > else mapped into this space, and the MTRRs seem ok, so either there's
> > something hidden in this
Jesse Barnes wrote:
What happens if you take out the chipset register detection, does
the MCFG table give you the same result? Wonder if they're doing
something funny with start/end bus values or something in their
table. There's some code in my patch that prints out the important
data from the
> > > What happens if you take out the chipset register detection, does
> > > the MCFG table give you the same result? Wonder if they're doing
> > > something funny with start/end bus values or something in their
> > > table. There's some code in my patch that prints out the important
> > > data
What happens if you take out the chipset register detection, does
the MCFG table give you the same result? Wonder if they're doing
something funny with start/end bus values or something in their
table. There's some code in my patch that prints out the important
data from the MCFG
Jesse Barnes wrote:
What happens if you take out the chipset register detection, does
the MCFG table give you the same result? Wonder if they're doing
something funny with start/end bus values or something in their
table. There's some code in my patch that prints out the important
data from the
On Monday, May 21, 2007, Robert Hancock wrote:
If I leave it enabled, several config cycles work fine, but the box
eventually hangs after probing 24 devices or so. I don't see anything
else mapped into this space, and the MTRRs seem ok, so either there's
something hidden in this memory
On Monday, May 21, 2007, Jesse Barnes wrote:
Yeah, I've got that data... just a sec while I make sure it's
reproducable...
Aha, I hadn't decoded the devfn before, looks like it's dying on an
access to the graphics device (bus 0, slot 2, device 0):
...
pci_mmcfg_read: 0, 0, 0x10, 0x18, 4 =
Jesse Barnes wrote:
On Wednesday, May 2, 2007 4:54 pm Jesse Barnes wrote:
What happens if you take out the chipset register detection, does
the MCFG table give you the same result? Wonder if they're doing
something funny with start/end bus values or something in their
table. There's some code
On Wednesday, May 2, 2007 4:54 pm Jesse Barnes wrote:
> > What happens if you take out the chipset register detection, does
> > the MCFG table give you the same result? Wonder if they're doing
> > something funny with start/end bus values or something in their
> > table. There's some code in my
On Wednesday, May 2, 2007 4:54 pm Jesse Barnes wrote:
What happens if you take out the chipset register detection, does
the MCFG table give you the same result? Wonder if they're doing
something funny with start/end bus values or something in their
table. There's some code in my patch that
Jesse Barnes wrote:
On Wednesday, May 2, 2007 4:54 pm Jesse Barnes wrote:
What happens if you take out the chipset register detection, does
the MCFG table give you the same result? Wonder if they're doing
something funny with start/end bus values or something in their
table. There's some code
On Wednesday, May 2, 2007 4:45 pm Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote:
> >> Jesse Barnes wrote:
> >>> On Tuesday, May 01, 2007, Jesse Barnes wrote:
> > I'm testing it now on my 965...
>
> Bah... nevermind Robert, I
Jesse Barnes wrote:
On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote:
Jesse Barnes wrote:
On Tuesday, May 01, 2007, Jesse Barnes wrote:
I'm testing it now on my 965...
Bah... nevermind Robert, I see you're doing this already in
pci_mmcfg_reject_broken. I'm about to reboot & test now.
1 - 100 of 122 matches
Mail list logo
