On Thu, Nov 15, 2018 at 05:16:01PM -0600, Alexandru Gagniuc wrote:
> Thanks to Keith for pointing out that it doesn't make sense to disable
> AER services when only one device has a FIRMWARE_FIRST HEST.
>
> AER ownership is an interesting issue brought in by FFS (firmware-first)
> model. In a nuts
On Tue, Nov 27, 2018 at 1:32 PM Sinan Kaya wrote:
>
> On 11/27/2018 1:22 PM, alex_gagn...@dellteam.com wrote:
> > On 11/20/2018 04:08 PM, Sinan Kaya wrote:
> >> I followed the ASWG thread yesterday. There will be a meeting next week to
> >> discuss this.
> >
> > Any updates on the meeting?
> >
> >
On 11/27/2018 1:22 PM, alex_gagn...@dellteam.com wrote:
On 11/20/2018 04:08 PM, Sinan Kaya wrote:
I followed the ASWG thread yesterday. There will be a meeting next week to
discuss this.
Any updates on the meeting?
Tyler should be able to get an update.
On 11/20/2018 04:08 PM, Sinan Kaya wrote:
> I followed the ASWG thread yesterday. There will be a meeting next week to
> discuss this.
Any updates on the meeting?
On 11/20/2018 04:08 PM, Sinan Kaya wrote:
> One version is:
> "if HEST table is present, ignore _OSC"
> or
> Another version is:
> "if HEST table is present, make sure that FW sets _OSC bit for AER to
> false. Otherwise, warn like crazy that this BIOS is broken and needs
> an update and can cause a
On 11/20/2018 04:28 PM, Sinan Kaya wrote:
On 11/20/2018 4:42 PM, Keith Busch wrote:
How does that work? If the OS takes control, it sets up MSIs that FW
don't
react to, and disables system errors through PCIe Root Control. Aren't
those sys errs the mechanism FW knows it has something to do,
On 11/20/2018 4:42 PM, Keith Busch wrote:
How does that work? If the OS takes control, it sets up MSIs that FW don't
react to, and disables system errors through PCIe Root Control. Aren't
those sys errs the mechanism FW knows it has something to do, which
means the OS can effectively fence it off
On 11/20/2018 4:46 PM, alex_gagn...@dellteam.com wrote:
Now, let's assume, for the sake of argument, that the firmware on those
system's is broken, and it didn't intend to give the OS control of AER.
OSPM checking HEST instead of _OSC is still wrong, according to the
spec. Two wrongs don't make a
On 11/20/2018 03:02 PM, Sinan Kaya wrote:
> On 11/20/2018 3:44 PM, alex_gagn...@dellteam.com wrote:
>> I'd prefer "sure" instead of "think". "I think it breaks some system I'm
>> not telling you about" doesn't help much in figuring out how not to
>> break said system(s).:)
>
> Sorry, I thought I m
On Tue, Nov 20, 2018 at 04:02:21PM -0500, Sinan Kaya wrote:
> On 11/20/2018 3:44 PM, alex_gagn...@dellteam.com wrote:
> > I'd prefer "sure" instead of "think". "I think it breaks some system I'm
> > not telling you about" doesn't help much in figuring out how not to
> > break said system(s).:)
>
>
On 11/20/2018 3:44 PM, alex_gagn...@dellteam.com wrote:
I'd prefer "sure" instead of "think". "I think it breaks some system I'm
not telling you about" doesn't help much in figuring out how not to
break said system(s).:)
Sorry, I thought I mentioned why it would break but let me repeat.
The sy
On 11/19/2018 07:54 PM, Sinan Kaya wrote:
> On 11/19/2018 6:49 PM, alex_gagn...@dellteam.com wrote:
>> On 11/19/2018 02:33 PM, Sinan Kaya wrote:
>>> However; table assumes governance about for which entities firmware first
>>> should be enabled. There is no cross reference to _OSC or permission
>>>
On 11/19/2018 6:49 PM, alex_gagn...@dellteam.com wrote:
On 11/19/2018 02:33 PM, Sinan Kaya wrote:
However; table assumes governance about for which entities firmware first
should be enabled. There is no cross reference to _OSC or permission
negotiation like _OST.
Well, from an OSPM perspective
On 11/19/2018 02:33 PM, Sinan Kaya wrote:
> True. I was trying to get it out in a rush. I omitted words.
Sounds like you'd make an top notch spec writer! :p
> However; table assumes governance about for which entities firmware first
> should be enabled. There is no cross reference to _OSC or perm
On Thu, Nov 15, 2018 at 8:49 PM Sinan Kaya wrote:
>
> On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
> > I've asked around a few people at Dell and they unanimously agree that
> > _OSC is the correct way to determine ownership of AER. In linux, we
> > use the result of _OSC to enable AER services
On 11/19/2018 3:16 PM, alex_gagn...@dellteam.com wrote:
On 11/19/2018 01:32 PM, Sinan Kaya wrote:
ACPI 6.2:
18.3.2.4 PCI Express Root Port AER Structure
Flags:
Bit [0] - FIRMWARE_FIRST: If set, this bit indicates to the OSPM that system
firmware will handle errors from this source first.
Bit
On 11/19/2018 01:32 PM, Sinan Kaya wrote:
> ACPI 6.2:
>
> 18.3.2.4 PCI Express Root Port AER Structure
>
> Flags:
>
> Bit [0] - FIRMWARE_FIRST: If set, this bit indicates to the OSPM that system
> firmware will handle errors from this source first.
> Bit [1] - GLOBAL: If set, indicates that the
UEFI HEST table specification also claims that it should be the ultimate
table for when PCI firmware-first should be disabled/enabled.
IIRC, EFI absorbed ACPI before FFS was a thing. Could you point me to the UEFI
chapter that says HEST is authoritative?
(not being a smartie, just that my free
On 11/19/2018 12:24 PM, Sinan Kaya wrote:
On 11/19/2018 1:10 PM, Keith Busch wrote:
We can't really turn off firmware first in the kernel without asking
help
from the firmware.
The _OSC method this patch utilizes is the ACPI spec defined way for
the kernel to wrest control from firmware. BIOS
On 11/19/2018 1:10 PM, Keith Busch wrote:
We can't really turn off firmware first in the kernel without asking help
from the firmware.
The _OSC method this patch utilizes is the ACPI spec defined way for
the kernel to wrest control from firmware. BIOS specific menu settings
shouldn't be our only
On Mon, Nov 19, 2018 at 12:56:56PM -0500, Sinan Kaya wrote:
> On 11/19/2018 12:41 PM, Keith Busch wrote:
> > > Still, breaking existing systems that rely on HEST table is not cool.
> > > I'd rather have users specify "pcie_ports=native" to skip FF rather than
> > > having broken systems by default
On 11/19/2018 12:41 PM, Keith Busch wrote:
Still, breaking existing systems that rely on HEST table is not cool.
I'd rather have users specify "pcie_ports=native" to skip FF rather than
having broken systems by default to be honest.
The pcie_ports=native work-around ignores FF to potentially unk
On Mon, Nov 19, 2018 at 12:42:25PM -0500, Sinan Kaya wrote:
> On 11/19/2018 12:32 PM, Sinan Kaya wrote:
> > >
> > > But we're not using HEST as a fine grain control. We disable native AER
> > > handling if *any* device has FF set in HEST, and that just forces people
> > > to use pcie_ports=native
On 11/19/2018 12:32 PM, Sinan Kaya wrote:
But we're not using HEST as a fine grain control. We disable native AER
handling if *any* device has FF set in HEST, and that just forces people
to use pcie_ports=native to get around that.
I don't see *any* in the code. aer_hest_parse() does the HES
On Mon, Nov 19, 2018 at 12:32:42PM -0500, Sinan Kaya wrote:
> On 11/19/2018 11:53 AM, Keith Busch wrote:
> > On Mon, Nov 19, 2018 at 11:53:05AM -0500, Tyler Baicar wrote:
> > > On Thu, Nov 15, 2018 at 8:49 PM Sinan Kaya wrote:
> > > >
> > > > On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
> > >
On 11/19/2018 11:53 AM, Keith Busch wrote:
On Mon, Nov 19, 2018 at 11:53:05AM -0500, Tyler Baicar wrote:
On Thu, Nov 15, 2018 at 8:49 PM Sinan Kaya wrote:
On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
I've asked around a few people at Dell and they unanimously agree that
_OSC is the correc
On Mon, Nov 19, 2018 at 11:53:05AM -0500, Tyler Baicar wrote:
> On Thu, Nov 15, 2018 at 8:49 PM Sinan Kaya wrote:
> >
> > On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
> > > I've asked around a few people at Dell and they unanimously agree that
> > > _OSC is the correct way to determine ownershi
From: Alexandru Gagniuc
> Sent: 15 November 2018 23:16
...
> I've asked around a few people at Dell and they unanimously agree that
> _OSC is the correct way to determine ownership of AER.
This is all very well, but we have systems (they might be Dell ones)
where failure of a PCIe link (even when
On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
I've asked around a few people at Dell and they unanimously agree that
_OSC is the correct way to determine ownership of AER. In linux, we
use the result of _OSC to enable AER services, but we use HEST to
determine AER ownership. That's inconsistent
29 matches
Mail list logo