from the manual:
Tm2sec converts a broken-down time to seconds since the
start of the epoch. It ignores wday, and assumes the local
time zone if zone is not GMT.
so we can assume localtime if Tm.zone is not set to GMT.
all code that wants no localtime conversion should set
Tm.zone explicitely to GMT. (see previous commits)
tm2sec() now does the reverse of localtime() when Tm.zone[0] == 0
which seems to be what the calling code (dossrv, zipfs) assumes.
this also makes sense because theres no simple way todo it
outside of libc as theres otherwise no access to the timezone
structure with the daylight saving periods.
tm2sec() ignores tm.tzoff and will use the local timezone for
conversion. to make it work right, we convert the dos timestamp
as GMT and then correct timezone with the offset provided by the
server.
instructions like BKPT, BX and BLX. Decoding these correctly allows db/acid to
single step through BX and BLX on armv5t+, and to show a breakpoint instruction
as 'BKPT $#0' instead of 'TEQ R0@>R0,R0'.
using a shared reply queue and a pool of worker procs does
result in replies to be send out of order under some conditions.
the symptoms are mnt errors when interrupting requests (Rflush
arriving before the original requests response).
this change gives each connection its own reply queue and its
own srvo process. so now a connection consists of one reply
queue, a srvi process reading the connections file descriptor
and a srvo process reading the reply queue and writng replies
to the connections file descriptor.
the srvi processes live as long as the connection is established.
the srvo prcoesses live forever and are attached to the chan
(which gets reused).
to avoid excessive process creation, we limit the number of
connections to 30. srvchan() returns nil when all 30 network
channels are in use.
due to the xfid handlers clearing flushtag too early, xfidflush might respond too early
causing spurious replies send later by the handler. now, we clear the flushtag in
filsysrespond *after* the reply was send. xfidflush will wait for us on the active
qlock.
scrollbars used to put the mouse on the scrollbar while scrolling. if latency
is high, this often results to the cursor jumping back. instead, make button 2
srolling work without needing the mouse to be inside the scrollbar and leave
the mouse position alone.
From richard:
A couple of patches applied yesterday should make debugging on ARM a
bit more reliable. Using db or acid on ARM, you may have noticed that
a program being debugged would sometimes execute through a breakpoint
without stopping, or run away while being single stepped. It turns out,
as often happens, that one symptom had two separate causes. For details:
/n/sources/patch/applied/5db-condcode/readme
/n/sources/patch/applied/arm-bkpt-cond/readme
To take advantage of the patches, rebuild libmach.a, then acid and db.
On machines with a kw kernel (sheevaplug et al), you'll also want to
rebuild /arm/9plug; otherwise breakpoints will stop working at all.
The new 9plug will, however, still work with the old libmach; and
the bcm and teg2 kernels are already compatible with the new libmach.
the heuristics that limits kernel memory on a cpu server to
a fixed amout (64MB + size for page tables) makes using devdraw
impractical.
if *imagemaxmb= is specified, we can assume that the draw device
will be used so we want to get a reasonable amount (30% default)
of kernel memory.
link status not working on 82567 was due to wrong phy number
used. instead of hardcoding the phy numbers, probe the phys
by reading id1 and id2 registers (code stolen from ethermii).
on the 82567, reading any phy register just gives 0 back.
however, the card works just fine and no action is required
to (re-)start auto negotiation. so we add maclproc() which just
reads the speed setting and link status from the mac status
register instead of reading the phy registers.
we'v probably seen this symptom on other cards (link: 0) like
82566. we should test if we can make link status work on
these cards as well by just using the maclproc().
rx pool exhaustion causes the system to deadlock when netbooted.
queue management should (etheroq) already makes sure the systen
can keep up with the data thowing away buffers.
icansleep() violates the lock ordering due to the following cases:
rbfree(): ilock(Rbpool.Lock) -> wakeup(): spli(), lock(Rbpool.Rendez)
sleep(): splhi(), lock(Rbpool.Rendez) -> icansleep(): ilock(Rbpool.Lock)
erik fixed this moving the wakeup() out of the ilock() in rbfree(),
but i think it is an error to try acquiering a ilock in sleeps wait
condition function in general.
so this is what we do:
in the icansleep() function, we check for the *real* event we care about;
that is, if theres a buffer available in the Rbpool. this is to handle
the case when rbfree() makes a buffer available *before* it sees us
setting p->starve = 1.
p->starve is now just used to gate rbfree() from calling wakeup() as
an optimization.
this might cause spurious wakeups but they are not a problem. missed
wakeups is the thing we have to prevent.
