LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-28  9:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linuxppc-dev, akpm, Linux Kernel list

Hi Linus !

I lied :-) There is a couple more features coming in. Mostly Roland
tracehook stuff which came in a bit late but since the generic bits
are in and he had some powerpc support ready, we felt like it was
something worth having. There's also some SPI bits from Grant who
were around but took some time to be fully acked and some stuff to
expose our cache topology through sysfs that we wanted but took a
bit longer to finish than expected.

The rest is mostly fixes.

It's all in:

git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge

(Hopefully no silly non-printable character this time, at least
nothing I manage to spot with evo but who knows...)

Cheers,
Ben.

 arch/powerpc/Kconfig                       |    1 
 arch/powerpc/kernel/entry_32.S             |   17 +-
 arch/powerpc/kernel/entry_64.S             |   10 +
 arch/powerpc/kernel/legacy_serial.c        |   44 ++--
 arch/powerpc/kernel/process.c              |    8 -
 arch/powerpc/kernel/prom_init.c            |   39 ----
 arch/powerpc/kernel/ptrace.c               |   54 ++---
 arch/powerpc/kernel/setup-common.c         |   24 --
 arch/powerpc/kernel/setup_64.c             |    3 
 arch/powerpc/kernel/signal.c               |   23 ++
 arch/powerpc/kernel/smp.c                  |  119 ++++++++++-
 arch/powerpc/kernel/stacktrace.c           |    1 
 arch/powerpc/kernel/sysfs.c                |  311 ++++++++++++++++++++++++++++
 arch/powerpc/kernel/vio.c                  |    6 -
 arch/powerpc/mm/hugetlbpage.c              |    9 +
 arch/powerpc/platforms/powermac/setup.c    |   72 ++++++
 arch/powerpc/platforms/powermac/udbg_scc.c |   12 +
 arch/powerpc/platforms/pseries/cmm.c       |    8 +
 drivers/net/ibmveth.c                      |    8 -
 drivers/of/Kconfig                         |    6 +
 drivers/of/Makefile                        |    1 
 drivers/of/base.c                          |   88 ++++++++
 drivers/of/of_i2c.c                        |   64 ------
 drivers/of/of_spi.c                        |   93 ++++++++
 drivers/spi/spi.c                          |  139 +++++++++----
 include/asm-powerpc/pgtable-4k.h           |    2 
 include/asm-powerpc/pgtable-64k.h          |    2 
 include/asm-powerpc/pgtable-ppc32.h        |    3 
 include/asm-powerpc/pgtable-ppc64.h        |    4 
 include/asm-powerpc/ptrace.h               |    1 
 include/asm-powerpc/signal.h               |    3 
 include/asm-powerpc/smp.h                  |    2 
 include/asm-powerpc/syscall.h              |   84 ++++++++
 include/asm-powerpc/thread_info.h          |    5 
 include/asm-powerpc/topology.h             |    2 
 include/linux/of.h                         |    1 
 include/linux/of_spi.h                     |   18 ++
 include/linux/spi/spi.h                    |   12 +
 38 files changed, 1039 insertions(+), 260 deletions(-)
 create mode 100644 drivers/of/of_spi.c
 create mode 100644 include/asm-powerpc/syscall.h
 create mode 100644 include/linux/of_spi.h

Benjamin Herrenschmidt (3):
      powerpc/powermac: Use sane default baudrate for SCC debugging
      powerpc/powermac: Fixup default serial port device for pmac_zilog
      powerpc: Disable 64K hugetlb support when doing 64K SPU mappings

Grant Likely (3):
      of: adapt of_find_i2c_driver() to be usable by SPI also
      spi: split up spi_new_device() to allow two stage registration.
      spi: Add OF binding support for SPI busses

Huang Weiyi (1):
      powerpc: Removed duplicated include in stacktrace.c

Kumar Gala (2):
      powerpc/booke: Clean up the hardware watchpoint support
      powerpc: Fix 8xx build failure

Nathan Lynch (7):
      powerpc: Fix vio build warnings
      powerpc: kill useless SMT code in prom_hold_cpus
      powerpc: register_cpu_online should be __cpuinit
      powerpc: Update cpu_sibling_maps dynamically
      powerpc: Make core sibling information available to userspace
      powerpc: Make core id information available to userspace
      powerpc: Show processor cache information in sysfs

