bootable on 1 FDD PC98 machines. (When an external FDD unit is
installed, unit numbers become discontinuous.)
Submitted by: IMAI Takeshi <take-i@ceres.dti.ne.jp>
now used in f_ops in place of NULL, and modifications to the files
are more carefully ordered. f_ops should also be set to &badfileops
upon "close" of a file.
This does not fix other problems mentioned in this PR than the first
one.
PR: 11629
Reviewed by: peter
with options.c which was fixed in ISC's version 2.0 (rev 1.1.1.2 --> 1.1.1.3).
I have tested host-name with both types `X' and `t' and things work fine
either way. I would prefer to match the offical sources when easily possible.
PR: 12205
Submitted by: John Baldwin <jobaldwi@vt.edu>
correct the pointers afterwards.
It's kinda bogus that we generate a 24 (?) byte filehandle (2 x int32
fsid and 16 byte VFS fhandle) and pad it out to 64 bytes for NFSv3 with
garbage. The whole point of NFSv3's variable filehandle length was
to allow for shorter handles, both in memory and over the wire. I plan
on taking a shot at fixing this shortly.
o use suser_xxx rather than suser to support JAIL code.
o KNF comment convention
o use vp->type rather than vaddr.type and eliminate call to
VOP_GETATTR. Bruce says that vp->type is valid at this
point.
Submitted by: bde.
Not fixed:
o return (value)
o Comment needs to be longer and more explicit. It will be after
the advisory.
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
