linuxsh-dev

[linuxsh-dev] memcpy/TLBMiss patch assembled for 2.4.18cvs

[Masahiro A. <m-...@aa...>]

I'm trying Mr. Stuart Menefy's "memcpy speed-up" and "TLB Miss Handling
optimization" patch with 2.4.18cvs source, on SolutionEngine 7750S, in
the hope that they may improve the behavior of RTLinux-patched kernel.

Now it's build and seems to work without problems. I don't have
performance figure yet, but thought some of you might try his work with
relatively easier way, I've put simple patch files on our server.

<ftp://ftp.aandd.co.jp/pub/linuxsh/work/20030126/>

There are three patches there.
-diff-2.4.18-cvs.diff.bz2 is to apply changes to stock 2.4.18 kernel,
and make it same as the "linux-2_4_18" tagged cvs source.
-diff-2.4.18cvs-se.diff.bz2 is to apply to the "linux-2_4_18" tagged cvs
source, and make it boot from CompactFlash on SolutionEngine 7750S. This
is not needed for other platforms.
-diff-2.4.18se-su-20030126-1.diff.bz2 is the main patch file of today.
This is to apply to the "linux-2_4_18" tagged cvs source. Includes "memcpy
speed-up" and "TLB Miss Handling optimization" patch.

I've read Mr. Stuart Menefy's original posts carefully and tried to
apply his changes as intended, but there may be some error due to my
lack of understanding. If such is found, please let everybody know.

to Mr. Stuart Menefy:
Regarding TLBMiss patch, I've moved "PCC_MASK" to asm-sh/mmu_context.h
and use in kernel/entry.S and mm/fault.c, since I thought the change in
update_mmu_cache is related to this flag. Please let me know if this
assumption is correct. Thanks.

=================================
Masahiro ABE, A&D Co., Ltd. Japan

[linuxsh-dev] Patch files for SH4 system with linux-2.4.18 + RTLinux-3.2-pre1

[Masahiro A. <m-...@aa...>]

I've been doing some work to make linux-2.4.18 + RTLinux/Free-3.2-pre1
work on Hitachi SH4 lately. (Some may remember that I've put patches for
2.4.5 + 3.0 for SH4 before.)

Mr.Saito of Interface Co.Ltd, Japan initiated this version-up process,
using 2.4.17 + RTL3.1. So many cheers should go to him.

Today I've put patch files and simple docs on the net, as a snapshot of
the work above, here:
<ftp://ftp.aandd.co.jp/pub/linuxsh/rtlinux/work/20030115/>

Currently the resultant kernel/modules won't provide you "Real-Time" yet.
Telnet-connection or application-launch causes several hundred microsec
jitter with examples/measurements test-program.

These patches works for Hitachi SolutionEngine 7750S, but may work for
other platform.

I wish someone interested would try out this, nail down the cause of
jitter, and hopefully make this true "Real-Time", together.

=================================
Masahiro ABE, A&D Co., Ltd. Japan

Re: [uClinux-dev] Re: [linuxsh-dev] init problems on MMU-less SH-4

[David M. <da...@sn...>]

Jivin Paul Mundt lays it down ...
> On Mon, 2003-01-06 at 17:06, David McCullough wrote:
> > Ok,  I guess it's a possibility that on SH you can generate an executable
> > that doesn't need relocations,  but I would be suspicious,  especially if
> > it isn't built with PIC.  It sounds like elf2flt is not being used
> > correctly as all the SH code I have seen generated would need relocations
> > to run on a non-MMU system.
> > 
> I don't think its a matter of elf2flt not being used correctly, since I
> can use a cross-compiled read-elf to look at the ELF and it also reports
> this. Ie:


elf2flt is not run on the final executable file.  Executable files for the
most part do not have relocations,  they are all resolved during the link
stage.

elf2flt runs on a relocatable version of the executable (not quite fully
linked) so that it can find all the parts of the program that will actually
need relocating in a non-MMU environment.  The ld-elf2flt script that comes
with elf2flt is generally used to replace the linker so it can intercept
the -elf2flt flag on the link line and take the appropriate actions on the
files as required.  The linker is renamed ld.real and ld-elf2flt calls this.

I am not 100% on how this is handled by the uClibc cross tools.  I think
ld-elf2flt has been moved into 'C' code somewhere.


> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
>   Class:                             ELF32
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              EXEC (Executable file)
>   Machine:                           Hitachi SH
>   Version:                           0x1
>   Entry point address:               0x4000c0
>   Start of program headers:          52 (bytes into file)
>   Start of section headers:          246920 (bytes into file)
>   Flags:                             0x9
>   Size of this header:               52 (bytes)
>   Size of program headers:           32 (bytes)
>   Number of program headers:         2
>   Size of section headers:           40 (bytes)
>   Number of section headers:         14
>   Section header string table index: 13
> 
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg
> Lk Inf Al
>   [ 0]                   NULL            00000000 000000 000000 00     
> 0   0  0
>   [ 1] .init             PROGBITS        00400074 000074 00003c 00  AX 
> 0   0  4
>   [ 2] .text             PROGBITS        004000c0 0000c0 031260 00  AX 
> 0   0 32
>   [ 3] .fini             PROGBITS        00431320 031320 000030 00  AX 
> 0   0  4
>   [ 4] .rodata           PROGBITS        00431350 031350 00a2e4 00   A 
> 0   0  4
>   [ 5] .data             PROGBITS        0044b634 03b634 000a10 00  WA 
> 0   0  4
>   [ 6] .eh_frame         PROGBITS        0044c044 03c044 000004 00  WA 
> 0   0  4
>   [ 7] .ctors            PROGBITS        0044c048 03c048 000008 00  WA 
> 0   0  4
>   [ 8] .dtors            PROGBITS        0044c050 03c050 000008 00  WA 
> 0   0  4
>   [ 9] .jcr              PROGBITS        0044c058 03c058 000004 00  WA 
> 0   0  4
>   [10] .got              PROGBITS        0044c05c 03c05c 0003d4 04  WA 
> 0   0  4
>   [11] .sbss             PROGBITS        0044c430 03c430 000000 00   W 
> 0   0  1
>   [12] .bss              NOBITS          0044c430 03c430 00482c 00  WA 
> 0   0  4
>   [13] .shstrtab         STRTAB          00000000 03c430 000058 00     
> 0   0  1
> Key to Flags:
>   W (write), A (alloc), X (execute), M (merge), S (strings)
>   I (info), L (link order), G (group), x (unknown)
>   O (extra OS processing required) o (OS specific), p (processor
> specific)
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
> Align
>   LOAD           0x000000 0x00400000 0x00400000 0x3b634 0x3b634 R E
> 0x10000
>   LOAD           0x03b634 0x0044b634 0x0044b634 0x00dfc 0x05628 RW 
> 0x10000
> 
>  Section to Segment mapping:
>   Segment Sections...
>    00     .init .text .fini .rodata 
>    01     .data .eh_frame .ctors .dtors .jcr .got .bss 
> 
> There is no dynamic segment in this file.
> 
> There are no relocations in this file.
> 
> There are no unwind sections in this file.
> 
> No version information found in this file.
> 
> That's just limited to this particular application. If I look at another
> SH bin, there's quite a bit of relocation, but that's mostly limited to
> R_SH_COPY, R_SH_JMP_SLOT and R_SH_GLOB_DAT.