Nick Piggin (1):
      powerpc/mm: Implement _PAGE_SPECIAL & pte_special() for 64-bit

Roland McGrath (5):
      powerpc: Call tracehook_signal_handler() when setting up signal frames
      powerpc: Make syscall tracing use tracehook.h helpers
      powerpc: Add asm/syscall.h with the tracehook entry points
      powerpc: Add TIF_NOTIFY_RESUME support for tracehook
      powerpc: Enable tracehook for the architecture

Stephen Rothwell (3):
      powerpc/pseries: Fix CMO sysdev attribute API change fallout
      ibmveth: Fix multiple errors with dma_mapping_error conversion
      powerpc/vio: More fallout from dma_mapping_error API change

^ permalink raw reply

* Re: mISDN still breaking the allmodconfig build...
From: Karsten Keil @ 2008-07-28 10:26 UTC (permalink / raw)
  To: David Miller; +Cc: sfr, marcel, linux-kernel, linuxppc-dev, akpm, torvalds
In-Reply-To: <20080727.180736.74131389.davem@davemloft.net>

On Sun, Jul 27, 2008 at 06:07:36PM -0700, David Miller wrote:
> From: Marcel Holtmann <marcel@holtmann.org>
> Date: Mon, 28 Jul 2008 03:03:04 +0200
> 
> > > More fallout from the premature mISDN driver merge:
> > >
> > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not  
> > > running on big endian machines now"
> > 
> > is that only the HFC driver or the whole mISDN stack?
> > 
> > I know that the two old ISDN stacks where really bad on big endian,  
> > but my assumption was that we did sort this out in the end.
> 
> One of the two mISDN drivers uses the deprecated virt_to_bus()
> interface for handling DMA addresses (that doesn't even work on many
> x86 systems these days) and the other mISDN driver gives the above
> big-endian compile time error.
> 

OK this was forgotten to change in a printk from the old driver, the new allocation
code should be OK it use pci_alloc_consistent().
I think it should simple use the returned dmahandle in this printk.

-- 
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)

^ permalink raw reply

* Re: mISDN still breaking the allmodconfig build...
From: Benjamin Herrenschmidt @ 2008-07-28 10:50 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: sfr, kkeil, linux-kernel, linuxppc-dev, akpm, torvalds,
	David Miller
In-Reply-To: <93120C4B-D2F4-4479-806B-2141AC3DC607@holtmann.org>

On Mon, 2008-07-28 at 03:03 +0200, Marcel Holtmann wrote:
> Hi Dave,
> 
> > More fallout from the premature mISDN driver merge:
> >
> > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not  
> > running on big endian machines now"
> 
> is that only the HFC driver or the whole mISDN stack?
> 
> I know that the two old ISDN stacks where really bad on big endian,  
> but my assumption was that we did sort this out in the end.

Well, I got it working well enough (the old one) on a ppc405 about 5 or
6 years ago... It did require some endian & dma mapping fixing, iirc, in
the hisax pci driver, but nothing very tricky.

What bugs me is that we -fixed- at least some of these things in the old
stack, up to the point where I could use it reliably in some commercial
products, and now we are merging a new stack which, in that area, is a
clear regression over the old code.

One basic premise to me for replacing a whole stack with a new one is
that the new one should be -at-least- as good as the old one in all
areas, and those (virt_to_bus and endianness) are pretty major.

Ben.

^ permalink raw reply

* Re: mISDN still breaking the allmodconfig build...
From: Karsten Keil @ 2008-07-28 11:14 UTC (permalink / raw)
  To: Alan Cox
  Cc: sfr, kkeil, linux-kernel, linuxppc-dev, akpm, torvalds,
	David Miller
In-Reply-To: <20080728102009.5fb3df6b@lxorguk.ukuu.org.uk>

On Mon, Jul 28, 2008 at 10:20:09AM +0100, Alan Cox wrote:
> On Sun, 27 Jul 2008 20:48:05 -0400
> Sean MacLennan <smaclennan@pikatech.com> wrote:
> 
> > On Mon, 28 Jul 2008 10:13:42 +1000
> > "Benjamin Herrenschmidt" <benh@kernel.crashing.org> wrote:
> > 
> > > On Sun, 2008-07-27 at 17:02 -0700, David Miller wrote:
> > > > More fallout from the premature mISDN driver merge:
> > > > 
> > > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not
> > > > running on big endian machines now"
> > > 
> > > Lovely...
> > 
> > mISDN is notoriously bad on big endian machines.
> 

