assorted kernel patches

assorted kernel patches

[Edward Swarthout]

We are switching to Linuxppc to support our early
processor bringup in the lab.

There are a small set of patches that we think would be useful to
merge back into linuxppc_2_4_devel.  What is the procedure to discuss
these changes, get them reviewed, and merged (if so desired)?

Here is the list:

1. Support for hardware breakpoints for process threads.

   - Add iabr and dabr to the end of the pt_regs structure.
   - Save and restore IABR and DABR on exception/switch.
     Since the 603 family does not have DABR, should it
     be excluded via a CONFIG compile option or with the cputable?
     In either case, pt_regs should contain spots for both.
   - add IABR and DABR register numbers for ptrace
     There is a hole before the FP regs where they can go
     without disturbing and user applications.
   - Change InstructionBreakpoint and do_page_fault to not
     call XMON/KGDB if the trap is from user_mode.

2. Allow superviser (MSR[PR]=0) user threads.
   Currently MSR[PR] has a second purpose which indicates the thread
   was in kernel mode on exception.  A different bit needs to
   indicate this.  A good alternative is MSR[RI].

   - change user_mode() to reference MSR_RI instead of MSR_PR
   - change copy_thread to use the user_mode macro instead of MSR_PR

3. Additional 7450 support
   - Use recommended cache flush/initialization routines
   - add machine check decodes in traps.c

4. 7450 L3 cache control
   - Use recommended initialization routine
   - l3cr-value in device-tree (what uses l2cr-value today?)
   - l3cr=xxxx on commandline
   - /proc/sys/kernel/l3cr

5. Use L2 Hardware flush routines for 7400, 7410, and 7450
   - define DSSALL in ppc_asm.h

6. Add support 8245 cpu/bridge, and mpc107 bridge

7. stabs support for kernel asm functions

8. In ProgramCheckException, do not call dubugger_bpt if in user_mode

9. Additional thread state:

   - per thread MSR[FE0,1] bits - allows thread to control
   - per thread MSR[FP,VA] state -  to know if thread
     used FPU for Vector unit even if it was subsequently taken from it.

Ed Swarthout

Ed.Swarthout@Motorola.com
Austin, Tx

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: assorted kernel patches

[Adrian Cox]

Edward Swarthout wrote:

> 3. Additional 7450 support
>    - add machine check decodes in traps.c

The current code deals with hardware errors inside the processor by
killing the user mode thread which was unlucky enough to be running at
the time. So as well as adding decodes in traps.c, you may also want to
ensure that internal error checking is enabled on 7400/10/50, and that
the machine is halted once an error is detected. I do have a patch for
this, but there wasn't a great deal of interest last time I posted it.
> 6. Add support 8245 cpu/bridge, and mpc107 bridge

The 2_4_devel tree already supports the mpc107. What did you have in mind?
--
Adrian Cox   http://www.humboldt.co.uk/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: assorted kernel patches

[Paul Mackerras]

Edward Swarthout writes:

> There are a small set of patches that we think would be useful to
> merge back into linuxppc_2_4_devel.  What is the procedure to discuss
> these changes, get them reviewed, and merged (if so desired)?

Well the primary thing is to make the actual patches available to us;
post them to the list or post a URL or something.  Since I am the
maintainer you need to persuade me that the patches are interesting
and useful and won't break anything too badly. :)

> 1. Support for hardware breakpoints for process threads.

A good idea in general although I will be interested to see how this
interacts with xmon's and kgdb's use of iabr/dabr.

>    - Add iabr and dabr to the end of the pt_regs structure.

Why save them there rather than in the thread_struct?  Do you change
them on every kernel entry from userspace?

>    - add IABR and DABR register numbers for ptrace

Is this so that gdb can change them?

> 2. Allow superviser (MSR[PR]=0) user threads.

Hmmm, you'll need to explain exactly why this is a good idea and why
it won't break anything.  Without a good strong argument I would be
inclined to reject this.  I don't see what you can do with a "user"
thread running in supervisor mode that you can't do with a kernel
module.