All of the above looks like information from the final executable for the
file.

You need to try and get you hands on the temporary file that ld-elf2flt (or
it's equivalent) creates.  It is called XXX.elf and if it doesn't have any
relocations then you do indeed have a file with no relocations.


> > binfmt_elf will deal with it,  but the program will not run.  You would
> > have to link every application at a different address and then make sure
> > that you never ran more than one instance of each.  Even then I doubt it
> > would work.  You will need to use flat executables to get it going.
>
> Okay, so by this assumption, elf2flt should _still_ convert the bin even
> if there aren't any relocations to speak of? In that case, its current
> behavior is broken.


I'm still not convinced but,  if you don't need relocations for SH then
remove the test for SH platforms.  This check is merely a safety check as
on all the platforms currently supported, the absence of relocations
signals broken apps or incorrect use of elf2flt.  This was of more
importance in the past when developers used to run elf2flt by hand
and often got it wrong ;-)


You can double check the need for relocations by looking at the output of
sh-linux-objdump -D XX.elf.  It will be obvious from the asm if it actually
needs relocations.  There will be absolute addresses in the code.  Any
absolute address used for a branch, function call or data access will
need a relocation in the flat file to work in a non-MMU environment.


> > > Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC
> > > supported. I'll submit patches for this once the above mess is worked
> > > out.
> > 
> > Sounds good.
> > 
> > By the way,  I subscribed to linuxsh-dev a month or so ago and haven't seen
> > any traffic.  It is working or am I missing something ?
>
> This is a dangerous combination of SourceForge thinking and there being
> low traffic in general. Though if you're seeing this mail and the one
> before it, you're likely seeing traffic from there, since uclinux-dev
> doesn't seem to like me sending it mail.
> 
> I have still to convince mailman on SF that I can send it mail, being
> subscribed and all... SF idiocies (to which there is an incredible
> abundance) usually work themselves out given some time.
> 
> You may also wish to look at the list archives (if they're working yet,
> see note about SF idiocies in preceding paragraph) to see if there's
> anything you've missed.

Ok,  it suddenly seems to be working.  I received two copies of my last
reply,  but only one for the original message ??

uclinux-dev will not let you post unless you are subscribed IIRC,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

Re: [uClinux-dev] Re: [linuxsh-dev] init problems on MMU-less SH-4

[Paul M. <le...@li...>]

On Mon, 2003-01-06 at 17:06, David McCullough wrote:
> Ok,  I guess it's a possibility that on SH you can generate an executable
> that doesn't need relocations,  but I would be suspicious,  especially if
> it isn't built with PIC.  It sounds like elf2flt is not being used
> correctly as all the SH code I have seen generated would need relocations
> to run on a non-MMU system.
> 
I don't think its a matter of elf2flt not being used correctly, since I
can use a cross-compiled read-elf to look at the ELF and it also reports
this. Ie:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Hitachi SH
  Version:                           0x1
  Entry point address:               0x4000c0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          246920 (bytes into file)
  Flags:                             0x9
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         14
  Section header string table index: 13

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg
Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00     
0   0  0
  [ 1] .init             PROGBITS        00400074 000074 00003c 00  AX 
0   0  4
  [ 2] .text             PROGBITS        004000c0 0000c0 031260 00  AX 
0   0 32
  [ 3] .fini             PROGBITS        00431320 031320 000030 00  AX 
0   0  4
  [ 4] .rodata           PROGBITS        00431350 031350 00a2e4 00   A 
0   0  4
  [ 5] .data             PROGBITS        0044b634 03b634 000a10 00  WA 
0   0  4
  [ 6] .eh_frame         PROGBITS        0044c044 03c044 000004 00  WA 
0   0  4
  [ 7] .ctors            PROGBITS        0044c048 03c048 000008 00  WA 
0   0  4
  [ 8] .dtors            PROGBITS        0044c050 03c050 000008 00  WA 
0   0  4
  [ 9] .jcr              PROGBITS        0044c058 03c058 000004 00  WA 
0   0  4
  [10] .got              PROGBITS        0044c05c 03c05c 0003d4 04  WA 
0   0  4
  [11] .sbss             PROGBITS        0044c430 03c430 000000 00   W 
0   0  1
  [12] .bss              NOBITS          0044c430 03c430 00482c 00  WA 
0   0  4
  [13] .shstrtab         STRTAB          00000000 03c430 000058 00     
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor
specific)

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
Align
  LOAD           0x000000 0x00400000 0x00400000 0x3b634 0x3b634 R E
