Re: sysfs_remove_dir bug?
On Tue, Jun 28, 2005 at 12:09:52PM +1000, Benjamin Herrenschmidt wrote: On Fri, 2005-06-24 at 09:58 -0400, Jon Smirl wrote: On 6/24/05, Jon Smirl [EMAIL PROTECTED] wrote: I'm update with your changes this morning. I'm still seeing this at system shutdown. I modprobe drm,radeon and then unloaded them (no errors) then shut the system down. With some more experiments, it only happens with radeonfb loaded. You also have to leave drm/radeon loaded when rebooting. If you rmmod them reboot is ok. It is starting to look like something is not right in kernel support for sysdev devices in loadable drivers. As I said earlier, using a sysdev for DRM is bogus anyway. On ppc at least, it will probably break sleep/wakeup since by the time the sysdev suspend routine will be called, the video chip will be in D2 or D3 state. O.k. I've yanked the code from CVS for this now, as I don't want to pollute things if they're not going to work properly. Is anyone working on a stub driver ?? Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On 6/28/05, Alan Hourihane [EMAIL PROTECTED] wrote: O.k. I've yanked the code from CVS for this now, as I don't want to pollute things if they're not going to work properly. Is anyone working on a stub driver ?? While you wait on the great stub debate to be settled (it has been going on for about 18 months with no action) why not simply fix intelfb to work right on the i915? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
Is anyone working on a stub driver ?? While you wait on the great stub debate to be settled (it has been going on for about 18 months with no action) why not simply fix intelfb to work right on the i915? I've said this before I think, but intelfb is very broken, apart from the fact it can't modeset on anything but single CRT case... I've got a start on a basic stub driver I might get a run at it this weekend to make it actually work... I'm going to do both radeon and intel as the issues so far have been mainly to do with not thinking about other use cases... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
I can also predict the probable outcome on kernel submission if we use the stub to start building suspend/resume in two different places - DRM and fbdev. My stub isn't your totally fb in the stub, we are only going to put initially interrupt handling, suspend/resume, PCI driver handling and some arbitration into the stub... this is similiar to what was going into the vga class stuff before, myself and benh have been talking this over and believe there is no point having mode setting or monitor detection in a lowlevel stub, You cannot do intelfb modesetting in the kernel, it needs VBE calls no-one is going to put those near the kernel hopefully... I'm trying to decide if the stub framework is worth the hassle of making generic or whether doing it for each driver is probably less trouble... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On 6/28/05, Dave Airlie [EMAIL PROTECTED] wrote: I can also predict the probable outcome on kernel submission if we use the stub to start building suspend/resume in two different places - DRM and fbdev. My stub isn't your totally fb in the stub, we are only going to put initially interrupt handling, suspend/resume, PCI driver handling and some arbitration into the stub... this is similiar to what was going into the vga class stuff before, myself and benh have been talking this over and believe there is no point having mode setting or monitor detection in a lowlevel stub, I'm starting to think that a stub is a really bad idea. It is going to make it easier to build multiple implementations of the same features in the different drivers. The net result will probably be an increase in the architectural chaos of video drivers. You cannot do intelfb modesetting in the kernel, it needs VBE calls no-one is going to put those near the kernel hopefully... The callgate for getting to mode setting has to be in the kernel. That provides a standard API and a secure user-root transition. After the call is in the kernel each driver can choose to satisfy the call in-kernel or use something like call_userhelper() to do the work in user space. I'm trying to decide if the stub framework is worth the hassle of making generic or whether doing it for each driver is probably less trouble... -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
The callgate for getting to mode setting has to be in the kernel. That provides a standard API and a secure user-root transition. After the call is in the kernel each driver can choose to satisfy the call in-kernel or use something like call_userhelper() to do the work in user space. As I explained already, I think it should be a userland daemon, that's really the best way to deal with access control and would fix all of the issues. Ben. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On 6/28/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: The callgate for getting to mode setting has to be in the kernel. That provides a standard API and a secure user-root transition. After the call is in the kernel each driver can choose to satisfy the call in-kernel or use something like call_userhelper() to do the work in user space. As I explained already, I think it should be a userland daemon, that's really the best way to deal with access control and would fix all of the issues. How do I communicate my desired mode to the daemon? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On Tue, 2005-06-28 at 20:13 -0400, Jon Smirl wrote: On 6/28/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: The callgate for getting to mode setting has to be in the kernel. That provides a standard API and a secure user-root transition. After the call is in the kernel each driver can choose to satisfy the call in-kernel or use something like call_userhelper() to do the work in user space. As I explained already, I think it should be a userland daemon, that's really the best way to deal with access control and would fix all of the issues. How do I communicate my desired mode to the daemon? We have to define an interface of course. The protocol there could go over a unix socket I suppose. Ben. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On Fri, 2005-06-24 at 09:58 -0400, Jon Smirl wrote: On 6/24/05, Jon Smirl [EMAIL PROTECTED] wrote: I'm update with your changes this morning. I'm still seeing this at system shutdown. I modprobe drm,radeon and then unloaded them (no errors) then shut the system down. With some more experiments, it only happens with radeonfb loaded. You also have to leave drm/radeon loaded when rebooting. If you rmmod them reboot is ok. It is starting to look like something is not right in kernel support for sysdev devices in loadable drivers. As I said earlier, using a sysdev for DRM is bogus anyway. On ppc at least, it will probably break sleep/wakeup since by the time the sysdev suspend routine will be called, the video chip will be in D2 or D3 state. Ben. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On 6/24/05, Jon Smirl [EMAIL PROTECTED] wrote: I'm update with your changes this morning. I'm still seeing this at system shutdown. I modprobe drm,radeon and then unloaded them (no errors) then shut the system down. With some more experiments, it only happens with radeonfb loaded. You also have to leave drm/radeon loaded when rebooting. If you rmmod them reboot is ok. It is starting to look like something is not right in kernel support for sysdev devices in loadable drivers. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
sysfs_remove_dir bug?
From bug 3609: I don't think this is via specific. Anybody that has a clue? kernel BUG at include/linux/dcache.h:294! invalid operand: [#1] PREEMPT Modules linked in: via drm nsc_ircc snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq parport_pc parport psmouse pcspkr snd_via82xx gameport snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_ircc irda acerhk amd64_agp agpgart eth1394 sata_via sata_svw libata sbp2 ohci1394 ieee1394 usb_storage usbhid CPU:0 EIP:0060:[c019d25c]Not tainted VLI EFLAGS: 00213246 (2.6.12-gentoo) EIP is at sysfs_remove_dir+0xfc/0x110 eax: ebx: db5aaf30 ecx: edx: ddf6f280 esi: db5aa800 edi: db891d14 ebp: dc5c16c0 esp: dac0de94 ds: 007b es: 007b ss: 0068 Process X (pid: 12235, threadinfo=dac0c000 task=db1835a0) Stack: dc62c9c0 dce3783a c04faea0 db5aaf30 db5aa800 dc62c940 dc5c16c0 c0300670 db5aaf30 db5aaf30 c03006a0 db5aaf30 0002 dc62cb20 df03d72d db5aaf30 dbb71380 df03e3a8 00203282 dac0c000 db5aa800 ddf64c80 Call Trace: [c0300670] kobject_del+0x10/0x20 [c03006a0] kobject_unregister+0x20/0x30 [df03d72d] drm_takedown+0x34d/0x3f0 [drm] [df03e3a8] drm_fasync+0x48/0x90 [drm] [df03e7c5] drm_release+0x3d5/0x540 [drm] [df03d950] drm_version+0x0/0xa0 [drm] [df03dbb3] drm_ioctl+0x1c3/0x23c [drm] [c0246400] udf_create+0x30/0x1b0 [df03d950] drm_version+0x0/0xa0 [drm] [c0246400] udf_create+0x30/0x1b0 [c0172cb7] do_ioctl+0x77/0xb0 [c015f58a] __fput+0x16a/0x1b0 [c015d942] filp_close+0x52/0xa0 [c015d9e8] sys_close+0x58/0xa0 [c010325b] sysenter_past_esp+0x54/0x75 Code: 89 44 24 08 8b 00 89 04 24 e8 c1 a9 fa ff 8b 54 24 08 8b 42 04 89 04 24 e8 32 35 16 00 8b 44 24 08 89 04 24 e8 a6 a9 fa ff eb 93 0f 0b 26 01 a2 94 49 c0 e9 17 ff ff ff 8d b4 26 00 00 00 00 83 /Thomas --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
Something in CVS is corrupting memory and causing various failures. My suspicion it is related to the power management code but I haven't been able to track it down. It is possible that this is related. On 6/23/05, Thomas Hellström [EMAIL PROTECTED] wrote: From bug 3609: I don't think this is via specific. Anybody that has a clue? kernel BUG at include/linux/dcache.h:294! invalid operand: [#1] PREEMPT Modules linked in: via drm nsc_ircc snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq parport_pc parport psmouse pcspkr snd_via82xx gameport snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_ircc irda acerhk amd64_agp agpgart eth1394 sata_via sata_svw libata sbp2 ohci1394 ieee1394 usb_storage usbhid CPU:0 EIP:0060:[c019d25c]Not tainted VLI EFLAGS: 00213246 (2.6.12-gentoo) EIP is at sysfs_remove_dir+0xfc/0x110 eax: ebx: db5aaf30 ecx: edx: ddf6f280 esi: db5aa800 edi: db891d14 ebp: dc5c16c0 esp: dac0de94 ds: 007b es: 007b ss: 0068 Process X (pid: 12235, threadinfo=dac0c000 task=db1835a0) Stack: dc62c9c0 dce3783a c04faea0 db5aaf30 db5aa800 dc62c940 dc5c16c0 c0300670 db5aaf30 db5aaf30 c03006a0 db5aaf30 0002 dc62cb20 df03d72d db5aaf30 dbb71380 df03e3a8 00203282 dac0c000 db5aa800 ddf64c80 Call Trace: [c0300670] kobject_del+0x10/0x20 [c03006a0] kobject_unregister+0x20/0x30 [df03d72d] drm_takedown+0x34d/0x3f0 [drm] [df03e3a8] drm_fasync+0x48/0x90 [drm] [df03e7c5] drm_release+0x3d5/0x540 [drm] [df03d950] drm_version+0x0/0xa0 [drm] [df03dbb3] drm_ioctl+0x1c3/0x23c [drm] [c0246400] udf_create+0x30/0x1b0 [df03d950] drm_version+0x0/0xa0 [drm] [c0246400] udf_create+0x30/0x1b0 [c0172cb7] do_ioctl+0x77/0xb0 [c015f58a] __fput+0x16a/0x1b0 [c015d942] filp_close+0x52/0xa0 [c015d9e8] sys_close+0x58/0xa0 [c010325b] sysenter_past_esp+0x54/0x75 Code: 89 44 24 08 8b 00 89 04 24 e8 c1 a9 fa ff 8b 54 24 08 8b 42 04 89 04 24 e8 32 35 16 00 8b 44 24 08 89 04 24 e8 a6 a9 fa ff eb 93 0f 0b 26 01 a2 94 49 c0 e9 17 ff ff ff 8d b4 26 00 00 00 00 83 /Thomas --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
Someone has logged a bug (#3549) that might be the cause. I've just not had time to investigate this yet. If no-one beats me to it, I'll take a look early next week. Alan. On Thu, Jun 23, 2005 at 04:45:48PM -0400, Jon Smirl wrote: Something in CVS is corrupting memory and causing various failures. My suspicion it is related to the power management code but I haven't been able to track it down. It is possible that this is related. On 6/23/05, Thomas Hellström [EMAIL PROTECTED] wrote: From bug 3609: I don't think this is via specific. Anybody that has a clue? kernel BUG at include/linux/dcache.h:294! invalid operand: [#1] PREEMPT Modules linked in: via drm nsc_ircc snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq parport_pc parport psmouse pcspkr snd_via82xx gameport snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_ircc irda acerhk amd64_agp agpgart eth1394 sata_via sata_svw libata sbp2 ohci1394 ieee1394 usb_storage usbhid CPU:0 EIP:0060:[c019d25c]Not tainted VLI EFLAGS: 00213246 (2.6.12-gentoo) EIP is at sysfs_remove_dir+0xfc/0x110 eax: ebx: db5aaf30 ecx: edx: ddf6f280 esi: db5aa800 edi: db891d14 ebp: dc5c16c0 esp: dac0de94 ds: 007b es: 007b ss: 0068 Process X (pid: 12235, threadinfo=dac0c000 task=db1835a0) Stack: dc62c9c0 dce3783a c04faea0 db5aaf30 db5aa800 dc62c940 dc5c16c0 c0300670 db5aaf30 db5aaf30 c03006a0 db5aaf30 0002 dc62cb20 df03d72d db5aaf30 dbb71380 df03e3a8 00203282 dac0c000 db5aa800 ddf64c80 Call Trace: [c0300670] kobject_del+0x10/0x20 [c03006a0] kobject_unregister+0x20/0x30 [df03d72d] drm_takedown+0x34d/0x3f0 [drm] [df03e3a8] drm_fasync+0x48/0x90 [drm] [df03e7c5] drm_release+0x3d5/0x540 [drm] [df03d950] drm_version+0x0/0xa0 [drm] [df03dbb3] drm_ioctl+0x1c3/0x23c [drm] [c0246400] udf_create+0x30/0x1b0 [df03d950] drm_version+0x0/0xa0 [drm] [c0246400] udf_create+0x30/0x1b0 [c0172cb7] do_ioctl+0x77/0xb0 [c015f58a] __fput+0x16a/0x1b0 [c015d942] filp_close+0x52/0xa0 [c015d9e8] sys_close+0x58/0xa0 [c010325b] sysenter_past_esp+0x54/0x75 Code: 89 44 24 08 8b 00 89 04 24 e8 c1 a9 fa ff 8b 54 24 08 8b 42 04 89 04 24 e8 32 35 16 00 8b 44 24 08 89 04 24 e8 a6 a9 fa ff eb 93 0f 0b 26 01 a2 94 49 c0 e9 17 ff ff ff 8d b4 26 00 00 00 00 83 /Thomas --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
