Re: Shorten efi regions output
On Wed, 21 Jan, at 11:06:33AM, Borislav Petkov wrote: > On Wed, Jan 21, 2015 at 12:48:58AM -0500, Jon Masters wrote: > > We have on a number of occasions found just this output useful in > > debugging boot issues on ARM servers > > We can turn it on by default on ARM and off on x86... Yeah, there's no reason we need to have the same default. That is to say, it can be on for ARM and off for x86, but when enabled the format should be the same for both. In the future the memory maps are likely to contain even more entries and I suspect we're going to get more requests to disable the voluminous memmap output by default if we don't do so now. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On Wed, 21 Jan, at 11:06:33AM, Borislav Petkov wrote: On Wed, Jan 21, 2015 at 12:48:58AM -0500, Jon Masters wrote: We have on a number of occasions found just this output useful in debugging boot issues on ARM servers We can turn it on by default on ARM and off on x86... Yeah, there's no reason we need to have the same default. That is to say, it can be on for ARM and off for x86, but when enabled the format should be the same for both. In the future the memory maps are likely to contain even more entries and I suspect we're going to get more requests to disable the voluminous memmap output by default if we don't do so now. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On Wed, Jan 21, 2015 at 12:48:58AM -0500, Jon Masters wrote: > We have on a number of occasions found just this output useful in > debugging boot issues on ARM servers We can turn it on by default on ARM and off on x86... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On Wed, Jan 21, 2015 at 12:48:58AM -0500, Jon Masters wrote: We have on a number of occasions found just this output useful in debugging boot issues on ARM servers We can turn it on by default on ARM and off on x86... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 1/5/15, 10:00 AM, Laszlo Ersek wrote: On 01/05/15 15:03, Matt Fleming wrote: On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote: On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: I have same feeling with you, it is too long for most of people. Since the printk code are for EFI_DEBUG, they are around the #ifdef so I would like to see a kernel param like efi_debug=on, so only efi_debug is specified then these verbose messages are printed. Without the param kernel can print some basic infomation about the memory ranges. In arm64 code there's already a uefi_debug param it can be moved to general code so that there will be a goable switch. Hmm, makes sense to me. Maybe we should really hide those behind a debug switch, the question is whether asking the user to boot with "efi_debug=on" in order to see the regions is ok. And I think it is ok because we do that when debugging other stuff so I don't see anything different here. And then when they're disabled by default, we don't really need to shorten them as they're pure debug output then. Matt? I'm fine with disabling the EFI memory output regions by default. Printing the regions is still useful for debugging, but like you mention, we frequently ask users to enable other debug options when tracking down issues. Laszlo, would you be OK with that? Sure. Pardon my intrusion into this thread (just going over the past month's LKML for things I missed). I'd like to see some map output by default in the kernel. We have on a number of occasions found just this output useful in debugging boot issues on ARM servers and I suspect that will remain the case over the coming months. Sure, you can always tell someone to reboot, but then you have to rely on them doing it. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 1/5/15, 10:00 AM, Laszlo Ersek wrote: On 01/05/15 15:03, Matt Fleming wrote: On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote: On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: I have same feeling with you, it is too long for most of people. Since the printk code are for EFI_DEBUG, they are around the #ifdef so I would like to see a kernel param like efi_debug=on, so only efi_debug is specified then these verbose messages are printed. Without the param kernel can print some basic infomation about the memory ranges. In arm64 code there's already a uefi_debug param it can be moved to general code so that there will be a goable switch. Hmm, makes sense to me. Maybe we should really hide those behind a debug switch, the question is whether asking the user to boot with efi_debug=on in order to see the regions is ok. And I think it is ok because we do that when debugging other stuff so I don't see anything different here. And then when they're disabled by default, we don't really need to shorten them as they're pure debug output then. Matt? I'm fine with disabling the EFI memory output regions by default. Printing the regions is still useful for debugging, but like you mention, we frequently ask users to enable other debug options when tracking down issues. Laszlo, would you be OK with that? Sure. Pardon my intrusion into this thread (just going over the past month's LKML for things I missed). I'd like to see some map output by default in the kernel. We have on a number of occasions found just this output useful in debugging boot issues on ARM servers and I suspect that will remain the case over the coming months. Sure, you can always tell someone to reboot, but then you have to rely on them doing it. Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 01/05/15 15:03, Matt Fleming wrote: > On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote: >> On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: >>> I have same feeling with you, it is too long for most of people. >>> >>> Since the printk code are for EFI_DEBUG, they are around the #ifdef >>> so I would like to see a kernel param like efi_debug=on, so only >>> efi_debug is specified then these verbose messages are printed. >>> Without the param kernel can print some basic infomation about the >>> memory ranges. >>> >>> In arm64 code there's already a uefi_debug param it can be moved to >>> general code so that there will be a goable switch. >> >> Hmm, makes sense to me. Maybe we should really hide those behind a >> debug switch, the question is whether asking the user to boot with >> "efi_debug=on" in order to see the regions is ok. And I think it is ok >> because we do that when debugging other stuff so I don't see anything >> different here. >> >> And then when they're disabled by default, we don't really need to >> shorten them as they're pure debug output then. >> >> Matt? > > I'm fine with disabling the EFI memory output regions by default. > > Printing the regions is still useful for debugging, but like you > mention, we frequently ask users to enable other debug options when > tracking down issues. > > Laszlo, would you be OK with that? Sure. Thanks Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote: > On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: > > I have same feeling with you, it is too long for most of people. > > > > Since the printk code are for EFI_DEBUG, they are around the #ifdef > > so I would like to see a kernel param like efi_debug=on, so only > > efi_debug is specified then these verbose messages are printed. > > Without the param kernel can print some basic infomation about the > > memory ranges. > > > > In arm64 code there's already a uefi_debug param it can be moved to > > general code so that there will be a goable switch. > > Hmm, makes sense to me. Maybe we should really hide those behind a > debug switch, the question is whether asking the user to boot with > "efi_debug=on" in order to see the regions is ok. And I think it is ok > because we do that when debugging other stuff so I don't see anything > different here. > > And then when they're disabled by default, we don't really need to > shorten them as they're pure debug output then. > > Matt? I'm fine with disabling the EFI memory output regions by default. Printing the regions is still useful for debugging, but like you mention, we frequently ask users to enable other debug options when tracking down issues. Laszlo, would you be OK with that? -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote: On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: I have same feeling with you, it is too long for most of people. Since the printk code are for EFI_DEBUG, they are around the #ifdef so I would like to see a kernel param like efi_debug=on, so only efi_debug is specified then these verbose messages are printed. Without the param kernel can print some basic infomation about the memory ranges. In arm64 code there's already a uefi_debug param it can be moved to general code so that there will be a goable switch. Hmm, makes sense to me. Maybe we should really hide those behind a debug switch, the question is whether asking the user to boot with efi_debug=on in order to see the regions is ok. And I think it is ok because we do that when debugging other stuff so I don't see anything different here. And then when they're disabled by default, we don't really need to shorten them as they're pure debug output then. Matt? I'm fine with disabling the EFI memory output regions by default. Printing the regions is still useful for debugging, but like you mention, we frequently ask users to enable other debug options when tracking down issues. Laszlo, would you be OK with that? -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 01/05/15 15:03, Matt Fleming wrote: On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote: On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: I have same feeling with you, it is too long for most of people. Since the printk code are for EFI_DEBUG, they are around the #ifdef so I would like to see a kernel param like efi_debug=on, so only efi_debug is specified then these verbose messages are printed. Without the param kernel can print some basic infomation about the memory ranges. In arm64 code there's already a uefi_debug param it can be moved to general code so that there will be a goable switch. Hmm, makes sense to me. Maybe we should really hide those behind a debug switch, the question is whether asking the user to boot with efi_debug=on in order to see the regions is ok. And I think it is ok because we do that when debugging other stuff so I don't see anything different here. And then when they're disabled by default, we don't really need to shorten them as they're pure debug output then. Matt? I'm fine with disabling the EFI memory output regions by default. Printing the regions is still useful for debugging, but like you mention, we frequently ask users to enable other debug options when tracking down issues. Laszlo, would you be OK with that? Sure. Thanks Laszlo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: > I have same feeling with you, it is too long for most of people. > > Since the printk code are for EFI_DEBUG, they are around the #ifdef > so I would like to see a kernel param like efi_debug=on, so only > efi_debug is specified then these verbose messages are printed. > Without the param kernel can print some basic infomation about the > memory ranges. > > In arm64 code there's already a uefi_debug param it can be moved to > general code so that there will be a goable switch. Hmm, makes sense to me. Maybe we should really hide those behind a debug switch, the question is whether asking the user to boot with "efi_debug=on" in order to see the regions is ok. And I think it is ok because we do that when debugging other stuff so I don't see anything different here. And then when they're disabled by default, we don't really need to shorten them as they're pure debug output then. Matt? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: I have same feeling with you, it is too long for most of people. Since the printk code are for EFI_DEBUG, they are around the #ifdef so I would like to see a kernel param like efi_debug=on, so only efi_debug is specified then these verbose messages are printed. Without the param kernel can print some basic infomation about the memory ranges. In arm64 code there's already a uefi_debug param it can be moved to general code so that there will be a goable switch. Hmm, makes sense to me. Maybe we should really hide those behind a debug switch, the question is whether asking the user to boot with efi_debug=on in order to see the regions is ok. And I think it is ok because we do that when debugging other stuff so I don't see anything different here. And then when they're disabled by default, we don't really need to shorten them as they're pure debug output then. Matt? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 12/09/14 at 10:58am, Borislav Petkov wrote: > Hi guys, > > so this decoded EFI regions output is nice but can we shorten it? It > sticks too far out in the terminal more than anything else in dmesg and > staring at it needs me to resize window and such. It probably is an even > bigger problem if one's monitor hasn't switched to higher res early > during boot. I have same feeling with you, it is too long for most of people. Since the printk code are for EFI_DEBUG, they are around the #ifdef so I would like to see a kernel param like efi_debug=on, so only efi_debug is specified then these verbose messages are printed. Without the param kernel can print some basic infomation about the memory ranges. In arm64 code there's already a uefi_debug param it can be moved to general code so that there will be a goable switch. > > So here's what I'm seeing with the latest EDKII: > > [0.00] efi: EFI v2.40 by EDK II > [0.00] efi: ACPI=0x7ff2d000 ACPI 2.0=0x7ff2d014 > [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x-0x1000) (0MB) > [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x1000-0x2000) (0MB) > [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x2000-0x0009f000) (0MB) > [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0009f000-0x000a) (0MB) > [0.00] efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x0010-0x0082) (7MB) > [0.00] efi: mem05: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x0082-0x0100) (7MB) > [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0100-0x03cbc000) (44MB) > [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x03cbc000-0x0400) (3MB) > [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0400-0x05cbc000) (28MB) > [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x05cbc000-0x3fffc000) (931MB) > [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x3fffc000-0x4000) (0MB) > [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x4000-0x7c00) (960MB) > [0.00] efi: mem12: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7c00-0x7c02) (0MB) > [0.00] efi: mem13: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x7c02-0x7ebc5000) (43MB) > [0.00] efi: mem14: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ebc5000-0x7ebfe000) (0MB) > [0.00] efi: mem15: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ebfe000-0x7ebff000) (0MB) > [0.00] efi: mem16: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x7ebff000-0x7ec03000) (0MB) > [0.00] efi: mem17: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec03000-0x7ec05000) (0MB) > [0.00] efi: mem18: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ec05000-0x7ec06000) (0MB) > [0.00] efi: mem19: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec06000-0x7ec07000) (0MB) > [0.00] efi: mem20: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ec07000-0x7ec08000) (0MB) > [0.00] efi: mem21: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec08000-0x7ece7000) (0MB) > [0.00] efi: mem22: [Boot Code | | | | | |WB|WT|WC|UC] > range=[0x7ece7000-0x7ee3b000) (1MB) > [0.00] efi: mem23: [Runtime Data |RUN| | | | |WB|WT|WC|UC] > range=[0x7ee3b000-0x7ee4e000) (0MB) > [0.00] efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ee4e000-0x7fd4e000) (15MB) > [0.00] efi: mem25: [Boot Code | | | | | |WB|WT|WC|UC] > range=[0x7fd4e000-0x7fece000) (1MB) > [0.00] efi: mem26: [Runtime Code |RUN| | | | |WB|WT|WC|UC] > range=[0x7fece000-0x7fefe000) (0MB) > [0.00] efi: mem27: [Runtime Data |RUN| | | | |WB|WT|WC|UC] > range=[0x7fefe000-0x7ff22000) (0MB) > [0.00] efi: mem28: [Reserved | | | | | |WB|WT|WC|UC] > range=[0x7ff22000-0x7ff26000) (0MB) > [0.00] efi: mem29: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC]
Re: Shorten efi regions output
On Tue, Dec 09, 2014 at 04:35:33PM +0100, Laszlo Ersek wrote: > I disagree with the patch in general, and I strongly disagree with this > specific change in particular. This part: > > - breaks the alignment for the right side of the table Well, we can start by removing the sizes - they're useless anyway and can be computed with a simple awk script or whatever. I.e., ... [0.00] efi: mem23: [0x7ee3b000-0x7ee4e000) [RtData |RT|WB|WT|WC|UC]) [0.00] efi: mem24: [0x7ee4e000-0x7fd4e000) [BootData |WB|WT|WC|UC] [0.00] efi: mem25: [0x7fd4e000-0x7fece000) [BootCode |WB|WT|WC|UC] [0.00] efi: mem26: [0x7fece000-0x7fefe000) [RtCode |RT|WB|WT|WC|UC] [0.00] efi: mem27: [0x7fefe000-0x7ff22000) [RtData |RT|WB|WT|WC|UC] ... Then we could do some more work like fishing out columns and removing those which are not set in any region from the output completely and then have alignment but with only the relevant fields, ... > - completely defeats another of my goals with the original patch, which > was to be able to get an overview of memory attributes *at a glance*. > That only works if each column is strictly associated with one bit, > and your gaze can slide over empty stretches. Well, and empty column doesn't tell me a whole lot, does it? [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) I still have to go and look up what those 5 empty bits mean. Thus my angle was: if it is not set, don't print it. > Please compare how you visually execute a search for the next > runtime region (or the next non-WB line) before and after. I'd look for region names RtData/RtCode. Unless this dump is supposed to be used to sanity-check region attribute flags too, then I see your point about the alignment. > Your patch shaves off 30 characters of the width if I measured it right > (goes from 131 to 101.) I don't believe that would justify breaking the > alignment of the columns. For example, you could remove 15 characters > from the right just with "dmesg -t" (timestamps are probably not overly > important for printing the memmap). Yeah, but you can look at that output with other means, i.e. serial console/netconsole/guest boot log, etc. > Anyway it's a matter of taste. I know you work with this every day so if > it doesn't meet your needs then I won't insist preserving it. I won't > NACK the patch it but I certainly won't ACK it either. Ok, fair enough. Let's see what the others think. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 12/09/14 10:58, Borislav Petkov wrote: > Hi guys, > > so this decoded EFI regions output is nice but can we shorten it? It > sticks too far out in the terminal more than anything else in dmesg and > staring at it needs me to resize window and such. It probably is an even > bigger problem if one's monitor hasn't switched to higher res early > during boot. > > So here's what I'm seeing with the latest EDKII: > > [0.00] efi: EFI v2.40 by EDK II > [0.00] efi: ACPI=0x7ff2d000 ACPI 2.0=0x7ff2d014 > [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x-0x1000) (0MB) > [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x1000-0x2000) (0MB) > [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x2000-0x0009f000) (0MB) > [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0009f000-0x000a) (0MB) > [0.00] efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x0010-0x0082) (7MB) > [0.00] efi: mem05: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x0082-0x0100) (7MB) > [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0100-0x03cbc000) (44MB) > [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x03cbc000-0x0400) (3MB) > [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0400-0x05cbc000) (28MB) > [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x05cbc000-0x3fffc000) (931MB) > [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x3fffc000-0x4000) (0MB) > [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x4000-0x7c00) (960MB) > [0.00] efi: mem12: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7c00-0x7c02) (0MB) > [0.00] efi: mem13: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x7c02-0x7ebc5000) (43MB) > [0.00] efi: mem14: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ebc5000-0x7ebfe000) (0MB) > [0.00] efi: mem15: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ebfe000-0x7ebff000) (0MB) > [0.00] efi: mem16: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x7ebff000-0x7ec03000) (0MB) > [0.00] efi: mem17: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec03000-0x7ec05000) (0MB) > [0.00] efi: mem18: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ec05000-0x7ec06000) (0MB) > [0.00] efi: mem19: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec06000-0x7ec07000) (0MB) > [0.00] efi: mem20: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ec07000-0x7ec08000) (0MB) > [0.00] efi: mem21: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec08000-0x7ece7000) (0MB) > [0.00] efi: mem22: [Boot Code | | | | | |WB|WT|WC|UC] > range=[0x7ece7000-0x7ee3b000) (1MB) > [0.00] efi: mem23: [Runtime Data |RUN| | | | |WB|WT|WC|UC] > range=[0x7ee3b000-0x7ee4e000) (0MB) > [0.00] efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ee4e000-0x7fd4e000) (15MB) > [0.00] efi: mem25: [Boot Code | | | | | |WB|WT|WC|UC] > range=[0x7fd4e000-0x7fece000) (1MB) > [0.00] efi: mem26: [Runtime Code |RUN| | | | |WB|WT|WC|UC] > range=[0x7fece000-0x7fefe000) (0MB) > [0.00] efi: mem27: [Runtime Data |RUN| | | | |WB|WT|WC|UC] > range=[0x7fefe000-0x7ff22000) (0MB) > [0.00] efi: mem28: [Reserved | | | | | |WB|WT|WC|UC] > range=[0x7ff22000-0x7ff26000) (0MB) > [0.00] efi: mem29: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] > range=[0x7ff26000-0x7ff2e000) (0MB) > [0.00] efi: mem30: [ACPI Memory NVS| | | | | |WB|WT|WC|UC] > range=[0x7ff2e000-0x7ff32000) (0MB) > [0.00] efi: mem31: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ff32000-0x7ffd) (0MB) > [0.00] efi: mem32: [Runtime Data |RUN| | | | |WB|WT|WC|UC] > range=[0x7ffd-0x8000) (0MB) > [
Re: Shorten efi regions output
On Tue, Dec 09, 2014 at 01:42:44PM +0100, Ard Biesheuvel wrote: > The |] thing is easily fixed, though. > > [...] > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > > index 8590099ac148..6734072980ee 100644 > > --- a/drivers/firmware/efi/efi.c > > +++ b/drivers/firmware/efi/efi.c > [...] > > @@ -490,15 +490,15 @@ char * __init efi_md_typeattr_format(char *buf, > > size_t size, > > snprintf(pos, size, "|attr=0x%016llx]", > > (unsigned long long)attr); > > else > > - snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]", > > -attr & EFI_MEMORY_RUNTIME ? "RUN" : "", > > -attr & EFI_MEMORY_XP ? "XP" : "", > > -attr & EFI_MEMORY_RP ? "RP" : "", > > -attr & EFI_MEMORY_WP ? "WP" : "", > > -attr & EFI_MEMORY_UCE ? "UCE" : "", > > -attr & EFI_MEMORY_WB ? "WB" : "", > > -attr & EFI_MEMORY_WT ? "WT" : "", > > -attr & EFI_MEMORY_WC ? "WC" : "", > > -attr & EFI_MEMORY_UC ? "UC" : ""); > > + snprintf(pos, size, "|%s%s%s%s%s%s%s%s%s]", > > Drop the leading | here > > > +attr & EFI_MEMORY_RUNTIME ? "RT|" : "", > > +attr & EFI_MEMORY_XP ? "XP|" : "", > > +attr & EFI_MEMORY_RP ? "RP|" : "", > > +attr & EFI_MEMORY_WP ? "WP|" : "", > > +attr & EFI_MEMORY_UCE ? "UCE|" : "", > > +attr & EFI_MEMORY_WB ? "WB|" : "", > > +attr & EFI_MEMORY_WT ? "WT|" : "", > > +attr & EFI_MEMORY_WC ? "WC|" : "", > > +attr & EFI_MEMORY_UC ? "UC" : ""); > > and move all the | to the beginning of the string here, including "UC" Haha, of course! :-) /me slaps forehead. Thanks! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 9 December 2014 at 10:58, Borislav Petkov wrote: > Hi guys, > > so this decoded EFI regions output is nice but can we shorten it? It > sticks too far out in the terminal more than anything else in dmesg and > staring at it needs me to resize window and such. It probably is an even > bigger problem if one's monitor hasn't switched to higher res early > during boot. > > So here's what I'm seeing with the latest EDKII: > > [0.00] efi: EFI v2.40 by EDK II > [0.00] efi: ACPI=0x7ff2d000 ACPI 2.0=0x7ff2d014 > [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x-0x1000) (0MB) > [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x1000-0x2000) (0MB) > [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x2000-0x0009f000) (0MB) > [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0009f000-0x000a) (0MB) > [0.00] efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x0010-0x0082) (7MB) > [0.00] efi: mem05: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x0082-0x0100) (7MB) > [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0100-0x03cbc000) (44MB) > [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x03cbc000-0x0400) (3MB) > [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x0400-0x05cbc000) (28MB) > [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x05cbc000-0x3fffc000) (931MB) > [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x3fffc000-0x4000) (0MB) > [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x4000-0x7c00) (960MB) > [0.00] efi: mem12: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7c00-0x7c02) (0MB) > [0.00] efi: mem13: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x7c02-0x7ebc5000) (43MB) > [0.00] efi: mem14: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ebc5000-0x7ebfe000) (0MB) > [0.00] efi: mem15: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ebfe000-0x7ebff000) (0MB) > [0.00] efi: mem16: [Conventional Memory| | | | | |WB|WT|WC|UC] > range=[0x7ebff000-0x7ec03000) (0MB) > [0.00] efi: mem17: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec03000-0x7ec05000) (0MB) > [0.00] efi: mem18: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ec05000-0x7ec06000) (0MB) > [0.00] efi: mem19: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec06000-0x7ec07000) (0MB) > [0.00] efi: mem20: [Loader Data| | | | | |WB|WT|WC|UC] > range=[0x7ec07000-0x7ec08000) (0MB) > [0.00] efi: mem21: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ec08000-0x7ece7000) (0MB) > [0.00] efi: mem22: [Boot Code | | | | | |WB|WT|WC|UC] > range=[0x7ece7000-0x7ee3b000) (1MB) > [0.00] efi: mem23: [Runtime Data |RUN| | | | |WB|WT|WC|UC] > range=[0x7ee3b000-0x7ee4e000) (0MB) > [0.00] efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ee4e000-0x7fd4e000) (15MB) > [0.00] efi: mem25: [Boot Code | | | | | |WB|WT|WC|UC] > range=[0x7fd4e000-0x7fece000) (1MB) > [0.00] efi: mem26: [Runtime Code |RUN| | | | |WB|WT|WC|UC] > range=[0x7fece000-0x7fefe000) (0MB) > [0.00] efi: mem27: [Runtime Data |RUN| | | | |WB|WT|WC|UC] > range=[0x7fefe000-0x7ff22000) (0MB) > [0.00] efi: mem28: [Reserved | | | | | |WB|WT|WC|UC] > range=[0x7ff22000-0x7ff26000) (0MB) > [0.00] efi: mem29: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] > range=[0x7ff26000-0x7ff2e000) (0MB) > [0.00] efi: mem30: [ACPI Memory NVS| | | | | |WB|WT|WC|UC] > range=[0x7ff2e000-0x7ff32000) (0MB) > [0.00] efi: mem31: [Boot Data | | | | | |WB|WT|WC|UC] > range=[0x7ff32000-0x7ffd) (0MB) > [0.00] efi: mem32: [Runtime Data |RUN| | | | |WB|WT|WC|UC] > range=[0x7ffd-0x8000) (0MB) > [
Shorten efi regions output
Hi guys, so this decoded EFI regions output is nice but can we shorten it? It sticks too far out in the terminal more than anything else in dmesg and staring at it needs me to resize window and such. It probably is an even bigger problem if one's monitor hasn't switched to higher res early during boot. So here's what I'm seeing with the latest EDKII: [0.00] efi: EFI v2.40 by EDK II [0.00] efi: ACPI=0x7ff2d000 ACPI 2.0=0x7ff2d014 [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x1000-0x2000) (0MB) [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x2000-0x0009f000) (0MB) [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0009f000-0x000a) (0MB) [0.00] efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0010-0x0082) (7MB) [0.00] efi: mem05: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0082-0x0100) (7MB) [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0100-0x03cbc000) (44MB) [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x03cbc000-0x0400) (3MB) [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0400-0x05cbc000) (28MB) [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x05cbc000-0x3fffc000) (931MB) [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x3fffc000-0x4000) (0MB) [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x4000-0x7c00) (960MB) [0.00] efi: mem12: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7c00-0x7c02) (0MB) [0.00] efi: mem13: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7c02-0x7ebc5000) (43MB) [0.00] efi: mem14: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ebc5000-0x7ebfe000) (0MB) [0.00] efi: mem15: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ebfe000-0x7ebff000) (0MB) [0.00] efi: mem16: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7ebff000-0x7ec03000) (0MB) [0.00] efi: mem17: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec03000-0x7ec05000) (0MB) [0.00] efi: mem18: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec05000-0x7ec06000) (0MB) [0.00] efi: mem19: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec06000-0x7ec07000) (0MB) [0.00] efi: mem20: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec07000-0x7ec08000) (0MB) [0.00] efi: mem21: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec08000-0x7ece7000) (0MB) [0.00] efi: mem22: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7ece7000-0x7ee3b000) (1MB) [0.00] efi: mem23: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ee3b000-0x7ee4e000) (0MB) [0.00] efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ee4e000-0x7fd4e000) (15MB) [0.00] efi: mem25: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7fd4e000-0x7fece000) (1MB) [0.00] efi: mem26: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x7fece000-0x7fefe000) (0MB) [0.00] efi: mem27: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7fefe000-0x7ff22000) (0MB) [0.00] efi: mem28: [Reserved | | | | | |WB|WT|WC|UC] range=[0x7ff22000-0x7ff26000) (0MB) [0.00] efi: mem29: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] range=[0x7ff26000-0x7ff2e000) (0MB) [0.00] efi: mem30: [ACPI Memory NVS| | | | | |WB|WT|WC|UC] range=[0x7ff2e000-0x7ff32000) (0MB) [0.00] efi: mem31: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ff32000-0x7ffd) (0MB) [0.00] efi: mem32: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ffd-0x8000) (0MB) [0.00] efi: mem33: [Runtime Data |RUN| | | | | | | |UC] range=[0xfff0-0x0001) (1MB) and here's with the proposed changes: * regions get printed first so that
Shorten efi regions output
Hi guys, so this decoded EFI regions output is nice but can we shorten it? It sticks too far out in the terminal more than anything else in dmesg and staring at it needs me to resize window and such. It probably is an even bigger problem if one's monitor hasn't switched to higher res early during boot. So here's what I'm seeing with the latest EDKII: [0.00] efi: EFI v2.40 by EDK II [0.00] efi: ACPI=0x7ff2d000 ACPI 2.0=0x7ff2d014 [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x1000-0x2000) (0MB) [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x2000-0x0009f000) (0MB) [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0009f000-0x000a) (0MB) [0.00] efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0010-0x0082) (7MB) [0.00] efi: mem05: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0082-0x0100) (7MB) [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0100-0x03cbc000) (44MB) [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x03cbc000-0x0400) (3MB) [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0400-0x05cbc000) (28MB) [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x05cbc000-0x3fffc000) (931MB) [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x3fffc000-0x4000) (0MB) [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x4000-0x7c00) (960MB) [0.00] efi: mem12: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7c00-0x7c02) (0MB) [0.00] efi: mem13: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7c02-0x7ebc5000) (43MB) [0.00] efi: mem14: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ebc5000-0x7ebfe000) (0MB) [0.00] efi: mem15: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ebfe000-0x7ebff000) (0MB) [0.00] efi: mem16: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7ebff000-0x7ec03000) (0MB) [0.00] efi: mem17: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec03000-0x7ec05000) (0MB) [0.00] efi: mem18: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec05000-0x7ec06000) (0MB) [0.00] efi: mem19: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec06000-0x7ec07000) (0MB) [0.00] efi: mem20: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec07000-0x7ec08000) (0MB) [0.00] efi: mem21: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec08000-0x7ece7000) (0MB) [0.00] efi: mem22: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7ece7000-0x7ee3b000) (1MB) [0.00] efi: mem23: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ee3b000-0x7ee4e000) (0MB) [0.00] efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ee4e000-0x7fd4e000) (15MB) [0.00] efi: mem25: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7fd4e000-0x7fece000) (1MB) [0.00] efi: mem26: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x7fece000-0x7fefe000) (0MB) [0.00] efi: mem27: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7fefe000-0x7ff22000) (0MB) [0.00] efi: mem28: [Reserved | | | | | |WB|WT|WC|UC] range=[0x7ff22000-0x7ff26000) (0MB) [0.00] efi: mem29: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] range=[0x7ff26000-0x7ff2e000) (0MB) [0.00] efi: mem30: [ACPI Memory NVS| | | | | |WB|WT|WC|UC] range=[0x7ff2e000-0x7ff32000) (0MB) [0.00] efi: mem31: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ff32000-0x7ffd) (0MB) [0.00] efi: mem32: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ffd-0x8000) (0MB) [0.00] efi: mem33: [Runtime Data |RUN| | | | | | | |UC] range=[0xfff0-0x0001) (1MB) and here's with the proposed changes: * regions get printed first so that
Re: Shorten efi regions output
On 9 December 2014 at 10:58, Borislav Petkov b...@alien8.de wrote: Hi guys, so this decoded EFI regions output is nice but can we shorten it? It sticks too far out in the terminal more than anything else in dmesg and staring at it needs me to resize window and such. It probably is an even bigger problem if one's monitor hasn't switched to higher res early during boot. So here's what I'm seeing with the latest EDKII: [0.00] efi: EFI v2.40 by EDK II [0.00] efi: ACPI=0x7ff2d000 ACPI 2.0=0x7ff2d014 [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x1000-0x2000) (0MB) [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x2000-0x0009f000) (0MB) [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0009f000-0x000a) (0MB) [0.00] efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0010-0x0082) (7MB) [0.00] efi: mem05: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0082-0x0100) (7MB) [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0100-0x03cbc000) (44MB) [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x03cbc000-0x0400) (3MB) [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0400-0x05cbc000) (28MB) [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x05cbc000-0x3fffc000) (931MB) [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x3fffc000-0x4000) (0MB) [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x4000-0x7c00) (960MB) [0.00] efi: mem12: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7c00-0x7c02) (0MB) [0.00] efi: mem13: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7c02-0x7ebc5000) (43MB) [0.00] efi: mem14: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ebc5000-0x7ebfe000) (0MB) [0.00] efi: mem15: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ebfe000-0x7ebff000) (0MB) [0.00] efi: mem16: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7ebff000-0x7ec03000) (0MB) [0.00] efi: mem17: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec03000-0x7ec05000) (0MB) [0.00] efi: mem18: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec05000-0x7ec06000) (0MB) [0.00] efi: mem19: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec06000-0x7ec07000) (0MB) [0.00] efi: mem20: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec07000-0x7ec08000) (0MB) [0.00] efi: mem21: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec08000-0x7ece7000) (0MB) [0.00] efi: mem22: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7ece7000-0x7ee3b000) (1MB) [0.00] efi: mem23: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ee3b000-0x7ee4e000) (0MB) [0.00] efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ee4e000-0x7fd4e000) (15MB) [0.00] efi: mem25: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7fd4e000-0x7fece000) (1MB) [0.00] efi: mem26: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x7fece000-0x7fefe000) (0MB) [0.00] efi: mem27: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7fefe000-0x7ff22000) (0MB) [0.00] efi: mem28: [Reserved | | | | | |WB|WT|WC|UC] range=[0x7ff22000-0x7ff26000) (0MB) [0.00] efi: mem29: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] range=[0x7ff26000-0x7ff2e000) (0MB) [0.00] efi: mem30: [ACPI Memory NVS| | | | | |WB|WT|WC|UC] range=[0x7ff2e000-0x7ff32000) (0MB) [0.00] efi: mem31: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ff32000-0x7ffd) (0MB) [0.00] efi: mem32: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ffd-0x8000) (0MB) [0.00] efi: mem33: [Runtime Data |RUN| | | | | |
Re: Shorten efi regions output
On Tue, Dec 09, 2014 at 01:42:44PM +0100, Ard Biesheuvel wrote: The |] thing is easily fixed, though. [...] diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 8590099ac148..6734072980ee 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c [...] @@ -490,15 +490,15 @@ char * __init efi_md_typeattr_format(char *buf, size_t size, snprintf(pos, size, |attr=0x%016llx], (unsigned long long)attr); else - snprintf(pos, size, |%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s], -attr EFI_MEMORY_RUNTIME ? RUN : , -attr EFI_MEMORY_XP ? XP : , -attr EFI_MEMORY_RP ? RP : , -attr EFI_MEMORY_WP ? WP : , -attr EFI_MEMORY_UCE ? UCE : , -attr EFI_MEMORY_WB ? WB : , -attr EFI_MEMORY_WT ? WT : , -attr EFI_MEMORY_WC ? WC : , -attr EFI_MEMORY_UC ? UC : ); + snprintf(pos, size, |%s%s%s%s%s%s%s%s%s], Drop the leading | here +attr EFI_MEMORY_RUNTIME ? RT| : , +attr EFI_MEMORY_XP ? XP| : , +attr EFI_MEMORY_RP ? RP| : , +attr EFI_MEMORY_WP ? WP| : , +attr EFI_MEMORY_UCE ? UCE| : , +attr EFI_MEMORY_WB ? WB| : , +attr EFI_MEMORY_WT ? WT| : , +attr EFI_MEMORY_WC ? WC| : , +attr EFI_MEMORY_UC ? UC : ); and move all the | to the beginning of the string here, including UC Haha, of course! :-) /me slaps forehead. Thanks! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 12/09/14 10:58, Borislav Petkov wrote: Hi guys, so this decoded EFI regions output is nice but can we shorten it? It sticks too far out in the terminal more than anything else in dmesg and staring at it needs me to resize window and such. It probably is an even bigger problem if one's monitor hasn't switched to higher res early during boot. So here's what I'm seeing with the latest EDKII: [0.00] efi: EFI v2.40 by EDK II [0.00] efi: ACPI=0x7ff2d000 ACPI 2.0=0x7ff2d014 [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x1000-0x2000) (0MB) [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x2000-0x0009f000) (0MB) [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0009f000-0x000a) (0MB) [0.00] efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0010-0x0082) (7MB) [0.00] efi: mem05: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0082-0x0100) (7MB) [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0100-0x03cbc000) (44MB) [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x03cbc000-0x0400) (3MB) [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0400-0x05cbc000) (28MB) [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x05cbc000-0x3fffc000) (931MB) [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x3fffc000-0x4000) (0MB) [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x4000-0x7c00) (960MB) [0.00] efi: mem12: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7c00-0x7c02) (0MB) [0.00] efi: mem13: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7c02-0x7ebc5000) (43MB) [0.00] efi: mem14: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ebc5000-0x7ebfe000) (0MB) [0.00] efi: mem15: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ebfe000-0x7ebff000) (0MB) [0.00] efi: mem16: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7ebff000-0x7ec03000) (0MB) [0.00] efi: mem17: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec03000-0x7ec05000) (0MB) [0.00] efi: mem18: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec05000-0x7ec06000) (0MB) [0.00] efi: mem19: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec06000-0x7ec07000) (0MB) [0.00] efi: mem20: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec07000-0x7ec08000) (0MB) [0.00] efi: mem21: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec08000-0x7ece7000) (0MB) [0.00] efi: mem22: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7ece7000-0x7ee3b000) (1MB) [0.00] efi: mem23: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ee3b000-0x7ee4e000) (0MB) [0.00] efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ee4e000-0x7fd4e000) (15MB) [0.00] efi: mem25: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7fd4e000-0x7fece000) (1MB) [0.00] efi: mem26: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x7fece000-0x7fefe000) (0MB) [0.00] efi: mem27: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7fefe000-0x7ff22000) (0MB) [0.00] efi: mem28: [Reserved | | | | | |WB|WT|WC|UC] range=[0x7ff22000-0x7ff26000) (0MB) [0.00] efi: mem29: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] range=[0x7ff26000-0x7ff2e000) (0MB) [0.00] efi: mem30: [ACPI Memory NVS| | | | | |WB|WT|WC|UC] range=[0x7ff2e000-0x7ff32000) (0MB) [0.00] efi: mem31: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ff32000-0x7ffd) (0MB) [0.00] efi: mem32: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ffd-0x8000) (0MB) [0.00] efi: mem33: [Runtime Data |RUN| | | | | | | |UC]
Re: Shorten efi regions output
On Tue, Dec 09, 2014 at 04:35:33PM +0100, Laszlo Ersek wrote: I disagree with the patch in general, and I strongly disagree with this specific change in particular. This part: - breaks the alignment for the right side of the table Well, we can start by removing the sizes - they're useless anyway and can be computed with a simple awk script or whatever. I.e., ... [0.00] efi: mem23: [0x7ee3b000-0x7ee4e000) [RtData |RT|WB|WT|WC|UC]) [0.00] efi: mem24: [0x7ee4e000-0x7fd4e000) [BootData |WB|WT|WC|UC] [0.00] efi: mem25: [0x7fd4e000-0x7fece000) [BootCode |WB|WT|WC|UC] [0.00] efi: mem26: [0x7fece000-0x7fefe000) [RtCode |RT|WB|WT|WC|UC] [0.00] efi: mem27: [0x7fefe000-0x7ff22000) [RtData |RT|WB|WT|WC|UC] ... Then we could do some more work like fishing out columns and removing those which are not set in any region from the output completely and then have alignment but with only the relevant fields, ... - completely defeats another of my goals with the original patch, which was to be able to get an overview of memory attributes *at a glance*. That only works if each column is strictly associated with one bit, and your gaze can slide over empty stretches. Well, and empty column doesn't tell me a whole lot, does it? [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) I still have to go and look up what those 5 empty bits mean. Thus my angle was: if it is not set, don't print it. Please compare how you visually execute a search for the next runtime region (or the next non-WB line) before and after. I'd look for region names RtData/RtCode. Unless this dump is supposed to be used to sanity-check region attribute flags too, then I see your point about the alignment. Your patch shaves off 30 characters of the width if I measured it right (goes from 131 to 101.) I don't believe that would justify breaking the alignment of the columns. For example, you could remove 15 characters from the right just with dmesg -t (timestamps are probably not overly important for printing the memmap). Yeah, but you can look at that output with other means, i.e. serial console/netconsole/guest boot log, etc. Anyway it's a matter of taste. I know you work with this every day so if it doesn't meet your needs then I won't insist preserving it. I won't NACK the patch it but I certainly won't ACK it either. Ok, fair enough. Let's see what the others think. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On 12/09/14 at 10:58am, Borislav Petkov wrote: Hi guys, so this decoded EFI regions output is nice but can we shorten it? It sticks too far out in the terminal more than anything else in dmesg and staring at it needs me to resize window and such. It probably is an even bigger problem if one's monitor hasn't switched to higher res early during boot. I have same feeling with you, it is too long for most of people. Since the printk code are for EFI_DEBUG, they are around the #ifdef so I would like to see a kernel param like efi_debug=on, so only efi_debug is specified then these verbose messages are printed. Without the param kernel can print some basic infomation about the memory ranges. In arm64 code there's already a uefi_debug param it can be moved to general code so that there will be a goable switch. So here's what I'm seeing with the latest EDKII: [0.00] efi: EFI v2.40 by EDK II [0.00] efi: ACPI=0x7ff2d000 ACPI 2.0=0x7ff2d014 [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x1000-0x2000) (0MB) [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x2000-0x0009f000) (0MB) [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0009f000-0x000a) (0MB) [0.00] efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0010-0x0082) (7MB) [0.00] efi: mem05: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0082-0x0100) (7MB) [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0100-0x03cbc000) (44MB) [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x03cbc000-0x0400) (3MB) [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0400-0x05cbc000) (28MB) [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x05cbc000-0x3fffc000) (931MB) [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x3fffc000-0x4000) (0MB) [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x4000-0x7c00) (960MB) [0.00] efi: mem12: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7c00-0x7c02) (0MB) [0.00] efi: mem13: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7c02-0x7ebc5000) (43MB) [0.00] efi: mem14: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ebc5000-0x7ebfe000) (0MB) [0.00] efi: mem15: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ebfe000-0x7ebff000) (0MB) [0.00] efi: mem16: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7ebff000-0x7ec03000) (0MB) [0.00] efi: mem17: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec03000-0x7ec05000) (0MB) [0.00] efi: mem18: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec05000-0x7ec06000) (0MB) [0.00] efi: mem19: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec06000-0x7ec07000) (0MB) [0.00] efi: mem20: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x7ec07000-0x7ec08000) (0MB) [0.00] efi: mem21: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ec08000-0x7ece7000) (0MB) [0.00] efi: mem22: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7ece7000-0x7ee3b000) (1MB) [0.00] efi: mem23: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7ee3b000-0x7ee4e000) (0MB) [0.00] efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x7ee4e000-0x7fd4e000) (15MB) [0.00] efi: mem25: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x7fd4e000-0x7fece000) (1MB) [0.00] efi: mem26: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x7fece000-0x7fefe000) (0MB) [0.00] efi: mem27: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x7fefe000-0x7ff22000) (0MB) [0.00] efi: mem28: [Reserved | | | | | |WB|WT|WC|UC] range=[0x7ff22000-0x7ff26000) (0MB) [0.00] efi: mem29: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] range=[0x7ff26000-0x7ff2e000) (0MB) [0.00]