0x10000
  LOAD           0x03b634 0x0044b634 0x0044b634 0x00dfc 0x05628 RW 
0x10000

 Section to Segment mapping:
  Segment Sections...
   00     .init .text .fini .rodata 
   01     .data .eh_frame .ctors .dtors .jcr .got .bss 

There is no dynamic segment in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

That's just limited to this particular application. If I look at another
SH bin, there's quite a bit of relocation, but that's mostly limited to
R_SH_COPY, R_SH_JMP_SLOT and R_SH_GLOB_DAT.


> binfmt_elf will deal with it,  but the program will not run.  You would
> have to link every application at a different address and then make sure
> that you never ran more than one instance of each.  Even then I doubt it
> would work.  You will need to use flat executables to get it going.
> 
Okay, so by this assumption, elf2flt should _still_ convert the bin even
if there aren't any relocations to speak of? In that case, its current
behavior is broken.

> > Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC
> > supported. I'll submit patches for this once the above mess is worked
> > out.
> 
> Sounds good.
> 
> By the way,  I subscribed to linuxsh-dev a month or so ago and haven't seen
> any traffic.  It is working or am I missing something ?
> 
This is a dangerous combination of SourceForge thinking and there being
low traffic in general. Though if you're seeing this mail and the one
before it, you're likely seeing traffic from there, since uclinux-dev
doesn't seem to like me sending it mail.

I have still to convince mailman on SF that I can send it mail, being
subscribed and all... SF idiocies (to which there is an incredible
abundance) usually work themselves out given some time.

You may also wish to look at the list archives (if they're working yet,
see note about SF idiocies in preceding paragraph) to see if there's
anything you've missed.

Regards,

-- 
Paul Mundt <le...@li...>

Re: [uClinux-dev] Re: [linuxsh-dev] init problems on MMU-less SH-4

[David M. <da...@sn...>]

Jivin Paul Mundt lays it down ...
> On Sun, 2003-01-05 at 20:34, David McCullough wrote:
> > I suspect that you are still running ELF programs.  When you turn off the
> > MMU support in the kernel,  the rules for applications change a little.
> > They cannot be paged in for example, and they have to be loaded (and
> > relocated) at run time.  Normal elf programs are loaded at a fixed
> > addresses and this cannot work without an MMU.
> > 
> > The uClinux guys use a program called elf2flt (ELF to flat) to make flat
> > binaries that can be run without an MMU.  You can find it at:
>
> Okay, one issue with elf2flt. I've built a static busybox linked against
> uClibc (which was built w/o HAS_MMU set), also using the sh-uclibc-
> toolchain (which is also built w/o HAS_MMU). Now, this busybox itself
> doesn't have any relocations in it, though it's still an ELF.


Ok,  I guess it's a possibility that on SH you can generate an executable
that doesn't need relocations,  but I would be suspicious,  especially if
it isn't built with PIC.  It sounds like elf2flt is not being used
correctly as all the SH code I have seen generated would need relocations
to run on a non-MMU system.


> elf2flt currently bails and refuses to write the flt hdr/file if it sees
> that the ELF doesn't have anything needing relocation. This happens
> around line 900 of elf2flt.c from current HEAD by way of the
> bfd_get_file_flags() HAS_RELOC check. If I comment this out, the flt
> file is generated properly.
> 
> This brings up the question, if I have an ELF that was built with PIC
> turned off, can binfmt_elf deal with it? or does it still have to pass
> through binfmt_flat?


binfmt_elf will deal with it,  but the program will not run.  You would
have to link every application at a different address and then make sure
that you never ran more than one instance of each.  Even then I doubt it
would work.  You will need to use flat executables to get it going.


> > 	http://cvs.uclinux.org/cgi-bin/cvsweb/elf2flt/
> > 
> > I don't believe there is SH support in it at the moment,  but it isn't a
> > huge amount of work. Generally only a few relocation types need to be
> > handled,
> 
> Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC
> supported. I'll submit patches for this once the above mess is worked
> out.

Sounds good.

By the way,  I subscribed to linuxsh-dev a month or so ago and haven't seen
any traffic.  It is working or am I missing something ?

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

Re: [uClinux-dev] Re: [linuxsh-dev] init problems on MMU-less SH-4

[Paul M. <le...@li...>]

On Sun, 2003-01-05 at 20:34, David McCullough wrote:
> I suspect that you are still running ELF programs.  When you turn off the
> MMU support in the kernel,  the rules for applications change a little.
> They cannot be paged in for example, and they have to be loaded (and
> relocated) at run time.  Normal elf programs are loaded at a fixed
> addresses and this cannot work without an MMU.
> 
> The uClinux guys use a program called elf2flt (ELF to flat) to make flat
> binaries that can be run without an MMU.  You can find it at:
> 
Okay, one issue with elf2flt. I've built a static busybox linked against
uClibc (which was built w/o HAS_MMU set), also using the sh-uclibc-
toolchain (which is also built w/o HAS_MMU). Now, this busybox itself
doesn't have any relocations in it, though it's still an ELF.

elf2flt currently bails and refuses to write the flt hdr/file if it sees
that the ELF doesn't have anything needing relocation. This happens
around line 900 of elf2flt.c from current HEAD by way of the
bfd_get_file_flags() HAS_RELOC check. If I comment this out, the flt
file is generated properly.

This brings up the question, if I have an ELF that was built with PIC
turned off, can binfmt_elf deal with it? or does it still have to pass
through binfmt_flat?

> 	http://cvs.uclinux.org/cgi-bin/cvsweb/elf2flt/
> 
> I don't believe there is SH support in it at the moment,  but it isn't a
> huge amount of work. Generally only a few relocation types need to be
> handled,

Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC
supported. I'll submit patches for this once the above mess is worked
out.

Regards,

-- 
Paul Mundt <le...@li...>

Re: [linuxsh-dev] init problems on MMU-less SH-4

[David M. <da...@sn...>]

