Created attachment 18342 [details]
xorg conf file

stressbases3 should be stress_bases3,and you run it by below steps:
1.run openarena
2.select demos on the menu
3.goes into demos you will find stress_bases3,then run it.

this issue also exists on GM45.

Now it still exists with current unstable build.

This issue also exists when running 3D games like torcs,doom3-demo,ut2004,et,celestia.

Increasing priority since it impacts many 3d games.
And note it can be reproduced with non-gem kernel.

reassigning to Haihao.
the driver contains GEM, but the kernel doesn't. So it's in classic mode.

Created attachment 18970 [details] [review]
patch to fix the assertion  issue

This assertion issue is introduced by a gem commit d2796939f18815935c8fe1effb01fa9765d6c7d8.  There are two problems:
 1. brw->curbe.curbe_bo is set to NULL in intel_batchbuffer_flush if check_aperture fails.
 2. input->bo is also set to NULL after uploading, so that brw_emit_vertices will   derefence a NULL pointer when re-emiting all states.

Hi, Eric
   Could you review this patch? Note this patch only resolves the assertion issue.
X still get hung when running celestia etc. If I reverted the the move of the bufmgr to libdrm, the hang issue would disappear. 

Thanks.
haihao

Hi, Eric
   It seems the hang issue is caused by the following code in intel_bufmgr_fake.c

   /* The kernel implementation of IRQ_WAIT is broken for wraparound, and has                                                
    * been since it was first introduced.  It only checks for                                                                
    * completed_seq >= seq, and thus never returns for pre-wrapped irq values                                                
    * if the GPU wins the race.                                                                                              
    *                                                                                                                        
    * So, check if it looks like a pre-wrapped value and just return success.                                                
    */                                                                                                                       
   if (*bufmgr_fake->last_dispatch - cookie > 0x4000000)                                                                     
      return;                                                                                                                
 
I don't understand why you add this check.  F                                                                                                            or example: *bufmgr_fake->last_dispatch is 1000, and cookie is 1005, note *bufmgr_fake->last_dispatch and cookie all are unsigned int.  So *bufmgr->last_dispatch will never get updated.  

Thanks
haihao

(In reply to comment #10)
> Hi, Eric
>    It seems the hang issue is caused by the following code in
> intel_bufmgr_fake.c
> 
>    /* The kernel implementation of IRQ_WAIT is broken for wraparound, and has   
>     * been since it was first introduced.  It only checks for                   
>     * completed_seq >= seq, and thus never returns for pre-wrapped irq values   
>     * if the GPU wins the race.                                                 
>     *                                                                           
>     * So, check if it looks like a pre-wrapped value and just return success.   
>     */                                                                          
>    if (*bufmgr_fake->last_dispatch - cookie > 0x4000000)                        
>       return;                                                                   
> 
> I don't understand why you add this check.  F                                  
>                                                                          or
> example: *bufmgr_fake->last_dispatch is 1000, and cookie is 1005, note
> *bufmgr_fake->last_dispatch and cookie all are unsigned int.  So
> *bufmgr->last_dispatch will never get updated.  
> 
> Thanks
> haihao
> 
This issue gone by commenting out "
 if (*bufmgr_fake->last_dispatch - cookie > 0x4000000)                        
     return;   ", and so does bug 17623.

Thanks for catching the comparison bug, and I've got a fix I'm testing for that, but this bug is different.  OpenArena is triggering the aperture space overflow case in the middle of batchbuffer state emit, which can't be allowed to happen (as you'd start a new batchbuffer without some of the relocations you're depending on for your state).

commit d533da2db873942b3f8676a754b8be3c9718bedf
Author: Eric Anholt <eric@anholt.net>
Date:   Tue Sep 23 15:53:29 2008 -0700

    i965: Cope with batch getting flushed in the middle of batchbuffer emits.
    
    This isn't required for GEM (at least, yet), but the check_aperture code
    for non-GEM results in batch getting flushed during emit.  brw_state_upload
    restarts state emits, but a bunch of the state emit functions were assuming
    that they would be called exactly once, after prepare and before new_batch.
    
    Bug #17179.

verified.