All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Krishna Kondaka" <Krishna.Kondaka@MCDATA.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Subject: RE: mips 32 bit HIGHMEM support
Date: Fri, 10 Oct 2003 10:44:19 -0700	[thread overview]
Message-ID: <501EA67E9359C645A10C42EB5B52480D2AB2D0@SNEXCH01.mcdata.com> (raw)


Ralf,

How safe is it to enable HIGHMEM for sibyte/broadcom's BCM12500 processors?
Do you know if any one is using HIGHMEM enabled linux on BCM12500s?

Thanks
Krishna

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, October 09, 2003 7:03 AM
To: exister99@velocitus.net
Cc: linux-mips@linux-mips.org
Subject: Re: mips 32 bit HIGHMEM support


On Wed, Oct 08, 2003 at 04:00:33PM -0600, exister99@velocitus.net wrote:

> I work for HP in Boise, ID, USA.  For the last six months I have been
> working with Linux in HP Laser jet Printers.  It is running in a formatter
> board that features an ASIC with a MIPS 20Kc core.

Reminds me of the HP Laserjet code in the kernel.  Anybody still using
or testing that?

> The original Linux port was achieved by others working before me.  I began
> working on applications for it when I started here (to make it print
> actually).  As I have tried to milk more performance out of this board the
> recurrent bottleneck has been the fact that the kernel only recognizes
> 512Mb of RAM.  So my current endeavor is fix the kernel so it sees the 1G
> of RAM that is physically present in the system.
> 
> I reconfigured and rebuilt the kernel with HIGHMEM support.  HIGHMEM is
> seen and booting up goes splendidly until init (pid 1) kicks off.  Early
> on in the execution of init the system crashes.  Specifically it crashes
> in do_page_fault().  A couple of strange things I have noticed:
> 
> 1.  All memory pages are divied up between the DMA Zone and the HIGHMEM
> Zone at bootup.  the NORMAL zone gets 0 pages.  Not sure if this is
> normal.
> 
> 2.  The virtual address that do_page_fault() chokes on is 0x00000000. 
> This doesn't seem like a reasonable address for init to be accessing
> especially considering its mem map only contains the chunks
> 0x10000000-0x10001000 and 0x400000-0x40b000 (I got these by traversing
> init's mm->mm_rb tree).
> 
> I decided to contact you about this after digging up this old posting of
> yours:

[... ancient posting deleted ...]

> I think this describes my machine.
> 
> If this is an issue who's solution is old news please point me to the
> solution.  In any case any ideas or guidance regarding this crash would be
> greatly appreciated.

In the meantime there is a highmem implementation for the MIPS kernel.
It's got a limitation - it only works on physically indexed D-caches or
more exactly processors that don't suffer from cache aliases.  On
processors that have such aliases the necessary flushes are rather bad
for performance so this currently simply isn't suported.

Anyway, for a 64-bit processor such as the 20Kc I suggest a 64-bit kernel.
Highmem is a pain and 64-bit is the cure.

  Ralf


SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
herby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.

Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions apply to that
information. (gate01)

WARNING: multiple messages have this Message-ID (diff)
From: "Krishna Kondaka" <Krishna.Kondaka@MCDATA.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: RE: mips 32 bit HIGHMEM support
Date: Fri, 10 Oct 2003 10:44:19 -0700	[thread overview]
Message-ID: <501EA67E9359C645A10C42EB5B52480D2AB2D0@SNEXCH01.mcdata.com> (raw)
Message-ID: <20031010174419.aG14bKQAzlbO1VjcgsyBFixtuMpxRX8tjk_fArxU2BA@z> (raw)


Ralf,

How safe is it to enable HIGHMEM for sibyte/broadcom's BCM12500 processors?
Do you know if any one is using HIGHMEM enabled linux on BCM12500s?

Thanks
Krishna

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, October 09, 2003 7:03 AM
To: exister99@velocitus.net
Cc: linux-mips@linux-mips.org
Subject: Re: mips 32 bit HIGHMEM support


On Wed, Oct 08, 2003 at 04:00:33PM -0600, exister99@velocitus.net wrote:

> I work for HP in Boise, ID, USA.  For the last six months I have been
> working with Linux in HP Laser jet Printers.  It is running in a formatter
> board that features an ASIC with a MIPS 20Kc core.

Reminds me of the HP Laserjet code in the kernel.  Anybody still using
or testing that?

> The original Linux port was achieved by others working before me.  I began
> working on applications for it when I started here (to make it print
> actually).  As I have tried to milk more performance out of this board the
> recurrent bottleneck has been the fact that the kernel only recognizes
> 512Mb of RAM.  So my current endeavor is fix the kernel so it sees the 1G
> of RAM that is physically present in the system.
> 
> I reconfigured and rebuilt the kernel with HIGHMEM support.  HIGHMEM is
> seen and booting up goes splendidly until init (pid 1) kicks off.  Early
> on in the execution of init the system crashes.  Specifically it crashes
> in do_page_fault().  A couple of strange things I have noticed:
> 
> 1.  All memory pages are divied up between the DMA Zone and the HIGHMEM
> Zone at bootup.  the NORMAL zone gets 0 pages.  Not sure if this is
> normal.
> 
> 2.  The virtual address that do_page_fault() chokes on is 0x00000000. 
> This doesn't seem like a reasonable address for init to be accessing
> especially considering its mem map only contains the chunks
> 0x10000000-0x10001000 and 0x400000-0x40b000 (I got these by traversing
> init's mm->mm_rb tree).
> 
> I decided to contact you about this after digging up this old posting of
> yours:

[... ancient posting deleted ...]

> I think this describes my machine.
> 
> If this is an issue who's solution is old news please point me to the
> solution.  In any case any ideas or guidance regarding this crash would be
> greatly appreciated.

In the meantime there is a highmem implementation for the MIPS kernel.
It's got a limitation - it only works on physically indexed D-caches or
more exactly processors that don't suffer from cache aliases.  On
processors that have such aliases the necessary flushes are rather bad
for performance so this currently simply isn't suported.

Anyway, for a 64-bit processor such as the 20Kc I suggest a 64-bit kernel.
Highmem is a pain and 64-bit is the cure.

  Ralf


SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
herby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.

Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions apply to that
information. (gate01)

             reply	other threads:[~2003-10-10 17:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-10 17:44 Krishna Kondaka [this message]
2003-10-10 17:44 ` mips 32 bit HIGHMEM support Krishna Kondaka
2003-10-10 17:53 ` Ralf Baechle
  -- strict thread matches above, loose matches on Subject: below --
2003-10-08 22:00 exister99
2003-10-08 22:00 ` exister99
2003-10-09 14:03 ` Ralf Baechle
2003-10-10 14:59   ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=501EA67E9359C645A10C42EB5B52480D2AB2D0@SNEXCH01.mcdata.com \
    --to=krishna.kondaka@mcdata.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.