Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1629827

Re: [PATCH V15 04/11] efi: parse ARM processor error

Show all headers | View raw

On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote:
> I guess it's not really needed. It just may be useful considering there can
> be numerous error info structures, numerous context info structures, and a
> variable length vendor information section. I can move this print to only in
> the length check failure cases.

And? Why does the user care?

I mean, it is good for debugging when you wanna see you're parsing the
error info data properly but otherwise it doesn't improve the error
reporting one bit.

> Because these are part of the error information structure. I wouldn't think
> FW would populate error information structures that are different versions
> in the same processor error, but it could be possible from the spec (at
> least once there are different versions of the table).

Same argument as above.

> There is an error information 64 bit value in the ARM processor error
> information structure. (UEFI spec 2.6 table 261)

So that's IP-dependent and explained in the following tables. Any plans
on decoding that too?

> Why's that? Dumping this vendor specific error information is similar to the
> unrecognized CPER section reporting which is also meant for vendor specific
> information https://lkml.org/lkml/2017/4/18/751

And how do those naked bytes help the user understand the error happening?

Even in your example you have:

[  140.739210] {1}[Hardware Error]:   00000000: 4d415201 4d492031 453a4d45 435f4343  .RAM1 IMEM:ECC_C
[  140.739214] {1}[Hardware Error]:   00000010: 53515f45 44525f42 00000000 00000000  E_QSB_RD........

Which looks like some correctable ECC DRAM error and is actually begging
to be decoded in a human-readable form. So let's do that completely and
not dump partially decoded information.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH V15 00/11] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64 Tyler Baicar <tbaicar@codeaurora.org> - 2017-04-19 01:10 +0200
  [PATCH V15 04/11] efi: parse ARM processor error Tyler Baicar <tbaicar@codeaurora.org> - 2017-04-19 01:10 +0200
    Re: [PATCH V15 04/11] efi: parse ARM processor error Borislav Petkov <bp@alien8.de> - 2017-04-21 20:30 +0200
      Re: [PATCH V15 04/11] efi: parse ARM processor error "Baicar, Tyler" <tbaicar@codeaurora.org> - 2017-04-21 20:30 +0200
        Re: [PATCH V15 04/11] efi: parse ARM processor error Borislav Petkov <bp@alien8.de> - 2017-04-24 20:00 +0200
          Re: [PATCH V15 04/11] efi: parse ARM processor error "Baicar, Tyler" <tbaicar@codeaurora.org> - 2017-04-25 18:10 +0200
            Re: [PATCH V15 04/11] efi: parse ARM processor error Borislav Petkov <bp@alien8.de> - 2017-04-25 18:40 +0200
  [PATCH V15 05/11] arm64: exception: handle Synchronous External Abort Tyler Baicar <tbaicar@codeaurora.org> - 2017-04-19 01:10 +0200
  [PATCH V15 03/11] cper: add timestamp print to CPER status printing Tyler Baicar <tbaicar@codeaurora.org> - 2017-04-19 01:20 +0200
    Re: [PATCH V15 03/11] cper: add timestamp print to CPER status  printing Borislav Petkov <bp@alien8.de> - 2017-04-21 14:30 +0200
      Re: [PATCH V15 03/11] cper: add timestamp print to CPER status  printing Borislav Petkov <bp@alien8.de> - 2017-04-21 20:20 +0200
        Re: [PATCH V15 03/11] cper: add timestamp print to CPER status  printing "Baicar, Tyler" <tbaicar@codeaurora.org> - 2017-04-21 20:20 +0200
          Re: [PATCH V15 03/11] cper: add timestamp print to CPER status  printing Borislav Petkov <bp@alien8.de> - 2017-04-21 20:30 +0200
      Re: [PATCH V15 03/11] cper: add timestamp print to CPER status  printing "Baicar, Tyler" <tbaicar@codeaurora.org> - 2017-04-21 20:50 +0200

csiph-web