kernels. The error message was "elf_loadexec: cannot seek".
Libstand maintains a read-ahead buffer for each open file, so that
it can read in chunks of 512 bytes for greater efficiency. When
the loader tries to lseek forward in a file by a small amount, it
sometimes happens that the target file offset is already in the
read-ahead buffer. But the lseek code simply discarded the contents
of that buffer and performed a seek directly on the underlying
file. This resulted in an attempt to seek backwards in the file,
since some of the data has already been read into the read-ahead
buffer. Gzipped data streams cannot seek backwards, so an error
was returned.
This commit adds code which checks to see if the desired file offset
is already in the read-ahead buffer. If it is, the code simply
adjusts the buffer pointer and length, thereby avoiding a reverse
seek on the gzipped data stream.
I incorporated a suggestion from Matt Dillon which saved a little
bit of code in this fix.
Reviewed by: dillon, gallatin, jhb
Certain ISO fs's (like the one for 4.4-RC1 disc1 on alpha)
trigger this, and we end up opening a null file name. This causes us to get
a false match for "kernel.ko" when it does not exist.
member f_devdata to be a pointer to a socket number. When currdev
is "pxe", that assumption is correct. When currdev is "disk*", that
assumption is incorrect.
Submitted by: Jim Browne <jbrowne@jbrowne.com>
The test for failing the end guard was always triggering (and was reported as
such in compiler warnings). This is a temporary band-aid until I can work
out what's really going on.
Reviewed by: obrien
the efficiency of byte-by-byte read operations on filesystems not already
supported by the block cache (especially NFS).
This should be a welcome change for users booting via PXE, as the loader
now reads its startup files almost instantly, instead of taking tens of
seconds.
identifier to the DHCP server. Now you can check for this string
in your dhcp configuration to decide whether you will hand out a
lease to the client or not.
was not the fault of the module code, nor FICL. The malloc code requires
sbrk() to return addresses that were at least 16 byte aligned. If the
Alpha loader happened to be 8 byte but not 16 byte aligned in length, then
you would get a zfree() panic at startup.
Incidently, this affected the i386 loader as well, and explains why
the static heap changed things and why jlemon had trouble when the bss
was not ending at a multiple of 8 bytes.
My fix is to 16 byte align it on all arches, even though the x86 version
only required 8 byte alignment (struct MemNode is smaller there). We could
page align it if we wanted to be paranoid, but it isn't presently necessary.
