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
to 0x600 via a 'rep movsw'. Once that was done, %cx was zero, so we could
simply use 'movb' to update the lower byte of %cx in preparation for
zeroing out the fake partition entry used to boot to other drives via F5.
Well, in the new boot0, we don't actually relocate ourselves, instead it
is easier to create the fake partition entry first and then just use it to
get the BIOS to load all of boot0 into memory at 0x600. However, since we
aren't doing the relocate code anymore, we don't know that %cx == 0 when
we hit the 'movb' to setup %cx for clearning the fake partition entry.
Thus, if %ch != 0 when the BIOS started boot0, then it would end up zeroing
a lot more memory than just 8 words. The solution is to do a word move of
$8 into %cx.
Debugging help from: David Wolfskill <dhw@whistle.com>
explanations into a new file "refuse.README". Some users are simply
copying these files and expecting them to work -- without even
reading them. I don't want to spend any more time closing bogus
PRs from that.
Also correct an error or two in the patterns.
display control by apm -d.
- Remove APM_DEBUG to avoid re-build kernel with such a unspported optioin.
- Introduce new denug flag `debug.apm_debug' which can be controlled by
sysctl interface and loader by setting like "debug.apm_debug=1", you
will get debug messages from APM driver.
- Add some enhancements from linux on display control by apm -d. I'm
expecting that we can see some improvements on some laptops where
apm -d doesn't work correctly so far.
Reviewed by: -mobile and -current folks (no objection)
Suggested by: Susumu WAKABAYASHI <susumu@wakabaya.net>
modules to depend on modules in the same file (uhub depends on usb) or
even on themselves (usb on usb, makes the define in usb_port.h a lot
less convoluted).
Use ANSI prototypes.
the scratch RAM for data normally found in the SEEPROM (presumably in the
event that the SEEPROM is unavailable or can't be read). This code causes
a spontaneous reboot on monster.osd.bsdi.com, which has an embedded aic7880
controller. The problem appears to happen either when it writes to the
SCBPTR port and then reads from the SCB_CONTROL port. Somewhere during
the inb/outb operations, the system has a heart attack and restarts.
This code looks very suspicious, particularly since it has unconditionalized
debug mesages such as "Got here!" and "And it even worked!". With this
block #ifdef'ed out, the machine boots and runs properly. I stronly suggest
that it stay #ifdef'ed out until it's properly tested.
