output values of touchscreen position are more stable on my WS003SH
- also tidy up read and calc ops in max1233_readpos()
- turn DAC on in max1233_init() as well as max1233_resume()
that does. The former works all the time but the latter gets consistently
stuck on amd64. Mark the latter as an expected timeout (should be a "race
condition" test, but atf does not have such a thing yet[1]).
This clears the test failures, at least, under anita running NetBSD/i386.
From pooka@: this could well be because calling sem_post(3) from a signal
handler can't possibly do the right thing with the pthread implementation.
However, according to signal(7), sem_post(3) is signal-async safe...
While here, program alarms using a timeout shorter than 1 second to speed
up the execution of the tests.
1: Good thing is I finally understand what a "race condition" test looks
like, I believe.
- build glsl as a host tool
- add the glsl objects to libmesa
- add/remove new/deleted sources for various components
- adjust the libmesa/libGL builds to pull in the new glsl objects
- re-apply the BUILDSYMLINK hack for eval.c/pixel.c/pixelstore.c
- use glsl to build the slang headers on the fly
This makes my laptop boot instead of panic:
panic: kernel diagnostic assertion "native_idle != NULL" failed: file "../../../../arch/x86/acpi/acpi_cpu_md.c", line 155
fatal breakpoint trap in supervisor mode
type 1 code 0 rip ffffffff8022e4ad cs 8 rflags 246 cr2 0 cpl 0 rsp ffff80004c37db10
trace
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x2ba
kern_assert() at netbsd:kern_assert+0x2d
acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62
acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34
sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41
1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?
3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.
to validate the execution of sort(1) and do not bother removing temporary
files.
This is in preparation to merge the tests for sort(1) that still live in
regress/usr.bin/sort/stests.
larger than the upper limit constants. Only sanity check against these
defaults when operating with FADT. This is also noted in a fine print of the
specification (ACPI 4.0, p. 314): "[...] The worst-case latency to enter and
exit the C State (in microseconds). There are no latency restrictions."
atf. They break on i386 (because the test was conceptually broken anyway);
reported by pooka@ in private mail.
Now... the current test does not actually check anything AFAICT... but this
is how it was before.
