* LoadFinished is called after redirects have taken place, so we can
show the final URL. It's also called for navigation inside a document
(jumping to anchors), whereas LoadCommitted is not.
* LoadCommitted is called earlier so we also want to set the URL there.
* At least some nVidia HDA controllers do not acknowledge the CORB
read pointer reset, which is required by the spec (cf. HDA 1.0a
ch. 3.3.21). For these controllers, do not fail when acknowledge
is missing.
* Makes hda driver work for nVidia HDA controllers again, thus fixing
the regression pointed out in #10212.
* Category identifyers are lower-case, we can use the "name" facility which
already existed for this purpose and simply iterate the list of known
categories.
* The getBulkPkg method now takes the architectures as a list as well,
helps with finding the right package in case there is a mix of
architectures across the requested package names.
* Some chipsets do not support bus-snooping for the HDA data
transfers. So, when trying to enable snooping, verify that the
setting was accepted.
* When snooping is not possible, set memory areas for audio buffers,
buffer descriptor lists and command ring-buffers as uncached to
ensure memory coherency with the HDA controller.
* This fixes KDLs during booting on some systems where snooping
is not supported (seen on two systems with AMD chipsets, maybe
applies to others as well).
After setting up the buffer descriptor list for a stream, it was a
gamble whether these writes would be visible to the HDA controller
when subsequently enabling the stream. On some boots it was unlucky
and then the HDA controller's DMA engine would go haywire and start
overwriting random kernel memory with audio input data. The
scheduler was usually the first victim and caused page fault KDLs
due to corrupted data structures.
* Do read-modify-write cycle to preserve bits marked as RsvdP in the
following registers: WAKEEN, CORBWP, CORBCTL, CORBSIZE, RIRBWP,
RINTCNT, RIRBCTL, RIRBSIZE.
* Spec requires software to wait for hardware to acknowledge the
reset by waiting for the bit to become set and then manually
unset it and again wait for it to become unset.
(cf. HDA spec 1.0a ch. 3.3.21)
* Also, do read-modify-write to protect preserved bits
Now that the fake packages are in place, it is much easier to build the
MMC image for ARM without the need for a bootstrap build.
This image still does not manage to access the tarfs and load the kernel
modules, but it gets to KDL, at least.
Needed for the test_app_server.
The logic here may need some improvements, but I'm not sure how to find
the right library name in all cases. I fixed at least the x86_gcc2 case
here.
- Revert the change to BuildFeature since the latest version of the zlib
sources package indeed uses the correct "sources" directory.
- Make the fake zlib package for ARM use the same revision number as the
current zlib version (4) so it can use the current version of the source
package instead of some older one.
This fixes the non-bootstrap ARM build.
I'm not sure this is the right fix, the zlib package seems to come with a
"source" (not "sources") folder on both ARM and x86_gcc2 but then I
don't understand how this worked for the x86_gcc2 build before.
This shoiuld make OpenSSL more thread safe and help with the random
network related crashes in Web+ (and anything else using SecureSocket
with more than one thread).
As the keyboard is used from usb_hid in the userland as well, we quite
probably are not in sync with the data toggle. Clearing the stall
should restore the toggle and make things work.
It constructs a clear feature request for the endpoint halt selector
and sends the request using debug transfers. Clearing a stall condition
can be done safely and has one nice side effect: it reinitializes the
data toggle to a known state. This command can therefore be used when
a pipe is possibly used from userland as well and the data toggle may
therefore be out of sync.
Pull debug transfer methods into the base BusManager class and
implement them for UHCI and EHCI. This makes it possible to have a
single debugger command installed by the USB stack instead of HCI
specific ones.
The alternate pointer is the software equivalent of the alternate
physical address in the hardware queue head part. The controller
follows that path, so we can follow the alternate pointer as well.
Simplifies and generalizes the logic.
Michael Lotz