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.
for a signal, because kernel stack is swappable, this causes page fault
in kernel under heavy swapping case. Fix this bug by eliminating unneeded
code.
Change fhc(4) to use IRQ numbers instead of RIDs for allocating the
IRQs of children. This works similar to e.g. sbus(4), i.e. add the
IRQ resources as fully specified to the resource lists of the children,
allocate them like normal. When establishing the interrupt search the
interrupt maps of the children for a matching INO to determine which
map we need to write the fully specified interrupt number to and to
enable the mapping (before the RID was used to indicate which interrupt
map to use).
- dev/puc/puc.c:
Revert rev. 1.38, with the above change fhc(4) no longer needs special
treatment for allocating IRQs.
Thanks to: joerg for providing access to an E3500
