simplifies some assumptions and stops some code compile problems.
This should fix the compile hiccup in PR#3491, but smp kernel profiling
isn't likely to be fixed by this.
1) i586_bcopy() problem
There have been a number of reports that the syscons doesn't work
properly if i586_bcopy() is enabled.
The problem prevented users from installing 2.2(.1)-RELEASE. The
symptom is that the system looks frozen during device probe or just
before the main installation menu. The workaround was to specify the
flag 0x01 to the npx device so that i586_bcopy() is disabled.
The patch forces the syscons to call generic_bcopy() when copying
to/from the video memory, even if CPU is Pentium and i586_bcopy() is
enabled. i586_bcopy() is still called for copy operations between
non-video memory regions.
PR: kern/2277, kern/3066, kern/3107, kern/3134
2) video mode parameter table problem
The syscons reads and uses the video mode parameter table provided by
the VGA BIOS to set VGA registers when changing video mode and
modifying font data. It appears that in some VGA BIOSes the table is
not ordered as the syscons expects, and this leads to screen
corruption.
The problem prevented users from installing 2.2(.1)-RELEASE. The
symptom is the corrupt screen or strange vertical lines soon after the
kernel is loaded into memory (just after the kernel decompression).
The patch performs simplistic test and if it fails, set video_mode_ptr
to NULL so that the video mode switching won't happen.
This is an interim kludge. There should be a better way to deal with
the problem.
PR: kern/2498, conf/2775, conf/3354
Reviewed by: sos
Tested by: PR originators (not all of them, though)
There are various options documented in i386/conf/LINT, there is more to
come over the next few days.
The kernel should run pretty much "as before" without the options to
activate SMP mode.
There are a handful of known "loose ends" that need to be fixed, but
have been put off since the SMP kernel is in a moderately good condition
at the moment.
This commit is the result of the tinkering and testing over the last 14
months by many people. A special thanks to Steve Passe for implementing
the APIC code!
resetting the keyboard.
Well, sorry, this bug is totally my fault. I DID intend to preserve
them, but somehow I failed.
The bug puts some old keyboard controllers in a strange state,
resulting in keyboard freeze or random key input.
The fix closes PR kern/3067.
Use the name argument almost the same in all LKM types. Maintain
the current behavior for the external (e.g., modstat) name for DEV,
EXEC, and MISC types being #name ## "_mod" and SYCALL and VFS only
#name. This is a candidate for change and I vote just the name without
the "_mod".
Change the DISPATCH macro to MOD_DISPATCH for consistency with the
other macros.
Add an LKM_ANON #define to eliminate the magic -1 and associated
signed/unsigned warnings.
Add MOD_PRIVATE to support wcd.c's poking around in the lkm structure.
Change source in tree to use the new interface.
Reviewed by: Bruce Evans
(see LINT). There is a new low-level console type that is more suitable
for use with gdb-remote.
Fixed setting of speed at probe time for the serial console (if any).
Reviewed by: dfr
change typematic rate, or the X server (XFree86 or Accelerated X)
starts up.
So far, there have been two independent reports from Dell Latitude XPi
notebook/laptop owners. The Latitude seems to be the only system which
suffers from this problem. (I don't know the problem is with the
entire Latitude line or with only some Latitude models) No problem
report has been heard about other systems (I certainly cannot
reproduce the problem in my -current and 2.2 systems).
In 3.0-CURRENT, 2.2-RELEASE and 2.2-GAMMA-970310, when programming the
keyboard LED/repeat-rate, `set_keyboard()' in `syscons' tells the
keyboard controller not to generate keyboard interrupt (IRQ1) and then
enable tty interrupts, expecting the keyboard interrupt doesn't occur.
It appears that somehow Latitude's keyboard controller still generates
the keyboard interrupt thereafter, and `set_keyboard()' doesn't see
the return code from the keyboard because it is consumed by the
keyboard interrupt handler.
The patch entirely disables tty interrupts while setting LED and
typematic rate in `set_keyboard()', making the routine behave more
like the previous versions of `syscons' (versions in 2.1.X and
2.2-ALPHA, -BETA, and some -GAMMAs). The reporter said this patch
eliminated the problem.
(I also found another typo/bug, but the reporter and I found that it
wasn't the cause of the problem...)
This should go into RELENG_2_2.
Warning: this won't work yet with PCVT_SCANSET=2 along in early
console mode (boot -c, or boot -d).
A big thanks to Kazutaka, and a word of apologies for delaying the
review for that long time...
Submitted by: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA)
valid signals, else return EINVAL for ioctl VT_SETMODE.
this fixes a problem that anybody with vty access can panic the system.
2.2-Candidate (and 2.1.0 I believe)
Reviewed-by: sos
changes, so don't expect to be able to run the kernel as-is (very well)
without the appropriate Lite/2 userland changes.
The system boots and can mount UFS filesystems.
Untested: ext2fs, msdosfs, NFS
Known problems: Incorrect Berkeley ID strings in some files.
Mount_std mounts will not work until the getfsent
library routine is changed.
Reviewed by: various people
Submitted by: Jeffery Hsu <hsu@freebsd.org>
The PS/2 mouse device responds to a reset command with a sequence of
ACK(fa), RESULT(aa) and ID(00). Most PS/2 mice immediately returns
ACK, but spend sometime before sending RESULT. The Armada takes time
before ACK; extra delay is necessary before the call to read ACK.
The problem was reported in comp.unix.bsd.freebsd.misc and the patch
was tested by the reporter. No PR was filed, by the way.
with <= 100 usec between each character arrival time. This didn't happen
until rev.1.75 of clock.c because DELAY(100) used to delay for closer to
80 usec than 100 usec, and the minimum time between character arrivals is
87.8 usec at the maximum supported speed of 115200 bps 8N1.
Clear DCD timestamp flag on close (the input timestamp flag is already
cleared).
key "print scrn".
It used to stop at the first non-open vty, now it skips the non-open
ones and thereby enable one to cycle around all open vty by pressing
"print scrn".
I have code to calibrate the overhead fairly accurately, but there
is little point in using it since it is most accurate on machines
where an estimate of 0 works well. On slow machines, the accuracy
of DELAY() has a large variance since it is limited by the resolution
of getit() even if the initial delay is calibrated perfectly.
Use fixed point and long longs to speed up scaling in DELAY().
The old method slowed down a lot when the frequency became variable.
Assume the default frequency for short delays so that the fixed
point calculation can be exact.
Fast scaling is only important for small delays. Scaling is done
after looking at the counter and outside the loop, so it doesn't
decrease accuracy or resolution provided it completes before the
delay is up. The comment in the code is still confused about this.
- don't uselessly initialize the fifo "DMA" bit at attach time.
- initialize the fifo "DMA" bit at open time. Without this, the device
interrupts for every character received, reducing input performance
to that of an 8250.
- don't uselessly initialize the fifo trigger level to 8 (scaled to
256) at attach time.
- don't scale the fifo trigger level to 512 bytes. The driver's pseudo-
dma buffer has size 256, so it can't handle bursts of size 512 or 256.
It should be able to handle the second lowest ftl (2 scaled to 64).
- don't reset the fifos in siostop(). Reset triggers a hardware bug
involving wedging of the output interrupt bit This workaround
unfortunately requires ESP support to be configured.
an X seesion. Really stupid error of me, and I've been looking at
this code SO many times. Thanks to Kazutaka YOKOTA for seeing this..
Submitted by: Kazutaka YOKOTA
one in draw_mouse causes spontanious hangs on my p5-100 when I
move the mouse excessively. Forgot that on the last commit, so
using the mouse or destructive cursor would produce large amounts
of flicker..
cur_console is NULL when copy_font() is first called from scinit(). This
is apparently harmless when scinit() is called early from sccninit() -
page 0 is apparently mapped r/w then, and 0->status contains suitable
garbage. However, when there is a serial console, scinit() is first
called from scattach() when the page tables are completely initialized,
so the NULL pointer causes a panic.
Submitted by: bruce
called early for console i/o. The timer is usually in BIOS mode
if it isn't explicitly initialized. Then it counts twice as fast
and has a max count of 65535 instead of 11932. The larger count
tended to cause infinite loops for delays of > 20 us. Such delays
are rare. For syscons and kbdio, DELAY() is only called early
enough to matter for ddb input after booting with -d, and the delay
is too small to matter (and too small to be correct) except in the
PC98 case. For pcvt, DELAY() is not used for small delays (pcvt
uses its own broken routine instead of the standard broken one),
but some versions call DELAY() with a large arg when they unnecessarily
initialize the keyboard for doing console output. The problem is
more serious for pcvt because there is always some early console
output.
Guard against the i8254 timer being partially or incorrectly
initialized. This would have prevented the endless loop.
Should be in 2.2.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
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)
