BUG in free_block (tainted)

BUG in free_block (tainted)

[Simon Arlott]

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]

http://img169.imageshack.us/img169/1170/1005548cp9.jpg

2.6.27-rc3 09873-gb08c7f5

(Tainted with fglrx, but X hadn't been run...)

-- 
Simon Arlott

[-- Attachment #2: dmesg4.bz2 --]
[-- Type: application/x-bzip, Size: 26849 bytes --]

Re: BUG in free_block (tainted)

[Pekka Enberg]

Hi Simon,

On Tue, Aug 19, 2008 at 12:28 AM, Simon Arlott <simon@fire.lp0.eu> wrote:
> http://img169.imageshack.us/img169/1170/1005548cp9.jpg
>
> 2.6.27-rc3 09873-gb08c7f5
>
> (Tainted with fglrx, but X hadn't been run...)

Looks like SLAB corruption so fglrx could have caused this even if you
just loaded the module. Do you have CONFIG_DEBUG_SLAB enabled? If not,
you might want to try to reproduce this with it. Of course,
reproducing the oops without fglrx would be most helpful. :-)

                          Pekka

Re: BUG in free_block (tainted)

[Simon Arlott]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On 18/08/08 22:37, Pekka Enberg wrote:
> Hi Simon,
> 
> On Tue, Aug 19, 2008 at 12:28 AM, Simon Arlott <simon@fire.lp0.eu> wrote:
>> http://img169.imageshack.us/img169/1170/1005548cp9.jpg
>>
>> 2.6.27-rc3 09873-gb08c7f5
>>
>> (Tainted with fglrx, but X hadn't been run...)
> 
> Looks like SLAB corruption so fglrx could have caused this even if you
> just loaded the module. Do you have CONFIG_DEBUG_SLAB enabled? If not,
> you might want to try to reproduce this with it. Of course,
> reproducing the oops without fglrx would be most helpful. :-)

In that case please disregard this completely. It's not yet happened again.

fglrx completely breaks slab in fantastic ways... I could show you my 
/proc/slabinfo... the start of it is badly corrupted - but only if X 
has been started (attached).

I might try enabling CONFIG_DEBUG_SLAB, perhaps it can detect that bug...

-- 
Simon Arlott

[-- Attachment #2: x.bz2 --]
[-- Type: application/x-bzip, Size: 3852 bytes --]

Re: BUG in free_block (tainted)

[Pekka Enberg]

Hi Simon,

On Tue, Aug 19, 2008 at 12:28 AM, Simon Arlott <simon@fire.lp0.eu> wrote:
>>> http://img169.imageshack.us/img169/1170/1005548cp9.jpg
>>>
>>> 2.6.27-rc3 09873-gb08c7f5
>>>
>>> (Tainted with fglrx, but X hadn't been run...)

On 18/08/08 22:37, Pekka Enberg wrote:
>> Looks like SLAB corruption so fglrx could have caused this even if you
>> just loaded the module. Do you have CONFIG_DEBUG_SLAB enabled? If not,
>> you might want to try to reproduce this with it. Of course,
>> reproducing the oops without fglrx would be most helpful. :-)

On Tue, Aug 19, 2008 at 12:42 AM, Simon Arlott <simon@fire.lp0.eu> wrote:
> In that case please disregard this completely. It's not yet happened again.
>
> fglrx completely breaks slab in fantastic ways... I could show you my
> /proc/slabinfo... the start of it is badly corrupted - but only if X has
> been started (attached).
>
> I might try enabling CONFIG_DEBUG_SLAB, perhaps it can detect that bug...

Aww, apparently the fglrx driver creates tons of SLAB caches with
really funky names for no good reason... Oh well, one more reason to
stay away from that crap and help out the nouveau folks instead ;-).

                         Pekka

Re: BUG in free_block (tainted)

[Christoph Lameter]

Pekka Enberg wrote:
 perhaps it can detect that bug...
> 
> Aww, apparently the fglrx driver creates tons of SLAB caches with
> really funky names for no good reason... Oh well, one more reason to
> stay away from that crap and help out the nouveau folks instead ;-).

Could you give SLUB a try? Diagnostics are better. Lets see what it spits out.

Re: BUG in free_block (tainted)

[Peter Zijlstra]

On Tue, 2008-08-19 at 00:49 +0300, Pekka Enberg wrote:

> Aww, apparently the fglrx driver creates tons of SLAB caches with
> really funky names for no good reason... Oh well, one more reason to
> stay away from that crap and help out the nouveau folks instead ;-).

fglrx is the AMD/ATI binary evilness - the open source efforts are the
radeon and radeonhd drivers. AMD/ATI are actually providing
documentation and paying developers to work on the drivers.

I'm not sure what the nvidia binary wonkyness is called, but its
respective open source effort is the nouveau - who must solely reply on
reverse engineering as nvidia isn't providing anything.

Anyway - your point still stands - binary stuff should not be used.

Re: BUG in free_block (tainted)

[Pekka Enberg]

Hi Peter,

On Tue, 2008-08-19 at 00:49 +0300, Pekka Enberg wrote:
> > Aww, apparently the fglrx driver creates tons of SLAB caches with
> > really funky names for no good reason... Oh well, one more reason to
> > stay away from that crap and help out the nouveau folks instead ;-).

On Thu, 2008-08-21 at 12:48 +0200, Peter Zijlstra wrote:
> fglrx is the AMD/ATI binary evilness - the open source efforts are the
> radeon and radeonhd drivers. AMD/ATI are actually providing
> documentation and paying developers to work on the drivers.

Oh, right. I guess I didn't even consider anyone would still be using
the binary-only ATI crap now that we have proper open source drivers
available.... ;-)

		Pekka

Re: BUG in free_block (tainted)

[Adrian Bunk]

On Thu, Aug 21, 2008 at 01:51:31PM +0300, Pekka Enberg wrote:
> 
> Oh, right. I guess I didn't even consider anyone would still be using
> the binary-only ATI crap now that we have proper open source drivers
> available.... ;-)

I never tried fglrx, but judging from my experiences with the onboard 
690G on the board I bought at the beginning of this year (with the two 
open source X11 drivers for it) the word "proper" is not appropriate 
when you want a working system.

And I'm not talking about stuff like Xv or even 3D - all I'm asking for 
is that DVI works flawlessly (and without sporadic GPU lookups).

Note that this is not meant against the developers of the open source 
drivers - that's simply one of the many areas where recent hardware
does not work flawlessly under Linux and developing drivers that work 
flawlessly takes some time.

> 		Pekka

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed