From: Alan C. <al...@lx...> - 2004-09-29 22:06:09
|
On Mer, 2004-09-29 at 22:52, Felix K=C3=BChling wrote: > Module Size Used by > savage 3520 0 > drm 62500 3 savage >=20 > Is it normal that the savage module looks unused? looks like a bug. If the drm layer provides the file_operations for the device node then the locking done automatically locks the wrong module. Thats easy to fix with try_module_get() and module_put() |
From: Jon S. <jon...@gm...> - 2004-09-29 23:25:33
|
On Wed, 29 Sep 2004 23:52:38 +0200, Felix K=FChling <fx...@gm...> wrote: > Is it normal that the savage module looks unused? I can actually rmmod > the savage module while X is running. After that direct rending fails > with some error message about permissions ... reloading savage didn't > help (of course, because X wouldn't reinitialize it). A bit later the > box locked up. Is this 0 usage count and the ability to rmmod the module > while X is running specific to the savage driver or do other drivers > show the same behaviour? This is a bug, open is marking the wrong module in use. > Some questions about future driver development: So the new linux-core > and shared-core are the place to do new driver development? If this is > correct then it will be for 2.6 kernels only, right? I suppose there > would some back-porting effort involved in getting a future savage > driver to work with 2.4 again (like adding back all the DRM() macros). There is no real difference between the code in the linux directory and linux-core except for the removal of the DRM macros and the associated restructuring needed to make everything work. When we get linux-core working without problems, it's not there yet, it could become the future 2.6 platform if everyone agrees. The impact of the linux-core changes are minimal on the board specific code. For 2.4 there is a choice: continue using the linux directory or backport linux-core to 2.4. I don't know how much effort everyone wants to put into backporting new driver development to 2.4. There are several possible choices: 1) leave 2.4 alone and stop working on it, 2.4 stays in the linux directory 2) declare the DRM version in the linux-2.4 the final version and only submit bug patches via the kernel process. 3) backport linux-core to 2.4 and so that everything will build on both OS's. Some 2.6 kernel changes are starting to make this a very cluttered option. 4) Make parallel changes to the 2.4 and 2.6 versions. 5) other combinations of these The removal of the DRM macros from files in the shared directory means that things can't be shared again unless 2.4/BSD also move the the core model. I have no strong opinions on what to do about 2.4. I'll go along with whatever the crowd picks. --=20 Jon Smirl jon...@gm... |
From: F. <jrf...@tu...> - 2004-10-06 13:39:46
|
Jon, I was trying to build and test the linux-core - I really like what you've been doing there - but I get endless kernel oops after insmod'ing any of the driver modules (not the common drm one though), regardless the specific chip is present or not. Before I search deeper into this could you let me know whether the code in *-core is not runnable yet, or if there must be something wrong on my side? Regards, José Fonseca |
From: Vladimir D. <vo...@mi...> - 2004-10-06 13:55:12
|
On Wed, 6 Oct 2004, [iso-8859-15] Jos=E9 Fonseca wrote: > Jon, > > I was trying to build and test the linux-core - I really like what > you've been doing there - but I get endless kernel oops after insmod'ing > any of the driver modules (not the common drm one though), regardless > the specific chip is present or not. > > Before I search deeper into this could you let me know whether the code > in *-core is not runnable yet, or if there must be something wrong on my > side? Just as a data point I was able to insert radeon module just fine on=20 2.6.9rc3. This was yesterday. Maybe a fresh checkout will help ? best Vladimir Dergachev > > Regards, > > Jos=E9 Fonseca > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out mo= re > http://productguide.itmanagersjournal.com/guidepromo.tmpl > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Jon S. <jon...@gm...> - 2004-10-06 16:30:23
|
On Wed, 6 Oct 2004 14:37:14 +0100, Jos=E9 Fonseca <jrf...@tu...> wrote: > Jon, >=20 > I was trying to build and test the linux-core - I really like what > you've been doing there - but I get endless kernel oops after insmod'ing > any of the driver modules (not the common drm one though), regardless > the specific chip is present or not. >=20 > Before I search deeper into this could you let me know whether the code > in *-core is not runnable yet, or if there must be something wrong on my > side? What kernel version?=20 What is the OOPs? Be sure and try with the current CVS. Bugs are getting fixed as fast as people are reporting them. --=20 Jon Smirl jon...@gm... |
From: F. <jrf...@tu...> - 2004-10-06 21:26:02
|
On Wed, Oct 06, 2004 at 12:30:01PM -0400, Jon Smirl wrote: > On Wed, 6 Oct 2004 14:37:14 +0100, José Fonseca > <jrf...@tu...> wrote: > > Jon, > > > > I was trying to build and test the linux-core - I really like what > > you've been doing there - but I get endless kernel oops after insmod'ing > > any of the driver modules (not the common drm one though), regardless > > the specific chip is present or not. > > > > Before I search deeper into this could you let me know whether the code > > in *-core is not runnable yet, or if there must be something wrong on my > > side? > > What kernel version? kernel version 2.6.8, from debian unstable. > What is the OOPs? They are not reproducible, i.e., they are always different every run, on a different entry point. They happen one after the other so fast that they're never recorded on /proc/kmsg. I got a screenshot (literaly, with a digital camera) on http://jrfonseca.dyndns.org/misc/bugs/radeon-core.jpg after insmod'ing radeon. It's likely that the first oops is within the loaded module, but all the others oops trash it away... I also add that insmod'ing mach64 or radeon from the linux-2.6 works just fine, so it must be some regression in linux-core. > Be sure and try with the current CVS. Bugs are getting fixed as fast > as people are reporting them. On Wed, Oct 06, 2004 at 09:53:51AM -0400, Vladimir Dergachev wrote: > Just as a data point I was able to insert radeon module just fine on > 2.6.9rc3. This was yesterday. Maybe a fresh checkout will help ? > > best > > Vladimir Dergachev I've tracking the CVS closely for the last 2 days, but nothing changed so far. I'll try with 2.6.9 too see if it changes anything. I noticed the "Ignoring new-style parameters in presence of obsolete ones" warnings. What is the de-facto way to enable extra debugging info in linux-core modules? José Fonseca |
From: Ian R. <id...@us...> - 2004-10-06 21:46:38
|
Jos=E9 Fonseca wrote: > They happen one after the other so fast that they're never recorded on > /proc/kmsg. I got a screenshot (literaly, with a digital camera) on > http://jrfonseca.dyndns.org/misc/bugs/radeon-core.jpg after insmod'ing > radeon. It's likely that the first oops is within the loaded module, bu= t > all the others oops trash it away... This is funny to me. I seem to remember someone scoffing the importance=20 of being able to print oopses, no matter what, at kernel summit. A lot=20 of people nodded approvingly until Linus took the mic...and described=20 almost exactly this situation! :) |
From: Jon S. <jon...@gm...> - 2004-10-06 21:51:45
|
For debug info: insmod ./drm.ko drm_opts=debug:on insmod ./radeon.ko drm_opts=debug:on I haven't fully writen the code for the new parameters yet. When it is finished the message will disappear. Make sure you don't have any old DRM drivers loaded by accident or compiled into your kernel. If you do the symbols will be all messed up and who know where the code will jump. Sometimes the drm/radeon pair will still load even if an old version is in memory. Try a sequence like this: [root@smirl linux-core]# insmod ./drm.ko drm_opts=debug:on [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on [root@smirl linux-core]# rmmod radeon [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on [root@smirl linux-core]# rmmod radeon [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on [root@smirl linux-core]# rmmod radeon [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on [root@smirl linux-core]# rmmod radeon [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on [root@smirl linux-core]# rmmod radeon [root@smirl linux-core]# rmmod drm [root@smirl linux-core]# This runs for me without errors. -- Jon Smirl jon...@gm... |
From: F. <jrf...@tu...> - 2004-10-11 10:59:32
|
On Wed, Oct 06, 2004 at 05:51:41PM -0400, Jon Smirl wrote: > For debug info: > insmod ./drm.ko drm_opts=debug:on > insmod ./radeon.ko drm_opts=debug:on > > I haven't fully writen the code for the new parameters yet. When it is > finished the message will disappear. > > Make sure you don't have any old DRM drivers loaded by accident or > compiled into your kernel. If you do the symbols will be all messed up > and who know where the code will jump. Sometimes the drm/radeon pair > will still load even if an old version is in memory. > > Try a sequence like this: > [root@smirl linux-core]# insmod ./drm.ko drm_opts=debug:on > [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on > [root@smirl linux-core]# rmmod radeon > [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on > [root@smirl linux-core]# rmmod radeon > [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on > [root@smirl linux-core]# rmmod radeon > [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on > [root@smirl linux-core]# rmmod radeon > [root@smirl linux-core]# insmod ./radeon.ko drm_opts=debug:on > [root@smirl linux-core]# rmmod radeon > [root@smirl linux-core]# rmmod drm > [root@smirl linux-core]# > > This runs for me without errors. This still fails on me. I've checked on another machine, with the same kernel but different hardware and kernel configuration, and it does works fint. I don't suppose any processor-specific assembly was added to the *-core, so I'm inclined towards any conflict with this machine kernel's configuration. FYI it's an AMD K6. I'll try to backtrack in the *-core to determine when the problem happened. Any other hints to hunt this bug down? José Fonseca |
From: Jon S. <jon...@gm...> - 2004-10-11 14:53:38
|
On Mon, 11 Oct 2004 11:56:27 +0100, Jos=E9 Fonseca <jrf...@tu...> wrote: > I've checked on another machine, with the same kernel but different > hardware and kernel configuration, and it does works fint. I don't > suppose any processor-specific assembly was added to the *-core, so I'm > inclined towards any conflict with this machine kernel's configuration. > FYI it's an AMD K6. >=20 > I'll try to backtrack in the *-core to determine when the problem > happened. Any other hints to hunt this bug down? What does dmesg say? There should be some debugging data in the log. drm loads right? which personality is failing? --=20 Jon Smirl jon...@gm... |
From: F. <jrf...@tu...> - 2004-10-15 14:22:07
|
On Mon, Oct 11, 2004 at 10:52:40AM -0400, Jon Smirl wrote: > What does dmesg say? There should be some debugging data in the log. > drm loads right? which personality is failing? It doesn't say nothing and I found (partially) why: the dynamic lynking is failing, so the call to "drm_init(&pci_driver, pciidlist, &driver)" never reaches a single line of code there (no debug message, *nothing*). I still don't know how this can be (the kernel configuration, or software setup, maybe), but I'm more inclined toward a problem on my end, rather than in *-core code. I'll still try sorting this out, so that I can move on to more interesting things. José Fonseca |
From: Jon S. <jon...@gm...> - 2004-10-15 15:41:11
|
On Fri, 15 Oct 2004 15:19:41 +0100, Jos=E9 Fonseca <jrf...@tu...> wrote: > It doesn't say nothing and I found (partially) why: the dynamic lynking > is failing, so the call to "drm_init(&pci_driver, pciidlist, &driver)" > never reaches a single line of code there (no debug message, *nothing*). Could it be symbol versioning?=20 Things behave weirdly if you have an old drm module loaded and load the new ones too. You should at least get a sign on: [drm] Initialized drm 1.0.0 20040925 That the very first thing the drm module does. If you sync from CVS you need to use... insmod ./drm.ko drm_debug=3D1=20 --=20 Jon Smirl jon...@gm... |
From: F. <jrf...@tu...> - 2004-10-18 15:07:32
|
On Fri, Oct 15, 2004 at 11:40:30AM -0400, Jon Smirl wrote: > On Fri, 15 Oct 2004 15:19:41 +0100, José Fonseca > <jrf...@tu...> wrote: > > It doesn't say nothing and I found (partially) why: the dynamic lynking > > is failing, so the call to "drm_init(&pci_driver, pciidlist, &driver)" > > never reaches a single line of code there (no debug message, *nothing*). > > Could it be symbol versioning? I've diffed my two machines kernel config files and symbol versioning was one of the suspicious differences indeed, but I only managed to get everything working as expected after disabling some of those "kernel hacking" options too. > Things behave weirdly if you have an old drm module loaded and load > the new ones too. > > You should at least get a sign on: > [drm] Initialized drm 1.0.0 20040925 Yes, this message always appeared when loading drm.ko. > That the very first thing the drm module does. > > If you sync from CVS you need to use... > insmod ./drm.ko drm_debug=1 Thanks for your help. This issue is finally closed. Regards, José Fonseca |
From: Ville <sy...@sc...> - 2004-10-06 14:53:42
|
On Wed, Oct 06, 2004 at 09:53:51AM -0400, Vladimir Dergachev wrote: >=20 >=20 > On Wed, 6 Oct 2004, [iso-8859-15] Jos=E9 Fonseca wrote: >=20 > >Jon, > > > >I was trying to build and test the linux-core - I really like what > >you've been doing there - but I get endless kernel oops after insmod'i= ng > >any of the driver modules (not the common drm one though), regardless > >the specific chip is present or not. > > > >Before I search deeper into this could you let me know whether the cod= e > >in *-core is not runnable yet, or if there must be something wrong on = my > >side? >=20 > Just as a data point I was able to insert radeon module just fine on=20 > 2.6.9rc3. This was yesterday. Maybe a fresh checkout will help ? Inserting mga worked on 2.6.7 for me. Unfortunately actually using the module failed. The problem is with=20 get_order() in drm_bufs.c. After I replaced get_order() with the original= =20 drm order function things started to work. --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |
From: Jon S. <jon...@gm...> - 2004-10-06 16:14:10
|
I'll revert these to the old DRM(order). One of the kernel developers wanted this changed and now I see these functions aren't identical. -- Jon Smirl jon...@gm... |
From: Jon S. <jon...@gm...> - 2004-10-06 16:28:24
|
On Wed, 6 Oct 2004 12:14:05 -0400, Jon Smirl <jon...@gm...> wrote: > I'll revert these to the old DRM(order). One of the kernel developers > wanted this changed and now I see these functions aren't identical. This is checked in now. -- Jon Smirl jon...@gm... |