Made NEW_STRATEGY default.
Removed misc. old cruft.
Centralized simple locks into mp_machdep.c
Centralized simple lock macros into param.h
More cleanup in the direction of making splxx()/cpl MP-safe.
Several new fine-grained locks.
New FAST_INTR() methods:
- separate simplelock for FAST_INTR, no more giant lock.
- FAST_INTR()s no longer checks ipending on way out of ISR.
sio made MP-safe (I hope).
Add support for MODEX 320x240x256color with "unchained" adressing, giving
access to all 256K on all VGA's, those with that much memory that is :)
Also make sysmouse use the right resolution in graphics modes.
- removed TEST_ALTTIMER.
- removed APIC_PIN0_TIMER.
- removed TIMER_ALL.
apic_vector.s:
- new algorithm where a CPU uses try_mplock instead of get_mplock:
if successful continue as before.
if fail set ipending bit, mask INT (to avoid recursion), cleanup & iret.
This allows the CPU to return to successful work, while the ISR will be run
by the CPU holding the lock as part of the doreti dance.
1. Add new interface, add_scrn_saver()/remove_scrn_saver(), to declare
loading/unloading of a screen saver. The screen saver calls these
functions to notify syscons of loading/unloading events.
It was possible to load multiple savers each of which will try to
remember the previous saver in a local variable (`old_saver'). The
scheme breaks easily if the user load two savers and unload them in a
wrong order; if the first saver is unloaded first, `old_saver' in the
second saver points to nowhere.
Now only one screen saver is allowed in memory at a time.
Soeren will be looking into this issue again later. syscons is
becoming too heavy. It's time to cut things down, rather than adding
more...
2. Make scrn_timer() to be the primary caller of the screen saver
(*current_saver)(). scintr(), scioctl() and ansi_put() update
`scrn_time_stamp' to indicate that they want to stop the screen saver.
There are three exceptions, however.
One is remove_scrn_saver() which need to stop the current screen saver
if it is running. To guard against scrn_timer() calling the saver during
this operation, `current_saver' is set to `none_saver' early.
The others are sccngetc() and sccncheckc(); they will unblank the
screen too. When the kernel enters DDB (via the hot key or a
break point), the screen saver will be stopped by sccngetc().
However, we have a reentrancy problem here. If the system has been in
the middle of the screen saver...
(The screen saver reentrancy problem has always been with sccnputc()
and sccngetc() in the -current source. So, the new code is doing no
worse, I reckon.)
3. Use `mono_time' rather than `time'.
4. Make set_border() work for EGA and CGA in addition to VGA. Do
nothing for MDA.
Changes to the LKM screen saver modules will follow shortly. YOU NEED
TO RECOMPILE BOTH SCREEN SAVERS AND KERNEL AS OF THESE CHANGES.
Reviewed by: sos and bde
and released. It should use `spcl' consistently in both cases,
otherwise shift/control/alt state may not be correctly set/reset.
(Even with this fix, you can still make syscons confused and fail to
change internal state if you really want to, by installing a really
arcane and artificial keymap.)
PR: i386/4030
Reviewed by: sos
cursor (CHAR_CURSOR)
1. Reduced the number of calls to set_destructive_cursor(). The
destructive cursor produced noticeable overhead on the system. It was
caused by draw_cursor_image() calling set_destructive_cursor() every
so often.
set_destructive_cursor() absolutely needs to be called when
a) the character code under the cursor has changed either because
the cursor moved or because the screen was updated or the mouse
pointer overlapped the cursor.
b) Or a new font has been loaded,
c) or the video mode has been changed,
d) or the cursor shape has been changed,
e) or the user switched virtual consoles.
2. Turn off the configuration flag CHAR_CURSOR (destructive cursor) in
scattach() if we have a non-VGA card. The destructive cursor works
only for VGA.
3. Removed redundant calls to set_destructive_cursor() in some places.
4. Fixed the "disappearing mouse pointer" problem. The mouse pointer
looked hidden under the destructive cursor when it overlaped the cursor.
A slightly different version of the patch was reviewd and OKed by
sos and ache.
Add a new configuration flag, KBD_NORESET (0x20) to tell scprobe() not
to reset the keyboard.
IBM ThinkPad 535 has the `Fn' key with which the user can perform
certain functions in conjunction with other keys. For example, `Fn' +
PageUP/PageDOWN adjust speaker volume, `Fn' + Home/End change
brightness of LCD screen. It can also be used to suspend the system.
It appears that these functions are implemented at the keyboard level
or the keyboard controller level and totally independent from BIOS or
OS. But, if the keyboard is reset (as is done in scprobe()), they
become unavailable. (There are other laptops which have similar
functions associated with the `Fn' key. But, they aren't affected by
keyboard reset.)
ThinkPad 535 doesn't have switches or buttons to adjust brightness and
volume, or to put the system into the suspend mode. Therefore, it is
essential to preserve these `Fn' key functions in FreeBSD. The new
flag make scprobe() skip keyboard reset.
If this flag is not set, scprobe() behaves in the same say as before.
(If we only knew a way to detect ThinkPad 535, we could skip keyboard
reset automatically, but...)
adapter during the system boot. It always assumes there is at least a
monochrome adapter.
This is rather strange assumption. If there is no dispaly adapter, the
console driver cannot be any good...
In this patch, scinit() is split into two parts; the first part is
now called scvidprobe() which will detect the presence of video card
at the CGA or MONO buffer address and returns TRUE if found. It is
called during sccnprobe() and scprobe(). Both will fail if no video
card is found.
The second part, whose name stays the same as before, scinit(), is
called from sccninit() and scattach() to complete initialization of
the found video card.
The keyboard probe code is moved from scprobe() to sckbdprobe();
scprobe() now calls scvidprobe() and sckbdprobe() to carry out device
probe. (This is rather a cosmetic change, but it sure makes the code
look better organized.)
The problem pointed out by Joerg.
speed using the boot blocks, instead of a hardcoded value stuck in the
kernel. This way, you can have systems using the same kernel but different
console speeds.
Add a sysctl entry for changing the system console speed.
Lock the user tty speed to match the system console speed.
Nuke CONSPEED.
Reviewed by: bde
When an ioctl command SW_XXXX is issued, scioctl() checks if the font
appropriate for the specified mode is already loaded. The check was
correctly done for 8 line and 16 line fonts, but not for 14 line font.
The symbols FONT_8, FONT_14 and FONT_16 were defined as numbers but
were sometimes treated as bit flags. They are now defined as bit
flags.
2) screen blinking (two fixes)
Removed a redundant call to timeout() in do_bell().
Don't let blink_screen() write to the video buffer if the screen is in
the graphics (UNKNOWN) mode.
3) screen saver timeout
The ioctl command CONS_BLANKTIME sets the screen saver's timeout. The
value of zero will disable the screen saver. If the screen saver is
currently running it should be stopped.
4) border color and destructive cursor (two fixes)
The border color and the cursor type can be changed via escape
sequences. But only VGA can change the border color and set the
cursor type to destructive (CHAR_CURSOR) in the current syscons.
scan_esc() failed to check this.
Reviewed by: sos
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)
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
The 'getchar' function in syscons (sccngetc) is used by UserConfig to
get keyboard input from the user. When it was modified to use the
shared keyboard port routines it used the port passed in during the
probe routine. Since the probe routine was not yet called, the port was
set to 0, which is obviously not going to work.
Pre-initialize sc_port to IO_KBD which is really a kludge, but it's how
the previous driver did it's job.
Found by: remote GDB
syscons and psm, curtesy Kazutaka Yokota with minor changes by
me. This contains an update of the psm driver as well.
This also fixes the breakage that I introduced to the psm driver by
making syscons poll for keyboard events in the atempt to fix the
hanging keyboard problem.
It works perfectly for me, and I'd like to hear from all that
have had keyboard/ps/2 mouse problems if this is the cure...
Submitted by: Kazutaka YOKOTA (yokota@zodiac.mech.utsunomiya-u.ac.jp)
almost complete control over RTS (control of its initial value is still
missing).
This fixes PR 1644 for sio.
The author of PR 1644 wants it in 2.1.6 and 2.2. This may be safe since
the complications are only in rarely used cases that I hope I've covered.
actually harmless.
2. Fixed code to match comment in scintr().
3. Don't allow even root to take control of the machine when securelevel > 0.
I've secured the accesses to PSL_IOPL in all drivers and asked pst to
review it, but he seems to be busy. Write access to /dev/kmem and
other critival devices currently leaks across raisings of securelevel
via open fd's, so there may as well be a similar leak for PSL_IOPL.
4. (Most important.) Don't corrupt memory beyond the screen buffers if
the cursor happens to be off the 80x25 screen when syscons starts.
5. Fix console cursor update (not perfect yet).
Submitted by: bruce
~
Steve Passe
Mike Smith
Søren Schmidt
Poul-Henning Kamp
Bruce Evans
John Dyson
Kazutaka YOKOTA
Brian Somers
Andrey A. Chernov
Paul Traina
Doug Rabson
Peter Wemm
Stephen McKay
Peter Dufault
Joerg Wunsch
Gary Palmer
John-Mark Gurney
KATO Takenori
Jordan K. Hubbard
Alexander Langer
Satoshi Asami
Nate Williams