Mere mortals like myself cannot understand more than two lines of
assembly without a million comments explaining what's happening, so do
that and make sure no one has to go on a wild stack state chase when
hacking on these.
The comments were confusing, and had a mathematical error, stop trying
to be clever and just let the computer do the math.
Also assert that we're pushing exactly as many stack elements as we're
using for the alignment calculations.
POSIX requires that sigaction() and friends set a _process-wide_ signal
handler, so move signal handlers and flags inside Process.
This also fixes a "pid/tid confusion" FIXME, as we can now send the
signal to the process and let that decide which thread should get the
signal (which is the thread with tid==pid, but that's now the Process's
problem).
Note that each thread still retains its signal mask, as that is local to
each thread.
Previously register_string would return incorrect values when
called multiple times with the same input. This patch makes this
function return the same index, identical strings. This change was
required, as this functionality is now being used with read syscall
profiling, (#12465), which uses 'register_string' to registers file
path on every read syscall.
If there's no PCI bus, then it's safe to assume that we run on a x86
machine that has an ISA IDE controller in the system. In such case, we
just instantiate a ISAIDEController object that assumes fixed locations
of IDE IO ports.
If there's no PCI bus, then it's safe to assume that the x86 machine we
run on supports VGA text mode console output with an ISA VGA adapter.
If this is the case, we just instantiate a ISAVGAAdapter object that
assumes this situation and allows us to boot into VGA text mode console.
Reading from /proc/pci assumes we have PCI enabled and also enumerated.
However, if PCI is disabled for some reason, we can't allow the user to
read from it as there's no valuable data we can supply.
To declare that we don't have a PCI bus in the system we do two things:
1. Probe IO ports before enabling access -
In case we are using the QEMU ISA-PC machine type, IO probing results in
floating bus condition (returning 0xFF values), thus, we know we don't
have PCI bus on the system.
2. Allow the user to specify to not use the PCI bus at all in the kernel
commandline.
This change allow the user to request the kernel to not use any PCI
resources/devices at all.
Also, don't try to initialize devices that rely on PCI if disabled.
Instead of winging it with "width * 4", use the actual pitch since it
may be different.
This makes the kernel text console show up in native 1368x768 on my
ThinkPad X250. :^)
We now only reset the PCM out channel during initialization, and handle
the case where the channel's current index has passed the last valid
index properly.
This fixes issues with stuttering audio between multiple subsequent
`aplay` invocations, for example.
This might help with debugging on bare metal. Since the minimum version
that can be specified is revision 2.1, and we do not use any feature
from revision 2.2 or newer, this is merely future-proofing ourselves
for new features yet to be built. Additionally, removing the `VERIFY()`
ensures we will not crash on cards that only support earlier revisions.
These are not technically required, since the Thread constructor
already sets these, but they are set on i686, so let's try and keep
consistent behaviour between the different archs.
The Qemu AC'97 device stops its PCM channel's DMA engine when it is
running and the sample rate is changed. We now make sure the DMA engine
is restarted after changing the sample rate, allowing you to e.g. run
`asctl set r 22050` during `aplay` playback.
In short: QEMU supports both Memory-Mapped-IO and classic IO methods
for controlling the emulated VGA device. Bochs and VirtualBox only
support the classic IO method. An excellent write up on the history of
these interfaces can be found here:
https://www.kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display
The IO method was how things were done originally in SerenityOS. Commit
6a728e2d76 introduced the MMIO method for
all devices, breaking Bochs and VirtualBox compatibility. Later in
commit 6a9dc5562d the classic IO method
was restored for VirtualBox graphics adapters.
QEMU and Bochs use the same PCI VID/DID (0x1234/0x1111) for the emulated
VGA adapter. To distinguish betwen QEMU and Bochs we use the PCI
revision ID field (0=Bochs, 2=QEMU).
This driver is not tested and probably not used on any modern hardware
machine, because it is plugged into the ISA bus and not the PCI bus.
Also, the run script doesn't utilize this device anymore, making it more
hard to test this driver and to ensure it doesn't rot.
The AP boot code was partially adapted to build on x86_64 but didn't
properly jump into 64 bit mode. Furthermore, the APIC code was still
using 32 bit pointers.
Fixes#12662
We already init receive buffer if we have singleport console, but if
we have multiport console that dynamically allocates ports we never
initted their receive buffers.
Some hardware controllers might reset when trying to do self-test, so
keep the configuration byte to restore it later on.
To ensure we are not missing the response from the i8042 controller,
bump the attempts count to 20 times after initiating self-test check.
Also, try to drain the i8042 controller output buffer as it might be a
early good indication on whether i8042 is present or not.
To ensure we drain all the output buffer, we attempt to read from the
buffer 50 times and not 20 times.
While investigating why gdb is failing when it calls `PT_CONTINUE`
against Serenity I noticed that the names of the programs in the
System Monitor didn't make sense. They were seemingly stale.
After inspecting the kernel code, it became apparent that the sequence
occurs as follows:
1. Debugger calls `fork()`
2. The forked child calls `PT_TRACE_ME`
3. The `PT_TRACE_ME` instructs the forked process to block in the
kernel waiting for a signal from the tracer on the next call
to `execve(..)`.
4. Debugger waits for forked child to spawn and stop, and then it
calls `PT_ATTACH` followed by `PT_CONTINUE` on the child.
5. Currently the `PT_CONTINUE` fails because of some other yet to
be found bug.
6. The process name is set immediately AFTER we are woken up by
the `PT_CONTINUE` which never happens in the case I'm debugging.
This chain of events leaves the process suspended, with the name of
the original (forked) process instead of the name we inherit from
the `execve(..)` call.
To avoid such confusion in the future, we set the new name before we
block waiting for the tracer.
This is very similar to the change that was done in 32053e8, except it
turned out that the new limit of 50 iterations was not enough when
testing on bare metal - most IO operations would succeed in the first or
second iteration, but two of them took 140 and 150 iterations
respectively.
Increase the limit from 50 to 250 to account for this, and have some
additional headroom.
This caused an initialization failure of the i8042 when I tested on
bare metal. We cannot entirely get rid of this method as QEMU for
example doesn't indicate the existence of an i8042 via ACPI, but we can
get away with only doing the manual probing if ACPI is disabled or we
didn't get a 'yes' from it.
Increasing the number of maximum loops did eventually lead to a
successful return from the function, but would later fail the actual
self test.
Arguments larger than 32bit need to be passed as a pointer on a 32bit
architectures. sys$profiling_enable has u64 event_mask argument,
which means that it needs to be passed as an pointer. Previously upper
32bits were filled by garbage.