This only affect the hardware IO layer of some cards and I think
it will be fixed very soon, I did not remove the very old
#error line, because I did not had the hardware to verify that it is
OK now.
I already reserved a PPC machine now (will get it today or tomorrow) and
will test the endian robustness this week.

> In which case it really should not be in Linus tree but in linux-next.
> Karsten - will you ask Linus to revert mISDN so it can go into linux-next
> instead and get cleaned up in the right place ?
> 

This was my original plan and my fault, that I only included the
pull URL and sent it to Linus diectely, I did not know that in this case
Linus will pull it without further discussion, but I'm still glad that it
is in and only show few issues (I'm very unhappy that I did not find
these before, I did builds on all our architectures, but not with the
all*config, only with subsets).
The good thing is, that this brought back the ENDIAN issue back on my
radar and on my near time TODO list :-)

-- 
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)

^ permalink raw reply

* Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
From: Christoph Hellwig @ 2008-07-28 12:33 UTC (permalink / raw)
  To: David Miller; +Cc: sfr, kkeil, linux-kernel, linuxppc-dev, akpm, torvalds, alan
In-Reply-To: <20080727.125604.73857337.davem@davemloft.net>

On Sun, Jul 27, 2008 at 12:56:04PM -0700, David Miller wrote:
> Yes, please.
> 
> IMHO, this driver was really rushed in and that was a huge mistake.
> If it had gone through linux-next we could have tidied all of this
> stuff up in a less "rushed" manner.

Or just reviewed in at least some way..

^ permalink raw reply

* Re: [PATCHv4] cpm2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Kumar Gala @ 2008-07-28 12:42 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <200807281043.22736.laurentp@cse-semaphore.com>


On Jul 28, 2008, at 3:43 AM, Laurent Pinchart wrote:

> Based on earlier work by Laurent Pinchart.
>
> This patch implement GPIO LIB support for the CPM2 GPIOs.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> Cc: Laurent Pinchart <laurentp@cse-semaphore.com>
> ---
> arch/powerpc/platforms/Kconfig   |    2 +
> arch/powerpc/sysdev/cpm2.c       |   11 ++++
> arch/powerpc/sysdev/cpm_common.c |  123 +++++++++++++++++++++++++++++ 
> +++++++++
> include/asm-powerpc/cpm.h        |    3 +
> 4 files changed, 139 insertions(+), 0 deletions(-)

applied.

- k

^ permalink raw reply

* Re: [RFC] cpm_uart: Add generic clock API support to set baudrates
From: Kumar Gala @ 2008-07-28 12:48 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linuxppc-dev list
In-Reply-To: <200807281042.16872.laurentp@cse-semaphore.com>


On Jul 28, 2008, at 3:42 AM, Laurent Pinchart wrote:

> This patch introduces baudrate setting support via the generic clock  
> API.
> When present the optional device tree clock property is used instead  
> of
> fsl-cpm-brg. Platforms can then define complex clock schemes, to  
> output
> the serial clock on an external pin for instance.
>
> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> ---
> drivers/serial/cpm_uart/cpm_uart.h      |    1 +
> drivers/serial/cpm_uart/cpm_uart_core.c |   26 ++++++++++++++++++ 
> +-------
> 2 files changed, 20 insertions(+), 7 deletions(-)
>
> On Friday 25 July 2008, Kumar Gala wrote:
>> I'm having problems applying due to mailer formatting.
>
> *sigh* I'll definitely have to fix GPG support in kmail. Sorry about  
> the
> annoyance.

np.

applied.

- k

^ permalink raw reply

* Re: [PATCHv2] cpm_uart: Modem control lines support
From: Kumar Gala @ 2008-07-28 12:49 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linuxppc-dev list
In-Reply-To: <200807241836.37913.laurentp@cse-semaphore.com>


On Jul 24, 2008, at 11:36 AM, Laurent Pinchart wrote:

> This patch replaces the get_mctrl/set_mctrl stubs with modem control  
> line
> read/write access through the GPIO lib.
>
> Available modem control lines are described in the device tree using  
> GPIO
> bindings. The driver expect a GPIO pin for each of the CTS, RTS,  
> DCD, DSR,
> DTR and RI signals. Unused control lines can be left out.
>
> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> ---
> Documentation/powerpc/booting-without-of.txt |   10 ++++++
> drivers/serial/cpm_uart/cpm_uart.h           |   10 ++++++
> drivers/serial/cpm_uart/cpm_uart_core.c      |   40 +++++++++++++++++ 
> +++++++--
> 3 files changed, 57 insertions(+), 3 deletions(-)

