(Unrelated) X.Org lockup resolved, radeonfb vs. vesa vga (was: Re: Kernel panic with Mobility M300 (TP43p) and DRI/Mesa/EGL demo)
Am Dienstag, den 20.02.2007, 20:10 +0100 schrieb Christian Neumair: Did you card work flawlessly with dri enabled under xorg ? No, it doesn't. The screen turns black, the computer itself does not seem to lock up, but according to the Xorg log (attached, gzipp'd) everything seems to go fine. My messages log has: Feb 20 19:39:31 localhost kernel: [17179959.672000] [drm] Used old pci detect: framebuffer loaded Feb 20 19:39:54 localhost kernel: [17179982.14] mtrr: 0xc000,0x800 overlaps existing 0xc000,0x400 (2 or 3 times) Feb 20 19:40:22 localhost kernel: [17180009.848000] 3[drm:drm_release] *ERROR* Device busy: 1 0 (this is in the log every 20 seconds) But maybe this is an expected result if I bring up the whole system at runtime? I run vesafb, modprobe drm and radeon and then just bring up the X server. Do these FBs interfere somehow? I didn't run vesafb, I actually ran radeonfb. The locking doesn't happen and X.Org can be launched fine when just using vesa (by appending video=vesa to the kernel line). I'm just dropping these lines to make it simpler for people desperately grepping mail archives to get their locked X.Org server (possibly on Ubuntu/Edgy) to run. I suppose this is really an unrelated readeonfb issue, the EGL/dri driver still doesn't work though. I'll further investigate it. -- Christian Neumair [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Kernel panic with Mobility M300 (TP43p) and DRI/Mesa/EGL demo
Dear DRI mailing list, I'm trying to make my Radeon Mobility M300 (probably PCIE) which is reported as 01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Radeon Mobility M300] work with the EGL demos. This is because I'd like to help out with EGL +MESA development. Now I'm totally stuck, and suppose I hit a few deeply-rooted problems that I cannot solve without in-depth knowledge about DRM memory layout. DRI/Mesa are fresh GIT checkouts, I also had this problem with old CVS builds. Such knowledge doesn't seem to be available publicly, and understanding the details often requires one to have much previous knowledge about graphic achitectures in general - which I suppose is often NDAed, as the publicly available papers aren't too long. Feel free to prove me wrong, I'm really interested in understanding GART, FB, VRAM, shared memory, the DRM locking scheme and especially how they play together. Back to my kernel panic: My DRM debugging output is [17199560.604000] [drm:radeon_do_init_cp] [17199560.604000] [drm:radeon_do_init_cp] dev_priv-cp_ring-handle e1cf5000 [17199560.604000] [drm:radeon_do_init_cp] dev_priv-ring_rptr-handle e1df6000 [17199560.608000] [drm:radeon_do_init_cp] dev-agp_buffer_map-handle e1df7000 [17199560.608000] [drm] Setting GART location based on old memory map [17199560.608000] [drm:radeon_do_init_cp] dev_priv-gart_size 8388608 [17199560.608000] [drm:radeon_do_init_cp] dev_priv-gart_vm_start 0x400 [17199560.612000] [drm:radeon_do_init_cp] dev_priv-gart_buffers_offset 0x4102000 [17199560.612000] [drm:radeon_do_init_cp] Setting phys_pci_gart to 07FF8000 [17199560.612000] [drm:drm_ati_pcigart_init] PCI: Gart Table: VRAM 07FF8000 mapped at [17199560.612000] BUG: unable to handle kernel NULL pointer dereference at virtual address (...) The last two lines really look fishy. The basic problem seems to be that in radeon_do_init_cp(), the drm_core_ioremap(dev_priv-gart_info.mapping, dev); fails, i.e. the mapping's handle is NULL afterwards. I have no clue what's causing this. Maybe there has to be added special code for dealing with PCIE cards that use shared memory. I'm really stuck here, thanks for any hints! -- Christian Neumair [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel panic with Mobility M300 (TP43p) and DRI/Mesa/EGL demo
Am Dienstag, den 20.02.2007, 18:04 +0100 schrieb Jerome Glisse: (...) (...) [1] Thanks for your hints regarding documentation. My overall impression was that some parts of the wiki are not tidied up, and many docs are scattered, but of course one can't expect busy developers to invest very much time into communcating their ideas. Did you card work flawlessly with dri enabled under xorg ? No, it doesn't. The screen turns black, the computer itself does not seem to lock up, but according to the Xorg log (attached, gzipp'd) everything seems to go fine. My messages log has: Feb 20 19:39:31 localhost kernel: [17179959.672000] [drm] Used old pci detect: framebuffer loaded Feb 20 19:39:54 localhost kernel: [17179982.14] mtrr: 0xc000,0x800 overlaps existing 0xc000,0x400 (2 or 3 times) Feb 20 19:40:22 localhost kernel: [17180009.848000] 3[drm:drm_release] *ERROR* Device busy: 1 0 (this is in the log every 20 seconds) But maybe this is an expected result if I bring up the whole system at runtime? I run vesafb, modprobe drm and radeon and then just bring up the X server. Do these FBs interfere somehow? If so then you will have to investigated, likely somethings isn't properly initialized and i would bet that this is somethings that ddx use to initialize. Maybe. The EGL code (_eglInitialize [2] calling radeonInitialize [3]) does indeed include some setup routines that are called before the problematic DRM_RADEON_CP_INIT in RADEONDRIKernelInit() (also [3], not sure how the XXX FIXME mark is). Thanks for your quick and helpful response! [1] http://marc.theaimsgroup.com/?t=11719896433r=1w=2 [2] http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=blob;hb=HEAD;f=src/egl/drivers/dri/egldri.c [3] http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=blob;hb=HEAD;f=src/mesa/drivers/dri/radeon/server/radeon_egl.c -- Christian Neumair [EMAIL PROTECTED] Xorg.0.log.gz Description: GNU Zip compressed data - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Help needed! I don't understand the DRM linux GART code.
Dear DRI/DRM developers, I'm trying to understand the DRM GART interaction with the linux DRM core, because I'm trying to run the M300 Mobility (PCI Express) with Xegl to help out with development. I fetched MESA and DRM, built them (after applying some fixes), and built Xegl. I'm now trying to run Xegl with a frame buffer, and when starting get [17182196.816000] [drm:radeon_do_init_cp] [17182196.816000] [drm:radeon_do_init_cp] dev_priv-cp_ring-handle e1ca2000 [17182196.816000] [drm:radeon_do_init_cp] dev_priv-ring_rptr-handle e1da3000 [17182196.816000] [drm:radeon_do_init_cp] dev-agp_buffer_map-handle e1da4000 [17182196.816000] [drm] Setting GART location based on old memory map [17182196.816000] [drm:radeon_do_init_cp] dev_priv-gart_size 8388608 [17182196.816000] [drm:radeon_do_init_cp] dev_priv-gart_vm_start 0x400 [17182196.816000] [drm:radeon_do_init_cp] dev_priv-gart_buffers_offset 0x4102000 [17182196.816000] [drm:radeon_do_init_cp] Setting phys_pci_gart to 07FF8000 [17182196.816000] [drm:drm_ati_pcigart_init] PCI: Gart Table: VRAM 07FF8000 mapped at [17182196.816000] BUG: unable to handle kernel NULL pointer dereference at virtual address (...) Because the driver is said to not work on PCI express cards, I already expected something like this, but I wasn't able to fix it up to now. My problem is that I read various GART interaction code having different code paths depending on whether a) the built-in card is AGP, PCIE or PCI b) the GART table is stored in FB or in MAIN memory I'm specifically puzzled by code relating to b), there is a lot of offset juggling, for instance in radeon_cp.c:radeon_do_init_cp, where for PCI cards the (otherwised unused/0-initialized) mapping.handle is under some circumstances assigned to dev_priv-gart_info.addr, which is then passed to drm_ati_pcigart_init. This code in turn will not malloc the PCIGART table for FB mapping tables, and thus dereference a NULL pointer when trying to memset the 0 address. My problem is now that while I found many articles describing the general idea of DRI and DRM, I could not found papers on the interaction with GART, and the concrete implementation design choices. I don't understand the role of the various offsets, including the fb_offset, radeon_fb_delta and gart_vm_start. An image containing some suggestive base pointer addressing illustrations on what memory areas are used, and where they are located would help me a lot. Maybe I'm just to dumb to grasp more than the big picture, and the code comments should be sufficient, or maybe I missed any docs? -- Christian Neumair [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