Jivin Paul Mundt lays it down ...
> Hi,
> 
> Running into a bit of weirdness, and was curious if anyone had seen this
> before.
> 
> I'm presently running on an SH-4, with the MMU implicitly turned off
> (and CONFIG_MMU unset). I've taken care of dealing with paging_init()
> changes, tlb ops, etc. to deal with the lack of an MMU, and none of that
> appears to be an issue. 
> 
> My current problem is that the minute init tries to start, I get endless
> unaligned userspace access traps. If I implicitly flush the cache prior
> to turning the MMU off, I don't have this problem, instead it runs into
> a sort of livelock situation where init just hangs .. though I'm still
> able to ping the target. Flushing the tlb prior to turning the MMU off
> for added sanity doesn't seem to make a difference one way or the other.
> 
> Also, flushing the cache at context switch time (to work around
> potential aliasing issues, SH is VIPT) doesn't seem to make a difference
> here either. I haven't tried running uncached yet, though I doubt that's
> an issue here.
> 
> Anyone seen this kind of behavior before? Suggestions?

I suspect that you are still running ELF programs.  When you turn off the
MMU support in the kernel,  the rules for applications change a little.
They cannot be paged in for example, and they have to be loaded (and
relocated) at run time.  Normal elf programs are loaded at a fixed
addresses and this cannot work without an MMU.

The uClinux guys use a program called elf2flt (ELF to flat) to make flat
binaries that can be run without an MMU.  You can find it at:

	http://cvs.uclinux.org/cgi-bin/cvsweb/elf2flt/

I don't believe there is SH support in it at the moment,  but it isn't a
huge amount of work. Generally only a few relocation types need to be
handled,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

[linuxsh-dev] init problems on MMU-less SH-4

[Paul M. <le...@li...>]

Hi,

Running into a bit of weirdness, and was curious if anyone had seen this
before.

I'm presently running on an SH-4, with the MMU implicitly turned off
(and CONFIG_MMU unset). I've taken care of dealing with paging_init()
changes, tlb ops, etc. to deal with the lack of an MMU, and none of that
appears to be an issue. 

My current problem is that the minute init tries to start, I get endless
unaligned userspace access traps. If I implicitly flush the cache prior
to turning the MMU off, I don't have this problem, instead it runs into
a sort of livelock situation where init just hangs .. though I'm still
able to ping the target. Flushing the tlb prior to turning the MMU off
for added sanity doesn't seem to make a difference one way or the other.

Also, flushing the cache at context switch time (to work around
potential aliasing issues, SH is VIPT) doesn't seem to make a difference
here either. I haven't tried running uncached yet, though I doubt that's
an issue here.

Anyone seen this kind of behavior before? Suggestions?

Regards,

-- 
Paul Mundt <le...@li...>

[linuxsh-dev] hardware

[suspect <su...@su...>]

Hello,

I'm looking to get into running linux on the DC, and have heard
some reports about not all hardware/firmware combinations being
usable.

Could anyone kindly clarify any restrictions on what hardware
I'll have success on (I've heard things like HW manuf. after
a certain date wont work, etc.)

Also, I'm looking to buy several DCs (~10) for a group project.
Any pointers on a good source ?


Thanks much.

[linuxsh-dev] FS design

[Adrian M. <ad...@mc...>]

This is more a general filesystem design question than an SH specific one - 
but if is for the vmu fs on the dreamcast...

I am seeking to implement write on this (read only currently works). One can 
now successfully delete files on the system, but I am not sure how best to 
implement writing/creating a file.

Should creating a new file be handled in file::write, or is it dealt with by a 
dissferent set of system calls?

The vmu fs is FAT based so the "inode"s created are entirely synthetic - it is 
easy to 'create' an inode but there is a real dislocation between that and 
writing a file out to disk and I am just trying to get my head round the 
appropriate sequence of calls....

Adrian

Re: [linuxsh-dev] Improved TLB miss handler (second attempt)

[Stuart M. <stu...@st...>]

Hi Paul

On Mon, 18 Nov 2002 13:09:06 -0500 pau...@ti... wrote:

> Stuart,
> 
> Looks good. Do you have any performance numbers showing how this
> compares to the old handler?

I did some performance testing while writing the code, but thought I'd
better go back and get some figures from unmodified code for comparison.

This is all on a 200MHz ST40GX1 + 112MB RAM

1. Build util-linux from clean:

2.4.17		14m37
2.4.18		14m08
2.4.18+tlb	 8m55

All files accessed over NFS

2. Quake (timedemo demo1)

2.4.18		17.1 FPS
2.4.18+tlb	19.1 FPS

3. LMBench

LMBench figures are less impressive. Most are unchanged excpt those relating
to local communication, context switching (especially for processes with a
big footprint) and memory latency (second line is with the TLB patch):

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host                 OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                        ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
iptest102 Linux 2.4.18_  18.0  108.6  324.9  152.2  494.8   182.8   486.3
iptest102 Linux 2.4.18+  16.0  106.9  314.0  109.4  354.4   112.0   348.9

*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
iptest102 Linux 2.4.18_  18.0  60.5 128. 241.7 539.4 371.0 722.8 1116
iptest102 Linux 2.4.18+  16.0  54.2 126. 261.1 548.9 390.6 753.4 1144

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
iptest102 Linux 2.4.18_ 21.0 23.7 39.2   28.8  120.1   48.1   45.5 115.  93.9
iptest102 Linux 2.4.18+ 23.5 24.0 39.9   28.1  136.0   53.0   49.6 136. 100.4

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
---------------------------------------------------
Host                 OS   Mhz  L1 $   L2 $    Main mem    Guesses
--------- -------------  ---- ----- ------    --------    -------
iptest102 Linux 2.4.18_   200  10.0  182.9  295.7
iptest102 Linux 2.4.18+   200  10.0  183.0  189.4    No L2 cache?

The most intersting is actually the graph which LMBench produces showing
memory latency. Previously this had a massive shoulder as soon as the data
set became larger then 256K, ie as soon as as the data set became larger
than the TLB size. Worst case we saw 200nS access times reduced to 1000uS
Thats now down to a more reasonable 235nS.
> This looks like a good candidate to merge into the restructure branch as
> well. Can you roll a patch against that? (There's also some ST40 stuff
> in cache-sh4.c that wants your attention).

I'll give it a try, however there are a raft of other patches I'll
need to roll forwards to 2.5 first for basic board support. Most should
apply pretty cleanly, so it shouldn't take too long, and its something I've
been putting off doing so this will be a good oportunity.

Stuart

> On Mon, 2002-11-18 at 06:51, Stuart Menefy wrote:
> > Attached is my second attempt at an improved TLB miss handler.
> > 
> > Unfortuntaly the previous patch was corrupted, so I've double checked this
> > one, and it applies cleanly to 2.4 brach HEAD (2.4.20-pre10) and almost
> > cleanly to 2.4.18.
> > 
> > This should build for both SH3 and SH4, although it has only been tested
> > on SH4.
> > 
> 
> Regards,
> 
> -- 
> Paul Mundt
> pau...@ti...
> TimeSys Corporation
> 

Re: [linuxsh-dev] Improved TLB miss handler (second attempt)

[Stuart M. <stu...@st...>]

Leaving it unset for now should be fine. Its only needed if you have a
system with PCMCIA implemented using the HD64465 support chip, because of
the gross way the PCMCIA attributes are handled. 

If we think this is important, then a then a better solution would be
to shift the entire pte up up or down a few bits, allowing the PTEA bits
to be stored contiguously.

Stuart


On Mon, 18 Nov 2002 13:42:54 -0500 pau...@ti... wrote:

> Stuart,
> 
> On Mon, 2002-11-18 at 06:51, Stuart Menefy wrote:
> > This should build for both SH3 and SH4, although it has only been tested
> > on SH4.
> > 
> This will only build for the ST40 stuff at the moment, due to PCC_MASK
> being set on non-ST40 and then #error'ed on further down.
> 
> Since its something that needs testing, lets just leave it unset for now
> and then turn it back on later once things work and the #error gets
> yanked.
> 
> Thoughts?
> 
> Regards,
> 
> -- 
> Paul Mundt
> pau...@ti...
> TimeSys Corporation
> 

Re: [linuxsh-dev] Improved TLB miss handler (second attempt)

[Paul M. <pau...@ti...>]

Stuart,

On Mon, 2002-11-18 at 06:51, Stuart Menefy wrote:
> This should build for both SH3 and SH4, although it has only been tested
> on SH4.
>=20
This will only build for the ST40 stuff at the moment, due to PCC_MASK
being set on non-ST40 and then #error'ed on further down.

Since its something that needs testing, lets just leave it unset for now
and then turn it back on later once things work and the #error gets
yanked.

Thoughts?

Regards,

--=20
Paul Mundt
pau...@ti...
TimeSys Corporation

Re: [linuxsh-dev] Improved TLB miss handler (second attempt)

[Paul M. <pau...@ti...>]

Stuart,

Looks good. Do you have any performance numbers showing how this
compares to the old handler?

This looks like a good candidate to merge into the restructure branch as
well. Can you roll a patch against that? (There's also some ST40 stuff
in cache-sh4.c that wants your attention).

On Mon, 2002-11-18 at 06:51, Stuart Menefy wrote:
> Attached is my second attempt at an improved TLB miss handler.
>=20
> Unfortuntaly the previous patch was corrupted, so I've double checked thi=
s
> one, and it applies cleanly to 2.4 brach HEAD (2.4.20-pre10) and almost
> cleanly to 2.4.18.
>=20
> This should build for both SH3 and SH4, although it has only been tested
> on SH4.
>=20

Regards,

--=20
Paul Mundt
pau...@ti...
TimeSys Corporation

[linuxsh-dev] setup_irq bug

[Andriy S. <ask...@im...>]

Dear All,

this patch fixes  a bug in setup_irq().
It allows IDE code to run correctly.

Andriy Skulysh.

P.S. who is responsible for applying patches into CVS ?

[linuxsh-dev] Improved TLB miss handler (second attempt)

[Stuart M. <stu...@st...>]

Folks

Attached is my second attempt at an improved TLB miss handler.

Unfortuntaly the previous patch was corrupted, so I've double checked this
one, and it applies cleanly to 2.4 brach HEAD (2.4.20-pre10) and almost
cleanly to 2.4.18.

This should build for both SH3 and SH4, although it has only been tested
on SH4.

As always, all comments welcome

Stuart

[linuxsh-dev] Re: gcc-3.2 register allocation problem

[kaz K. <kk...@rr...>]

"peter garrone" <pga...@li...> wrote:
> Thanks. This patch that you sent me causes the compiler to produce
> correct code. I will describe how to reproduce the bug as far as
> possible. My apologies for the length of the post.

Congratulations! It is the patch by Niibe-san and was thrown
to the gcc mailing list already, but not applied to 3.2 branch.
Thanks for the testcase and details.

Regards,
	kaz

[linuxsh-dev] Re: gcc-3.2 register allocation problem

[peter g. <pga...@li...>]

Thanks. This patch that you sent me causes the compiler to produce correct code. I will describe how
to reproduce the bug as far as possible. My apologies for the length of the post.

--- reload1.c  Wed May 22 08:42:54 2002
+++ m17n/gcc-3.2-branch/gcc/reload1.c	Sat Aug 10 19:18:03 2002
@@ -6104,6 +6104,7 @@ merge_assigned_reloads (insn)
 	    for (j = 0; j < n_reloads; j++)
 	      if (rld[j].in != 0
 		  && rld[j].when_needed != RELOAD_OTHER
+		  && rld[j].when_needed != RELOAD_FOR_OUTPUT_ADDRESS
 		  && reg_overlap_mentioned_for_reload_p (rld[j].in,
 							 rld[i].in))
 		rld[j].when_needed





