Either they're there early and the ispfw sets have
registered themselves, or they're not.
The module dependency stuff isn't quite what we want
anyway. If the user doesn't want the load placed on
system memory by loading the firmware, they don't
specify it to be loaded (either by being linked in
or via being a module to be loaded and then hooked
in with firmware(9)). It doesn't then make sense to
then override what they want by pulling it in anyway.
This might be able to work if we were able to pull in
just exactly what we needed for the card we have- but
that's an optimization left for the future.
at which the kernel should start allocating physical memory. The primary
purpose of this is to test 64-bit cleanness of the data path by setting
hw.physmemstart=4G so that all physical allocations are above 4GB. AMD64
and i386/PAE could also benefit from having this option.
just the intenral phy on parts supported by the rl and re drivers, the
RTL8201BL for example. He also sent me a nice picture of hundreds of
these chips in a tray to boulder his claim. :-) Therefore remove a
comment that suggested that they were...
is already bounded by hw.physmem to calculate phys_avail[] - previously only
real_phys_avail[] was being bound by hw.physmem so we were allocating memory
that wasn't mapped in the direct map
- shuffle memory range following kernel to the beginning of phys_avail
- have the direct area use 256MB pages where possible
- remove dead code from the end of pmap_bootstrap
- have pmap_alloc_contig_pages check all memory ranges in phys_avail before
giving up
- informal benchmarking indicates a ~5% speedup on buildworld
an "export" flag indicating that we are trying to NFS export the
filesystem, and the MSDOSFS_LARGEFS flag is set on the filesystem,
then deny the mount update and export request. Otherwise,
let the full mount update proceed normally.
MSDOSFS_LARGES and NFS don't mix because of the way inodes are calculated
for MSDOSFS_LARGEFS.
MFC after: 3 days
The symptoms were that outgoing DHCP requests for diskless kernels
had the IP header corrupt. After long investigations, the source of
the problem was found in ether_output() - for SIMPLEX interfaces
and broadcast traffic, a copy of the packet is passed back to the kernel
through if_simloop(). However if_simloop() modifies the mbuf, while
the copy obtained through m_copym() is a readonly one.
The bug has been there forever, but it has been triggered only recently
by a change in sosend_dgram() which passed down mbufs with sufficient
space to prepend the header.
This fix is trivial - use m_dup() instead of m_copy() to create
the copy. As an alternative, we could try and modify if_simloop()
to play safely with readonly mbufs, but i don't think it is worthwhile
because 1) this is a relatively infrequent code path so we do not need
to worry too much about performance, and 2) the cost of doing an
extra m_pullup in if_simloop() is probably the same as doing the
copy of the cluster, anyways.
MFC after: 1 week
field to "unsigned long" so that it actually works.
Thanks to Robert Sciuk for sending me a DVD that
demonstrated ISO9660-formatted media with a file >2G.
I've now fixed this both in libarchive and in the cd9660
filesystem.
MFC after: 14 days
timer in xl_txeof()/xl_txeof_90xB(); xl_poll_locked() unconditionally
invokes xl_txeof()/xl_txeof_90xB(), effectively circumventing that
the watchdog ever fires in the DEVICE_POLLING case as its timer is
constantly reloaded.
- Remove the banal and pedantically outdated comment regarding setting
xl_wdog_timer to 0 in xl_txeof().
Pointed out by: bde
(somewhat) meaningful message and terminate the build. It'd be
nice to print a proper URL from which to fetch the file but that
seems problematic. Leave a suggested starting point in this file
(TBD: add it to the man page).
Submitted by: ru
to workaround the problem with SMP kernels on Turion64 X2 processors
described in kern/104678 and may be useful in other situations too.
MFC after: 3 days
rather than treating them as a fatal exception and halting. At least one
storage BIOS (some newer mpt(4) parts) have a breakpoint instruction in
their disk read routine.
MFC after: 3 days
Make part of John Birrell's KSE patch permanent..
Specifically, remove:
Any reference of the ksegrp structure. This feature was
never fully utilised and made things overly complicated.
All code in the scheduler that tried to make threaded programs
fair to unthreaded programs. Libpthread processes will already
do this to some extent and libthr processes already disable it.
Also:
Since this makes such a big change to the scheduler(s), take the opportunity
to rename some structures and elements that had to be moved anyhow.
This makes the code a lot more readable.
The ULE scheduler compiles again but I have no idea if it works.
The 4bsd scheduler still reqires a little cleaning and some functions that now do
ALMOST nothing will go away, but I thought I'd do that as a separate commit.
Tested by David Xu, and Dan Eischen using libthr and libpthread.
driving xl_watchdog() in order to avoid races accessing if_timer.
While at it relax the watchdog a bit by reloading it in xl_txeof()/
xl_txeof_90xB() if there are still packets enqueued.
- Use bus_get_dma_tag() so xl(4) works on platforms requiring it.
- Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that.
hme_watchdog() in order to avoid races accessing if_timer.
- Use bus_get_dma_tag() so hme(4) works on platforms requiring it.
- Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that.
gem_watchdog() in order to avoid races accessing if_timer.
While at it relax the watchdog a bit by reloading it in gem_tint()
if there are still packets enqueued.
- Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that.
- Fix inconsistencies in prototypes.
depending on the NIC and isn't used at all with HomePNA links)
instead of if_slowtimo() for driving dc_watchdog() in order to
avoid races accessing if_timer.
- Use bus_get_dma_tag() so dc(4) works on platforms requiring it.
- Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that.
- Remove an alpha remnant in dc_softc.
of the nvenet lib upgrade (the constant went from 63 (2^n - 1) to
32 (2^n)). For reasons that are not obvious to me this fixes the driver
on at least some NICs.
MFC after: 3 days
