Re: DRM-core oopses on 2.6.11 [WAS Re: oopses upon loading or removing via]

[<unichrome@sh...>]

Thomas Hellstr=F6m wrote:

> Benno Schulenberg wrote:
>
>>Hi Thomas,
>>
>>You wrote:
>> =20
>>
>>>OK, could you mail me your kernel config,=20
>>>   =20
>>>
>>
>>Attached.
>>
>> =20
>>
>>>and also make sure the=20
>>>via_agp (via-agp?) module gets loaded properly.
>>>   =20
>>>
>>
>>Ehm, I disabled that in the config while trying to find the cause=20
>>for the problem, because it didn't seem needed, as it didn't get=20
>>automatically loaded when doing modprobe via, and its presence=20
>>seemed to cause panics instead of oopses.
>>
>>Benno
>> =20
>>
> Yes, I can reproduce the problem here, on 2.6.11.6. In fact, the via=20
> module never initializes properly as it doesn't print out the version=20
> info etc. This seems to cause an oops on exit.
>
> I'm not sure wether this is via-specific or drm-specific. Anyone with=20
> a clue?
>
> /Thomas
>
OK, just tried to modprobe i915 and sis with the same result, so it is=20
apparently not via-specific.
The driver calls drm_init() but never gets there. A debug statement at=20
the beginning of drm_init() is never printed.

Sounds like maybe the wrong drm.ko is loaded, but there is no such stuff=20
lying around. Also drm is not enabled in the kernel config.

Does anyone have a working set of CVS drivers with 2.6.11.6?

Regards,
Thomas

[Bug 2797] DRI with r300 doesn't work with Crystal Space

[<bugzilla-daemon@fr...>]

Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=2797          
     




------- Additional Comments From ajax@...  2005-03-30 09:39 -------
it's wrong.  DRI drivers should be loadable by the server as well, which is not
linked against libGL.

this is the same issue doom3 had when it first came out.  as a workaround try
running walktest with LD_PRELOAD=/usr/lib/libGL.so (or wherever you put your libGL).          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: [r300] what about *BSD?

[Jung-uk Kim <jkim@ni...>]

On Wednesday 30 March 2005 12:17 pm, Jung-uk Kim wrote:
> On Wednesday 30 March 2005 01:52 am, Jerome Glisse wrote:
> > On Tue, 29 Mar 2005 13:20:01 -0500, Jung-uk Kim <jkim@...>
>
> wrote:
> > > On Monday 28 March 2005 03:22 pm, Jung-uk Kim wrote:
> > > > On Saturday 26 March 2005 07:03 am, Jerome Glisse wrote:
> > > > > > Wait, I have one thing that's not from CVS.  I patched
> > > > > > system compiler from GCC 3.4.2 to GCC 3.4.4 snapshot
> > > > > > (20050318).  I updated GCC because I found some nasty
> > > > > > optimization bugs for AMD64 in GCC 3.4.2. Can this be the
> > > > > > fix?
> > > > >
> > > > > Maybe, weird things can happen... To tell the true have no
> > > > > clue if this gcc upgrade have fix this...Anyway now it
> > > > > works for you. Do you have any freeze now  (try
> > > > > moving,resizing gl window, or some glintensive app...) ?
> > > >
> > > > Actually, I was excited too early.  After I set
> > > > LIBGL_DEBUG=verbose, I found loading r300_dri.so failed
> > > > (because of Mesa's 3DLab shader language commits). :-(  I was
> > > > fooled because it was quite faster than indirect rendering
> > > > (although I have no idea why).  Any way, I just updated Mesa
> > > > again (which disabled mesa_slang thingy but not completely)
> > > > and now it's broken as before.  It's flickering and stretched
> > > > as before and it's not just hung for a while but blanked
> > > > display completely (maybe because Mesa partially disabled
> > > > 3dlabs thingy?) and glxgears is hung on DRM_WAIT_ON() as
> > > > before.
> > >
> > > To make sure I am not doing anything stupid, I copied Xorg,
> > > Mesa, and DRI binaries to my desktop with RV280 (Athlon 64,
> > > same kernel, same DRM, etc.) and it worked perfectly fine. 
> > > glxgears yields close to 3,000 FPS.  So I guess it's R300
> > > issue. :-(
> >
> > I guess there must things to do in the drm in order to make it
> > work with r300 on BSD. If you feel it, you can try see if you see
> > any things that is BSD specifique in r200 drm and see if you can
> > adapt it to r300 drm.
>
> AFAIK, there's nothing r200 specific.  In fact, r300 requires a
> magic to start with:
>
> static int
> radeon_attach(device_t nbdev)
> {
>         drm_device_t *dev = device_get_softc(nbdev);
>
>         bzero(dev, sizeof(drm_device_t));
>         radeon_configure(dev);
> --->    r300_init_reg_flags();
>         return drm_attach(nbdev, radeon_pciidlist);
> }
>
> Inspired by this commit:
>
> http://cvs.sourceforge.net/viewcvs.py/r300/r300_driver/drm/linux-co
>re/radeon_drv.c?r1=1.2&r2=1.3
>
> BTW, can't this be moved to the end of radeon_configure() or
> somewhere?

I meant some r300-specific init function.  radeon_configure() is 
BSD-specific.

Sorry for the confusion,

Jung-uk Kim

> Is it possible the different init path between the two OSes breaks
> r300? 
>
> Thanks,
>
> Jung-uk Kim
>
> > I will take a look at this if i get time (which will be difficult
> >
> > :)).
> >
> > best,
> > Jerome Glisse

[Bug 2797] DRI with r300 doesn't work with Crystal Space

[<bugzilla-daemon@fr...>]

Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=2797          
     




------- Additional Comments From glasse@...  2005-03-30 09:22 -------
Created an attachment (id=2259)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=2259&action=view)
patch to link r300_dri.so against libGL

