some control transactions can confuse the xhci controller so
much that it even fails to respond to command abort or STOPEP
control command. with no way for us to abort the transaction
but a full controller reset.
we give the controller 5 seconds to abort our initial
transaction and if that fails we wake the recover process
to reset the controller.
thanks mischief for testing.
from what i can tell, sending port enable is a spec violation.
this fixes a hang during hub enumeration in the ASMedia
xhci controller when i plug in my IBM UltraNav SK-8845.
also, send unsuspend when port is suspended instead of enable.
from the USB 2 specification:
11.24.2.7.1.2 PORT_ENABLE
...
This bit may be set only as a result of a SetPortFeature(PORT_ENABLE).
...
The hub response to a SetPortFeature(PORT_ENABLE) request is not specified.
we have to explicitely convert to vlong by sign or
zero extending as not every operation leaves a proper
zero/sign extended result in the register. for example
NEGW will zero extend, breaking negative int offsets
on pointers.
we explicitely insert SXTW or MOVWU instructions which
the peephole optimizer takes out again when it is safe
todo so.
when promoting constant offsets to immediate offsets,
make sure the offset will be in range. otherwise the
linker will produce not so optimal pointer arithmetic
instructions to calculate the offset.
the possible bitmasks generated depend on the data width
of the instruction, so we introduce C_BITCON32 and C_BITCON64
operand types to keep them apart.
the encoding of the bitcon operation was wrong.
the temporary stack segment used to be at a fixed address above or
below the user stack. these days, the temp stack is mapped dynamically
by sysexec so TSTKTOP is obsolete.
return the error message from MSG_CHANNEL_OPEN_FAILURE
in the "connect" control write.
use a extra state "Finished" to distinguish server from client
initiated teardown. that way we do not need to track if we
send the MSG_CHANNEL_CLOSE message in closeclient(). this way
we also cannot be fooled by misbehaving server.
simplify hangupclient() by removing state transitions and doing
them in the caller explicitely. that way we can use hangupclient()
instead of dialedclient().
in mux mode, ssh relays raw MSG_CHANNEL_*
messages on standard input and output while
still handling authentication and key exchange
internally.
the intend is to use the mux mode to implement
something like the old sshnet ontop of ssh.
between being commited to a machno and having acquired the lock, the
scheduler could come in an schedule us on a different processor. the
solution is to have dtmachlock() take a special -1 argument to mean
"current mach" and return the actual mach number after the lock has
been acquired and interrupts being disabled.
this fixes the miscompilation of 6l with 5c resulting in bogus
vlong -> long conversion at the top of asmandsz():
asmandsz 0x0000aec4 MOVW.W R14,#-0x2c(R13)
asmandsz+0x4 0x0000aec8 MOVW rex+8(FP),R5
asmandsz+0x8 0x0000aecc MOVW $andptr-SB(SB),R7
asmandsz+0xc 0x0000aed0 MOVW R0,R6
asmandsz+0x10 0x0000aed4 AND $#0x44,R5,R8
asmandsz+0x14 0x0000aed8 MOVW R8,rex+8(FP)
asmandsz+0x18 0x0000aedc MOVW R0,R4
asmandsz+0x1c 0x0000aee0 MOVM.IA (R0),[R1,R3] <- R1 used here
asmandsz+0x20 0x0000aee4 MOVW R8,v-4(SP) <- substituted by R8
- do not write /net/ndb for loopback medium unless -p is specified
- use defmask() instead of hardcoded /64 for v6 to get correct /128 mask for ::1
- only do duplicate address detection on ethernet
- increase buffer size to support up to 4096 bit RSA keys
- handle PMTUDiscovery option and respond to pmtu probes
- handle port in Address option
- wlock(&netlk) before closing udpfd to sync with writers
- move default subnet handling out of gethost()
using ~IP_DF mask to select offset and "more fragments" bits
includes the evil bit 15. so instead define a constant IP_FO
for the fragment offset bits and use (IP_MF|IP_FO). that way
the evil bit gets ignored and doesnt cause any useless calls
to ipreassemble().
tested on a t43 with igfx and a 1600x1200 t43p screen
what works: lvds, blanking
what doesn't: hwgc (not visible), snarfing edid
untested: vga
based on realemu traces.
only try listen/dial on udp when IndirectData/TcpOnly is not
enabled.
add support for scipts:
host-up
host-down
tinc-up
tinc-down
subnet-up
subnet-down
when dialing udp connection, only switch when there is no
other udp connection active. when we receive an authenticated
message, we switch to that connection immidiately.
unfraglen() had the side effect that it would always copy the
nexthdr field from the fragment header to the previous nexthdr
field. this is fine when we reassemble packets but breaks
fragments that we want to just forward unchanged.
given that we now keep the block size consistent with the
ip packet size, the variable header part of the ip packet
is just: BLEN(bp) - fp->flen == fp->hlen.
fix bug in ip6reassemble() in the non-fragmented case:
reload ih after ip header was moved before writing ih->ploadlen.
use concatbloc() instead of pullupblock().
some protocols assume that Ip4hdr.length[] and Ip6hdr.ploadlen[]
are valid and not out of range within the block but this has
not been verified. also, the ipv4 and ipv6 headers can have variable
length options, which was not considered in the fragmentation and
reassembly code.
to make this sane, ipiput4() and ipiput6() now verify that everything
is in range and trims to block to the expected size before it does
any further processing. now blocklen() and Ip4hdr.length[] are conistent.
ipoput4() and ipoput6() are simpler now, as they can rely on
blocklen() only, not having a special routing case.
ip fragmentation reassembly has to consider that fragments could
arrive with different ip header options, so we store the header+option
size in new Ipfrag.hlen field.
unfraglen() has to make sure not to run past the buffer, and hadle
the case when it encounters multiple fragment headers.
kivik wrote:
I've found a nasty bug in lib9p handling of Tversion
messages, where an invalid version string in the request
leads to servers abort()ing the spaceship.
To reproduce:
; ramfs -S ram
; aux/9pcon /srv/ram
Tversion ~0 DIE
The issue lies in sversion() where in case an invalid
version string is received we respond right away with
ofcall.version="unknown"; however, we fail to set the
ofcall.msize, which at this point is cleared to 0. This
causes the convS2M call in respond() to fail and abort being
called.
we want to accept V4 subnets in CIDR notation consistently which
means we need to interpret the mask in context of the IP address.
so parseipmask() now has an additional v4 flag argument which
offsets the prefixlength by 96 so a /24 will be interpreted
as a /120.
parseipandmask() is the new function which handles this automatically
depending on the ip address type.
v4parsecidr() is now obsolete.
steve wrote:
> I cam across a bug in cifs.
>
> An empty directory under windows 7 pro contains a single entry "." but it
> doesn't appear to contain "..". As a result "." is not removed on dirscan
> and plan9 gets when trying to traverse the hierarchy.
all screen implementations use a Memimage* internally
for the framebuffer, so we can return a shared reference
to its Memdata structure in attachscreen() instead of
a framebuffer data pointer.
this eleminates the softscreen == 0xa110c hack as we
always use shared Memdata* now.
Under the normal close sequence, when we receive a FIN|ACK, we enter
TIME-WAIT and respond to that LAST-ACK with an ACK. Our TCP stack would
send an ACK in response to *any* ACK, which included FIN|ACK but also
included regular ACKs. (Or PSH|ACKs, which is what we were actually
getting/sending).
That was more ACKs than is necessary and results in an endless ACK storm
if we were under the simultaneous close sequence. In that scenario,
both sides of a connection are in TIME-WAIT. Both sides receive
FIN|ACK, and both respond with an ACK. Then both sides receive *those*
ACKs, and respond again. This continues until the TIME-WAIT wait period
elapses and each side's TCP timers (in the Plan 9 / Akaros case) shut
down.
The fix for this is to only respond to a FIN|ACK when we are in TIME-WAIT.
At this moment plan9 is using vendorinfo to communicate
some specific plan9 parameters, but there are some boards
that use this attribute to set specific values. This
patch allows netbooting of these boards using ndb attributes
instead of hard coded solutions in dhcpd(1). Vendor attribute
is used for that purpose because it is also used for the
same purpose in bootp.
Lookupip() was already reading rootpath, but it didn't read the
address of the rootserver. As they are very related it makes sense to
read them at the same time.
This patch also fixes a typo, where vendorclass was used instead of
vendor, resulting that vendor ndb attribute was never used.
always start the pager kproc in swapinit(), simplifying kickpager().
allow zero conf.nswap and conf.nswppo. avoid allocating the reference
map and iolist arrays in that case.
use ulong for ioptr and iolist indices.
don't panic when writing pages out to the swapfile fails. just
requeue the page in the io transaction list so we will try
again next time executeio() is run or just free the page when
the swap reference was dropped.
remove unused pagersummary() function.
rfork F closes all file descriptors, so we have to
invalidate the redirections as they are now refering
to closed files. not doing so causes the wrong file
descriptors being closed later on as the fd numbers
get reused.
the FCA registers 0x28, 0x2C have been reassigned to
to FEXTNVM on i217, i218 and i219 so add Fnofca flag
and avoid writing the registers.
make link detection more robust on i217 by delaying the
phy status read after link status change by 150ms. we'd
otherwise get a "phy wedged" (power saving state?) and
not update the link status until the next link change.
the max packet size is configured in 1K increments on these chips,
which can result in the card receiving a 10K packet but the
driver having only allocated 9.5K of buffer. this actually caued
pool corruption with i210, i217, i218, i219, i350.
for 82598 and x550, we explicitely round rbsz to avoid similar bugs
in the future, even tho the Rbsz constant was already a multiple of
1K and is not affected by the bug.
the lru is there to track least recently used messages so
we can evict them from the cache and refetch them again on
demand. for pop3 mailbox, which doesnt provide fetch routine,
the messages should never be put on the freelist.
The previous attempt to fix this problem (see changesets b32199e0f90a
and 00ae79a6ba50) caused all calls to cachefree to free the cached
message contents in addition to updating the LRU list. This causes
problems for the POP3 driver since it provides no fetch function; once
a message is evicted from the LRU cache, its contents is lost.
This time we fix cachefree to always update the LRU list but only free
the cached message contents if the driver provides a fetch function or
the force flag is set.
Some SD card readers are slow to unstall. We try to unstall them
in a loop if there's no SD card in there, but they're not stalled.
They're happily reporting that there's no SD card in them by giving
back the appropriate error code.
Skipping the unstall speeds up the retry loop, cutting the time spent
attaching the USB device at boot from multiple minutes to nearly instant.
Force the cacheclear operation in the LRU cache trimming loop in order
to guarantee that the cache becomes smaller with each iteration.
Without the force flag cacheclear is a no-op for mailboxes that do not
provide a fetch function, e.g. POP3.
because a client might not handle resize, rio would try to move ther
window offsceen after 750 ms. however, it does this by window name,
which could have been reassigned by another concurrent rio, causing the
wrong window to disappear.
now we always move the window offscreen before freeimage(). this way we
are sure to still have the right reference to the original window.
