[ANNOUNCEMENT] GRUB mini-summit - 3rd virtual session Tue Nov 17 15:00 UTC
Hi, Next GRUB mini-summit session starts on Tue Nov 17 at 15:00 UTC. More you can find here: https://twitter.com/3mdeb_com/status/1327278804100931587 Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Antw: [EXT] [systemd-devel] [SPECIFICATION RFC] The firmware and bootloader log specification
On 16/11/2020 08.02, Ulrich Windl wrote: Daniel Kiper schrieb am 14.11.2020 um 00:52 in > Nachricht <20201113235242.k6fzlwmwm2xqh...@tomti.i.net-space.pl>: > ... >> The members of struct bf_log_msg: >> ‑ size: total size of bf_log_msg struct, >> ‑ ts_nsec: timestamp expressed in nanoseconds starting from 0, > > Who or what defines t == 0? Some sort of "clapperboard" log entry, stating "the RTC says X, the cycle counter is Y, the onboard ACME atomic clock says Z, I'm now starting to count ts_nsec from W" might be useful for some eventual userspace tool to try to stitch together the log entries from the various stages. I have no idea how a formal spec of such an entry would look like or if it's even feasible to do formally. But even just such entries in free-form prose could at least help a human consumer. Rasmus ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 03/15] luks2: Rename source disk variabled named 'disk' to 'source' as in luks.c.
On Sun, Nov 15, 2020 at 10:39:21AM +0100, Patrick Steinhardt wrote: > On Fri, Nov 06, 2020 at 10:44:23PM -0600, Glenn Washburn wrote: > > This makes it more obvious to the reader that the disk referred to is the > > source disk, as opposed to say the disk holding the cryptodisk. > > > > Signed-off-by: Glenn Washburn > > Reviewed-by: Patrick Steinhardt Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 04/15] types: Define GRUB_CHAR_BIT based on compiler macro instead of using literal.
On Sun, Nov 15, 2020 at 10:42:39AM +0100, Patrick Steinhardt wrote: > On Fri, Nov 06, 2020 at 10:44:24PM -0600, Glenn Washburn wrote: > > Signed-off-by: Glenn Washburn > > --- > > include/grub/types.h | 10 -- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/include/grub/types.h b/include/grub/types.h > > index 035a4b528..495c86bb1 100644 > > --- a/include/grub/types.h > > +++ b/include/grub/types.h > > @@ -72,6 +72,14 @@ > > # endif > > #endif > > > > +#ifndef __CHAR_BIT__ > > +#error __CHAR_BIT__ is not defined > > +#elif __CHAR_BIT__ != 8 > > +#error __CHAR_BIT__ is not equal 8 > > +#else > > +#define GRUB_CHAR_BIT __CHAR_BIT__ > > +#endif > > + > > Nested defines typically use spaces: Yeah, good point. Anyway, I will fix it before commiting. > #ifndef __CHAR_BIT__ > # error __CHAR_BIT__ is not defined > #elif __CHAR_BIT__ != 8 > # error __CHAR_BIT__ is not equal 8 > #else > # define GRUB_CHAR_BIT __CHAR_BIT__ > #endif Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 05/15] luks2: Use correct index variable when looping in luks2_get_keyslot.
On Sun, Nov 15, 2020 at 10:43:17AM +0100, Patrick Steinhardt wrote: > On Fri, Nov 06, 2020 at 10:44:25PM -0600, Glenn Washburn wrote: > > The loop variable j should be used to index the digests and segments json > > array, instead of the variable i, which is the keyslot index. > > > > Signed-off-by: Glenn Washburn > > Reviewed-by: Patrick Steinhardt Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 01/15] cryptodisk: Rename total_length field in grub_cryptodisk_t to total_sectors.
On Sun, Nov 15, 2020 at 10:37:23AM +0100, Patrick Steinhardt wrote: > On Fri, Nov 06, 2020 at 10:44:21PM -0600, Glenn Washburn wrote: > > This creates an alignment with grub_disk_t naming of the same field and is > > more intuitive as to how it should be used. > > > > Signed-off-by: Glenn Washburn > > Reviewed-by: Patrick Steinhardt Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 07/15] luks2: Rename index variable j to i.
On Sun, Nov 15, 2020 at 10:44:26AM +0100, Patrick Steinhardt wrote: > On Fri, Nov 06, 2020 at 10:44:27PM -0600, Glenn Washburn wrote: > > Looping variable j was named such because the variable name i was taken. > > Since i has been renamed in the previous patch, we can rename j to i. > > > > Signed-off-by: Glenn Washburn > > Reviewed-by: Patrick Steinhardt Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 02/15] cryptodisk: Rename offset in grub_cryptodisk_t to offset_sectors.
On Sun, Nov 15, 2020 at 10:38:18AM +0100, Patrick Steinhardt wrote: > On Fri, Nov 06, 2020 at 10:44:22PM -0600, Glenn Washburn wrote: > > This makes it clear that the offset represents sectors, not bytes, in order > > to improve readability. > > > > Signed-off-by: Glenn Washburn > > Reviewed-by: Patrick Steinhardt Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 06/15] luks2: Rename variable i to keyslot_idx in luks2_get_keyslot.
On Sun, Nov 15, 2020 at 10:43:55AM +0100, Patrick Steinhardt wrote: > On Fri, Nov 06, 2020 at 10:44:26PM -0600, Glenn Washburn wrote: > > Variables named i are usually looping variables, so rename to keyslot_idx to > > allow for easier reading of luks2_get_keyslot. > > > > Signed-off-by: Glenn Washburn > > Reviewed-by: Patrick Steinhardt Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] ieee1275: Avoiding many unnecessary open/close
On 2020-09-24 20:58, Eric Snowberg wrote:
On Sep 24, 2020, at 11:11 AM, diegodo
wrote:
Hi,
we are facing some performance issues with ieee1275 platform (ppc64le
architecture to be more specific) and I would like to suggest a couple
of changes to try to avoid them.
Sometimes the system can take more than 10 minutes to boot (in fact,
it can takes more than 30 and 40 minutes in some cases). From my
investigations, I noticied the following points:
1. Some types of storage devices (NVMe, Fibre Channel, ...) can have a
long time for shutdown notification. Our investigation here showed us
this shutdown increase with the size of the storage. For example,
6.4TB NVMe can takes something like 7 seconds just to issue a shutdown
notification.
2. The grub calls a lot for OPEN/READ/CLOSE for each device. I ran
some tests with just one disk (NVMe 6.4TB) and found that, even with
one disk, grub call the OPEN/CLOSE functions more than 60 times.
Considering the opening time of the device something like 1.5 seconds,
we have almost 9 minutes just opening and closing the disk.
I did some changes in the code and the time during the boot dropped
drastically - from 492s to only 15s.
The idea is to handle the _actual close_ while _opening_ the disk. So,
during the _grub_ofdisk_open_ function, we check if the requested disk
is the same as the already opened and close the previous one if we are
dealing with a different disk. Yet, I removed the OPEN/CLOSE calls
inside the _grub_ofdisk_get_block_size_ function and let it just
checking for the block size.
What are your suggestions? Is there a better way to handle this? I
really appreciate your help here.
I ran into the same issue with the ieee1275 platform on SPARC when
using
ofdisk. It would take 20+ minutes to get to the GRUB menu. I found the
same
problem, open and close can take a long time and upper level grub code
would
issue hundreds of them. I ended up writing obdisk.c. Within it, each
disk is
only opened once. I tried to make it as generic as possible. You might
consider
moving from ofdisk to obdisk. If you did, ppc64le device specific code
would
need to be included in iterate_devtree.
It also includes new features not found in ofdisk, such as hot-plug
support and
the ability to find disks that don’t have a device alias.
Thanks
---
grub-core/disk/ieee1275/ofdisk.c | 63 +---
1 file changed, 34 insertions(+), 29 deletions(-)
diff --git a/grub-core/disk/ieee1275/ofdisk.c
b/grub-core/disk/ieee1275/ofdisk.c
index d887d4b..d0ee4ae 100644
--- a/grub-core/disk/ieee1275/ofdisk.c
+++ b/grub-core/disk/ieee1275/ofdisk.c
@@ -44,7 +44,7 @@ struct ofdisk_hash_ent
};
static grub_err_t
-grub_ofdisk_get_block_size (const char *device, grub_uint32_t
*block_size,
+grub_ofdisk_get_block_size (grub_uint32_t *block_size,
struct ofdisk_hash_ent *op);
#define OFDISK_HASH_SZ 8
@@ -461,6 +461,7 @@ grub_ofdisk_open (const char *name, grub_disk_t
disk)
grub_ssize_t actual;
grub_uint32_t block_size = 0;
grub_err_t err;
+ struct ofdisk_hash_ent *op;
if (grub_strncmp (name, "ieee1275/", sizeof ("ieee1275/") - 1) != 0)
return grub_error (GRUB_ERR_UNKNOWN_DEVICE,
@@ -471,6 +472,34 @@ grub_ofdisk_open (const char *name, grub_disk_t
disk)
grub_dprintf ("disk", "Opening `%s'.\n", devpath);
+ op = ofdisk_hash_find (devpath);
+ if (!op)
+op = ofdisk_hash_add (devpath, NULL);
+ if (!op)
+{
+ grub_free (devpath);
+ return grub_errno;
+}
+
+ /* Check if the call to open is the same to the last disk already
opened */
+ if (last_devpath && !grub_strcmp(op->open_path,last_devpath))
+ {
+ goto finish;
+ }
+
+ /* If not, we need to close the previous disk and open the new one
*/
+ else {
+if (last_ihandle){
+grub_ieee1275_close (last_ihandle);
+}
+last_ihandle = 0;
+last_devpath = NULL;
+
+grub_ieee1275_open (op->open_path, &last_ihandle);
+if (! last_ihandle)
+ return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "can't open
device");
+ }
+
if (grub_ieee1275_finddevice (devpath, &dev))
{
grub_free (devpath);
@@ -491,25 +520,18 @@ grub_ofdisk_open (const char *name, grub_disk_t
disk)
return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "not a block
device");
}
+
+ finish:
/* XXX: There is no property to read the number of blocks. There
should be a property `#blocks', but it is not there. Perhaps it
is possible to use seek for this. */
disk->total_sectors = GRUB_DISK_SIZE_UNKNOWN;
{
-struct ofdisk_hash_ent *op;
-op = ofdisk_hash_find (devpath);
-if (!op)
- op = ofdisk_hash_add (devpath, NULL);
-if (!op)
- {
-grub_free (devpath);
-return grub_errno;
- }
disk->id = (unsigned long) op;
disk->data = op->open_path;
-err = grub_ofdisk_get_block_size (devpath, &block_size, op);
+err = grub_ofdisk_get_block_size (&block_si
Re: Network stack status & bugs?
Hey Daniel & team, On Thu, Oct 29, 2020 at 03:34:20AM +0200, Faidon Liambotis wrote: > On Tue, Oct 27, 2020 at 10:17:06PM +0100, Daniel Kiper wrote: > > On Mon, Jun 15, 2020 at 12:51:29PM +0300, Faidon Liambotis wrote: > > > Around a year ago, in my attempts to use GRUB for PXE, I ran into quite > > > a few bugs with GRUB's TCP, DNS and HTTP stack that prevented me from > > > using GRUB for that purpose. > > > > > > I tried my best to troubleshoot them and provide ways to reproduce them. > > > I posted my findings in Savannah: > > > - https://savannah.gnu.org/bugs/?56391 TCP FSM bug(s) > > > - https://savannah.gnu.org/bugs/?56390 Non-dual-stack aware DNS > > > - https://savannah.gnu.org/bugs/?49531 HTTP Connection: close > > > > > > I haven't seen any activity in these for over a year, but that does not > > > seem to be unusual for bugs reported to Savannah in general(?). > > > > > > However, from what I can tell, this mailing list seems to be getting a > > > lot of activity and lots of progress being made (including recent e.g. > > > the recent UEFI IPv6 improvements, yay!). So, I'm giving this a go > > > instead in the hopes to surface those to the attention of more > > > knowledgeable folks :) > > > > May I ask you to retest the latest upstream version from git master? I think > > we should fix at least some of theses issues for upcoming 2.06 release. > > I can confirm that all three of those bugs are still present in current > tip (2df291226). Happy to help test any patches! Bumping this wondering if there are any news or plans at this point :) I watched Michał Żygowski's presentation last week at the GRUB mini-summit with interest, and noticed your comments there as well -- possibly referring to some of these bugs above? Best, Faidon ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