>    indicate this.  A good alternative is MSR[RI].

Huh?  Why is RI good?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: assorted kernel patches

[Albert D. Cahalan]

Paul Mackerras writes:
> Edward Swarthout writes:

>> 1. Support for hardware breakpoints for process threads.
>
> A good idea in general although I will be interested to see
> how this interacts with xmon's and kgdb's use of iabr/dabr.

Who cares? Take a look at the Alpha and i386 Linux ports.
Debugger support for users is important. Kernel hackers can
live without it. (including myself) Go check the linux-kernel
archives to see Linus Torvalds and David S. Miller's opinions
about kernel debuggers.

It would be nice if the ppc port met the Linus standard.

>> 2. Allow superviser (MSR[PR]=0) user threads.
>
> Hmmm, you'll need to explain exactly why this is a good idea
> and why it won't break anything. Without a good strong argument
> I would be inclined to reject this. I don't see what you can do
> with a "user" thread running in supervisor mode that you can't
> do with a kernel module.

It is good for experimenting with processor features.

On an embedded system, it is often nice to turn off interrupts
to do a bit of super-hard real-time from userspace. The user code
may well be incompatible with the kernel. (non-GPL C++ or FORTRAN)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: assorted kernel patches

[David A. Gatwood]

On Wednesday, August 22, 2001, at 02:12 PM, Albert D. Cahalan wrote:

>
> Paul Mackerras writes:
>> Edward Swarthout writes:
>
>>> 1. Support for hardware breakpoints for process threads.
>>
>> A good idea in general although I will be interested to see
>> how this interacts with xmon's and kgdb's use of iabr/dabr.
>
> Who cares? Take a look at the Alpha and i386 Linux ports.
> Debugger support for users is important. Kernel hackers can
> live without it. (including myself)

Depends on what part of the kernel.  Sure, you can debug a driver with
printf debugging, generally.  But as anybody who ever tried to debug a
file system without a kernel debugger will testify, it ain't pretty.
Threw gdb at it, and suddenly problems that had been thwarting detection
for weeks suddenly became blindingly obvious....

This particularly becomes a problem when the debugging information you
need would require dumping a screen worth of data for every block
written to or read from the disk and occurs only after a few gigabytes
of data are written or read.  If you have ever stared blankly at tens or
even hundreds of thousands of lines of debug output from a single test
run to figure out what went wrong, only then will you understand why no
sane person would say that kernel debuggers are unnecessary.  Been
there, done that.  Never, ever, ever, never, ever again.  :-)


Later,
David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: assorted kernel patches

[Paul Mackerras]

Albert D. Cahalan writes:

> Who cares? Take a look at the Alpha and i386 Linux ports.
> Debugger support for users is important. Kernel hackers can
> live without it. (including myself) Go check the linux-kernel
> archives to see Linus Torvalds and David S. Miller's opinions
> about kernel debuggers.

I find a simple debugger like xmon useful as an aid to understanding.
Neither Linus nor DaveM have ever said to me that xmon should be
removed.

In any case this is all vapor since Ed Swarthout has not posted his
patches for us to look at, nor has he sent them to me.

> >> 2. Allow superviser (MSR[PR]=0) user threads.
> >
> > Hmmm, you'll need to explain exactly why this is a good idea
> > and why it won't break anything. Without a good strong argument
> > I would be inclined to reject this. I don't see what you can do
> > with a "user" thread running in supervisor mode that you can't
> > do with a kernel module.
>
> It is good for experimenting with processor features.
>
> On an embedded system, it is often nice to turn off interrupts
> to do a bit of super-hard real-time from userspace. The user code
> may well be incompatible with the kernel. (non-GPL C++ or FORTRAN)

OK, I can buy that argument.  The way that Ed described that he
implemented this sounded to me like it maybe wasn't the best way to do
it but without seeing any actual code we can't usefully discuss it any
further.

Paul.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/