[haiku-bugs] Re: [Haiku] #5383: MTRR regression: AGP transfer inconsistencies
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Tue, 23 Feb 2010 21:18:50 -0000
#5383: MTRR regression: AGP transfer inconsistencies
------------------------+---------------------------------------------------
Reporter: rudolfc | Owner: bonefish
Type: bug | Status: closed
Priority: normal | Milestone: R1
Component: - General | Version: R1/Development
Resolution: fixed | Keywords:
Blockedby: | Platform: All
Blocking: |
------------------------+---------------------------------------------------
Changes (by bonefish):
* status: in-progress => closed
* resolution: => fixed
Comment:
Replying to [comment:10 rudolfc]:
> On r35580 it's working again, acceleration is operating correctly in AGP
mode. I'll attach a syslog below.
Thanks, looks beautiful. :-)
> BTW: On previous versions the nvidia kernel driver should have aborted
loading because it checks for success of mapping the command buffer (if
(si->dma_area < 0) fail).
>
> Is the kernel correctly reporting failed mappings, where it should fail
if it's not able to set the requested cache type?
It should have worked as expected. The "Memory range intersects with
existing one" output from add_memory_type_range() we see in the syslog was
immediately followed by a "return B_BAD_VALUE" in that function. The
return value was passed right through by arch_vm_set_memory_type(). The
calling vm_map_physical_memory() checked the return value, deleted the
already created area and would pass the error code back. So, yes indeed,
[vm_]map_physical_memory() would fail, when the memory type could not be
set.
With the exception that MTRR algorithm has changed and
vm_map_physical_memory() now always sets a memory type ("uncached", if
none has been specified), errors are still propagated the same way.
--
Ticket URL: <http://dev.haiku-os.org/ticket/5383#comment:11>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
