Re: Is anyone using the http module to do largish transfers?
On 2/8/15 7:24 PM, Andrei Borzenkov wrote: В Sun, 08 Feb 2015 12:26:53 -0800 Alan Perry пишет: Another question about the http module. http_establish() builds a GET request that may have a Content-Range header. Where do you see it? My mistake - looks like this has been changed since I last updated my local repo. alan However, looking at the HTTP/1.1 RFCs, Content-Range is something that appears in a status 206 response, not in a request. The http module shouldn't insert this header, should it? alan Thanks, alan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: initrd loading, max size, addr_min, and page_align
Andrei Borzenkov wrote: В Sun, 08 Feb 2015 11:14:28 -0600 Bruce Dubbs пишет: Andrei Borzenkov wrote: В Thu, 5 Feb 2015 21:55:54 + Eric Ewanco пишет: Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to find out the whys and wherefores of the GRUB 2.00 size limit. GRUB 2.00 is way too old. But as far as I know grub-2.00 is the last "stable" release. There is the more current grub-2.02~beta2 that was released over a year ago, but some people prefer releases that upstream has designated as stable. If you want to discuss a problem on development list, you should at least verify if this problem exists in current code. I agree. In practice all ditros I'm aware of are using at least 2.02~beta2 or what effectively amounts to git snapshot. Indeed. We have gone to 2.02~beta2 also, although we prefer it when upstream labels a packages as stable. Has grub gone to a policy of git snapshots only and forgone stable releases? I do not think it is intentional. There are several packages that do not release stable releases but only snapshots (but it is uncommon), however AFAIK grub is one of the very few active packages that does not seem to have a regularly scheduled release process. It would actually help us if you just said that you are not going to designate stable, release candidate, beta, etc tarballs any more and it's up to the distro or individual to figure out what version to extract from version control. -- Bruce Dubbs LFS ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: initrd loading, max size, addr_min, and page_align
В Sun, 08 Feb 2015 11:14:28 -0600 Bruce Dubbs пишет: > Andrei Borzenkov wrote: > > В Thu, 5 Feb 2015 21:55:54 + Eric Ewanco > > пишет: > > > >> > >> Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), > >> and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to > >> find out the whys and wherefores of the GRUB 2.00 size limit. > > > > GRUB 2.00 is way too old. > > But as far as I know grub-2.00 is the last "stable" release. There is the > more > current grub-2.02~beta2 that was released over a year ago, but some people > prefer releases that upstream has designated as stable. > If you want to discuss a problem on development list, you should at least verify if this problem exists in current code. In practice all ditros I'm aware of are using at least 2.02~beta2 or what effectively amounts to git snapshot. > Has grub gone to a policy of git snapshots only and forgone stable releases? > I do not think it is intentional. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Is anyone using the http module to do largish transfers?
В Sun, 08 Feb 2015 12:26:53 -0800 Alan Perry пишет: > > Another question about the http module. http_establish() builds a GET > request that may have a Content-Range header. Where do you see it? > However, looking at the > HTTP/1.1 RFCs, Content-Range is something that appears in a status 206 > response, not in a request. The http module shouldn't insert this > header, should it? > > alan > > > > >> Thanks, > >> > >> alan > >> > >> > >> ___ > >> Grub-devel mailing list > >> Grub-devel@gnu.org > >> https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Is anyone using the http module to do largish transfers?
On 2/7/15 8:35 AM, Andrei Borzenkov wrote: В Wed, 04 Feb 2015 16:39:20 -0800 Alan Perry пишет: Hi, I am trying to debug a problem involving largish HTTP data transfers (around 80M). I have no problem transferring around 3M with the grub http module. Has anyone here observed a similar issue or is this not a problem for others and I should be looking for the problem somewhere other than the http module? I did a quick test and was able to do "initrd (http)/initrd" for ~90MB file using current git. This is under QEMU. Physical hardware may be different. OK, knowing that it works in some instances is good. As I have been digging into the problem, it seems to be somewhere other than http. I would elaborate further, but I am still working through why the code is doing what I see on the network. Another question about the http module. http_establish() builds a GET request that may have a Content-Range header. However, looking at the HTTP/1.1 RFCs, Content-Range is something that appears in a status 206 response, not in a request. The http module shouldn't insert this header, should it? alan Thanks, alan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Add a module for retrieving SMBIOS information
On 02/08/2015 01:54 PM, David Michael wrote:
> The following are two use cases from Rajat Jain :
>
> 1) We have a board that boots Linux and this board itself can be plugged into
> one of different chassis types. We need to pass different parameters to the
> kernel based on the "CHASSIS_TYPE" information that is passed by the bios in
> the DMI / SMBIOS tables.
>
why isn't 1) already in the kernel itself?
P.
> 2) We may have a USB stick that can go into multiple boards, and the exact
> kernel to be loaded depends on the machine information (PRODUCT_NAME etc)
> passed via the DMI.
>
> * grub-core/commands/smbios.c: New file.
> * grub-core/Makefile.core.def (smbios): New module.
> * docs/grub.texi (smbios): New node.
> (Command-line and menu entry commands): Add a menu entry for smbios.
> ---
>
> Changes since v1:
>
> * Removed formfeeds and quoted use cases in the commit messages as
> suggested by Prarit Bhargava.
>
> * Enabled building the module on all EFI platforms as suggested by Leif
> Lindholm.
>
> docs/grub.texi | 67
> grub-core/Makefile.core.def | 7 +
> grub-core/commands/smbios.c | 361
>
> 3 files changed, 435 insertions(+)
> create mode 100644 grub-core/commands/smbios.c
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 46b9e7f..f4e187f 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -3830,6 +3830,7 @@ you forget a command, you can run the command
> @command{help}
> * sha256sum:: Compute or check SHA256 hash
> * sha512sum:: Compute or check SHA512 hash
> * sleep:: Wait for a specified number of seconds
> +* smbios:: Retrieve SMBIOS information
> * source:: Read a configuration file in same context
> * test::Check file types and compare values
> * true::Do nothing, successfully
> @@ -4944,6 +4945,72 @@ if timeout was interrupted by @key{ESC}.
> @end deffn
>
>
> +@node smbios
> +@subsection smbios
> +
> +@deffn Command smbios @
> + [@option{-t} @var{type}] @
> + [@option{-h} @var{handle}] @
> + [@option{-m} @var{match}] @
> + [ (@option{-b} | @option{-w} | @option{-d} | @option{-q} | @option{-s}) @
> + @var{offset} [@option{-v} @var{variable}] ]
> +Retrieve SMBIOS information. This command is only available on x86 and EFI
> +systems.
> +
> +When run with no options, @command{smbios} will print the SMBIOS table
> entries
> +to the console as the header values, a hex dump, and a string list. The
> +following options can filter which table entries are printed.
> +
> +@itemize @bullet
> +@item
> +Specifying @option{-t} will only print entries with a matching @var{type}.
> The
> +type can be any value from 0 to 255. Specify a value outside this range to
> +match entries with any type. The default is -1.
> +@item
> +Specifying @option{-h} will only print entries with a matching @var{handle}.
> +The handle can be any value from 0 to 65535. Specify a value outside this
> +range to match entries with any handle. The default is -1.
> +@item
> +Specifying @option{-m} will only print number @var{match} in the list of all
> +filtered entries; e.g. @code{smbios -m 3} will print the third entry. The
> list
> +is always ordered the same as the hardware's SMBIOS table. The match number
> +can be any positive value. Specify 0 to match all entries. The default is
> 0.
> +@end itemize
> +
> +The remaining options print the value of a field in the matched SMBIOS table
> +entry. Only one of these options may be specified. When they are used, the
> +option @code{-m 0} is synonymous with @code{-m 1} to match the first entry.
> +
> +@itemize @bullet
> +@item
> +When given @option{-b}, print the value of the byte
> +at @var{offset} bytes into the matched SMBIOS table entry.
> +@item
> +When given @option{-w}, print the value of the word (two bytes)
> +at @var{offset} bytes into the matched SMBIOS table entry.
> +@item
> +When given @option{-d}, print the value of the dword (four bytes)
> +at @var{offset} bytes into the matched SMBIOS table entry.
> +@item
> +When given @option{-q}, print the value of the qword (eight bytes)
> +at @var{offset} bytes into the matched SMBIOS table entry.
> +@item
> +When given @option{-s}, print the string table entry with its index found
> +at @var{offset} bytes into the matched SMBIOS table entry.
> +@end itemize
> +
> +If any of the options in the above list were given, a variable name can be
> +specified with @option{-v} to store the value instead of printing it.
> +
> +For example, this will store and display the system manufacturer string.
> +
> +@example
> +smbios -t 1 -s 4 -v system_manufacturer
> +echo $system_manufacturer
> +@end example
> +@end deffn
> +
> +
> @node source
> @subsection source
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 42443bc..f87de70
[PATCH v2] Add a module for retrieving SMBIOS information
The following are two use cases from Rajat Jain :
1) We have a board that boots Linux and this board itself can be plugged into
one of different chassis types. We need to pass different parameters to the
kernel based on the "CHASSIS_TYPE" information that is passed by the bios in
the DMI / SMBIOS tables.
2) We may have a USB stick that can go into multiple boards, and the exact
kernel to be loaded depends on the machine information (PRODUCT_NAME etc)
passed via the DMI.
* grub-core/commands/smbios.c: New file.
* grub-core/Makefile.core.def (smbios): New module.
* docs/grub.texi (smbios): New node.
(Command-line and menu entry commands): Add a menu entry for smbios.
---
Changes since v1:
* Removed formfeeds and quoted use cases in the commit messages as
suggested by Prarit Bhargava.
* Enabled building the module on all EFI platforms as suggested by Leif
Lindholm.
docs/grub.texi | 67
grub-core/Makefile.core.def | 7 +
grub-core/commands/smbios.c | 361
3 files changed, 435 insertions(+)
create mode 100644 grub-core/commands/smbios.c
diff --git a/docs/grub.texi b/docs/grub.texi
index 46b9e7f..f4e187f 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3830,6 +3830,7 @@ you forget a command, you can run the command
@command{help}
* sha256sum:: Compute or check SHA256 hash
* sha512sum:: Compute or check SHA512 hash
* sleep:: Wait for a specified number of seconds
+* smbios:: Retrieve SMBIOS information
* source:: Read a configuration file in same context
* test::Check file types and compare values
* true::Do nothing, successfully
@@ -4944,6 +4945,72 @@ if timeout was interrupted by @key{ESC}.
@end deffn
+@node smbios
+@subsection smbios
+
+@deffn Command smbios @
+ [@option{-t} @var{type}] @
+ [@option{-h} @var{handle}] @
+ [@option{-m} @var{match}] @
+ [ (@option{-b} | @option{-w} | @option{-d} | @option{-q} | @option{-s}) @
+ @var{offset} [@option{-v} @var{variable}] ]
+Retrieve SMBIOS information. This command is only available on x86 and EFI
+systems.
+
+When run with no options, @command{smbios} will print the SMBIOS table entries
+to the console as the header values, a hex dump, and a string list. The
+following options can filter which table entries are printed.
+
+@itemize @bullet
+@item
+Specifying @option{-t} will only print entries with a matching @var{type}. The
+type can be any value from 0 to 255. Specify a value outside this range to
+match entries with any type. The default is -1.
+@item
+Specifying @option{-h} will only print entries with a matching @var{handle}.
+The handle can be any value from 0 to 65535. Specify a value outside this
+range to match entries with any handle. The default is -1.
+@item
+Specifying @option{-m} will only print number @var{match} in the list of all
+filtered entries; e.g. @code{smbios -m 3} will print the third entry. The list
+is always ordered the same as the hardware's SMBIOS table. The match number
+can be any positive value. Specify 0 to match all entries. The default is 0.
+@end itemize
+
+The remaining options print the value of a field in the matched SMBIOS table
+entry. Only one of these options may be specified. When they are used, the
+option @code{-m 0} is synonymous with @code{-m 1} to match the first entry.
+
+@itemize @bullet
+@item
+When given @option{-b}, print the value of the byte
+at @var{offset} bytes into the matched SMBIOS table entry.
+@item
+When given @option{-w}, print the value of the word (two bytes)
+at @var{offset} bytes into the matched SMBIOS table entry.
+@item
+When given @option{-d}, print the value of the dword (four bytes)
+at @var{offset} bytes into the matched SMBIOS table entry.
+@item
+When given @option{-q}, print the value of the qword (eight bytes)
+at @var{offset} bytes into the matched SMBIOS table entry.
+@item
+When given @option{-s}, print the string table entry with its index found
+at @var{offset} bytes into the matched SMBIOS table entry.
+@end itemize
+
+If any of the options in the above list were given, a variable name can be
+specified with @option{-v} to store the value instead of printing it.
+
+For example, this will store and display the system manufacturer string.
+
+@example
+smbios -t 1 -s 4 -v system_manufacturer
+echo $system_manufacturer
+@end example
+@end deffn
+
+
@node source
@subsection source
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 42443bc..f87de70 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1023,6 +1023,13 @@ module = {
};
module = {
+ name = smbios;
+ common = commands/smbios.c;
+ enable = efi;
+ enable = x86;
+};
+
+module = {
name = suspend;
ieee1275 = commands/ieee1275/suspend.c;
enable = i386_ieee1275;
diff --git a/grub-core/commands/
Re: initrd loading, max size, addr_min, and page_align
Andrei Borzenkov wrote: В Thu, 5 Feb 2015 21:55:54 + Eric Ewanco пишет: Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to find out the whys and wherefores of the GRUB 2.00 size limit. GRUB 2.00 is way too old. But as far as I know grub-2.00 is the last "stable" release. There is the more current grub-2.02~beta2 that was released over a year ago, but some people prefer releases that upstream has designated as stable. Has grub gone to a policy of git snapshots only and forgone stable releases? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: initrd loading, max size, addr_min, and page_align
В Thu, 5 Feb 2015 21:55:54 + Eric Ewanco пишет: > > Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), > and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to find > out the whys and wherefores of the GRUB 2.00 size limit. GRUB 2.00 is way too old. > > In the process of doing this I noticed a strange behavior. The code has a > ceiling (addr_max) and a floor (addr_min) for the initrd. The initrd is > loaded high, so that it ends at the ceiling and grows toward the floor as the > size of the initrd increases. The odd behavior, or at least the one that I > don't understand, is that the floor grows upward toward the ceiling at the > same time. The lines in question: > > addr_min = (grub_addr_t) prot_mode_target + prot_init_space > + page_align (size); > This code is different in current GIT. > /* Put the initrd as high as possible, 4KiB aligned. */ > addr = (addr_max - size) & ~0xFFF; > > page_align(size) returns a rounded-up alignment of size; i.e., if size is > 0x2335b728, it returns 0x2335c000. Consequently, if the initrd size doubles, > the distance between the ceiling and the first byte doubles (expected), AND > the distance between the floor and the first byte halves because both are > proportional to the size. I would expect the floor to remain relatively > constant based on the memory map. Maybe be adjusted between 1-4k bytes for > alignment, but not by the whole size of the initrd. > > I'm wondering if this is a bug, or if my modest and cursory understanding of > the code is incorrect. > > If I am incorrect, can someone explain the page_align calculus, and also > explain how the value of GRUB_LINUX_INITRD_MAX_ADDRESS (0x37FF) was > determined, whether it is hard or might be revisable upward on some systems, > and what the implications are of changing it (i.e. will it either work or not > boot at all, or whether I might silently hose something). > > Thanks, > Eric Ewanco > > > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
