All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Rumpf <prumpf@suse.de>
To: Grant Grundler <grundler@cup.hp.com>
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] 715/100 data page fault and msg output
Date: Fri, 17 Sep 1999 01:32:40 +0200	[thread overview]
Message-ID: <19990917013240.J8112@suse.de> (raw)
In-Reply-To: <199909162322.QAA21423@milano.cup.hp.com>; from Grant Grundler on Thu, Sep 16, 1999 at 04:22:00PM -0700

> > > Couple of things in the trap handler would help here:
> > > o More white space - makes what to cut/paste easier to determine
> > > o clear text describing the fault
> > > o In this case the offending instruction and a stack trace.
> > > o printing the invalid address, IOAQ and general registers was good
> > 
> > basically look at what the x86 port does and implement it.
> 
> Ok - any volunteers?

I am a low-priority volunteer, i.e. if noone else does it I'll do it anyway
one day.

> > > ps. Alex showed me the "la la la" work around in init_task.c.
> > >    Is anyone already working to make this a runtime check?
> > 
> > you cannot.  not without major pain at least
> 
> That didn't answer my question.
> 
> The right person might be able fix this without major pain.
> I don't think I'm that person but I could look at it anyway
> and then try to find the right person. Another OS doesn't have
> this problem and obviously has solved it.

 - we could fix our binutils and use elf instead of som.  we'll have to do
   so anyway at one point but it's a major piece of boring work

 - we could runtime-relocate init_task_union.  major pain because we would
   have to change assembly

 - we could reduce the size of task_struct and stack to 4 KB

 - we could change the way Linux allocates the kernel stack

 - we could detect at build time that init_task_union isn't aligned and work
   around it with makefile / ld magic.

  reply	other threads:[~1999-09-16 23:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-16 21:58 [parisc-linux] 715/100 data page fault and msg output Grant Grundler
1999-09-16 22:32 ` Philipp Rumpf
1999-09-16 23:22   ` Grant Grundler
1999-09-16 23:32     ` Philipp Rumpf [this message]
1999-09-17  1:05     ` Ryan Bradetich
1999-09-17  1:34       ` [parisc-linux] C200 support Grant Grundler
1999-09-17  3:02         ` Ryan Bradetich
1999-09-16 22:44 ` [parisc-linux] 715/100 data page fault and msg output LaMont Jones
1999-09-16 22:55   ` Philipp Rumpf
1999-09-17  1:39     ` LaMont Jones
1999-09-17  1:52       ` Philipp Rumpf
1999-09-17 21:48         ` Grant Grundler
1999-09-22 11:48 ` [parisc-linux] 715/80 problems Hannu Martikka
1999-09-22 13:35   ` Philipp Rumpf
1999-09-22 14:27     ` Hannu Martikka
1999-09-22 14:29       ` Philipp Rumpf
1999-09-22 14:31     ` Grant Grundler
1999-09-22 15:15       ` Hannu Martikka
1999-09-22 17:00     ` Alex deVries
1999-09-22 13:42   ` Grant Grundler
1999-09-22 15:18     ` Hannu Martikka

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=19990917013240.J8112@suse.de \
    --to=prumpf@suse.de \
    --cc=grundler@cup.hp.com \
    --cc=parisc-linux@thepuffingroup.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.