1. All the suggestions earlier made by Bruce: renaming some symbols,
stricter error checking, removing redundant code, etc.
2. The `psm' driver preserves the default counter resolution and
report rate, whatever they are after reset. (Based on reports and
suggestion from Nate and Rob Bolin).
3. The `psm' driver now does not check the so-called sync. bit in the
first byte of the data packet by default, so that the tapping feature
of ALPUS GlidePoint works (based on reports from Louis Mamakos). I
tested the code with ALPUS Desktop GlidePoint (M/N GP101) and found
no problem; tapping worked. It appears ALPUS produces several models
of GlidePoint. I hope the other models are OK too.
The check code can still be activated by defining the PSM_CHECKSYNC
option in the config file. (The bit checking slightly reduces, if not
completely eliminates, weird mouse behavior cased by unsynchronized
mouse data packets. It also helps us to detect if the mouse interrupt
can ever be lost. But, well, if there are devices which cannot be
supported this way...)
4. The `psm' driver does not include the protocol emulation code by
default. The code can still be compiled in if the PSM_EMULATION option
is specified in the config file. Louis Mamakos suggests the emulation
code is putting too much in the kernel, and `moused' works well.
I will think about this later and decide if the entire emulation
code should be removed.
5. And, of course, the fix in `scprobe()' from Bruce to cure the
UserConfig problem. My code in `kbdio.c' is slightly different from
his patch, but has the same effect. There still is a possibility that
`scprobe()' gets confused, if, for whatever reasons, the user holds
down a key for very long time during the boot process. But we cannot
cope with everything, can we?
Submitted by: Kazutaka YOKOTA (yokota@zodiac.mech.utsunomiya-u.ac.jp)
Most of the standard utilities that depended on (or were broken in
a different way by) the old behaviour of interpreting "" as "."
were fixed a year or two ago. There is still a fairly harmless
bug in tar and a harmless bug in gzip. Tar apparently replaces
"/" by "" when it strips leading slashes.
decrease the size of buffer_map to approx 2/3 of what it used to be
(buffer_map can be smaller now.) The original commit of these changes
increased the size of buffer_map to the point where the system would
not boot on large systems -- now large systems with large caches will
have even less problems than before.
the sd & od drivers. There is also slight changes to fdisk & newfs
in order to comply with different sectorsizes.
Currently sectors of size 512, 1024 & 2048 are supported, the only
restriction beeing in fdisk, which hunts for the sectorsize of
the device.
This is based on patches to od.c and the other system files by
John Gumb & Barry Scott, minor changes and the sd.c patches by
me.
There also exist some patches for the msdos filesys code, but I
havn't been able to test those (yet).
John Gumb (john@talisker.demon.co.uk)
Barry Scott (barry@scottb.demon.co.uk)
a) Removal of private typedefs tulip_uint*_t, use standard u_int_*_t.
b) Change [Dd][Cc]21.4. to just 21.4., seems Dec has done this to all
of the drivers for all OS's. (Did they get in trouble with someone?)
[The few that remain can either not be eliminated, or are waiting for
additional driver functional changes that will remove them.]
c) Move some code from dc21040.h into the driver, later a whole block of that
code and more will move to devar.h, but for now this makes it easier
to study diffs.
d) Add a big bold comment to the README.de file about it not reflecting
reality anymore.
Note that these are all cosmetic changes and should be no functional
change in the driver whatsoever. If _anyone_ spots a problem introduced
by this please let me know ASAP!
scheme. Additionally, add the capability for checking for unexpected
kernel page faults. The maximum amount of kva space for buffers hasn't
been decreased from where it is, but it will now be possible to do so.
This scheme manages the kva space similar to the buffers themselves. If
there isn't enough kva space because of usage or fragementation, buffers
will be reclaimed until a buffer allocation is successful. This scheme
should be very resistant to fragmentation problems until/if the LFS code
is fixed and uses the bogus buffer locking scheme -- but a 'fixed' LFS
is not likely to use such a scheme.
Now there should be NO problem allocating buffers up to MAXPHYS.
are always together with Framing Errors and they were incorrectly
treated as FE's and discarded.
Reorganized the BREAK/FE/PE tests.
Found by: NIST-PCTS
with sio devices (not perfectly, since there is no way to flush the tx
holding register on 8250-16450's. I'm not sure if resetting the fifos
flushes the tx shift register).
Reminded by: NIST-PCTS
is completely empty. There is no interrupt for output completion, so
poll for it every 10 ms after output is nearly complete. Now ttywait()
works right.
Reminded by: NIST-PCTS
succeeds. Writing an action now succeeds iff the handler isn't changed.
(POSIX allows attempts to change the handler to be ignored or cause an
error. Changing other parts of the action is allowed (except attempts
to mask unmaskable signals are silently ignored as usual).)
Found by: NIST-PCTS
registers.) Also clean up some namespace pollution, and remove
gcc-1 support (nothing really works with it anymore anyway.)
Submitted by: Bruce Evans <bde@freebsd.org> and me.
the queues and generate a SIGINT. Previously, this wasn't done if ISIG
was clear or the VINTR character was disabled, and it was done by
converting the BREAK to a VINTR character and sometimes bogusly echoing
this character.
Found by: NIST-PCTS
consistent stack frame in fastmove() so that only one new fault handler
is necessary.
Should be in 2.2. Harmless until the i586 versions are reenabled.
Per Wayne Scott of Intel, the old sequence took 20cycles!!! on a P6.
Another nice side-benefit is that the kernel is about 3K smaller!!!
Submitted by: Wayne Scott <wscott@ichips.intel.com>
larger than the vfs layer can provide. We now automatically support
32K clusters if MSDOSFS is installed, and panic if a filesystem tries
to allocate a buffer larger than MAXBSIZE.
This commit is a result of some "prodding" by BDE.
larger than the vfs layer can provide. We now automatically support
32K clusters if MSDOSFS is installed, and panic if a filesystem tries
to allocate a buffer larger than MAXBSIZE.
This commit is a result of some "prodding" by BDE.
The rest of the code was treating it as a header mbuf, but it was
allocated as a normal mbuf.
This fixes the panic: ip_output no HDR when you have a multicast
tunnel configured.
the keyboard IO port definitions from <machine/console.h>.
Note: I do not have a machine available to test this yet, I sent this
for review to several people who have not replied.
This is also totally busted in 2.2, which has half of the syscons/psm/kbdio
changes in it. This really desperately needs to be tested and fixed
in 2.2 as well.
SCBs in response to a busfree.
When re-queueing an SCB that returned with QUEUE FULL status, reset its timeout.
Ensure that aborted SCBs have an error code set in there xs before it gets
passed back up with scsi_done.
Fix a few KNF nits.
Immediate SCBs, since they always send messages that tell the target to
transition to bus free now rely on the busfree interrupt instead of the
IMMEDDONE sequencer interrupt that was generated before.
Rearrange some code in the message out loop to give ATN a little more time
to drop before we ACK the last byte.
Use SPIORDY instead of REQINIT when snooping for a tag message on a reconnect.
This is done for the same reasons we use SPIORDY in the inb functions.
When going into BITBUCKET mode, turn off HDMAEN in the DFCNTRL register so
that we can "not care" what the value of HCNT is. If HCNT is 0, BITBUCKET
mode won't transfer any data if HDMAEN is set. Seeing as we don't want the
transfer to even think about touching the host, this seems more sane anyway.
Thanks to "Dan Willis" <dan@plutotech.com> for pointing out that this was
a problem.
uses /usr/include/sys/*, which may point to a different build tree. I'm
not sure that this is necessary, but there was a question mark over what
/usr/include/sys points to when building the "user mode" binaries in the
kernel code, especially when building the smp tree.
I suspect that the "right" line here is to use ${INCLUDES}, but that
causes warnings about unused static inline functions in stdio.h and ctype.h
also fixes a bug I've been chasing for a LONG TIME,
due to the fact that spec_bwrite is a NOP and I didn't realise it..
old symptom:
mount -t devfs devfs /mnt
mount /mnt/wd0e /mnt/mnt2
umount /mnt2 <process hangs>
there are some pretty large structural differences internal to devfs
but outwards it should look the same.
I have not yet tested extensively but will do so and fix 3 warnings tomorrow.
