we start polling the BMCR again. Greg Woods noted on tech-net@
that the DP83840A manual states that there should be a 500us delay
between asserting software reset and attempting MII serial operations.
I've also noted that a DP83815 can get into a bad state on cable
removal and reinsertion if we do not delay here.
This may well address PR/16346, and I seem to recall occasional
reports of auto-negotiation and flaky kinds of errors that this
might also alleviate.
descriptor sizes if larger mbuf clusters are in use -- currently
commented out because, for some reason, transmit doesn't work at
all with large mbuf cluster sizes.
Note that using actual 9K frames is a _lot_ less efficient than
using frames that are a little smaller than 8K so that they fit
in one or two pages (instead of two or three) and avoid the extra
chained descriptor with only 1K of data in it, too. TCP will
segment things just fine for an 8K total packet size, just as it
does for 1500-byte packets.
On my system, using "mtu 8000" with ifconfig, I get an almost 50%
performance boost for TCP (930Mbit/sec instead of 660Mbit/sec) over
1500-byte frames. "mtu 9000" yields only 770Mbit/sec.
* We were never calling the callback function when we got a UFI CCI(!).
* We were passing a bogus residual count on non-UFI CCIs.
* After a REQUEST SENSE, the UFI CCI may include the ASC/ASCQ from the sense
information -- don't consider this a failure.
In addition, remove a horrible hack that was causing us to drop sense
information on the floor and return empty INQUIRY responses, often in the case
where there is a UNIT ATTENTION pending during the INQUIRY. (Some drives send
the data and then fail, some don't.)
This eliminates the need for quirks for the Y-E DATA FlashBuster.
These changes work on:
umass0: SAMSUNG SFD-321U [FW 0C], rev 1.10/2.10, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus1 drive 0: <SMSC, USB FDC, 2.10> disk removable
umass0: TEAC TEAC FD-05PUB, rev 1.10/0.00, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus0 drive 0: <TEAC, FD-05PUB, 1026> disk removable
umass0: Y-E DATA FlashBuster-U, rev 1.00/3.04, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus0 drive 0: <Y-E DATA, USB-FDU, 3.04> disk removable
Handy because ls(1) helpfully converts the time to human-readable
format when printing, and because shell tools like "test -nt" and
"find -newer" can be used against it.
"Inspired" by a discussion about removing lockfiles older than the
last reboot, and Al Crooks' handy observation that a close
approximation can be found with /var/run/dmesg.boot
While here, notice that a lot of the kernfs structures and naming
changed suddenly, and though it seems a clear improvement, there was no
mention in commit logs.
shminfo.shmseg, in view of the fact that only few processes utilize a
significant fraction of it:
-turn the table into a linked list, elements allocated from a pool(9)
-On fork(), just bump a refcount instead of copying the list; it will
be decremented on exit() and exec(). Only copy if an attach or detach
takes place in between, which is rarely the case.
the first two directory entries are "." and "..".
This behaviour is not required by applicable standards, and
actually not provided by "coda".
Now we get the "." and ".." into the per-directiry hash tables,
but this should not hurt.
mkstemp is not found. The configure test for gettimeofday is thus
only run in that case, which explains why HAVE_GETTIMEOFDAY was
not defined by default in the resulting config.h. Since we don't
need gettimeofday, don't define HAVE_GETTIMEOFDAY manually to
simplify updates to this file.
Add RCS Id.
