-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has
been closed from further activity.
You can subscribe and participate further through the new bug through
this link to our GitLab instance:
(In reply to comment #63)
> 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.
Yeah, I'll try to have a look later on.
>
> Option 3 could definately tell if it's only used for a particular memory
>
Even more interesting, your trace actually has
[0] 1012.956817 MMIO32 R 0x100080 0xe100 PFB+0x80 => 0xe100
[0] 1012.956820 MMIO32 W 0x100080 0xe100 PFB+0x80 <= 0xe100
Which means that it _starts out_ at 0xe100. Was this trace done on a
clean boot, or had the nvidia module
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
(In reply to comment #55)
> So something is initialized by the nvidia driver, which is not touched by
> nouveau but is required for correct operation.
>
> Is there a way I could help? Like dumping register states with/without the
> nvidia init?
You could do a mmiotrace of the nvidia driver. It's
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,
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
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
BTW, interesting. In your VBIOS, it tells us to do
0xcbf2: 7a 80 00 10 00 00 00 00 e0 ZM_REG
R[0x100080] = 0xe000
Which is why that bit gets lost on resume (but not on kexec, since init
scripts don't run, since the adapter is already init'd). Good to know,
that means that
(In reply to comment #61)
> At the end I got what I wanted. The winner is:
> nvapoke 00100080 e100
>
> This register is e000 after suspend or after clean boot. So all this
> trouble only because of a single bit was not set ;(
Fantastic! I was secretly hoping that by ignoring the issue
I ignore if it's related, but my Dell D800 with nv28 burts many-many-many beeps
on boot until the grub menu displays. Feel free to ask any thing.
Regards
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-nouveau in
(In reply to Emil Velikov from comment #77)
> agpmode and modeset are not even remotely related I'm afraid. With 4.3
> onward one should be using nouveau.config="NvAGP=0" as documented [1]
>
> [1] http://nouveau.freedesktop.org/wiki/KernelModuleParameters/#config
Yes. The syntax given seems to
On Lubuntu 14.04.3 (I think it's Kernel 3.19.x) "nouveau.agpmode=0" also works,
although standby still doesn't seem to work.
What I want to note though, is, that activating the Shadow Framebuffer in
/etc/X11/xorg.conf.d/20-nouveau.conf results in a substantial performance
increase regarding
agpmode and modeset are not even remotely related I'm afraid. With 4.3
onward one should be using nouveau.config="NvAGP=0" as documented [1]
[1] http://nouveau.freedesktop.org/wiki/KernelModuleParameters/#config
--
You received this bug notification because you are a member of Desktop
Packages,
I reached to retreive my video bios version*:
cat /proc/driver/nvidia/cards/0
Model: GeForce4 4200 Go
IRQ: 11
Video BIOS: 04.28.20.31.c1
Card Type: AGP
DMA Size: 32 bits
DMA Mask: 0x
Maybe you will like to check against your own and tell me you need
something else from me.
* not that
(In reply to Ilia Mirkin from comment #64)
> (In reply to comment #63)
> >
> > 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).
>
> I've fired off a question to NVIDIA, hopefully they'll
(In reply to Ilia Mirkin from comment #75)
> (In reply to AndrewK from comment #73)
> > (In reply to nv28m from comment #71)
> > > nouveau.agpmode=0 seems to work here too, also after comming back from
> > > suspend.
> > >
> > The parameter name seems to be changed. nouveau.modeset=0 is what
(In reply to nv28m from comment #71)
> 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.
The parameter name
(In reply to AndrewK from comment #73)
> (In reply to nv28m from comment #71)
> > 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
Guys, if I can help in any maneer I'd be glad. I want you to know my
video adapter is flashed with a bios update I found long time ago on
dell's site (in my memory, this was a bios update for Windows).
--
You received this bug notification because you are a member of Desktop
Packages, which is
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
Hi, I do not know if it may be still relevant after nv28m dicoveries but
here's some quick info (with a debian testing fully updated a month
ago).
Booting with plain nouveau (agp v2 4x): distorted mouse, nothing new
here :(
I tried to boot the following kernel command lines:
*
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 Desktop
Packages, which is subscribed to
I just discovered this bug as I acquired a Dell Inspiron 8500 a few
weeks back and ran into the same problem. In fact, on my machine (same
nVidia graphics), the problem even seems worse: Any attempt at using the
nouveau driver so far has not only produced the distortions described by
the original
I ended in Ubuntu 12.04 with latest nvidia-96(-updates maybe). The
Laptop sleeps now for weeks and I won't wake it up. I Just can say that
once I admitted that vino won't work with desktop effects, I decided to
use this laptop with gnome-shell no-effects only, and with the latest
drivers state
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
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
** Changed in: nouveau
Status: Confirmed => Unknown
** Bug watch added:
gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues #29
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/29
--
You received this bug notification because you are a member of Desktop
I was not able to boot the referenced ISO as it appears even the i386
kernel requires PAE (seems like a bug?).
I will try to upgrade existing installed OS, but it will take a fair
amount of time.
-john
--
You received this bug notification because you are a member of Desktop
Packages, which is
John Navitsky, this bug was reported a while ago and there hasn't been
any activity in it recently. We were wondering if this is still an
issue? If so, could you please test for this with the latest development
release of Ubuntu? ISO images are available from
https://bugs.freedesktop.org/show_bug.cgi?id=54700
** Bug watch added: freedesktop.org Bugzilla #54700
https://bugs.freedesktop.org/show_bug.cgi?id=54700
** Bug watch added: freedesktop.org Bugzilla #54700
https://bugs.freedesktop.org/show_bug.cgi?id=54700
** Changed in: nouveau
** Changed in: nouveau
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-nouveau in Ubuntu.
https://bugs.launchpad.net/bugs/653714
Title:
Garbage on X display w/ Dell D800 wuxga
33 matches
Mail list logo
