Bug 9301 - FreeBSD system locks up with DRI enabled on Radeon RS300
Summary: FreeBSD system locks up with DRI enabled on Radeon RS300
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/other (show other bugs)
Version: DRI git
Hardware: x86 (IA32) FreeBSD
: high normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-11 00:46 UTC by Yong-Jhen Hong
Modified: 2013-03-15 14:26 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
drm debug message from syslog (7.42 KB, text/plain)
2006-12-11 00:49 UTC, Yong-Jhen Hong
no flags Details
X.org server log when system locks up (44.17 KB, text/plain)
2006-12-12 08:27 UTC, Yong-Jhen Hong
no flags Details
X.org server log with PCI mode (50.10 KB, text/plain)
2006-12-12 16:27 UTC, Yong-Jhen Hong
no flags Details
drm syslog with PCI mode (14.30 KB, text/plain)
2006-12-12 16:28 UTC, Yong-Jhen Hong
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yong-Jhen Hong 2006-12-11 00:46:29 UTC
On a Shuttle "Zen" XPC ST62K with ATI Radeon 9100 IGP (RS300),
X.org server with DRI enabled causes system lockup.
It runs fine when DRI is disabled.

OS: FreeBSD 6.2-RC1
libdrm: version 2.3.0
xorg-server: version 1.1.99.903, with AIGLX disabled
drm: latest version from git repo (mesa/drm, 1 Dec 2006 10:00:32 +0000)
xf86-video-ati: latest version from git repo (xorg/driver/xf86-video-ati, 8 Dec
2006 01:51:52 +0000)

From dmesg:
drm0: <ATI Radeon RS300 9100 IGP> port 0xc000-0xc0ff mem
0xe8000000-0xebffffff,0xec020000-0xec02ffff irq 16 at device 5.0 on pci1
[drm:pid0:drm_load]
[drm:pid0:radeon_driver_load] AGP card detected
[drm:pid0:drm_agp_init] agp_available = 1
info: [drm] AGP at 0xe0000000 128MB
[drm:pid0:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:pid0:drm_ctxbitmap_init] drm_ctxbitmap_init : 0
info: [drm] Initialized radeon 1.25.0 20060524
Comment 1 Yong-Jhen Hong 2006-12-11 00:49:54 UTC
Created attachment 8054 [details]
drm debug message from syslog
Comment 2 Roland Scheidegger 2006-12-11 04:12:31 UTC
Could you also attach your xorg log when it locked up?
Comment 3 Yong-Jhen Hong 2006-12-11 08:22:25 UTC
(In reply to comment #2)
> Could you also attach your xorg log when it locked up?

Sorry I cannot do it because it is empty.
Comment 4 Roland Scheidegger 2006-12-11 08:37:09 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Could you also attach your xorg log when it locked up?
> 
> Sorry I cannot do it because it is empty.
If that's because of the crash try mounting the partition where it is with the
sync option. If it's always empty there is something wrong with your setupl...

Comment 5 Yong-Jhen Hong 2006-12-12 08:27:00 UTC
Created attachment 8069 [details]
X.org server log when system locks up

Finally got the log after tuning off soft-updates and mounting with sync option
to the device.
Comment 6 Roland Scheidegger 2006-12-12 09:21:48 UTC
I can't see anything unusual in the log. Seems to blow up when initializing the
cp. Could you provide the drm debug messages when mounted with sync? I think
there should be some more. Not sure if it would reveal anything interesting, but
it's worth a try.
Comment 7 Yong-Jhen Hong 2006-12-12 09:35:20 UTC
(In reply to comment #6)
> I can't see anything unusual in the log. Seems to blow up when initializing the
> cp. Could you provide the drm debug messages when mounted with sync? I think
> there should be some more. Not sure if it would reveal anything interesting, but
> it's worth a try.

It it exactly the same from the one I posted earlier, unfortunately.
Except for PID and some differences on addresses.
Comment 8 Yong-Jhen Hong 2006-12-12 10:56:16 UTC
After some tracing, I find it hangs on:

radeon_dri.c:
 RADEONDRIKernelInit():
  drmCommandWrite(info->drmFD, DRM_RADEON_CP_INIT, &drmInfo, sizeof(drmRadeonInit))

Should I provide all the fields in drmInfo?
Comment 9 Roland Scheidegger 2006-12-12 15:23:11 UTC
(In reply to comment #8)
> After some tracing, I find it hangs on:
> 
> radeon_dri.c:
>  RADEONDRIKernelInit():
>   drmCommandWrite(info->drmFD, DRM_RADEON_CP_INIT, &drmInfo,
sizeof(drmRadeonInit))
yup, that's what I meant with the cp init... (it should cause some more drm
messages, maybe syslog doesn't write them instantly to the log file)

> Should I provide all the fields in drmInfo?
I think it's almost impossible those are wrong. Is this a regression? You could
try with an older driver. Some people also had trouble with AGP, so you could
try pci mode (Option "BusType" "PCI").  Also, is the ram amount (and width - not
sure if this has to match in igp case) correctly detected (should match what
you've configured in bios). Could also be an issue with the memory maps - though
I think benh really fixed that up...

Comment 10 Yong-Jhen Hong 2006-12-12 16:27:07 UTC
Created attachment 8076 [details]
X.org server log with PCI mode

It works with PCI mode.
Comment 11 Yong-Jhen Hong 2006-12-12 16:28:31 UTC
Created attachment 8077 [details]
drm syslog with PCI mode
Comment 12 Roland Scheidegger 2006-12-13 04:36:43 UTC
(In reply to comment #10)
> It works with PCI mode.
Hmm. Another one of those cases. I wonder what's up with that. Could be problem
with setting up agp map (seems unlikely), asic bug needing workaround (like
forcing AIC clock on), no idea :-(.

Comment 13 Roland Scheidegger 2006-12-13 10:08:29 UTC
Hmm, could you try what was suggested here:
https://bugs.freedesktop.org/show_bug.cgi?id=9284
Comment 14 Yong-Jhen Hong 2006-12-14 08:23:57 UTC
(In reply to comment #13)
> Hmm, could you try what was suggested here:
> https://bugs.freedesktop.org/show_bug.cgi?id=9284

I tried the "AGPMode" option with values 8, 4, 2, and 1,
but still got the lock-ups at the same place with no luck.
Comment 15 chemtech 2013-03-15 14:26:43 UTC
Yong-Jhen Hong 
Do you still experience this issue with newer soft ?
Please check the status of your issue.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.