Here it is a year later and there has basically been no progress on
this ongoing situation. I still often encounter bugs raised against
the kernel w.r.t. unmet resource allocations - here is the most recent
example, I'll attach the 'dmesg' log from the platform at
Here it is a year later and there has basically been no progress on
this ongoing situation. I still often encounter bugs raised against
the kernel w.r.t. unmet resource allocations - here is the most recent
example, I'll attach the 'dmesg' log from the platform at
On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe wrote:
snip
>
> There is a kernel boot parameter, pci=norom, that is intended to disable the
> kernel's resource assignment actions for Expansion ROMs that do not already
> have BIOS assigned address ranges. Note however, if I remember correctly,
>
On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe wrote:
snip
>
> The kernel expects device Expansion ROM BARs to be programmed with valid
> values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
> device’s expansion ROM address space is disabled). This seems to be the
> main
On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe wrote:
snip
>
> There is a kernel boot parameter, pci=norom, that is intended to disable the
> kernel's resource assignment actions for Expansion ROMs that do not already
> have BIOS assigned address ranges. Note however, if I
On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe wrote:
snip
>
> The kernel expects device Expansion ROM BARs to be programmed with valid
> values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
> device’s expansion ROM address space is disabled). This seems
On Thursday, September 24, 2015 at 10:50:07 AM UTC+8, Myron Stowe wrote:
> I've encountered numerous bugzilla reports related to platform BIOS' not
> programming valid values into a PCI device's Type 0 Configuration space
> "Expansion ROM Base Address" field (a.k.a. Expansion ROM BAR). The main
>
On Thursday, September 24, 2015 at 10:50:07 AM UTC+8, Myron Stowe wrote:
> I've encountered numerous bugzilla reports related to platform BIOS' not
> programming valid values into a PCI device's Type 0 Configuration space
> "Expansion ROM Base Address" field (a.k.a. Expansion ROM BAR). The main
>
On Fri, Sep 25, 2015 at 9:18 AM, Alex Williamson
wrote:
>> > > Or do we want to keep a white list to say which device should have
>> > > ROM bar as mush have, and other is optional to have ?
>> >
>> > Subject: [RFC PATCH] PCI: Add pci_dev_need_rom_bar()
>> >
>> > Only set that for
>> > 1. if
On Fri, Sep 25, 2015 at 7:31 AM, Myron Stowe wrote:
> On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu wrote:
>> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
>>
>>> Or do we want to keep a white list to say which device should have
>>> ROM bar as mush have, and other is optional to have ?
>
On Fri, 2015-09-25 at 09:35 -0500, Bjorn Helgaas wrote:
> On Thu, Sep 24, 2015 at 09:35:20PM -0700, Yinghai Lu wrote:
> > On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
> >
> > > Or do we want to keep a white list to say which device should have
> > > ROM bar as mush have, and other is
On Thu, Sep 24, 2015 at 09:35:20PM -0700, Yinghai Lu wrote:
> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
>
> > Or do we want to keep a white list to say which device should have
> > ROM bar as mush have, and other is optional to have ?
>
> Subject: [RFC PATCH] PCI: Add
On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu wrote:
> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
>
>> Or do we want to keep a white list to say which device should have
>> ROM bar as mush have, and other is optional to have ?
I suppose this idea is one possible outcome that could occur
On Thu, Sep 24, 2015 at 09:35:20PM -0700, Yinghai Lu wrote:
> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
>
> > Or do we want to keep a white list to say which device should have
> > ROM bar as mush have, and other is optional to have ?
>
> Subject: [RFC PATCH] PCI:
On Fri, 2015-09-25 at 09:35 -0500, Bjorn Helgaas wrote:
> On Thu, Sep 24, 2015 at 09:35:20PM -0700, Yinghai Lu wrote:
> > On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
> >
> > > Or do we want to keep a white list to say which device should have
> > > ROM bar as mush
On Fri, Sep 25, 2015 at 7:31 AM, Myron Stowe wrote:
> On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu wrote:
>> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
>>
>>> Or do we want to keep a white list to say which device should
On Fri, Sep 25, 2015 at 9:18 AM, Alex Williamson
wrote:
>> > > Or do we want to keep a white list to say which device should have
>> > > ROM bar as mush have, and other is optional to have ?
>> >
>> > Subject: [RFC PATCH] PCI: Add pci_dev_need_rom_bar()
>> >
>> > Only
On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu wrote:
> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
>
>> Or do we want to keep a white list to say which device should have
>> ROM bar as mush have, and other is optional to have ?
I suppose this idea
On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
> Or do we want to keep a white list to say which device should have
> ROM bar as mush have, and other is optional to have ?
Subject: [RFC PATCH] PCI: Add pci_dev_need_rom_bar()
Only set that for
1. if BIOS/firmware already set ROM bar.
2.
On Thu, Sep 24, 2015 at 10:06 AM, Myron Stowe wrote:
> On Wed, Sep 23, 2015 at 9:21 PM, Yinghai Lu wrote:
>> On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote:
>>>
>>> The kernel expects device Expansion ROM BARs to be programmed with valid
>>> values - even if the respective Expansion ROM's
On Wed, Sep 23, 2015 at 9:21 PM, Yinghai Lu wrote:
> On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote:
>>
>> The kernel expects device Expansion ROM BARs to be programmed with valid
>> values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
>> device’s expansion ROM address
On Thu, Sep 24, 2015 at 10:06 AM, Myron Stowe wrote:
> On Wed, Sep 23, 2015 at 9:21 PM, Yinghai Lu wrote:
>> On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote:
>>>
>>> The kernel expects device Expansion ROM BARs to be
On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
> Or do we want to keep a white list to say which device should have
> ROM bar as mush have, and other is optional to have ?
Subject: [RFC PATCH] PCI: Add pci_dev_need_rom_bar()
Only set that for
1. if BIOS/firmware
On Wed, Sep 23, 2015 at 9:21 PM, Yinghai Lu wrote:
> On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote:
>>
>> The kernel expects device Expansion ROM BARs to be programmed with valid
>> values - even if the respective Expansion ROM's Enable bit is 0
On Wed, 2015-09-23 at 20:21 -0700, Yinghai Lu wrote:
> On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote:
> >
> > The kernel expects device Expansion ROM BARs to be programmed with valid
> > values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
> > device’s expansion ROM
On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote:
>
> The kernel expects device Expansion ROM BARs to be programmed with valid
> values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
> device’s expansion ROM address space is disabled). This seems to be the
> main contention
On Wed, 2015-09-23 at 20:21 -0700, Yinghai Lu wrote:
> On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote:
> >
> > The kernel expects device Expansion ROM BARs to be programmed with valid
> > values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
> >
On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote:
>
> The kernel expects device Expansion ROM BARs to be programmed with valid
> values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
> device’s expansion ROM address space is disabled). This seems to
28 matches
Mail list logo