irqs can't work (at best, the first one attached wins). It used to
be necessary to skip this check because of bogus irqs in the sound
drivers, but the sound drivers have been fixed, except possibly the
OSS ones.
arg of type u_short (just write the function in ANSI C like most
other functions in this file instead of fixing the interface or
depending on a gcc feature).
vm_inherit_t. These types are smaller than ints, so the prototypes
should have used the promoted type (int) to match the old-style function
definitions. They use just vm_prot_t and/or vm_inherit_t. This depends
on gcc features to work. I fixed the definitions since this is easiest.
The correct fix may be to change the small types to u_int, to optimize
for time instead of space.
wasted.
Fixed type mismatches for functions with vm_prot_t's as args. vm_prot_t
is u_char, so the prototypes should have used promoteof(u_char) to match
the old-style function definitions. They use just vm_prot_t. This depends
on gcc features to work. I fixed the definitions since this is easiest.
The correct fix may be to change vm_prot_t to u_int, to optimize for time
instead of space.
Removed a stale comment.
Added a new variable, 'bsp_apic_ready', which is set as soon as the bootstrap
CPU has initialized its local APIC. Conditionalize the GENSPLR functions
to call ss_lock ONLY after bsp_apic_ready is TRUE; This should prevent
any problems with races between the time the 1st AP becomes ready and the
time smp_active is set.
region protected by the simplelock 'cpl_lock'.
Notes:
- this code is currently controlled on a section by section basis with
defines in machine/param.h. All sections are currently enabled.
- this code is not as clean as I would like, but that can wait till later.
- the "giant lock" still surrounds most instances of this "cpl region".
I still have to do the code that arbitrates setting cpl between the
top and bottom halves of the kernel.
- the possibility of deadlock exists, I am committing the code at this
point so as to exercise it and detect any such cases B4 the "giant lock"
is removed.
pause before attempting to reset the sequencer address. Remove the
loop checking to see if the address has gone to zero since it is
unnecessary
Adjust the abort SCB timeouts back up to 2 seconds where they should
be.
Fix an oversight in the removal of the bus reset settle code where
we might not run the queue of completed commands.
Remove an unecessary call to ahc_run_done_queue in ahc_reset_current_bus.
Submitted by: Tor Egge <Tor.Egge@idi.ntnu.no>
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.
I have no way of testing this one, first SMP/cy user please let me know...
It is my belief that sio and cy are the only FAST_INTR() ISRs. If this
is a bad assumption please educate me.
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).
Could somebody please update other drivers so that SCSI_RSVD (0x18)
to be handled just like SCSI_BUSY(0x08)?
There's no need for extra state, so we use XS_BUSY for SCSI_RSVD too.
PR: 4257
socket addresses in mbufs. (Socket buffers are the one exception.) A number
of kernel APIs needed to get fixed in order to make this happen. Also,
fix three protocol families which kept PCBs in mbufs to not malloc them
instead. Delete some old compatibility cruft while we're at it, and add
some new routines in the in_cksum family.
We now tsleep() in kthread_init() between start_init()
and prepare_usermode() while waiting for ALL the idle_loop()
processes to come online.
Debugged & tested by: "Thomas D. Dean" <tomdean@ix.netcom.com>
Reviewed by: David Greenman <dg@root.com>
entry to the QOUTFIFO when it is full. This should eliminate the
"Timed out while idle" problems that many have reported.
In truth, this is somewhat of a hack. Although are interrupt latency is
low enough that we should be able to always service the queue in time,
since each entry must be passed up to the higher SCSI layer for what can
be a large amount of processing (perhaps even resulting in a new command
being queued) with interrupts disabled, we need this mechanism to avoid
overflow. In the future, these additional tasks will be offloaded to a
software interrupt handler which should make this hack unnecessary.
as chargeable CPU usage. This should mitigate the problem of processes
doing disk I/O hogging the CPU. Various users have reported the
problem, and test code shows that the problem should now be gone.
Work done by BSDI, Jonathan Lemon <jlemon@americantv.com>,
Mike Smith <msmith@gsoft.com.au>, Sean Eric Fagan <sef@kithrup.com>,
and probably alot of others.
Submitted by: Jnathan Lemon <jlemon@americantv.com>
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.
This code was eliminated when the PEND_INTS algorithm was added. But it was
discovered that PEND_INTS only worsen latency for FAST_INTR() routines,
which can't be marked pending.
Noticed & debugged by: dave adkins <adkin003@gold.tc.umn.edu>
Initially functionality is confined to 32-bit BIOS functions, however
it is envisioned that BIOS support may be enlisted for other
activities in the future.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
Mask the read value from the count register in order to return zero correctly
after TC, as per intel datasheet : "If it is not autoinitialised, this
register will have a count of FFFFH after TC"
comments. Remove reduntant extra addition that was unncessary, and
unneeded mask (asuming inb works correctly).
Submitted by: Stephen McKay <syssgm@dtir.qld.gov.au>
handlers don't skew the results of isa_dmastatus. The function can be
safely called with interrupts disabled.
Submitted by: Stephen McKay <syssgm@dtir.qld.gov.au>
- removed TEST_ALTTIMER.
- removed APIC_PIN0_TIMER.
- removed TIMER_ALL.
mplock.s:
- minor update of try_mplock for new algorithm where a CPU uses try_mplock
instead of get_mplock in the ISRs.
- 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.
Macros to convert the Lite2 lock manager primitives to the names used
in the kernel proper. This allows us to hide them from the lock
manager till they can be turned on.
smp.h:
declarations for the new simplelock functions.
we use lazy masking INTREN()/INTRDIS() might be called with INTs enabled.
This means another higher prio INT to the same cpu could attempt to
re-enter the critical region, but would spin waiting for the lock. Since
it is the owner, it would deadlock.
- s_lock_init()
- s_lock()
- s_lock_try()
- s_unlock()
Created lock for IO APIC and apic_imen (SMP version of imen)
- imen_lock
Code to use imen_lock for access from apic_ipl.s and apic_vector.s.
Moved this code *outside* of mp_lock.
It seems to work!!!
and he says he's happy to see forward movement in aligning our defaults
with a 16 bit world, the 8 bit folk already being veterans by this
point who know how to use userconfig.
In any case, perhaps Warner will soon come to save us all with his Dynamic
Probing(tm) feature and this will all become totally moot in any case,
so it's probably not worth arguing about either way.
included twice as a side effect of including unrelated headers, but I
removed the #include of one of the headers and will soon fix the nested
#include in the other.
the file so that this compiles without forward declarations of that
data. (It is impossible to forward-declare static data in Gnu C.
Declaring it as static is correct, but causes bogus warnings from
gcc -Wredundant-decls. Declaring it as extern works, but causes
correct warnings from gcc -pedantic and is undefined in ANSI C.
We usually declare it as extern. Here it was once really extern,
but botched staticization left it as static here and apparently-
extern in a header file.)
----------------------------------------------------------------------
another system, such as NetBSD, CVS: then name the system in this
line, otherwise delete it. CVS: Reviewed by: CVS: Before
committing changes please have someone check your work and CVS:
include their name here. If the change is trivial and you have not
else; i.e., CVS: they sent us a patch or a new module, then
include their name/email CVS: address here. If this is your work
then delete this line. CVS:
----------------------------------------------------------------------
----------------------------------------------------------------------
Moved description of sio 16650A flag to the sio section and rewrote the
description. It was in the generic console flags section.
Added undocumented options CPU_UPGRADE_HW_CACHE and WLDEBUG.
This define enables the code to ALWAYS run the 8254 timer thru the 8259 ICU.
It is ON by default.
It depricates the usage of "options SMP_TIMER_NC" in the config file.
1) Make sure that the region mapped by a 4MB page is
properly aligned.
2) Don't turn on the PG_G flag in locore for SMP. I plan
to do that later in startup anyway.
3) Make sure the 2nd processor has PSE enabled, so that 4MB
pages don't hose it.
We don't use PG_G yet on SMP -- there is work to be done to make that
work correctly. It isn't that important anyway...
of the kernel, and also most of the dynamic parts of the kernel. Additionally,
4MB pages will be allocated for display buffers as appropriate (only.)
The 4MB support for SMP isn't complete, but doesn't interfere with operation
either.
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
to this when raised, and most were in favor of at least this option
(some also asked for semaphores and messages, but I'll leave that argument
for another time :).
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
instructions more (many cases were already intended to be byte-sized
but were missing prefixes so gas assembled them bogusly), and
rearranging a loop to test at the end.
this code is controlled by smptests.h: TEST_CPUSTOP, OFF by default
new code for handling mixed-mode 8259/APIC programming without 'ExtInt'
this code is controlled by smptests.h: TEST_ALTTIMER, ON by default
- TEST_CPUSTOP adds stop_cpus()/restart_cpus(), OFF by default
- TEST_ALTTIMER new method for attaching 8259 PIC to APIC
this method avoids 'ExtInt' programming, ON by default
- TIMER_ALL sends 8259/8254 timer INTs to all CPUs, ON by default
- ASMPOSTCODExxx code to display bytes to POST hardware, OFF by default
and bios.S were small enough and have been merged back into their
respective files in biosboot/, conditionalized on CDBOOT. Other
files might be merged at a later stage.
Caveat emptor: i cannot test this right now.
This is the long-threatened ISO 9660 CD-ROM bootstrap code.
This work has been sponsored by Plutotech International, Inc (who paid
the initial work), and interface business GmbH (where i did most of
the work). A big thanks also goes to Bruce Evans, for his continuing
help and answering my stupid questions.
The code is basically functioning, with the following caveats:
. Rock Ridge attributes are not yet supported.
. Only SCSI CD-ROMs are supported, since i fail to see any possibility
to determine the drive type using BIOS functions. (Even for hard disks,
this determination is done by a big hack only.)
. El Torito specifies a lot of crap and useless misfeatures, but crucial
things like the ability to figure out the CD TOC have been ``forgotten''.
Thus, if you wanna boot a multisession CD, you need to know at which CD
block your session starts, and need to speciffy it using the @ clause.
. None of the CD-ROM controllers i've seen so far implements the full
El Torito specification at all. Adaptec is probably the closest, but
they miss on non-emulation booting (which would be the most logical
choice for us). Thus, the current code bloats the 7.5 KB boot code
up to 1.44 MB, in order to fake a `floppy' image.
If you wanna use it, specify this file as the boot image on the
command-line of the mksiosfs command (option -b).
Caveat emptor: some versions of the Adaptec BIOS might even fail to
access the CD-ROM at all, using the BIOS functions. I think i've
notice this for ver 1.26, the code has been tested with ver 1.23.
The boot string is as follows:
[@sess-start] [filename] [-flags]
sess-start Extend # where the last session starts, measured in
CD-ROM blocks.
filename As usual, but the input is case-insensitive by now
(since we don't grok RR anyway).
flags As usual, but -C (use CDROM root f/s) is default, so
specifying -C will decactivate this option (which is
probably not what you want :).
A lot of cleanup work is probably required, and some of the files
could/should be merged back to biosboot, perhaps made conditional on
some #ifdef. The malloc implementation that comes with cdboot might
also be useful for kzipboot. (I needed a malloc() since the root dir
ain't fixed in size on a CD.)
I've been testing all this with a 2.2-STABLE as the base for biosboot.
I don't expect too many surprises, although i know the biosboot stuff
has been changed a lot in -current lately. I'm sure Bruce will
comment on all this here anyway. :-)
This work has been sponsored by Plutotech International, Inc (who paid
the initial work), and interface business GmbH (where i did most of
the work). A big thanks also goes to Bruce Evans, for his continuing
help and answering my stupid questions.
The code is basically functioning, with the following caveats:
. Rock Ridge attributes are not yet supported.
. Only SCSI CD-ROMs are supported, since i fail to see any possibility
to determine the drive type using BIOS functions. (Even for hard disks,
this determination is done by a big hack only.)
. El Torito specifies a lot of crap and useless misfeatures, but crucial
things like the ability to figure out the CD TOC have been ``forgotten''.
Thus, if you wanna boot a multisession CD, you need to know at which CD
block your session starts, and need to speciffy it using the @ clause.
. None of the CD-ROM controllers i've seen so far implements the full
El Torito specification at all. Adaptec is probably the closest, but
they miss on non-emulation booting (which would be the most logical
choice for us). Thus, the current code bloats the 7.5 KB boot code
up to 1.44 MB, in order to fake a `floppy' image.
If you wanna use it, specify this file as the boot image on the
command-line of the mksiosfs command (option -b).
Caveat emptor: some versions of the Adaptec BIOS might even fail to
access the CD-ROM at all, using the BIOS functions. I think i've
notice this for ver 1.26, the code has been tested with ver 1.23.
The boot string is as follows:
[@sess-start] [filename] [-flags]
sess-start Extend # where the last session starts, measured in
CD-ROM blocks.
filename As usual, but the input is case-insensitive by now
(since we don't grok RR anyway).
flags As usual, but -C (use CDROM root f/s) is default, so
specifying -C will decactivate this option (which is
probably not what you want :).
A lot of cleanup work is probably required, and some of the files
could/should be merged back to biosboot, perhaps made conditional on
some #ifdef. The malloc implementation that comes with cdboot might
also be useful for kzipboot. (I needed a malloc() since the root dir
ain't fixed in size on a CD.)
I've been testing all this with a 2.2-STABLE as the base for biosboot.
I don't expect too many surprises, although i know the biosboot stuff
has been changed a lot in -current lately. I'm sure Bruce will
comment on all this here anyway. :-)
because there was no non-inline spl0() to call.
Don't frob intr_nesting_level in idle() or cpu_switch(). Interrupts
are mostly disabled then, so the frobbing had little effect.
is defined, or SMP is defined. It is silly to configure PERFMON when
it can't work (it will be disabled at runtime), but I like to leave
the PERFMON configuration alone when I temporarily disable support for
modern CPUs to run regression tests.
Removed an unused #include.
- Added the psm options PSM_HOOKAPM and PSM_RESETAFTERSUSPEND.
LINT:
- Added the psm options PSM_HOOKAPM and PSM_RESETAFTERSUSPEND.
- Added comments on the flag 0x20 for syscons.
- Clarified descriptions on the flags (0x02, 0x04) regarding the cursor
shape in syscons.
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.
If the configuration option PSM_HOOKAPM is defined and the APM device
is available, the psm driver will issue the ENABLE command to the
pointing device at the resume APM event if the device was open when
the system went into suspended mode. If the option
PSM_RESETAFTERSUSPEND is specified in addition to PSM_HOOKAPM, the
driver will try to reset the pointing device before sending the
ENABLE command.
Built-in PS/2-type pointing devices in some laptops (all the reports I
heard were about Toshiba models) sometimes don't work immediately
after the system is resumed. The device MAY become available after a
while. The system may exhibit the same symptom in other OS's too
(no, FreeBSD is not the only OS that is suffering :-).
I don't know the correct way of solving this yet, but it's been
reported that issuing the ENABLE command after resumption wakes up the
pointing device.
Without PSM_HOOKAPM, the psm driver behaves in the same way as before.
Problem reported in the bsd-nomads mailing list in Japan.
fix stopped it being used in all cases, because substitution on unset
variables does not work.
When profiling, put -malign-functions=4 in CFLAGS instead of in PROF.
This fixes the histogram counts for profiling support functions. It
gives bogus but harmless extra alignment for genassym etc.
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...)
- added Xcpustop IPI code to support stop_cpus()/restart_cpus().
it is off by default, enable via smptests.h:TEST_CPUSTOP
intr_machdep.h:
- moved +ICULEN to lower level.
- added entry for Xcpustop.
General cleanup.
New functions to stop/start CPUs via IPIs:
- int stop_cpus( u_int map );
- int restart_cpus( u_int map );
Turned off by default, enabled via smptests.h:TEST_CPUSTOP.
Current version has a BUG, perhaps a deadlock?
This variable is a bitmap showing all CPUs present EXCEPT the CPU
owning the variable. In other words, it is equal to the global bitmap
'all_cpus' minus its own bit.
Till now NMIs would be ignored. Now an NMI is caught by the BSP.
APs still ignore NMI, am working on code to allow a CPU to stop other CPUs
via an IPI.
