* This fixes booting on virtualbox with UEFI, where it
fails to identify CDs as BOOT_METHOD_CD, such that the
write_overlay driver doesn't get loaded, causing a
panic in the kernel trying to mount the boot device.
Change-Id: I1f23b4c4195668752357735368f4668b73f75980
The package kit calls this function to print errors it hits
when reading packages. We should never hit this in "normal
operation", but it should help with debugging #14993.
Inside the device_consumer thread, the sequence of operations was this:
1. Call fifo_dequeue_buffer()
2. If it returned B_INTERRUPTED, exit the thread. Otherwise, process
the buffer it returned as normal.
3. Loop.
Thus, if the FIFO was destroyed not during a call to
fifo_dequeue_buffer, the next loop, fifo_dequeue_buffer would
be called on a destroyed FIFO. It would then try to lock the mutex
in the FIFO which had been destroyed, causing an assertion failure
and thus a panic.
Now, we check the ref_count on every loop, and set it to 0 before
calling uninit_fifo(). Thus, even if we are in the middle of a loop
inside the FIFO thread, the loop iteration condition will fail
and thus the thread will exit, avoiding the race.
Probably this was not an issue before because the timing required
to hit this is incredibly unlikely. With the new ipro1000 driver
(or kallisti5's WIP TUN/TAP driver), the timing makes this much
more likely.
Should fix#15024.
* Oops, there's a standard for these. Stick to the standard.
* Add a few that could be useful someday.
* Mention iana spec.
Change-Id: I4cf75e8c1e4b25f65d10921c7075fbd53f44e14e
Show warning in the touchpad preference dialog box when user is not connected and also disable touchpad preferences except touchpad view.
Change-Id: I52b80e834ee3bb37d568aa065942eae405001343
Reviewed-on: https://review.haiku-os.org/c/1344
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This fixes booting on virtualbox with UEFI, where it
fails to identify CDs as BOOT_METHOD_CD, such that the
write_overlay driver doesn't get loaded, causing a
panic in the kernel trying to mount the boot device.
Change-Id: I63046d976661500227604bf01cc1631f1ae2b608
Reviewed-on: https://review.haiku-os.org/c/1406
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On VirtualBox, the reported maximum transfer size is 2MB; but all
I/O >= 753KB fails in an identical way to the "maximum size" failures.
In other news, there are multiple open tickets in the VirtualBox
tracker about Linux systems failing to boot off NVMe...
I tested with a hacked-in maximum segment size of 752KB and everything
seemed to work just fine. Writing a HPKG to a FAT partition on NVMe,
rebooting, and then reading back the HPKG showed it had the same
sha256sum as the one stored in /system did. So this is working!
Before this commit, only one qpair was allocated and it was
locked for the duration of the transfer. Now we allocate more
qpairs if the device supports it and lock only when actually
calling read(), enabling multiple reads to both be queued
and execute simultaneously.
This is probably a significant performance improvement,
even more so than it is/would be for SCSI, as SSDs
can actually read from as many sectors as bandwidth
allows at once.
* Modeled after pppconfig to some degree.
* Normally various VPN and other services will create / manage
tunnels directly, however this gives us a good way to
test / play with things initially.
As the comment implies, we don't want to wait here, but low_resource()
waits forever when timeout=0. It doesn't seem to do anything with the
"size" argument at all, so not calling it is just as effective, and so
replace the comment there altogether.
The case where this was most often hit, causing a full system deadlock
in anything relating to memory management, was when the passed "size"
was 0. So now we check for this case explicity at the beginning and
panic() on KDEBUG kernels for it.
This is the cause of #14557. It seems that OpenBSD does the same thing.
I didn't read the spec yet to determine precisely what this means,
so for now, just do what OpenBSD does and bail.
This only seems to happen with a secondary XHCI controller on that
device, so hopefully most USB ports will still work.
The previous version did not account for the position not being a
multiple of the block size, among other problems.
Tested by hand with DiskProbe and then "dd skip=..." to read single
bytes from partial blocks, and validated as correct.
Only one qpair is used for reading, which is rather inefficient.
We currently allocate a bounce buffer for every allocation, which is
also inefficient, due to the fact that we must read an integer multiple
of LBAs.
But it does work, and it is actually reasonably fast, even on an emulated
machine using a spinning-disk-backed NVMe device (88MB/s.)
I wasn't able to get it working in non-packaged, though; the device manager
called supports_device() on a number of PCI devices, but not the NVMe
device, so I have a different version with a hack that grabs the PCI info
manually. I didn't test inside haiku.hpkg yet; perhaps it will work in there.
Previously it was possible that we put() them twice, leading to
assert-failure panics as their ref-counts would go below 0.
Now we get() them once for every bus object that we create, as
the destructors put() them.
Should fix the panic in #15004.
... based on mouse type setting in Mouse Preferences.
for (default) 3 button mouse, nothing changes. #important
for 1 button mouse,
emulate right click by ctrl+click. This replicates Tracker
behavior everwhere
for 2 button mouse,
add todo to emulate middle click by pushing both buttons at
the same time. Unfortunately I was unsucessful getting this
feature to work.
Change-Id: I5377ed5b4967483096f7f185f434bced3f86cdb9
Reviewed-on: https://review.haiku-os.org/c/303
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