I fixed the problem by linking r300_dri.so against libGL. I have no idea if
this is the Right Thing or not, though.          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: [r300] what about *BSD?

[Jung-uk Kim <jkim@ni...>]

On Wednesday 30 March 2005 01:52 am, Jerome Glisse wrote:
> On Tue, 29 Mar 2005 13:20:01 -0500, Jung-uk Kim <jkim@...> 
wrote:
> > On Monday 28 March 2005 03:22 pm, Jung-uk Kim wrote:
> > > On Saturday 26 March 2005 07:03 am, Jerome Glisse wrote:
> > > > > Wait, I have one thing that's not from CVS.  I patched
> > > > > system compiler from GCC 3.4.2 to GCC 3.4.4 snapshot
> > > > > (20050318).  I updated GCC because I found some nasty
> > > > > optimization bugs for AMD64 in GCC 3.4.2. Can this be the
> > > > > fix?
> > > >
> > > > Maybe, weird things can happen... To tell the true have no
> > > > clue if this gcc upgrade have fix this...Anyway now it works
> > > > for you. Do you have any freeze now  (try moving,resizing gl
> > > > window, or some glintensive app...) ?
> > >
> > > Actually, I was excited too early.  After I set
> > > LIBGL_DEBUG=verbose, I found loading r300_dri.so failed
> > > (because of Mesa's 3DLab shader language commits). :-(  I was
> > > fooled because it was quite faster than indirect rendering
> > > (although I have no idea why).  Any way, I just updated Mesa
> > > again (which disabled mesa_slang thingy but not completely) and
> > > now it's broken as before.  It's flickering and stretched as
> > > before and it's not just hung for a while but blanked display
> > > completely (maybe because Mesa partially disabled 3dlabs
> > > thingy?) and glxgears is hung on DRM_WAIT_ON() as before.
> >
> > To make sure I am not doing anything stupid, I copied Xorg, Mesa,
> > and DRI binaries to my desktop with RV280 (Athlon 64, same
> > kernel, same DRM, etc.) and it worked perfectly fine.  glxgears
> > yields close to 3,000 FPS.  So I guess it's R300 issue. :-(
>
> I guess there must things to do in the drm in order to make it work
> with r300 on BSD. If you feel it, you can try see if you see any
> things that is BSD specifique in r200 drm and see if you can adapt
> it to r300 drm.

AFAIK, there's nothing r200 specific.  In fact, r300 requires a magic 
to start with:

static int
radeon_attach(device_t nbdev)
{
        drm_device_t *dev = device_get_softc(nbdev);

        bzero(dev, sizeof(drm_device_t));
        radeon_configure(dev);
--->    r300_init_reg_flags();
        return drm_attach(nbdev, radeon_pciidlist);
}

Inspired by this commit:

http://cvs.sourceforge.net/viewcvs.py/r300/r300_driver/drm/linux-core/radeon_drv.c?r1=1.2&r2=1.3

BTW, can't this be moved to the end of radeon_configure() or 
somewhere?  Is it possible the different init path between the two 
OSes breaks r300?

Thanks,

Jung-uk Kim

> I will take a look at this if i get time (which will be difficult
> :)).
>
> best,
> Jerome Glisse

