passing a zero-valued timeout, the code would always sleep for one tick.
Change code to avoid calling tsleep if we have no intention of sleeping.
Bring in bugfix from sys_select.c, r1.60 which also applies here.
Modify error handling slightly; passing in an invalid fd will now result
in EBADF returned in the eventlist, while an attempt to change a knote
which does not exist will result in ENOENT being returned. Previously
such attempts would fail silently without notification.
Pointed out by: nicolas.leonard@animaths.com
Rick Reed (rr@yahoo-inc.com)
if their SUPFILE variables are defined _and_ NO_PORTSUPDATE and
NO_DOCUPDATE respectively are not defined.
Previously, only ports was updated and there was no way to prevent
this without undefining its SUPFILE variable.
PR: 17514
Reported by: Udo Erdelhoff <ue@nathan.ruhr.de>
With more than 1 AP present, an AP could fail to properly release
the mp lock before waiting for smp_started to become nonzero.
With early startup of APs, the BSP could fail to properly release
the mp lock before waiting for smp_started to become nonzero.
cases the registers are not correctly set on resume.
This solves the problem of USB failing after resuming a machine.
Submitted by: mike+fbsd@medianstrip.net
PR: 18261
Promise Ultra100 / Fasttrak100
HighPoint HPT370 controllers (fx Abit KA7-100 onboard ctrl, Abit HotRod 100)
Intel ICH2 (Intel 815E based motherboards)
So far I can read >90MB/s on the Promise and the HPT370.
I can write >64MB/s on the promise and >50MB/s on the HPT370 so it seems
writing is still done in ATA66 mode :(
The ICH2 support is untested as of yet...
panicing and return a status so that we can decide whether to drop
into DDB or panic. If the status from isa_nmi is true, panic the
kernel based on machdep.panic_on_nmi, otherwise if DDB is
enabled, drop to DDB based on machdep.ddb_on_nmi.
Reviewed by: peter, phk
Don't allow cpu entries in the MP table to contain APIC IDs out of range.
Don't write outside array boundaries if an IO APIC entry in the MP table
contains an APIC ID out of range.
Assign APIC IDs for all IO APICs according to section 3.6.6 in the
Intel MP spec:
- If the current APIC ID on an IO APIC doesn't conflict with other
IO APICs or CPUs, that APIC ID should be used. The copy of the MP
table must be updated if the corresponding APIC ID in the MP table
is different.
- If the current APIC ID was in conflict with other units, the
corresponding APIC ID specified in the MP table is checked for conflict.
- If a conflict is still found then fall back to using a new unique ID.
The copy of the MP table must be updated.
- IDs out of range is considered to be in conflict.
During these operations, the IO_TO_ID array cannot be used, since any
conflict would have caused information loss. The array is then corrected,
since all APIC ID conflicts should have been resolved.
PR: 20312, 18919
