FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F9.0.0 2009-01-07T21:25:44Z 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 2007-06-08T04:33:25Z Hidetoshi Shimokawa simokawa@FreeBSD.org 2007-06-08T04:33:25Z urn:sha1:293b847542ebfac574cd9a9d888df9769d45e77f A change to dconschat(8) will follow so that it can bomb this address over FireWire to reset a wedged system. Though this method is just a hack and far from perfection, it should be useful if you don't want to go machine room just to reset or to power-cycle a machine without remote-managed power supply. And much better than doing: # fwcontrol -m target-eui64 # dd if=/dev/zero of=/dev/fwmem0.2 bs=1m 2007-06-08T00:54:44Z Hidetoshi Shimokawa simokawa@FreeBSD.org 2007-06-08T00:54:44Z urn:sha1:9953c34ca6e41c2022f0bbc73001aee0f8ac981d Now, it's safe to call the fwohci interrupt(polling) routine while ddb/gdb is active. After this change, a dcons connnection over FireWire can survive bus resets even in kernel debugger. This means that it is not too late to plug a FireWire cable after a panic to investigate the problem. Actually there is a small window(between a jump to kernel from loader and initialization of dcons_crom) in which no one can take care of a bus reset. Except that window, firewire console should keep working from loader to reboot even with a panic and a bus reset. (as far as you enable LOADER_FIREWIRE_SUPPORT) 2007-05-27T14:00:34Z Hidetoshi Shimokawa simokawa@FreeBSD.org 2007-05-27T14:00:34Z urn:sha1:db7275797330ddc1b8c9866c11fb218bc388b422 for least astonishment. MFC after: 3 days 2005-01-06T01:43:34Z Warner Losh imp@FreeBSD.org 2005-01-06T01:43:34Z urn:sha1:098ca2bda93c701c5331d4e6aace072495b4caaa 2004-10-13T05:38:42Z Hidetoshi Shimokawa simokawa@FreeBSD.org 2004-10-13T05:38:42Z urn:sha1:31a58777865b45a056dd435ea8ecf426bed54985 - Implement dcons_ischar() and dcons_load_buffer(). - If loader passed a dcons buffer address, keep using it. (We still need a patch to cheat memory management system.) 2004-05-30T20:08:47Z Poul-Henning Kamp phk@FreeBSD.org 2004-05-30T20:08:47Z urn:sha1:fe12f24bb098d8d2a6c35394a53a65b3e64f83d9 2004-02-16T07:25:46Z Hidetoshi Shimokawa simokawa@FreeBSD.org 2004-02-16T07:25:46Z urn:sha1:19b3bba3e5e734773a56c7a0962510dfe16a64d5 - Force dcons to be the high-level console after dcons_crom has been attached. - Add a tunable to be the high-level console. 2003-11-08T16:26:22Z Hidetoshi Shimokawa simokawa@FreeBSD.org 2003-11-08T16:26:22Z urn:sha1:ddce43e1cf10a06aefc01c1d56ce7e2269c1c8f2