Hi,
After many tests and reboot i have a set of register that
may influence 9800 lockups. Unfortunetly i don't know
how to play with this register as they doesn't seems to be
used anywhere (nor X driver, dri, drm if i trust my grep :))
RADEON_LATENCY the most likely to help to resolve the
lockup.
On Sun, 12 Jun 2005, Jerome Glisse wrote:
Hi,
After many tests and reboot i have a set of register that
may influence 9800 lockups. Unfortunetly i don't know
how to play with this register as they doesn't seems to be
used anywhere (nor X driver, dri, drm if i trust my grep :))
RADEON_LATENCY
On 6/12/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 12 Jun 2005, Jerome Glisse wrote:
>
> > Hi,
> >
> > After many tests and reboot i have a set of register that
> > may influence 9800 lockups. Unfortunetly i don't know
> > how to play with this register as they doesn't seems
Thx for the info but seems that the most important (at least to me :))
RADEON_LATENCY have no specs ?
I really think, nearly convinced that this the key register to solve the
lockup. I dump the reg after a cold boot with xorg & r300, then
i quit xorg & r300 and launch x with fglrx don't launch any
Btw Daniels suggest me that this could be a mirror of
the latency reg register(0xd) of PCI. If it is should i expect
it to change overtime or should it keeps its value ?
Jerome Glisse
---
This SF.Net email is sponsored by: NEC IT Guy Games. Ho
It's not only RADEON_LATENCY if i set PCI latency to 0xff
i still got the lockup i am pretty disappointed as it seemed
to be the winning register. Anyway here is a longer list of
reg that may play role (i will try to find a place on the web
to put the dump thus anyone interested could look at them
Jerome Glisse wrote:
Does the following differences means that the
fglrx driver load another microcode ?
Last I checked, Yes.
Rune Petersen
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How
On 6/12/05, Rune Petersen <[EMAIL PROTECTED]> wrote:
> Jerome Glisse wrote:
> > Does the following differences means that the
> > fglrx driver load another microcode ?
> Last I checked, Yes.
But when reloading r300 (radeon module) the fglrx
microcode is overwritten no ?
Jerome Glisse
--
Jerome Glisse wrote:
On 6/12/05, Rune Petersen <[EMAIL PROTECTED]> wrote:
Jerome Glisse wrote:
Does the following differences means that the
fglrx driver load another microcode ?
Last I checked, Yes.
But when reloading r300 (radeon module) the fglrx
microcode is overwritten no ?
yes.
R
> Does the following differences means that the
> fglrx driver load another microcode ?
I've written a hw_script that reads back the microcode from fglrx,
I've already replaced my microcode to see if my issues were with it (they
weren't..)
I've added a hw_scripts directory to r300_driver with 3
On Sun, 12 Jun 2005, Rune Petersen wrote:
Jerome Glisse wrote:
On 6/12/05, Rune Petersen <[EMAIL PROTECTED]> wrote:
Jerome Glisse wrote:
Does the following differences means that the
fglrx driver load another microcode ?
Last I checked, Yes.
But when reloading r300 (radeon module) th
11 matches
Mail list logo
