The code was originaly contributed by Kelly Yancey
<kbyanc@freedomnet.com> in PR i386/6269 and revised by Akio Morita
<amorita@meadow.scphys.kyoto-u.ac.jp> and me. Test was performed by
Akio Morita and Toshiomi Moriki <moriki@db.is.kyushu-u.ac.jp>.
- Fix stylistic bug in identcpu.c.
- Update copyright in initcpu.c
- Fix typo in LINT.
PR: 6269 and 6270
print out a one line description/dump of every SCSI CDB sent to a
particular debugging target or targets.
This is a good bit more useful than the other debugging modes, I think.
Change some things in LINT to note the availability of this new option.
Fix an erroneous argument to scsi_cdb_string() in scsi_all.c
Reviewed by: gibbs
timeouts in the SA driver (timeouts for space, rewind and erase). Folks
can lengthen the timeouts if their hardware is especially slow, or shorten
them if they want to be notified of errors a little sooner.
Also, get rid of two OD driver options. The od driver has been made
obsolete by the da driver.
Reviewed by: ken, gibbs
Submitted by: Dag-Erling Coidan Smørgrav <des@FreeBSD.ORG>
the in-kernel linker to access the _DYNAMIC data for doing loadable elf
modules. The alpha kernel is already done this way, I've borrowed some of
the hacks from there.
This is primarily aimed at the 3-stage boot process which is intended to
be able to do pre-loading of kernel modules.
Note that the entry point isn't 0xf0100000 any more, it'll be a little
further on - but this value is stored in the headers. I don't think this
will be a problem, but I'm sure somebody will tell me if it is. :-)
I'm not sure if btxboot is going to like this, it doesn't do proper ELF
header checking and assumes that there are exactly two program header
entries and that they are both PT_LOAD entries - a bad assumption.
The last consumer of this code (the old SCSI system) has left us and
the CAM code does it's own bouncing. The isa dma system has been
doing it's own bouncing for a while too.
Reviewed by: core
Now supposedly less harmful way of accessing VGA sequencer registers
is default. An alternative, often troublesome, I/O access is optional.
Discussed with: sos, jkh
on opt_global.h. This actually matters for genassym.o (it depends
on at least SMP).
Don't undefine KERNEL for compiling genassym.c. genassym.o really
depends on KERNEL, and the prototype mismatches that required
undefining KERNEL in rev.1.49 no longer exist.
Compile gensetdefs* with the same flags as genassym*. External
`gen' programs such linux_genassym should also use these flags
(${GEN_CFLAGS}).
Fixed missing dependency generation for gensetdefs.o. C sources
for external `gen' programs should be added to GEN_CFILES to get
their dependencies generated.
Cleaned up flags definitions and use. All of ${CFLAGS} is now
passed to mkdep and the assembler (both are actually variants of
${CC} and will ignore the irrelevant flags).
annoying #!CAM# indicators are used to be clear, in the expectation
that the places they show will be either fixed or diked out reasonably
quickly.
Reviewed by: ken
CAM options section.
Document that SCSI_DELAY is in milliseconds, not seconds.
Tell users that SCSI_CAM is only needed if you've got the QLogic driver in
your kernel.
Reviewed by: gibbs
Kazu writes:
The VESA support code requires vm86 support. Make sure your kernel
configuration file has the following line.
options "VM86"
If you want to statically link the VESA support code to the kernel,
add the following option to the kernel configuration file.
options "VESA"
The vidcontrol command now accepts the following video mode names:
VESA_132x25, VESA_132x43, VESA_132x50, VESA_132x60, VESA_800x600
The VESA_800x600 mode is a raster display mode. The 80x25 text will
be displayed on the 800x600 screen. Useful for some laptop computers.
vidcontrol accepts the new `-i <info>' option, where <info> must be
either `adapter' or `mode'. When the `-i adapter' option is given,
vidcontrol will print basic information (not much) on the video
adapter. When the `-i mode' option is specified, vidcontrol will
list video modes which are actually supported by the video adapter.
Submitted by: Kazutaka YOKOTA yokota@FreeBSD.ORG