This is the program that causes the error, at line 87. It is compiled with the command
"mk6gcc -g -O2 -S -dAaPp testbug.c"

--------------------------------------------------------------------------------------------------
typedef unsigned long ulg;
typedef unsigned short ush;
typedef unsigned char uch;
ulg bb;
ulg bk;
static const unsigned border[] = { 16, 17, 18};

 const ush mask_bits[] = { 0x0000 };

#define NEXTBYTE()  (uch)get_byte()
#define NEEDBITS(n) {while(k<(n)){b|=((ulg)NEXTBYTE())<<k;k+=8;}}
#define DUMPBITS(n) {b>>=(n);k-=(n);}

struct huft {
  uch e;                /* number of extra bits or operation */
  uch b;                /* number of bits in this code or subcode */
  union {
    ush n;              /* literal, length base, or distance base */
    struct huft *t;     /* pointer to next level of table */
  } v;
};
#define NULL (0)

 const int lbits = 9;          /* bits in base literal/length lookup table */
 const int dbits = 6;          /* bits in base distance lookup table */

int inflate_dynamic()
/* decompress an inflated type 2 (dynamic Huffman codes) block. */
{
  int i;                /* temporary variables */
  unsigned j;
  unsigned l;           /* last length */
  unsigned m;           /* mask for bit lengths table */
  unsigned n;           /* number of lengths to get */
  struct huft *tl;      /* literal/length code table */
  struct huft *td;      /* distance code table */
  int bl;               /* lookup bits for tl */
  int bd;               /* lookup bits for td */
  unsigned nb;          /* number of bit length codes */
  unsigned nl;          /* number of literal/length codes */
  unsigned nd;          /* number of distance codes */
  unsigned ll[286+30];  /* literal/length and distance code lengths */
  register ulg b;       /* bit buffer */
  register unsigned k;  /* number of bits in bit buffer */


  /* make local bit buffer */
  b = bb;
  k = bk;


  /* read in table lengths */
  NEEDBITS(5)
  nl = 257 + ((unsigned)b & 0x1f);      /* number of literal/length codes */
  DUMPBITS(5)
  NEEDBITS(5)
  nd = 1 + ((unsigned)b & 0x1f);        /* number of distance codes */
  DUMPBITS(5)
  NEEDBITS(4)
  nb = 4 + ((unsigned)b & 0xf);         /* number of bit length codes */
  DUMPBITS(4)
  if (nl > 286 || nd > 30)
    return 1;                   /* bad lengths */


  /* read in bit-length-code lengths */
  for (j = 0; j < nb; j++)
  {
    NEEDBITS(3)
    ll[border[j]] = (unsigned)b & 7;
    DUMPBITS(3)
  }
  for (; j < 19; j++)
    ll[border[j]] = 0;

  /* build decoding table for trees--single level, 7 bit lookup */
  bl = 7;
  if ((i = huft_build(ll, 19, 19, NULL, NULL, &tl, &bl)) != 0)
  {
    if (i == 1)
      huft_free(tl);
    return i;                   /* incomplete code set */
  }

	
  /* read in literal and distance code lengths */
  n = nl + nd;  //Bug.
  m = mask_bits[bl];
  i = l = 0;
  while ((unsigned)i < n)
  {
    NEEDBITS((unsigned)bl)
    j = (td = tl + ((unsigned)b & m))->b;
    DUMPBITS(j)
    j = td->v.n;
    if (j < 16)                 /* length of code in bits (0..15) */
      ll[i++] = l = j;          /* save last length in l */
    else if (j == 16)           /* repeat last length 3 to 6 times */
    {
      NEEDBITS(2)
      j = 3 + ((unsigned)b & 3);
      DUMPBITS(2)
      if ((unsigned)i + j > n)
        return 1;
      while (j--)
        ll[i++] = l;
    }
  }

  return 0;
}
--------------------------------------------------------------------------------------------------
I will now describe the setup I am using.
I am using gcc-3.2, from the following source
http://mirror.aarnet.edu.au/pub/gcc/releases/gcc-3.2.tar.bz2

I am applying the following patch.
--------------------------------------------------------------------------------------------------
diff -ruN gcc-3.2.orig/gcc/config/sh/sh.h gcc-3.2/gcc/config/sh/sh.h
--- gcc-3.2.orig/gcc/config/sh/sh.h	Fri Feb 22 03:42:28 2002
+++ gcc-3.2/gcc/config/sh/sh.h	Mon Oct 21 09:06:18 2002
@@ -54,7 +54,7 @@
 %{m3e:-D__SH3E__} \
 %{m4-single-only:-D__SH4_SINGLE_ONLY__} \
 %{m4-single:-D__SH4_SINGLE__} \
-%{m4-nofpu:-D__sh3__ -D__SH4_NOFPU__} \
+%{m4-nofpu:-D__SH4__ -D__SH4_NOFPU__} \
 %{m4:-D__SH4__} \
 %{!m1:%{!m2:%{!m3*:%{!m4*:%{!m5*:%(cpp_default_cpu_spec)}}}}} \
 %{mhitachi:-D__HITACHI__} \
diff -ruN gcc-3.2.orig/gcc/configure gcc-3.2/gcc/configure
--- gcc-3.2.orig/gcc/configure	Sat Jun 29 10:20:11 2002
+++ gcc-3.2/gcc/configure	Mon Oct 21 08:03:34 2002
@@ -6789,13 +6789,17 @@
 # If this is using newlib, then define inhibit_libc in LIBGCC2_CFLAGS.
 # This prevents libgcc2 from containing any code which requires libc
 # support.
