[uClinux-dev] XIP broken in 2.4.31-uc0 ? (fwd)

David McCullough davidm at snapgear.com
Thu Oct 6 18:21:10 EDT 2005


Jivin Michael Leslie lays it down ...
> 
> Hi David,
> 
> I just checked out uClinux-2.4.x and gave it a spin on XIP 68vz328.
> Whereas previously I would get a panic at the attempt to deallocate 
> 'echo', very early on in /etc/rc, now I'm seeing:
> 
> 	kernel BUG at mmap.c:1343!
> 	Kernel panic: BUG!
> 
> a little later on, just after configuring local loopback. It didn't 
> continue from there, though. The system seems to have hung.

The BUG! message is a lockup.

Gerg saw it here late yesterday on a 5275??,  so it looks like real HW
is needed to track the rest of the problem down,  I get that happening
today,

Cheers,
Davidm


> On Thu, 6 Oct 2005, David McCullough wrote:
> 
> > 
> > Erwin,
> > 
> > Can you back out the previous patches you have tried and get the latest
> > updates from cvs for these files:
> > 
> > 	linux-2.4.x/mmnommu/mmap.c
> > 	linux-2.4.x/fs/proc/nommu.c
> > 	linux-2.4.x/lib/rbtree.c
> > 	linux-2.4.x/fs/binfmt_flat.c
> > 	linux-2.4.x/drivers/block/blkmem.c
> > 
> > Otherwise I have attached a patch just in case :-)
> > 
> > This should see XIP working without errors and fix various problems
> > surrounding it and the VMA house keeping.  It is running ok for me on
> > Xcopilot and the ARMulator.  Actually it was previously running for the
> > simple "it boots test", unfortunately I didn't try much harder than that
> > before pushing out 2.4.31 :-(
> > 
> > Cheers,
> > Davidm
> > 
> > 
> > Jivin Erwin Authried lays it down ...
> > > Am Don, den 22.09.2005 schrieb Erwin Authried um 11:57:
> > > > Am Mit, den 21.09.2005 schrieb Michael Leslie um 22:27:
> > > > > Hi Erwin,
> > > > > 
> > > > > I sent Greg a couple of patches for this just recently, based on 
> > > > > suggestions from Greg and David Howells. Part of the solution also 
> > > > > required satisfying the requirements of MAGIC_ROM_PTR in the arch/ code.
> > > > > 
> > > > > I've attached the patches that got XIP going for me on Motorola 68VZ328.
> > > > > They also seem _not_ to break non-XIP (I've tested on Coldfire).
> > > > > 
> > > > > I hope these help.
> > > > > 
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Michael Leslie,
> > > > > Arcturus Networks Inc.
> > > > > 
> > > > Hello Michael,
> > > > 
> > > > thanks a lot! The patch still doesn't solve the problem completely. Now
> > > > I'm getting a alignment exception in put_vma when I invoke the
> > > > application a second time. from the backtrace, the functions are:
> > > > 
> > > > sys_exit -> do_exit -> mmput -> exit_mmap -> put_vma
> > > > 
> > > > I verified that there's no problem when the load-to-ram flag is set. The
> > > > same application works with XIP on an older kernel (2.4.27-uc1).
> > > > 
> > > > Regards,
> > > > Erwin
> > > > 
> > > I found the reason for the problem now. The execption occured in kfree
> > > that's called from put_vma, instead of in put_vma as reported before.
> > > kfree crashed because it was called with the address of the
> > > application's entry point in flash. 
> > > The base address of romfs is calculated in blkmem.c, with
> > > ioremap_nocache(). In most uclinux architectures, ioremap is just a 1:1
> > > translation. In my case (w90n740), ioremap returns a pointer to
> > > noncacheable memory, by setting Bit 31 in the address. I guess that this
> > > causes  is_in_rom() to return false. At least, after removing the
> > > ioremap_nocache line in blkmem.c, everything worked fine. 
> > > But still, I have some doubts about blkmem:
> > > 
> > > * ioremap_nocache returns a pointer to memory fro non-cached access by
> > > definition. That will slow down XIP execution considerably if ioremap
> > > isn't a dummy macro.
> > > 
> > > * If blkmem isn't inside flash, kfree would try to free non-malloced
> > > memory (just a guess, I haven't verified that) when the application
> > > exits.
> > > 
> > > Regards,
> > > Erwin
> > > 
> > > 
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> > 
> > -- 
> > David McCullough, davidm at cyberguard.com.au, Custom Embedded Solutions + Security
> > Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com
> > 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
David McCullough, davidm at cyberguard.com.au, Custom Embedded Solutions + Security
Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com



More information about the uClinux-dev mailing list