This code was written with wired ethernet in mind, where changes are
rare. However, on wifi the "media" changes all the time (switching
between different connection speeds). So, only log linkup and linkdown.
The other events are not that important.
Change-Id: Iaafb74ceb05a59dedf94184eee23a4e81fa5e983
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4827
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Number of retries could overflow. If we retry something more than 255
times and it fails, just stop, instead of flooding the network with
bogus requests
- The timeout could also overflow. It was stored in microseconds in a
time_t, which allows a bit more than an hour. This is fine for the
initial timeout (which starts at a few seconds and will go up to 64
seconds), but after that we switch to a slower rate driven by the
"state time". In particular, this can be the lease time, which DHCP
servers may set to several days, or at least easily more than an hour.
- The computaiton of the timeout in the "slow lease" case attempted to
do "not less than a minute", but missed a conversion from microseconds
to seconds so it ended up doing "not less than 60 microseconds"
The combination of all these things means we can end up with a negative
timeout, and we will send a burst of requests without ever stopping,
flooding the network.
Change-Id: I0eb811c90f4a4dd8c9d92bff728bc2bbb52fbd56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4826
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
used by PR_OpenSemaphore in NSPR to check the creator inited.
Change-Id: I626c6ab0d50896c94224718ca4fa0788f74ae27a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4824
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* We pack the first 8 bits into a union for the raw
edid since alignment matters.
* Handing the raw_edid is a bit ugly, so in the edid struct
we drop the input_type from the union since packing doesn't
matter as much.
Change-Id: I32dbfe9484f9eb83cf491a44d30a32ca36d65b7b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4775
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
each poll_fd struct should be checked, valid when not -1 and revents not zero.
Change-Id: Ia624ad1369ad1a6066c9970a47cfac63fa773702
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4821
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
the socket interface module checks the receive.low_water_mark to automatically
notify a read event. available_data will be zero, thus enabling the notification.
fixes the test poll_nm in NSPR.
Change-Id: I5354faec439df96671506550cdb144a45f6082b1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4820
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
<strstream> has been deprecated since C++98. Both GCC 2.95.3 and GCC 8.3 have
the successor <sstream> available, so use that one instead.
Change-Id: Ifefe686974864c2fd1d4a9d083294b1edb436fbd
PulkoMandy in cb3199681e changed
the _GetDomainSupport functions to always Ref() the the object.
However, that means in the case of the second _GetDomainSupport
function, which is implemented in terms of the first, we should
not call Ref() as this will create a double-reference.
Fixes a memory leak.
Change-Id: Ib82b2dadc0c8cc8d8f95efcffeb2430ac602a0a9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4791
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
LGTM seems to provide GCC 9.2, for which the flag -Wformat-diag is falsely
detected as supported.
Change-Id: I95a5946d9c6cd2af73e85070973f855fba3fcc39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4786
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
LGTM build failed since -Wformat-diag check is failed.
So we add g++ to check its version in LGTM.
May help to fix#17460.
Change-Id: I9400dbbab7800c522bf7ed797adae48299581a4e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4780
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change
Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Using a memcpy here is supremely dangerous, because we are writing to
an app_server buffer that we chose the length for, but using a size
that came from the client. And, indeed, because the buffer can contain
padding if the BBitmap was allocated with a non-standard BytesPerRow,
we will overflow the buffer and corrupt memory, causing app_server to crash.
So, instead, reorganize parameters a bit, and pass BytesPerRow along
with the other data needed to instantiate the bitmap, and then use
ImportBits.
Fixes an app_server crash I triggered with the experimental libX11
compatibility layer.
* Cut extra calls to display_get_encoder_mode
* Correct incorrect ucMiscInfo on table 1.6 via atombios
comments
Change-Id: Ib6d7938269b8421d3711c1344eab0b9842336932
* Looks like some error in atombios. AMD just
reversed the values instead of fixing the atom.h
defines in Linux.
Change-Id: I440682af5708ce0da1625e8f50e8cb77595c8397
* A first attempt at improving on #17377
* We haven't actually seen any cards using this
routing stuff yet pre-navi.
* We don't use the router information yet... but this might
improve things a bit on new cards.
Change-Id: I17962dfd8bb09e619a6084cd9571ccb9832fb19a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4697
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: If7feffafea4fc6d295d04f696127c8f0fbd8fb9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4704
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The previous round of this code unblocked after unset universally,
but that was incorrect in the case where the thread was not in
the "waiting" state before we unset. Yesterday I changed that to
just unblock before unset universally.
It seems, however, that thread_unblock is so time-consuming
that the other thread will wake up and begin doing things
before unblock returns for us, and then it will hit the timeout
before we have a chance to unset. So, now we unblock later
if it is possible to do so.
It seems very strange, though, that thread_unblock will
not return in a small but significant number of cases
before the unblocked thread actually starts running (note
that we are in interrupts-disabled mode here, so that is
not the problem.) That sounds like a problem for another day.
Should fix#17455, possibly in tandem with the previous commit.
This also fixes a leak of slots when initializing devices failed.
Fixes#16323, although there is some other underlying problem
which led to that error in the first place.
