* dmi type 0xB1 record - unknown flag
@ 2017-06-01 12:38 Jean Delvare
2017-06-01 13:28 ` Narendra.K
0 siblings, 1 reply; 9+ messages in thread
From: Jean Delvare @ 2017-06-01 12:38 UTC (permalink / raw)
To: x86, linux-pci; +Cc: Narendra_K, Jordan Hargrave, Shyam Iyer, Bjorn Helgaas
Hi all,
I see the following message in my kernel log:
dmi type 0xB1 record - unknown flag
This is on a Dell Optiplex 9020 workstation. I see the message comes
from:
static void __init read_dmi_type_b1(const struct dmi_header *dm,
void *private_data)
{
(...)
switch (((*(u32 *)d) >> 9) & 0x03) {
case 0x00:
printk(KERN_INFO "dmi type 0xB1 record - unknown flag\n");
break;
What is the value of this message? Is there anything which needs to be
done to properly support such systems?
Thanks,
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: dmi type 0xB1 record - unknown flag
2017-06-01 12:38 dmi type 0xB1 record - unknown flag Jean Delvare
@ 2017-06-01 13:28 ` Narendra.K
2017-06-01 16:59 ` Bjorn Helgaas
2017-06-02 14:13 ` Jean Delvare
0 siblings, 2 replies; 9+ messages in thread
From: Narendra.K @ 2017-06-01 13:28 UTC (permalink / raw)
To: jdelvare, x86, linux-pci
Cc: Jordan.Hargrave, Shyam.Iyer, bhelgaas, Narendra.K
> -----Original Message-----
> From: Jean Delvare [mailto:jdelvare@suse.de]
> Sent: Thursday, June 1, 2017 6:08 PM
> To: x86@kernel.org; linux-pci@vger.kernel.org
> Cc: K, Narendra <Narendra_K@Dell.com>; Hargrave, Jordan
> <Jordan_Hargrave@Dell.com>; Iyer, Shyam <Shyam_Iyer@Dell.com>; Bjorn
> Helgaas <bhelgaas@google.com>
> Subject: dmi type 0xB1 record - unknown flag
>=20
> Hi all,
>=20
Hi Jean,
> I see the following message in my kernel log:
>=20
> dmi type 0xB1 record - unknown flag
>=20
> This is on a Dell Optiplex 9020 workstation. I see the message comes
> from:
>=20
> static void __init read_dmi_type_b1(const struct dmi_header *dm,
> void *private_data) {
> (...)
> switch (((*(u32 *)d) >> 9) & 0x03) {
> case 0x00:
> printk(KERN_INFO "dmi type 0xB1 record - unknown flag\n")=
;
> break;
>=20
> What is the value of this message? Is there anything which needs to be do=
ne
> to properly support such systems?
This function was added to avoid adding systems to the 'pciprobe_dmi_table'=
and set breadth first sorting in a generic way.
This flag is a hint to indicate the sort method to be used. The value 0x01 =
indicates that PCI breadth first sort be used.
' find_sort_method' function checks if smbios_type_b1_flag is set to 1 and =
if yes, calls 'set_bf_sort '. This function sets ' pci_bf_sort' to 'pci_dmi=
_bf'.
The value 0x00 is not a valid value. When the flag is 0x00, the sort method=
will be the default that is decided by the kernel.
There is no additional handling required for such a system.
With regards,
Narendra K
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dmi type 0xB1 record - unknown flag
2017-06-01 13:28 ` Narendra.K
@ 2017-06-01 16:59 ` Bjorn Helgaas
2017-06-02 9:47 ` Narendra.K
2017-06-02 14:13 ` Jean Delvare
1 sibling, 1 reply; 9+ messages in thread
From: Bjorn Helgaas @ 2017-06-01 16:59 UTC (permalink / raw)
To: Narendra.K
Cc: jdelvare, x86, linux-pci, Jordan.Hargrave, Shyam.Iyer, bhelgaas
On Thu, Jun 01, 2017 at 01:28:31PM +0000, Narendra.K@dell.com wrote:
> > -----Original Message-----
> > From: Jean Delvare [mailto:jdelvare@suse.de]
> > Sent: Thursday, June 1, 2017 6:08 PM
> > To: x86@kernel.org; linux-pci@vger.kernel.org
> > Cc: K, Narendra <Narendra_K@Dell.com>; Hargrave, Jordan
> > <Jordan_Hargrave@Dell.com>; Iyer, Shyam <Shyam_Iyer@Dell.com>; Bjorn
> > Helgaas <bhelgaas@google.com>
> > Subject: dmi type 0xB1 record - unknown flag
> >
> > Hi all,
> >
>
> Hi Jean,
>
> > I see the following message in my kernel log:
> >
> > dmi type 0xB1 record - unknown flag
> >
> > This is on a Dell Optiplex 9020 workstation. I see the message comes
> > from:
> >
> > static void __init read_dmi_type_b1(const struct dmi_header *dm,
> > void *private_data) {
> > (...)
> > switch (((*(u32 *)d) >> 9) & 0x03) {
> > case 0x00:
> > printk(KERN_INFO "dmi type 0xB1 record - unknown flag\n");
> > break;
> >
> > What is the value of this message? Is there anything which needs
> > to be done to properly support such systems?
>
> This function was added to avoid adding systems to the
> 'pciprobe_dmi_table' and set breadth first sorting in a generic way.
>
> This flag is a hint to indicate the sort method to be used. The
> value 0x01 indicates that PCI breadth first sort be used. '
> find_sort_method' function checks if smbios_type_b1_flag is set to 1
> and if yes, calls 'set_bf_sort '. This function sets ' pci_bf_sort'
> to 'pci_dmi_bf'.
>
> The value 0x00 is not a valid value. When the flag is 0x00, the sort
> method will be the default that is decided by the kernel.
>
> There is no additional handling required for such a system.
That was added by 6e8af08dfa40 ("PCI: enable pci=bfsort by default on
future Dell systems").
The fact that BIOS supplied a B1 record with an unknown value (0)
looks like a Dell BIOS defect, which is ironic, considering that Dell
added this thing in the first place.
I think we should remove the message, since it is alarming to users
and they can't do anything about it anyway.
Bjorn
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: dmi type 0xB1 record - unknown flag
2017-06-01 16:59 ` Bjorn Helgaas
@ 2017-06-02 9:47 ` Narendra.K
0 siblings, 0 replies; 9+ messages in thread
From: Narendra.K @ 2017-06-02 9:47 UTC (permalink / raw)
To: helgaas
Cc: jdelvare, x86, linux-pci, Jordan.Hargrave, Shyam.Iyer, bhelgaas,
Sujith.Pandel
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> Sent: Thursday, June 1, 2017 10:30 PM
> To: K, Narendra <Narendra_K@Dell.com>
> Cc: jdelvare@suse.de; x86@kernel.org; linux-pci@vger.kernel.org; Hargrave=
,
> Jordan <Jordan_Hargrave@Dell.com>; Iyer, Shyam
> <Shyam_Iyer@Dell.com>; bhelgaas@google.com
> Subject: Re: dmi type 0xB1 record - unknown flag
[...]
> > The value 0x00 is not a valid value. When the flag is 0x00, the sort
> > method will be the default that is decided by the kernel.
> >
> > There is no additional handling required for such a system.
>=20
> That was added by 6e8af08dfa40 ("PCI: enable pci=3Dbfsort by default on
> future Dell systems").
>=20
> The fact that BIOS supplied a B1 record with an unknown value (0) looks l=
ike a
> Dell BIOS defect, which is ironic, considering that Dell added this thing=
in the
> first place.
>=20
> I think we should remove the message, since it is alarming to users and t=
hey
> can't do anything about it anyway.
>=20
Hi Bjorn,
Thank you for the feedback. We will submit a patch to remove the message.=20
With regards,
Narendra K
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dmi type 0xB1 record - unknown flag
2017-06-01 13:28 ` Narendra.K
2017-06-01 16:59 ` Bjorn Helgaas
@ 2017-06-02 14:13 ` Jean Delvare
2017-06-06 8:02 ` Narendra.K
2017-06-15 21:39 ` Bjorn Helgaas
1 sibling, 2 replies; 9+ messages in thread
From: Jean Delvare @ 2017-06-02 14:13 UTC (permalink / raw)
To: Narendra.K; +Cc: x86, linux-pci, Jordan.Hargrave, Shyam.Iyer, bhelgaas
Hi Narendra,
Thanks for your answer.
On Thu, 1 Jun 2017 13:28:31 +0000, Narendra.K@dell.com wrote:
> > -----Original Message-----
> > From: Jean Delvare [mailto:jdelvare@suse.de]
> > I see the following message in my kernel log:
> >
> > dmi type 0xB1 record - unknown flag
> >
> > This is on a Dell Optiplex 9020 workstation. I see the message comes
> > from:
> >
> > static void __init read_dmi_type_b1(const struct dmi_header *dm,
> > void *private_data) {
> > (...)
> > switch (((*(u32 *)d) >> 9) & 0x03) {
> > case 0x00:
> > printk(KERN_INFO "dmi type 0xB1 record - unknown flag\n");
> > break;
> >
> > What is the value of this message? Is there anything which needs to be done
> > to properly support such systems?
>
> This function was added to avoid adding systems to the 'pciprobe_dmi_table' and set breadth first sorting in a generic way.
>
> This flag is a hint to indicate the sort method to be used. The value 0x01 indicates that PCI breadth first sort be used.
> ' find_sort_method' function checks if smbios_type_b1_flag is set to 1 and if yes, calls 'set_bf_sort '. This function sets ' pci_bf_sort' to 'pci_dmi_bf'.
I can read the code, thank you ;-)
> The value 0x00 is not a valid value. When the flag is 0x00, the sort method will be the default that is decided by the kernel.
How can it be invalid? I have DMI dumps of several Dell systems with a
type 0xB1 DMI structure, with value 0x00 for these bits. If Dell ships
such systems, then this is valid by definition.
> There is no additional handling required for such a system.
I don't understand the complexity of the code. There are 4 possible
values for these bits, the code treats all of them differently:
* 0x01, you set smbios_type_b1_flag to 1 and this later triggers a call
to set_bf_sort().
* 0x02, you set smbios_type_b1_flag to 2 but this has no effect.
* 0x00, you print a rather cryptic info message which serves no purpose.
* 0x03, you do nothing.
On top of that, I can't see the value of the intermediate variable
smbios_type_b1_flag. The only situations where it would make a
difference is if multiple type 0xB1 structures with conflicting
information were present; but I don't think this is supposed to happen
in the first place.
Lastly I'm not sure why you continue processing the list of DMI
matches, when smbios_type_b1_flag == 1, and stop processing it if not.
This seems needlessly inconsistent.
I think the whole thing can be simplified like this:
From: Jean Delvare <jdelvare@suse.de>
Subject: x86/PCI: Simplify Dell DMI B1 quirk
No need for such convoluted code, when all we need is to call one
function in one specific case.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
---
arch/x86/pci/common.c | 27 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
--- linux-4.11.orig/arch/x86/pci/common.c 2017-05-01 04:47:48.000000000 +0200
+++ linux-4.11/arch/x86/pci/common.c 2017-06-02 16:04:05.737889598 +0200
@@ -24,7 +24,6 @@ unsigned int pci_probe = PCI_PROBE_BIOS
unsigned int pci_early_dump_regs;
static int pci_bf_sort;
-static int smbios_type_b1_flag;
int pci_routeirq;
int noioapicquirk;
#ifdef CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS
@@ -197,34 +196,18 @@ static int __init set_bf_sort(const stru
static void __init read_dmi_type_b1(const struct dmi_header *dm,
void *private_data)
{
- u8 *d = (u8 *)dm + 4;
+ u8 *data = (u8 *)dm + 4;
if (dm->type != 0xB1)
return;
- switch (((*(u32 *)d) >> 9) & 0x03) {
- case 0x00:
- printk(KERN_INFO "dmi type 0xB1 record - unknown flag\n");
- break;
- case 0x01: /* set pci=bfsort */
- smbios_type_b1_flag = 1;
- break;
- case 0x02: /* do not set pci=bfsort */
- smbios_type_b1_flag = 2;
- break;
- default:
- break;
- }
+ if ((((*(u32 *)data) >> 9) & 0x03) == 0x01)
+ set_bf_sort((const struct dmi_system_id *)private_data);
}
static int __init find_sort_method(const struct dmi_system_id *d)
{
- dmi_walk(read_dmi_type_b1, NULL);
-
- if (smbios_type_b1_flag == 1) {
- set_bf_sort(d);
- return 0;
- }
- return -1;
+ dmi_walk(read_dmi_type_b1, (void *)d);
+ return 0;
}
/*
What do you think?
Thanks,
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: dmi type 0xB1 record - unknown flag
2017-06-02 14:13 ` Jean Delvare
@ 2017-06-06 8:02 ` Narendra.K
2017-06-15 21:39 ` Bjorn Helgaas
1 sibling, 0 replies; 9+ messages in thread
From: Narendra.K @ 2017-06-06 8:02 UTC (permalink / raw)
To: jdelvare
Cc: x86, linux-pci, Jordan.Hargrave, Shyam.Iyer, bhelgaas, Narendra.K
> -----Original Message-----
> From: Jean Delvare [mailto:jdelvare@suse.de]
> Sent: Friday, June 2, 2017 7:43 PM
> To: K, Narendra <Narendra_K@Dell.com>
> Cc: x86@kernel.org; linux-pci@vger.kernel.org; Hargrave, Jordan
> <Jordan_Hargrave@Dell.com>; Iyer, Shyam <Shyam_Iyer@Dell.com>;
> bhelgaas@google.com
> Subject: Re: dmi type 0xB1 record - unknown flag
[...]
> > The value 0x00 is not a valid value. When the flag is 0x00, the sort me=
thod
> will be the default that is decided by the kernel.
>=20
> How can it be invalid? I have DMI dumps of several Dell systems with a ty=
pe
> 0xB1 DMI structure, with value 0x00 for these bits. If Dell ships such sy=
stems,
> then this is valid by definition.
>=20
> > There is no additional handling required for such a system.
>=20
> I don't understand the complexity of the code. There are 4 possible value=
s
> for these bits, the code treats all of them differently:
> * 0x01, you set smbios_type_b1_flag to 1 and this later triggers a call
> to set_bf_sort().
> * 0x02, you set smbios_type_b1_flag to 2 but this has no effect.
> * 0x00, you print a rather cryptic info message which serves no purpose.
> * 0x03, you do nothing.
>=20
> On top of that, I can't see the value of the intermediate variable
> smbios_type_b1_flag. The only situations where it would make a difference
> is if multiple type 0xB1 structures with conflicting information were pre=
sent;
> but I don't think this is supposed to happen in the first place.
>=20
> Lastly I'm not sure why you continue processing the list of DMI matches,
> when smbios_type_b1_flag =3D=3D 1, and stop processing it if not.
> This seems needlessly inconsistent.
>=20
> I think the whole thing can be simplified like this:
>=20
> From: Jean Delvare <jdelvare@suse.de>
> Subject: x86/PCI: Simplify Dell DMI B1 quirk
>=20
> No need for such convoluted code, when all we need is to call one functio=
n in
> one specific case.
>=20
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> ---
> arch/x86/pci/common.c | 27 +++++----------------------
> 1 file changed, 5 insertions(+), 22 deletions(-)
>=20
> --- linux-4.11.orig/arch/x86/pci/common.c 2017-05-01
> 04:47:48.000000000 +0200
> +++ linux-4.11/arch/x86/pci/common.c 2017-06-02 16:04:05.737889598 +0200
> @@ -24,7 +24,6 @@ unsigned int pci_probe =3D PCI_PROBE_BIOS
>=20
> unsigned int pci_early_dump_regs;
> static int pci_bf_sort;
> -static int smbios_type_b1_flag;
> int pci_routeirq;
> int noioapicquirk;
> #ifdef CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS
> @@ -197,34 +196,18 @@ static int __init set_bf_sort(const stru static vo=
id
> __init read_dmi_type_b1(const struct dmi_header *dm,
> void *private_data)
> {
> - u8 *d =3D (u8 *)dm + 4;
> + u8 *data =3D (u8 *)dm + 4;
>=20
> if (dm->type !=3D 0xB1)
> return;
> - switch (((*(u32 *)d) >> 9) & 0x03) {
> - case 0x00:
> - printk(KERN_INFO "dmi type 0xB1 record - unknown flag\n");
> - break;
> - case 0x01: /* set pci=3Dbfsort */
> - smbios_type_b1_flag =3D 1;
> - break;
> - case 0x02: /* do not set pci=3Dbfsort */
> - smbios_type_b1_flag =3D 2;
> - break;
> - default:
> - break;
> - }
> + if ((((*(u32 *)data) >> 9) & 0x03) =3D=3D 0x01)
> + set_bf_sort((const struct dmi_system_id *)private_data);
> }
>=20
> static int __init find_sort_method(const struct dmi_system_id *d) {
> - dmi_walk(read_dmi_type_b1, NULL);
> -
> - if (smbios_type_b1_flag =3D=3D 1) {
> - set_bf_sort(d);
> - return 0;
> - }
> - return -1;
> + dmi_walk(read_dmi_type_b1, (void *)d);
> + return 0;
> }
>=20
> /*
>=20
> What do you think?
Hi Jean,
Thank you for reviewing and providing feedback. We will look into this and =
provide feedback.
With regards,
Narendra K
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dmi type 0xB1 record - unknown flag
2017-06-02 14:13 ` Jean Delvare
2017-06-06 8:02 ` Narendra.K
@ 2017-06-15 21:39 ` Bjorn Helgaas
2017-06-16 9:36 ` Narendra.K
1 sibling, 1 reply; 9+ messages in thread
From: Bjorn Helgaas @ 2017-06-15 21:39 UTC (permalink / raw)
To: Jean Delvare
Cc: Narendra.K, x86, linux-pci, Jordan.Hargrave, Shyam.Iyer, bhelgaas
On Fri, Jun 02, 2017 at 04:13:11PM +0200, Jean Delvare wrote:
> ...
> I think the whole thing can be simplified like this:
>
> From: Jean Delvare <jdelvare@suse.de>
> Subject: x86/PCI: Simplify Dell DMI B1 quirk
>
> No need for such convoluted code, when all we need is to call one
> function in one specific case.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
Applied to pci/misc for v4.13, thanks!
As far as I can tell, the new code is functionally equivalent to the
old code, so I don't think there's any risk here.
> ---
> arch/x86/pci/common.c | 27 +++++----------------------
> 1 file changed, 5 insertions(+), 22 deletions(-)
>
> --- linux-4.11.orig/arch/x86/pci/common.c 2017-05-01 04:47:48.000000000 +0200
> +++ linux-4.11/arch/x86/pci/common.c 2017-06-02 16:04:05.737889598 +0200
> @@ -24,7 +24,6 @@ unsigned int pci_probe = PCI_PROBE_BIOS
>
> unsigned int pci_early_dump_regs;
> static int pci_bf_sort;
> -static int smbios_type_b1_flag;
> int pci_routeirq;
> int noioapicquirk;
> #ifdef CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS
> @@ -197,34 +196,18 @@ static int __init set_bf_sort(const stru
> static void __init read_dmi_type_b1(const struct dmi_header *dm,
> void *private_data)
> {
> - u8 *d = (u8 *)dm + 4;
> + u8 *data = (u8 *)dm + 4;
>
> if (dm->type != 0xB1)
> return;
> - switch (((*(u32 *)d) >> 9) & 0x03) {
> - case 0x00:
> - printk(KERN_INFO "dmi type 0xB1 record - unknown flag\n");
> - break;
> - case 0x01: /* set pci=bfsort */
> - smbios_type_b1_flag = 1;
> - break;
> - case 0x02: /* do not set pci=bfsort */
> - smbios_type_b1_flag = 2;
> - break;
> - default:
> - break;
> - }
> + if ((((*(u32 *)data) >> 9) & 0x03) == 0x01)
> + set_bf_sort((const struct dmi_system_id *)private_data);
> }
>
> static int __init find_sort_method(const struct dmi_system_id *d)
> {
> - dmi_walk(read_dmi_type_b1, NULL);
> -
> - if (smbios_type_b1_flag == 1) {
> - set_bf_sort(d);
> - return 0;
> - }
> - return -1;
> + dmi_walk(read_dmi_type_b1, (void *)d);
> + return 0;
> }
>
> /*
>
> What do you think?
>
> Thanks,
> --
> Jean Delvare
> SUSE L3 Support
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: dmi type 0xB1 record - unknown flag
2017-06-15 21:39 ` Bjorn Helgaas
@ 2017-06-16 9:36 ` Narendra.K
2017-06-16 13:25 ` Jean Delvare
0 siblings, 1 reply; 9+ messages in thread
From: Narendra.K @ 2017-06-16 9:36 UTC (permalink / raw)
To: helgaas, jdelvare
Cc: x86, linux-pci, Jordan.Hargrave, Shyam.Iyer, bhelgaas, Narendra.K
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> Sent: Friday, June 16, 2017 3:10 AM
> To: Jean Delvare <jdelvare@suse.de>
> Cc: K, Narendra <Narendra_K@Dell.com>; x86@kernel.org; linux-
> pci@vger.kernel.org; Hargrave, Jordan <Jordan_Hargrave@Dell.com>; Iyer,
> Shyam <Shyam_Iyer@Dell.com>; bhelgaas@google.com
> Subject: Re: dmi type 0xB1 record - unknown flag
>=20
> On Fri, Jun 02, 2017 at 04:13:11PM +0200, Jean Delvare wrote:
> > ...
> > I think the whole thing can be simplified like this:
> >
> > From: Jean Delvare <jdelvare@suse.de>
> > Subject: x86/PCI: Simplify Dell DMI B1 quirk
> >
> > No need for such convoluted code, when all we need is to call one
> > function in one specific case.
> >
> > Signed-off-by: Jean Delvare <jdelvare@suse.de>
>=20
> Applied to pci/misc for v4.13, thanks!
>=20
> As far as I can tell, the new code is functionally equivalent to the old =
code, so
> I don't think there's any risk here.
>=20
Hi Jean/Bjorn,
Sorry for the delay. I applied the patch to the mainline kernel version 4.1=
2-rc5 and performed sanity test on a DellEMC PowerEdge R730XD system. It =
is working as=20
expected. 'dmesg' shows the message that 'pci=3Dbfsort' is enabled.
I also booted kernel version 4.12-rc5 with patch applied on a DellEMC Power=
Edge 1950 system which is listed in the ' pciprobe_dmi_table' quicks table.
It is working as expected and has not caused regression on this system. 'dm=
esg' shows the message that 'pci=3Dbfsort' is enabled.
[...]
> >
> > What do you think?
=20
Thank you for simplifying the code and for the patch.=20
With regards,
Narendra K
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dmi type 0xB1 record - unknown flag
2017-06-16 9:36 ` Narendra.K
@ 2017-06-16 13:25 ` Jean Delvare
0 siblings, 0 replies; 9+ messages in thread
From: Jean Delvare @ 2017-06-16 13:25 UTC (permalink / raw)
To: Narendra.K, helgaas; +Cc: x86, linux-pci, Jordan.Hargrave, Shyam.Iyer, bhelgaas
On ven., 2017-06-16 at 09:36 +0000, Narendra.K@dell.com wrote:
> Sorry for the delay. I applied the patch to the mainline kernel version 4.12-rc5 and performed sanity test on a DellEMC PowerEdge R730XD system. It is working as
> expected. 'dmesg' shows the message that 'pci=bfsort' is enabled.
>
> I also booted kernel version 4.12-rc5 with patch applied on a DellEMC PowerEdge 1950 system which is listed in the ' pciprobe_dmi_table' quicks table.
> It is working as expected and has not caused regression on this system. 'dmesg' shows the message that 'pci=bfsort' is enabled.
Thank you for testing it on real systems, this is very useful and
appreciated.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-06-16 13:25 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-01 12:38 dmi type 0xB1 record - unknown flag Jean Delvare
2017-06-01 13:28 ` Narendra.K
2017-06-01 16:59 ` Bjorn Helgaas
2017-06-02 9:47 ` Narendra.K
2017-06-02 14:13 ` Jean Delvare
2017-06-06 8:02 ` Narendra.K
2017-06-15 21:39 ` Bjorn Helgaas
2017-06-16 9:36 ` Narendra.K
2017-06-16 13:25 ` Jean Delvare
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.