On Thu, 5 Apr 2007, Badari Pulavarty wrote:
> On Wed, 2007-04-04 at 21:29 -0700, Christoph Lameter wrote:
> > Here is a patch that adds validation (only for cpuslabs and partial
> > slabs but thats where the action is). Apply this patch
> > and then do
> >
> > echo 1 >/sys/slab//validate
> >
>
On Wed, 2007-04-04 at 21:29 -0700, Christoph Lameter wrote:
> Here is a patch that adds validation (only for cpuslabs and partial
> slabs but thats where the action is). Apply this patch
> and then do
>
> echo 1 >/sys/slab//validate
>
> I suggest to boot with full debugging and then run this on
Here is a patch that adds validation (only for cpuslabs and partial
slabs but thats where the action is). Apply this patch
and then do
echo 1 >/sys/slab//validate
I suggest to boot with full debugging and then run this on the ACPI slabs.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
In
On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> > Were the slabs merged? Look at /sys/slab and see if there are any symlinks
> > there.
> >
Ok. symlinks there. Its a sporadic thing. I think I am going to add a slab
validator to SLUB that goes through all slabs and checks all objects for
validity
On Wed, 2007-04-04 at 17:31 -0700, Christoph Lameter wrote:
> On Wed, 4 Apr 2007, Badari Pulavarty wrote:
>
> > On Wed, 2007-04-04 at 15:59 -0700, Christoph Lameter wrote:
> > > On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> > >
> > > > Here is the slub_debug=FU output with the above patch.
> > >
On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> On Wed, 2007-04-04 at 15:59 -0700, Christoph Lameter wrote:
> > On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> >
> > > Here is the slub_debug=FU output with the above patch.
> >
> > Hmmm... Looks like the object is actually free. Someone writes beyond
On Wed, 2007-04-04 at 15:59 -0700, Christoph Lameter wrote:
> On Wed, 4 Apr 2007, Badari Pulavarty wrote:
>
> > Here is the slub_debug=FU output with the above patch.
>
> Hmmm... Looks like the object is actually free. Someone writes beyond the
> end of the earlier object. Setting Z should check
On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> Here is the slub_debug=FU output with the above patch.
Hmmm... Looks like the object is actually free. Someone writes beyond the
end of the earlier object. Setting Z should check overwrites but it
switched off merging. So set
slub_debug = FZ
Analo
On Wed, 2007-04-04 at 11:22 -0700, Christoph Lameter wrote:
> On Wed, 4 Apr 2007, Christoph Lameter wrote:
>
> > Yes. slub_debug=U. But user tracking may need to increase the slab
> > size (depends on the padding available in the slab) to store the
> > tracking information, so you may not get th
On Wed, 2007-04-04 at 10:35 -0700, Christoph Lameter wrote:
> On Wed, 4 Apr 2007, Badari Pulavarty wrote:
>
> > Next issue ? Sorry.
>
> No problem. Could have a look at the hvsi driver and figure out what is
> failing there? What is the hvsi driver?
>
> > Console: switching to colour frame buf
On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> free. Any ideas on how I can track down easily ? Is there
> a way to store last allocated (function, line#) and look
> around there ?
Also you may want to switch off slab merging. That will allow you to
determine the cache involved if its not a kmall
On Wed, 4 Apr 2007, Christoph Lameter wrote:
> Yes. slub_debug=U. But user tracking may need to increase the slab
> size (depends on the padding available in the slab) to store the
> tracking information, so you may not get the same corruption.
Hummm U is switching off merging and you may need
On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> Machine booted fine with slub_debug=F. Got following in the
> log. I guess we need to track down who is touching after
> free. Any ideas on how I can track down easily ? Is there
> a way to store last allocated (function, line#) and look
> around there
On Wed, 2007-04-04 at 10:03 -0700, Christoph Lameter wrote:
> On Wed, 4 Apr 2007, Badari Pulavarty wrote:
>
> > On Tue, 2007-04-03 at 16:55 -0700, Christoph Lameter wrote:
> > > On Tue, 3 Apr 2007, Badari Pulavarty wrote:
> > >
> > > > Hmm. booted fine with slub_debug :(
> > >
> > > Try to selec
On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> Next issue ? Sorry.
No problem. Could have a look at the hvsi driver and figure out what is
failing there? What is the hvsi driver?
> Console: switching to colour frame buffer device 80x30
> fb0: MATROX frame buffer device
> matroxfb_crtc2: secondar
On Wed, 2007-04-04 at 10:13 -0700, Christoph Lameter wrote:
> On Wed, 4 Apr 2007, Badari Pulavarty wrote:
>
> > Well !! Helps a little, but not enough to boot (hangs little later) :(
> > I will try to get stack trace for that.
>
> Great! Thanks for all the debugging help.
>
>
> > Processor 6 f
On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> Well !! Helps a little, but not enough to boot (hangs little later) :(
> I will try to get stack trace for that.
Great! Thanks for all the debugging help.
> Processor 6 found.
> Processor 7 found.
> Brought up 8 CPUs
> mm/memory.c:111: bad pud c000
On Wed, 4 Apr 2007, Badari Pulavarty wrote:
> On Tue, 2007-04-03 at 16:55 -0700, Christoph Lameter wrote:
> > On Tue, 3 Apr 2007, Badari Pulavarty wrote:
> >
> > > Hmm. booted fine with slub_debug :(
> >
> > Try to selectively disable debug options... if you got the
> > time...
> >
> > F.e. Tr
18 matches
Mail list logo