Re: add new ati radeon card ids

[Alex Deucher <alexdeucher@gm...>]

On Wed, 30 Mar 2005 07:41:18 +0200, Frank <fbehrens@...> wrote:
> 
> ATI Radeon X800 (R430) (PCIE)
> 
> 0000:05:00.0 Class 0300: 1002:554f
> 0000:05:00.1 Class 0380: 1002:556f  <-- second device
> 
> 73 de Frank
> 

see bug 2827 for the latest pci ids for radeon:
https://bugs.freedesktop.org/show_bug.cgi?id=2827
The secondary devices are really just a hack so that windows 2000 can
support dualhead.  It's just a placeholder id.  The actual chip is the
first device.  X won't work on the second id; everything is through
the first, hence all secondary ids are ignored.

Alex

DRM-core oopses on 2.6.11 [WAS Re: oopses upon loading or removing via]

[<unichrome@sh...>]

Benno Schulenberg wrote:

>Hi Thomas,
>
>You wrote:
>  
>
>>OK, could you mail me your kernel config, 
>>    
>>
>
>Attached.
>
>  
>
>>and also make sure the 
>>via_agp (via-agp?) module gets loaded properly.
>>    
>>
>
>Ehm, I disabled that in the config while trying to find the cause 
>for the problem, because it didn't seem needed, as it didn't get 
>automatically loaded when doing modprobe via, and its presence 
>seemed to cause panics instead of oopses.
>
>Benno
>  
>
Yes, I can reproduce the problem here, on 2.6.11.6. In fact, the via 
module never initializes properly as it doesn't print out the version 
info etc. This seems to cause an oops on exit.

I'm not sure wether this is via-specific or drm-specific. Anyone with a 
clue?

/Thomas

Re: [r300] building on ppc?

[Johannes Berg <johannes@si...>]

On Tue, 2005-03-29 at 18:51 -0500, Adam Jackson wrote:

> It should have been installed when you built Xorg from CVS.  ie, you shou=
ld=20
> already have it.

For some reason it wasn't built initially but its there now and I got
all the technicalities figured out. Now, however, X instantly loops or
locks up when starting (first time I tried I could still kill it while
it was taking close to 100% cpu time, second time it locked up)

I'll be taking a closer look at that, but not today.

johannes

Re: oopses upon loading or removing via

[<unichrome@sh...>]

Benno Schulenberg wrote:

