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
Hi Simon,
On Tue, Aug 19, 2008 at 12:28 AM, Simon Arlott <[email protected]> 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
On 18/08/08 22:37, Pekka Enberg wrote:
> Hi Simon,
>
> On Tue, Aug 19, 2008 at 12:28 AM, Simon Arlott <[email protected]> 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
Hi Simon,
On Tue, Aug 19, 2008 at 12:28 AM, Simon Arlott <[email protected]> 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 <[email protected]> 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
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.
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.
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
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