applied.

- k

^ permalink raw reply

* Re: [PATCH 3/4] powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC
From: Kumar Gala @ 2008-07-28 12:54 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080611230431.GC21351@polina.dev.rtsoft.ru>


On Jun 11, 2008, at 6:04 PM, Anton Vorontsov wrote:

> i8259 PIC is disabled on MPC8610HPCD boards, thus currently rtc-cmos
> driver fails to probe.
>
> To fix the issue, we lookup the device tree for "chrp,iic" and
> "pnpPNP,000" compatible devices, and if not found we do not assign RTC
> IRQ and assuming that i8259 was disabled.
>
> Though this patch fixes RTC on some boards (and surely should not  
> break
> any other), the whole approach is still broken. We can't easily fix  
> this
> though, because old device trees do not specify i8259 interrupts for  
> the
> cmos rtc node.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/rtc_cmos_setup.c |   23 +++++++++++++++++------
> 1 files changed, 17 insertions(+), 6 deletions(-)

applied.

- k

^ permalink raw reply

* Please pull from 'powerpc-next' branch (for 2.6.27)
From: Kumar Gala @ 2008-07-28 12:54 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev

Please pull from 'powerpc-next' branch of

	master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next

to receive the following updates:

Sorry for taking so long on these.  Being at OLS limited patch applying
ability last week.  These are some CPM related patches that have been on
the list for some time and a fix to the RTC cmos detection need for the
mpc8610ds board.

- k

 Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt |   11
 arch/powerpc/platforms/8xx/Kconfig                       |   10
 arch/powerpc/platforms/Kconfig                           |    2
 arch/powerpc/sysdev/cpm1.c                               |  267 ++++++++++++++-
 arch/powerpc/sysdev/cpm2.c                               |   11
 arch/powerpc/sysdev/cpm_common.c                         |  123 ++++++
 arch/powerpc/sysdev/rtc_cmos_setup.c                     |   23 -
 drivers/serial/cpm_uart/cpm_uart.h                       |   11
 drivers/serial/cpm_uart/cpm_uart_core.c                  |   66 +++
 include/asm-powerpc/cpm.h                                |    3
 10 files changed, 506 insertions(+), 21 deletions(-)

Anton Vorontsov (1):
      powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC

Jochen Friedrich (1):
      powerpc: implement GPIO LIB API on CPM1 Freescale SoC.

Laurent Pinchart (3):
      cpm2: Implement GPIO LIB API on CPM2 Freescale SoC.
      cpm_uart: Modem control lines support
      cpm_uart: Add generic clock API support to set baudrates

^ permalink raw reply

* Re: mISDN still breaking the allmodconfig build...
From: Sinan Akman @ 2008-07-28 12:49 UTC (permalink / raw)
  To: Karsten Keil
  Cc: sfr, Marcel Holtmann, linux-kernel, linuxppc-dev, akpm, torvalds,
	David Miller
In-Reply-To: <20080728084024.GA23465@pingi.kke.suse.de>

Karsten Keil wrote:
> [...]
> virt_to_bus() I never got a complain before and yes I already have some patches
> to solve the endian issues in the HFC driver, but it was not finaly

   Karsten, do you have those patches available somewhere ?
I could give it a try on  4xx with a 4s card in the near future.

   Thanks

   Sinan Akman

^ permalink raw reply

* Re: [PATCH] cpm2: Rework baud rate generators configuration to support external clocks.
From: Kumar Gala @ 2008-07-28 13:48 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linuxppc-dev list, vbordug
In-Reply-To: <200807221800.44234.laurentp@cse-semaphore.com>


On Jul 22, 2008, at 11:00 AM, Laurent Pinchart wrote:

