If I enable CONFIG_DRM_RADEON under 2.6.25-rc3 then starting up
X using the xf86-video-ati driver (6.8.0 or latest git) causes the
machine to become unresponsive; while it still pings and will accept
incoming connections they never actually complete and it's not possible
to login over a serial console (the actual video console doesn't display
anything and the monitor reports a loss of sync).
Disabling the kernel DRM option results in X running successfully.
Likewise 2.6.24 works fine with DRM enabled, presumably because the
support for the RS690 was only added in 2.6.25-rc
The last messages from the kernel before it becomes unresponsive are:
[drm] Setting GART location based on new memory map
[drm] Loading R300 Microcode
[drm] writeback test succeeded in 1 usecs
The motherboard in question is an ASUS M2A-VM HDMI, with the analog VGA
output being used. The machine is running an AMD64 with Debian unstable.
I have put the output of lspci, a non drm Xorg.log and a drm Xorg.log
at:
http://the.earth.li/~noodles/xorg-ati-drm/lspci
http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-nodrm
http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-drm
If I can provide any more useful information please let me know.
J.
--
I get the feeling that I've been | .''`. Debian GNU/Linux Developer
cheated. | : :' : Happy to accept PGP signed
| `. `' or encrypted mail - RSA +
| `- DSA keys on the keyservers.
On Sat, Mar 1, 2008 at 2:35 PM, Jonathan McDowell <[email protected]> wrote:
> If I enable CONFIG_DRM_RADEON under 2.6.25-rc3 then starting up
> X using the xf86-video-ati driver (6.8.0 or latest git) causes the
> machine to become unresponsive; while it still pings and will accept
> incoming connections they never actually complete and it's not possible
> to login over a serial console (the actual video console doesn't display
> anything and the monitor reports a loss of sync).
>
> Disabling the kernel DRM option results in X running successfully.
> Likewise 2.6.24 works fine with DRM enabled, presumably because the
> support for the RS690 was only added in 2.6.25-rc
>
> The last messages from the kernel before it becomes unresponsive are:
>
> [drm] Setting GART location based on new memory map
> [drm] Loading R300 Microcode
> [drm] writeback test succeeded in 1 usecs
>
> The motherboard in question is an ASUS M2A-VM HDMI, with the analog VGA
> output being used. The machine is running an AMD64 with Debian unstable.
> I have put the output of lspci, a non drm Xorg.log and a drm Xorg.log
> at:
>
> http://the.earth.li/~noodles/xorg-ati-drm/lspci
> http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-nodrm
> http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-drm
>
> If I can provide any more useful information please let me know.
Unfortunately, drm support on recent IGP chips is a little shaky at
the moment. In some cases it helps to change the bios vram options to
a fixed vram size rather than setting it to "auto".
Alex
On Sat, 1 Mar 2008 19:35:11 +0000 Jonathan McDowell <[email protected]> wrote:
> If I enable CONFIG_DRM_RADEON under 2.6.25-rc3 then starting up
> X using the xf86-video-ati driver (6.8.0 or latest git) causes the
> machine to become unresponsive; while it still pings and will accept
> incoming connections they never actually complete and it's not possible
> to login over a serial console (the actual video console doesn't display
> anything and the monitor reports a loss of sync).
>
> Disabling the kernel DRM option results in X running successfully.
> Likewise 2.6.24 works fine with DRM enabled, presumably because the
> support for the RS690 was only added in 2.6.25-rc
>
> The last messages from the kernel before it becomes unresponsive are:
>
> [drm] Setting GART location based on new memory map
> [drm] Loading R300 Microcode
> [drm] writeback test succeeded in 1 usecs
>
> The motherboard in question is an ASUS M2A-VM HDMI, with the analog VGA
> output being used. The machine is running an AMD64 with Debian unstable.
> I have put the output of lspci, a non drm Xorg.log and a drm Xorg.log
> at:
>
> http://the.earth.li/~noodles/xorg-ati-drm/lspci
> http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-nodrm
> http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-drm
>
> If I can provide any more useful information please let me know.
>
Did 2.6.24 work OK with all the same userspace software?
On Mon, 3 Mar 2008, Andrew Morton wrote:
> On Sat, 1 Mar 2008 19:35:11 +0000 Jonathan McDowell <[email protected]> wrote:
>
> > If I enable CONFIG_DRM_RADEON under 2.6.25-rc3 then starting up
> > X using the xf86-video-ati driver (6.8.0 or latest git) causes the
> > machine to become unresponsive; while it still pings and will accept
> > incoming connections they never actually complete and it's not possible
> > to login over a serial console (the actual video console doesn't display
> > anything and the monitor reports a loss of sync).
> >
> > Disabling the kernel DRM option results in X running successfully.
> > Likewise 2.6.24 works fine with DRM enabled, presumably because the
> > support for the RS690 was only added in 2.6.25-rc
> >
> > The last messages from the kernel before it becomes unresponsive are:
> >
> > [drm] Setting GART location based on new memory map
> > [drm] Loading R300 Microcode
> > [drm] writeback test succeeded in 1 usecs
> >
> > The motherboard in question is an ASUS M2A-VM HDMI, with the analog VGA
> > output being used. The machine is running an AMD64 with Debian unstable.
> > I have put the output of lspci, a non drm Xorg.log and a drm Xorg.log
> > at:
> >
> > http://the.earth.li/~noodles/xorg-ati-drm/lspci
> > http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-nodrm
> > http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-drm
> >
> > If I can provide any more useful information please let me know.
> >
>
> Did 2.6.24 work OK with all the same userspace software?
>
We haven't actually released any userspace software properly yet, its all
experimental at this point until we debug the hardware some more..
Dave.
On Tue, Mar 04, 2008 at 08:16:49AM +0000, Dave Airlie wrote:
> On Mon, 3 Mar 2008, Andrew Morton wrote:
> > On Sat, 1 Mar 2008 19:35:11 +0000 Jonathan McDowell <[email protected]>
> > wrote:
> >
> > > If I enable CONFIG_DRM_RADEON under 2.6.25-rc3 then starting up
> > > X using the xf86-video-ati driver (6.8.0 or latest git) causes the
> > > machine to become unresponsive; while it still pings and will accept
> > > incoming connections they never actually complete and it's not possible
> > > to login over a serial console (the actual video console doesn't display
> > > anything and the monitor reports a loss of sync).
> > >
> > > Disabling the kernel DRM option results in X running successfully.
> > > Likewise 2.6.24 works fine with DRM enabled, presumably because the
> > > support for the RS690 was only added in 2.6.25-rc
> > >
> > > The last messages from the kernel before it becomes unresponsive are:
> > >
> > > [drm] Setting GART location based on new memory map
> > > [drm] Loading R300 Microcode
> > > [drm] writeback test succeeded in 1 usecs
> > >
> > > The motherboard in question is an ASUS M2A-VM HDMI, with the analog VGA
> > > output being used. The machine is running an AMD64 with Debian unstable.
> > > I have put the output of lspci, a non drm Xorg.log and a drm Xorg.log
> > > at:
> > >
> > > http://the.earth.li/~noodles/xorg-ati-drm/lspci
> > > http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-nodrm
> > > http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-drm
> > >
> > > If I can provide any more useful information please let me know.
> > >
> >
> > Did 2.6.24 work OK with all the same userspace software?
> >
> We haven't actually released any userspace software properly yet, its all
> experimental at this point until we debug the hardware some more..
Is xf86-driver-ati 6.8.0 not a proper release? I'm pretty sure the
combination of that, 2.6.25-rc3 and CONFIG_DRM_RADEON causes my machine
to become unresponsive. I only tried a git build of the driver after the
released version was causing issues.
Replacing 2.6.25-rc3 with 2.6.24 (still with CONFIG_DRM_RADEON enabled)
results in a machine that boots to GDM successfully. Likewise if I
disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM ok.
J.
--
jid: [email protected]
101 things you can't have too much of : 42
- Pepsi.
On Tue, 4 Mar 2008 08:51:55 +0000 Jonathan McDowell <[email protected]> wrote:
> On Tue, Mar 04, 2008 at 08:16:49AM +0000, Dave Airlie wrote:
> > On Mon, 3 Mar 2008, Andrew Morton wrote:
> > > On Sat, 1 Mar 2008 19:35:11 +0000 Jonathan McDowell <[email protected]>
> > > wrote:
> > >
> > > > If I enable CONFIG_DRM_RADEON under 2.6.25-rc3 then starting up
> > > > X using the xf86-video-ati driver (6.8.0 or latest git) causes the
> > > > machine to become unresponsive; while it still pings and will accept
> > > > incoming connections they never actually complete and it's not possible
> > > > to login over a serial console (the actual video console doesn't display
> > > > anything and the monitor reports a loss of sync).
> > > >
> > > > Disabling the kernel DRM option results in X running successfully.
> > > > Likewise 2.6.24 works fine with DRM enabled, presumably because the
> > > > support for the RS690 was only added in 2.6.25-rc
> > > >
> > > > The last messages from the kernel before it becomes unresponsive are:
> > > >
> > > > [drm] Setting GART location based on new memory map
> > > > [drm] Loading R300 Microcode
> > > > [drm] writeback test succeeded in 1 usecs
> > > >
> > > > The motherboard in question is an ASUS M2A-VM HDMI, with the analog VGA
> > > > output being used. The machine is running an AMD64 with Debian unstable.
> > > > I have put the output of lspci, a non drm Xorg.log and a drm Xorg.log
> > > > at:
> > > >
> > > > http://the.earth.li/~noodles/xorg-ati-drm/lspci
> > > > http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-nodrm
> > > > http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-drm
> > > >
> > > > If I can provide any more useful information please let me know.
> > > >
> > >
> > > Did 2.6.24 work OK with all the same userspace software?
> > >
> > We haven't actually released any userspace software properly yet, its all
> > experimental at this point until we debug the hardware some more..
>
> Is xf86-driver-ati 6.8.0 not a proper release? I'm pretty sure the
> combination of that, 2.6.25-rc3 and CONFIG_DRM_RADEON causes my machine
> to become unresponsive. I only tried a git build of the driver after the
> released version was causing issues.
This:
> Replacing 2.6.25-rc3 with 2.6.24 (still with CONFIG_DRM_RADEON enabled)
> results in a machine that boots to GDM successfully. Likewise if I
> disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM ok.
is what we wanted to know, thanks. Surely it's a plain old regression?
> > results in a machine that boots to GDM successfully. Likewise if I
> > disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM ok.
>
> is what we wanted to know, thanks. Surely it's a plain old regression?
Nope, its a userspace driver problem.. we have not released
non-experimental code for that chipset, so its not surprising it fails
when the kernel code gets run, but the fix most likely is in userspace not
in the kernel.
I could disable the userspace DRI code but then where would I find my
testers .. if he reads his Xorg log it says DRI is experimental on rs690
and not to come crying..
this is the problem with adding new chipsets, I either wait for 6 months
for all the bugs to get kicked out so nobody wins, or I push it upstream
so most people win, I could back this out of the kernel, but experimental
userspace code isn't a reason for this..
Dave.
On Tue, Mar 04, 2008 at 09:24:08AM +0000, Dave Airlie wrote:
> > > results in a machine that boots to GDM successfully. Likewise if I
> > > disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM
> > > ok.
> >
> > is what we wanted to know, thanks. Surely it's a plain old
> > regression?
>
> Nope, its a userspace driver problem.. we have not released
> non-experimental code for that chipset, so its not surprising it fails
> when the kernel code gets run, but the fix most likely is in userspace
> not in the kernel.
>
> I could disable the userspace DRI code but then where would I find my
> testers .. if he reads his Xorg log it says DRI is experimental on
> rs690 and not to come crying..
If you accuse your testers of coming crying when they report issues then
you'll find less of them bother coming forward. I've worked round the
problem locally by disabling the kernel DRM support and was reporting
the issue:
*) So that other people would know there was a problem and might be able
to avoid it.
and
*) In case there was anything I could try out that might help to get the
problem fixed going forward.
I understand the support for the RS690 is experimental; I'm very pleased
to see it at all in the Free xorg driver. I've also been able to ditch
the fglrx driver on my work machine (which has an X1300 running dual
head). Please don't think I'm unappreciative of your work; if I was I
wouldn't have bothered trying to improve things by reporting my issue.
(I can make the X server crash by trying to use Xv as well; I assume
there's no point in reporting that somewhere?)
> this is the problem with adding new chipsets, I either wait for 6
> months for all the bugs to get kicked out so nobody wins, or I push it
> upstream so most people win, I could back this out of the kernel, but
> experimental userspace code isn't a reason for this..
Perhaps rather than just automatically enabling the new experimental
support in the kernel there needs to be a CONFIG_DRM_RADEON_EXPERIMENTAL
option or similar to enable support for chipsets that aren't believed to
be stable?
J.
--
/-\ | I'm from the government. I'm here
|@/ Debian GNU/Linux Developer | to help you.
\- |
>
> Is xf86-driver-ati 6.8.0 not a proper release? I'm pretty sure the
> combination of that, 2.6.25-rc3 and CONFIG_DRM_RADEON causes my machine
> to become unresponsive. I only tried a git build of the driver after the
> released version was causing issues.
Yes we made a mistake with 6.8.0 enabling DRI on rs680 chips before we
knew it worked for everyone, I may be still able to fix this in the kernel
but there is a good chance that it'll require a 6.8.1 userspace, I can't
do anything else about it..
Jonathan I appreciate the bug report, I'm more saying to Andrew that
getting DRI right on new chipsets is non-trivial as there are lot of
configurations we can't test until we actually push the code to users..
and in this case you are one of those..
you might try setting the VRAM in your BIOS to 128MB instead of Auto and
seeing it helps..
I'll be trying to fix the problem properly quite soon.
The correct workaround is to add Option "DRI" "Off" to xorg.conf or for me
to travel back in time and unrelease 6.8.0. Removing the kernel DRI
support will just break lots of working systems.
Dave.
>
> Replacing 2.6.25-rc3 with 2.6.24 (still with CONFIG_DRM_RADEON enabled)
> results in a machine that boots to GDM successfully. Likewise if I
> disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM ok.
>
> J.
>
>
Is 128 MB some sort of a sweet spot for ram allocated to gpu ?
(hard coded?)
First Alex suggested that, & now you.
(asking 'coz i used 256 MB while testing)
-JoJo
On Tue, Mar 4, 2008 at 4:53 PM, Dave Airlie <[email protected]> wrote:
> >
> > Is xf86-driver-ati 6.8.0 not a proper release? I'm pretty sure the
> > combination of that, 2.6.25-rc3 and CONFIG_DRM_RADEON causes my machine
> > to become unresponsive. I only tried a git build of the driver after the
> > released version was causing issues.
>
> Yes we made a mistake with 6.8.0 enabling DRI on rs680 chips before we
> knew it worked for everyone, I may be still able to fix this in the kernel
> but there is a good chance that it'll require a 6.8.1 userspace, I can't
> do anything else about it..
>
> Jonathan I appreciate the bug report, I'm more saying to Andrew that
> getting DRI right on new chipsets is non-trivial as there are lot of
> configurations we can't test until we actually push the code to users..
> and in this case you are one of those..
>
> you might try setting the VRAM in your BIOS to 128MB instead of Auto and
> seeing it helps..
>
> I'll be trying to fix the problem properly quite soon.
>
> The correct workaround is to add Option "DRI" "Off" to xorg.conf or for me
> to travel back in time and unrelease 6.8.0. Removing the kernel DRI
> support will just break lots of working systems.
>
> Dave.
>
>
> >
> > Replacing 2.6.25-rc3 with 2.6.24 (still with CONFIG_DRM_RADEON enabled)
> > results in a machine that boots to GDM successfully. Likewise if I
> > disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM ok.
> >
> > J.
> >
> >
>
>
> _______________________________________________
> xorg-driver-ati mailing list
> [email protected]
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
On Tue, Mar 4, 2008 at 12:13 PM, JoJo jojo <[email protected]> wrote:
> Is 128 MB some sort of a sweet spot for ram allocated to gpu ?
> (hard coded?)
>
> First Alex suggested that, & now you.
>
> (asking 'coz i used 256 MB while testing)
It shouldn't really matter, it's just that the "auto" setting seems to
causes hangs for some people.
Alex