[ros-kernel] Re: [ros-cvs] CVS Update: reactos - Supportof Matroxdisplay card

[Waldo Alvarez Cañizares]

Hi Filip:
 
I think you misunderstood what I was trying to tell you.
 
What I mean is:
 
Is the value in eax preserved? I think it is showing the value in cr2 instead of the value that should print for eax. With that exception.
 
The page fault was not a problem in ROS was a mistake I did writing some code. While I was trying to find out what I was doing wrong I needed to know the value in eax at the time of the fault but noticed that it was the same as cr2 (was a value that was quite improvable to get in eax for the code I was analyzing) And when I saw your report I noticed values in eax and cr2 are the same too. So maybe this is a little bug in ROS but very annoying.
 
      Processor: 0 CS:EIP 8:ceb8e99e <mga64ddi: 2e99e>   => Matrox Dll
--> cr2 1f0180 cr3 3446000 Proc: c14442f8 Pid: 6 <setup> Thrd: c144d230 Tid: 29
      DS 10 ES 10 FS 30 GS 10
--> EAX: 001f0180   EBX: 00000008   ECX: 00000000
      EDX: 00000000   EBP: 00000000   ESI: cddb6000   ESP: ce9aacf0

I was inspecting the code that prints this text yesterday and saw that cr2 is moved into eax somewhere so provably the value in eax is not saved or is destroyed before it is saved. (Just did a quick look as it was very late)
 
Next time you see this exception, take a look to both values to see if this is true.
 
Best Regards
Waldo Alvarez
 

________________________________

From: ros-kernel-bounces at reactos.com on behalf of Filip Navara
Sent: Mon 3/8/2004 10:23 AM
To: ReactOS Kernel List
Subject: Re: [ros-kernel] Re: [ros-cvs] CVS Update: reactos - Supportof Matroxdisplay card



I'm currently working together with Gerard to fix this problem. The
video miniport driver fails to map the frambuffer and then the display
driver accesses the non-mapped memory. So far I traced it to passing
flag VIDEO_MEMORY_SPACE_DENSE to VideoPortMapMemory, which fails later
in HalTranslateBusAddress. I sent Gerard a test version few minutes ago
and now I'm waiting for test results...

So, Waldo, I guess it's different problem than you have.

- Filip

Waldo Alvarez Cañizares wrote:

>Hi guys:
>
>________________________________
>
>From: ros-kernel-bounces at reactos.com on behalf of Gge
>Sent: Sun 3/7/2004 10:24 AM
>To: ReactOS Kernel List
>Subject: [ros-kernel] Re: [ros-cvs] CVS Update: reactos - Support of Matroxdisplay card
>
>
>
>David Welch wrote:
>
> 
>
>>CVSROOT:       /CVS/ReactOS
>>Module name:   reactos
>>Repository:    reactos/drivers/video/videoprt/
>>Changes by:    dwelch at mok.osexperts.com.(none) 04/03/06 20:43:56
>>
>>Modified files:
>>      reactos/drivers/video/videoprt/: videoprt.c videoprt.h
>>                                       videoprt.def videoprt.edf
>>
>>Log message:
>>      - Added an implemention of VideoPortGetProcAddress
>>      - ati2mtag calls VideoPortGetAccessRanges with *DeviceId == 0 so treat
>>      that as matching an device id.
>>      - Return STATUS_SUCCESS from VideoPortSetTrappedEmulatorPorts even though
>>      the data is ignored.
>>
>>
>>
>>   
>>
>Hi David,
>
>The Matrox Mystique display card needs  "VideoPortVerifyAccessRanges"
>as per Bug # 93.
>Following this commit I tested again the support  of this display card
>but without success. This function is still unimplemented as per Debug
>messages.
>I assume that the ATI board does not need this feature .
>Does anybody use Matrox board ?
>
>--------------------------------------------------------------------
>DriverBase for \SystemRoot\system32\drivers\mga64.sys: cdd2f000  =>
>Matrox driver
>DriverBase for \SystemRoot\system32\drivers\VIDEOPRT.SYS: cddac000
>(videoprt.c:1042) VideoPortVerifyAccessRanges not implemented
>(videoprt.c:1042) VideoPortVerifyAccessRanges not implemented
>DriverBase for \SystemRoot\system32\drivers\msfs.sys: cdddc000
>Mailslot FSD 0.0.1
>DriverBase for \SystemRoot\system32\drivers\npfs.sys: cde00000
>Named Pipe FSD 0.0.2
>DriverBase for \SystemRoot\system32\drivers\kmregtests.sys: cde16000
>DriverBase for \SystemRoot\system32\win32k.sys: ce59a000
>DriverBase for \SystemRoot\system32\freetype.dll: ce6f4000
>DriverBase for \SystemRoot\System32\kbdfr.dll: ce769000
>(NTDLL:ldr/utils.c:2092) Performing relocations (76160000 -> 60d000)
>(NTDLL:ldr/utils.c:2092) Performing relocations (76160000 -> 651000)
>(NTDLL:ldr/utils.c:2050) Failed to create or open dll section of
>'msacm.drv' (Status c0000135)
>(NTDLL:ldr/utils.c:2050) Failed to create or open dll section of
>'midimap.drv' (Status c0000135)
>DriverBase for \SystemRoot\System32\mga64ddi.DLL: ceb60000
>Bug detected (code 1e param 0 0 0 0)
>  KMODE_EXCEPTION_NOT_HANDLED
>Page Fault Exception: 14(0)
>Processor: 0 CS:EIP 8:ceb8e99e <mga64ddi: 2e99e>   => Matrox Dll
>cr2 1f0180 cr3 3446000 Proc: c14442f8 Pid: 6 <setup> Thrd: c144d230 Tid: 29
>DS 10 ES 10 FS 30 GS 10
>EAX: 001f0180   EBX: 00000008   ECX: 00000000
>EDX: 00000000   EBP: 00000000   ESI: cddb6000   ESP: ce9aacf0
>EDI: c1574000   EFLAGS: 00010246 kESP ce9aacf0 kernel stack base ce9a8000
>Frames:
>------------------------------------------------------------------------
>Regards
>Gerard
>
>Now that you put this
>
>Are the values of cr2 = 1f0180 and eax = 1f0180 a coincidence?
>
>I once was getting the same exception this weekend
>
>Page Fault Exception: 14(0)
>
>And was not able to see the value of eax (wich contained an address and was showing the same value as cr2 and was not a coincidence for sure)
>
>Regards
>Waldo Alvarez
> 
>

_______________________________________________
Ros-kernel mailing list
Ros-kernel at reactos.com
http://reactos.com/mailman/listinfo/ros-kernel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 10034 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20040308/069223b3/attachment-0001.bin