reset command.
I observed some anomalous behavior while testing a 3c905C with a
Dell PowerEdge 4300/500 dual PIII 500Mhz system. The NIC would seem
to work correctly most of the time but would sometimes fail to receive
certain packets, in particular NFS create requests. I could mount
an NFS filesystem from the PowerEdge and do an ls on it, but trying
to do a "touch foo" would hang. Monitoring traffic from another host
revealed that the client was properly sending an NFS create request
but the server was not receiving it. It *did* receive it when I
ran the same test with an Intel fxp card.
I don't understand the exact mechanics of this strange behavior, but
resetting the receiver and transmitter seems to get rid of it. I used
to perform an RX and TX reset in xl_init(), but stopped doing it there
because on 3c905B and later cards this causes the autoneg session to
restart, which would lead to the NIC waiting a long time before exchanging
traffic after being brought up the first time. Apparently the receiver
and transmitter resets should be performed at least once when initializing
the card.
Hopefully this will cure problems that people have been having with the
3c905C -- this was the only strange behavior that I have observed with
the 3c905C so far which does not appear with the 3c905B or 3c905.
in a long (-l) listing.
MFC-jockies should make sure that bde's concerns regarding the number
of digits required to represent a uid_t and the use of snprintf
on the associated PR have been addressed before going wild.
PR: 12866
Reported by: Philip Kizer <pckizer@nostrum.com>
Obtained from: NetBSD
other typos, ~four grammar gnits, an ironic case of incorrect
parallelization, bad capitalization, an incorrect use of the
infamous slash ('/'), and an unclear sentence.
did not specify an exit code. This implies the use of either a hand-
rolled err() (Bruce's suggestion) or a random error code (my suggestion),
both of which are against the style guidelines. This commit specifies
the correct error code (implicitly). This also changes the error message
to be a little more helpful.
eisa_add_intr() which now takes an additional arguement (one of
EISA_TRIGGER_LEVEL or EISA_TRIGGER_EDGE).
The flag RR_SHAREABLE has no effect when passed to
bus_alloc_resource(dev, SYS_RES_IRQ, ...) in an EISA device context as
the eisa_alloc_resource() call (bus_alloc_resource method) now deals
with this flag directly, depending on the device ivars.
This change does nothing more than move all the 'shared = inb(foo + iobsse)'
nonesense to the device probe methods rather than the device attach.
Also, print out 'edge' or 'level' in the IRQ announcement message.
Reviewed by: dfr
February.
If you do a web search for "lionheart crowned" you'll get lots of
conflicting information. Some sites say 3rd September, while others
say 27th February. Most of the "27th February" crowd seem to take their
information from other incarnations of this file on other operating
systems.
After a very pleasant afternoon spent lunching with my girlfriend's
parents, I availed myself of their extensive reference library.
You'd be surprised how hard it is to get concrete information about this.
The _Encyclopedia Brittanica_ doesn't mention the date, only the year, as
does _Brewer's Dictionary of Phrase and Fable_, as do all the other printed
sources I tried. One of them even said July 7th 1189! Microsoft's (yeah,
so sue me) Encarta '95 has quite a comprehensive entry, but again, no
day and month information
In desperation, I tried the web once more, and finally stumbled upon
http://www.btinternet.com/~timeref/hsttime2.htm. This revealed that
Henry II died on 6th July 1189 (presumably the source of the 7th July
entry in another reference), and that Richard was crowned on 3rd
September.
Best of all, this site gives references. So if any of you have a copy of
_The Life and Times of Richard I_, John Gillingham, pub. George Weidenfeld
and Nicholson Limited, 1974, then you can confirm this for yourselves.
For completenesses sake, I tried to find an ISBN number for the above
book. But Amazon and Barnes and Noble don't appear to stock it (although
it looks like a revised version, by the same author, is due out in October
1999, in case anyone's interested).
PR: docs/10488
Submitted by: solon@macaulay.demon.co.uk
o Add field to dev_desc for the size of the io port range. This isn't
used yet in the committed sources, but will make the transition easier
in the future.
If you build this into your kernel, you will need to rebuild pccardd.
o Document debug level keyword
o Implement debug level:
o For most of the diagnostic messages, change them from #ifdef DEBUG
to if (debuglevel > 0).
o Add a couple more diagnostic messages that weren't present before
o Fix a couple of excessively long lines.
Reviewed by: hosokawa-san
o Start to implement the stopgap kludge for -current's pccard code by passing
the length of the i/o range. If DEV_DESC_HAS_SIZE is defined, we'll set
the size. This is done as an ifdef so that I can generate patches
against the kernel more easily.
o Add preliminary support for tweaking sleep times, but leave it
disabled until a good range of values can be established.
Didn't fix: logmsg problem noted by Nate.
_or_ you may specify "log logamount number" to set logging specifically
the rule.
In addition, "ipfw resetlog" has been added, which will reset the
logging counters on any/all rule(s). ipfw resetlog does not affect
the packet/byte counters (as ipfw reset does), and is the only "set"
command that can be run at securelevel >= 3.
This should address complaints about not being able to set logging
amounts, not being able to restart logging at a high securelevel,
and not being able to just reset logging without resetting all of the
counters in a rule.
Removed POSIX.1/NetBSD markup (braces) for NAME_MAX, etc. We don't
define this. Most FreeBSD man pages hard-code the limits; in fact,
utimes.2 recently became the only file in libc/sys/*.2 that mentions
NAME_MAX. There probably should be mandoc macros for this.
that -E only operates for a specified variable. Useful since the -e option
will often pull-in many unwanted variable overrides (esp. in a make world
situation). Uses include overriding BINOWN (which cannot be done by normal
methods or through abuses of MAKEFLAGS) or likely for ports to honour CFLAGS
(provided they're running on a system whose make(1) has this option).
Specifically intended for removing -fschg ("INSTALLFLAGS_EDIT=:S/schg/uchg/")
this makes the NOFSCHG flag redundant. NOFSCHG will still be honoured by
bsd.lib.mk but is valid for buildworld only. NOFSCHG is still implemented in
the old way (ie. _not_ ".if NOFSCHG then { INSTALLFLAGS_EDIT+=:S/schg/,/ }"
to emphasize the fact that NOFSCHG is only supported in a limited
fashion and for buildworld.
The interface and implementation are such that future use of flags such
as sappnd can also be easily removed or altered (perhaps to uappnd).
This commit brought to you by the letters B, D, and E, and the numbers six,
one, thirteen, and three.
