at some point result in a status event being triggered (it should
be a link down event: the Microsoft driver design guide says you
should generate one when the NIC is initialized). Some drivers
generate the event during MiniportInitialize(), such that by the
time MiniportInitialize() completes, the NIC is ready to go. But
some drivers, in particular the ones for Atheros wireless NICs,
don't generate the event until after a device interrupt occurs
at some point after MiniportInitialize() has completed.
The gotcha is that you have to wait until the link status event
occurs one way or the other before you try to fiddle with any
settings (ssid, channel, etc...). For the drivers that set the
event sycnhronously this isn't a problem, but for the others
we have to pause after calling ndis_init_nic() and wait for the event
to arrive before continuing. Failing to wait can cause big trouble:
on my SMP system, calling ndis_setstate_80211() after ndis_init_nic()
completes, but _before_ the link event arrives, will lock up or
reset the system.
What we do now is check to see if a link event arrived while
ndis_init_nic() was running, and if it didn't we msleep() until
it does.
Along the way, I discovered a few other problems:
- Defered procedure calls run at PASSIVE_LEVEL, not DISPATCH_LEVEL.
ntoskrnl_run_dpc() has been fixed accordingly. (I read the documentation
wrong.)
- Similarly, the NDIS interrupt handler, which is essentially a
DPC, also doesn't need to run at DISPATCH_LEVEL. ndis_intrtask()
has been fixed accordingly.
- MiniportQueryInformation() and MiniportSetInformation() run at
DISPATCH_LEVEL, and each request must complete before another
can be submitted. ndis_get_info() and ndis_set_info() have been
fixed accordingly.
- Turned the sleep lock that guards the NDIS thread job list into
a spin lock. We never do anything with this lock held except manage
the job list (no other locks are held), so it's safe to do this,
and it's possible that ndis_sched() and ndis_unsched() can be
called from DISPATCH_LEVEL, so using a sleep lock here is
semantically incorrect. Also updated subr_witness.c to add the
lock to the order list.
- "options" is followed by the characters \040\011, not \011\011.
Correct both my own sins and those of others.
- Comment blocks start and end with an empty line ^#$.
- Remove non-standard comments added in my last commit.
Requested by: njl
Correctness confirmed by: bde
since there are often significant holes in the memory map due to the
kernel, loader and OFW data structures not being included: Maxmem is
the highest available, so can be misleading.
them all, otherwise the driver will be useless and will only confuse user
as manual page says nothing about the need to enable one of those frame
types explicitly in the kernel config.
PR: kern/47152
Submitted by: Andriy Gapon <avg@icyb.net.ua>
MFC after: 3 days
as we can't rely on a trap happening, as it is done normally.
While I'm there, uncomment the call to cpu_dcache_wbinv_range() in
pmap_kenter_internal, as we don't call cpu_dcache_wbinv_all() there anymore.
asynchronously by different threads. Thus, declare as volatile the
reference count that is accessed through m_ext's pointer, ref_cnt.
Revert the previous change, revision 1.144, that casts as volatile a
single dereference of ref_cnt.
Reviewed by: bmilekic, dwhite
Problem reported by: kris
MFC after: 3 days
Beastie boot menu disabled,
acpi(4) turns ACPI and PCI devices off or to a lower
power state in suspend,
acpi_ibm driver added,
ed(4) ALTQ support,
ipfw(4) ucred-based rules can be used with debug.mpsafenet=1,
TCP-MD5 implementation in KAME IPv4 IPsec,
ftpd(8) 212 and 213 status code support,
gvinum checkparity/rebuildparity/setstate subcommand support,
periodic(8) security report now includes blocked packet
counts by pf(4),
ppp(8) NAS-IP-Address/NAS-Identifier options,
pppd(8) incorrect CBCP response fix, and
rescue(8) now includes BSD tar.
Update release notes:
rc.conf(5) network interface renaming support (MFC), and
markup fix in the entry of systat(1) IPv6 support.
Symptoms of the problem included assembler warnings and
nondeterministic runtime behavior when a fe*() call that affects the
fpsr is closely followed by a float point op.
The bug (at least, I think it's a bug) is that gcc does not insert a
break between a volatile asm and a dependent instruction if the
volatile asm came from an inlined function. Volatile asms seem to be
fine in other circumstances, even without -mvolatile-asm-stop, so
perhaps the compiler adds the stop bits before inlining takes place.
The problem does not occur at -O0 because inlining is disabled, and it
doesn't happen at -O2 because -fschedule-insns2 knows better.
