the BIOS is reporting (and speedfan for windows).
* Simplify the code.
* Remove unused functions and unnecessary variables.
* Provide more rfact values for the voltage sensors (from OpenBSD).
* Remove the limit of 1.5 seconds for refreshing the sensors, it's
unnecessary... we can read it every time we want.
Now I'm happy with the driver (code and envstat output):
[juan@nocturno][~]> envstat -r
CPU Temp: 38.000 degC
System Temp: 36.000 degC
VCORE_A: 1.664 V
+3.3V: 3.312 V
+5V: 4.919 V
+12V: 12.480 V
VBAT: 3.248 V
CPU Fan: 3096 RPM
System Fan: 0 RPM
[juan@nocturno][~]>
- In xencons_handler(), update in_cons inside the loop, otherwise,
we would trigger the xenconscn_getc() workaround wich reset cons and prod
to their original values, and this creates an infinite loop
Should fix the console hang reported by several users on port-xen@.
(the relevant changes haven't been done though).
Call built binary bootxx_fat16 for consistency.
Use 'push %cs' to push a zero value in places where we had relied on %bx
being zero from much higher up the code.
on comparisons < 0, since they can never be true. All register_t's should
be made signed, and this commit should be reverted. For now cast to int,
since the syscall code is a small number and guaranteed to fit.
make the default values of bidirectional pins `output' because
they were often the main reason of no sound problems.
* add stac9221_mixer_init()
It has a code for Intel Mac but it is disabled for now.
server that it needs to mount the file system backend if it wants
to call mount
* provide some options for getmntopts(), assume that callers will parse
command line (or fstab) args
* reorganize the puffs_cc interface just a bit, preparing for a bigger
revamp later
mapping of msgbuf during startup may map invalid physical adresses
Apply a similar patch as in the i386 case.
The amd64 version was supplied by Blair Sadewitz, thanks.
mapping of msgbuf during startup may map invalid physical adresses
"If the last available physical memory segment on a system is less 16k,
than the startup code that will map the kernel message buffer, will fail
and map physical pages behind the last segment. This may either only lead
to a message buffer without physical memory behind it, or to an
overlapping message buffer with something else."
Fix by allowing multiple physical memory segments to be used for msgbuf.
Also remove some leftover msgbuf manipulation from pmap.c.
Fix supplied by Wolfgang Stukenbrock in the PR, with some modifications
from me, mainly to use the already existing constant VM_PHYSSEG_MAX as the
static limit of number of msgbuf segments.