- When operating on a core file (-M) and -c is specified we don't clear
the message buffer of the running system.
- If we don't have permission to clear the buffer print the error message
only. That's what Linux does in this case, where this feature was ported
from, and it ensures that the error message doesn't get lost in the noise.
Discussed with: antoine, cognet
Approved by: cognet
linux_file structure and use it instead of directly accessing td_fpop
when destroying the linux_file structure. The td_fpop pointer is not
valid when a cdevpriv destructor is run, and the type-specific close
method has already been called, so f_vnode may not be valid (and the
vnode might have been recycled without our own reference).
Tested by: Julian Stecklina <jsteckli@os.inf.tu-dresden.de>
MFC after: 1 week
This is a workaround for WITH_LDNS_UTILS forcing BIND_UTILS off. It can
be reverted when we no longer have these conflicting options, or made more
general if we grow more cases like this.
running state. fxp(4) requires controller reinitialization for the
following cases.
o RX lockup condition on i82557
o promiscuous mode change
o multicast filter change
o WOL configuration
o TSO/VLAN hardware tagging/checksum offloading configuration
o MAC reprogramming after speed/duplex/flow-control resolution
o Any events that result in MAC reprogramming(link UP/DOWN,
remote link partner's restart of auto-negotiation etc)
o Microcode loading/unloading
Apart from above cases which come from hardware limitation, upper
stack also blindly reinitializes controller whenever an IP address
is assigned. After r194573, fxp(4) no longer needs to reinitialize
the controller to program multicast filter after upping the
interface. So keeping track of driver running state should remove
all unnecessary controller reinitializations.
This change will also address endless controller reinitialization
triggered by dhclient(8).
Tested by: hrs, Alban Hertroys <haramrae@gmail.com>
about mount and unmount events. This is used by Juniper to implement a more
optimal implementation of NetBSD's veriexec.
Submitted by: stevek@juniper.net
Obtained from: Juniper Networks, Inc
when booting from ZFS turned out to also cause the boot path not being
adjusted if booting from CD-ROM with firmware versions that do not employ
the "cdrom" alias in that case. So shuffle the code around instead in order
to achieve the original intent. Ideally, we shouldn't fiddle with the boot
path when booting from UFS on a disk either; unfortunately, there doesn't
seem to be an universal way of telling disks and CD-ROMs apart, though. [1]
- Use NULL instead of 0 for pointers.
PR: 179289
MFC after: 1 week
This allows setting attributes on tables. One simply does not provide
an index in that case. Otherwise the entry corresponding the index has
the attribute set or unset.
Use this change to fix a relatively longstanding bug in our GPT scheme
that's the result of rev 198097 (relatively harmless) followed by rev
237057 (damaging). The damaging part being that our GPT scheme always
has the active flag set on the PMBR slice. This is in violation with
EFI. Existing EFI implementions for both x86 and ia64 reject the GPT.
As such, GPT disks created by us aren't usable under EFI because of
that.
After this change, GPT disks never have the active flag set on the PMBR
slice. In order to make the GPT disk bootable under some x86 BIOSes,
the reason of rev 198097, one must now set the active attribute on the
gpt table. The kernel will apply this to the PMBR slice For (S)ATA:
gpart set -a active ada0
To fix an existing GPT disk that has the active flag set in the PMBR,
and that does not need the flag, use (again for (S)ATA):
gpart unset -a active ada0
The EBR, MBR & PC98 schemes, which also impement at least 1 attribute,
now check to make sure the entry passed is valid. They do not have
attributes that apply to the table.
{,ipv6_}static_routes and rc.d/routing. For example:
static_routes="foo bar:em0"
route_foo="-net 10.0.0.0/24 -gateway 192.168.2.1"
route_bar="-net 192.168.1.0/24 -gateway 192.168.0.2"
At boot time, all of the static routes are installed as before.
The differences are:
- "/etc/rc.d/netif start/stop <if>" now configures static routes
with :<if> if any.
- "/etc/rc.d/routing start/stop <af> <if>" works as well. <af> cannot be
omitted when <if> is specified, but a keyword "any" or "all" can be used
for <af> and <if>.
"Startup"->"View/Edit Startup Configuration"->"Add New"->"Add From List":
[: -eq: unexpected operator
NOTE: Previously mentioned in r251557
Problem caused by removal of $retval to capture exit status of call to
f_dialog_input_rclist().
While we're here, enhance f_dialog_input_rclist() to accept a default-item
to make selecting multiple values to-add more efficient.
The superblock in ext2fs defines all the fields as unsigned but for
some reason the in-memory superblock was carrying e2fs_bpg and
e2fs_isize as signed.
We should preserve the specified types for consistency.
MFC after: 5 days
Based on r134760:
Reset the seek pointer to 0 when a file is successfully opened,
since otherwise the initial seek offset will contain the directory
offset of the filesystem block that contained its directory entry.
This bug was mostly harmless because typically the directory is
less than one filesystem block in size so the offset would be zero.
It did however generally break loading a kernel from the (large)
kernel compile directory.
Also reset the seek pointer when a new inode is opened in read_inode(),
though this is not actually necessary now because all callers set
it afterwards.
PR: 177328
Submitted by: Eric van Gyzen
Reviewed by: iedowse
MFC after: 5 days
After pushing in my fix for the 2 byte functions, I realized that the
functions for 1 and 2 byte operations had become identical. Reduce the
code size by merging the functions for 1 and 2 byte operations together.
While there, slightly improve variable naming and comments.
This small utility performs a sequence of atomic operations with random
parameters on an atomic variable. For every type, we also create 16
variables, to ensure that we test the correctness at different
alignments.
the performance conversion process.
The effect of this was the following error when selecting the menu
"Startup"->"View/Edit Startup Configuration"->"Add New"->"Add From List":
[: -eq: unexpected operator
By running `bsdconfig -d' as root to enable debugging, this turns into:
DEBUG: f_getvar: var=[text] value=[
Error: Expected a number for token 4 of --menu.
Use --help to list options.] r=0
[: -eq: unexpected operator
Indicating that the fourth token for --menu which should be $height was
instead a string (the first item of $menu_list) because it was using the
old size-calculation method and $size was now null (needed to use instead
the new size variables of $height $width and $rows).
the performance conversion process.
The effect of this was, when your /etc/defaults/rc.conf file changed
(based on md5(1)) and re-generating the file startup_rcconf_map.cache in
/var/run/bsdconfig/ you would get a screen-dump of its contents before the
menu would appear.
would not launch (and gave no error). This was easily diagnosed by running
`bsdconfig -d' as root and seeing the following error right after selecting
the "Ttys" sub-menu:
DEBUG: f_getvar: var=[text] value=[
Error: Expected at least 6 tokens for --menu, have 4.
Use --help to list options.] r=0
Typo was introduced by SVN r251361.
This is based on the AR933x (Hornet) SoC from Qualcomm Atheros.
It's a much nicer board to do development on - 64MB RAM, 16MB flash.
The development board breaks out the GPIO pins, ethernet, serial (via
a USB<->RS232 chip), USB host and of course a small wifi antenna.
Everything but the wifi works thus far.
"Login Management" module): Use default values for all account details?
If you select "Yes" (the default is "No"), you'll jump past all the prompts
and jump straight to the review screen with all-default values.
Makes adding a lot of users/groups faster/easier if you don't need to
customize more than one or two different values from their defaults.
fix the regression introduced by r251544; which was trying to make things
consistent w/respect to ESC versus YES versus NO in the password disable
prompt in "Login Management".
(need stronger coffee; very sorry for the churn)
With this revision, the "YES", "NO", and implied ESC options all work as-
expected. Choosing "YES" allows you to proceed and the password will be
disabled. Choosing "NO" will bring back around to enter a password for the
account. Pressing ESC will drop you out of either user or group input and
back to the usermgmt screen.
