src-test2/sys/dev/dcons, branch release/10.0.0FreeBSD source treehttps://cgit-dev.freebsd.org/src-test2/atom?h=release%2F10.0.02013-02-19T18:22:25ZMFcalloutng:2013-02-19T18:22:25ZAlexander Motinmav@FreeBSD.org2013-02-19T18:22:25Zurn:sha1:fd7e68271969f2a6a2b4a10cbc451c090ac276a3
Make dcons input polling adaptive, reducing poll rate to 1Hz after several
minutes of inactivty to reduce global interrupt rate. Most of users never
used FireWire debugging, so it is not very useful to consume power by it.
kern cons: introduce infrastructure for console grabbing by kernel2011-12-17T15:08:43ZAndriy Gaponavg@FreeBSD.org2011-12-17T15:08:43Zurn:sha1:9976156f12f1be7cb85c90e9ef54be06690bc955
At the moment grab and ungrab methods of all console drivers are no-ops.
Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).
Inspired by: bde
MFC after: 2 months
Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.2011-11-07T15:43:11ZEd Schoutened@FreeBSD.org2011-11-07T15:43:11Zurn:sha1:6472ac3d8a86336899b6cfb789a4cd9897e3fab5
The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.
Follow up to r225203 refining break-to-debugger run-time configuration2011-08-27T14:24:27ZRobert Watsonrwatson@FreeBSD.org2011-08-27T14:24:27Zurn:sha1:e5a0927394502ac7d7d0383c523490eb35f773dc
improvements:
(1) Implement new model in previously missed at91 UART driver
(2) Move BREAK_TO_DEBUGGER and ALT_BREAK_TO_DEBUGGER from opt_comconsole.h
to opt_kdb.h (spotted by np)
(3) Garbage collect now-unused opt_comconsole.h
MFC after: 3 weeks
Approved by: re (bz)
Attempt to make break-to-debugger and alternative break-to-debugger more2011-08-26T21:46:36ZRobert Watsonrwatson@FreeBSD.org2011-08-26T21:46:36Zurn:sha1:4cf75455890c103c9a66cb791e88998aafd4f8ce
accessible:
(1) Always compile in support for breaking into the debugger if options
KDB is present in the kernel.
(2) Disable both by default, but allow them to be enabled via tunables
and sysctls debug.kdb.break_to_debugger and
debug.kdb.alt_break_to_debugger.
(3) options BREAK_TO_DEBUGGER and options ALT_BREAK_TO_DEBUGGER continue
to behave as before -- only now instead of compiling in
break-to-debugger support, they change the default values of the
above sysctls to enable those features by default. Current kernel
configurations should, therefore, continue to behave as expected.
(4) Migrate alternative break-to-debugger state machine logic out of
individual device drivers into centralised KDB code. This has a
number of upsides, but also one downside: it's now tricky to release
sio spin locks when entering the debugger, so we don't. However,
similar logic does not exist in other device drivers, including uart.
(5) dcons requires some special handling; unlike other console types, it
allows overriding KDB's own debugger selection, so we need a new
interface to KDB to allow that to work.
GENERIC kernels in -CURRENT will now support break-to-debugger as long as
appropriate boot/run-time options are set, which should improve the
debuggability of BETA kernels significantly.
MFC after: 3 weeks
Reviewed by: kib, nwhitehorn
Approved by: re (bz)
Last minute TTY API change: remove mutex argument from tty_alloc().2009-05-29T06:41:23ZEd Schoutened@FreeBSD.org2009-05-29T06:41:23Zurn:sha1:c5e30cc02b9bee4c53457d1bc4184b256ce1a569
I don't want people to override the mutex when allocating a TTY. It has
to be there, to keep drivers like syscons happy. So I'm creating a
tty_alloc_mutex() which can be used in those cases. tty_alloc_mutex()
should eventually be removed.
The advantage of this approach, is that we can just remove a function,
without breaking the regular API in the future.
Reduce the dcons polling frequency to 25 Hz.2009-04-06T13:09:02ZEd Schoutened@FreeBSD.org2009-04-06T13:09:02Zurn:sha1:2dae467d6197ef1efef4f348aa042475aa78dbcf
It makes little sense to use 100 Hz polling in dcons. We cannot live
without polling, because that's just how dcons works. It polls the
buffer filled by the firewire hardware. 25 Hz is probably enough for
most use cases.
Discussed with: rwatson
Tested by: kan
Fix logic in MOD_LOAD handler to call dcons_attach after all successful2009-04-06T02:29:28ZAlexander Kabaevkan@FreeBSD.org2009-04-06T02:29:28Zurn:sha1:9ec7a1f5680f71f422045e62e97cba9cc83654c9
dcons_drv_init invocations. Testing return value for 0 does not work for
cases where dcons_drv_init was called already as part of low level
console initialization.
We need to initialize the console for dcons to work.2009-03-13T02:15:49ZWarner Loshimp@FreeBSD.org2009-03-13T02:15:49Zurn:sha1:3fdd7f1605a2e51f0ed069e26e4cade315d61ed5
Submitted by: nork@
Check the return values of contigmalloc(9) as well as bus_dma(9)2009-01-07T21:25:44ZMarius Stroblmarius@FreeBSD.org2009-01-07T21:25:44Zurn:sha1:3da80d3a0e4fffb41478141e752c945daf69aeaf
functions and stop attaching of dcons(4) and dcons_crom(4) if
they indicate failure. This fixes a panic seen on sparc64 machines
with no free physical memory in the requested 32-bit region but
still doesn't make dcons(4)/dcons_crom(4) these work. I think
the latter can be fixed by simply specifying ~0UL as the upper
limit for contigmalloc(9) and letting the bounce pages and the
IOMMU respectively handle limitations of the DMA engine. I didn't
want to change that without the consensus of simokawa@ though,
who unfortunately didn't reply so far.
MFC after: 1 week