-inhibit_libc=
-if test x$host != x$target && test x$with_headers = x; then
-       inhibit_libc=-Dinhibit_libc
-else
-       if test x$with_newlib = xyes; then
-               inhibit_libc=-Dinhibit_libc
-       fi
+
+# If --without-headers was an option, then define inhibit_libc.
+# But if inhibit_libc is previously defined, leave it.
+if test x${inhibit_libc} = x
+then
+	if ( ( test x$host != x$target && test x$with_headers = x) \
+			|| ( test x${with_headers} = xno ) \
+			|| ( test x$with_newlib = xyes ) \
+	    ); then
+		inhibit_libc=-Dinhibit_libc
+	fi
 fi
--------------------------------------------------------------------------------------------------

I am using binutils from the same source.
http://mirror.aarnet.edu.au/pub/gnu/binutils/binutils-2.13.tar.bz2
No patches are applied.
I am using the following configuration script.
--------------------------------------------------------------------------------------------------
#/bin/sh
#Script to build the cross compiler toolchain.
#loosely derived from crossgcc FAQ (http://www.objsw.com/CrossGCC)
#
#Host and target parameter configuration.
host=i686-pc-linux-gnu
build=$host
target=sh-linux-gnu
#
#directories.
top=`pwd`
install=$top/install
prefix=$install
i=$install/bin
headers=$top/glibc/include
export PATH=$PATH:$i
#
#Various shell functions.
function delete_install()
{
	if test -d install
	then
		echo Removing existing install directory.
		rm -rf install
	fi
	mkdir install
}
function delete_build()
{
	if test -d build
	then
		echo Removing existing build directory.
		rm -rf build
	fi
	mkdir build
}

function configure_package()
{
	package=$1
	mkdir $package
	cd $package
	shift 1
	../../$package/configure \
		--program-prefix=mk6 \
		--target=$target \
		--prefix=$prefix \
		--host=$host \
		--build=$build \
		-v \
		$@
	cd ..
}

function config_make_binutils()
{
	configure_package binutils
	cd binutils
	make all install
	cd ..
}

function config_make_gcc_bootstrap()
{
	configure_package gcc \
		--without-headers \
		--enable-languages=c \
		--with-cpu=sh4 \
		--disable-threads \



	(cd gcc; make all install; cd ..; ) 

	#I am not completely sure why these executables
	#are not renamed for a cross compiler.
	#I copy them here anyway.

	ln -s sh-linux-gnu-gcc $i/mk6gcc
	ln -s sh-linux-gnu-cpp $i/mk6cpp
	ln -s sh-linux-gnu-gcc.1 $install/man/man1/mk6gcc.1
}

function config_make_gdb()
{
	configure_package gdb
	cd gdb
	make all install
	cd ..
}

#do the entire build and install.
delete_install
delete_build
cd build

config_make_binutils

config_make_gcc_bootstrap

#config_make_gdb
--------------------------------------------------------------------------------------------------





 

-- 
______________________________________________
http://www.linuxmail.org/
Now with POP3/IMAP access for only US$19.95/yr

Powered by Outblaze

[linuxsh-dev] Re: gcc-3.2 register allocation problem

[kaz K. <kk...@rr...>]

"peter garrone" <pga...@li...> wrote:
> Compiling boot/compressed/misc.c, a problem occurs in the function inflate_dynamic (include file inflate.c) (kernel version 2.5.13)
> At line inflate.c:805 "n = nl + nd;"
> The generated code, is as follows:
>  mov.w L106,r0
>  add r14,r0
>  mov.l @(8,r0),r1
>  mov.l @(12,r0),r0
>  add r0,r1
>  mov.l r1,@(4,r0)
[snip]
> I can provide a smallish (111 line) program to anyone interested, unfortunately any smaller and the bug disappears.

Please could you send it to the list?

BTW, which gcc-3.2 are you using? Were any patches applied to it?

Regards,
	kaz

[linuxsh-dev] gcc-3.2 register allocation problem

[peter g. <pga...@li...>]

Compiling boot/compressed/misc.c, a problem occurs in the function inflate_dynamic (include file inflate.c) (kernel version 2.5.13)
At line inflate.c:805 "n = nl + nd;"
The generated code, is as follows:
 mov.w L106,r0
 add r14,r0
 mov.l @(8,r0),r1
 mov.l @(12,r0),r0
 add r0,r1
 mov.l r1,@(4,r0)
The problem is that r0 is used as both a temporary base register, (r14 the frame pointer is out of range) 
and to hold the sum of the variables temporarily.
If the macro LEGITIMIZE_RELOAD_ADDRESS is not defined, then correct but slightly sub-optimal code is produced.
Optimization "-O2" must be used.
I can provide a smallish (111 line) program to anyone interested, unfortunately any smaller and the bug disappears.


-- 
______________________________________________
http://www.linuxmail.org/
Now with POP3/IMAP access for only US$19.95/yr

Powered by Outblaze

[linuxsh-dev] SuperH 2 Port?

[Paul M. <pau...@ti...>]

Hi all,

Some time ago there was various mentions of an SH-2 port floating
around, and Lineo also seems to claim to support it.

Does anyone know what the status of the port is? and more importantly
where the source can be obtained?

Also, on a slightly unrelated note, are there currently any other
MMUless platforms doing SMP?

Regards,

--=20
Paul Mundt
pau...@ti...
TimeSys Corporation

Re: [linuxsh-dev] pci

[David W. <dw...@in...>]

pau...@ti... said:
>  Linux exposes PCI access routines to do this in the form of
> pci_resource_start(pdev, BAR_nr) and pci_resource_len(pdev, BAR_nr),
> which you can pass to ioremap()/ioremap_nocache() directly to get a
> corresponding cached/uncached virtual address.

It is not a virtual address. It may look like one but that is only 
coincidence. It is a magic cookie for use with readb() et al., not an 
address.

--
dwmw2

Re: [linuxsh-dev] pread/pwrite fix for SH-4

[SUGIOKA T. <su...@it...>]

At 11:38 02/11/01 +0900, NIIBE Yutaka <gn...@m1...> wrote:
>I think that better way to solve this is implement pread with 6
>arguments with dummy fourth argument, as MIPS implementation.
>
>I mean, fix kernel, fix glibc, BOTH.