> The CPM2 BRG setup functions cpm_setbrg and cpm2_fastbrg don't  
> support external
> clocks. This patch adds a new exported __cpm2_setbrg function that  
> takes the
> clock rate and clock source as extra parameters, and moves  
> cpm_setbrg and
> cpm2_fastbrg to include/asm-powerpc/cpm2.h where they become inline  
> wrappers
> around __cpm2_setbrg.
>
> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> ---
> arch/powerpc/sysdev/cpm2.c |   34 +++----------------------------
> include/asm-powerpc/cpm2.h |   46 ++++++++++++++++++++++++++++++ 
> +------------
> 2 files changed, 37 insertions(+), 43 deletions(-)

applied.

- k

^ permalink raw reply

* Re: Please pull from 'powerpc-next' branch (for 2.6.27)(updated)
From: Kumar Gala @ 2008-07-28 13:50 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807280752420.22887@blarg.am.freescale.net>

Please pull from 'powerpc-next' branch of

	master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next

Laurent informed me I missed one CPM related patch:
'cpm2: Rework baud rate generators configuration to support external
clocks.'

- k

to receive the following updates:

 Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt |   11
 arch/powerpc/platforms/8xx/Kconfig                       |   10
 arch/powerpc/platforms/Kconfig                           |    3
 arch/powerpc/sysdev/cpm1.c                               |  267 ++++++++++++++-
 arch/powerpc/sysdev/cpm2.c                               |   45 --
 arch/powerpc/sysdev/cpm_common.c                         |  123 ++++++
 arch/powerpc/sysdev/rtc_cmos_setup.c                     |   23 -
 drivers/serial/cpm_uart/cpm_uart.h                       |   11
 drivers/serial/cpm_uart/cpm_uart_core.c                  |   66 +++
 include/asm-powerpc/cpm.h                                |    3
 include/asm-powerpc/cpm2.h                               |   46 +-
 11 files changed, 544 insertions(+), 64 deletions(-)

Anton Vorontsov (1):
      powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC

Jochen Friedrich (1):
      powerpc: implement GPIO LIB API on CPM1 Freescale SoC.

Laurent Pinchart (4):
      cpm2: Implement GPIO LIB API on CPM2 Freescale SoC.
      cpm_uart: Modem control lines support
      cpm_uart: Add generic clock API support to set baudrates
      cpm2: Rework baud rate generators configuration to support external clocks.

^ permalink raw reply

* Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
From: Gabriel Paubert @ 2008-07-28 13:52 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: the arch/x86 maintainers, linux-kernel, Mike Travis, Linuxppc-dev,
	Hugh Dickins, Ingo Molnar
In-Reply-To: <1217075802.11188.129.camel@pasglop>

On Sat, Jul 26, 2008 at 10:36:42PM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2008-07-26 at 12:02 +0100, Hugh Dickins wrote:
> > 
> > Hmm, perhaps it is doing sibling calls differently even without the
> > explicit -fno-optimize-sibling-calls (but when I add that option,
> > the vmlinux size does go up another 4400).
> > 
> > Sorry, I'm most probably fussing over nothing,
> > and wasting your time with my ignorance.
> 
> No you aren't, there is indeed something happening. It looks like gcc is
> keeping a copy of each stack frame in r31, thus forcing to save/restore
> that register, along function calls, possibly to help get reliable
> frames for leaf functions. I don't think we use that "feature" in our
> backtrace code though... so it won't harm in the sense that it won't
> break things, but it will indeed bloat the code a little bit.
> 
> Maybe we should totally disable -fno-omit-frame-pointers on powerpc ...

Yes.
> either that or see about actually using that r31 linkage, though I'm not
> sure it would be that useful.

On PPC you can get reliable backtraces (modulo leaf functions, but AFAIR
the frame pointer does not help, only the CFI data) without a frame pointer
since the ABI makes the stack pointer chain easy to follow. The frame pointer
(r31) is only necessary when there are variable size stack allocations, 
alloca() for example, but are they even allowed in the kernel?

	Regards,
	Gabriel

^ permalink raw reply

* Changing Mac address
From: Guillaume Dargaud @ 2008-07-28 14:25 UTC (permalink / raw)
  To: linuxppc-dev

Hello all,
there's something I miss here. I'd like to setup a MAC address in software 
at the start of the boot process. I'm trying to figure out where this is 
done in the kernel code.
I'm on a custom variant of a Xilinx ML405 card, still in PPC arch.
So it appears to be going in the arch/ppc/boot/simple/embed_config.c piece 
of code, but since I don't have I2C, the only 'relevant' code is this one:

