From: <exister99@velocitus.net>
To: <ralf@oss.sgi.com>
Cc: <linux-mips@linux-mips.org>
Subject: mips 32 bit HIGHMEM support
Date: Wed, 8 Oct 2003 16:00:33 -0600 (MDT) [thread overview]
Message-ID: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net> (raw)
Hello Ralf,
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.
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:
>Is anybody using 32-bit MIPS CPUs which have more than 512mb of memory or
>to be more exact have RAM that isn't accessible via the KSEG0 / KSEG1
>window?
>
>So far I haven't ever seen such a machine. For 64-bit CPUs the right
>thing to do is easy - use a 64-bit kernel. But for 32-bit CPUs the Intel
>highmem stuff in the memory managment now gives us a sane way to use
>the memory of such configuration with just a little bit of extra code.
>
>So if anybody wants support for such a configuration, please drop me a
>note.
>
>Thanks,
>
> Ralf
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.
Regards, Andrew Stone
WARNING: multiple messages have this Message-ID (diff)
From: <exister99@velocitus.net>
To: ralf@oss.sgi.com
Cc: linux-mips@linux-mips.org
Subject: mips 32 bit HIGHMEM support
Date: Wed, 8 Oct 2003 16:00:33 -0600 (MDT) [thread overview]
Message-ID: <5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net> (raw)
Message-ID: <20031008220033.uAcqA6QnwSDvcHt13SpCzsbjfUDzOjRpC7ahvAnB3BI@z> (raw)
Hello Ralf,
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.
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:
>Is anybody using 32-bit MIPS CPUs which have more than 512mb of memory or
>to be more exact have RAM that isn't accessible via the KSEG0 / KSEG1
>window?
>
>So far I haven't ever seen such a machine. For 64-bit CPUs the right
>thing to do is easy - use a 64-bit kernel. But for 32-bit CPUs the Intel
>highmem stuff in the memory managment now gives us a sane way to use
>the memory of such configuration with just a little bit of extra code.
>
>So if anybody wants support for such a configuration, please drop me a
>note.
>
>Thanks,
>
> Ralf
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.
Regards, Andrew Stone
next reply other threads:[~2003-10-08 22:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-08 22:00 exister99 [this message]
2003-10-08 22:00 ` mips 32 bit HIGHMEM support exister99
2003-10-09 14:03 ` Ralf Baechle
2003-10-09 22:11 ` bug in kernel_entry? Steve Scott
2003-10-09 22:11 ` Steve Scott
2003-10-10 13:23 ` Ralf Baechle
2003-10-10 14:59 ` mips 32 bit HIGHMEM support Ralf Baechle
2003-10-13 23:15 ` 64 bit kernel in the name of HIGHMEM exister99
2003-10-13 23:15 ` exister99
2003-10-10 17:44 mips 32 bit HIGHMEM support Krishna Kondaka
2003-10-10 17:44 ` Krishna Kondaka
2003-10-10 17:53 ` 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=5334.156.153.254.2.1065650433.squirrel@webmail.rmci.net \
--to=exister99@velocitus.net \
--cc=linux-mips@linux-mips.org \
--cc=ralf@oss.sgi.com \
/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.