Here is a patch to fix pread/pwrite.
I'll commit to HEAD and 2.4 branch if no objections.

I have also attached glibc-2.2.5 patch (by kaz kojima) for your reference. 

Index: arch/sh/kernel/entry.S
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/entry.S,v
retrieving revision 1.1.1.1.2.11
diff -u -r1.1.1.1.2.11 entry.S
--- arch/sh/kernel/entry.S	1 Oct 2002 00:43:32 -0000	1.1.1.1.2.11
+++ arch/sh/kernel/entry.S	6 Nov 2002 03:54:33 -0000
@@ -1147,8 +1147,8 @@
 	.long SYMBOL_NAME(sys_rt_sigtimedwait)
 	.long SYMBOL_NAME(sys_rt_sigqueueinfo)
 	.long SYMBOL_NAME(sys_rt_sigsuspend)
-	.long SYMBOL_NAME(sys_pread)		/* 180 */
-	.long SYMBOL_NAME(sys_pwrite)
+	.long SYMBOL_NAME(sys_pread_wrapper)	/* 180 */
+	.long SYMBOL_NAME(sys_pwrite_wrapper)
 	.long SYMBOL_NAME(sys_chown16)
 	.long SYMBOL_NAME(sys_getcwd)
 	.long SYMBOL_NAME(sys_capget)
Index: arch/sh/kernel/sys_sh.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/sys_sh.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 sys_sh.c
--- arch/sh/kernel/sys_sh.c	15 Oct 2001 20:44:53 -0000	1.1.1.1
+++ arch/sh/kernel/sys_sh.c	6 Nov 2002 03:54:33 -0000
@@ -238,3 +238,19 @@
 	schedule();
 	return -ERESTARTNOHAND;
 }
+
+asmlinkage ssize_t sys_pread_wrapper(unsigned int fd, char * buf,
+			     size_t count, long dummy, loff_t pos)
+{
+	extern asmlinkage ssize_t sys_pread(unsigned int fd, char * buf,
+					size_t count, loff_t pos);
+	return sys_pread(fd, buf, count, pos);
+}
+
+asmlinkage ssize_t sys_pwrite_wrapper(unsigned int fd, const char * buf,
+			      size_t count, long dummy, loff_t pos)
+{
+	extern asmlinkage ssize_t sys_pwrite(unsigned int fd, const char * buf,
+					size_t count, loff_t pos);
+	return sys_pwrite(fd, buf, count, pos);
+}



diff -ruN glibc-2.2.5.orig/sysdeps/unix/sysv/linux/sh/pread.c glibc-2.2.5/sysdeps/unix/sysv/linux/sh/pread.c
--- glibc-2.2.5.orig/sysdeps/unix/sysv/linux/sh/pread.c	Thu Jan  1 09:00:00 1970
+++ glibc-2.2.5/sysdeps/unix/sysv/linux/sh/pread.c	Wed Nov  6 10:00:20 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/mips/pread.c>
diff -ruN glibc-2.2.5.orig/sysdeps/unix/sysv/linux/sh/pread64.c glibc-2.2.5/sysdeps/unix/sysv/linux/sh/pread64.c
--- glibc-2.2.5.orig/sysdeps/unix/sysv/linux/sh/pread64.c	Thu Jan  1 09:00:00 1970
+++ glibc-2.2.5/sysdeps/unix/sysv/linux/sh/pread64.c	Wed Nov  6 10:00:44 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/mips/pread64.c>
diff -ruN glibc-2.2.5.orig/sysdeps/unix/sysv/linux/sh/pwrite.c glibc-2.2.5/sysdeps/unix/sysv/linux/sh/pwrite.c
--- glibc-2.2.5.orig/sysdeps/unix/sysv/linux/sh/pwrite.c	Thu Jan  1 09:00:00 1970
+++ glibc-2.2.5/sysdeps/unix/sysv/linux/sh/pwrite.c	Wed Nov  6 10:01:32 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/mips/pwrite.c>
diff -ruN glibc-2.2.5.orig/sysdeps/unix/sysv/linux/sh/pwrite64.c glibc-2.2.5/sysdeps/unix/sysv/linux/sh/pwrite64.c
--- glibc-2.2.5.orig/sysdeps/unix/sysv/linux/sh/pwrite64.c	Thu Jan  1 09:00:00 1970
+++ glibc-2.2.5/sysdeps/unix/sysv/linux/sh/pwrite64.c	Wed Nov  6 10:01:15 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/mips/pwrite64.c>


----
SUGIOKA Toshinobu

Re: [linuxsh-dev] Patches for UBC contention (GDB) and cache flush (KGDB)

[Jeremy S. <js...@mv...>]

Paul Mundt wrote:
> Hi Jeremy,
> 
> On Tue, 2002-11-05 at 16:36, Jeremy Siegel wrote:
> 
>>If nobody objects, I'd like to add the two attached patches to the into 
>>our 2.4 tree.
>>
> 
> No objections here, though you might want to merge them into the
> restructure branch, since there's a few other ptrace changes .. and HEAD
> will be blown away with whatever is in there.
> 
> Also, in the future, it'd be helpful to attach the patches.
> 
> Regards,
> 

<RED_FACE>
Oops!
Here they are...
</RED_FACE>

Re: [linuxsh-dev] Patches for UBC contention (GDB) and cache flush (KGDB)

[Paul M. <pau...@ti...>]

Hi Jeremy,

On Tue, 2002-11-05 at 16:36, Jeremy Siegel wrote:
> If nobody objects, I'd like to add the two attached patches to the into=20
> our 2.4 tree.
>=20
No objections here, though you might want to merge them into the
restructure branch, since there's a few other ptrace changes .. and HEAD
will be blown away with whatever is in there.

Also, in the future, it'd be helpful to attach the patches.

Regards,

--=20
Paul Mundt
pau...@ti...
TimeSys Corporation