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.
We really should not be writing raw structs out to devices
for endianness' sake, but that's currently what *all* the
USB bus drivers do with this struct. So, add the _PACKED flag
to ensure it's always precisely 8 bytes.
Additionally, remove memory_chunk, as nothing uses it anymore.
Some of the functions moved lower in this commit use functions
that were previously defined below them, which was a warning in
GCC but an error in Clang.
It warns when you try to use some standard library functions
without including the system headers, which we don't
care about as we are providing the system headers in the tree.
This just stops the errors from occuring rather than trying to
rebuild the files at all. This is much cleaner, and solves
a few cases that the other method did not.
Since NULL is not considered a user address anymore, we must check for
it first.
This fixes the "mount: Bad address" error after hrev52905.
Change-Id: If60ea58bb81b6c35c6bf27ecfa9b29bd7a25d8aa
The x86_64 buildmaster was only updated past the R1~beta1 version
a few weeks ago, so most packages still have a R1~alpha4_pm dependency.
Thus thus broke the build. Revert it for now so we don't do that.
- Bump year to 2019
- Adjust compat version, use alpha1 for x86 and generic packages, and
beta1 for other architectures since that's where they first appeared
(we will probably bump to beta2 for arm/sparc/ppc when we release
them for real?)
Change-Id: Ibb0968feb28731898776335eba01d34dcb758625
Reviewed-on: https://review.haiku-os.org/c/1069
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is technically only a functional change following the previous
commit, which unconditionally made sure the address was larger than
the base except for B_EXACT_ADDRESS. Essentially this makes sure
that if an address is passed which is smaller than the base is
passed in, it won't immediately fail just by being too small.
Checked against BeOS (0x0 passed to create_area with B_BASE_ADDRESS
succeeds, and returns 0x2000 consistently.) This is also needed
to not break userland initialization following the next commit.
VM86 was removed in 2012, so these are no longer needed.
The USER_BASE vs. USER_BASE_ANY distinction still seems like a
potentially useful one, though, so I've left all those changes in.
This reverts commit 58ed2965d0.
This reverts commit 055d49b1fd.
I was mistaken, it is perfectly legal to block a pinned thread.
It seems we'll need some other way to detect invalid context
switches.
int_io_* functions do not touch the thread state, but we already have
it here as we will modify its contents later, so it makes more sense
to set this flag here.
This is mostly only relevant following the previous commit, i.e.
finding interrupt handlers that brokenly try to context-switch.
Preventing "normal" context switches caused by a time interrupt
is the primary reason for pinning threads. "thread_block" and friends,
however, cause an explicit context switch and will not return until
another thread unblocks us.
Calling these while a thread is pinned is thus undefined behavior,
and so we should just panic in the case anyone attempts to do so.
Previously they would just get -1, as the BusManager class
would request their ID before they had been added to the Stack.
Now we add them to the stack inside ::Start(), rather than letting
the individual drivers do that just after ::Start(), and then assign
the ID there directly.
The Jam build logic for HaikuDepot was potentially creating
a dummy file that was newer than the generated .cpp/.h files.
This then, in turn, caused the dependent .o files to be
considered needing to be re-built. This change will ensure
that the dummy file is touched first so it is not newer than
the generated sources and also if the dummy does end up
being newer then the generated sources will be touched.
trac #14853
Change-Id: Ieefb0b2aa14bf43b7cbbdfee4228c215cad5b6fa
Reviewed-on: https://review.haiku-os.org/c/1070
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Let's make the nightly builds consistent in a way that they would always
be recognized by libosinfo (and, consequently, by GNOME Boxes,
virt-manager, virt-install, ...) by explictly using "nightly" instead
of the $(HAIKU_VERSION) when generating nightly builds.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
Change-Id: I6fc4f15be1e8e9244abf14e75308fc825f37b2e8
Reviewed-on: https://review.haiku-os.org/c/1053
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Another FileSystemVisitor implementation will be used for resizing
Change-Id: I2d5f47dcbefb4c76834487b194a99c6f5ae7de50
Reviewed-on: https://review.haiku-os.org/c/923
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>