Kernel Oops in drm_set_version
I noticed some kernel oopses in DRM in my kernel log. They don't seem to be fatal as DRI is still working. This is on a machine with Vesa framebuffer. On the other box without kernel framebuffer there are no oopses. Oct 19 18:30:31 trabant kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: S3 Inc. VT8375 [ProSavage8 KM266/KL266] Oct 19 18:30:31 trabant kernel: [drm] Used old pci detect: framebuffer loaded Oct 19 18:30:31 trabant kernel: Unable to handle kernel paging request at virtual address f000e2c3 Oct 19 18:30:31 trabant kernel: printing eip: Oct 19 18:30:31 trabant kernel: cfdb2af0 Oct 19 18:30:31 trabant kernel: *pde = Oct 19 18:30:31 trabant kernel: Oops: [#1] Oct 19 18:30:31 trabant kernel: Modules linked in: savage drm ipv6 parport_pc lp parport snd_via82xx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd soundcore via_ircc ohci1394 ieee1394 joydev usbhid via_rhine mii ehci_hcd uhci_hcd usbcore via_agp agpgart Oct 19 18:30:31 trabant kernel: CPU:0 Oct 19 18:30:31 trabant kernel: EIP:0060:[pg0+261954288/1069666304]Not tainted Oct 19 18:30:31 trabant kernel: EFLAGS: 00013292 (2.6.8) Oct 19 18:30:31 trabant kernel: EIP is at drm_set_busid+0x90/0xf0 [drm] Oct 19 18:30:31 trabant kernel: eax: ebx: c9439800 ecx: edx: cfdb749c Oct 19 18:30:31 trabant kernel: esi: edi: f000e2c3 ebp: cdd25860 esp: cbd7ff08 Oct 19 18:30:31 trabant kernel: ds: 007b es: 007b ss: 0068 Oct 19 18:30:31 trabant kernel: Process Xorg (pid: 1915, threadinfo=cbd7e000 task=cea58c90) Oct 19 18:30:31 trabant kernel: Stack: cd810b20 0014 cfdb7487 0001 ba80 Oct 19 18:30:31 trabant kernel:c9439800 cbd7ff44 cfdb2e85 0001 0002 0001 0001 Oct 19 18:30:31 trabant kernel:0001 c9439800 0001 cfdb2de0 cfdb1c55 ba80 Oct 19 18:30:31 trabant kernel: Call Trace: Oct 19 18:30:31 trabant kernel: [pg0+261955205/1069666304] drm_setversion+0xa5/0xf0 [drm] Oct 19 18:30:31 trabant kernel: [pg0+261955040/1069666304] drm_setversion+0x0/0xf0 [drm] Oct 19 18:30:31 trabant kernel: [pg0+261950549/1069666304] drm_ioctl+0xe5/0x1ae [drm] Oct 19 18:30:31 trabant kernel: [do_int+167/592] do_int+0xa7/0x250 Oct 19 18:30:31 trabant kernel: [do_int+167/592] do_int+0xa7/0x250 Oct 19 18:30:31 trabant kernel: [sys_ioctl+175/496] sys_ioctl+0xaf/0x1f0 Oct 19 18:30:31 trabant kernel: [syscall_call+7/11] syscall_call+0x7/0xb Oct 19 18:30:31 trabant kernel: [do_int+167/592] do_int+0xa7/0x250 Oct 19 18:30:31 trabant kernel: Code: f2 ae f7 d1 49 03 4b 04 ba d0 00 00 00 8d 41 02 e8 7b 23 38 HTH, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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 more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel Oops in drm_set_version
The fault is in drm_set_busid. It's a NULL pointer reference. I'm not
seeing this so it may be savage specific. The only place I can see
where you could get a NULL reference is if the PCI driver didn't set a
name, dev-pdev-driver-name. Can you add a debug statement and check
if there is one? The trap looks like it is in a sprintf.
static int drm_set_busid(drm_device_t * dev)
{
if (dev-unique != NULL)
return EBUSY;
dev-unique_len = 20;
dev-unique = drm_alloc(dev-unique_len + 1, DRM_MEM_DRIVER);
if (dev-unique == NULL)
return ENOMEM;
snprintf(dev-unique, dev-unique_len, pci:%04x:%02x:%02x.%d,
dev-pci_domain, dev-pci_bus, dev-pci_slot, dev-pci_func);
dev-devname = drm_alloc(strlen(dev-pdev-driver-name) + dev-unique_len + 2,
DRM_MEM_DRIVER);
if (dev-devname == NULL)
return ENOMEM;
sprintf(dev-devname, [EMAIL PROTECTED], dev-pdev-driver-name,
dev-unique);
return 0;
}
--
Jon Smirl
[EMAIL PROTECTED]
---
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 more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel Oops in drm_set_version
What do I have to do to X to make it call set_busid? It's not getting called in my config. -- Jon Smirl [EMAIL PROTECTED] --- 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 more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel Oops in drm_set_version
Am Di, den 19.10.2004 schrieb Jon Smirl um 20:11:
The fault is in drm_set_busid. It's a NULL pointer reference. I'm not
seeing this so it may be savage specific. The only place I can see
where you could get a NULL reference is if the PCI driver didn't set a
name, dev-pdev-driver-name. Can you add a debug statement and check
if there is one? The trap looks like it is in a sprintf.
I added these debug statements:
printk(KERN_ERR dev = %p\n, dev);
printk(KERN_ERR dev-pdev = %p\n, dev-pdev);
printk(KERN_ERR dev-pdev-driver = %p\n, dev-pdev-driver);
printk(KERN_ERR dev-pdev-driver-name = %p\n, dev-pdev-driver-name);
This is the output:
dev = c9438800
dev-pdev = cee8c400
dev-pdev-driver =
dev-pdev-driver-name = f000e2c3
Funny thing is that it doesn't complain about the NULL-pointer
reference. It complains about:
Unable to handle kernel paging request at virtual address f000e2c3
The real problem is that dev-pdev-driver is NULL.
drm_set_busid is called if the minor interface version is = 1. This
interface version is requested by the common DRI code in the Xserver.
This in turn depends on the available libdrm version (quoting
xc/programs/Xserver/GL/dri/dri.c):
if (drmlibmajor == 1 drmlibminor = 2) {
drmSetVersion sv;
/* Get the interface version, asking for 1.1. */
sv.drm_di_major = 1;
sv.drm_di_minor = 1;
sv.drm_dd_major = -1;
err = drmSetInterfaceVersion(pDRIPriv-drmFD, sv);
if (err == 0) {
drmdimajor = sv.drm_di_major;
drmdiminor = sv.drm_di_minor;
} else {
/* failure, so set it to 1.0.0. */
drmdimajor = 1;
drmdiminor = 0;
}
}
else {
/* We can't check the DI DRM interface version, so set it to 1.0.0. */
drmdimajor = 1;
drmdiminor = 0;
}
Are you using an up-to-date libdrm for testing?
BTW, I noticed one small thing in drm_set_version that looks like a
typo:
if_version = DRM_IF_VERSION(sv.drm_di_major, sv.drm_dd_minor);
-^ -^
Does it make sense to mix driver and interface versions? Shouldn't it
be:
if_version = DRM_IF_VERSION(sv.drm_di_major, sv.drm_di_minor);
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
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 more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel Oops in drm_set_version
Does this fix it for you? I haven't figured out how to trigger it yet.
[EMAIL PROTECTED] drm-bk]$ bk -r diffs -u
= linux-core/drm_drv.c 1.11 vs edited =
--- 1.11/linux-core/drm_drv.c 2004-10-18 22:58:26 -04:00
+++ edited/linux-core/drm_drv.c 2004-10-20 00:33:20 -04:00
@@ -329,6 +329,8 @@
pid-subvendor, pid-subdevice,
pdev))) {
/* stealth mode requires a manual probe */
+ if (!pdev-driver)
+ pdev-driver = driver-pci_driver;
pci_dev_get(pdev);
drm_get_dev(pdev, pciidlist[i], driver);
}
[EMAIL PROTECTED] drm-bk]$ bk -r diffs -u ../patch
[EMAIL PROTECTED] drm-bk]$
--
Jon Smirl
[EMAIL PROTECTED]
---
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 more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel Oops in drm_set_version
On Wed, 20 Oct 2004 00:40:07 -0400, Jon Smirl [EMAIL PROTECTED] wrote: Does this fix it for you? I haven't figured out how to trigger it yet. I think the problem here is that vesafb is not attached as a true device driver but it has the resources allocated. DRM comes along and see vesafb so it goes into stealth mode. In stealth mode DRM does not attach as a true driver either. So now we have the pci device in use without a driver attached. The answer here is that because of stealth mode I can't rely on the pointer pdev-driver-name to get the driver name. It may be null in the case of fbdev and xxxfb for an fbdev driver. I need to make a different pointer for recording the driver name. -- Jon Smirl [EMAIL PROTECTED] --- 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 more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel Oops in drm_set_version
I checked in a fix that switches from dev-pdev-driver-name to drm-driver-pci_driver.name This should fix the segfaults in stealth mode when the pci driver is set to the wrong driver (fbdev) or no driver (vesafb). Please give it a try. -- Jon Smirl [EMAIL PROTECTED] --- 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 more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
