linux-kernel - Re: X "Hangs" with RS690 + 2.6.26

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 Jul 2008 11:44:58 +0200
From:	Jerome Glisse <glisse@...edesktop.org>
To:	Nicolai Hähnle <prefect@....de>
Cc:	dri-devel@...ts.sourceforge.net,
	Jonathan McDowell <noodles@...th.li>,
	linux-kernel@...r.kernel.org
Subject: Re: X "Hangs" with RS690 + 2.6.26

On Fri, 25 Jul 2008 19:04:55 +0200
Nicolai Hähnle <prefect@....de> wrote:

> Am Freitag 25 Juli 2008 12:12:59 schrieb Jerome Glisse:
> > This looks like usual engine lockup followed by CP lockup so
> > that DMA buffer age never get written and we run out of DMA
> > buffer thus freelist failing in infinite loop.
> >
> > I think we now know all the reason why we lockup, while a
> > fix could be made for old ioctl we believe the best plan is
> > to work on new ioctl with this fix in mind.
> 
> I can't help but feel uneasy with that kind of plan. After all, do "we" 
> *really* know what's going on? I always had the impression that we only knew 
> things along the lines of "perhaps it's better to submit 3D stuff in indirect 
> buffers".
> 
> If you *really* know what causes the lockups, could you please document that? 
> As in, what's the actual command processor sequence that is to blame? I know  
> that running e.g. a Nexuiz demo + glxgears window above it is apparently a 
> 100% guaranteed lockup on my system (R420).
> 
> If you could share your progress in tracking down the sources of the lockups, 
> I'd happily try to write a patch against the current system.
> 
> cu,
> Nicolai
> 

Here is a brief list from top of my head for the record : 

- no RB3D_DSTCACHE twice in a row without rendering cmd in btw
- initialize all clip register to default values wait for engine idle
  after setting them
- update wptr every 32 dwords (2 dwords seems enough but that one
  is very hard to track)
- use indirect buffer
- RB3D_DSTCACHE is not pipelined if free or sync bit is not set
  thus you have to feel the fifo and wait for idle before writing
  it if none of these bits are set
- flush & wait until 3d before 2d, and flush & wait dma & 2d idle
  after 2d as well feel the fifo with dummy 2d reg to avoid unpipelined
  3d reg to get executed before idle is asserted
- avoid emitting cliprect too much
- txinval before changing texture
- avoid stuff RB3D_DSTCACHE & RB2D_DSTCACHE too much
- set ISYNC properly through CP
- CP idle is wrong we should wait for tag and not
  try to force CP to goes idle or inject flush after
  idle
- set vertex shader constant & input to default safe value

And there is other things to think about scattered in my drm.
Baiscly things should be set in some order to make sure the
engine will not be unhappy in face of a cmd stream. Some of the
above might be wrong but i use them because somehow they each
one of them seems to give me more stable drm. The last drm
i have doesn't lockup in the case of few glxgears on top
of other 3d app like celestia and likely nexuiz haven't tried
that one.

Cheers,
Jerome Glisse <glisse@...edesktop.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/