#if (!defined(CONFIG_XILINX_MLxxx) || !defined(XPAR_IIC_0_BASEADDR) || 
!defined(XPAR_PERSISTENT_0_IIC_0_BASEADDR))
int get_cfg_data(unsigned char **cfg_data) {
#warning I2C needed for obtaining the Ethernet MAC address. Using hard-coded 
MAC address
 return 0; /* no cfg data found */
}

Nonetheless, ifconfig (from busybox) gives me a proper MAC address 
(00:0A:35:01:02:03) and can even change it:
ifconfig eth0 down hw ether 00:0A:35:01:02:10 up
But I want to do that before the network is up.

What is the relevant kernel section to change in order to set the MAC 
address ?
Thanks.
-- 
Guillaume Dargaud
http://www.gdargaud.net/

^ permalink raw reply

* Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
From: Ingo Molnar @ 2008-07-28 14:41 UTC (permalink / raw)
  To: Hugh Dickins
  Cc: the arch/x86 maintainers, linux-kernel, Mike Travis, Linuxppc-dev,
	Linus Torvalds, Arjan van de Ven
In-Reply-To: <Pine.LNX.4.64.0807251839190.20617@blonde.site>


* Hugh Dickins <hugh@veritas.com> wrote:

> [PATCH] sched: move sched_clock before first use
> 
> Move sched_clock() up to stop warning: weak declaration of 
> `sched_clock' after first use results in unspecified behavior (if 
> -fno-unit-at-a-time).
> 
> Signed-off-by: Hugh Dickins <hugh@veritas.com>

applied to tip/sched/urgent - thanks Hugh.

> I rather think CONFIG_FRAME_POINTER shouldn't exist at all (or be a 
> private, config-user-invisible, specific-to-a-few-arches thing): what 
> one wants to configure is how far to sacrifice cpu performance and 
> kernel smallness to getting a good stacktrace.  Frame pointer is just 
> an implementation detail on that, appropriate to some arches. Perhaps 
> three settings: no stacktrace, fair stacktrace, best stacktrace.

actually, we consciously use and rely on frame pointers on x86. The 
runtime cost on 64-bit is miniscule and the improved backtrace output in 
recent kernels makes backtraces _much_ easier to interpret:

 Call Trace:
  <NMI>  [<ffffffff80480779>] _raw_spin_trylock+0x19/0x50
  [<ffffffff808fb2e9>] _spin_lock_irqsave+0x59/0x90
  [<ffffffff80261ab4>] atomic_notifier_chain_register+0x24/0x60
  [<ffffffff80262f38>] ? __profile_tick+0x58/0x90
  [<ffffffff808fd1a9>] nmi_watchdog_tick+0x59/0x1e0
  [<ffffffff808fc79a>] default_do_nmi+0x6a/0x220
  [<ffffffff808fc9b4>] do_nmi+0x64/0xb0
  [<ffffffff808fc032>] nmi+0xa2/0xc2
  [<ffffffff80285bd1>] ? stopmachine+0x61/0xd0
  <<EOE>>  [<ffffffff8020dca9>] child_rip+0xa/0x11
  [<ffffffff8020cf3e>] ? restore_args+0x0/0x30
  [<ffffffff80285b70>] ? stopmachine+0x0/0xd0
  [<ffffffff8020dc9f>] ? child_rip+0x0/0x11

we experimented with using dwarf2 data in the past but it proved to be 
very fragile in practice - we depended too much on the whims of 
gcc/binutils being absolutely correct, etc.

Something as fundamental to the kernel's general health as backtraces 
must not be fragile. So the EBP based backtracing code was ported to 
64-bit as well and it was improved further upon.

kudos to Arjan for that.

	Ingo

^ permalink raw reply

* Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
From: Hugh Dickins @ 2008-07-28 14:54 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: the arch/x86 maintainers, linux-kernel, Mike Travis, Linuxppc-dev,
	Linus Torvalds, Arjan van de Ven
In-Reply-To: <20080728144133.GH18144@elte.hu>

On Mon, 28 Jul 2008, Ingo Molnar wrote:
> * Hugh Dickins <hugh@veritas.com> wrote:
> 
> > I rather think CONFIG_FRAME_POINTER shouldn't exist at all (or be a 
> > private, config-user-invisible, specific-to-a-few-arches thing): what 
> > one wants to configure is how far to sacrifice cpu performance and 
> > kernel smallness to getting a good stacktrace.  Frame pointer is just 
> > an implementation detail on that, appropriate to some arches. Perhaps 
> > three settings: no stacktrace, fair stacktrace, best stacktrace.
> 
> actually, we consciously use and rely on frame pointers on x86. The 
> runtime cost on 64-bit is miniscule and the improved backtrace output in 
> recent kernels makes backtraces _much_ easier to interpret:

Just to clarify, no way was I criticizing the use of frame pointers
on x86.  What I don't care for is that CONFIG_FRAME_POINTER is used
by common code (e.g. top level Makefile, and various debug Kconfigs),
when I see it as an arch-specific technique for getting best stacktrace.

Hugh

^ permalink raw reply

* Re: ide pmac breakage
From: Bartlomiej Zolnierkiewicz @ 2008-07-28 14:31 UTC (permalink / raw)
  To: benh; +Cc: FUJITA Tomonori, list linux-ide, Borislav Petkov,
	linuxppc-dev list
In-Reply-To: <1217210545.11188.146.camel@pasglop>

On Monday 28 July 2008, Benjamin Herrenschmidt wrote:
> On Mon, 2008-07-28 at 11:29 +1000, Benjamin Herrenschmidt wrote:
> > The current ide-pmac upstream is broken. It calls
> > media_bay_set_ide_infos() with an uninitialized "hwif" argument.
> > 
> > It's not a trivial mistake, there's a chicken-and-egg problem in the
> > init code in there.
> > 
> > I've locally fixed it with this patch that i'll merge via the powerpc
> > tree unless you have an objection.

Fine with me (you may add my ACK) and thanks for fixing it.

> > However, the machine crashes when removing the media-bay CD-ROM drive.
> > 
> > Crash appears to be a NULL deref, possibly in elv_may_queue() though
> > I don't have a clean backtrace yet, working on it...

I wonder whether conversion from on-stack struct requests to allocated
ones may have something to do with it (or not?)...

> Here's a backtrace:
> 
> Vector: 300 (Data Access) at [c58b7b80]
>     pc: c014f264: elv_may_queue+0x10/0x44
>     lr: c0152750: get_request+0x2c/0x2c0
>     sp: c58b7c30
>    msr: 1032
>    dar: c
>  dsisr: 40000000
>   current = 0xc58aaae0
>     pid   = 854, comm = media-bay
> enter ? for help
> mon> t
> [c58b7c40] c0152750 get_request+0x2c/0x2c0
> [c58b7c70] c0152a08 get_request_wait+0x24/0xec
> [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0
> [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc
> [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0
> [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c
> [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8
> [c58b7e50] c022395c ide_cd_release+0x80/0x84
> [c58b7e70] c0163650 kref_put+0x54/0x6c
> [c58b7e80] c0223884 ide_cd_put+0x40/0x5c
> [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c
> [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4
> [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44
> [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8
> [c58b7f00] c01e7424 device_del+0x104/0x198
> [c58b7f20] c01e74d0 device_unregister+0x18/0x30
> [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88
> [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80
> [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0
> [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc
> [c58b7fd0] c00485c0 kthread+0x48/0x84
> [c58b7ff0] c0011b20 kernel_thread+0x44/0x60

^ permalink raw reply

* [PATCH 1/3] powerpc: correctly hookup PTRACE_GET/SETVSRREGS for 32 bit processes
From: Michael Neuling @ 2008-07-28 15:13 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1217257994.262387.980049492980.qpush@coopers>

Fix bug where PTRACE_GET/SETVSRREGS are not connected for 32 bit processes.

Signed-off-by: Michael Neuling <mikey@neuling.org>
---

 arch/powerpc/kernel/ptrace32.c |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/ptrace32.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c
@@ -294,6 +294,8 @@ long compat_arch_ptrace(struct task_stru
 	case PTRACE_SETFPREGS:
 	case PTRACE_GETVRREGS:
 	case PTRACE_SETVRREGS:
+	case PTRACE_GETVSRREGS:
+	case PTRACE_SETVSRREGS:
 	case PTRACE_GETREGS64:
 	case PTRACE_SETREGS64:
 	case PPC_PTRACE_GETFPREGS:

^ permalink raw reply

* [PATCH 0/3] powerpc: VSX ptrace bug fixes for 2.6.27
From: Michael Neuling @ 2008-07-28 15:13 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev

Below are a few bug fixes for VSX ptrace for 2.6.27.

Thanks to Luis Machado for helping find these with his VSX GDB work.

^ permalink raw reply

* [PATCH 3/3] powerpc: fix setting the wrong thread_struct for ptrace get/set VSX regs
From: Michael Neuling @ 2008-07-28 15:13 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1217257994.262387.980049492980.qpush@coopers>

In PTRACE_GET/SETVSRREGS, we should be using the thread we are
ptracing rather than current.  

Signed-off-by: Michael Neuling <mikey@neuling.org>
---

 arch/powerpc/kernel/ptrace.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c
@@ -374,7 +374,7 @@ static int vsr_get(struct task_struct *t
 	flush_vsx_to_thread(target);
 
 	for (i = 0; i < 32 ; i++)
-		buf[i] = current->thread.fpr[i][TS_VSRLOWOFFSET];
+		buf[i] = target->thread.fpr[i][TS_VSRLOWOFFSET];
 	ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
 				  buf, 0, 32 * sizeof(double));
 
@@ -393,7 +393,7 @@ static int vsr_set(struct task_struct *t
 	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
 				 buf, 0, 32 * sizeof(double));
 	for (i = 0; i < 32 ; i++)
-		current->thread.fpr[i][TS_VSRLOWOFFSET] = buf[i];
+		target->thread.fpr[i][TS_VSRLOWOFFSET] = buf[i];
 
 
 	return ret;

^ permalink raw reply

* [PATCH 2/3] powerpc: fix ptrace buffer size for VSX
From: Michael Neuling @ 2008-07-28 15:13 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1217257994.262387.980049492980.qpush@coopers>

Fix cut-and-paste error in the size setting for ptrace buffers for VSX.

Signed-off-by: Michael Neuling <mikey@neuling.org>
---

 arch/powerpc/kernel/ptrace.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c
@@ -913,15 +913,13 @@ long arch_ptrace(struct task_struct *chi
 	case PTRACE_GETVSRREGS:
 		return copy_regset_to_user(child, &user_ppc_native_view,
 					   REGSET_VSX,
-					   0, (32 * sizeof(vector128) +
-					       sizeof(u32)),
+					   0, 32 * sizeof(double),
 					   (void __user *) data);
 
 	case PTRACE_SETVSRREGS:
 		return copy_regset_from_user(child, &user_ppc_native_view,
 					     REGSET_VSX,
-					     0, (32 * sizeof(vector128) +
-						 sizeof(u32)),
+					     0, 32 * sizeof(double),
 					     (const void __user *) data);
 #endif
 #ifdef CONFIG_SPE

^ permalink raw reply

* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2008-07-28 15:40 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, akpm, Linux Kernel list
In-Reply-To: <1217239117.11188.187.camel@pasglop>



On Mon, 28 Jul 2008, Benjamin Herrenschmidt wrote:
> 
> It's all in:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge

It doesn't really seem to be. I get "Already up-to-date.", and the top 
commit there seems to be from July 3..

Forgot to push?

> (Hopefully no silly non-printable character this time, at least
> nothing I manage to spot with evo but who knows...)

Yeah, no odd whitespace here either. Not that it helps ;)

		Linus

^ permalink raw reply

* Re: [git pull] Please pull powerpc.git merge branch
From: Stephen Rothwell @ 2008-07-28 15:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: akpm, Linux Kernel list, linuxppc-dev
In-Reply-To: <alpine.LFD.1.10.0807280838580.3486@nehalem.linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

Hi Linus,

On Mon, 28 Jul 2008 08:40:44 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Mon, 28 Jul 2008, Benjamin Herrenschmidt wrote:
> > 
> > It's all in:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
> 
> It doesn't really seem to be. I get "Already up-to-date.", and the top 
> commit there seems to be from July 3..
> 
> Forgot to push?

It should be

	git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

Ben seems to have copied from one of Paul's pull requests.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2008-07-28 16:06 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: akpm, Linux Kernel list, linuxppc-dev
In-Reply-To: <20080729015330.39aff7a5.sfr@canb.auug.org.au>



On Tue, 29 Jul 2008, Stephen Rothwell wrote:
> 
> It should be
> 
> 	git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
> 
> Ben seems to have copied from one of Paul's pull requests.

Ok, that one worked for me.

Ben, I'm sure some day you'll get it right on the first try. We're all 
cheering for you!

			Linus

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox