Jerome Glisse wrote:
> On Mon, 2009-04-20 at 12:13 +0200, Thomas Hellstrom wrote:
>   
>> Jerome Glisse wrote:
>>     
>>> On Sun, 2009-04-19 at 18:21 +0200, Thomas Hellström wrote:
>>>   
>>>       
>>>> Jerome Glisse wrote:
>>>>     
>>>>         
>>>>> On Sat, 2009-04-18 at 21:06 +0200, Thomas Hellström wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Jerome Glisse wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> Hi Thomas
>>>>>>>
>>>>>>> I am getting massive error on x86_64, things like :
>>>>>>> BUG: Bad page map in process gnome-session  pte:1f1d1d1d01000000
>>>>>>> pmd:321a6067
>>>>>>> keep filling the log until very bad things happen.
>>>>>>> Do you have any idea what might cause that in ttm ?
>>>>>>> My assumption is that ttm vm code is guilty their.
>>>>>>> Note that on x86 exact same code seem to run fine.
>>>>>>> All this with 2.6.29 final.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jerome Glisse
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> Hi, Jerome!
>>>>>>
>>>>>> The TTM code may well be guilty here. I haven't tested x86-64 for a 
>>>>>> while, but I can probably give it a try on openChrome next week.
>>>>>>
>>>>>> /Thomas
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Okay so i really narrowed it down to asking for WC memory, so my guess
>>>>> is that either my CPU (AMD Athlon(tm) Dual Core Processor 4450e) have
>>>>> PAT issue either TTM PAT/WC code is wrong somehow. I haven't time yet
>>>>> to go deeper with this but i think it worked on an Intel Core2 CPU
>>>>> with x86-64. Also it seems other people doesn't have the issue with
>>>>> WC on x86-64.
>>>>>
>>>>> PS: Sorry for all the noise, the bug didn't always showed up quickly so
>>>>> i had false feeling. I am yet unsure it's fully fixed but so far all my
>>>>> test case which triggered it seems to work fine.
>>>>>
>>>>> Cheers,
>>>>> Jerome
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> Jerome,
>>>> I think I missed what the fix was?
>>>>
>>>> Anyway, for PAT-aware kernels the drm git TTM code is always assuming 
>>>> PAT is enabled and working.
>>>> For production kernels, the function
>>>>  
>>>> pgprot_ttm_x86_wc
>>>>
>>>> should be replaced by an exported version of x86 pgprot_writecombine.
>>>>
>>>> FWIW x86-64 seems to work fine here on a 2.6.27 kernel Athlon-64 
>>>> single-core on openChrome.
>>>>
>>>> /Thomas
>>>>     
>>>>         
>>> Fix is to not ask for WC memory, i will look at this after i cleanup
>>> all my hack to track down this.
>>>
>>> Cheers,
>>> Jerome
>>>
>>>   
>>>       
>> OK.
>>
>> If there was an erratum causing PAT not to be enabled on your processor, 
>> then definitely that
>> may have cause strange inconsistencies.
>>
>> Thanks,
>> Thomas.
>>     
>
> I think ttm_tt caching stuff does follow kernel policies outlined
> in Documentation/x86/pat.txt well at least from understanding of
> code i have right now through (call chains being sometimes hard
> to fully follow). As also have another issue it seems that calling
> set_memory_(uc|wc) while suspending lockup the cpu or at least doesn't
> return, is this somethings i should expect ?
>
>   
I'm not 100% sure about whether it's save to call set_memory_xx while 
suspending.
Certainly the Moorestown and openChrome drivers swap out all buffers 
before suspending, which will involve calls to set_memory_wb(), and that 
seems to work, but I'm not 100% sure it's legal.

/Thomas



> Cheers,
> Jerome
>
>   




------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to