Bug 58776

Created attachment 72130 [details]
kernel config

Created attachment 72131 [details]
dmesg output (part 01)

NOTE: dmesg broken in 2 files to be able to upload

Created attachment 72132 [details]
dmesg output (part 02)

NOTE: dmesg output broken in 2 parts to be able to upload

I have done some more experiments.

Following discussions in bug#46557 and bug#54988, I have tried both
https://bugs.freedesktop.org/attachment.cgi?id=63137 and the mem=2G
kernel opt.

The former does not have any effect, while the latter works (with
mem=2G I can boot fine and also X11 runs nicely)

I would not be in favor of a buggy hardware, since the GPU works without any
problem with kernel 3.6.x (i.e., no need to append any mem=2G
option).

I would rather think about changes between 3.6/3.7, but, as I
told above, my knowledge about the whole matter is less than poor...
	
thank you very much in advance for any help

ciao
gabriele

For the records:

just for the fun of it, I have also tried this one:

   https://bugs.freedesktop.org/attachment.cgi?id=72201&action=edit

without any success, though (behavior exactly the same)

So: up to now, the only workaround is the mem=2G kernel opt; but that
means running with half of the total available memory...


ciao
gabriele

Please attach dmesg from 3.6 kernel.

2 things to try:
1) Dealing with this:
[    0.000000] No AGP bridge found
[    0.000000] Node 0: aperture @ c4000000 size 32 MB
[    0.000000] Aperture pointing to e820 RAM. Ignoring.
[    0.000000] Your BIOS doesn't leave a aperture memory hole
[    0.000000] Please enable the IOMMU option in the BIOS setup
[    0.000000] This costs you 64 MB of RAM
[    0.000000] Mapping aperture over 65536 KB of RAM @ c4000000

2) Booting with nouveau.vram_pushbuf=1

Thanks a lot.

1) I cannot find (or I am not able to recognize) any option related to
   AGP/IOMMU in my BIOS menu.
   Following advice in
   http://www.kernel.org/doc/Documentation/x86/x86_64/boot-options.txt,
   I have booted with iommu=soft, which apparently makes the IOMMU
   complaint go away from demsg, but I don't know if this is really a
   solution...
   In any case, booting with (only) iommu=soft, does not make any
   difference: i.e. the machine freezes as above

2) The nouveau.vram_pushbuf=1 option allows me to boot fine (with or
   without the iommu=soft option above)!
   However, now X11 has problems.
   After starting X11, text in menus (e.g. emacs, firefox) and in
   window borders is made of unreadable black rectangles; text in
   windows (e.g. xterm text lines, text in emacs buffers etc) are fine, though.
   This problem goes away if I boot into X11 with
                    Option  "Accel"   "Off"
   i.e.: if I switch acceleration off, everything works nicely (but,
   of course, I have no acceleration)

I have attached dmesg for kernel 3.6.10 (which works perfectly), the
new dmesg for kernel 3.7.1 with iommu=soft and nouveau.vram_pushbuf=1,
my xorg.conf and xorg.0.log for kernel 3.6.10 and 3.7.1 (with/without
accel)

I'll be happy to send any other information which might help to
clarify this problem

thank you very much again

ciao
gabriele

Created attachment 72452 [details]
demsg for kernel-3.6.10

Created attachment 72453 [details]
dmesg for kernel-3.7.1 with iommu=soft nouveau.vram_pushbuf=1

Created attachment 72454 [details]
xorg.conf

Created attachment 72455 [details]
Xorg.0.log for kernel-3.6.10

Created attachment 72456 [details]
Xorg.0.log for kernel-3.7.1 without acceleration

Created attachment 72457 [details]
Xorg.0.log with acceleration

(For some reason GPU reads garbage from GART. With vram_pushbuf=1 we moved main push buffer from GART to VRAM, so it at least starts. But we really need GART.)

Can you bisect it? To speed it up you can use drivers/gpu/drm/nouveau/ as bisect path.

hi there,

sorry for the delay (busy time at work and first time doing a git
bisect).

Here is the final result of the bisection:

---8<-------8<-------8<----

e5f186c4f9812eccbc291da6dfe8b15da546f961 is the first bad commit
commit e5f186c4f9812eccbc291da6dfe8b15da546f961
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Thu Sep 27 08:55:29 2012 +1000

    drm/nv44/vm: fix and enable use of "real" pciegart
    
    Something seems to be missing in regards to flushing specific ranges of
    the TLB.  For the moment, flushing the entire thing seems to make it
    work alright.
    
    Should give 39-bit DMA addressing on the relevant chipsets.
    
    v2: allocate contig 16KiB for dummy pages, reported by mwk on irc
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

:040000 040000 7dd13fec39439ac29561ada8b22f6d2666f46ff5 cf817ecb40b80ebb8446457ea4420005438ebd8e M      drivers

---8<-------8<-------8<----

Don't hesitate to ask me any other piece of information that might be
useful


I thank you very much for your assistance

ciao
gabriele

Lovely, the fix for bug 46557 breaks your card.
I guess booting with nouveau.config=NvPCIE=0 works?

CC'ing Ben.

(In reply to comment #16)
> Lovely, the fix for bug 46557 breaks your card.
> I guess booting with nouveau.config=NvPCIE=0 works?
> 

yep!

With nouveau.config=NvPCIE=0 I can boot 3.7.1 without problems and also X11 (with acceleration, as far as I can say) works fine

thanks a lot

I'll be happy to make any other test and/or gather any other piece of information if needed

ciao
gabriele

I'd be rather curious to know if this issue has fixed itself, although I would guess not. Would you mind checking 3.10 or 3.11-rc6?

Thanks for your interest

Unfortunately, that machine is dead since my report and I am now using a different hardware...

thanks again
ciao
gabriele

OK, closing as invalid since you can no longer test patches.