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.
pc98).
(While here, remove mention of 80386 custom kernels since support for the
80386 has been removed from CURRENT.)
Feedback from: bde, des, imp, jhb
"Userland Changes" section. I'm pretty sure this is all my
fault...only a native English^H^H^H^H^H^H^HAmerican speaker could mess
it up this badly.
No content changes.
