RE: [microblaze-uclinux] Bug at line 497 of mmnommu/slab.c?

["David Banas" <dbanas@xxxxxxxxxxxxxx>]

Are you in a position to do a post-mortem stack trace analysis, in order to
see if you're also getting bogus values passed to the function?

David Banas
Field Applications Engineer
Nu Horizons Electronics Corp.
2070 Ringwood Avenue
San Jose, CA 95131
(408)434-0800 - office
(415)846-5837 - cell
http://www.nuhorizons.com

> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au [mailto:owner-microblaze-
> uclinux@itee.uq.edu.au] On Behalf Of Kristian Chaplin
> Sent: Monday, March 14, 2005 5:23 AM
> To: microblaze-uclinux@itee.uq.edu.au
> Cc: Kristian Chaplin
> Subject: RE: [microblaze-uclinux] Bug at line 497 of mmnommu/slab.c?
> 
> Hi All,
> 
> I am getting something very similar, although on a different line in
> slab.c
> 
> Linux version 2.4.29-uc0 (xilinx@debian) (gcc version 2.95.3-4 Xilinx EDK
> 6.3 Build EDK_Gmm.11.2) #4 Mon Mar 14 12:42:18 GMT 2005
> On node 0 totalpages: 8192
> zone(0): 8192 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> CPU: MICROBLAZE
> Console: xmbserial on UARTLite
> Kernel command line: °
> Calibrating delay loop... 3.68 BogoMIPS
> Memory: 32MB = 32MB total
> Memory: 30260KB available (1178K code, 968K data, 44K init)
> kernel BUG at slab.c:682!
> 
> This is on a new board build (the memory is known good), and this is not a
> known good toolchain (my first try on this linux box).
> 
> CVS dist and kernel was downloaded from scratch on Sunday.
> 
> MHS, MSS and config.in included, incase it helps!
> 
> Best regards
> 
> Kris
> 
> 
> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au [mailto:owner-microblaze-
> uclinux@itee.uq.edu.au] On Behalf Of John Williams
> Sent: 12 March 2005 01:33
> To: microblaze-uclinux@itee.uq.edu.au
> Subject: Re: [microblaze-uclinux] Bug at line 497 of mmnommu/slab.c?
> 
> Hi David,
> 
> David Banas wrote:
> 
> > I think I just found a bug at line 497 of mmnommu/slab.c:
> >    "0" -> "0L"
> >
> > It was preventing my kernel from booting during the 'kmem_cache_init()'
> > phase by giving a bogus cache size to a lower level function, which was,
> in
> > turn, bailing out to 'machine_halt' after being asked to create a cache
> of
> > over 3 billion bytes.
> 
> The compiler should promote the 0 to 0L automagically.  What was the
> bogus value passed to the lwoer level function?
> 
> > What's curious is this: the fix doesn't appear in the current CVS
> archive.
> > So, my question is, how is anyone running successfully with this bug
> > present?
> 
> That code is stable and works across all nommu arches, microblaze
> included.  I'm more inclined to suspect something specific to your setup.
> 
> When did you last update your kernel sources (not that it should matter
> in this instance)?
> 
> What compiler version are you using?
> 
> Also, can you run mb-objdump -S over the slab.o file, and see what sort
> of assembly is being generated?
> 
> Thanks,
> 
> John
> 
> 
> 
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-
> uclinux/
> 
> 
> 
> ________________________________________________________________________
> This email has been scanned for all viruses by the MessageLabs Email
> Security System. For more information on a proactive email security
> service working around the clock, around the globe, visit
> http://www.messagelabs.com
> ________________________________________________________________________



___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/