2.6.10 boots fine, but is killed by the X server when it
tries to initialize my PCI radeon 9200 SE. This problem exists
in 2.6.9 too, but not in 2.6.8.1. So I'm stuck with that version currently.
The problem seems to be access to the card bios, X uses
int10 bios calls to initialize the card.
Helge Hafting
I am getting something similar -- the X process gets stuck in some
kind of system call, but I can login from the network and shut the
system down, but I cannot change the console from the X to a text
console.
on Thursday 01/13/2005 Helge Hafting([email protected]) wrote
> 2.6.10 boots fine, but is killed by the X server when it
> tries to initialize my PCI radeon 9200 SE. This problem exists
> in 2.6.9 too, but not in 2.6.8.1. So I'm stuck with that version currently.
>
> The problem seems to be access to the card bios, X uses
> int10 bios calls to initialize the card.
>
> Helge Hafting
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
John Covici
[email protected]
> on Thursday 01/13/2005 Helge Hafting([email protected]) wrote
> > 2.6.10 boots fine, but is killed by the X server when it
> > tries to initialize my PCI radeon 9200 SE. This problem exists
> > in 2.6.9 too, but not in 2.6.8.1. So I'm stuck with that version currently.
> >
> > The problem seems to be access to the card bios, X uses
> > int10 bios calls to initialize the card.
> >
Do you have DRM enabled if so can you turn it off.. same with radeonfb
or vesafb...
Dave.
I ran into a similar problem with 2.6.8.1 and found that by downgrading to
AGP4 I could get it to work.
DAvid Lang
On Thu, 13 Jan 2005, John covici wrote:
> Date: Thu, 13 Jan 2005 06:00:40 -0500
> From: John covici <[email protected]>
> To: Helge Hafting <[email protected]>
> Cc: Kernel Mailing List <[email protected]>
> Subject: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE
>
> I am getting something similar -- the X process gets stuck in some
> kind of system call, but I can login from the network and shut the
> system down, but I cannot change the console from the X to a text
> console.
>
> on Thursday 01/13/2005 Helge Hafting([email protected]) wrote
> > 2.6.10 boots fine, but is killed by the X server when it
> > tries to initialize my PCI radeon 9200 SE. This problem exists
> > in 2.6.9 too, but not in 2.6.8.1. So I'm stuck with that version currently.
> >
> > The problem seems to be access to the card bios, X uses
> > int10 bios calls to initialize the card.
> >
> > Helge Hafting
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> John Covici
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
David Lang wrote:
> I ran into a similar problem with 2.6.8.1 and found that by
> downgrading to AGP4 I could get it to work.
It can't be AGP because it is a PCI card.
Unless something is so broken as to mess with
AGP when dealing with a PCI card, that is. I have an
AGP card too in this machine.
Helge Hafting
I have an apg card and it happens on that one as well. How can I turn
off drm -- just not load the dri module?
on Friday 01/14/2005 Helge Hafting([email protected]) wrote
> David Lang wrote:
>
> > I ran into a similar problem with 2.6.8.1 and found that by
> > downgrading to AGP4 I could get it to work.
>
> It can't be AGP because it is a PCI card.
> Unless something is so broken as to mess with
> AGP when dealing with a PCI card, that is. I have an
> AGP card too in this machine.
>
> Helge Hafting
--
John Covici
[email protected]
> I have an apg card and it happens on that one as well. How can I turn
> off drm -- just not load the dri module?
>
don't load the drm kernel module or make sure CONFIG_DRM is set to n..
Dave.
On Fri, Jan 14, 2005 at 08:06:09AM +1100, Dave Airlie wrote:
> > on Thursday 01/13/2005 Helge Hafting([email protected]) wrote
> > > 2.6.10 boots fine, but is killed by the X server when it
> > > tries to initialize my PCI radeon 9200 SE. This problem exists
> > > in 2.6.9 too, but not in 2.6.8.1. So I'm stuck with that version currently.
> > >
> > > The problem seems to be access to the card bios, X uses
> > > int10 bios calls to initialize the card.
> > >
>
> Do you have DRM enabled if so can you turn it off.. same with radeonfb
> or vesafb...
>
Some more data:
2.6.10 with agp and drm (drm for radeon & matrox) - dies with X on radeon
2.6.10 with drm (for radeon) no agp - runs X fine!
2.6.10 with agp and no drm at all - dies with X on radeon
2.6.10 no agp no drm - runs X, but no 3d of course
2.6.10 with drm and no agp couldn't use matrox drm because that one
needs agp to compile.
This is a bit strange. I can't run X on the radoen PCI card if AGP is compiled,
but X and the kernel is not supposed to use AGP in this case because it is a
pci card! Seems very strange to me, particularly considering that 2.6.8.1
is able to run with both agp and drm.
I've mounted /var synchronously so as to get the most of the crash log. It ends
like this:
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
(II) RADEON(0): initializing int10
(**) RADEON(0): Option "InitPrimary" "on"
(II) Truncating PCI BIOS Length to 53248
A normal non-crashing run looks like this:
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(II) LoadModule: "int10"
(II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
(II) RADEON(0): initializing int10
(**) RADEON(0): Option "InitPrimary" "on"
(II) Truncating PCI BIOS Length to 53248
(--) RADEON(0): Chipset: "ATI Radeon 9200SE 5964 (AGP)" (ChipID = 0x5964)
(--) RADEON(0): Linear framebuffer at 0xe0000000
(--) RADEON(0): VideoRAM: 131072 kByte (64 bit DDR SDRAM)
(II) RADEON(0): PCI card detected
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(and so on)
Another item that may be interesting:
>From the log, it looks like DRM failed to load for the PCI card when
AGP wasn't present. Odd - it couldn't use AGP anyway.
Maybe the explanation is that the xserver erroneously believes that it is
an agp card? The log contains this:
(--) Chipset ATI Radeon 9200SE 5964 (AGP) found
It _is_ an "ATI Radeon 9200 SE", but it is definitely not an AGP card.
I don't know wether the X server is mistaken, or if it merely is a
wrong message. I don't think X should hang the kernel this way, even
if it opens the AGP device by mistake. AGP is normally in use by the
matrox card and should be unavailable anyway.
Any further ideas?� More things to try? It'd be nice to get 3D on these
newer kernels too. :-) I can post full logs if that's interesting.
Helge Hafting
> Some more data:
> 2.6.10 with agp and drm (drm for radeon & matrox) - dies with X on radeon
> 2.6.10 with drm (for radeon) no agp - runs X fine!
> 2.6.10 with agp and no drm at all - dies with X on radeon
> 2.6.10 no agp no drm - runs X, but no 3d of course
>
> 2.6.10 with drm and no agp couldn't use matrox drm because that one
> needs agp to compile.
>
> This is a bit strange. I can't run X on the radoen PCI card if AGP is compiled,
> but X and the kernel is not supposed to use AGP in this case because it is a
> pci card! Seems very strange to me, particularly considering that 2.6.8.1
> is able to run with both agp and drm.
>
> I've mounted /var synchronously so as to get the most of the crash log. It ends
> like this:
>
> (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
> (II) Loading sub module "int10"
> (II) LoadModule: "int10"
> (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
> (II) RADEON(0): initializing int10
> (**) RADEON(0): Option "InitPrimary" "on"
> (II) Truncating PCI BIOS Length to 53248
>
> A normal non-crashing run looks like this:
> (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
> (II) LoadModule: "int10"
> (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
> (II) RADEON(0): initializing int10
> (**) RADEON(0): Option "InitPrimary" "on"
> (II) Truncating PCI BIOS Length to 53248
> (--) RADEON(0): Chipset: "ATI Radeon 9200SE 5964 (AGP)" (ChipID = 0x5964)
> (--) RADEON(0): Linear framebuffer at 0xe0000000
> (--) RADEON(0): VideoRAM: 131072 kByte (64 bit DDR SDRAM)
> (II) RADEON(0): PCI card detected
> (II) Loading sub module "ddc"
> (II) LoadModule: "ddc"
>
> (and so on)
>
> Another item that may be interesting:
> From the log, it looks like DRM failed to load for the PCI card when
> AGP wasn't present. Odd - it couldn't use AGP anyway.
> Maybe the explanation is that the xserver erroneously believes that it is
> an agp card? The log contains this:
>
> (--) Chipset ATI Radeon 9200SE 5964 (AGP) found
>
> It _is_ an "ATI Radeon 9200 SE", but it is definitely not an AGP card.
> I don't know wether the X server is mistaken, or if it merely is a
> wrong message. I don't think X should hang the kernel this way, even
> if it opens the AGP device by mistake. AGP is normally in use by the
> matrox card and should be unavailable anyway.
Well the problem with a lot of ATI chips is they can be put onto
either an AGP or PCI card and work fine, so chips which are AGP chips
can end up on PCI cards...
I've cc'ed Jon Smirl who has a similiar setup (or has at least an AGP
and PCI radeon on his machine).... Jon can you try 2.6.10 on your
setup and see does it work?
it sounds like something may have broken the int10 stuff, but I've no
idea what, the only other thing I can think to recommend doing is an
binary search say starting at 2.6.9-rc1 and maybe using the -bk
snapshots to nail down exactly when it went wrong....
Dave.
I use PCI Rage128 cards which are working fine.
I suspect it is this code from radeon_drv.c. There is probably
something wrong with card's BIOS or whatever and it is saying that it
is an AGP card when it is really a PCI one. We used to specify this
manually in xconfig but now DRM code does it automatically. Fix is
probably to add a special case on the PCI_ID of the card that is
failing.
/* There are signatures in BIOS and PCI-SSID for a PCI card,
but they are not very reliable.
Following detection method works for all cards tested so far.
Note, checking AGP_ENABLE bit after drmAgpEnable call can also
give the correct result.
However, calling drmAgpEnable on a PCI card can cause some
strange lockup when the server
restarts next time.
*/
pci_read_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG, &save);
pci_write_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG,
save | RADEON_AGP_ENABLE);
pci_read_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG, &temp);
if (temp & RADEON_AGP_ENABLE)
dev_priv->flags |= CHIP_IS_AGP;
DRM_DEBUG("%s card detected\n",
((dev_priv->flags & CHIP_IS_AGP) ? "AGP" : "PCI"));
pci_write_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG, save);
--
Jon Smirl
[email protected]
Be sure and run with "modprobe drm debug=1" and check the debug
output. If it is broken the debug output will say the card is AGP. The
message from the X server does not mean anything for DRM, you need to
check the debug output from DRM.
--
Jon Smirl
[email protected]
>
> /* There are signatures in BIOS and PCI-SSID for a PCI card,
> but they are not very reliable.
> Following detection method works for all cards tested so far.
> Note, checking AGP_ENABLE bit after drmAgpEnable call can also
> give the correct result.
> However, calling drmAgpEnable on a PCI card can cause some
> strange lockup when the server
> restarts next time.
> */
> pci_read_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG, &save);
> pci_write_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG,
> save | RADEON_AGP_ENABLE);
> pci_read_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG, &temp);
> if (temp & RADEON_AGP_ENABLE)
> dev_priv->flags |= CHIP_IS_AGP;
> DRM_DEBUG("%s card detected\n",
> ((dev_priv->flags & CHIP_IS_AGP) ? "AGP" : "PCI"));
> pci_write_config_dword(dev->pdev, RADEON_AGP_COMMAND_PCI_CONFIG, save);
perhaps the stuff from Mike Harris in the latest radeon_driver.c in
Xorg might be a better idea..
Dave.
On Sun, Jan 16, 2005 at 09:08:38PM +1100, Dave Airlie wrote:
> Well the problem with a lot of ATI chips is they can be put onto
> either an AGP or PCI card and work fine, so chips which are AGP chips
> can end up on PCI cards...
>
X uses chip ID to guess wether it is an AGP or PCI card? Ouch.
Doesn�'t the kernel know very well how the card is connected,
couldn't X get this from the same interfaces "lspci" uses?
> it sounds like something may have broken the int10 stuff, but I've no
> idea what, the only other thing I can think to recommend doing is an
> binary search say starting at 2.6.9-rc1 and maybe using the -bk
> snapshots to nail down exactly when it went wrong....
That�'s an option. It'll take time though, it is a multiuser machin;
I can compile all the kernels I want but rebooting isn't
that popular.
Helge Hafting
you need to check the output from "modprobe drm debug=1" "modprobe
radeon" and see if drm is misidentifying the board as AGP. We don't
want to fix something if it isn't broken.
--
Jon Smirl
[email protected]
> you need to check the output from "modprobe drm debug=1" "modprobe
> radeon" and see if drm is misidentifying the board as AGP. We don't
> want to fix something if it isn't broken.
have a look at bug 255 in fd.o bugzilla, this was what was wrong with
the original code, I'd seriously think about putting this code into
the radeon drm not the old stuff..
Dave.
On Sun, 16 Jan 2005 22:07:13 +1100, Dave Airlie <[email protected]> wrote:
> > you need to check the output from "modprobe drm debug=1" "modprobe
> > radeon" and see if drm is misidentifying the board as AGP. We don't
> > want to fix something if it isn't broken.
>
>
> have a look at bug 255 in fd.o bugzilla, this was what was wrong with
> the original code, I'd seriously think about putting this code into
> the radeon drm not the old stuff..
>
> Dave.
>
I'm fine with adding this code, but we still don't know if this is the
cause of his problem. The debug output can determine if this really is
the source of the problem or if it is somewhere else.
--
Jon Smirl
[email protected]
>
> I'm fine with adding this code, but we still don't know if this is the
> cause of his problem. The debug output can determine if this really is
> the source of the problem or if it is somewhere else.
>
I actually doubt it is this stuff.. my guess is that it is something
nasty like ACPI breaking int10 for X or something like that... it
seems a lot more subtle than the usually things that break when we
mess with the DRM :-)
Dave.
On Sun, Jan 16, 2005 at 06:04:32AM -0500, Jon Smirl wrote:
> you need to check the output from "modprobe drm debug=1" "modprobe
> radeon" and see if drm is misidentifying the board as AGP. We don't
> want to fix something if it isn't broken.
>
Stupid question - how do I get a modular drm?
I usually make everything compiled-in with no module support.
But now I made a kernel with module support and selected "M"
for the agp stuff and for the radeon and matrox DRM support.
But DRM itself will only accept Yes or No, Module is not an
option there with "make menuconfig". So I can load
and unload the radeon module now, but there is no DRM module.
loading/unloading radeon gives me messages from DRM about this
happening, but DRM itself is compiled in so I can't modprobe it
with that debug parameter.
Is there perhaps something in some other menu that needs to be (M)
before (M) becomes an option for DRM?
Helge Hafting
OK, I don't have a module called drm except a .a file in the library
directory for X -- I have some radeon stuff but modprobe radeon
debug=1 says invalid parameter and loads the module. Am I missing
something?
Thanks.
on Sunday 01/16/2005 Jon Smirl([email protected]) wrote
> On Sun, 16 Jan 2005 22:07:13 +1100, Dave Airlie <[email protected]> wrote:
> > > you need to check the output from "modprobe drm debug=1" "modprobe
> > > radeon" and see if drm is misidentifying the board as AGP. We don't
> > > want to fix something if it isn't broken.
> >
> >
> > have a look at bug 255 in fd.o bugzilla, this was what was wrong with
> > the original code, I'd seriously think about putting this code into
> > the radeon drm not the old stuff..
> >
> > Dave.
> >
>
> I'm fine with adding this code, but we still don't know if this is the
> cause of his problem. The debug output can determine if this really is
> the source of the problem or if it is somewhere else.
>
>
> --
> Jon Smirl
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
John Covici
[email protected]
On Sun, 16 Jan 2005 13:18:23 +0100
Helge Hafting <[email protected]> wrote:
> On Sun, Jan 16, 2005 at 06:04:32AM -0500, Jon Smirl wrote:
> > you need to check the output from "modprobe drm debug=1" "modprobe
> > radeon" and see if drm is misidentifying the board as AGP. We
> > don't want to fix something if it isn't broken.
> >
> Stupid question - how do I get a modular drm?
> I usually make everything compiled-in with no module support.
> But now I made a kernel with module support and selected "M"
> for the agp stuff and for the radeon and matrox DRM support.
> But DRM itself will only accept Yes or No, Module is not an
> option there with "make menuconfig". So I can load
> and unload the radeon module now, but there is no DRM module.
> loading/unloading radeon gives me messages from DRM about this
> happening, but DRM itself is compiled in so I can't modprobe it
> with that debug parameter.
>
> Is there perhaps something in some other menu that needs to be (M)
> before (M) becomes an option for DRM?
>
> Helge Hafting
Hello,
I can help shed a bit of light on this particular discrepancy. It's
only very recently that "drm" itself has been selectable as a
separate module. In plain 2.6.10 it hasn't happened yet. (I noticed it
when doing 2.6.11-rc1)
In 2.6.10 the "direct rendering manager" choice just enables the other
DRM choices below it, and the DRM code was
built into your video card specific module.
Now, the "direct rendering manager" choice is now individually
selectable and when you modprobe your card specific module, it
loads "drm" as a dependent module.
e.g. from lsmod on my system with 2.6.11-rc1:
Module Size Used by
radeon 51584 1
drm 37012 2 radeon
intel_agp 11676 1
agpgart 15272 2 drm,intel_agp
Where before there was no module "drm" and it was a fatter 90 kb
radeon module.
I hope you get your problem solved,
Mike
On Sun, 16 Jan 2005 13:18:23 +0100, Helge Hafting
<[email protected]> wrote:
> On Sun, Jan 16, 2005 at 06:04:32AM -0500, Jon Smirl wrote:
> > you need to check the output from "modprobe drm debug=1" "modprobe
> > radeon" and see if drm is misidentifying the board as AGP. We don't
> > want to fix something if it isn't broken.
> >
> Stupid question - how do I get a modular drm?
For older radeon drivers "modprobe radeon debug=1" should work. I also
think you can do it for compiled in ones by adding the kernel
parameter radeon.debug=1
--
Jon Smirl
[email protected]
On Sun, Jan 16, 2005 at 05:08:12PM -0500, Jon Smirl wrote:
> On Sun, 16 Jan 2005 13:18:23 +0100, Helge Hafting
> <[email protected]> wrote:
> > On Sun, Jan 16, 2005 at 06:04:32AM -0500, Jon Smirl wrote:
> > > you need to check the output from "modprobe drm debug=1" "modprobe
> > > radeon" and see if drm is misidentifying the board as AGP. We don't
> > > want to fix something if it isn't broken.
> > >
> > Stupid question - how do I get a modular drm?
>
> For older radeon drivers "modprobe radeon debug=1" should work. I also
> think you can do it for compiled in ones by adding the kernel
> parameter radeon.debug=1
I tried that - and got a message from the radeon module that "debug"
was an unknown parameter.
Helge Hafting
On Sun, Jan 16, 2005 at 05:08:12PM -0500, Jon Smirl wrote:
> On Sun, 16 Jan 2005 13:18:23 +0100, Helge Hafting
> <[email protected]> wrote:
> > On Sun, Jan 16, 2005 at 06:04:32AM -0500, Jon Smirl wrote:
> > > you need to check the output from "modprobe drm debug=1" "modprobe
> > > radeon" and see if drm is misidentifying the board as AGP. We don't
> > > want to fix something if it isn't broken.
> > >
> > Stupid question - how do I get a modular drm?
>
> For older radeon drivers "modprobe radeon debug=1" should work. I also
> think you can do it for compiled in ones by adding the kernel
> parameter radeon.debug=1
>
I tried 2.6.11rc1, which has modular drm (and also the crash I'm
struggling with.)
# modprobe drm debug=1
# modprobe radeon
I got this in dmesg (some of it also on the console):
[drm] Initialized drm 1.0.0 20040925
[drm:drm_init]
[drm:drm_probe]
[drm:drm_probe] assigning minor 0
PCI: Enabling device 0000:00:08.0 (0000 -> 0003)
ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 19 (level, low) -> IRQ 19
[drm:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:drm_ctxbitmap_init] drm_ctxbitmap_init : 0
[drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI Technologies Inc
RV280 [Radeon 9200 SE]
[drm:drm_probe] new minor assigned 0
I guess it was detected as pci, due to the "PCI: Enabling device..." message.
At least there is no mention of AGP here.
I tried to run X on the radeon after this, and it locked up solid as usual.
I hope this helps. I can try other kernels, but I hope a binary
search will be a last resort. (I will try that if absolutely necessary,
but it will take time. I can't reboot all the time.)
Helge Hafting
On Sun, Jan 16, 2005 at 10:41:23PM +1100, Dave Airlie wrote:
> >
> > I'm fine with adding this code, but we still don't know if this is the
> > cause of his problem. The debug output can determine if this really is
> > the source of the problem or if it is somewhere else.
> >
>
> I actually doubt it is this stuff.. my guess is that it is something
> nasty like ACPI breaking int10 for X or something like that... it
> seems a lot more subtle than the usually things that break when we
> mess with the DRM :-)
>
The search was a short one.
2.6.9-rc1 works fine, just like 2.6.8.1
2.6.9-rc2 crashes. I didn't find any kernel revisions between those two.
It is interesting to note that the 2.6.9 crash was a bit different.
X got a bit further according to the log.
During the test, everything stopped, but the machine wasn't completely
dead like it usually is. Numlock actually toggled the LED, but the screen was
black and I could not break out of X with ctrl+alt+backspace. So I tried to
switch consoles, and the kernel died a bit more. No more numlock LED
toggling, but sysrq+S+U+B actually worked. The discs synced and
the thing booted. Hm, perhaps X always got a bit further, but
now the disc sync preserved more of the log?
Here is how it ended (I have all of it if necessary):
(==) RADEON(0): Write-combining range (0xe0000000,0x8000000)
(II) RADEON(0): Wrote: rd=12, fd=120, pd=1
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) RADEON(0): [drm] loaded kernel module for "radeon" driver
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:0:8:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0920000
(II) RADEON(0): [drm] mapped SAREA 0xe0920000 to 0xafd8c000
(II) RADEON(0): [drm] framebuffer handle = 0xe0000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [pci] 8192 kB allocated with handle 0xe097d000
(II) RADEON(0): [pci] ring handle = 0xe097d000
(II) RADEON(0): [pci] Ring mapped at 0xafc8b000
(II) RADEON(0): [pci] Ring contents 0x00000000
(II) RADEON(0): [pci] ring read ptr handle = 0xe0a7e000
(II) RADEON(0): [pci] Ring read ptr mapped at 0xafc8a000
(II) RADEON(0): [pci] Ring read ptr contents 0x00000000
(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe0a7f000
(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xafa8a000
(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
(II) RADEON(0): [pci] GART texture map handle = 0xe0c7f000
(II) RADEON(0): [pci] GART Texture map mapped at 0xaf5aa000
(II) RADEON(0): [drm] register handle = 0xf6000000
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): CP in BM mode
(II) RADEON(0): Using 8 MB GART aperture
(II) RADEON(0): Using 1 MB for the ring buffer
(II) RADEON(0): Using 2 MB for vertex/indirect buffers
(II) RADEON(0): Using 5 MB for GART textures
(II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)
(II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7165
(II) RADEON(0): Will use back buffer at offset 0x1400000
(II) RADEON(0): Will use depth buffer at offset 0x1900000
(II) RADEON(0): Will use 100352 kb for textures at offset 0x1e00000
(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indirect CPU to Screen color expansion
Solid Lines
Scanline Image Writes
Offscreen Pixmaps
Setting up tile and stipple cache:
32 128x128 slots
32 256x256 slots
16 512x512 slots
(II) RADEON(0): Acceleration enabled
(==) RADEON(0): Backing store disabled
(==) RADEON(0): Silken mouse enabled
(II) RADEON(0): Using hardware cursor (scanline 1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7161
(**) Option "dpms"
(**) RADEON(0): DPMS enabled
(WW) RADEON(0): Option "DynamicClocks" is not used
(II) RADEON(0): X context handle = 0x00000001
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
I hope this can be of help,
Helge Hafting
Makes sense to me -- I went from 6.8 to 6.9rc2 and that is I think
when my X died. Now mine is an APG not PCI, but it may be related.
on Friday 01/21/2005 Helge Hafting([email protected]) wrote
> On Sun, Jan 16, 2005 at 10:41:23PM +1100, Dave Airlie wrote:
> > >
> > > I'm fine with adding this code, but we still don't know if this is the
> > > cause of his problem. The debug output can determine if this really is
> > > the source of the problem or if it is somewhere else.
> > >
> >
> > I actually doubt it is this stuff.. my guess is that it is something
> > nasty like ACPI breaking int10 for X or something like that... it
> > seems a lot more subtle than the usually things that break when we
> > mess with the DRM :-)
> >
> The search was a short one.
> 2.6.9-rc1 works fine, just like 2.6.8.1
> 2.6.9-rc2 crashes. I didn't find any kernel revisions between those two.
>
> It is interesting to note that the 2.6.9 crash was a bit different.
> X got a bit further according to the log.
> During the test, everything stopped, but the machine wasn't completely
> dead like it usually is. Numlock actually toggled the LED, but the screen was
> black and I could not break out of X with ctrl+alt+backspace. So I tried to
> switch consoles, and the kernel died a bit more. No more numlock LED
> toggling, but sysrq+S+U+B actually worked. The discs synced and
> the thing booted. Hm, perhaps X always got a bit further, but
> now the disc sync preserved more of the log?
>
> Here is how it ended (I have all of it if necessary):
>
> (==) RADEON(0): Write-combining range (0xe0000000,0x8000000)
> (II) RADEON(0): Wrote: rd=12, fd=120, pd=1
> drmOpenDevice: minor is 0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is -1, (Unknown error 999)
> drmOpenDevice: open result is -1, (Unknown error 999)
> drmOpenDevice: Open failed
> drmOpenDevice: minor is 0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is -1, (Unknown error 999)
> drmOpenDevice: open result is -1, (Unknown error 999)
> drmOpenDevice: Open failed
> drmOpenDevice: minor is 0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 6, (OK)
> drmGetBusid returned ''
> (II) RADEON(0): [drm] loaded kernel module for "radeon" driver
> (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:0:8:0"
> (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0920000
> (II) RADEON(0): [drm] mapped SAREA 0xe0920000 to 0xafd8c000
> (II) RADEON(0): [drm] framebuffer handle = 0xe0000000
> (II) RADEON(0): [drm] added 1 reserved context for kernel
> (II) RADEON(0): [pci] 8192 kB allocated with handle 0xe097d000
> (II) RADEON(0): [pci] ring handle = 0xe097d000
> (II) RADEON(0): [pci] Ring mapped at 0xafc8b000
> (II) RADEON(0): [pci] Ring contents 0x00000000
> (II) RADEON(0): [pci] ring read ptr handle = 0xe0a7e000
> (II) RADEON(0): [pci] Ring read ptr mapped at 0xafc8a000
> (II) RADEON(0): [pci] Ring read ptr contents 0x00000000
> (II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe0a7f000
> (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xafa8a000
> (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
> (II) RADEON(0): [pci] GART texture map handle = 0xe0c7f000
> (II) RADEON(0): [pci] GART Texture map mapped at 0xaf5aa000
> (II) RADEON(0): [drm] register handle = 0xf6000000
> (II) RADEON(0): [dri] Visual configs initialized
> (II) RADEON(0): CP in BM mode
> (II) RADEON(0): Using 8 MB GART aperture
> (II) RADEON(0): Using 1 MB for the ring buffer
> (II) RADEON(0): Using 2 MB for vertex/indirect buffers
> (II) RADEON(0): Using 5 MB for GART textures
> (II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)
> (II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
> (II) RADEON(0): Largest offscreen area available: 1280 x 7165
> (II) RADEON(0): Will use back buffer at offset 0x1400000
> (II) RADEON(0): Will use depth buffer at offset 0x1900000
> (II) RADEON(0): Will use 100352 kb for textures at offset 0x1e00000
> (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
> Screen to screen bit blits
> Solid filled rectangles
> 8x8 mono pattern filled rectangles
> Indirect CPU to Screen color expansion
> Solid Lines
> Scanline Image Writes
> Offscreen Pixmaps
> Setting up tile and stipple cache:
> 32 128x128 slots
> 32 256x256 slots
> 16 512x512 slots
> (II) RADEON(0): Acceleration enabled
> (==) RADEON(0): Backing store disabled
> (==) RADEON(0): Silken mouse enabled
> (II) RADEON(0): Using hardware cursor (scanline 1026)
> (II) RADEON(0): Largest offscreen area available: 1280 x 7161
> (**) Option "dpms"
> (**) RADEON(0): DPMS enabled
> (WW) RADEON(0): Option "DynamicClocks" is not used
> (II) RADEON(0): X context handle = 0x00000001
> (II) RADEON(0): [drm] installed DRM signal handler
> (II) RADEON(0): [DRI] installation complete
> (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
>
>
> I hope this can be of help,
> Helge Hafting
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Your life is like a penny -- how are you going to spend it?
John Covici
[email protected]