Re: 2.6.10 dies when X uses PCI radeon 9200 SE, binary search result

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, binary search result

[Andreas Hartmann]

Hello Helge,

Helge Hafting schrieb:
> 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 :-)

Which glibc do you use? I have problems with glibc 2.3.4, kernel 2.4.x and
X / Xorg while executing the int10-code of X. glibc 2.3.3 works fine for
me. But I could find another posting, which describes, that there are even
problems with glibc 2.3.3 and kernel 2.4.x.

It's new for me, that there could be problems with kernelversions of 2.6, too.

Therefore, it would be really interessting to know, which glibc version
you are using.


Kind regards,
Andreas Hartmann

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, binary search result

[Helge Hafting]

On Fri, Jan 21, 2005 at 09:05:12PM +0100, Andreas Hartmann wrote:
> Hello Helge,
> 
> Helge Hafting schrieb:
> > 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 :-)
> 
> Which glibc do you use? I have problems with glibc 2.3.4, kernel 2.4.x and
> X / Xorg while executing the int10-code of X. glibc 2.3.3 works fine for
> me. But I could find another posting, which describes, that there are even
> problems with glibc 2.3.3 and kernel 2.4.x.
> 
> It's new for me, that there could be problems with kernelversions of 2.6, too.
> 
> Therefore, it would be really interessting to know, which glibc version
> you are using.
> 
I use glibc 2.3.2 from debian testing (or unstable).  
This is not the problem though, because a reboot into 2.6.8.1 makes
X work without crashing.  The crash only happens with 2.6.9-rc2
or later kernels.  

So the only way glibc could be the culprit, is if the newer kernel
exports some new interface that this glibc manages to mess up.  Still,
even a buggy glibc shouldn't hang the kernel anyway.  Such issues
could crash (all) user apps, but shouldn't prevent the machine from
responding to sysrq sequences.

Helge Hafting

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, binary search result

[Dave Airlie]

> >>
> 
> That's certainly correct.
> 
> > Such issues
> > could crash (all) user apps, but shouldn't prevent the machine from
> > responding to sysrq sequences.
> 
> You emphasized the differences of the effects. But there is one reason in
> all cases which I know: int10 crashes X or even the whole kernel.
> 
> I could debug the problem to the following point:
> 
> 
> I could see, that X crashes in glibc 2.3.4 with kernel 2.4.x (not with
> kernel 2.6.x, x <= 10, x > 10 not tested) during the first malloc syscall
> after int10 to execute the function
> xf86MsgVerb(X_INFO,3,"my comment\n");
> 
> The crashes depend on different versions of used software:
> 
> glibc 2.3.3 or 2.3.4 with kernel 2.4.x
> glibc 2.3.2 with kernel > 2.6.9rc2
> 


Well if you can track down which patch in -rc2 causes it then we can
annoy the person who created it, if you build some kernels from the bk
snapshots it might help as -rc2 is quite large vs -rc1..

Dave.

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, binary search result

[Andreas Hartmann]

Helge Hafting schrieb:
> On Fri, Jan 21, 2005 at 09:05:12PM +0100, Andreas Hartmann wrote:
>> Hello Helge,
>> 
>> Helge Hafting schrieb:
>> > 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 :-)
>> 
>> Which glibc do you use? I have problems with glibc 2.3.4, kernel 2.4.x and
>> X / Xorg while executing the int10-code of X. glibc 2.3.3 works fine for
>> me. But I could find another posting, which describes, that there are even
>> problems with glibc 2.3.3 and kernel 2.4.x.
>> 
>> It's new for me, that there could be problems with kernelversions of 2.6, too.
>> 
>> Therefore, it would be really interessting to know, which glibc version
>> you are using.
>> 
> I use glibc 2.3.2 from debian testing (or unstable).  
> This is not the problem though, because a reboot into 2.6.8.1 makes
> X work without crashing.  The crash only happens with 2.6.9-rc2
> or later kernels.

Did you try another version of glibc?

> So the only way glibc could be the culprit, is if the newer kernel
> exports some new interface that this glibc manages to mess up.  Still,
> even a buggy glibc shouldn't hang the kernel anyway.

That's certainly correct.

> Such issues
> could crash (all) user apps, but shouldn't prevent the machine from
> responding to sysrq sequences.

You emphasized the differences of the effects. But there is one reason in
all cases which I know: int10 crashes X or even the whole kernel.

I could debug the problem to the following point:

--------------------------------------------------------------------------
static int
vm86_rep(struct vm86_struct *ptr)
{
    int __res;

#ifdef __PIC__
    /* When compiling with -fPIC, we can't use asm constraint "b" because
       %ebx is already taken by gcc. */
    __asm__ __volatile__("pushl %%ebx\n\t"
                         "movl %2,%%ebx\n\t"
                         "movl %1,%%eax\n\t"
                         "int $0x80\n\t"
                         "popl %%ebx"
                         :"=a" (__res)
                         :"n" ((int)113), "r" ((struct vm86_struct *)ptr));
#else
    __asm__ __volatile__("int $0x80\n\t"
                         :"=a" (__res):"a" ((int)113),
                         "b" ((struct vm86_struct *)ptr));
#endif
/* Comment from me */
xf86MsgVerb(X_INFO,3,"my comment\n");
            if (__res < 0) {
                errno = -__res;
                __res = -1;
            }
            else errno = 0;
            return __res;
}

#endif
-----------------------------------------------------------------------

I could see, that X crashes in glibc 2.3.4 with kernel 2.4.x (not with
kernel 2.6.x, x <= 10, x > 10 not tested) during the first malloc syscall
after int10 to execute the function
xf86MsgVerb(X_INFO,3,"my comment\n");


The crashes depend on different versions of used software:

glibc 2.3.3 or 2.3.4 with kernel 2.4.x
glibc 2.3.2 with kernel > 2.6.9rc2

I asked a X developper, but he couldn't help until now, too.


I can't say, if glibc or the kernel could be the problem. You can't relate
it reliable neither to glibc nor to the kernel nor to X. Therefore, it
_seems_ to me, nobody really cares about the problem.

I'm willing to help to find the problem - but I'm neither a kernel
developper, nor a glibc developper nor a X developper. I'm depending on
the support of the developpers.

I think, there should work one developper of each application together to
find the problem. I could ask a X developper, which I know, if he is
willing to help to find the problem together with a developper from the
kernel and from the glibc (I don't know, who to ask from the glibc-team).


Kind regards,
Andreas Hartmann

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, binary search result

[John covici]

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(helgehaf@aitel.hist.no) 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 majordomo@vger.kernel.org
 > 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
         covici@ccs.covici.com

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, binary search result

[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