<DIV><BR>Can you please check the data format . PPC works on BigEndian format. Please do this and let me know ....</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;--- misbah<BR></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">----- Original Message -----<BR>From: linuxppc-embedded-request@ozlabs.org<BR>To: linuxppc-embedded@ozlabs.org<BR>Subject: Linuxppc-embedded Digest, Vol 35, Issue 51<BR>Date: Tue, 24 Jul 2007 12:00:02 +1000<BR><BR><BR>Send Linuxppc-embedded mailing list submissions to<BR>linuxppc-embedded@ozlabs.org<BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR>https://ozlabs.org/mailman/listinfo/linuxppc-embedded<BR>or, via email, send a message with subject or body 'help' to<BR>linuxppc-embedded-request@ozlabs.org<BR><BR>You can reach the person managing the list at<BR>linuxppc-embedded-owner@ozlabs.org<BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of Linuxppc-embedded digest..."<BR><BR><BR>Today's Topics:<BR><BR>1. Re: Gdbserver syscall clobber (Andreas Schwab)<BR>2. Re: Kmalloc returns which address (Scott Wood)<BR>3. Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports<BR>access of bad area during boot with DEBUG_SLAB=y (Christoph Lameter)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Mon, 23 Jul 2007 18:19:37 +0200<BR>From: Andreas Schwab <SCHWAB@SUSE.DE><BR>Subject: Re: Gdbserver syscall clobber<BR>To: Bill Gatliff <BGAT@BILLGATLIFF.COM><BR>Cc: gdb@sourceware.org, linuxppc-embedded@ozlabs.org<BR>Message-ID: <JEMYXN6QJQ.FSF@SYKES.SUSE.DE><BR>Content-Type: text/plain; charset=iso-8859-1<BR><BR>Bill Gatliff <BGAT@BILLGATLIFF.COM>writes:<BR><BR>&gt; Daniel Jacobowitz wrote:<BR>&gt;&gt; On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:<BR>&gt;&gt;<BR>&gt;&gt;&gt; Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM<BR>&gt;&gt;&gt; lately), but it looks to me like the kernel is setting bit 0 in CR0<BR>&gt;&gt;&gt; (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0<BR>&gt;&gt;&gt; (bnslr+) bit 3 a.k.a. SO.<BR><BR>Bits are numbered from left to right, thus 0x10000000 is bit 3 of CR0<BR><BR>Andreas.<BR><BR>--<BR>Andreas Schwab, SuSE Labs, schwab@suse.de<BR>SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany<BR>PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5<BR>"And now for something completely different."<BR><BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Mon, 23 Jul 2007 13:35:11 -0500<BR>From: Scott Wood <SCOTTWOOD@FREESCALE.COM><BR>Subject: Re: Kmalloc returns which address<BR>To: Misbah khan <MISBAH_KHAN@ENGINEER.COM><BR>Cc: linuxppc-embedded@ozlabs.org<BR>Message-ID: &lt;20070723183510.GA29223@ld0162-tx32.am.freescale.net&gt;<BR>Content-Type: text/plain; charset=us-ascii<BR><BR>On Sun, Jul 22, 2007 at 08:47:47PM -0700, Misbah khan wrote:<BR>&gt; yes really it would really generate a machine check... but i guess if you<BR>&gt; convert this virt address to physical address using __pa() then pass it to<BR>&gt; the ioremap() i guess things will work .<BR><BR>What would be the point? All you'd get is another virtual mapping.<BR><BR>Is the DMA mapping API that difficult?<BR><BR>-Scott<BR><BR><BR>------------------------------<BR><BR>Message: 3<BR>Date: Mon, 23 Jul 2007 13:34:50 -0700<BR>From: Christoph Lameter <CLAMETER@SGI.COM><BR>Subject: Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports<BR>access of bad area during boot with DEBUG_SLAB=y<BR>To: Andrew Morton <AKPM@LINUX-FOUNDATION.ORG><BR>Cc: netdev@vger.kernel.org, bart.vanassche@gmail.com,<BR>linux-mm@kvack.org, "bugme-daemon@kernel-bugs.osdl.org"<BR><BUGME-DAEMON@BUGZILLA.KERNEL.ORG>, linuxppc-embedded@ozlabs.org<BR>Message-ID: &lt;20070723133450.3de91b33@schroedinger.engr.sgi.com&gt;<BR>Content-Type: text/plain; charset=US-ASCII<BR><BR>On Wed, 18 Jul 2007 09:55:37 -0700<BR>Andrew Morton <AKPM@LINUX-FOUNDATION.ORG>wrote:<BR><BR>&gt; hm. It should be the case that providing SLAB_HWCACHE_ALIGN at<BR>&gt; kmem_cache_create() time will override slab-debugging's offsetting<BR>&gt; of the returned addresses.<BR><BR><BR>That is true for SLUB but not in SLAB. SLAB has always ignored<BR>SLAB_HWCACHE_ALIGN when debugging is on because of the issues involved<BR>in placing the redzone values etc. Could be fun to fix.<BR><BR><BR><BR>------------------------------<BR><BR>_______________________________________________<BR>Linuxppc-embedded mailing list<BR>Linuxppc-embedded@ozlabs.org<BR>https://ozlabs.org/mailman/listinfo/linuxppc-embedded<BR><BR>End of Linuxppc-embedded Digest, Vol 35, Issue 51<BR>*************************************************<BR></BLOCKQUOTE><BR>

-- 
<div> Enter the Bourne Ultimatum Sweepstakes<br>
<a href="http://www.hollywoodlife.net/index.php/sweepstakescontests/the-bourne-ultimatum/?utm_source=mail_hl_sent_footer&utm_medium=email&utm_term=070713&utm_content=hl_textlink&utm_campaign=the-bourne-ultimatum" target="_blank">View Trailer, Win Free Prizes.</a> In Theaters 08.03.07</div>