uses white) so base the color of the border on SC_NORM_ATTR rather
than hardcoding BG_BLACK.
- Use SC_DRIVER_NAME rather than hardcoding 'sc' in message strings
(see also sys/dev/syscons/syscons.h rev. 1.82).
syscons(4) and its pseudo-devices don't get confused (including by
other device drivers) with the system controller devices which are
also termed 'sc' in the OFW tree (and which we probably want to
interface with hwpmc(4) one day).
VTB_FRAMEBUFFER specific code. On sparc64 we don't use a buffer of
type VTB_FRAMEBUFFER (see syscons.c) and excluding the respective
code here allows to compile syscons(4) without isa(4).
Requested by: joerg, marcel, yongari
a band-aid allowing to call this function savely multiple times, e.g.
during sckbdprobe() and sc_probe_unit(). Otherwise calling it a second
time results in a non-working keyboard. This needs a lot of more work
to actually do the right thing and work like expected.
- Let sunkbd_configure() return the number of the found keyboards, i.e.
1 in case probing succeeds, as it's expected. The return values of the
keyboard configure functions however currently aren't checked so this
doesn't make a difference at the moment.
- Use FBSDID.
Use bus_generic_probe() and add a bus_add_child() interface method to
allow device drivers to use the identify method to add themselves if
need be (e.g. syscons(4)).
- Use FBSDID.
consist of the expected number of address and size cells (we can't use
dynamic arrays here because at the point in the boot process when this
code is used malloc() doesn't work, yet). This fixes a Fast Data Access
MMU Miss when uart(4) (erroneously) calls OF_decode_addr() to decode
the address of PS/2 keyboards. PS/2 keyboards use a different and also
undocumented scheme at the first parent node than mapping at 'ranges'
properties. It's however not worth implementing that other scheme and
actually also fits atkbdc(4) better to just start at the first parent
node of PS/2 keyboards which is the 8042 controller (I have atkbdc(4)
working that way).
- Use FBSDID.
MFC after: 1 month
which doesn't assume a hardware cursor on __sparc64__ rather than on
DEV_CREATOR. If we want to include more than one framebuffer driver in
e.g. the GENERIC kernel all drivers have to work the same way. Now that
DEV_CREATOR is no longer used remove it from options.sparc64.
and restoring the metadata. In particular, the metadata-restore
functions now all accept a file descriptor and a pathname. If the
file descriptor is set and the platform supports the appropriate
syscall, restore the metadata through the file descriptor. Otherwise,
restore it through the pathname. This is complicated by varying
syscall support (FreeBSD has an fchmod(2) but no fchflags(2), for
example) and because non-file entries don't have an fd to use in
restoring attributes (for example, mknod(2) doesn't return a file
handle).
MFC after: 14 days
address. One was alltraps_with_regs_pushed, the other was calltrap.
When the stack tracer walks up, it looks for magic symbol names to
determine how to parse non-standard stack frames, such as a trapframe.
It was looking for "calltrap". Which of the two symbols you got depended
on things like Phase of moon, etc. If you were unlucky, you got a
garbage stack trace for things like 'debug.trace_on_panic', which would
completely hide the actual source of the problem.
of MCOUNT to have a C version and an asm version with the same name and
not have LOCORE ifdefs to distinguish them. <machine/profile.h> provides
a C version and <machine/asmacros.h> provides an assembler version.
Discussed with: bde
shell meta characters it is not passed to the shell, but the command
is executed directly (given that the line is not a shell builtin) and
that the line with a meta character is passed to the shell.
controllers of Sun PCIO-2 chips which are used onboard in most of
the newer PCI-based sun4u machines (cosmetic change as they were also
already probed as generic FWOHCI without this). As with gem(4), hme(4)
and ohci(4) detect whether their intpin register is valid and correct
it if necessary, i.e. set the respective IVAR to the right value for
allocating the IRQ resource, as some of them come up having it set
to 0 (in fact in all machines I'm currently aware of the FireWire
part being enabled). This fixes attaching affected controllers.
Apporved by: simokawa
Tested by: Michiel Boland <michiel@boland.org>
MFC after: 1 month
in case of IP fast forwarding. Enqueue a taskqueue(9) task instead of
calling xl_rxeof() directly.
Reported & tested by: Slava Alpatov
Reviewed by: wpaul
MFC after: 1 week
pointer. If kernel malloc(0) returns a valid pointer, it needs to be
freed. If it returns NULL, it's ok to free this also.
Submitted by: pjd
Reviewed by: imp, dfr
Obtained from: Coverity Prevent
We can't call KeFlushQueuedDpcs() during bootstrap (cold == 1), since
the flush operation sleeps to wait for completion, and we can't sleep
here (clowns will eat us).
On an i386 SMP system, if we're loaded/probed/attached during bootstrap,
smp_rendezvous() won't run us anywhere except CPU 0 (since the other CPUs
aren't launched until later), which means we won't be able to set up
the GDTs anywhere except CPU 0. To deal with this case, ctxsw_utow()
now checks to see if the TID for the current processor has been properly
initialized and sets up the GTD for the current CPU if not.
Lastly, in if_ndis.c:ndis_shutdown(), do an ndis_stop() to insure we
really halt the NIC and stop interrupts from happening.
Note that loading a driver during bootstrap is, unfortunately, kind of
a hit or miss sort of proposition. In Windows, the expectation is that
by the time a given driver's MiniportInitialize() method is called,
the system is already in 'multiuser' state, i.e. it's up and running
enough to support all the stuff specified in the NDIS API, which includes
the underlying OS-supplied facilities it implicitly depends on, such as
having all CPUs running, having the DPC queues initialized, WorkItem
threads running, etc. But in UNIX, a lot of that stuff won't work during
bootstrap. This causes a problem since we need to call MiniportInitialize()
at least once during ndis_attach() in order to find out what kind of NIC
we have and learn its station address.
What this means is that some cards just plain won't work right if
you try to pre-load the driver along with the kernel: they'll only be
probed/attach correctly if the driver is kldloaded _after_ the system
has reached multiuser. I can't really think of a way around this that
would still preserve the ability to use an NDIS device for diskless
booting.
