of a data transfer operation immediately after the data transfer
was finished, instead of waiting for the chip to interrupt us and
tell us that it was finished and had the result for us. This worked
okay for read and write since the operation would be finished very
shortly after the data transfer completed. However, with formatting,
the chip still had most of the rest of the track to do, so we ended
up timing out before the operation was finished. This fix is from
sparc64/dev/fdc.c and was tested on sparc by tnn@.
of a data transfer operation immediately after the data transfer
was finished, instead of waiting for the chip to interrupt us and
tell us that it was finished and had the result for us. This worked
okay for read and write since the operation would be finished very
shortly after the data transfer completed. However, with formatting,
the chip still had most of the rest of the track to do, so we ended
up timing out before the operation was finished. This fix is from
sparc64/dev/fdc.c and was tested on sparc by tnn@.
framebuf event loop to take n i/o fd's as parameters and also allow
dynamic add/remove of fd's. (not tested except for one fd, but more
changes coming soon)
Instead, save/restore them on context switch. For 32bit processes, save/restore
the selector values only, for 64bit processes, save/restore the appropriate
MSRs. Iff the defaults have been changed.
disk volume header. On NetBSD this means RB_ASKNAME, however in SGI terms
it appears to mean 'autoboot'.
Add an appropriate kludge to keep us from doing the wrong thing.
XXX - This whole argv/env/prom parameter mess needs to be cleaned up.
"state lock" flag (if-bound, gr-bound, floating) at the end of a
NAT rule. The new syntax is backwards-compatbile with the old
syntax.
PF (kernel): change the macro BOUND_IFACE() to the inline function
bound_iface(), and add a new argument, the applicable NAT rule.
Use both the flags on the applicable filter rule and on the applicable
NAT rule to decide whether or not to bind a state to the interface
or the group where it is created.
into oversized volume headers:
Query ARCBIOS for OSLoadFilename and OSLoadOptions first, rather than only
using the environment variables passed since we want to go through arcemu.
Add an ugly hack to arcemu that munges the nvram 'bootfile' variable. We
need this because bootfile will point to the volume header, which then
translates into a bogus root device of 'sd0i', or similar.
> - With the PCIe devices, it looks issuing a TX command while there's
> already a transmission in progress doesn't have any effect. In other
> words, if you send two packets in rapid succession, the second one may
> end up sitting in the TX DMA ring until another transmit command is
> issued later in the future. Basically, if re_txeof() sees that there
> are still descriptors outstanding, it needs to manually resume the
> TX DMA channel by issuing another TX command to make sure all
> transmissions are flushed out. (The PCI devices seem to keep the
> TX channel moving until all descriptors have been consumed. I'm not
> sure why the PCIe devices behave differently.)
stack instead of the continuation stack. This is for lib/36011, where
pthread gets confused since we aren't running on the regular stack.
I'm not really sure which direction to go to with this quite yet, so
make the hack hard to enable on purpose. The whole request dispatch
code needs cleaning anyway.
Makes ftp a bit more portable (not needing fparseln()) at the expense of not
supporting arbitrary long header lines, which I'm not concerned about
because we don't support header line continuation either...
