POWER does not provided subtract immediate functions and
instead rely on negative addition. It was such that the linker
was the one who would go through and rewrite these to be negative
but it really should be done in the compiler while we still have
the width information.
* Add a handful of 64 bit classifications to 9l, along with instruction generation for each.
* 9c should avoid generating immediate instructions for 64 constants.
* libmach should know about 9l's generation to present a better disassembly.
* libmach now properly displays MOVD for moves between registers on 64 bit.
This was leftover from before 6c was
in /sys/src/cmd, as the mkfile adds this
to the include path. Now that we have 6c,
this subdirectory is never used.
Commit 9f755671fb broke
webseeding with the last block.
The haveiece() call at the end was because the inner
is not calling havepiece() on the last block as it
does not take the piece length into account.
Now, instead, fix the inner loop, making the code
more setright foward so we call havepiece() on the
last block.
The transition time in the timezone info file is,
confusingly, in local time and not UTC, so we need
to translate it before we do the comparison.
While we're here, revert the Australian timezone
change that made the offsets UTC, and add some test
to make sure we get this right.
This global "Mss" MIB element does not really exists,
and it makes no sense as the MSS is negotiated
per connection.
Put the InLimbo in the statistics table.
In limbo() function, once tpriv->nlimbo
reaches Maxlimbo, we'd try to re-use
Limbo entries from the head of the hash
chain. However, theres a special case
where our current chain contains only
a single entry. Then Limbo **l; points
to its next pointer, and writing:
*l = lp; would just yield in the entry
being linked to itself, leaking it.
The for(;;) loop in limborexmit() was wrong,
as the "continue" case would not advance
the lp pointer at all, (such as when
tpriv->nlimbo reaches > 100), we'd stop
cleaning out entries.
Handle Fsnewcall() returning nil case,
have to free Limbo *lp as we just removed
it from the hash table.
Add tpriv->nlimbo as "InLimbo" at the
end of /net/tcp/stats.
We where allocating the dialid and acceptid using:
rand()<<16 + rand()
this gives a biased values as rand() retuns a 15-bit
number. Instead, use two calls to nrand() to get
the full 32-bit unsigned range.
the start generation was allocated by calling rand(),
which gives a value between 0 and 2^15.
Instead, make a newgen() function that returns a new
generation id in the full 32-bit range, but also
avoids 0 and Hangupgen special values.
Cleanup and make all helper functions static.
Using > causes the kbmap file to get truncated,
which resets to the default keymap and *THEN*
applies the new change. Which is probably not
what was intended.
The default behaviour of the key labelled as Caps Lock is
to be a Ctrl key, but in some cases in can be desirable
to have it like an actual Caps Lock. A new kbmap file is
added and the keyboard documentation is updated.
git/commit /sys/lib/kbmap/caps /sys/man/6/keybo
We used to only allow a single report per interface,
ignoring queries if a interfce already had a report
in flight.
However, this is not correct. Imagine if there is
a query specific query for a group, we add the
report and then we will ignore all further
queries (general or specific) until that
report times out.
Instead, we should maintain the timeout (report)
for each group (and interface) individually.
This means, Report.multi must point to a *single*
Ipmulti. When we handle general queries,
we must create individual Reports for
each of our multicast addresses, but check if
such a report already exists (for that interface).
Because the individual check is basically
quadratic, organise the reports in a hash table
to make finding the existing reports per group
per interface cheaper.
The semacquire allocates a Rendez struct on its stack,
and publishes it on the semaphore linked list in the
segment.
Before returning, it removes it again, properly taking
the locks protecting the linked list, so whats the issue?
The issue happens when procinterrupt() does the wakeup,
which does not care about the spinlock of the segment
lined list, and it does it in the following way:
p->r = nil;
r->p = nil;
ready(p);
unlock(r);
Note that the unlock happens *after* the ready.
So the process could'v already run on another core, remove
itself from the segment list and get out of semacquire()
alltogether, but we still have one line to execute here,
which is the unlock() of the now free'd Rendez.
And that was causing the stack corruption!
So wakeup() and procinterrupt() always had this issue.
If the Rendez memory stays valid after the wakeup,
here is no issue. Most code just uses &up->sleep,
which will stay valid as Proc's are never freed.
The solution for now is to do the ready() as the
last step, not touching the resource after the final
unlock.
