1) Adjust NFRAMES from 16 to 8 per 16k of memory.
2) Acknowledge interrupts to the card early in the interrupt
handler before processing the event that caused the interrupt.
This frees the card to process addtional events instead of
waiting for the driver to finish handling events.
3) Changed the initialization of the transmit buffers to be a
loop so that the number of buffers can be more easily changed.
4) Moved the code to take the adapter out of loop back mode to just
before we enable the receiver.
I also made the driver dynamically size its resource arrays at attach
time so that we can take full advantage of adapters with more than 16k
of memory.
Richard has some other changes he's working on to improve performance,
but this should get ee16 support working reliably again.
Thanks to Wes Santee <wes@bogon.net> for testing these patches.
Submitted by: Richard Straka <straka@user1.inficad.com>
full implementation of the sate machine as described in RFC1661, and
provides support for plugging in various control protocols. I needed
this to provide PPP support for the BISDN project (right now).
Unfortunatley, while the existing API was almost up to the point, i
needed one minor API change in order to decouple the this-layer-
started and this-layer-finished actions from the respective Up and
Down events of the lower layer. This requires two additional lines in
the attach routines of all existing lower layer interface drivers that
are using syncPPP (shortcutting these actions and events). Apart from
this, i believe i didn't change the API of all this, so everything
should plug in without too many hassles. Please report if i broke
something in the existing drivers.
For a list of features (including new ones like dial-on-demand), and
things still to be done, please refer to the man page i'll commit asap.
Encouraged by: Serge Vakulenko <vak@cronyx.ru>
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
- doesn't break my system.
- NOT yet verified on the affected motherboard.
Stifle an annoying dma_start busy message for the sound cards.
Submitted by: "John S. Dyson" <toor@dyson.iquest.net>
. It makes cd9660 root f/s working again.
. It makes CD9660 a new-style option.
. It adds support to mount an ISO9660 multi-session CD-ROM as the root
filesystem (the last session actually, but that's what is expected
behaviour).
Sigh. The CDIOREADTOCENTRYS did a copyout() of its own, and thus has
been unusable for me for this work. Too bad it didn't simply stuff
the max 100 entries into the struct ioc_read_toc_entry, but relied on
a user supplied data buffer instead. :-( I now had to reinvent the
wheel, and created a CDIOREADTOCENTRY ioctl command that can be used
in a kernel context.
While doing this, i noticed the following bogosities in existing CD-ROM
drivers:
wcd: This driver is likely to be totally bogus when someone tries
two succeeding CDIOREADTOCENTRYS (or now CDIOREADTOCENTRY)
commands with requesting MSF format, since it apparently
operates on an internal table.
scd: This driver apparently returns just a single TOC entry only for
the CDIOREADTOCENTRYS command.
I have only been able to test the CDIOREADTOCENTRY command with the
cd(4) driver. I hereby request the respective maintainers of the
other CD-ROM drivers to verify my code for their driver. When it
comes to merging this CD-ROM multisession stuff into RELENG_2_2 i will
only consider drivers where i've got a confirmation that it actually
works.
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.
Peter Wemm <peter@spinner.DIALix.COM>, Steve Passe <smp@csn.net>
removed all the IPI_INTS code.
made the XFAST_IPI32 code default, renaming Xfastipi32 to Xinvltlb.
cleanup of i386/isa/isa_device.h to eliminate SMP dependancies:
made the id_irq member of struct isa_device an u_int.
made the id_drq member of struct isa_device an int.
removed all other '#ifdefs' concerning SMP & APIC_IO.
removed SMP/APIC_IO dependancies from if_ze.c.
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)
The SMP source was merged into 3.0-current last nite and this broke
the make of sbin/dset.
Should make things work for non-SMP case.
People making SMP kernels will need to edit i386/isa/isa_device.h, re-enabling
'#include "opt_smp.h"'. People making SMP worlds will have to punt for now...
I'm thinking about the real solution, but for now the goal is to NOT break
the world!
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!
have successfully built, booted, and run a number of different ELF
kernel configurations, including GENERIC. LINT also builds and
links cleanly, though I have not tried to boot it.
The impact on developers is virtually nil, except for two things.
All linker sets that might possibly be present in the kernel must be
listed in "sys/i386/i386/setdefs.h". And all C symbols that are
also referenced from assembly language code must be listed in
"sys/i386/include/asnames.h". It so happens that failure to do
these things will have no impact on the a.out kernel. But it will
break the build of the ELF kernel.
The ELF bootloader works, but it is not ready to commit quite yet.
delay after we reset the card to allow the card to come back to life.
It appears the newer card takes longer to reset.
Submitted by: Samuel Lam <skl@ScalableNetwork.com>
type mismatches. There was no problem in practice (at least on 386's).
The timeout args still get bogusly cast from int to `void *' via
caddr_t and back to int.
type mismatches. mcd and scd were/are particularly bogus. They
used a general purpose function taking 2 args for the timeout
function and fudged varargs stuff to supply the second arg for the
timeout case. This broke `cc -mrtd'. Bounce through a timeout
function instead. The timeout arg still gets bogusly cast from
int to `void *' and back.
type mismatches. There was no problem in practice (at least on 386's).
Don't cast NULL in calls to timeout functions. pcvt is fully prototyped
and doesn't support K&R.
Timeout functions take args of type `void *', so use magic numbers of
type `void *' for UPDATE_* to reduce the danger of wrong conversions.
Removed FreeBSD-pre-1.1-related TIMEOUT_FUNC_T macro. It was especially
bogus for the pre-1.1 case.
1) Dell Latitude XPi
This laptop has a strange, IMHO broken :-), keyboard controller which
wouldn't disable the keyboard interrupt. The kludge is to disable tty
intr. during set_keyboard(), used for changing LED and setting
typematic.
The patch also changes the function name:
set_keyboard() -> set_keyboard_param()
Although it is a static function, the name corrides with a routine in
`syscons' and is confusing when debugging the kernel which has both
`syscons' and `pcvt' with DDB. (Suggested by Bruce)
2) doreset() bug
doreset() failed to preserve some bits in the keyboard controller's
command byte during keyboard reset. This bug may put some keyboard
controllers in old motherboards (386 and 486) in a strange state,
resulting in complete keyboard lockup or random key input.
Reviewed by: Joerg
Increase the delay in read_eeprom_data() by two orders of magnitude.
> A better fix would be to make read_eeprom_data() call
> f_is_eeprom_busy() after the DELAY().
Submitted by: Samuel Lam <skl@ScalableNetwork.com>
for the ix driver.
Add a shutdown hook that resets the etherexpress so that Windoze can find
the card after a warm boot.
Submitted by: Aaron Smith <aaron@tau.veritas.com>
Obtained From: NetBSD
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.
