diff options
| -rw-r--r-- | usr/src/lib/libefi/common/rdwr_efi.c | 2 | ||||
| -rw-r--r-- | usr/src/uts/common/sys/efi_partition.h | 2 | ||||
| -rw-r--r-- | usr/src/uts/i86pc/dboot/dboot_startkern.c | 14 |
3 files changed, 9 insertions, 9 deletions
diff --git a/usr/src/lib/libefi/common/rdwr_efi.c b/usr/src/lib/libefi/common/rdwr_efi.c index 34edfa088b..6aaaba7b92 100644 --- a/usr/src/lib/libefi/common/rdwr_efi.c +++ b/usr/src/lib/libefi/common/rdwr_efi.c @@ -135,7 +135,7 @@ static int efi_read(int, struct dk_gpt *); /* * In normal operation, libefi just passes everything down to the kernel driver * (and - usually - cmlb), as that code needs to react to any partitioning - * changes by changing devices nodes under /dev/?dsk/ and the like. + * changes by changing device nodes under /dev/?dsk/ and the like. * * However, if we are running against an un-labeled lofi device on an older * version of illumos, these ioctl()s aren't emulated. This can be a problem if diff --git a/usr/src/uts/common/sys/efi_partition.h b/usr/src/uts/common/sys/efi_partition.h index 9b8d7e9708..065f65f802 100644 --- a/usr/src/uts/common/sys/efi_partition.h +++ b/usr/src/uts/common/sys/efi_partition.h @@ -51,7 +51,7 @@ extern "C" { /* * Although the EFI spec is clear that sizeof (efi_gpt_t) is a valid value * (512), at least one EFI system (AMI v4.6.4.1) incorrectly expects this to be - * exactly the size of the structure defiend in the spec, that is, 92. + * exactly the size of the structure defined in the spec, that is, 92. * * As the reserved section is never used, the modified value works fine * everywhere else. diff --git a/usr/src/uts/i86pc/dboot/dboot_startkern.c b/usr/src/uts/i86pc/dboot/dboot_startkern.c index 3e63ed7720..74e3504d11 100644 --- a/usr/src/uts/i86pc/dboot/dboot_startkern.c +++ b/usr/src/uts/i86pc/dboot/dboot_startkern.c @@ -1471,13 +1471,13 @@ dboot_add_memlist(uint64_t start, uint64_t end) max_mem = end; /* - * Well, this is sad. One some systems, there is a region of memory - * that can be corrupted until some number of seconds after we have - * booted. And the BIOS doesn't tell us that this memory is unsafe to - * use. And we don't know how long it's dangerous. So we'll chop out - * this range from any memory list that would otherwise be usable. Note - * that any system of this type will give us the new-style (0x40) - * memlist, so we need not fix up the other path below. + * Well, this is sad. On some systems, there is a region of memory that + * can be corrupted until some number of seconds after we have booted. + * And the BIOS doesn't tell us that this memory is unsafe to use. And + * we don't know how long it's dangerous. So we'll chop out this range + * from any memory list that would otherwise be usable. Note that any + * system of this type will give us the new-style (0x40) memlist, so we + * need not fix up the other path below. * * However, if we're boot-loaded from something that doesn't have a * RICHMOND-16 workaround (which on many systems is just fine), it could |