| Message ID | 20200415072916.16293-1-ajd@linux.ibm.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | hw/phys-map: Fix OCAPI_MEM BAR values | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch master (e991415a88dbfd6c1690c5c2d8840288f45ec925) |
| snowpatch_ozlabs/snowpatch_job_snowpatch-skiboot | success | Test snowpatch/job/snowpatch-skiboot on branch master |
| snowpatch_ozlabs/snowpatch_job_snowpatch-skiboot-dco | success | Signed-off-by present |
Le 15/04/2020 à 09:29, Andrew Donnellan a écrit : > The comment next to the OCAPI_MEM entries in the Nimbus phys-map claims > that we are "varying the upper 2 bits of the group ID" for each OpenCAPI > link, as matches the chip address extension mask that will be set by future > versions of Hostboot. > > The actual entries, on the other hand, vary the *lower* 2 bits of the group > ID. Whoops. > > This didn't appear to cause us problems on the specific machines that we > had access to at the time, but now that this is being tested a bit harder > it's crashing machines... > > Fixes: bc72973d13215 ("hw/npu2-opencapi: Support multiple LPC devices") > Cc: Frederic Barrat <fbarrat@linux.ibm.com> > Reported-by: Wael El-Essawy <welessa@us.ibm.com> > Reported-by: Milton Miller <miltonm@us.ibm.com> > Reported-by: Jenny Huynh <jhuynh@us.ibm.com> > Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> > --- I could probably have read the code a zillion times and still not see it... Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> > hw/phys-map.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/hw/phys-map.c b/hw/phys-map.c > index ad041738f0de..2c4d8e45f708 100644 > --- a/hw/phys-map.c > +++ b/hw/phys-map.c > @@ -53,9 +53,9 @@ static const struct phys_map_entry phys_map_table_nimbus[] = { > * We don't currently support >4TB ranges. > */ > { OCAPI_MEM, 0, 0x0002000000000000ull, 0x0000040000000000ull }, > - { OCAPI_MEM, 1, 0x0002200000000000ull, 0x0000040000000000ull }, > - { OCAPI_MEM, 2, 0x0002400000000000ull, 0x0000040000000000ull }, > - { OCAPI_MEM, 3, 0x0002600000000000ull, 0x0000040000000000ull }, > + { OCAPI_MEM, 1, 0x0002800000000000ull, 0x0000040000000000ull }, > + { OCAPI_MEM, 2, 0x0003000000000000ull, 0x0000040000000000ull }, > + { OCAPI_MEM, 3, 0x0003800000000000ull, 0x0000040000000000ull }, > > /* 0 TB offset @ MMIO 0x0006000000000000ull */ > { PHB4_64BIT_MMIO, 0, 0x0006000000000000ull, 0x0000004000000000ull }, >
[+ skiboot stable] On 23/4/20 5:13 pm, Frederic Barrat wrote: > > > Le 15/04/2020 à 09:29, Andrew Donnellan a écrit : >> The comment next to the OCAPI_MEM entries in the Nimbus phys-map claims >> that we are "varying the upper 2 bits of the group ID" for each OpenCAPI >> link, as matches the chip address extension mask that will be set by >> future >> versions of Hostboot. >> >> The actual entries, on the other hand, vary the *lower* 2 bits of the >> group >> ID. Whoops. >> >> This didn't appear to cause us problems on the specific machines that we >> had access to at the time, but now that this is being tested a bit harder >> it's crashing machines... >> >> Fixes: bc72973d13215 ("hw/npu2-opencapi: Support multiple LPC devices") >> Cc: Frederic Barrat <fbarrat@linux.ibm.com> >> Reported-by: Wael El-Essawy <welessa@us.ibm.com> >> Reported-by: Milton Miller <miltonm@us.ibm.com> >> Reported-by: Jenny Huynh <jhuynh@us.ibm.com> >> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> >> --- > > > I could probably have read the code a zillion times and still not see it... > Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Thanks. Now that 6.6 has been tagged without this patch included, could this be picked up for 6.6.1? Andrew > > >> hw/phys-map.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/hw/phys-map.c b/hw/phys-map.c >> index ad041738f0de..2c4d8e45f708 100644 >> --- a/hw/phys-map.c >> +++ b/hw/phys-map.c >> @@ -53,9 +53,9 @@ static const struct phys_map_entry >> phys_map_table_nimbus[] = { >> * We don't currently support >4TB ranges. >> */ >> { OCAPI_MEM, 0, 0x0002000000000000ull, >> 0x0000040000000000ull }, >> - { OCAPI_MEM, 1, 0x0002200000000000ull, >> 0x0000040000000000ull }, >> - { OCAPI_MEM, 2, 0x0002400000000000ull, >> 0x0000040000000000ull }, >> - { OCAPI_MEM, 3, 0x0002600000000000ull, >> 0x0000040000000000ull }, >> + { OCAPI_MEM, 1, 0x0002800000000000ull, >> 0x0000040000000000ull }, >> + { OCAPI_MEM, 2, 0x0003000000000000ull, >> 0x0000040000000000ull }, >> + { OCAPI_MEM, 3, 0x0003800000000000ull, >> 0x0000040000000000ull }, >> /* 0 TB offset @ MMIO 0x0006000000000000ull */ >> { PHB4_64BIT_MMIO, 0, 0x0006000000000000ull, >> 0x0000004000000000ull }, >>
On Wed, Apr 15, 2020 at 5:32 PM Andrew Donnellan <ajd@linux.ibm.com> wrote: > > The comment next to the OCAPI_MEM entries in the Nimbus phys-map claims > that we are "varying the upper 2 bits of the group ID" for each OpenCAPI > link, as matches the chip address extension mask that will be set by future > versions of Hostboot. > > The actual entries, on the other hand, vary the *lower* 2 bits of the group > ID. Whoops. > > This didn't appear to cause us problems on the specific machines that we > had access to at the time, but now that this is being tested a bit harder > it's crashing machines... > > Fixes: bc72973d13215 ("hw/npu2-opencapi: Support multiple LPC devices") > Cc: Frederic Barrat <fbarrat@linux.ibm.com> > Reported-by: Wael El-Essawy <welessa@us.ibm.com> > Reported-by: Milton Miller <miltonm@us.ibm.com> > Reported-by: Jenny Huynh <jhuynh@us.ibm.com> > Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Thanks, merged as 75198f668911830bb5df27da59786199eac2e47c
diff --git a/hw/phys-map.c b/hw/phys-map.c index ad041738f0de..2c4d8e45f708 100644 --- a/hw/phys-map.c +++ b/hw/phys-map.c @@ -53,9 +53,9 @@ static const struct phys_map_entry phys_map_table_nimbus[] = { * We don't currently support >4TB ranges. */ { OCAPI_MEM, 0, 0x0002000000000000ull, 0x0000040000000000ull }, - { OCAPI_MEM, 1, 0x0002200000000000ull, 0x0000040000000000ull }, - { OCAPI_MEM, 2, 0x0002400000000000ull, 0x0000040000000000ull }, - { OCAPI_MEM, 3, 0x0002600000000000ull, 0x0000040000000000ull }, + { OCAPI_MEM, 1, 0x0002800000000000ull, 0x0000040000000000ull }, + { OCAPI_MEM, 2, 0x0003000000000000ull, 0x0000040000000000ull }, + { OCAPI_MEM, 3, 0x0003800000000000ull, 0x0000040000000000ull }, /* 0 TB offset @ MMIO 0x0006000000000000ull */ { PHB4_64BIT_MMIO, 0, 0x0006000000000000ull, 0x0000004000000000ull },
The comment next to the OCAPI_MEM entries in the Nimbus phys-map claims that we are "varying the upper 2 bits of the group ID" for each OpenCAPI link, as matches the chip address extension mask that will be set by future versions of Hostboot. The actual entries, on the other hand, vary the *lower* 2 bits of the group ID. Whoops. This didn't appear to cause us problems on the specific machines that we had access to at the time, but now that this is being tested a bit harder it's crashing machines... Fixes: bc72973d13215 ("hw/npu2-opencapi: Support multiple LPC devices") Cc: Frederic Barrat <fbarrat@linux.ibm.com> Reported-by: Wael El-Essawy <welessa@us.ibm.com> Reported-by: Milton Miller <miltonm@us.ibm.com> Reported-by: Jenny Huynh <jhuynh@us.ibm.com> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> --- hw/phys-map.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)