Can you please check the data format . PPC works on BigEndian format. Please do this and let me know .... --- misbah
----- Original Message ----- From: [EMAIL PROTECTED] To: [email protected] Subject: Linuxppc-embedded Digest, Vol 35, Issue 51 Date: Tue, 24 Jul 2007 12:00:02 +1000 Send Linuxppc-embedded mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://ozlabs.org/mailman/listinfo/linuxppc-embedded or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Linuxppc-embedded digest..." Today's Topics: 1. Re: Gdbserver syscall clobber (Andreas Schwab) 2. Re: Kmalloc returns which address (Scott Wood) 3. Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y (Christoph Lameter) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Jul 2007 18:19:37 +0200 From: Andreas Schwab Subject: Re: Gdbserver syscall clobber To: Bill Gatliff Cc: [EMAIL PROTECTED], [email protected] Message-ID: Content-Type: text/plain; charset=iso-8859-1 Bill Gatliff writes: > Daniel Jacobowitz wrote: >> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote: >> >>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM >>> lately), but it looks to me like the kernel is setting bit 0 in CR0 >>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0 >>> (bnslr+) bit 3 a.k.a. SO. Bits are numbered from left to right, thus 0x10000000 is bit 3 of CR0 Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ------------------------------ Message: 2 Date: Mon, 23 Jul 2007 13:35:11 -0500 From: Scott Wood Subject: Re: Kmalloc returns which address To: Misbah khan Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii On Sun, Jul 22, 2007 at 08:47:47PM -0700, Misbah khan wrote: > yes really it would really generate a machine check... but i guess if you > convert this virt address to physical address using __pa() then pass it to > the ioremap() i guess things will work . What would be the point? All you'd get is another virtual mapping. Is the DMA mapping API that difficult? -Scott ------------------------------ Message: 3 Date: Mon, 23 Jul 2007 13:34:50 -0700 From: Christoph Lameter Subject: Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y To: Andrew Morton Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], "[EMAIL PROTECTED]" , [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII On Wed, 18 Jul 2007 09:55:37 -0700 Andrew Morton wrote: > hm. It should be the case that providing SLAB_HWCACHE_ALIGN at > kmem_cache_create() time will override slab-debugging's offsetting > of the returned addresses. That is true for SLUB but not in SLAB. SLAB has always ignored SLAB_HWCACHE_ALIGN when debugging is on because of the issues involved in placing the redzone values etc. Could be fun to fix. ------------------------------ _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded End of Linuxppc-embedded Digest, Vol 35, Issue 51 ************************************************* -- We've Got Your Name at http://www.mail.com! Get a FREE E-mail Account Today - Choose From 100+ Domains
_______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
