Author: emaste
Date: Tue Nov 11 14:59:46 2014
New Revision: 274382
URL: https://svnweb.freebsd.org/changeset/base/274382

Log:
  Add workaround for vt efifb's early use of PHYS_TO_DMAP
  
  In vt_efifb_init the framebuffer's physaddr is passed to PHYS_TO_DMAP
  before the DMAP is setup. The result is not actually accessed until
  after the mapping is setup, though. Loosen the assertion in PHYS_TO_DMAP
  for now, to allow use when dmaplimit == 0.
  
  Reviewed by:  kib
  Sponsored by: The FreeBSD Foundation
  Differential Revision:        https://reviews.freebsd.org/D1142

Modified:
  head/sys/amd64/include/vmparam.h

Modified: head/sys/amd64/include/vmparam.h
==============================================================================
--- head/sys/amd64/include/vmparam.h    Tue Nov 11 14:30:35 2014        
(r274381)
+++ head/sys/amd64/include/vmparam.h    Tue Nov 11 14:59:46 2014        
(r274382)
@@ -175,8 +175,14 @@
 #define        VM_MAX_ADDRESS          UPT_MAX_ADDRESS
 #define        VM_MIN_ADDRESS          (0)
 
+/*
+ * XXX Allowing dmaplimit == 0 is a temporary workaround for vt(4) efifb's
+ * early use of PHYS_TO_DMAP before the mapping is actually setup. This works
+ * because the result is not actually accessed until later, but the early
+ * vt fb startup needs to be reworked.
+ */
 #define        PHYS_TO_DMAP(x) ({                                              
\
-       KASSERT((x) < dmaplimit,                                        \
+       KASSERT(dmaplimit == 0 || (x) < dmaplimit,                      \
            ("physical address %#jx not covered by the DMAP",           \
            (uintmax_t)x));                                             \
        (x) | DMAP_MIN_ADDRESS; })
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to