FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F9.0.0 2011-08-27T14:24:27Z 2011-08-27T14:24:27Z Robert Watson rwatson@FreeBSD.org 2011-08-27T14:24:27Z urn: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) 2011-08-26T21:46:36Z Robert Watson rwatson@FreeBSD.org 2011-08-26T21:46:36Z urn: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) 2009-05-29T06:41:23Z Ed Schouten ed@FreeBSD.org 2009-05-29T06:41:23Z urn: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. 2009-04-06T13:09:02Z Ed Schouten ed@FreeBSD.org 2009-04-06T13:09:02Z urn: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 2009-04-06T02:29:28Z Alexander Kabaev kan@FreeBSD.org 2009-04-06T02:29:28Z urn: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. 2009-03-13T02:15:49Z Warner Losh imp@FreeBSD.org 2009-03-13T02:15:49Z urn:sha1:3fdd7f1605a2e51f0ed069e26e4cade315d61ed5 Submitted by: nork@ 2009-01-07T21:25:44Z Marius Strobl marius@FreeBSD.org 2009-01-07T21:25:44Z urn: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 2008-11-19T22:09:03Z Marius Strobl marius@FreeBSD.org 2008-11-19T22:09:03Z urn:sha1:eddfa7b1474598bf9c9327713a849c4773afd868 and output, set BUS_DMA_COHERENT when creating the DMA map used for loading the buffer. As a side-effect this solves locking issues on sparc64 when dcons(4) calls bus_dmamap_sync(9) while in an interrupt filter, which are executed in a critical section, and iommu(4) has to use a sleep lock when taking advantage of the streaming buffer. Reported and tested by: kensmith Approved by: simokawa 2008-11-19T21:12:26Z Ed Schouten ed@FreeBSD.org 2008-11-19T21:12:26Z urn:sha1:656b038372878935c0b630b41625a2adb5345f1b The callout locks the TTY layer the way it should, so there is no reason why its callout shouldn't set this flag. 2008-08-20T08:31:58Z Ed Schouten ed@FreeBSD.org 2008-08-20T08:31:58Z urn:sha1:bc093719ca478fe10b938cef32c30b528042cbcd The last half year I've been working on a replacement TTY layer for the FreeBSD kernel. The new TTY layer was designed to improve the following: - Improved driver model: The old TTY layer has a driver model that is not abstract enough to make it friendly to use. A good example is the output path, where the device drivers directly access the output buffers. This means that an in-kernel PPP implementation must always convert network buffers into TTY buffers. If a PPP implementation would be built on top of the new TTY layer (still needs a hooks layer, though), it would allow the PPP implementation to directly hand the data to the TTY driver. - Improved hotplugging: With the old TTY layer, it isn't entirely safe to destroy TTY's from the system. This implementation has a two-step destructing design, where the driver first abandons the TTY. After all threads have left the TTY, the TTY layer calls a routine in the driver, which can be used to free resources (unit numbers, etc). The pts(4) driver also implements this feature, which means posix_openpt() will now return PTY's that are created on the fly. - Improved performance: One of the major improvements is the per-TTY mutex, which is expected to improve scalability when compared to the old Giant locking. Another change is the unbuffered copying to userspace, which is both used on TTY device nodes and PTY masters. Upgrading should be quite straightforward. Unlike previous versions, existing kernel configuration files do not need to be changed, except when they reference device drivers that are listed in UPDATING. Obtained from: //depot/projects/mpsafetty/... Approved by: philip (ex-mentor) Discussed: on the lists, at BSDCan, at the DevSummit Sponsored by: Snow B.V., the Netherlands dcons(4) fixed by: kan