I also have this problem. Everything unaccelerated comes up as trash,
even on the kernel framebuffer (if acceleration was switched off). Or
for example I can see most of the graphics ok, but if I use ShadowFB
then the whole screen is unusable. And the cursor is garbage too most of
the time.
This
nouveau.agpmode=0 seems to work here too, also after comming back from
suspend.
Still I think I'm stuck with the modesetting driver with the bit 24 hack
in boot/suspend scripts. The scrolling and rxvt performance is just
better.
--
You received this bug notification because you are a member of
Yes, it was taken after several attempts, that's why it was already set.
I've made a better dump and sent it in e-mail now. According to this
it's set the first time it's written to.
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to
I've wasted a lot of time with the mmio registers to find out why things
go slow. But it seems it's something else.
Just loading the nvidia kernel module without starting X is enough to
make nouveau go fast after kexec.
I did an mmio trace while loading the module, but it only wrote 140 to
0,
For the first two options I think it could be useful to grep through all
those dumps collected over the years and check which cards have this
set.
Option 3 could definately tell if it's only used for a particular memory
configuration of this chip, or it's more general (e.g. first 2 options).
By
I've e-mailed the dump file.
I've put in 3 markers, one before starting xinit /usr/bin/urxvt, one in
urxvt before quiting, and one after xinit returned.
I hope it's useful. Thanks! I can try to repeat the same thing using the
nouveau driver, if needed.
--
You received this bug notification
I had the feeling that there's not much chance that the dump alone will
help. So I did some debugging on my own, after all it can't be that hard
if I have the hardware at hand to play with ;)
First I've collected all writes locations out from the dump, and ignored
the part which looked like a
Doing a suspend to RAM restores the original trashing behaviour. I'm not
sure, but maybe the screen update is slower as well now.
This is a Dell D800:
01:00.0 VGA compatible controller: NVIDIA Corporation NV28M [GeForce4 Ti 4200
Go AGP 8x] (rev a1)
X.Org X Server 1.15.1
Release Date: 2014-04-13
The default Debian kernel is not very debug friendly, so I've dumped the ROMs
with nvagetbios. There are two versions, as I made a firmware update later to
see if it helps. (e-mailed)
The MMIO dumps are comming soon, tomorrow or so. This is a slow machine
and the kernel compile takes a while
9 matches
Mail list logo
