was calling nfs_flush() and then clearing the NMODIFIED bit. This is
not legal since there might still be dirty buffers after the nfs_flush
(for example, pending commits). The clearing of this bit in turn prevented
a necessary vinvalbuf() from occuring leaving left over dirty buffers
even after truncating the file in a new operation. The fix is to
simply not clear NMODIFIED.
Also added a sysctl vfs.nfs.nfsv3_commit_on_close which, if set to 1,
will cause close() to do a stage 1 write AND a stage 2 commit
synchronously. By default only the stage 1 write is done synchronously.
Reviewed by: Alfred Perlstein <bright@wintelcom.net>
the low level interrupt handler number should be used. Change
setup_apic_irq_mapping() to allocate low level interrupt handler X (Xintr${X})
for any ISA interrupt X mentioned in the MP table.
Remove an assumption in the driver for the system clock (clock.c) that
interrupts mentioned in the MP table as delivered to IOAPIC #0 intpin Y
is handled by low level interrupt handler Y (Xintr${Y}) but don't assume
that low level interrupt handler 0 (Xintr0) is used.
Don't allocate two low level interrupt handlers for the system clock.
Reviewed by: NOKUBI Hirotaka <hnokubi@yyy.or.jp>
o s/unsigned/unsigned int/g
o Add -Wall
btxld can now be built as a cross-tool for cross-building i386/pc98 on
platforms that don't have btxld (such as alpha).
hardpps() produced offset component. This is tested and behaved
stable with frequency offsets from -338.05 to +499.91 PPM.
Interestingly the machine I tested this on would fail if the clock
were slower than 14.3132 MHz whereas it was perfectly happy to run
at 16.384 MHz, in other words [-340PPM ... +14.4%]
Make pps_shift tweakable with sysctl.
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
* Remove "why we need this decl..." comment. The `matcher' variable
is defined in *grepmat.c files in the original distribution, which
we did not import.
has it blacklisted. Silly us for not planning ahead. Tsk. Anyway-
a 10 year window patch is probably sufficient to still detect
nonsense in the clock but allow us to roll past the year 2000.
code gratefully borrowed from Patrick Stirling who did a lot of the
grunt work on this years ago. There are also some beginnings of
swizzle macros in case we go to a big endian machine. This is just
a first pass at this and is likely to change a bit over the next
Add in a very large amount of target mode support code- this is just
a first pass at this. It's a difficult thing because some of the code
can be in platform independent areas (see isp_target.?) but a lot has
to be in platform dependent areas because of not only the tight coupling
of received commands/events and the specific OS subsystem but because
the platform independent code has (deliberately) no event/wait mechanisms.
of where we could have seen the loop up at least once so it
makes sense. Change some stuff in ispscsicmd so we don't get
stuck there if the loop has never come up yet. Add in some
target mode support code.
