Here's a new patch based on Linus latest one with better error checking.
Please push if you are fine with it.
This patch fixes a problem with pci_map_rom() which doesn't properly
update the ROM BAR value with the address thas allocated for it by the
PCI code. This problem, among other, breaks boot
Linus Torvalds wrote:
On Tue, 30 Aug 2005, Jon Smirl wrote:
I was reading the status out of the PCI config space to account for
our friend X which enables ROMs without informing the OS. With X
around PCI config space can get out of sync with the kernel
structures.
Well, yes, except that we
On Llu, 2005-08-29 at 22:15 -0700, Linus Torvalds wrote:
> I'm sure X plays games with this register (I suspect that's why the Matrox
> thing broke in the first place), but I don't think it should do so while
> the kernel uses it.
X maps it over ram during matrox set up but that is all it uses
On Mon, 2005-08-29 at 22:29 -0700, Linus Torvalds wrote:
>
> On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
> >
> > I was just testing a slightly different one that appear to fix the
> > problem :
> ...
> > + rom_addr = region.start | (res->flags & PCI_REGION_FLAG_MASK);
>
> I worry about
On Mon, 2005-08-29 at 22:32 -0700, David S. Miller wrote:
> From: Jon Smirl <[EMAIL PROTECTED]>
> Date: Tue, 30 Aug 2005 00:35:11 -0400
>
> > As far as I can tell no one has built recent hardware this way. But I
> > believe there are some old SCSI controllers that do this. I provided a
> > ROM API
On Mon, 2005-08-29 at 22:03 -0700, Linus Torvalds wrote:
>
> On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
> >
> > So what about fixing pci_map_rom() to call pcibios_resource_to_bus() and
> > then write the resource back to the BAR ? I'm still a bit annoyed that
> > we re-allocate the addres
From: Jon Smirl <[EMAIL PROTECTED]>
Date: Tue, 30 Aug 2005 00:35:11 -0400
> As far as I can tell no one has built recent hardware this way. But I
> believe there are some old SCSI controllers that do this. I provided a
> ROM API for disabling sysfs access, if we identify one of these cards
> we sh
On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
>
> I was just testing a slightly different one that appear to fix the
> problem :
...
> + rom_addr = region.start | (res->flags & PCI_REGION_FLAG_MASK);
I worry about this one. It's not really correct. The low en bits are
"reserved", and
On Tue, 30 Aug 2005, Jon Smirl wrote:
>
> I was reading the status out of the PCI config space to account for
> our friend X which enables ROMs without informing the OS. With X
> around PCI config space can get out of sync with the kernel
> structures.
Well, yes, except that we use the in-kerne
On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
>
> So what about fixing pci_map_rom() to call pcibios_resource_to_bus() and
> then write the resource back to the BAR ? I'm still a bit annoyed that
> we re-allocate the address while the original one was perfectly good
> (though not enabled) b
>
> I was reading the status out of the PCI config space to account for
> our friend X which enables ROMs without informing the OS. With X
> around PCI config space can get out of sync with the kernel
> structures.
Well, X isn't supposed to keep the ROM enabled is it ? besides, most of
the time,
On 8/30/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Aug 2005, David S. Miller wrote:
> >
> > So I think the kernel, by not enabling the ROM, is doing the
> > right thing here.
>
> Notice that on ppc even older versions didn't actually _enable_ the rom,
> but they would write t
On Mon, 2005-08-29 at 21:40 -0700, Linus Torvalds wrote:
>
> On Mon, 29 Aug 2005, David S. Miller wrote:
> >
> > So I think the kernel, by not enabling the ROM, is doing the
> > right thing here.
>
> Notice that on ppc even older versions didn't actually _enable_ the rom,
> but they would write
On 8/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
> >
> > pci_map_rom "sees" that the resource is unassigned by testing the parent
> > pointer, and calls pci_assign_resource() which, with this new patch,
> > will do nothing.
>
> Ehh..
On Mon, 2005-08-29 at 21:20 -0700, David S. Miller wrote:
> From: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Mon, 29 Aug 2005 21:09:24 -0700 (PDT)
>
> > So 2.6.13 is being "safe". It allocates the space for the ROM in the
> > resource tables, but it neither enables it nor does it write the
> > (di
On Mon, 29 Aug 2005, David S. Miller wrote:
>
> So I think the kernel, by not enabling the ROM, is doing the
> right thing here.
Notice that on ppc even older versions didn't actually _enable_ the rom,
but they would write the non-enabled address to the PCI_ROM_ADDRESS
register, so that anybody
> What you want is a "zombie state", where we write the partial information
> to hardware. It's what we used to do, but it's certainly no more logical
> than what it does now, and it led to problem reports.
>
> Btw, why does this happen on powerpc, but not x86? I'm running a radeon
> laptop ri
On 8/29/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> While looking there, I also noticed pci_map_rom_copy() stuff and I'm
> surprised it was ever accepted in the tree. While I can understand that
> we might need to keep a cached copy of the ROM content (due to cards
> like matrox who can
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Mon, 29 Aug 2005 21:09:24 -0700 (PDT)
> So 2.6.13 is being "safe". It allocates the space for the ROM in the
> resource tables, but it neither enables it nor does it write the
> (disabled) address out to the device, since both of those actions have
>
On Mon, 29 Aug 2005, Linus Torvalds wrote:
>
> What you want is a "zombie state", where we write the partial information
> to hardware. It's what we used to do, but it's certainly no more logical
> than what it does now, and it led to problem reports.
Btw, the fundamental reason for the chang
On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
>
> Ok, it won't do nothing in fact. It's worse. It will return 0 (success),
> will actually assign a completely new address to the resource, will
> update the resource structure ... and will _not_ update the PCI resource
> BAR for the ROM.
>
>
> pci_map_rom "sees" that the resource is unassigned by testing the parent
> pointer, and calls pci_assign_resource() which, with this new patch,
> will do nothing.
Ok, it won't do nothing in fact. It's worse. It will return 0 (success),
will actually assign a completely new address to the resour
On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
>
> pci_map_rom "sees" that the resource is unassigned by testing the parent
> pointer, and calls pci_assign_resource() which, with this new patch,
> will do nothing.
Ehh.. It didn't do anything with the old code either for that case, so
there
L PROTECTED]> Sat, 27 Aug 2005 00:49:22 -0700
>
> Ignore disabled ROM resources at setup
>
> Writing even a disabled value seems to mess up some matrox graphics
> cards. It may be a card-related issue, but we may also be writing
> reserved low bits in the result.
>
>
24 matches
Mail list logo
