side-effect of registering them, config_detach(9) cleared DVF_ACTIVE
before it called wddetach() or sddetach(). Even though sd(4)'s
detachment may have subsequently failed with EBUSY, we could not
begin new disk I/O on sd(4) because the device had been deactivated.
By analogy to sdstrategy(), test device_is_active() in wdstrategy()
and if it is false set b_errno to EIO instead of initiating new
disk I/O.
XXX We should decline more politely to start new I/O, since
XXX !device_is_active() may mean simply that the device is suspended.
XXX I suppose that EIO is safe as long as system suspension is
XXX all-or-nothing.
- allocate space for each cpu_info{} in pmap_bootstrap
- remap cpu0's space into the PA currently in CPUINFO_VA
- cpus[] becomes an array of pointers to cpu_info{}, easy to traverse
- only call kernel lock for IPL_VM interrupts (? as implemented on
x86 and sparc64)
- revert a minor part of locore.s:1.241
- in cpu_hatch(), set %sp to near the middle of the interrupt stack.
we only need a %sp until we get to run an MI thread (own idlelwp or
real code)
we still waste one page of space, but this gets SMP much closer to
actually working again.
Export i386/i386/gdt.c:update_descriptor() and use it in x86_set_sdbase(),
as a direct write to the GDT will cause a kernel trap.
Fix PR port-xen/41401.
sdhc_bus_clock() calls mutex_enter().
then in DIAGNOSTIC section, sdhc_bus_clock() calls sdhc_card_detect().
sdhc_card_detect() calls mutex_enter() on the same mutex again.
when LOCKDEBUG is enabled, you get
Mutex error: lockdebug_wantlock: locking against myself
BRDGGFLT and BRDGSFILT bridge controls are only available with BRIDGE_IPF and PFIL_HOOKS defined.
In amd64 GENERIC and XEN kernel configs PFIL_HOOKS is defined but BRIDGE_IPF is not.
When a BRDGGFLT or BRDGSFILT command comes in, then ifd->ifd_cmd is not in range
of bridge_control_table_size. Then bc is not set and is dereferenced
later => BOOM.
