when a prefix is added with the onlink flag clear, packets
towards that prefix needs to be send to the default gateway
so we omit adding the interface route.
when the on-link flag gets changed to 1 later, we add the
interface route.
the on-link flag is sticky, so theres no way to clear it back
to zero except removing and re-adding the prefix.
Once a second rebalance() is called on cpu0 to adjust priorities,
so cpu-bound processes won't lock others out. However it was only
adjusting processes which were running on cpu0. This was observed
to lead to livelock, eg when a higher-priority process spin-waits
for a lock held by a lower priority one.
syntax: reboot!bootfile[!method...]
this echos bootfile to /dev/reboot, causing bootfile kernel
to be started.
when method is given, we first connect to the filesystem and
set bootargs so that bootfile can be loaded from the target
network or local fileserver.
note, when no bootfile is given, this causes the kernel to
reboot to bios.
the end condition port < offset+n could never become
false when offset truncated to 32 bit signed port is
negative. change the condition variables to unsigned
int.
msr's are not byte addressible, so advance reads by
one instead of 8.
sending multicast was broken when ipconfig assigned the 0
address for dhcp as they would wrongly classified as Runi.
this could happen when we do slaac and dhcp in parallel,
breaking the sending of router solicitations.
now handle the supported rates element properly, only
providing the intersecting set of rates that the bss
advertises and what the driver supports, putting the
basic rates first.
also avoid using usupported rates.
nobody passes us the "RSD PTR " address when doing multiboot/kexec
on UEFI systems. so we search for it manually in the ACPI reserved
area as indicated in the e820 memory map.
we did not apply the special case to store 0xFFFF (-0)
in the checksum field when the checksum calculation
returned zero. we survived this for v4 as RFC768 states:
> If the computed checksum is zero, it is transmitted as
> all ones (the equivalent in one's complement arithmetic).
>
> An all zero transmitted checksum value means that the
> transmitter generated no checksum (for debuging or for
> higher level protocols that don't care).
for ipv6 however, the checksum is not optional and receivers
would drop packets with a zero checksum.
during dhcp, ipconfig assigns the null address :: which makes
ipforme() return Runi for any destination, which can trigger
arp resolution when we attempt to reply. so have v4local()
skip the null address and have sendarp() check the return
status of v4local(), avoing the spurious arp requests.
closeconv() calls ipifcremmulti() like:
while((mp = cv->multi) != nil)
ipifcremmulti(cv, mp->ma, mp->ia);
so we have to defer freeing the entry after doing:
if((lifc = iplocalonifc(ifc, ia)) != nil)
remselfcache(f, ifc, lifc, ma);
which accesses the otherwise free'd ia and ma arguments.
on HZ 100 systems like pc and pc64, the minium sleep time
was 10ms, which is quite high. the cap isnt really needed
as arch specific timerset() enforces its own limit, but on
a higher resolution.
background:
from Charles Forsyth:
I haven't really got an opinion on it. The 10ms interval was first used on
machines that were much slower.
I thought someone did set HZ to a bigger value, partly to support better
in-kernel timing. I haven't done it because I never had a need for it.
If I were doing (say) protocol implementation in user mode, I'd certainly
reconsider. Sleep itself forces at best ms granularity,
and for some applications that's too big.
initial mail from qwx raising the issue:
> Hello,
>
> I found out recently that sleep(2)'s resolution on 386 and 9front's amd64
> kernel is 10 ms rather than 1 ms. The reason is that on those kernels,
> HZ is set to 100 rather than say 1000. In syssleep, we get 1 tich every
> 10 ms.
>
> What is unclear is why.
>
> To paraphrase cinap_lenrek's answer to my question:
>
> In syssleep:
> if(ms < TK2MS(1))
> ms = TK2MS(1);
> tsleep(&up->sleep, return0, 0, ms);
>
> "TK2MS(1)" can be replaced with just "1", and the arch specific
> timerset() routine would do its own capping of the period if it's too
> small for the timer resolution, and make better decisions based on what
> the minimum timer period should be given the latency overhead of the
> given arch's interrupt handling and performance characteristics.
>
> Alternatively, HZ could be raised to 500 or 1000.
>
> It seems it's just trying to prevent excessive context switches and
> interrupts, but it seems somewhat arbitrary. A ton of syscalls can be
> done in 1 ms, and it's the lowest we can go without changing the unit.
>
>
> What do you think?
>
> Thanks in advance,
>
> qwx
devdir internally replicates the qid in ther perm stat field
already and the practice of explicitely passing just causing
confusion when done inconsistently.
this driver makes regions of physical memory accessible as a disk.
to use it, ramdiskinit() has to be called before confinit(), so
that conf.mem[] banks can be reserved. currently, only pc and pc64
kernel use it, but otherwise the implementation is portable.
ramdisks are not zeroed when allocated, so that the contents are
preserved across warm reboots.
to not waste memory, physical segments do not allocate Page structures
or populate the segment pte's anymore. theres also a new SG_CHACHED
attribute.
fpurestore() unconditionally changed fpstate to FPinactive when
the kernel used the FPU. but in the FPinit case, the registers are
not saved by mathemu(), resulting in all zero initialized registers
being loaded once userspace uses the FPU so the process would have
wrong MXCR value.
the index overflow check was wrong with using shifted value.
there appears to be confusion about the refresh flag of arpenter().
when we get an arp reply, it makes more sense to just refresh
waiting/existing entries instead creating a new one as we do not
know if we are going to communicate with the remote host in the future.
when we see an arp request for ourselfs however, we want to always
enter the senders address into the arp cache as it is likely the sender
attempts to communicate with us and with the arp entry, we can reply
immidiately.
reject senders from multicast/broadcast mac addresses. thats just silly.
we can get rid of the multicast/broadcast ip checks in ethermedium and
do it in arpenter() instead, checking the route type for the target to
see if its a non unicast target.
enforce strict separation of interface's arp entries by passing a
rlock'd ifc explicitely to arpenter, which we compare against the route
target interface. this makes sure arp/ndp replies only affect entries for
the receiving interface.
handle neighbor solicitation retransmission in nbsendsol() only. that is,
both ethermedium and the rxmitproc just call nbsendsol() which maintains
the timers and counters and handles the rotation on the re-transmission
chain.
no need to rlock ifc in targetttype() as we are called from icmpiput6(),
which the ifc rlocked.
for icmpadvise, the lport, destination *AND* source have to match.
a connection gets a packet when the packets destination matches the source
*OR* the packets source matches the destination.
v4lookup() and v6lookup() do not acquire the routelock, so it is
possible to hit routes that are on the freelist. to detect these,
we set ref to 0 and check for this case, avoiding overriding the ifc.
re-evaluate routes when the ifcid on the route hint doesnt match.
rfc4861 7.2.2:
If the source address of the packet prompting the solicitation is the
same as one of the addresses assigned to the outgoing interface, that
address SHOULD be placed in the IP Source Address of the outgoing
solicitation.
this change adds ndbsendsol() which handles the source address selection
and also handles the arp table locking; avoiding access to the arp entry
after the arp table is unlocked.
cleanups:
- use ipmove() instead of memmove().
- useless extern qualifiers
ipv4local() and ipv6local() now take remote address argument,
returning the closest local address to the source. this
implements the standartized source address selection rules
instead of just returning the first local v4 or v6 address.
the source address selection was broken for esp, rudp an udp,
blindly assuming ifc->lifc->local being a valid v4 address.
use ipv6local() instead.
the v6 routing code used to lookup source address route to
decide to drop the packet instead of checking the interface
on the destination route.
factor out the route hint from Conv and put it in Routehint
structure. avoiding stack bloat in v4 routing. implement the
same trick for v6 avoiding second route lookup in ipoput6.
fix memory leak in icmpv6 router solicitation handling.
remove old unfinished handling of multiple v6 routers. should
implement source specific routes instead.
avoid duplication, use common convipvers() function.
use isv4() instead of memcmp v4prefix.
everything was broken. strting with hsinit not even chaining
the itd's into a ring. followed by broken buffer pointer pages.
finally, the interrupt handler's read transaction length
calculation was completely bugged, using the *FRAME* index
to access descriptors csw[] fields and not reseting tdi->ndata
thru the loop.
minor stuff:
iso->data needs to be freed with ctlr->dmafree()
put ival in iso->ival so ctl message cannot override the endpoints
pollival and screw up deallocation.
we allow devether to create ethernet cards on attach. this is useull
for virtual cards like the sink driver, so we can create a sink
by simply: bind -a '#l2:sink ea=112233445566' /net
the detach routine was never called, so remove it from the few drivers
that attempted to implement it.
the only architecture dependence of devether was enabling interrupts,
which is now done at the end of the driver's reset() function now.
the wifi stack and dummy ethersink also go to port/.
do the IRQ2->IRQ9 hack for pc kernels in intrenabale(), so not
every caller of intrenable() has to be aware of it.
the td index "x" was incremented twice, once in for loop
and in the body expression. so r->rp only got updated
every second completion. this is wrong, but harmless.
flushing tlb once the index wraps arround is not enougth
as in use pte's can be speculatively loaded. so instead
use invlpg() and explicitely invalidate the tlb of the
page mapped.
this fixes wired mount cache corruption for reads approaching
2MB which is the size of the KMAP window.
invlpg() was broken, using wrong operand type.
