Announcement

Collapse
No announcement yet.

black screen with kubuntu 8.04 x86_64 and fglrx 8.5

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mamonetti
    started a topic black screen with kubuntu 8.04 x86_64 and fglrx 8.5

    black screen with kubuntu 8.04 x86_64 and fglrx 8.5

    Hi

    Well, i've just switched from my old opensuse/ati9600, and i'm just having problems with fglrx.

    I decided to install the latest version, and seems to get installed fine (with apt and also "manually" generating the packages with ati installer). In fact manual installation was generating some error messages (after switching from ati driver to fglrx), but i was able to fix it using this "guide": http://ubuntuforums.org/showthread.php?t=785107

    Anyway, every time i install it i get a black screen at boot time, when the X server is going to start. The computer freezes, the keyboard doesn't work and i can't even go to a text terminal to make anything. In the end i have to force reboot. If i start in single user mode i can see loaded the driver by typing lsmod (there it is).

    How can i check where's the problem? Have you seen something similar?

    Regards

  • aslpavel
    replied
    actualy there is no use changin mtrr unless u device realy located on 0xe0000000 mine is located at 0xd0000000:
    Code:
    01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870] (prog-if 00 [VGA controller])
    	Subsystem: ATI Technologies Inc Device 0502
    	Flags: bus master, fast devsel, latency 0, IRQ 30
    	Memory at d0000000 (64-bit, prefetchable) [size=256M]
    	Memory at fe8e0000 (64-bit, non-prefetchable) [size=64K]
    	I/O ports at c000 [size=256]
    	Expansion ROM at fe8c0000 [disabled] [size=128K]
    	Capabilities: [50] Power Management version 3
    	Capabilities: [58] Express Legacy Endpoint, MSI 00
    	Capabilities: [a0] MSI: Mask- 64bit+ Count=1/1 Enable+
    	Capabilities: [100] Vendor Specific Information <?>
    	Kernel driver in use: fglrx_pci
    	Kernel modules: fglrx
    i thought u find a way to shift device to 256Mb in address space
    with compoziting enabled i got crashes like this:

    Code:
    Backtrace:
    0: X(xorg_backtrace+0x26) [0x4eaff6]
    1: X(xf86SigHandler+0x39) [0x487f89]
    2: /lib/libc.so.6 [0x7f3ca7941270]
    3: /usr/lib64/xorg/modules//libxaa.so [0x7f3ca5ce8dec]
    4: /usr/lib64/xorg/modules//libxaa.so [0x7f3ca5ce95f0]
    5: X [0x52c3d8]
    6: X [0x51b63a]
    7: X(Dispatch+0x364) [0x44a404]
    8: X(main+0x44d) [0x430b2d]
    9: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f3ca792d5c6]
    10: X [0x42ff19]
    
    Fatal server error:
    Caught signal 11.  Server aborting
    and kernel log like this
    Code:
    May  6 23:17:46 maggot [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_close] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fbfc7228000,handle:0xd13f5000
    May  6 23:17:46 maggot [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_close] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fbfc7229000,handle:0xd13f4000
    May  6 23:17:46 maggot [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_close] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fbfc722a000,handle:0xd13f0000
    May  6 23:17:46 maggot [fglrx:firegl_takedown] *ERROR* map 0xffff8800cbcb7a80 - type UNKNOWN 16
    May  6 23:17:46 maggot [fglrx:firegl_takedown] *ERROR* map 0xffff8800cd1cfe40 - type UNKNOWN 16
    May  6 23:17:46 maggot [fglrx:firegl_takedown] *ERROR* map 0xffff8800cdd9d120 - type UNKNOWN 16
    May  6 23:17:46 maggot [fglrx:firegl_takedown] *ERROR* map 0xffff8800cdd9de40 - type UNKNOWN 16
    May  6 23:17:46 maggot [fglrx:firegl_takedown] *ERROR* map 0xffff8800cc116c60 - type UNKNOWN 16
    After this the only way to make it work again is reboot, if i try
    to start X again it hangs whole system even ssh connetion fails
    Any suggestions?

    Leave a comment:


  • kingtaurus
    replied
    You can set the mtrr by (hand). However I would caution against this. My mtrr tables are currently set to:

    Code:
    reg01: base=0x0e0000000 ( 3584MB), size=  512MB, count=1: uncachable
    reg02: base=0x000000000 (    0MB), size= 4096MB, count=1: write-back
    reg03: base=0x100000000 ( 4096MB), size=  512MB, count=1: write-back
    reg04: base=0x120000000 ( 4608MB), size=  256MB, count=1: write-back
    these are set by the kernel (I don't modify the tables by hand). Currently using Jaunty (9.04) with the corresponding
    Code:
    uname -a
    being

    Code:
    Linux bender 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux


    Originally posted by aslpavel View Post
    2kingtaurus
    could u provide exect kernel options that u use to achieve shift of pci device from 0xd000000 to 0xe0000000. I think porblems some how related to alignment of the "base" it should be aligned to the "size" but if we got 512Mb video ram and it mapped to 3328 by bios it cannot be alligned this way and when driver try to access higher ranges of memory it crashes system. Actualy catalyst work for me but randomly crashes when i use comositing.

    Mb: Asus P5Q Pro
    Mem: 2x2Gb
    Cpu: Q9300
    Video: HD4870

    Thx

    Leave a comment:


  • aslpavel
    replied
    2kingtaurus
    could u provide exect kernel options that u use to achieve shift of pci device from 0xd000000 to 0xe0000000. I think porblems some how related to alignment of the "base" it should be aligned to the "size" but if we got 512Mb video ram and it mapped to 3328 by bios it cannot be alligned this way and when driver try to access higher ranges of memory it crashes system. Actualy catalyst work for me but randomly crashes when i use comositing.

    Mb: Asus P5Q Pro
    Mem: 2x2Gb
    Cpu: Q9300
    Video: HD4870

    Thx

    Leave a comment:


  • alec
    replied
    this is good news!

    Leave a comment:


  • kingtaurus
    replied
    Originally posted by kingtaurus View Post
    Ooops ... stupid me .

    You might have to do the following:

    [X86-32] Use together with memmap= to avoid physical
    address space collisions. Without memmap= PCI devices
    could be placed at addresses belonging to unused RAM.

    From (http://www.mjmwired.net/kernel/Docum...arameters.txt)

    Kano ... is there an x86_64 kernel parameter like pci=nobios (x86_32)?
    MTRR is now setup properly using ubuntu-8.10 release candidate. My tables are now configured like:
    gking@bender:~$ cat /proc/mtrr
    reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
    reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
    reg04: base=0x120000000 (4608MB), size= 256MB: write-back, count=1

    Leave a comment:


  • kingtaurus
    replied
    Ooops ... stupid me .

    You might have to do the following:

    [X86-32] Use together with memmap= to avoid physical
    address space collisions. Without memmap= PCI devices
    could be placed at addresses belonging to unused RAM.

    From (http://www.mjmwired.net/kernel/Docum...arameters.txt)

    Kano ... is there an x86_64 kernel parameter like pci=nobios (x86_32)?

    Originally posted by Kano View Post
    only M not MB.
    Last edited by kingtaurus; 06-05-2008, 06:45 PM.

    Leave a comment:


  • Kano
    replied
    only M not MB.

    Leave a comment:


  • kingtaurus
    replied
    Did you try using the mem=xxxxMB as a kernel option?

    Originally posted by hehe2 View Post
    I've made the test yesterday, disabling the memory remapping in the bios. That leads to 3.3Gb usable only, even with the 64Gb PAE kernel.

    In fact, as soon as the PC starts, bios detects only 3.3Gb without memory remapping (startup bios display), and I presume the memory lost can't be recovered by the OS in a later time.

    Leave a comment:


  • hehe2
    replied
    [ Test ]

    Originally posted by movieman View Post
    If the extra memory isn't remapped, it will be hidden by the PCI memory mapping.

    That said, I guess the OS could do remapping itself, but by the time it boots that may be too late.
    I've made the test yesterday, disabling the memory remapping in the bios. That leads to 3.3Gb usable only, even with the 64Gb PAE kernel.

    In fact, as soon as the PC starts, bios detects only 3.3Gb without memory remapping (startup bios display), and I presume the memory lost can't be recovered by the OS in a later time.

    Leave a comment:

Working...
X