>Thomas Hellstr=F6m wrote:
> =20
>
>>Benno Schulenberg wrote:
>>   =20
>>
>>>Using CVS of today (and of the past few weeks I can't get the
>>>via module to work, it doesn't do anything, and it oopses
>>>either when loaded or removed.
>>>     =20
>>>
>>Working fine here with 2.6.8.
>>   =20
>>
>
>Could you please try with a 2.6.10 or 2.6.11 kernel, Thomas? =20
>To make sure it's not me making some stupid mistake.
>
> =20
>
OK, could you mail me your kernel config, and also make sure the
via_agp (via-agp?) module gets loaded properly.

/Thomas


>>Could you try to set
>>
>>#define VIA_PCI_BUF_SIZE 60000
>>
>>instead of 120000
>>(via_drv.h)
>>recompile and see if this changes things.
>>   =20
>>
>
>Okay, tried it, same result:
>
># rmmod -v via
>rmmod via, wait=3Dno
>Unable to handle kernel NULL pointer dereference at virtual address 0000=
0000
> printing eip:
>*pde =3D 00000000
>Oops: 0002 [#1]
>Modules linked in: via drm agpgart
>CPU:    0
>EIP:    0060:[<c029263c>]    Not tainted VLI
>EFLAGS: 00010002   (2.6.11)
>EIP is at __down+0x4c/0xc0
>eax: 00000000   ebx: debc563c   ecx: debc5644   edx: c17a9ee4
>esi: dd974060   edi: 00000246   ebp: c17a9f04   esp: c17a9ed4
>ds: 007b   es: 007b   ss: 0068
>Process rmmod (pid: 959, threadinfo=3Dc17a8000 task=3Ddd974060)
>Stack: debc5644 00000001 dd974060 c01103c0 debc5644 00000000 00000096 00=
000000
>       c17a9f18 debc5634 debc5520 00000000 c17a9f14 c02927aa debc2700 de=
bc5ac4
>       c17a9f24 c01e1cb1 debc5634 00000000 c17a9f30 c01afcf4 debc5634 c1=
7a9f4c
>Call Trace:
> [<c01027cf>] show_stack+0x7f/0xa0
> [<c0102967>] show_registers+0x157/0x1d0
> [<c0102bbc>] die+0x13c/0x160
> [<c010e7b0>] do_page_fault+0x3d0/0x5fe
> [<c010246b>] error_code+0x2b/0x30
> [<c02927aa>] __down_failed+0xa/0x10
> [<c01e1cb1>] .text.lock.driver+0x8/0x17
> [<c01afcf4>] pci_unregister_driver+0x14/0x20
> [<debb6cb9>] drm_exit+0x99/0xc0 [drm]
> [<debc2712>] via_exit+0x12/0x47 [via]
> [<c01279a7>] sys_delete_module+0x127/0x160
> [<c01022c3>] syscall_call+0x7/0xb
>Code: 89 75 d8 c7 45 dc c0 03 11 c0 c7 06 02 00 00 00 9c 5f fa 8d 43 08 =
83 4d d4 01 8d 55 e0 89 45 d0 89 c1 8b 40 04 89 4d e0 89 51 04 <89> 10 ff=
 43 04 89 45 e4 eb 17 c7 43 04 01 00 00 00 57 9d e8 8c
> Segmentation fault
>
>Benno
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
>--
>_______________________________________________
>Dri-devel mailing list
>Dri-devel@...
>https://lists.sourceforge.net/lists/listinfo/dri-devel
> =20
>

Re: oopses upon loading or removing via

[Benno Schulenberg <bensberg@ju...>]

Thomas Hellstr=F6m wrote:
> Benno Schulenberg wrote:
> > Using CVS of today (and of the past few weeks I can't get the
> > via module to work, it doesn't do anything, and it oopses
> > either when loaded or removed.
>
> Working fine here with 2.6.8.

Could you please try with a 2.6.10 or 2.6.11 kernel, Thomas? =20
To make sure it's not me making some stupid mistake.

> Could you try to set
>
> #define VIA_PCI_BUF_SIZE 60000
>
> instead of 120000
> (via_drv.h)
> recompile and see if this changes things.

Okay, tried it, same result:

# rmmod -v via
rmmod via, wait=3Dno
Unable to handle kernel NULL pointer dereference at virtual address 00000=
000
 printing eip:
*pde =3D 00000000
Oops: 0002 [#1]
Modules linked in: via drm agpgart
CPU:    0
EIP:    0060:[<c029263c>]    Not tainted VLI
EFLAGS: 00010002   (2.6.11)
EIP is at __down+0x4c/0xc0
eax: 00000000   ebx: debc563c   ecx: debc5644   edx: c17a9ee4
esi: dd974060   edi: 00000246   ebp: c17a9f04   esp: c17a9ed4
ds: 007b   es: 007b   ss: 0068
Process rmmod (pid: 959, threadinfo=3Dc17a8000 task=3Ddd974060)
Stack: debc5644 00000001 dd974060 c01103c0 debc5644 00000000 00000096 000=
00000
       c17a9f18 debc5634 debc5520 00000000 c17a9f14 c02927aa debc2700 deb=
c5ac4
       c17a9f24 c01e1cb1 debc5634 00000000 c17a9f30 c01afcf4 debc5634 c17=
a9f4c
Call Trace:
 [<c01027cf>] show_stack+0x7f/0xa0
 [<c0102967>] show_registers+0x157/0x1d0
 [<c0102bbc>] die+0x13c/0x160
 [<c010e7b0>] do_page_fault+0x3d0/0x5fe
 [<c010246b>] error_code+0x2b/0x30
 [<c02927aa>] __down_failed+0xa/0x10
 [<c01e1cb1>] .text.lock.driver+0x8/0x17
 [<c01afcf4>] pci_unregister_driver+0x14/0x20
 [<debb6cb9>] drm_exit+0x99/0xc0 [drm]
 [<debc2712>] via_exit+0x12/0x47 [via]
 [<c01279a7>] sys_delete_module+0x127/0x160
 [<c01022c3>] syscall_call+0x7/0xb
Code: 89 75 d8 c7 45 dc c0 03 11 c0 c7 06 02 00 00 00 9c 5f fa 8d 43 08 8=
3 4d d4 01 8d 55 e0 89 45 d0 89 c1 8b 40 04 89 4d e0 89 51 04 <89> 10 ff =
43 04 89 45 e4 eb 17 c7 43 04 01 00 00 00 57 9d e8 8c
 Segmentation fault

Benno

Re: [r300] what about *BSD?

[Jerome Glisse <j.glisse@gm...>]

On Tue, 29 Mar 2005 13:20:01 -0500, Jung-uk Kim <jkim@...> wrote:
> On Monday 28 March 2005 03:22 pm, Jung-uk Kim wrote:
> > On Saturday 26 March 2005 07:03 am, Jerome Glisse wrote:
> > > > Wait, I have one thing that's not from CVS.  I patched system
> > > > compiler from GCC 3.4.2 to GCC 3.4.4 snapshot (20050318).  I
> > > > updated GCC because I found some nasty optimization bugs for
> > > > AMD64 in GCC 3.4.2. Can this be the fix?
> > >
> > > Maybe, weird things can happen... To tell the true have no clue
> > > if this gcc upgrade have fix this...Anyway now it works for you.
> > > Do you have any freeze now  (try moving,resizing gl window, or
> > > some glintensive app...) ?
> >
> > Actually, I was excited too early.  After I set
> > LIBGL_DEBUG=verbose, I found loading r300_dri.so failed (because of
> > Mesa's 3DLab shader language commits). :-(  I was fooled because it
> > was quite faster than indirect rendering (although I have no idea
> > why).  Any way, I just updated Mesa again (which disabled
> > mesa_slang thingy but not completely) and now it's broken as
> > before.  It's flickering and stretched as before and it's not just
> > hung for a while but blanked display completely (maybe because Mesa
> > partially disabled 3dlabs thingy?) and glxgears is hung on
> > DRM_WAIT_ON() as before.
> 
> To make sure I am not doing anything stupid, I copied Xorg, Mesa, and
> DRI binaries to my desktop with RV280 (Athlon 64, same kernel, same
> DRM, etc.) and it worked perfectly fine.  glxgears yields close to
> 3,000 FPS.  So I guess it's R300 issue. :-(

I guess there must things to do in the drm in order to make it work
with r300 on BSD. If you feel it, you can try see if you see any
things that is BSD specifique in r200 drm and see if you can adapt
it to r300 drm.

I will take a look at this if i get time (which will be difficult :)).

best,
Jerome Glisse

add new ati radeon card ids

[Frank <fbehrens@hs...>]

ATI Radeon X800 (R430) (PCIE)

0000:05:00.0 Class 0300: 1002:554f
0000:05:00.1 Class 0380: 1002:556f  <-- second device

73 de Frank

Re: [r300] building on ppc?

[Vladimir Dergachev <volodya@mi...>]

Just to add a comment:

  I always had good success with using using "X -configure" configuration 
files.

  If things break, try "X -configure" configuration file first and, if it 
works, copy custom sections into it from other configuration files
(I usually have to add mouse configuration, DefaultDepth and a modeline or 
two).

                     best

                          Vladimir Dergachev

On Tue, 29 Mar 2005, Adam Jackson wrote:

> On Tuesday 29 March 2005 18:47, Johannes Berg wrote:
>> On Tue, 2005-03-29 at 18:38 -0500, Adam Jackson wrote:
>>> That file name should end in .so, not .o.  Find all the .o and .a files
>>> under /opt/Xorg-cvs and move them aside.
>>
>> Ouch, ok. All gone, but where do I get radeon_drv.so then?
>
> It should have been installed when you built Xorg from CVS.  ie, you should
> already have it.
>
> - ajax
>

[Bug 2852] Bug when I enable DRI, xfree86 take 100% CPU

[<bugzilla-daemon@fr...>]

Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=2852          
     

zor@... changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From zor@...  2005-03-29 18:44 -------
option agpmode=4 was the problem          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 2852] Bug when I enable DRI, xfree86 take 100% CPU

[<bugzilla-daemon@fr...>]

Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=2852          
     




------- Additional Comments From airlied@...  2005-03-29 17:44 -------
Try getting the DRM from CVS and using it - 2.6.12 will have a fixed DRM for
X4.3, simple patch just got missed, I might push it into a 2.6.11.7 depends on
if I get time..


          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.