This makes the output much easier to read (e.g. "write(...)" vs.
"_kern_write(...)") and similar to strace/dtrace/etc. output
on other platforms.
Change-Id: Iac8e32aae0dcf3731a348c6192203f8d5b54da7a
Reviewed-on: https://review.haiku-os.org/c/1451
Reviewed-by: Bruno Albuquerque <bga@bug-br.org.br>
- Did not see his comments before pushing my previous change.
- clear owning flag when passed value is NULL.
Change-Id: I493973aff2b107785c3734847c85a52f0f9da360
Reviewed-on: https://review.haiku-os.org/c/1443
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fixes#15056.
Change-Id: I48c00b955346971aa88b731ccad1953a4044983d
Reviewed-on: https://review.haiku-os.org/c/1442
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
- Keep track if the softc was allocated externally or not.
- Only try to deallocate it if it was allocated internally.
Do not try to free the softc if we were not the ones allocating it.
- Avoid a double free on consecutive calls to device_set_softc.
Change-Id: Ibb38e54e9dfd2a80dbb53920970bead626da8ba1
Reviewed-on: https://review.haiku-os.org/c/1441
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Since not everyone likes the default, make it an option in the vesa
settings file. Note setting a mode with the Screen prefs overwrites
the file so it will discard the option.
Also move the code to get_mode_from_settings() since we can't load driver
settings as early as vesa_init().
Change-Id: I93080bd1fbc064dab053624ad37935268b1ed17d
It is very, very rarely used, and is extremely wide on some locales
(i.e. almost 2x the width of the other buttons combined), making it
appear out of place. Now that it can be done from Debugger, having
it here does not seem to make a lot of sense.
As requested and discussed in #14777.
* mutex_destroy() only checked wether or not there were waiters,
not if the lock itself was presently held by another thread.
Now we do, which should make #15015 panic much earlier instead
of trying to use freed memory.
* mutex_transfer_lock() and recursive_lock_transfer_lock() did
not check that the calling thread actually owned the lock.
Now it does, which should trigger asserts if anyone tries
to do this.
We need to call pci_ram_address() on the whole address, not just the
lower 32 bits, and then store both components inside the PCI info
(previously we were leaving the high bits unset.)
Very few drivers bother to check if the address is 64-bit or not,
and for the most part they don't need to care, since the PCI bus
is at 0x0 physically and will pretty much never get anywhere near
4GB in size. But the XHCI driver read these, and so would get
bogus values for the high 32 bits, as we were never setting those.
Probably fixes#15040.
cache_io() did some bounds checking, but for uncached reads it was
entirely on the filesystem. Now we are more consistent: do all the
bounds checking for reads in the file cache, and do all bounds
checking for writes in the filesystems.
This makes sense as nearly all file systems were doing the exact
same logic for read() but of course all have different logic
for write(), due to block allocation, etc.
This potentially fixes#14993.
Change-Id: Iaf3e549001344cf375c7b8de549fc169d77bdbb2
Reviewed-on: https://review.haiku-os.org/c/1420
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This makes the behavior more standard, is still to be used with libroot_debug.so
for instance.
The old behavior is obtained with "LD_PRELOAD_ADDONS"; in fact a runtime_loader add-on
needs to be entirely loaded before the executable to be effective. To be used with
libltrace_stub.so for instance.
Change-Id: I8536c5b8873f975405bea9eb4e2b92febabfc78a
Reviewed-on: https://review.haiku-os.org/c/1409
Reviewed-by: Jérôme Duval <jerome.duval@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: 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.
