must have been inadvertently changed to '>'. This broke nfsm_adv()
in the case where the advancement count is equal to the amount of
data remaining in the current mbuf. Instead of moving the current
position N bytes forward, nfs_adv() could end up moving it back to
N bytes from the start of the mbuf data.
This should fix the client-side readdirplus problems that have been
reported since September.
In order of importance:
* Make ugen use updated frlengths.
* More tests for NULL pipes.
* Generate better error codes on bulk write.
* Error messages in general.
IPv6 on an sppp interface. In an IPv6-enabled kernel, every IPv6
interface automatically gets an IPv6 address assigned (and IPv6
multicast packets sent at initialization time). For sppp links where
we know our remote peer wouldn't support IPv6 at all, there's no point
in attempting to negotiate IPV6CP (or to even dial out for an IPv6
packet at all for dial-on-demand interfaces).
I wish there were a more generic way to administratively disable IPv6
on an interface instead. ume told me there isn't.
While i was at it, converted both, enable_vj and enable_ipv6 into flag
bits in struct sppp (enable_vj used to be an int of its own).
MFC after: 1 month
of unused partition entries and later detection of unused entries.
Use memcpy to be consistent with the rest of the code, and fix a
minor style nit.
Submitted by: bde
it again when going from INITIAL to STARTING. This has been done for
passive or auto-conecting interfaces always, but not for permanent
ones.
Obtained from: NetBSD (rev 1.32)
& and && has been botched. This was likely the cause for some havoc
with various negotiation cases of sppp in the past.
Obtained from: NetBSD (rev 1.13)
MFC after: 1 week
makes the implied assumption there were another 128 bytes of space in
front of the packet handed off to it... which is not the case for
sppp. This could easily end up in corrupting random memory.
This fix is about the same as revs 1.6, 1.8, and 1.9 from our
i4b_ispppsubr.c.
Also fixed IPCP option negotiation to zero out the options when
starting IPCP. Otherwise, if negotiation parameters change between
various IPCP startups, it could happen that old options would still be
requested (this happened if VJ was turned off, and ended up in half
off the link still negotiating for VJ compression).
IMHO, the base system's sppp is now feature-wise up to date with the
one in the i4b part of the tree, so the latter can be disabled.
MFC after: 1 month
a special file on the command line, eg:
sysctl kern.dumpdev=/dev/ad1s1b
In parse(), when a value is given for a CTLTYPE_QUAD variable,
newval and newsize erroneously fail to be set because of an early
"break".
show_var() contains code that duplicates the functionality of the
oidfmt() function.
PR: 33151, 33150
Submitted by: Thomas Quinot <thomas@cuivre.fr.eu.org>
o Do not use a special struct to keep track of CPUs we found;
instead, use struct pcpu. This handles all the magic WRT
thread creation (yay!).
o Respect MAXCPU.
o Use the vhpt_base and vhpt_size values to initialize the AP.
o Style fixes.
Note that this commit temporarily breaks SMP configurations.
Previously APs didn't do anything, but they now enter the
scheduler. They hold sched_lock for more than 5 secs though
and cause a panic. That's what I call progress :-)
ia64_pal_base instead of scanning the EFI tables. This way
AP startup code can more easily use the function.
o Initialize ia64_pal_base in ia64_init(). When the PAL code
doesn't need explicit mapping or no PAL code has been found,
ia64_pal_base will be 0.
o Remove some unused global variables.
o Also in ia64_init(), allocate only 1 page for struct pcpu
and remove some Alpha leftovers.
o Initialize pc_pcb in cpu_pcpu_init().
1222 bytes (derived as the maximum that isc-dhcpd uses). This solves
the problem if a bootp/DHCP reply is over 256 bytes in which the
end of the bootp/DHCP reply will not be found and then the reply will
be ignored. This happens when swap and root paths are longish or many
parameters are set.
Reviewed by: imp
Approved by: imp
