linuxsh-dev

Re: Irq priorities

[Manuel L. <ma...@ro...>]

Howdy,

On Wed, Jun 27, 2007 at 02:56:39PM +0200, EXTERNAL Brunner Markus (Praktikant;  ST-FIR/Eng) wrote:

> I have a question about the priority for the irqs. 
> I found that the priorities for the other CPUs, set in the setup-sh*.c
> are set as followed:
> low priority (2) for timers
> low priority (3) for sci(f) 
> high priority (7) for dma
> This doesn't make sens to me. I would give timers a high priority, so
> they keep acurate and dma a low priority. 
> 
> Are there any rules for setting the priority for interrupts? 

I guess this depends on the application the system is intended for.
I set DMABRG priority high on the SH7760 because audio needs them to
be handled as soon as possible (especially if you want to do low-latency
mixing and stuff [but that's impossible on the 7760 anyway ;-) ])

So I suggest you set priorities according to your specific needs.

	Manuel Lauss

Irq priorities

[EXTERNAL B. M. (P. ST-FIR/Eng) <ext...@de...>]

Hi there,

I have a question about the priority for the irqs.=20
I found that the priorities for the other CPUs, set in the setup-sh*.c
are set as followed:
low priority (2) for timers
low priority (3) for sci(f)=20
high priority (7) for dma
This doesn't make sens to me. I would give timers a high priority, so
they keep acurate and dma a low priority.=20

Are there any rules for setting the priority for interrupts?=20

Regards

Markus

2.6.22-rc6 on Dreamcast (SH4)

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

Still getting this:

 MODPOST vmlinux
WARNING: arch/sh/boards/dreamcast/built-in.o(.data+0x0): Section
mismatch: reference to .init.text: (between 'mv_dreamcast' and
'systemasic_int')
WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch: reference
to .init.data: (between 'pvr2fb_check_var' and 'pvr2fb_interrupt')
WARNING: drivers/built-in.o(.text+0x1701c): Section mismatch: reference
to .init.data: (between 'pvr2fb_pci_probe' and 'read_mem')
WARNING: drivers/built-in.o(.text+0x17024): Section mismatch: reference
to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
WARNING: drivers/built-in.o(.data+0x738): Section mismatch: reference
to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
WARNING: drivers/built-in.o(.data+0x750): Section mismatch: reference
to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')

But compiles and executes

Interrupt questions

[EXTERNAL B. M. (P. ST-FIR/Eng) <ext...@de...>]

Hello Paul et.al.,

currently I am porting SH7720 to 2.6.22 and I have a question about
interrupts.=20

Did I understand it right that all interrupts handling internal
peripherals are initialized using a setup-sh*.c and all peripherals that
are connected to external interrupt lines (IRQ*, PINT) are initialized
in boards/*/irq.c?
setup-sh7709.c also sets the priorities for IRQ0-5 which doesn't make
sens to me, also the comments to those irqs seem board-specific.

Regards,
Markus

re: Problems with -rc5 afterall on Dreamcast

[Kristoffer E. <kri...@gm...>]

Greetings Adrian,

I noticed around 2.6.19/2.6.20 that I got similiar warnings on both 6xx and
7xx builds. Everything works fine though, so not sure what its all about.

Best wishes
Kristoffer

Problems with -rc5 afterall on Dreamcast

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

Previously it had compiled and built cleanly, but when I added in the
sound driver I got this:

  MODPOST vmlinux
WARNING: arch/sh/boards/dreamcast/built-in.o(.data+0x0): Section
mismatch: reference to .init.text: (between 'mv_dreamcast' and
'systemasic_int')
WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch: reference
to .init.data: (between 'pvr2fb_check_var' and 'pvr2fb_interrupt')
WARNING: drivers/built-in.o(.text+0x1701c): Section mismatch: reference
to .init.data: (between 'pvr2fb_pci_probe' and 'read_mem')
WARNING: drivers/built-in.o(.text+0x17024): Section mismatch: reference
to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
WARNING: drivers/built-in.o(.data+0x738): Section mismatch: reference
to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
WARNING: drivers/built-in.o(.data+0x750): Section mismatch: reference
to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')

Re: Conflicting types for '__div64_32'

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

On Thu, Jun 21, 2007 at 07:34:19PM +0900, Katsuya MATSUBARA wrote:
>  I found an inconsistent declaration
>  in arch/sh/lib/div-generic.c in 2.6.21.
> 
>  the function 'div64_32()' in arch/sh/lib/div64-generic.c
>  returns a value of u64 type,
>  but the declaration of that function is
> 
>  extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
>         ^^^^^^^^
>  in include/asm-generic/div64.h
>  (which is referred by include/asm-sh/div64.h).
> 
Yes, div64_32() should be uint32_t, the result is passed back in r0, so
the u64 thing is pointless. I'll queue up a patch, but probably won't get
around to looking at it until after OLS.

Conflicting types for '__div64_32'

[Katsuya M. <ma...@ig...>]

 Hi,

 I found an inconsistent declaration
 in arch/sh/lib/div-generic.c in 2.6.21.

 the function 'div64_32()' in arch/sh/lib/div64-generic.c
 returns a value of u64 type,
 but the declaration of that function is

 extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
        ^^^^^^^^
 in include/asm-generic/div64.h
 (which is referred by include/asm-sh/div64.h).

 Thanks,
---
 Katsuya Matsubara @ Igel Co., Ltd
 matsu _a_t_ igel.co.jp 

RE: [PATCH] race in parallel out-of-tree build

[Johansson Erik-E. <eri...@mo...>]

> -----Original Message-----
> From: Paul Mundt [mailto:le...@li...]
> Can you try this with current git to see if it's still a problem? I'm
> unfortunately unable to reproduce this, even with a -j.

I tried 2.6.22-rc5 (git failed to clone sh-2.6.git) and was able to
reproduce the problem. If you add sleep 2 as the first command in the
two targets include/asm-sh/{.cpu,.mach} you should see it, without
having to rely on timing.

/Erik

Re: [PATCH] race in parallel out-of-tree build

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

On Wed, Jun 20, 2007 at 09:54:16AM +0100, Johansson Erik-EJO017 wrote:
> Output from building with -j 16 without my patch:
>   GEN     <long_path>/kernel-debug/Makefile
>   SYMLINK include/asm -> include/asm-sh
>   CHK     include/linux/version.h
>   Using <long_path>/linux-2.6.17 as source for kernel
>   SPLIT   include/linux/autoconf.h -> include/config/*
>   UPD     include/linux/version.h
>   SYMLINK include/asm-sh/cpu -> include/asm-sh/cpu-sh4
>   Generating include/asm-sh/machtypes.h
> /bin/sh: include/asm-sh/machtypes.h: No such file or directory
>   SYMLINK include/asm-sh/mach -> include/asm-sh/stb7100ref
> make[3]: *** [include/asm-sh/machtypes.h] Error 1
> make[2]: *** [maketools] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> The error above is what you get if you run (without an include/asm-sh
> dir):
> /bin/sh -c 'awk -f gen-mach-types mach-types >
> include/asm-sh/machtypes.h'
> 
Can you try this with current git to see if it's still a problem? I'm
unfortunately unable to reproduce this, even with a -j.

RE: [PATCH] race in parallel out-of-tree build

[Johansson Erik-E. <eri...@mo...>]

> -----Original Message-----
> From: Paul Mundt [mailto:le...@li...]
> Hmm.. Have you actually seen this as a problem? An easy way to
reproduce,
> or at least a log of the error would be nice. I don't seem to have any
> luck reproducing this. maketools depends on version.h, which is
generated
> by prepare1 in the top-level, which comes after archprepare in the
.PHONY
> list. The dependency ordering is explicit, in that each stage depends
on
> the previous one, so I still don't see anything wrong here. On the
other
> hand, if this is a valid bug, ARM also has this problem.

Output from building with -j 16 without my patch:
  GEN     <long_path>/kernel-debug/Makefile
  SYMLINK include/asm -> include/asm-sh
  CHK     include/linux/version.h
  Using <long_path>/linux-2.6.17 as source for kernel
  SPLIT   include/linux/autoconf.h -> include/config/*
  UPD     include/linux/version.h
  SYMLINK include/asm-sh/cpu -> include/asm-sh/cpu-sh4
  Generating include/asm-sh/machtypes.h
/bin/sh: include/asm-sh/machtypes.h: No such file or directory
  SYMLINK include/asm-sh/mach -> include/asm-sh/stb7100ref
make[3]: *** [include/asm-sh/machtypes.h] Error 1
make[2]: *** [maketools] Error 2
make[2]: *** Waiting for unfinished jobs....

The error above is what you get if you run (without an include/asm-sh
dir):
/bin/sh -c 'awk -f gen-mach-types mach-types >
include/asm-sh/machtypes.h'

The same, but with my patch:
  GEN     <long_path>/kernel-debug/Makefile
  SYMLINK include/asm -> include/asm-sh
  SPLIT   include/linux/autoconf.h -> include/config/*
  CHK     include/linux/version.h
  Using <long_path>/linux-2.6.17 as source for kernel
  UPD     include/linux/version.h
  Generating include/asm-sh/machtypes.h
  SYMLINK include/asm-sh/cpu -> include/asm-sh/cpu-sh4
  SYMLINK include/asm-sh/mach -> include/asm-sh/stb7100ref

In both cases you see that Generating include/asm-sh/machtypes.h comes
before creating the two symlinks (cpu and mach).

/Erik

Re: [PATCH] race in parallel out-of-tree build

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

On Wed, Jun 20, 2007 at 07:58:55AM +0100, Johansson Erik-EJO017 wrote:
> > -----Original Message-----
> > From: Paul Mundt [mailto:le...@li...]
> > which went in during the 2.6.16-rc1 merge window. So even your 2.6.17
> > tree should have this. Both of these are also FORCE'd (which is also
> > in the phony targets), so the race you describe should be impossible.
> > Confused.
> 
> Yes, we have it in our tree as well. The problem is that when building
> in parallel, the maketools target may be built before .cpu and .mach,
> resulting in a missing asm-sh directory. FORCE only forces the targets
> to be built every time, it doesn't force the ordering.
> 
Hmm.. Have you actually seen this as a problem? An easy way to reproduce,
or at least a log of the error would be nice. I don't seem to have any
luck reproducing this. maketools depends on version.h, which is generated
by prepare1 in the top-level, which comes after archprepare in the .PHONY
list. The dependency ordering is explicit, in that each stage depends on
the previous one, so I still don't see anything wrong here. On the other
hand, if this is a valid bug, ARM also has this problem.

RE: [PATCH] race in parallel out-of-tree build

[Johansson Erik-E. <eri...@mo...>]

> -----Original Message-----
> From: Paul Mundt [mailto:le...@li...]
> which went in during the 2.6.16-rc1 merge window. So even your 2.6.17
tree
> should have this. Both of these are also FORCE'd (which is also in the
> phony
> targets), so the race you describe should be impossible. Confused.

Yes, we have it in our tree as well. The problem is that when building
in parallel, the maketools target may be built before .cpu and .mach,
resulting in a missing asm-sh directory. FORCE only forces the targets
to be built every time, it doesn't force the ordering.

/Erik

Re: [PATCH] race in parallel out-of-tree build

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

On Tue, Jun 19, 2007 at 11:55:55AM +0100, Johansson Erik-EJO017 wrote:
> Depending on which of the three dependencies for archprepare (in
> arch/sh/Makefile) get built first, the directory include/asm-sh may or
> may not exist when the maketools target is built. If the directory does
> not exist, awk will fail to generate machtypes.h. This patch fixes this
> by creating the directory before awk is executed.
> 
[snip]

> Diff from linux-2.6.17, but the file hasn't changed in sh-2.6.git tree,
> so it should apply there as well.
> 
I'm not sure what sh-2.6.git tree you're looking at, but mine already has
this for the .cpu and .mach cookies:

include/asm-sh/.cpu: $(wildcard include/config/cpu/*.h) \
                     include/config/auto.conf FORCE
        @echo '  SYMLINK include/asm-sh/cpu -> include/asm-sh/$(cpuincdir-y)'
        $(Q)if [ ! -d include/asm-sh ]; then mkdir -p include/asm-sh; fi

...

include/asm-sh/.mach: $(wildcard include/config/sh/*.h) \
                      include/config/auto.conf FORCE
        @echo -n '  SYMLINK include/asm-sh/mach -> '
        $(Q)if [ ! -d include/asm-sh ]; then mkdir -p include/asm-sh; fi
...

git-annotate points at cad8244840d1a148f638925758afd1cdf81fc839 when this
particular change happened:

cad8244840d1a148f638925758afd1cdf81fc839        (Paul Mundt     2006-01-16 22:14:19 -0800       153)    $(Q)if [ ! -d include/asm-sh ]; then mkdir -p include/asm-sh; fi

which happens to be:

commit cad8244840d1a148f638925758afd1cdf81fc839
Author: Paul Mundt <le...@li...>
Date:   Mon Jan 16 22:14:19 2006 -0800

    [PATCH] sh: Move CPU subtype configuration to its own Kconfig

...

which went in during the 2.6.16-rc1 merge window. So even your 2.6.17 tree
should have this. Both of these are also FORCE'd (which is also in the phony
targets), so the race you describe should be impossible. Confused.

[PATCH] race in parallel out-of-tree build

[Johansson Erik-E. <eri...@mo...>]

sh: fix race in parallel out-of-tree build

Depending on which of the three dependencies for archprepare (in
arch/sh/Makefile) get built first, the directory include/asm-sh may or
may not exist when the maketools target is built. If the directory does
not exist, awk will fail to generate machtypes.h. This patch fixes this
by creating the directory before awk is executed.

Signed-off-by: Erik Johansson <eri...@mo...>
---
Diff from linux-2.6.17, but the file hasn't changed in sh-2.6.git tree,
so it should apply there as well.

--- linux-2.6.17/arch/sh/tools/Makefile~	2006-06-18
03:49:35.000000000 +0200
+++ linux-2.6.17/arch/sh/tools/Makefile	2007-06-19 11:20:05.000000000
+0200
@@ -12,4 +12,5 @@
=20
 include/asm-sh/machtypes.h: $(src)/gen-mach-types $(src)/mach-types
 	@echo '  Generating $@'
+	$(Q)if [ ! -d include/asm-sh ]; then mkdir -p include/asm-sh; fi
 	$(Q)$(AWK) -f $^ > $@ || { rm -f $@; /bin/false; }

Re: Syscall restarted with the clobbered 5th argument

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

On Mon, Jun 18, 2007 at 12:00:39PM +0100, Carl Shaw wrote:
> I found another minor problem as well - we are missing a test for
> -ERESTART_RESTARTBLOCK in handle_signal().
> 
> This fixes the LTP test nanosleep03 - the current kernel causes
> -ERESTART_RESTARTBLOCK to reach user space rather than the correct
> -EINTR.

Hmm, wonder how we missed that. Looks like sh64 needs it too. I'll queue
up a fix for 2.6.22, thanks Carl.

Re: Syscall restarted with the clobbered 5th argument

[Carl S. <sha...@gm...>]

Hi Kaz,

I've just fixed the same problem (in exactly the same way) in our
2.6.17 ST kernel!  It causes a failure in the glibc test tst-eintr1.

I found another minor problem as well - we are missing a test for
-ERESTART_RESTARTBLOCK in handle_signal().

i.e.

switch (regs->regs[0]) {
                        case -ERESTARTNOHAND:
                                regs->regs[0] = -EINTR;
                                break;

should be

switch (regs->regs[0]) {
                        case -ERESTART_RESTARTBLOCK:
                        case -ERESTARTNOHAND:
                                regs->regs[0] = -EINTR;
                                break;

(Apologies for lack of patch but it is only a one line change and I
don't have a copy of the latest git kernel handy).

This fixes the LTP test nanosleep03 - the current kernel causes
-ERESTART_RESTARTBLOCK to reach user space rather than the correct
-EINTR.

Slightly off-topic for the kernel mailing list, this work came about
because we are experiencing occasional problems with SH4 thread
unwinding after a pthread_cancel() and the ensuing signal.  I'll email
you more information off-list as well as some other SH glibc fixes we
have.

Carl

On 6/16/07, Kaz Kojima <kk...@rr...> wrote:
> Hi,
>
> I'm working on the latest GNU libc with the 2.6.22-rc4 kernel and
> I've found a few kernel problems.  This is the first one.
>
> We use R0 as the 5th argument of syscall.  When the syscall restarts
> after signal handling, we should restore the old value of R0.
> The attached patch does it.  Without this patch, I've experienced random
> failures in the situation which signals are issued frequently.
>
> Regards,
>         kaz
>
> Signed-off-by: Kaz Kojima <kk...@rr...>
>
> --- GIT/linux-2.6/arch/sh/kernel/signal.c       2007-06-09 07:33:58.000000000 +0900
> +++ linux-2.6.22-rc4/arch/sh/kernel/signal.c    2007-06-15 10:56:43.000000000 +0900
> @@ -481,7 +481,7 @@ give_sigsegv:
>
>  static int
>  handle_signal(unsigned long sig, struct k_sigaction *ka, siginfo_t *info,
> -             sigset_t *oldset, struct pt_regs *regs)
> +             sigset_t *oldset, struct pt_regs *regs, unsigned int save_r0)
>  {
>         int ret;
>
> @@ -500,6 +500,7 @@ handle_signal(unsigned long sig, struct
>                                 }
>                         /* fallthrough */
>                         case -ERESTARTNOINTR:
> +                               regs->regs[0] = save_r0;
>                                 regs->pc -= instruction_size(
>                                                 ctrl_inw(regs->pc - 4));
>                                 break;
> @@ -583,7 +584,8 @@ static void do_signal(struct pt_regs *re
>         signr = get_signal_to_deliver(&info, &ka, regs, NULL);
>         if (signr > 0) {
>                 /* Whee!  Actually deliver the signal.  */
> -               if (handle_signal(signr, &ka, &info, oldset, regs) == 0) {
> +               if (handle_signal(signr, &ka, &info, oldset, regs, save_r0)
> +                   == 0) {
>                         /* a signal was successfully delivered; the saved
>                          * sigmask will have been stored in the signal frame,
>                          * and will be restored by sigreturn, so we can simply
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>

Re: What's in sh-2.6.23.git

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

On Mon, Jun 18, 2007 at 12:57:21PM +0900, Paul Mundt wrote:
> and either SLUB + http://marc.info/?l=linux-mm&m=118127614524083&w=2,

And that's of course supposed to be:

	http://marc.info/?l=linux-mm&m=118127688911359&w=2

What's in sh-2.6.23.git

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

Now that 2.6.22 is winding down, it's time to review what's going on for
the 2.6.23 merge window. The big changes so far are mostly centered
around NUMA and sparsemem support, rework of the IRQ controllers and the
machvec, as well as some Kconfig reordering (we're now in much better
shape to survive allyesconfig/allmodconfig/randconfig for regression
testing).

There's quite a bit of SMP code also, for 4-way SH-X3, so some of that
will make it in, with most of the later 2.6.23-rc's then being targetted
at fixing up a lot of the remaining locking issues and so on.

multi-node NUMA is presently only wired up on SH-MobileR (SH7722),
particularly its URAM block (128kB SRAM), but SH7785 and others will
follow, all the way up to 6-nodes for SH-X3. There'll be some
documentation on the wiki a bit later on how to work with it, for those
that are interested.

There are a couple outstanding patches required to make use of this,
including changing the node interleave map for kernel data structure
spreading at system init time, which can be found here:

	http://marc.info/?l=linux-mm&m=118117916022379&w=2

and either SLUB + http://marc.info/?l=linux-mm&m=118127614524083&w=2,
or SLOB + http://marc.info/?l=linux-mm&m=118213456808163&w=2

SLAB is also possible, but is quite heavy on the non-reclaimable slab
pages, so is better avoided for tiny nodes. cpusets + page migration is
also possible, but with a node this small, page migration is best
avoided. Simply mounting the node with a mempolicy via tmpfs or using
libnuma is the best way for applications to make use of the memory
(remember that URAM access bypasses the cache controller!).

The outstanding patches should also be merged during the -rc1 window, via
alternate channels.

The queue so far:

Magnus Damm (2):
      sh: rework intc2 code
      sh: rework ipr code

Nobuhiro Iwamatsu (1):
      sh: Add L-BOX RE2 to mach-types.

Paul Mundt (37):
      sh: Split out CPU topology initialization.
      sh: __user annotations for __get/__put_user().
      sh: Fixup machvec support.
      sh: Shut up SH2-DSP compile warnings.
      sh: Rework CPU/board dependencies.
      sh: Fixup cmdline handling from machvec changes.
      sh: Get multiple boards in one image working again.
      sh: Kill off machvec aliases.
      sh: Rip out special unknown machvec.
      sh: Fix SH-4 CPU selects.
      sh: pfn_valid() depends on flatmem.
      sh: sparsemem support.
      sh: Allow for bootmem debug support.
      sh: Register multiple nodes in topology_init().
      sh: Mark sparsemem regions present earlier.
      sh: Enable IPR-IRQ for SH7206.
      sh: Wrap CPU tuning through cc-option.
      sh: Tidy compiler warnings for SH-2A build.
      sh: Wire up mempolicy syscalls.
      sh: Default to 4-byte alignment for SLUB objects.
      sh: Fix up max_zone_pfns[] with multiple nodes.
      sh: Use asm/sections.h for linker section symbols.
      sh: Support for multiple nodes.
      sh: URAM node support for SH7722.
      sh: Make NUMA depend on sparsemem.
      sh: Fix the SH7722 flatmem build.
      sh: Fix up cpu to node mapping in sysfs.
      sh: memory hot-add for sparsemem users support.
      sh: Kill off dead SH7604 support.
      sh: Compile fix for SH7604 removal.
      sh: Tidy up dependencies for SH-2 build.
      sh: Fixup misaligned data for sh2 lockdep.
      fs: hugetlbfs: Disable for shnommu.
      sh: Kill off broken dma page ops.
      sh: Fix up the math-emu build.
      sh: Only support PMB for SH-X cores.
      sh: Update SH-2/SH-2A defconfigs.

Robert P. J. Day (1):
      sh: Warn against direct inclusion of <asm/rwsem.h>.

Takashi YOSHII (1):
      sh: Align .machvec.init section on a 4-byte boundary.

Yoshihiro Shimoda (1):
      sh: Provide a defconfig for R7780MP.

 arch/sh/Kconfig                             |  355 ++++----
 arch/sh/Kconfig.debug                       |    5 +
 arch/sh/Makefile                            |   98 ++-
 arch/sh/boards/dreamcast/setup.c            |    3 +-
 arch/sh/boards/hp6xx/mach.c                 |    4 +-
 arch/sh/boards/hp6xx/setup.c                |    3 +-
 arch/sh/boards/landisk/setup.c              |    3 +-
 arch/sh/boards/lboxre2/setup.c              |    3 +-
 arch/sh/boards/mpc1211/setup.c              |    3 +-
 arch/sh/boards/renesas/edosk7705/setup.c    |    3 +-
 arch/sh/boards/renesas/hs7751rvoip/setup.c  |    3 +-
 arch/sh/boards/renesas/r7780rp/Kconfig      |    6 +-
 arch/sh/boards/renesas/r7780rp/setup.c      |    3 +-
 arch/sh/boards/renesas/rts7751r2d/setup.c   |    3 +-
 arch/sh/boards/renesas/sh7710voipgw/setup.c |    3 +-
 arch/sh/boards/renesas/systemh/setup.c      |    3 +-
 arch/sh/boards/saturn/Makefile              |    8 -
 arch/sh/boards/saturn/io.c                  |   26 -
 arch/sh/boards/saturn/irq.c                 |  118 ---
 arch/sh/boards/saturn/setup.c               |   31 -
 arch/sh/boards/saturn/smp.c                 |   68 --
 arch/sh/boards/se/7206/setup.c              |    3 +-
 arch/sh/boards/se/7300/setup.c              |    3 +-
 arch/sh/boards/se/73180/setup.c             |    3 +-
 arch/sh/boards/se/7343/setup.c              |    3 +-
 arch/sh/boards/se/7619/setup.c              |    3 +-
 arch/sh/boards/se/770x/irq.c                |  124 ++--
 arch/sh/boards/se/770x/setup.c              |    3 +-
 arch/sh/boards/se/7722/irq.c                |   15 +-
 arch/sh/boards/se/7722/setup.c              |    3 +-
 arch/sh/boards/se/7751/irq.c                |   59 +-
 arch/sh/boards/se/7751/setup.c              |    3 +-
 arch/sh/boards/se/7780/irq.c                |   45 +-
 arch/sh/boards/se/7780/setup.c              |    3 +-
 arch/sh/boards/sh03/setup.c                 |   31 +-
 arch/sh/boards/shmin/setup.c                |   33 +-
 arch/sh/boards/snapgear/setup.c             |   31 +-
 arch/sh/boards/superh/microdev/setup.c      |    3 +-
 arch/sh/boards/titan/setup.c                |   25 +-
 arch/sh/boards/unknown/Makefile             |    6 -
 arch/sh/boards/unknown/setup.c              |   21 -
 arch/sh/cchips/Kconfig                      |    6 +-
 arch/sh/configs/r7780mp_defconfig           | 1223 +++++++++++++++++++++++++++
 arch/sh/configs/se7206_defconfig            |  272 ++----
 arch/sh/configs/se7619_defconfig            |  215 ++----
 arch/sh/drivers/dma/Kconfig                 |   17 -
 arch/sh/drivers/pci/Kconfig                 |    1 +
 arch/sh/kernel/Makefile                     |    9 +-
 arch/sh/kernel/cf-enabler.c                 |    6 +-
 arch/sh/kernel/cpu/init.c                   |   15 +-
 arch/sh/kernel/cpu/irq/intc2.c              |   58 +-
 arch/sh/kernel/cpu/irq/ipr.c                |   59 +-
 arch/sh/kernel/cpu/sh2/entry.S              |    1 +
 arch/sh/kernel/cpu/sh2/probe.c              |   13 +-
 arch/sh/kernel/cpu/sh2/setup-sh7619.c       |   24 +-
 arch/sh/kernel/cpu/sh2a/setup-sh7206.c      |   24 +-
 arch/sh/kernel/cpu/sh3/setup-sh7705.c       |   40 +-
 arch/sh/kernel/cpu/sh3/setup-sh7709.c       |   84 ++-
 arch/sh/kernel/cpu/sh3/setup-sh7710.c       |   42 +-
 arch/sh/kernel/cpu/sh4/Makefile             |    4 +
 arch/sh/kernel/cpu/sh4/setup-sh7750.c       |   58 +-
 arch/sh/kernel/cpu/sh4/setup-sh7760.c       |   45 +-
 arch/sh/kernel/cpu/sh4a/setup-sh7722.c      |   29 +-
 arch/sh/kernel/cpu/sh4a/setup-sh7780.c      |   15 +-
 arch/sh/kernel/cpu/sh4a/setup-sh7785.c      |   16 +-
 arch/sh/kernel/machvec.c                    |  130 +++
 arch/sh/kernel/process.c                    |   18 +-
 arch/sh/kernel/ptrace.c                     |    8 +-
 arch/sh/kernel/setup.c                      |  208 +----
 arch/sh/kernel/signal.c                     |    5 +-
 arch/sh/kernel/syscalls.S                   |    6 +-
 arch/sh/kernel/topology.c                   |   49 ++
 arch/sh/kernel/traps.c                      |    5 +-
 arch/sh/kernel/vmlinux.lds.S                |    4 +-
 arch/sh/math-emu/math.c                     |   18 +-
 arch/sh/mm/Kconfig                          |   77 +-
 arch/sh/mm/Makefile                         |    5 +-
 arch/sh/mm/init.c                           |  107 ++-
 arch/sh/mm/numa.c                           |   92 ++
 arch/sh/mm/pg-dma.c                         |   95 ---
 arch/sh/tools/mach-types                    |    2 +-
 drivers/serial/sh-sci.h                     |   25 +-
 fs/Kconfig                                  |    2 +-
 include/asm-sh/bugs.h                       |    2 +-
 include/asm-sh/cache.h                      |    4 +
 include/asm-sh/cpu-sh2/cache.h              |   20 +-
 include/asm-sh/hd64461.h                    |    2 +-
 include/asm-sh/hw_irq.h                     |   42 +
 include/asm-sh/irq.h                        |   40 -
 include/asm-sh/machvec.h                    |    4 +-
 include/asm-sh/machvec_init.h               |   53 --
 include/asm-sh/mmzone.h                     |   46 +
 include/asm-sh/page.h                       |   10 +
 include/asm-sh/processor.h                  |    6 +-
 include/asm-sh/rwsem.h                      |    6 +-
 include/asm-sh/saturn/io.h                  |   19 -
 include/asm-sh/saturn/smpc.h                |   34 -
 include/asm-sh/sections.h                   |    2 +-
 include/asm-sh/setup.h                      |    1 +
 include/asm-sh/sh03/io.h                    |    4 -
 include/asm-sh/snapgear.h                   |    4 -
 include/asm-sh/sparsemem.h                  |   16 +
 include/asm-sh/system.h                     |   16 +-
 include/asm-sh/topology.h                   |   30 +
 include/asm-sh/uaccess.h                    |   40 +-
 include/asm-sh/ubc.h                        |    9 +-
 mm/Kconfig                                  |    2 +-
 107 files changed, 2854 insertions(+), 1862 deletions(-)

Re: [linux] Re: Give a functional include/asm-sh/futex.h

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

Paul Mundt <le...@li...> wrote:
> How about this?
> 
> I think your FUTEX_OP_ANDN implementation was buggy, since you were doing
> oldval & oparg instead of oldval & ~oparg..

Looks fine.  Thanks!

Regards,
	kaz

Re: Give a functional include/asm-sh/futex.h

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

On Mon, Jun 18, 2007 at 11:34:30AM +0900, Kaz Kojima wrote:
> Paul Mundt <le...@li...> wrote:
> > Yes, but I'm rather concerned about the size, perhaps we should
> > and move it out-of-line and inline the op handlers?
> >
> > If we just have a set of atomic_futex_op_xxx() ops that correspond to
> > each FUTEX_OP_xxx that are inlined in futex.h (FR-V seems to do this
> > already, in arch/frv/kernel/futex.c), futex_atomic_op_inuser() can be
> > brought out-of-line without any trouble, and we can bury all of the
> > local_irq_xxx() mess in the futex op itself.
> 
> Looks not so different with atomic.h and I always prefer to follow
> the x86 way :-)  But, anyway, either way looks ok.
> 
How about this?

I think your FUTEX_OP_ANDN implementation was buggy, since you were doing
oldval & oparg instead of oldval & ~oparg..

--

 include/asm-sh/futex-irq.h |  111 +++++++++++++++++++++++++++++++++++++++++++++
 include/asm-sh/futex.h     |   79 ++++++++++++++++++++++++++++++--
 2 files changed, 186 insertions(+), 4 deletions(-)

diff --git a/include/asm-sh/futex.h b/include/asm-sh/futex.h
index 6a332a9..54d98b3 100644
--- a/include/asm-sh/futex.h
+++ b/include/asm-sh/futex.h
@@ -1,6 +1,77 @@
-#ifndef _ASM_FUTEX_H
-#define _ASM_FUTEX_H
+#ifndef __ASM_FUTEX_H
+#define __ASM_FUTEX_H
 
-#include <asm-generic/futex.h>
+#ifdef __KERNEL__
 
-#endif
+#include <linux/futex.h>
+#include <asm/errno.h>
+#include <asm/uaccess.h>
+
+/* XXX: UP variants, fix for SH-4A and SMP.. */
+#include <asm/futex-irq.h>
+
+static inline int futex_atomic_op_inuser(int encoded_op, int __user *uaddr)
+{
+	int op = (encoded_op >> 28) & 7;
+	int cmp = (encoded_op >> 24) & 15;
+	int oparg = (encoded_op << 8) >> 20;
+	int cmparg = (encoded_op << 20) >> 20;
+	int oldval = 0, ret;
+
+	if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
+		oparg = 1 << oparg;
+
+	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
+		return -EFAULT;
+
+	pagefault_disable();
+
+	switch (op) {
+	case FUTEX_OP_SET:
+		ret = atomic_futex_op_xchg_set(oparg, uaddr, &oldval);
+		break;
+	case FUTEX_OP_ADD:
+		ret = atomic_futex_op_xchg_add(oparg, uaddr, &oldval);
+		break;
+	case FUTEX_OP_OR:
+		ret = atomic_futex_op_xchg_or(oparg, uaddr, &oldval);
+		break;
+	case FUTEX_OP_ANDN:
+		ret = atomic_futex_op_xchg_and(~oparg, uaddr, &oldval);
+		break;
+	case FUTEX_OP_XOR:
+		ret = atomic_futex_op_xchg_xor(oparg, uaddr, &oldval);
+		break;
+	default:
+		ret = -ENOSYS;
+		break;
+	}
+
+	pagefault_enable();
+
+	if (!ret) {
+		switch (cmp) {
+		case FUTEX_OP_CMP_EQ: ret = (oldval == cmparg); break;
+		case FUTEX_OP_CMP_NE: ret = (oldval != cmparg); break;
+		case FUTEX_OP_CMP_LT: ret = (oldval < cmparg); break;
+		case FUTEX_OP_CMP_GE: ret = (oldval >= cmparg); break;
+		case FUTEX_OP_CMP_LE: ret = (oldval <= cmparg); break;
+		case FUTEX_OP_CMP_GT: ret = (oldval > cmparg); break;
+		default: ret = -ENOSYS;
+		}
+	}
+
+	return ret;
+}
+
+static inline int
+futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
+{
+	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
+		return -EFAULT;
+
+	return atomic_futex_op_cmpxchg_inatomic(uaddr, oldval, newval);
+}
+
+#endif /* __KERNEL__ */
+#endif /* __ASM_SH_FUTEX_H */
diff --git a/dev/null b/include/asm-sh/futex-irq.h
new file mode 100644
index 0000000..a9f16a7
--- /dev/null
+++ b/include/asm-sh/futex-irq.h
@@ -0,0 +1,111 @@
+#ifndef __ASM_SH_FUTEX_IRQ_H
+#define __ASM_SH_FUTEX_IRQ_H
+
+#include <asm/system.h>
+
+static inline int atomic_futex_op_xchg_set(int oparg, int __user *uaddr,
+					   int *oldval)
+{
+	unsigned long flags;
+	int ret;
+
+	local_irq_save(flags);
+
+	ret = get_user(*oldval, uaddr);
+	if (!ret)
+		ret = put_user(oparg, uaddr);
+
+	local_irq_restore(flags);
+
+	return ret;
+}
+
+static inline int atomic_futex_op_xchg_add(int oparg, int __user *uaddr,
+					   int *oldval)
+{
+	unsigned long flags;
+	int ret;
+
+	local_irq_save(flags);
+
+	ret = get_user(*oldval, uaddr);
+	if (!ret)
+		ret = put_user(*oldval + oparg, uaddr);
+
+	local_irq_restore(flags);
+
+	return ret;
+}
+
+static inline int atomic_futex_op_xchg_or(int oparg, int __user *uaddr,
+					  int *oldval)
+{
+	unsigned long flags;
+	int ret;
+
+	local_irq_save(flags);
+
+	ret = get_user(*oldval, uaddr);
+	if (!ret)
+		ret = put_user(*oldval | oparg, uaddr);
+
+	local_irq_restore(flags);
+
+	return ret;
+}
+
+static inline int atomic_futex_op_xchg_and(int oparg, int __user *uaddr,
+					   int *oldval)
+{
+	unsigned long flags;
+	int ret;
+
+	local_irq_save(flags);
+
+	ret = get_user(*oldval, uaddr);
+	if (!ret)
+		ret = put_user(*oldval & oparg, uaddr);
+
+	local_irq_restore(flags);
+
+	return ret;
+}
+
+static inline int atomic_futex_op_xchg_xor(int oparg, int __user *uaddr,
+					   int *oldval)
+{
+	unsigned long flags;
+	int ret;
+
+	local_irq_save(flags);
+
+	ret = get_user(*oldval, uaddr);
+	if (!ret)
+		ret = put_user(*oldval ^ oparg, uaddr);
+
+	local_irq_restore(flags);
+
+	return ret;
+}
+
+static inline int atomic_futex_op_cmpxchg_inatomic(int __user *uaddr,
+						   int oldval, int newval)
+{
+	unsigned long flags;
+	int ret, prev = 0;
+
+	local_irq_save(flags);
+
+	ret = get_user(prev, uaddr);
+	if (!ret && oldval == prev)
+		ret = put_user(newval, uaddr);
+
+	local_irq_restore(flags);
+
+	if (ret)
+		return ret;
+
+	return prev;
+}
+
+#endif /* __ASM_SH_FUTEX_IRQ_H */

Re: Give a functional include/asm-sh/futex.h

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

Paul Mundt <le...@li...> wrote:
> Yes, but I'm rather concerned about the size, perhaps we should
> and move it out-of-line and inline the op handlers?
>
> If we just have a set of atomic_futex_op_xxx() ops that correspond to
> each FUTEX_OP_xxx that are inlined in futex.h (FR-V seems to do this
> already, in arch/frv/kernel/futex.c), futex_atomic_op_inuser() can be
> brought out-of-line without any trouble, and we can bury all of the
> local_irq_xxx() mess in the futex op itself.

Looks not so different with atomic.h and I always prefer to follow
the x86 way :-)  But, anyway, either way looks ok.

> Also, is futex_atomic_cmpxchg_inatomic() required, or should this simply
> be a -ENOSYS if we don't have ll/sc methods? It seems like kernel/futex.c
> handles the -ENOSYS case ok, and other platforms do return this way.

Former, I believe.  It looks that kernel simply ignore such platforms
in full futex support which is required by glibc.  In general, platforms
without ll/sc-like can't use nptl and aren't target of current glibc in
the first place.  SH is an exception in this regard by virtue of gUSA.

Regards,
	kaz

Re: Give a functional include/asm-sh/futex.h

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

On Mon, Jun 18, 2007 at 10:11:47AM +0900, Kaz Kojima wrote:
> Paul Mundt <le...@li...> wrote:
> > Hmm.. this all looks terribly generic, if glibc requires the generic
> > implementation to be extended, perhaps this change should be made against
> > asm-generic/futex.h instead?
> 
> Perhaps if local_irq_* are removed, as I can't find any use of
> them in asm-generic/*.h.  It seems to me that the situation is
> quite similar to atomic.h.  So asm-sh/futex.h which includes
> asm-sh/futex-irq.h and asm-sh/futex-llsc.h selectively might
> be a way to go, though I have no strong opinion.
> 
Yes, but I'm rather concerned about the size, perhaps we should
and move it out-of-line and inline the op handlers?

If we just have a set of atomic_futex_op_xxx() ops that correspond to
each FUTEX_OP_xxx that are inlined in futex.h (FR-V seems to do this
already, in arch/frv/kernel/futex.c), futex_atomic_op_inuser() can be
brought out-of-line without any trouble, and we can bury all of the
local_irq_xxx() mess in the futex op itself.

Also, is futex_atomic_cmpxchg_inatomic() required, or should this simply
be a -ENOSYS if we don't have ll/sc methods? It seems like kernel/futex.c
handles the -ENOSYS case ok, and other platforms do return this way.

Re: Give a functional include/asm-sh/futex.h

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

Paul Mundt <le...@li...> wrote:
> Hmm.. this all looks terribly generic, if glibc requires the generic
> implementation to be extended, perhaps this change should be made against
> asm-generic/futex.h instead?

Perhaps if local_irq_* are removed, as I can't find any use of
them in asm-generic/*.h.  It seems to me that the situation is
quite similar to atomic.h.  So asm-sh/futex.h which includes
asm-sh/futex-irq.h and asm-sh/futex-llsc.h selectively might
be a way to go, though I have no strong opinion.

Regards,
	kaz

Re: Terminate .eh_frame in VDSO with a 4-byte 0

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

On Sun, Jun 17, 2007 at 07:23:32AM +0900, Kaz Kojima wrote:
> The 2nd one is about VDSO.
> It's assumed that .eh_frame is terminated with 4-byte 0 in shared
> libraries and executable.  It seems to be the case for VDSOs too.
> Without this terminator, I saw failures when unwinding from VDSO,
> though I don't know how other architectures handle this issue.
> For the normal libs, crtendS.o gives this terminator.  We can use
> such terminating objects.  Or we can add a 4-byte 0 with modifying
> the linker script like as the patch below.
> 
At least looking at the i386 implementation, it looks like it's
explicitly padded out on a 4-byte boundary at the end of eh_frame.

So, we can either pad it out in vsyscall-trapa.S directly, or just stick
with the linker script hack. I would prefer to have this padding in the
vsyscall code rather than in the linker script, so it's more consistent
with what the other architectures do.

Others (like ia64) don't have an eh_frame for their linux-gate at all,
interesting.

> BTW, I've found that SH boards set CONFIG_VSYSCALL=y as default.
> Brave enough! :-)
> 
I figured no one would test it if it wasn't default-enabled, and people
would complain very quickly if the signal trampoline suddenly broke. In
the long term I plan on removing the option entirely and just setting it
as def_bool y if MMU. It can be disabled via the kernel command line or
via the sysctl interface at run-time (some folks may want to be rid of
the randomized vdso VMA entirely when debugging).