------------------------------------------------------------------------
r172854 | marius | 2007-10-21 10:03:18 -0700 (Sun, 21 Oct 2007) | 16 lines
Changed paths:
M /head/lib/libstand/tftp.c
- Given that we tell the compiler that struct ip is packed and 32-bit
aligned, GCC 4.2.1 also generates code for sendudp() that assumes
this alignment. GCC 4.2.1 however doesn't 32-bit align wbuf, causing
the loader to crash due to an unaligned access of wbuf in sendudp()
when netbooting sparc64. Solve this by specifying wbuf as packed and
32-bit aligned, too. As for lastdata and readudp() this currently is
no issue when compiled with GCC 4.2.1, though give lastdata the same
treatment as wbuf for consistency and possibility of being affected
in the future. [1]
- Sprinkle const on a lookup table.
------------------------------------------------------------------------
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
unwanted packet(non-tftp). Change this to retransmit the packet(request or ack) only after
a timeout.
Obtained from: Juniper Networks
Fixed by: Santhanakrishnan Balraj <sbalraj at juniper dot net>
In sendrecv_tftp:
* Upon receving an unexpected block of data or error, resend the ACK
immediately instead of waiting till the expiry of receive data timeout
to resend the ACK.
* change the receive timeout value between retries to be 2xMINTMO.
Obtained from: Juniper Networks
Fixed by: Santhanakrishnan Balraj <sbalraj at juniper dot net>
to increase in steps of MINTMO, instead of doubling the timeout for every
retry.
Obtained from: Juniper Networks
Fixed by: Santhanakrishnan Balraj <sbalraj at juniper dot net>
It seems there have only been a small amount to the compiler-rt source
code in the mean time. I'd rather have the code in sync as much as
possible by the time we release 9.0. Changes:
- The libcompiler_rt library is now dual licensed under both the
University of Illinois "BSD-Like" license and the MIT license.
- Our local modifications for using .hidden instead of .private_extern
have been upstreamed, meaning our changes to lib/assembly.h can now be
reverted.
- A possible endless recursion in __modsi3() has been fixed.
- Support for ARM EABI has been added, but it has no effect on FreeBSD
(yet).
- The functions __udivmodsi4 and __divmodsi4 have been added.
Requested by: many, including bf@ and Pedro Giffuni
As noted in Austin Group issue #370 (an interpretation has been issued),
failing posix_spawn() because an fd specified with
posix_spawn_file_actions_addclose() is not open is unnecessarily harsh, and
there are existing implementations that do not fail posix_spawn() for this
reason.
Reviewed by: ed
MFC after: 10 days
as long as this does not happen, we need to fix interfaces to userland
in order to not break run-time accesses to the structure.
Reviwed by: kib
Tested by: pluknet
similar to what we do for binutils. When clang's default triple starts
with 'amd64-', it does not pass a proper -target-cpu option to its
first stage.
This can lead to problems, for example when structs are memcpy'd, and
clang erroneously assumes they are 16-byte aligned. It will then use
the 'movaps' SSE instruction to implement the copy, which results in a
bus error if the struct is really 8-byte aligned.
I encountered this issue when gcc's /usr/libexec/cc1 started crashing
with SIGBUS, after rebuilding world with clang ToT, but it also affects
the version of clang that we have in the tree. We were just lucky until
now, apparently. :)
Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.
Reviewed by: marius
Tested by: sbruno
Approved by: re
