Re: Linuxppc-embedded Digest, Vol 35, Issue 51

From: "misbah khan" <misbah_khan@engineer.com>
To: linuxppc-embedded@ozlabs.org
Subject: Re: Linuxppc-embedded Digest, Vol 35, Issue 51
Date: Tue, 24 Jul 2007 04:19:12 -0500	[thread overview]
Message-ID: <20070724091912.98B0C478077@ws1-5.us4.outblaze.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 4355 bytes --]

Can you please check the data format . PPC works on BigEndian format.
Please do this and let me know ....  --- misbah

  ----- Original Message -----
  From: linuxppc-embedded-request@ozlabs.org
  To: linuxppc-embedded@ozlabs.org
  Subject: Linuxppc-embedded Digest, Vol 35, Issue 51
  Date: Tue, 24 Jul 2007 12:00:02 +1000

  Send Linuxppc-embedded mailing list submissions to
  linuxppc-embedded@ozlabs.org

  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
  linuxppc-embedded-request@ozlabs.org

  You can reach the person managing the list at
  linuxppc-embedded-owner@ozlabs.org

  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: gdb@sourceware.org, linuxppc-embedded@ozlabs.org
  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, schwab@suse.de
  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: linuxppc-embedded@ozlabs.org
  Message-ID: <20070723183510.GA29223@ld0162-tx32.am.freescale.net>
  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: netdev@vger.kernel.org, bart.vanassche@gmail.com,
  linux-mm@kvack.org, "bugme-daemon@kernel-bugs.osdl.org"
  , linuxppc-embedded@ozlabs.org
  Message-ID: <20070723133450.3de91b33@schroedinger.engr.sgi.com>
  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
  Linuxppc-embedded@ozlabs.org
  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

[-- Attachment #2: Type: text/html, Size: 5136 bytes --]