Sachin P. Sant wrote:
sure if this is a new problem or a recurring one. Will try booting
some older kernels on this box and will report the results.
I tried few older kernels till 2.6.28 and all of them had the
same problem.
I also tried using SLUB instead of SLAB. That also failed to
boot with
Hello all：
We use the AMCC PowerPC 405ex through emac1 way RGMII with realtek RTL8211 Giga
phy linked to, At present the PHY Address is: 00110
add delay 2ns for RGMII
CONFIG[8:5]:AUTO_Negotiation
=NWay,advertise ，all capabilities,prefer Slave
mode;1=RGMII mode
Clk on the hardware no probl
There is no dependece between efp and math-emu.
But when disalbe math-emu, the efp code cannot be built.
This patch fixes it.
Signed-off-by: Liu Yu
---
It would be nice to see this patch go along with 2.6.29
arch/powerpc/Makefile |4 ++--
arch/powerpc/math-emu/Makefile |5 ++---
Hi Sergej,
On Fri, Mar 6, 2009 at 9:07 PM, Stepanov, Sergej wrote:
> gpio - driver functions pretty well for a pin-setup, but
> uninitialized/unexported pins have undefined states
-did you achieve this using gpiolib.c? If not, then what files and
what kernel are you using? We are trying to get
On Mon, 2009-03-09 at 20:05 -0400, Josh Boyer wrote:
> [cfffb830] [c05fe504] .mutex_lock_nested+0x78/0x4b0
> (unreliable)
> [cfffb950] [c039d520] .echo_char_raw+0x40/0x98
> [cfffb9f0] [c039fd68] .n_tty_receive_buf+0xb48/0x1104
> [cfffbbb0] [c0
> > Grant,
> >
> > Can you grab this guy too?
> >
> > http://patchwork.ozlabs.org/patch/24082/
>
> Oops, forgot to email you about this one. I actually wrote another
> patch the eliminates the sysfs attributes entirely which also
> eliminates the problem. It will be in my next pull request to Be
Hey Mikey,
On Mon, Mar 9, 2009 at 5:46 PM, Michael Neuling wrote:
> Grant,
>
> Can you grab this guy too?
>
> http://patchwork.ozlabs.org/patch/24082/
Oops, forgot to email you about this one. I actually wrote another
patch the eliminates the sysfs attributes entirely which also
eliminates the
I get the following oops on a ppc64 machine using a Fedora rawhide kernel,
which is very close to 2.6.29-rc7.
It's a POWER5, pSeries CHRP IBM,9123-710.
Haven't looked into it just quite yet, but I found it interesting and was
wondering if anyone had seen anything like this or could recreate.
jos
On Mon, 2009-03-09 at 22:30 +0100, Gerhard Pircher wrote:
> Hi,
>
> I heard rumors that DRI doesn't work on SAM440EP (onboard Radeon GPU)
> boards. I had DRI halfway working on my AmigaOne (Radeon 9250) with an
> early release candidate of the 2.6.25 kernel and IIRC this patch here
> (manually app
> Hey Ben,
>
> Here are some more for -next.
>
> The following changes since commit 652e8f8d579d61745094e36b4ff085026a332e73:
> Benjamin Herrenschmidt (1):
> Merge commit 'jwb/next' into next
>
> are available in the git repository at:
>
> git://git.secretlab.ca/git/linux-2.6-mpc52x
Hi,
I heard rumors that DRI doesn't work on SAM440EP (onboard Radeon GPU)
boards. I had DRI halfway working on my AmigaOne (Radeon 9250) with an
early release candidate of the 2.6.25 kernel and IIRC this patch here
(manually applied):
http://kerneltrap.org/index.php?q=mailarchive/git-commits-head/
However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus
by the kernel code. My understanding is this is not correct - patch
attached.
You are missing the Signed-off-by tag that is needed.
I'm sorry.
Signed-off-by: Mikhail Zolotaryov
Aside from that, I'm curious if you
On Mon, 2009-03-09 at 12:06 -0700, Geoff Levand wrote:
> There was some work by Joe Perches to list the files a maintainer is
> responsible for into the MAINTAINERS file. I think that would give
> you what you want, a way to automatically get the maintainer of a
> file.
>
> Joe, could you let us
Hi,
On 03/09/2009 11:43 AM, Alessandro Zummo wrote:
> Geoff Levand wrote:
>> On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
>> > On Mon, 9 Mar 2009 14:26:23 +0100
>> > Geert Uytterhoeven wrote:
>> >> +
>> >> +MODULE_AUTHOR("Sony Corporation");
>> >
>> > real name, if possible and a contact a
On 03/09/2009 06:26 AM, Geert Uytterhoeven wrote:
> Create a real RTC driver for PS3, and unhook the deprecated
> ppc_md.[gs]et_rtc_time.
> 8 files changed, 132 insertions(+), 18 deletions(-)
Sorry, I hadn't been following the discussion closely, but
could you explain why we are going from a gen
On Mon, 9 Mar 2009 11:04:17 -0700
Geoff Levand wrote:
>
> Hi,
>
> On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
> > On Mon, 9 Mar 2009 14:26:23 +0100
> > Geert Uytterhoeven wrote:
> >> +
> >> +MODULE_AUTHOR("Sony Corporation");
> >
> > real name, if possible and a contact address
> > her
Hi,
On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
> On Mon, 9 Mar 2009 14:26:23 +0100
> Geert Uytterhoeven wrote:
>> +
>> +MODULE_AUTHOR("Sony Corporation");
>
> real name, if possible and a contact address
> here . Just in case I need someone to bother :)
Please look at the MAINTAINERS fi
When the console is on a serial port to be driven by serial8250, a
character can be lost from the end of the first line in the two-line
sequence
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
This happens because udbg_p
On Mon, Mar 09, 2009 at 10:02:11PM +0530, Sachin P. Sant wrote:
> While trying to boot 2.6.29-rc7-git2 on a power5 box ran into
> following crash.
>
> Unable to handle kernel paging request for data at address 0xc00070001008
> Faulting instruction address: 0xc0119070
> cpu 0x0: Vector:
On 03/06/2009 04:54 AM, Geert Uytterhoeven wrote:
> Convert the PS3 Video RAM Storage Driver from an MTD driver to a plain block
> device driver.
>
> The ps3vram driver exposes unused video RAM on the PS3 as a block device
> suitable for storage or swap. Fast data transfer is achieved using a loc
On Mon, Mar 09, 2009 at 06:21:36PM +0200, Mikhail Zolotaryov wrote:
> Hi,
>
> according to the PPC440EPx Embedded Processor User Manual (rev 1.14)
> DDR0_14[REDUC] bit has the following meaning:
>
> REDUC - Enable the half data path feature of the controller
> 0 = Standard operation using full 64
On Feb 27, 2009, at 9:53 AM, Martyn Welch wrote:
The registers for the local bus are incorrectly set to 0xf8005000
rather
than there actual location of 0xfef05000.
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_sbc610.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-
On Jan 23, 2009, at 1:49 PM, Anton Vorontsov wrote:
On Tue, Jan 06, 2009 at 10:28:10PM -0600, Kumar Gala wrote:
On Dec 5, 2008, at 2:09 PM, Anton Vorontsov wrote:
Hi all,
The patch series are used to support SPI via the OF SPI subsystem
(driver/of/of_spi.c). Now the driver is able to manage
Hi,
according to the PPC440EPx Embedded Processor User Manual (rev 1.14)
DDR0_14[REDUC] bit has the following meaning:
REDUC - Enable the half data path feature of the controller
0 = Standard operation using full 64/72-bit memory bus
1 = Memory data path width is 32/40 bits
However, "1" is de
On Mar 5, 2009, at 9:01 PM, Xiaotian Feng wrote:
After UART interrupt handler is installed and rx is enabled, if an rx
interrupt comes before hardware init, rx->cur will be updated. Then
the
hardware init will reset BD and make rx->cur out of sync, move the
hardware
init code before reque
Signed-off-by: Wolfram Sang
---
arch/powerpc/kernel/pci-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 0f41812..f57b7bf 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/ke
On Mar 3, 2009, at 10:51 PM, Liming Wang wrote:
SPE registers use the high part bit0~bit31 of E500 GPR0~GPR31.
The unwind information in "eh_frame" section is used during exception
handling and describes register information in the signal frame. But
current unwind information doesn't cover SPE
In ehea_probe_adapter() the initial memory allocation and initialisation does
not need to be done with the ehea_fw_handles.lock semaphore held. Doing so
extends the amount of time the lock is held unnecessarily.
Signed-off-by: David Howells
---
drivers/net/ehea/ehea_main.c | 13 ++---
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/configs/linkstation_defconfig | 36 +
arch/powerpc/configs/storcenter_defconfig| 35 +--
Kumar Gala wrote:
> does not apply cleanly if/after I apply:
>
> powerpc: add fsl, fifo-depth property to Freescale SSI device nodes
That's weird -- I designed the patch so that it would. Oh well, I'll
rebase and repost.
--
Timur Tabi
Linux kernel developer at Freescale
_
On Mar 4, 2009, at 2:55 PM, Timur Tabi wrote:
The Freescale Serial Synchronous Interface (SSI) is an audio device
present on
some Freescale SOCs. Various implementations of the SSI have a
different
transmit and receive FIFO depth, but are otherwise identical. To
support
these variations,
On Mar 6, 2009, at 1:43 PM, Timur Tabi wrote:
Add the definition of the fsl,ssi-asynchronous property to ssi.txt
(documentation
of the device tree bindings for the Freescale SSI device).
Also tidy up the layout of ssi.txt.
Signed-off-by: Timur Tabi
---
v2: fixed typo, improved wording.
D
On Mon, Mar 09, 2009 at 02:26:16PM +0100, Geert Uytterhoeven wrote:
> Paul: Feel free to add your SuperH support.
>
> I suppose the easiest way for this to go in is through Kyle's PA-RISC tree, as
> he already has the preceding patches? Can I have your acks, please?
>
I'll add the SH support once
On Mar 2, 2009, at 10:55 PM, Benjamin Herrenschmidt wrote:
Note: Kumar and Grant, pls be a bit more careful with files outside of
arch/powerpc ... like the 5200 fec driver change, even if it's really
powerpc only stuff and quite clearly so, it's in drivers/net, it
wouldn't have hurt to seek dav
On Mon, 9 Mar 2009, Alessandro Zummo wrote:
> On Mon, 9 Mar 2009 14:26:23 +0100
> Geert Uytterhoeven wrote:
> > +
> > +static int ps3_get_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
> > + tm->tm_year -= 1900;
> > + tm->tm_mo
From: Grant Likely
fixed-head.o must be linked into the bootwrapper for raw-binary images to
work. This patch adds it into the bootwrapper.
Signed-off-by: Grant Likely
Reported-by: Eddie Dawydiuk
---
I pulled this chunk out of Eddie's bigger patch and also modified the other
case where it ap
Josh Boyer-4 wrote:
>
> On Mon, Mar 09, 2009 at 03:53:25AM -0700, Felix Radensky wrote:
>>
>>
>>
>>Josh Boyer-4 wrote:
>>>
>>> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
Hi,
I'm getting machine check exception when trying to dump
emac registers on 405
Hello Stefan,
On Mon, Dec 1, 2008 at 8:46 PM, Stefan Roese wrote:
> On Monday 01 December 2008, Leon Woestenberg wrote:
>> >> Now, if I re-program the end-point FPGA during the u-boot boot
>> >> time-out, Linux will recognize the end-point.
>> >
>> > It's possible that either the reset in between
On Mon, 9 Mar 2009 14:26:16 +0100
Geert Uytterhoeven wrote:
> Hi Alessandro et al,
>
> These patches are relative to the "rtc-parisc" branch of Kyle's PA-RISC git
> repository, which already contains some cleanups for the rtc-parisc driver by
> Dann, which already have been ack'ed by A
On Mon, 9 Mar 2009 14:26:23 +0100
Geert Uytterhoeven wrote:
Hi,
just a few notes:
> +
> +static int ps3_get_time(struct device *dev, struct rtc_time *tm)
> +{
> + to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
> + tm->tm_year -= 1900;
> + tm->tm_mon -= 1;
> + return 0;
On Mon, 2009-03-09 at 14:26 +0100, Geert Uytterhoeven wrote:
> PowerPC has been a long time user of the generic RTC abstraction, so hook up
> rtc-generic:
> - Create the "rtc-generic" platform device if ppc_md.get_rtc_time is set,
> - Kill rtc-ppc, as rtc-generic offers the same functionality i
Create a real RTC driver for PS3, and unhook the deprecated
ppc_md.[gs]et_rtc_time.
Signed-off-by: Geert Uytterhoeven
Cc: Geoff Levand
---
arch/powerpc/include/asm/ps3.h|3 +
arch/powerpc/platforms/ps3/os-area.c |2 +
arch/powerpc/platforms/ps3/platform.h |2 -
arch/powerpc
PowerPC has been a long time user of the generic RTC abstraction, so hook up
rtc-generic:
- Create the "rtc-generic" platform device if ppc_md.get_rtc_time is set,
- Kill rtc-ppc, as rtc-generic offers the same functionality in a more
generic way, and supports autoloading through udev.
Sig
The rtc-parisc driver is not PA-RISC specific at all, as it uses the existing
(but deprecated) generic RTC infrastructure ([gs]et_rtc_time()).
Rename the driver from rtc-parisc to rtc-generic.
Signed-off-by: Geert Uytterhoeven
---
arch/parisc/Kconfig |2 +-
arch/parisc/kernel/time.c |
m68k has been a long time user of the generic RTC abstraction, so hook up
rtc-generic:
- Create the "rtc-generic" platform device if mach_hwclk is set,
- Add checks for mach_hwclk, in anticipation of RTC chip drivers being moved
to drivers/rtc/.
Signed-off-by: Geert Uytterhoeven
---
arch
Make udev autoload the driver
Signed-off-by: Geert Uytterhoeven
---
drivers/rtc/rtc-parisc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index f4e871c..48ef5b4 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc
When using platform_driver_probe(), it's not needed to setup a .probe
function, and .remove should be marked __exit_p(), not __devexit_p().
Signed-off-by: Geert Uytterhoeven
Cc: dann frazier
---
drivers/rtc/rtc-parisc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/
Signed-off-by: Geert Uytterhoeven
---
drivers/rtc/rtc-parisc.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index b966f56..620b949 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -13,9 +13,7
Hi Alessandro et al,
This patch series:
1. Adds the missing module alias to rtc-parisc (which is a bugfix), and
performs a few cleanups,
2. Moves the platform device creation out of rtc-ppc and into arch-specific
code (which is also a bugfix),
3. Consolidates rtc-parisc an
Josh Boyer-4 wrote:
>
> On Mon, Mar 09, 2009 at 03:53:25AM -0700, Felix Radensky wrote:
>>
>>
>>
>>Josh Boyer-4 wrote:
>>>
>>> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
Hi,
I'm getting machine check exception when trying to dump
emac registers on 405
Hi all,
Has anybody tested KGDBOC in linux-2.6.28 for Xilinx Virtex-5 PowerPC
target boards..
I just see that KGDB waits for remote connection from GDB host, but
unfortunately
Command line arguments were :
console=ttyS0 ip=bootp root=/dev/nfs rw kgdboc=ttyS0 kgdbwait
The test is been done on
On Mon, Mar 09, 2009 at 03:53:25AM -0700, Felix Radensky wrote:
>
>
>
>Josh Boyer-4 wrote:
>>
>> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
>>>
>>>Hi,
>>>
>>>I'm getting machine check exception when trying to dump
>>>emac registers on 405EX Kilauea board. The kernel is 2.6.29-
Henk,
On Montag, 9. März 2009, Henk Stegeman wrote:
> I don't understand how this would work,
>
> Now I do one byte-swap, which works.
> -I byteswap in software, for 16-bit cycles by byte swapping and for 8
> bit cycles by adding an offset of 1.
> (The byte swapping on the chipselect is off)
>
>
On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> On Mon, 9 Mar 2009, Jens Axboe wrote:
> > On Mon, Mar 09 2009, Jens Axboe wrote:
> > > On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > O
Josh Boyer-4 wrote:
>
> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
>>
>>Hi,
>>
>>I'm getting machine check exception when trying to dump
>>emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7
>>The problem seems not new, I can reproduce it on 2.6.25 Denx kernel
>
On Mon, 9 Mar 2009, Jens Axboe wrote:
> On Mon, Mar 09 2009, Jens Axboe wrote:
> > On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > On Fri, Ma
On Mon, Mar 09 2009, Jens Axboe wrote:
> On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > O
On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> On Fri, 6 Mar 2009, Jens Axboe wrote:
> > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > On
On Fri, 6 Mar 2009, Jens Axboe wrote:
> On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > Bu
On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
>
>Hi,
>
>I'm getting machine check exception when trying to dump
>emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7
>The problem seems not new, I can reproduce it on 2.6.25 Denx kernel
I've not looked at what that code
> Please provide a valid email address here.
New email client helpfully stripped out the address...
>> called in a context where you can't iomap ? (ie with a spinlock held).
That is indeed the case. Keeping ehci generic is a valid point, but because of
the above I don't think adding a "hook" i
Juergen,
I don't understand how this would work,
Now I do one byte-swap, which works.
-I byteswap in software, for 16-bit cycles by byte swapping and for 8
bit cycles by adding an offset of 1.
(The byte swapping on the chipselect is off)
Your advice includes two byteswaps, one by re-routing t
Hi,
I'm getting machine check exception when trying to dump
emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7
The problem seems not new, I can reproduce it on 2.6.25 Denx kernel
-bash-3.2# ethtool -d eth0
Data machine check in kernel mode.
Oops: Machine check, sig: 7 [#1]
Kilauea
M
63 matches
Mail list logo
