Previous commit adding these was merged very quickly, so here's one
more...
Change-Id: I23c424db7631db1f0ec48e2d0ae47c8409ae6af2
Reviewed-on: https://review.haiku-os.org/c/1088
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On x86 and x86_64, this warning is never emitted because it is perfectly
fine to do unaligned access. On sparc, such accesses are not supported
by the hardware and will generate a SIGBUS. This must be caught by a
trap handler, and the unaligned access performed there, slowly, using
byte by byte access.
However, making this a Werror is annoying because it will trigger
everytime one casts a byte pointer to something larger, even when
alignment is actually preserved. So, removing all such warnings would be
nearly impossible (for example, just for the mergesort function, there
is a whole GSoC project for it at FreeBSD).
Keep it as a warning for now. The warning can be silenced by using
BytePointer, if desired. We should also investigate where the SIGBUS
trap is triggered a lot and consider improving the alignment of data
where possible.
Change-Id: I6b90025e8c6d69ef1ccda3c10eee270ccc1ebd29
Reviewed-on: https://review.haiku-os.org/c/1103
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I'm copypasting a lot from this, so I may as well clean it up while I'm
at it.
Change-Id: I9288c087abbf95475f980b5539f2fd19fad7f775
Reviewed-on: https://review.haiku-os.org/c/1136
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
During the compilation of LLVM version 8, the build failed because it depends
on a constant in this file. In hrev49042 all BSD headers were feature-gated by
_BSD_SOURCE. This is not done (for this file) in glibc and (obviously) not in
BSD's libc.
Since this is not common practise, I would propose removing the feature gate
for this header file, as it would mean that we would have to upstream patches
for ports of other software that depends on the availability of these
constants.
Change-Id: I486f0c2e87eff489ce92d03589a6299ef1be6ca5
Reviewed-on: https://review.haiku-os.org/c/1144
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The tool "pkgman" was not showing it's help text
and this seems to be somehow related to the
initialization of constants such as
"kCommandCategoryPackages"; these values seems to
be coming through as empty-string for some reason.
I am changing those to be "#define" of regular
C-Strings and this seems to resolve the problem.
These values only seem to be used to group the
possible commands for production of the syntax or
help text - there do not seem to be any deeper
impacts beyond that functionality.
Change-Id: If9cd61462cd7f1f1b5ab2ece521bb3f00a1ba246
Reviewed-on: https://review.haiku-os.org/c/1139
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Operations that succeed should not take longer; ones that fail will.
Should get rid of ControllerReset() failed CMD_HCRST.
Change-Id: I4981a319bd64a076f2f404214a96d9909f0676de
Reviewed-on: https://review.haiku-os.org/c/1135
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* use --no-as-needed on Linux as the default changed some time ago.
* adjust LD_LIBRARY_PATH/LIBRARY_PATH to load in the current directory.
* fix some builds of program with compile_lib.
Only dlopen_lookup_next1 fails on Ubuntu 18.04.02 x86_64.
Change-Id: I6ecf70f742f67ab24d7d00fa615baa209634d02c
Reviewed-on: https://review.haiku-os.org/c/1140
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some operating systems only ship with Python 3 and the
binary for this is 'python3' instead of 'python' which
causes the Jam build process to fail because it expects
to find 'python'. This change will mean that the
configure process will detect this case and configure
the build to use the correct binary name.
Fixes#14938
Change-Id: I30cd0df828792715a54d760b86dd79aee04e2b2f
Reviewed-on: https://review.haiku-os.org/c/1134
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
In recent changes to HD's build files to generate
some sources at build-time there was a problem
with builds that were configured to run with some
element of concurrency. In this change, the steps
that should be in sequence are done with shell
commands to avoid race conditions.
Change-Id: I5b6fb4907d8ea5f3ca90de956ecce322cd89c685
Reviewed-on: https://review.haiku-os.org/c/1130
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Use the latest version of the compiler for bootstrap.
Change-Id: I43639b560de2d4f3dc3fed48c3d4bd32a544cb57
Reviewed-on: https://review.haiku-os.org/c/1104
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
This is my first commit, so bear with me if I've violated any standards here!
I've bumped a few offsets to fix text clipping in the Get Info window. The proper
long-term fix is to recreate this window with the layout library, but that's
a substantially larger job.
Patch set 1
Before: https://i.imgur.com/S7Pl5Qv.png
After: https://i.imgur.com/bd3H1Kw.png
Patch set 3
French: https://i.imgur.com/rpmUb5T.png
German: https://i.imgur.com/ca9DecW.png
Portuguese: https://i.imgur.com/dE8sKFI.png
The font size in the Permissions drop-down is fixed. I had previously bumped it to
12, to be inline with the default font size present in a new Haiku install. However,
that produced text clipping for French and other locales. I reverted it back to 10,
and now longer strings fit as-is.
Change-Id: I7f4412b10074c76eb5b023a231bdb6b230c8f35a
Reviewed-on: https://review.haiku-os.org/c/1073
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Remove memset(), since WebCamAddOn()::FillDefaultFlavorInfo()
at next line sets all flavor_info members except _reserved_[].
Change-Id: I41b4297a79303b61ccea914133b268b118b0d968
Reviewed-on: https://review.haiku-os.org/c/1118
Reviewed-by: Barrett17 <b.vitruvio@gmail.com>
Window must be locked or MidiRunThread crashes with a segment violation.
Change-Id: I9d5d0fa477475a9b5ba877aea3d6583690aacb2b
Reviewed-on: https://review.haiku-os.org/c/1080
Reviewed-by: Barrett17 <b.vitruvio@gmail.com>
We need to hold the endpoint lock while reading the TD list on
the endpoint, as otherwise we have no guarantee that the pointers
will not be modified while we are looking at them.
Since this is the only consumer of _UnlinkDescriptorForPipe, just
make that function assume a lock, and then do all locking within
HandleTransferComplete.
This went through review too fast, the wrong variable name was used so
the package name was not listed...
Change-Id: I81d4aa57fdb65297ae9f63ebf123d7a6395a99b6
Reviewed-on: https://review.haiku-os.org/c/1109
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The Browse button was misplaced when the "Start up" setting was
introduced recently. Moving it back into the "Download folder" row.
Move the "Download folder" row to the bottom of the group.
Have the text field of the days-of-history BSpinner not stretch
the whole window width.
Change-Id: I00260126cf7594f435899fa821e8bf79bb475ba8
Reviewed-on: https://review.haiku-os.org/c/1110
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Getting 64 bytes of data in a 32 bit variable is a bad idea
Change-Id: I760e1cfb996a9be053dbc50d6610b3e865cde65d
Reviewed-on: https://review.haiku-os.org/c/1096
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Don't set the IOC bit on the link TRB in LinkDescriptorForPipe. We don't
want to know about this' completion, only about the other transfers
completion and statuses. This should halve the interrupt rate.
* Check if this is an Event Data TRB, and return an error if it is.
(I haven't managed to trigger this code, but it is theoretically possible.)
* Rewrite loops for clarity and consistency.
* Use the correct offset when checking for the TRB.
- Don't rely on the trb_count to tell us whether the TRB is in the TD,
but just check the address based on MAX_TRBS_PER_TD.
- Previously, as the link TRB would trigger an interrupt, we could rely
on that to determine when the transfer finished. But that of course
did not tell us the correct status, as the link TRB is techically in a
different TD, as it isn't linked to the previous TRBs. Now we always use
"count - 1", which will be the final TRB in the TD, properly speaking.
* Print errors when we fail to find the TRB for any reason.
Reading multiple GB and abusing "stat" on a usb_disk following this commit
only managed to stall my usb_hid attached mouse once in multiple rounds of
testing, which seems a marked improvement; previously only a few hundred MB
and not that much abuse of "stat" were needed to actually trigger the stall.
So it seems this improves the stall situation considerably.
The TRB_3_DIR bit on the Status Stage was previously correctly set as per the spec:
Table 4-6: Status Stage TRB and Device-to-host and wLength > 0 means DIR OUT.
Also free descriptors when _LinkDescriptorForPipe fails.
There seems to be a problem with the way we set the gcc_bootstrap
package build to depend on the bootstrap package with haiku headers.
If said package cannot be built (for example some definitions are
missing for a new architecture), we end up passing an empty string as
the package to use to haikuporter.
The error message given by Haikuporter is confusing, and not easy to
investigate. So, intercept the error earlier to save time for the next
person to hit this problem.
Change-Id: I64f326e5cb3bb0d44632864ad38ad10bb88d0c7b
Reviewed-on: https://review.haiku-os.org/c/1082
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Fix dead initialization at line 596. Pointed out
by clang static analyzer.
* As a result, 'BMallocIO encodingIO' at line 524
becomes unused, so delete it and header.
Change-Id: Ia62184fe0682a2eedeee42a513faccabdd3d1b59
Reviewed-on: https://review.haiku-os.org/c/1079
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This is used quite a lot in critical transfer paths, so we don't
want to lock things up if no buffers are available for whatever reason.
Wait 2 seconds, and if we didn't get anything by then, return B_NO_MEMORY.
Possibly fixes or helps with certain USB-related lockups.
* Rearrange some basic setup to be more towards the top of the function,
so we have less things to tear down upon failures.
* Don't double-initialize qwtrb0 of the Setup Stage (no functional change.)
* Rework Data Stage initialization considerably:
- TD_SIZE refers to the number of remaining TRBs in this TD. As we only
use 1 TRB for the Data Stage TD at present, this should be 0, not 1.
- Actually copy data for outbound transfers. (This code does get hit,
so I'm not sure how it wasn't a problem previously.)
* Initialize the first quadbit of the Status Stage. (Potentially a
functional change.)
* Set the TRB_3_DIR bit on the Status Stage correctly as per the spec.
(See inline comment.)
Device initialization seems to behave much more smoothly now; at least on
my hardware, the "error Parameter" doesn't happen anymore, and of course
anything depending on outbound Control transfers will now work correctly.
I now get much better speeds from usb_disk, but I still see usb_hid stalls
after this patch.
Fixes various NULL dereferences in other parts of the USB stack
when the XHCI controller is not behaving quite as expected.
Possibly related to #13403.
