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
add a default case to handle the situation when the variables are not
initialized.
Furthermore, abort() if the snmp agent passes an invalid option to the
bridge module. As the option (SET, GET, GETNEXT, COMMIT, ROLLBACK) is
determined by the snmp agent based on the operation requested by user,
this behaviour is unlikely to be abused as a source for a DoS, but if
ever hit will likely reveal a problem in the snmp agent or bridge
module.
Approved by: bz (mentor)
flag set, rmdir(2) returns EPERM.
- If the parent directory of the directory to be removed has its immutable or
append-only flag set, rmdir(2) returns EPERM.
immutable or append-only flag set, rename(2) returns EPERM.
- If the parent directory of the file pointed at by the to argument has its
immutable flag set, rename(2) returns EPERM.
- 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
This s part of an import of the PVR-250 driver. Originally it was
calleed pvr250-setchannel, but it seems better to improve this program
to work for any tuner card, so I'm starting with a more generic name.
That shouldn't mislead anybody: currently the program only works with
the (yet to be committed) cxm driver.
Contributed by: John Wehle <john\@feith.com>
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
: fdisk.c revision 1.74
: date: 2004/06/14 07:21:19; author: phk; state: Exp; lines: +3 -3
: Make fdisk initialize the first instead of the last slice by default.
After a change of devd.conf, devd(8) handles NIC attach/detach event
by using /etc/pccard_ether with the interface name as the argument.
This model does not work properly with IPv6 configuration because the
implementation of IPv6 stateless auto-configuration in the FreeBSD
rc.d scripts depends on whether there are any explicit configurations
for interfaces or not. It works this way: if no manual configuration,
it will perform auto-configuration, but otherwise no
auto-configuration will be performed. So, this behavior can only be
determined by all of the interfaces on a system, not a single one.
For this reason, the network6_interface_setup() function called from
the pccard_ether_start() does not work with a single interface name.
And what is worse, this combination of devd.conf and
pccard_ether_start() caused a bad side-effect that when
ipv6_enable=YES, all of interfaces marked as DOWN would be UP
unconditionally (and router solicitation was sent) just after devd(8)
was invoked. This should be fixed in a more sophisticated way.
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
