* Re: Add hvc_console to MAINTAINERS
From: Josh Boyer @ 2009-04-01 0:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andrew Morton, roel.kluin, linux-kernel
In-Reply-To: <1238545250.6522.17.camel@localhost>
On Wed, Apr 01, 2009 at 11:20:50AM +1100, Michael Ellerman wrote:
>Add a MAINTAINERS entry for the hypervisor virtual console driver.
>
>Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>---
> MAINTAINERS | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
>How about this?
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 1c2ca1d..854437a 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -1918,6 +1918,12 @@ L: lm-sensors@lm-sensors.org
> W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
> S: Maintained
>
>+HYPERVISOR VIRTUAL CONSOLE DRIVER
>+L: linuxppc-dev@ozlabs.org
>+L: linux-kernel@vger.kernel.org
>+S: Odd Fixes
>+F: drivers/char/hvc_*
>+
> GSPCA FINEPIX SUBDRIVER
> P: Frank Zago
> M: frank@zago.net
>--
>1.6.1.2
>
>
>
^ permalink raw reply
* Add hvc_console to MAINTAINERS
From: Michael Ellerman @ 2009-04-01 0:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Andrew Morton, roel.kluin, linux-kernel
In-Reply-To: <1238544253.6522.14.camel@localhost>
Add a MAINTAINERS entry for the hypervisor virtual console driver.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
MAINTAINERS | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
How about this?
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c2ca1d..854437a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1918,6 +1918,12 @@ L: lm-sensors@lm-sensors.org
W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
S: Maintained
+HYPERVISOR VIRTUAL CONSOLE DRIVER
+L: linuxppc-dev@ozlabs.org
+L: linux-kernel@vger.kernel.org
+S: Odd Fixes
+F: drivers/char/hvc_*
+
GSPCA FINEPIX SUBDRIVER
P: Frank Zago
M: frank@zago.net
--
1.6.1.2
^ permalink raw reply related
* Re: [PATCH] Add hvc_console to MAINTAINERS
From: Michael Ellerman @ 2009-04-01 0:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Andrew Morton, roel.kluin, linux-kernel
In-Reply-To: <20090331235057.GB563@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]
On Tue, 2009-03-31 at 19:50 -0400, Josh Boyer wrote:
> On Wed, Apr 01, 2009 at 10:44:00AM +1100, Michael Ellerman wrote:
> >On Tue, 2009-03-31 at 09:29 -0400, Josh Boyer wrote:
> >> Add a MAINTAINERS entry for the hypervisor virtual console support
> >> used on IBM POWER servers.
> >>
> >> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> >> ---
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index c5f4e9d..387ad45 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -2176,6 +2176,11 @@ W: http://www.ia64-linux.org/
> >> T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> >> S: Maintained
> >>
> >> +IBM HYPERVISOR VIRTUAL CONSOLE
> >> +P: Several
> >> +L: linuxppc-dev@ozlabs.org
> >> +S: Maintained
> >
> >I don't think it's the "IBM" Hypervisor virtual console driver anymore.
> >There are backends for Xen, Beat (Toshiba) and virtio.
>
> Was just going by the copyright in the files, and Documentation/powerpc/hvc*
>
> Also, if there are other backends, then is the list specified really
> correct? Perhaps it should just be linux-kernel.
I would say /also/ linux-kernel.
I think there's still more folks on linux-ppc who have looked at the
driver than elsewhere, but cross-posting to lkml is probably good as
well.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* PowerPC 460EX AD7416 Temperature Sensor
From: Henry Bausley @ 2009-04-01 0:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090331135629.GC3044@pengutronix.de>
Does anyone know if the I2C temperature sensor is functioning on the AMCC
460EX?
When I do a cat /proc/ad7416 I get the following crash.
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc02cbe28
Oops: Kernel access of bad area, sig: 11 [#1]
PowerPC 44x Platform
NIP: c02cbe28 LR: c023cec8 CTR: c023d314
REGS: ef107d90 TRAP: 0300 Not tainted (2.6.28.7)
MSR: 00029000 <EE,ME> CR: 88000444 XER: 00000000
DEAR: 00000000, ESR: 00000000
TASK = ef8590c0[2611] 'cat' THREAD: ef106000
GPR00: 00000000 ef107e40 ef8590c0 00000000 ef107e9c 00000000 00000c00
ef107e98
GPR08: 00000000 c0330000 ffffffff c0330000 48000448 1001cb7c 100042bc
100df49c
GPR16: 00000002 00000400 c032f014 c032efe4 ef107e9c ef107e98 bfffffff
efb43a00
GPR24: ef61d000 00000000 ef107f20 ef107e98 00000c00 c0400000 00001000
efb43a00
NIP [c02cbe28] mutex_lock+0x0/0x1c
LR [c023cec8] ad7416_read_temp+0x24/0x80
Call Trace:
[ef107e40] [00000400] 0x400 (unreliable)
[ef107e70] [c023d334] i2c_ad7416_read_proc+0x20/0x70
[ef107e90] [c00e8018] proc_file_read+0x108/0x334
[ef107ee0] [c00e2d3c] proc_reg_read+0x4c/0x70
[ef107ef0] [c00a54e8] vfs_read+0xb4/0x16c
[ef107f10] [c00a58e0] sys_read+0x4c/0x90
[ef107f40] [c000ea88] ret_from_syscall+0x0/0x3c
Instruction dump:
90010014 38000001 90030000 85230004 7f891800 419e000c 80690008 4bd50779
80010014 38210010 7c0803a6 4e800020 <7c001828> 3000ffff 7c00192d 40a2fff4
---[ end trace 774db769c3754abe ]---
**********************************************************
Outbound scan for Spam or Virus by Barracuda at Delta Tau
**********************************************************
^ permalink raw reply
* Re: [PATCH] Add hvc_console to MAINTAINERS
From: Josh Boyer @ 2009-03-31 23:52 UTC (permalink / raw)
To: Joe Perches; +Cc: linuxppc-dev, Andrew Morton, roel.kluin, linux-kernel
In-Reply-To: <1238535658.9715.321.camel@localhost>
On Tue, Mar 31, 2009 at 02:40:58PM -0700, Joe Perches wrote:
>On Tue, 2009-03-31 at 14:22 -0700, Andrew Morton wrote:
>> On Tue, 31 Mar 2009 14:10:23 -0700
>> Joe Perches <joe@perches.com> wrote:
>> > On Tue, 2009-03-31 at 09:29 -0400, Josh Boyer wrote:
>> > > Add a MAINTAINERS entry for the hypervisor virtual console support
>> > > used on IBM POWER servers.
>> > > diff --git a/MAINTAINERS b/MAINTAINERS
>> > > index c5f4e9d..387ad45 100644
>> > > --- a/MAINTAINERS
>> > > +++ b/MAINTAINERS
>> > > @@ -2176,6 +2176,11 @@ W: http://www.ia64-linux.org/
>> > > T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
>> > > S: Maintained
>> > >
>> > > +IBM HYPERVISOR VIRTUAL CONSOLE
>> > > +P: Several
>> > > +L: linuxppc-dev@ozlabs.org
>> > > +S: Maintained
>> > > +
>> > > IBM MCA SCSI SUBSYSTEM DRIVER
>> > > P: Michael Lang
>> > > M: langa2@kph.uni-mainz.de
>> >
>> > I think this sort of entry should not be acceptable.
>> > Maintainers should have individual names and contact addresses.
>>
>> There isn't a maintainer.
>>
>> But people send patches to the wrong list, so the ppc guys (who use
>> this driver) don't get to see them.
>>
>> That's a practical, real-world problem. We should have a fix for it.
>>
>> > An exploder entry should be OK though.
>> > For instance, the DVB subsystem:
>> >
>> > DVB SUBSYSTEM AND DRIVERS
>> > P: LinuxTV.org Project
>> > M: linux-media@vger.kernel.org
>> >
>> > A list entry could be something like:
>> >
>> > P: Linux PCMCIA Team
>> > L: linux-pcmcia@lists.infradead.org
>> >
>>
>> I'm unclear on what the difference is here..
>
>I have no problem with the "L: list" entry.
>I think that's good. Along with some file
>matching pattern as well of course...
>
>I think the "P: Several" entry is not good.
>
>"Several" doesn't give any idea as to who
>actually does the work.
I copied that from something else in MAINTAINERS. I believe it
was the KERNEL JANITORS entry. I guess I should have known better
than to copy from that...
>If the "P:" entry is there at all, it should
>be the list name.
>
>Maybe "P: Linux PPC Development Team" or
>something similar.
Except that isn't right for the reasons Michael specified.
josh
^ permalink raw reply
* Re: kexec: proc/device-tree/chosen/linux,kernel-end: No such file or directory
From: Michael Ellerman @ 2009-03-31 23:52 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <alpine.LRH.2.00.0903311808310.32461@vixen.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On Tue, 2009-03-31 at 18:25 +0200, Geert Uytterhoeven wrote:
> With today's kernel, I can no longer kexec any kernel on PS3:
>
> | /proc/device-tree/chosen/linux,kernel-end: No such file or directory
> | Could not get memory layout
>
> Today's bad version: 15f7176eb1cccec0a332541285ee752b935c1c85
> Yesterday's good version: 0d34fb8e93ceba7b6dad0062dbb4a0813bacd75b
>
> Before I start bisecting (tomorrow or the day thereafter), anyone with an idea?
Hmm, not really.
Looking at the code the only obvious way you could end up without that
property is if you didn't have a /chosen?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add hvc_console to MAINTAINERS
From: Josh Boyer @ 2009-03-31 23:50 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andrew Morton, roel.kluin, linux-kernel
In-Reply-To: <1238543040.6522.10.camel@localhost>
On Wed, Apr 01, 2009 at 10:44:00AM +1100, Michael Ellerman wrote:
>On Tue, 2009-03-31 at 09:29 -0400, Josh Boyer wrote:
>> Add a MAINTAINERS entry for the hypervisor virtual console support
>> used on IBM POWER servers.
>>
>> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>> ---
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index c5f4e9d..387ad45 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2176,6 +2176,11 @@ W: http://www.ia64-linux.org/
>> T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
>> S: Maintained
>>
>> +IBM HYPERVISOR VIRTUAL CONSOLE
>> +P: Several
>> +L: linuxppc-dev@ozlabs.org
>> +S: Maintained
>
>I don't think it's the "IBM" Hypervisor virtual console driver anymore.
>There are backends for Xen, Beat (Toshiba) and virtio.
Was just going by the copyright in the files, and Documentation/powerpc/hvc*
Also, if there are other backends, then is the list specified really
correct? Perhaps it should just be linux-kernel.
Guess that's the problem with trying to add a maintainers entry for something
that doesn't really have a specific maintainer.
josh
^ permalink raw reply
* Re: [PATCH] Add hvc_console to MAINTAINERS
From: Michael Ellerman @ 2009-03-31 23:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Andrew Morton, roel.kluin, linux-kernel
In-Reply-To: <20090331132944.GB2332@yoda.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On Tue, 2009-03-31 at 09:29 -0400, Josh Boyer wrote:
> Add a MAINTAINERS entry for the hypervisor virtual console support
> used on IBM POWER servers.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> ---
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c5f4e9d..387ad45 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2176,6 +2176,11 @@ W: http://www.ia64-linux.org/
> T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> S: Maintained
>
> +IBM HYPERVISOR VIRTUAL CONSOLE
> +P: Several
> +L: linuxppc-dev@ozlabs.org
> +S: Maintained
I don't think it's the "IBM" Hypervisor virtual console driver anymore.
There are backends for Xen, Beat (Toshiba) and virtio.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: 8641D with linux 2.6.29 did'n show second cpu
From: Kumar Gala @ 2009-03-31 23:27 UTC (permalink / raw)
To: Eduard Fuchs; +Cc: linuxppc-dev
In-Reply-To: <200903311706.55478.edfuchs@uni-kassel.de>
On Mar 31, 2009, at 10:06 AM, Eduard Fuchs wrote:
> Hi,
>
> Am Dienstag 31 M=E4rz 2009 15:20:21 schrieb Kumar Gala:
>> On Mar 31, 2009, at 5:15 AM, Eduard Fuchs wrote:
>>> Hi,
>>>
>>> I'm testing the evaluation board from freescale (MPC8641DHPCN) with
>>> the latest
>>> linux kernel (2.6.29) and the second core seems disabled. CONFIG_SPM
>>> is
>>> enabled but the /proc/cpuinfo shows only one cpu. With original
>>> 2.6.27 kernel
>>> both cpu cores appears in /proc/cpuinfo.
>>>
>>> Has anyone an idea how can i enable the second core?
>>
>> Are you using u-boot? I can't remember if you need a newer u-boot to
>> deal with changes in how we bring up the second core.
>
> Yes. My u-boot version is 2009.03. Are there some additional config =20=
> keys for
> SMP support in u-boot?
It appears we introduced a bug in v2009.03 of u-boot.
- k=
^ permalink raw reply
* Re: using IRQ1 in mpc5121ads
From: David Gibson @ 2009-03-31 23:10 UTC (permalink / raw)
To: sylvain.louchez; +Cc: linuxppc-dev
In-Reply-To: <49d0d82a.09038e0a.585d.348b@mx.google.com>
On Mon, Mar 30, 2009 at 10:33:11AM -0400, sylvain louchez wrote:
> Hello, I'm a newbie looking for where the documentation and implementation
> model can be found.
>
>
>
> My custom driver is looking for an interrupt notification from the kernel -
> and it registers in the /proc/interrupts file as expected when installed,
> i.e.
>
> $insmod custom_driver.ko gps_irq=<n>
>
> **Note - this part's OK, I see the instance in /proc/interrupts after I load
> it**
>
>
>
> On the hardware side the actual signal is a 1 Hz pulse (from GPS) routed to
> IRQ1 through the board's CPLD. This is the only interrupt on IRQ_1 so we can
> keep the logic simple i.e. on IRQ1 we can just jump to the service routine
> in a custom driver.
>
>
>
> I understand 2 things have to be done:
>
>
>
> 1. create an entry in the dts file; I think we've got this understood
> through advice already received - for example the new interrupt entry can be
> created in the dts file - something like:
>
>
>
> gps@0 { // there is no address so just make it 0
>
> compatible = "gps_interrupt";
Sorry, this is not relevant to your actual question, but this is not a
good 'compatible' value. You should use the "vendor,model" convention
here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: i2c-mpc: preserve I2C clocking
From: David Gibson @ 2009-03-31 23:06 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20090331124348.330571158@denx.de>
On Tue, Mar 31, 2009 at 02:43:39PM +0200, Wolfgang Grandegger wrote:
> The I2c node property "fsl,preserve-clocking" allows to overtake the
> clock settings from the boot loader and avoids the hard-coded setting.
Hrm. This is dubious. The device tree should generally describe
hardware, not OS/driver behaviour which is what this appears to be
doing. There are exceptions, but you need to justify them.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
From: David Gibson @ 2009-03-31 23:04 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20090331124036.057237866@denx.de>
On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
> Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:24:38.078719288 +0200
> +++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:47:56.986720719 +0200
> @@ -52,6 +52,7 @@
> soc8544@e0000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> + device_type = "soc";
You should not be adding device_type to a new board's dts. You
*especially* shouldn't be doing that with no patch comment explaining
why.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [ppc64] 2.6.29-git7 : offlining a cpu causes an exception
From: Benjamin Herrenschmidt @ 2009-03-31 22:44 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev
In-Reply-To: <49D1E21E.3090505@in.ibm.com>
On Tue, 2009-03-31 at 14:57 +0530, Sachin Sant wrote:
> While executing CPU HotPlug[1] tests i observed that during
> every cpu offline process an exception is thrown.
Looks like a BUG_ON() to me... can you look at what other
messages just before that ?
That or lookup where the PC and LR values are in System.map
and maybe get us a backtrace from xmon ?
(You seem to have no symbols, have you built with kallsyms ?)
Ben.
> cpu 0x2: Vector: 700 (Program Check) at [c0000000074c7ca0]
> pc: 00000000007b6640
> lr: 000000000079ddc0
> sp: c0000000074c7f20
> msr: 8000000000081002
> current = 0xc0000000fe1c8580
> paca = 0xc000000000ab2800
> pid = 0, comm = swapper
> 2:mon> r
> R00 = 0000000000000000 R16 = 0000000000000002
> R01 = c0000000074c7f20 R17 = 0000000000000000
> R02 = 00000000009e8dc0 R18 = 0000000000000000
> R03 = 0000000000008278 R19 = 0000000000000000
> R04 = 0000000000008000 R20 = 0000000000000000
> R05 = 0000000000000002 R21 = 0000000000000000
> R06 = 0000000000000002 R22 = c000000000b33ae0
> R07 = 0000000000000000 R23 = 0000000000000000
> R08 = 0000000000000000 R24 = 0000000000000002
> R09 = 00000000000082fc R25 = 0000000000000000
> R10 = 0000000000000000 R26 = 0000000000000004
> R11 = a000000000001002 R27 = c000000000a95bd8
> R12 = a000000000000000 R28 = 0000000000000008
> R13 = c000000000ab2800 R29 = ffffffffffffffff
> R14 = 0000000000000000 R30 = c00000000095e750
> R15 = 0000000007531868 R31 = 0000000007d70b20
> pc = 00000000007b6640
> lr = 000000000079ddc0
> msr = 8000000000081002 cr = 22000004
> ctr = 0000000000000000 xer = 0000000000000020 trap = 700
> 2:mon> u
> SLB contents of cpu 2
> 00 c000000008000000 40004f7ca3000500 1T ESID= c00000 VSID= 4f7ca3 LLP:100
> 01 d000000008000000 4000eb71b0000510 1T ESID= d00000 VSID= eb71b0 LLP:110
> 24 0000000008000000 0000000000000c80 256M ESID= 0 VSID= 0 LLP: 0
> 2:mon>
>
> I can recreate this problem very easily on power5
> as well as power6 box.
>
> 2.6.29-git6 did not have this problem. Let me know if there
> is any other information i can provide. I have attached the
> dmesg log here.
>
> Thanks
> -Sachin
>
> [1] -> CPU Hotplug test which is part of LTP.
>
> plain text document attachment (dmesg_cpu_hotplug)
> <6>Phyp-dump disabled at boot time.
> <6>Using pSeries machine description.
> <7>Page orders: linear mapping = 24, virtual = 16, io = 12.
> <6>Using 1TB segments.
> <4>Found initrd at 0xc0000000034d0000:0xc000000003c7f14f.
> <6>console [udbg0] enabled.
> <6>Partition configured for 4 cpus..
> <6>CPU maps initialized for 2 threads per core.
> <7> (thread shift is 1).
> <4>Starting Linux PPC64 #3 SMP Tue Mar 31 14:33:34 IST 2009.
> <4>-----------------------------------------------------.
> <4>ppc64_pft_size = 0x1a.
> <4>physicalMemorySize = 0x100000000.
> <4>htab_hash_mask = 0x7ffff.
> <4>-----------------------------------------------------.
> <6>Initializing cgroup subsys cpuset.
> <6>Initializing cgroup subsys cpu.
> <5>Linux version 2.6.29-git7 (root@llm62) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #3 SMP Tue Mar 31 14:33:34 IST 2009.
> <4>[boot]0012 Setup Arch.
> <7>Node 0 Memory: 0x0-0x100000000.
> <4>EEH: No capable adapters found.
> <6>PPC64 nvram contains 15360 bytes.
> <7>Using shared processor idle loop.
> <4>Zone PFN ranges:.
> <4> DMA 0x00000000 -> 0x00010000.
> <4> Normal 0x00010000 -> 0x00010000.
> <4>Movable zone start PFN for each node.
> <4>early_node_map[1] active PFN ranges.
> <4> 0: 0x00000000 -> 0x00010000.
> <7>On node 0 totalpages: 65536.
> <7> DMA zone: 56 pages used for memmap.
> <7> DMA zone: 0 pages reserved.
> <7> DMA zone: 65480 pages, LIFO batch:1.
> <4>[boot]0015 Setup Done.
> <4>Built 1 zonelists in Node order, mobility grouping on. Total pages: 65480.
> <4>Policy zone: DMA.
> <5>Kernel command line: root=/dev/sda5 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M .
> <6>NR_IRQS:512.
> <4>[boot]0020 XICS Init.
> <4>[boot]0021 XICS Done.
> <7>pic: no ISA interrupt controller.
> <4>PID hash table entries: 4096 (order: 12, 32768 bytes).
> <7>time_init: decrementer frequency = 512.000000 MHz.
> <7>time_init: processor frequency = 4704.000000 MHz.
> <6>clocksource: timebase mult[7d0000] shift[22] registered.
> <7>clockevent: decrementer mult[8312] shift[16] cpu[0].
> <4>Console: colour dummy device 80x25.
> <6>console handover: boot [udbg0] -> real [hvc0].
> <6>Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes).
> <6>Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes).
> <6>allocated 2621440 bytes of page_cgroup.
> <6>please try cgroup_disable=memory option if you don't want.
> <4>freeing bootmem node 0.
> <6>Memory: 4119872k/4194304k available (8192k kernel code, 74432k reserved, 1984k data, 4194k bss, 448k init).
> <6>Calibrating delay loop... 1022.36 BogoMIPS (lpj=5111808).
> <6>Security Framework initialized.
> <6>SELinux: Disabled at boot..
> <4>Mount-cache hash table entries: 4096.
> <6>Initializing cgroup subsys debug.
> <6>Initializing cgroup subsys ns.
> <6>Initializing cgroup subsys cpuacct.
> <6>Initializing cgroup subsys memory.
> <6>Initializing cgroup subsys devices.
> <6>Initializing cgroup subsys freezer.
> <7>clockevent: decrementer mult[8312] shift[16] cpu[1].
> <4>Processor 1 found..
> <7>clockevent: decrementer mult[8312] shift[16] cpu[2].
> <4>Processor 2 found..
> <7>clockevent: decrementer mult[8312] shift[16] cpu[3].
> <4>Processor 3 found..
> <6>Brought up 4 CPUs.
> <7>Node 0 CPUs: 0-3.
> <7>CPU0 attaching sched-domain:.
> <7> domain 0: span 0-1 level SIBLING.
> <7> groups: 0 1.
> <7> domain 1: span 0-3 level CPU.
> <7> groups: 0-1 2-3.
> <7> domain 2: span 0-3 level NODE.
> <7> groups: 0-3.
> <7>CPU1 attaching sched-domain:.
> <7> domain 0: span 0-1 level SIBLING.
> <7> groups: 1 0.
> <7> domain 1: span 0-3 level CPU.
> <7> groups: 0-1 2-3.
> <7> domain 2: span 0-3 level NODE.
> <7> groups: 0-3.
> <7>CPU2 attaching sched-domain:.
> <7> domain 0: span 2-3 level SIBLING.
> <7> groups: 2 3.
> <7> domain 1: span 0-3 level CPU.
> <7> groups: 2-3 0-1.
> <7> domain 2: span 0-3 level NODE.
> <7> groups: 0-3.
> <7>CPU3 attaching sched-domain:.
> <7> domain 0: span 2-3 level SIBLING.
> <7> groups: 3 2.
> <7> domain 1: span 0-3 level CPU.
> <7> groups: 2-3 0-1.
> <7> domain 2: span 0-3 level NODE.
> <7> groups: 0-3.
> <6>net_namespace: 1888 bytes.
> <6>NET: Registered protocol family 16.
> <6>IBM eBus Device Driver.
> <6>PCI: Probing PCI hardware.
> <7>PCI: Probing PCI hardware done.
> <4>bio: create slab
> <bio-0> at 0.
> <6>usbcore: registered new interface driver usbfs.
> <6>usbcore: registered new interface driver hub.
> <6>usbcore: registered new device driver usb.
> <6>NET: Registered protocol family 2.
> <7>Switched to high resolution mode on CPU 0.
> <7>Switched to high resolution mode on CPU 1.
> <7>Switched to high resolution mode on CPU 2.
> <7>Switched to high resolution mode on CPU 3.
> <6>IP route cache hash table entries: 32768 (order: 2, 262144 bytes).
> <6>TCP established hash table entries: 131072 (order: 5, 2097152 bytes).
> <6>TCP bind hash table entries: 65536 (order: 4, 1048576 bytes).
> <6>TCP: Hash tables configured (established 131072 bind 65536).
> <6>TCP reno registered.
> <6>NET: Registered protocol family 1.
> <6>Unpacking initramfs... done.
> <4>Freeing initrd memory: 7868k freed.
> <6>IOMMU table initialized, virtual merging enabled.
> <7>RTAS daemon started.
> <6>audit: initializing netlink socket (disabled).
> <5>type=2000 audit(1238490478.637:1): initialized.
> <6>Kprobe smoke test started.
> <6>Kprobe smoke test passed successfully.
> <6>HugeTLB registered 16 MB page size, pre-allocated 0 pages.
> <6>HugeTLB registered 16 GB page size, pre-allocated 0 pages.
> <5>VFS: Disk quotas dquot_6.5.2.
> <4>Dquot-cache hash table entries: 8192 (order 0, 65536 bytes).
> <6>msgmni has been set to 8060.
> <6>alg: No test for stdrng (krng).
> <6>Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254).
> <6>io scheduler noop registered.
> <6>io scheduler anticipatory registered.
> <6>io scheduler deadline registered.
> <6>io scheduler cfq registered (default).
> <6>pci_hotplug: PCI Hot Plug PCI Core version: 0.5.
> <6>rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1.
> <7>vio_register_driver: driver hvc_console registering.
> <7>HVSI: registered 0 devices.
> <6>Generic RTC Driver v1.07.
> <6>Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled.
> <6>pmac_zilog: 0.6 (Benjamin Herrenschmidt
> <benh@kernel.crashing.org>).
> <6>input: Macintosh mouse button emulation as /devices/virtual/input/input0.
> <6>Uniform Multi-Platform E-IDE driver.
> <6>ide-gd driver 1.18.
> <6>IBM eHEA ethernet device driver (Release EHEA_0100).
> <6>ehea: eth0: Jumbo frames are disabled.
> <6>ehea: eth0 -> logical port id #2.
> <6>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver.
> <6>ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver.
> <6>mice: PS/2 mouse device common for all mice.
> <6>EDAC MC: Ver: 2.1.0 Mar 31 2009.
> <6>usbcore: registered new interface driver hiddev.
> <6>usbcore: registered new interface driver usbhid.
> <6>usbhid: v2.6:USB HID core driver.
> <6>TCP cubic registered.
> <6>NET: Registered protocol family 15.
> <4>registered taskstats version 1.
> <4>Freeing unused kernel memory: 448k freed.
> <6>SysRq : Changing Loglevel.
> <4>Loglevel set to 1.
> <5>SCSI subsystem initialized.
> <7>vio_register_driver: driver ibmvscsi registering.
> <6>ibmvscsi 30000002: SRP_VERSION: 16.a.
> <6>scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8.
> <6>ibmvscsi 30000002: partner initialization complete.
> <6>ibmvscsi 30000002: sent SRP login.
> <6>ibmvscsi 30000002: SRP_LOGIN succeeded.
> <6>ibmvscsi 30000002: host srp version: 16.a, host partition VIO (1), OS 3, max io 1048576.
> <5>scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3.
> <6>udevd version 128 started.
> <4>Driver 'sd' needs updating - please use bus_type methods.
> <5>sd 0:0:1:0: [sda] 167772160 512-byte hardware sectors: (85.8 GB/80.0 GiB).
> <5>sd 0:0:1:0: [sda] Write Protect is off.
> <7>sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08.
> <5>sd 0:0:1:0: [sda] Cache data unavailable.
> <3>sd 0:0:1:0: [sda] Assuming drive cache: write through.
> <5>sd 0:0:1:0: [sda] Cache data unavailable.
> <3>sd 0:0:1:0: [sda] Assuming drive cache: write through.
> <6> sda: sda1 sda2
> < sda5 > sda3 sda4.
> <5>sd 0:0:1:0: [sda] Attached SCSI disk.
> <6>kjournald starting. Commit interval 5 seconds.
> <6>EXT3 FS on sda5, internal journal.
> <6>EXT3-fs: mounted filesystem with ordered data mode..
> <6>udevd version 128 started.
> <5>sd 0:0:1:0: Attached scsi generic sg0 type 0.
> <6>Adding 1044096k swap on /dev/sda3. Priority:-1 extents:1 across:1044096k .
> <6>device-mapper: uevent: version 1.0.3.
> <6>device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com.
> <6>loop: module loaded.
> <6>fuse init (API version 7.11).
> <6>ehea: eth0: Physical port up.
> <6>ehea: External switch port is backup port.
> <6>NET: Registered protocol family 10.
> <6>lo: Disabled Privacy Extensions.
> <7>eth0: no IPv6 routers present.
> <4>cpu 2 (hwid 2) Ready to die....
> <7>CPU0 attaching NULL sched-domain..
> <7>CPU1 attaching NULL sched-domain..
> <7>CPU2 attaching NULL sched-domain..
> <7>CPU3 attaching NULL sched-domain..
> <7>CPU0 attaching sched-domain:.
> <7> domain 0: span 0-1 level SIBLING.
> <7> groups: 0 1.
> <7> domain 1: span 0-1,3 level CPU.
> <7> groups: 0-1 3.
> <7> domain 2: span 0-1,3 level NODE.
> <7> groups: 0-1,3.
> <7>CPU1 attaching sched-domain:.
> <7> domain 0: span 0-1 level SIBLING.
> <7> groups: 1 0.
> <7> domain 1: span 0-1,3 level CPU.
> <7> groups: 0-1 3.
> <7> domain 2: span 0-1,3 level NODE.
> <7> groups: 0-1,3.
> <7>CPU3 attaching sched-domain:.
> <7> domain 0: span 0-1,3 level CPU.
> <7> groups: 3 0-1.
> <7> domain 1: span 0-1,3 level NODE.
> <7> groups: 0-1,3.....................
^ permalink raw reply
* Re: [PATCH 00/14] Add common OF device tree support for MDIO busses
From: David Miller @ 2009-03-31 22:22 UTC (permalink / raw)
To: grant.likely; +Cc: Joakim.Tjernlund, netdev, linuxppc-dev, afleming, olof
In-Reply-To: <fa686aa40903311519m3108c697v52180d192975a3b1@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Tue, 31 Mar 2009 16:19:42 -0600
> On Tue, Mar 31, 2009 at 3:57 PM, David Miller <davem@davemloft.net> wrote:
> > It therefore didn't get any -next exposure, so it's unreasonable to
> > merge this stuff now.
>
> Since when has sitting in a -next tree been a requirement for merging
> when the series has been kept up to date and tested? I purposefully
> kept it out of -next to ensure that when it was applied for real to a
> -next tree it would be as complete, bug free, and bisectable as
> possible since once it hits a signed-off -next branch the individual
> commit cannot be modified.
I know your pissed off, but take a deep breath and consider this
from my position.
If I don't put a line in the sand somewhere, everyone can say
"I've been working so hard, I posted it to the lists a thousand
times, I have tons of testers" and I have to put the change in.
That doesn't work, so please wait until the next release to get
your changes in. And get them into a tree that gets exposure
in linux-next. Then you have nothing to worry about.
Thank you.
^ permalink raw reply
* Re: MPC83xx console : no output after handover
From: Matthew L. Creech @ 2009-03-31 22:22 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <49D28A7E.2090703@mlbassoc.com>
On Tue, Mar 31, 2009 at 5:26 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>
> The fact that you get the ttyS1 line printed is interesting. =A0At
> this point, the kernel is switching from raw console I/O (only
> suitable for bring-up messages) to the general serial driver
> (interrupt driven, etc). =A0I'm curious about what the ttyS1 driver
> is causing to break...
>
> A couple of things you could try:
> =A0* Disable ttyS1 (take it out of your device tree)
I tried taking ttyS1 out - the results are no different (other than
the fact that "console handover" is now the last line that prints).
My debug printk()s at the end of 8250_init() show up, which would seem
to imply that ttyS0 was initialized correctly, so I'm not sure what
else could be stomping on it.
> =A0* Look at the console log when this happens. =A0Look in your system
> =A0 =A0map for the symbol '__log_buf', e.g.
> =A0 =A0 =A0 c031ca54 b __log_buf
> =A0 =A0This will get stored at physical location '0x31ca54' and will
> =A0 =A0often contain data that didn't get a chance to print, for example
> =A0 =A0if you have stuck interrupts that prevent the console from working=
.
> =A0 =A0I'd just run it to this point and then examine the memory - either
> =A0 =A0using a BDI if one is attached, or press RESET (I hope you have on=
e!)
> =A0 =A0and then look using your boot loader (uBoot, RedBoot, ...)
>
I think I can get my hands on a BDI tomorrow, so I'll give this a try
then. Thanks for the reply
--=20
Matthew L. Creech
^ permalink raw reply
* Re: [PATCH 00/14] Add common OF device tree support for MDIO busses
From: Grant Likely @ 2009-03-31 22:19 UTC (permalink / raw)
To: David Miller; +Cc: Joakim.Tjernlund, netdev, linuxppc-dev, afleming, olof
In-Reply-To: <20090331.145738.36845509.davem@davemloft.net>
On Tue, Mar 31, 2009 at 3:57 PM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Tue, 31 Mar 2009 02:26:43 -0600
>
>> David, as I mentioned below, I'd really like to get the core changes
>> (1, 4, 5 =A06) merged into 2.6.30 (assuming Andy confirms they are okay)=
.
>
> No, sorry.
>
> We could have worked out the interdependencies before the merge window
> openned up. =A0There is no reason this could not have sat in at least
> somebody's tree before the merge window started.
It's been out there on the list since before the merge window, getting
tested by more than just me. This is not series which has simply
dropped out of thin air. I've been working hard to address issues
reported by others (Thanks Olof!) and to keep it building and applying
cleanly to the top of tree.
> It therefore didn't get any -next exposure, so it's unreasonable to
> merge this stuff now.
Since when has sitting in a -next tree been a requirement for merging
when the series has been kept up to date and tested? I purposefully
kept it out of -next to ensure that when it was applied for real to a
-next tree it would be as complete, bug free, and bisectable as
possible since once it hits a signed-off -next branch the individual
commit cannot be modified.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 00/14] Add common OF device tree support for MDIO busses
From: David Miller @ 2009-03-31 21:57 UTC (permalink / raw)
To: grant.likely; +Cc: Joakim.Tjernlund, netdev, linuxppc-dev, afleming, olof
In-Reply-To: <20090331075537.1427.7819.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Tue, 31 Mar 2009 02:26:43 -0600
> David, as I mentioned below, I'd really like to get the core changes
> (1, 4, 5 6) merged into 2.6.30 (assuming Andy confirms they are okay).
No, sorry.
We could have worked out the interdependencies before the merge window
openned up. There is no reason this could not have sat in at least
somebody's tree before the merge window started.
It therefore didn't get any -next exposure, so it's unreasonable to
merge this stuff now.
^ permalink raw reply
* Re: MPC83xx console : no output after handover
From: Scott Wood @ 2009-03-31 21:48 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <5ee96a840903311330y36ed97bet92319da8d118086@mail.gmail.com>
On Tue, Mar 31, 2009 at 04:30:26PM -0400, Matthew L. Creech wrote:
> (Sorry if this is a dupe, but I think my first attempt was filtered out)
No, it's a dupe. :-)
> I'm trying to get Linux booting on a custom board based on the MPC8313
> ERDB, but there's no output after the console is transferred. I get
> the following:
[snip]
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
Make sure that u-boot for your board (or whatever you're using) is
properly filling in the clock-frequency property of the serial port
nodes.
-Scott
^ permalink raw reply
* Re: [PATCH] Add hvc_console to MAINTAINERS
From: Joe Perches @ 2009-03-31 21:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, roel.kluin
In-Reply-To: <20090331142252.3bf74fe1.akpm@linux-foundation.org>
On Tue, 2009-03-31 at 14:22 -0700, Andrew Morton wrote:
> On Tue, 31 Mar 2009 14:10:23 -0700
> Joe Perches <joe@perches.com> wrote:
> > On Tue, 2009-03-31 at 09:29 -0400, Josh Boyer wrote:
> > > Add a MAINTAINERS entry for the hypervisor virtual console support
> > > used on IBM POWER servers.
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index c5f4e9d..387ad45 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -2176,6 +2176,11 @@ W: http://www.ia64-linux.org/
> > > T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> > > S: Maintained
> > >
> > > +IBM HYPERVISOR VIRTUAL CONSOLE
> > > +P: Several
> > > +L: linuxppc-dev@ozlabs.org
> > > +S: Maintained
> > > +
> > > IBM MCA SCSI SUBSYSTEM DRIVER
> > > P: Michael Lang
> > > M: langa2@kph.uni-mainz.de
> >
> > I think this sort of entry should not be acceptable.
> > Maintainers should have individual names and contact addresses.
>
> There isn't a maintainer.
>
> But people send patches to the wrong list, so the ppc guys (who use
> this driver) don't get to see them.
>
> That's a practical, real-world problem. We should have a fix for it.
>
> > An exploder entry should be OK though.
> > For instance, the DVB subsystem:
> >
> > DVB SUBSYSTEM AND DRIVERS
> > P: LinuxTV.org Project
> > M: linux-media@vger.kernel.org
> >
> > A list entry could be something like:
> >
> > P: Linux PCMCIA Team
> > L: linux-pcmcia@lists.infradead.org
> >
>
> I'm unclear on what the difference is here..
I have no problem with the "L: list" entry.
I think that's good. Along with some file
matching pattern as well of course...
I think the "P: Several" entry is not good.
"Several" doesn't give any idea as to who
actually does the work.
If the "P:" entry is there at all, it should
be the list name.
Maybe "P: Linux PPC Development Team" or
something similar.
^ permalink raw reply
* Re: Interrupts on GPIO
From: Grant Likely @ 2009-03-31 21:38 UTC (permalink / raw)
To: Yann Pelletier; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <9A8B45DD4DE17F4783430D784DA0B68811C429F9B7@HEXMBVS12.hostedmsx.local>
On Tue, Mar 31, 2009 at 2:59 PM, Yann Pelletier
<ypelletier@haivision.com> wrote:
>> Message: 7
>> Date: Mon, 30 Mar 2009 10:32:17 -0600
>> From: Grant Likely <grant.likely@secretlab.ca>
>> Subject: > To: Yann Pelletier <ypelletier@haivision.com>
>> Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
>> Message-ID:
>> =A0 =A0 =A0 <fa686aa40903300932p2c92110g2907bb7bf80d44d@mail.gmail.com>
>> Content-Type: text/plain; charset=3DISO-8859-1
>>
>> On Mon, Mar 30, 2009 at 9:57 AM, Yann Pelletier
>> <ypelletier@haivision.com> wrote:
>> >
>> > Hi,
>> > I'd like to add supports for interrupts handling from GPIO controller.
>> ?Some of these interrupts are from I2C devices and some others are from
>> SPI devices.
>> >
>> > What is the best approach to enable interrupts handling for those
>> devices through GPIO.
>>
>> Modify the GPIO driver to also be a cascaded IRQ driver (see
>> http://patchwork.ozlabs.org/patch/21914/ for an example).
>>
>
> I've looked at the patch but I wonder if this would be applicable to the =
MPC8313. =A0If my understanding is good, in the MPC52xx you have 8 gpio onl=
y interrupts and 8 gpio/gpt. =A0With the MPC8313, each GPIO can act as an i=
nterrupt but they are all muxed to only 1 interrupt in the IPIC. =A0So I'm =
concern about making the GPIO controller act as an interrupt controller.
Why? The situation really isn't any different. Using the GPIO
controller hardware as a Linux interrupt controller means that other
drivers can just use it without having to do anything special. It's
just and IRQ.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: MPC83xx console : no output after handover
From: Gary Thomas @ 2009-03-31 21:26 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <5ee96a840903311403r331943d2wf9dbb16491f6bc3@mail.gmail.com>
Matthew L. Creech wrote:
> On Tue, Mar 31, 2009 at 4:45 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> What does your command line (boot args) when it fails? It should
>> probably have something like "console=ttyS0,115200" in it.
>>
>
> Yes, that's what I'm using. It also seems to be the default if none
> is supplied.
>
> For the sake of completeness, here's a full dump:
>
> ============
> Using MPC831x RDB machine description
> Linux version 2.6.29 (mlcreech@lap) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-50
> ) ) #3 PREEMPT Tue Mar 31 15:10:02 EDT 2009
> console [udbg0] enabled
> setup_arch: bootmem
> mpc831x_rdb_setup_arch()
> arch: exit
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00008000
> Normal 0x00008000 -> 0x00008000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00008000
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
> Kernel command line: root=/dev/mtdblock1 init=/bin/sh console=ttyS0,115200
> IPIC (128 IRQ sources) at fdffd700
> PID hash table entries: 512 (order: 9, 2048 bytes)
> clocksource: timebase mult[7800001] shift[22] registered
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 126236k/131072k available (3260k kernel code, 4692k reserved, 136k data,
> 98k bss, 160k init)
> SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> Calibrating delay loop... 66.30 BogoMIPS (lpj=33152)
> Mount-cache hash table entries: 512
> net_namespace: 708 bytes
> NET: Registered protocol family 16
>
> bio: create slab <bio-0> at 0
> Freescale Elo / Elo Plus DMA driver
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> NET: Registered protocol family 1
> WDT driver for MPC8xxx initialized. mode:reset timeout=65535 (32 seconds)
> fsl-elo-dma e00082a8.dma: Probe the Freescale DMA driver for fsl,elo-dma control
> ler at e00082a8...
> fsl-elo-dma e00082a8.dma: #0 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #1 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #2 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #3 (fsl,elo-dma-channel), irq 71
> squashfs: version 4.0 (2009/01/31) Phillip Lougher
> Registering unionfs 2.5.1 (for 2.6.29-rc2)
> yaffs Mar 31 2009 02:31:59 Installing.
> msgmni has been set to 246
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered (default)
> io scheduler cfq registered
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
> ============
The fact that you get the ttyS1 line printed is interesting. At
this point, the kernel is switching from raw console I/O (only
suitable for bring-up messages) to the general serial driver
(interrupt driven, etc). I'm curious about what the ttyS1 driver
is causing to break...
A couple of things you could try:
* Disable ttyS1 (take it out of your device tree)
* Look at the console log when this happens. Look in your system
map for the symbol '__log_buf', e.g.
c031ca54 b __log_buf
This will get stored at physical location '0x31ca54' and will
often contain data that didn't get a chance to print, for example
if you have stuck interrupts that prevent the console from working.
I'd just run it to this point and then examine the memory - either
using a BDI if one is attached, or press RESET (I hope you have one!)
and then look using your boot loader (uBoot, RedBoot, ...)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] Add hvc_console to MAINTAINERS
From: Andrew Morton @ 2009-03-31 21:22 UTC (permalink / raw)
To: Joe Perches; +Cc: linuxppc-dev, linux-kernel, roel.kluin
In-Reply-To: <1238533823.9715.292.camel@localhost>
On Tue, 31 Mar 2009 14:10:23 -0700
Joe Perches <joe@perches.com> wrote:
> On Tue, 2009-03-31 at 09:29 -0400, Josh Boyer wrote:
> > Add a MAINTAINERS entry for the hypervisor virtual console support
> > used on IBM POWER servers.
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > ---
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index c5f4e9d..387ad45 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2176,6 +2176,11 @@ W: http://www.ia64-linux.org/
> > T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> > S: Maintained
> >
> > +IBM HYPERVISOR VIRTUAL CONSOLE
> > +P: Several
> > +L: linuxppc-dev@ozlabs.org
> > +S: Maintained
> > +
> > IBM MCA SCSI SUBSYSTEM DRIVER
> > P: Michael Lang
> > M: langa2@kph.uni-mainz.de
>
> I think this sort of entry should not be acceptable.
> Maintainers should have individual names and contact addresses.
There isn't a maintainer.
But people send patches to the wrong list, so the ppc guys (who use
this driver) don't get to see them.
That's a practical, real-world problem. We should have a fix for it.
> An exploder entry should be OK though.
> For instance, the DVB subsystem:
>
> DVB SUBSYSTEM AND DRIVERS
> P: LinuxTV.org Project
> M: linux-media@vger.kernel.org
>
> A list entry could be something like:
>
> P: Linux PCMCIA Team
> L: linux-pcmcia@lists.infradead.org
>
I'm unclear on what the difference is here..
^ permalink raw reply
* Re: [PATCH] Add hvc_console to MAINTAINERS
From: Joe Perches @ 2009-03-31 21:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Andrew Morton, roel.kluin, linux-kernel
In-Reply-To: <20090331132944.GB2332@yoda.jdub.homelinux.org>
On Tue, 2009-03-31 at 09:29 -0400, Josh Boyer wrote:
> Add a MAINTAINERS entry for the hypervisor virtual console support
> used on IBM POWER servers.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> ---
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c5f4e9d..387ad45 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2176,6 +2176,11 @@ W: http://www.ia64-linux.org/
> T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> S: Maintained
>
> +IBM HYPERVISOR VIRTUAL CONSOLE
> +P: Several
> +L: linuxppc-dev@ozlabs.org
> +S: Maintained
> +
> IBM MCA SCSI SUBSYSTEM DRIVER
> P: Michael Lang
> M: langa2@kph.uni-mainz.de
I think this sort of entry should not be acceptable.
Maintainers should have individual names and contact addresses.
An exploder entry should be OK though.
For instance, the DVB subsystem:
DVB SUBSYSTEM AND DRIVERS
P: LinuxTV.org Project
M: linux-media@vger.kernel.org
A list entry could be something like:
P: Linux PCMCIA Team
L: linux-pcmcia@lists.infradead.org
^ permalink raw reply
* Re: MPC83xx console : no output after handover
From: Matthew L. Creech @ 2009-03-31 21:03 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <49D280E0.9020701@mlbassoc.com>
On Tue, Mar 31, 2009 at 4:45 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>
> What does your command line (boot args) when it fails? =A0It should
> probably have something like "console=3DttyS0,115200" in it.
>
Yes, that's what I'm using. It also seems to be the default if none
is supplied.
For the sake of completeness, here's a full dump:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Using MPC831x RDB machine description
Linux version 2.6.29 (mlcreech@lap) (gcc version 4.3.2 (Sourcery G++ Lite 4=
.3-50
) ) #3 PREEMPT Tue Mar 31 15:10:02 EDT 2009
console [udbg0] enabled
setup_arch: bootmem
mpc831x_rdb_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00008000
Normal 0x00008000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00008000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: root=3D/dev/mtdblock1 init=3D/bin/sh console=3DttyS0,1=
15200
IPIC (128 IRQ sources) at fdffd700
PID hash table entries: 512 (order: 9, 2048 bytes)
clocksource: timebase mult[7800001] shift[22] registered
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126236k/131072k available (3260k kernel code, 4692k reserved, 136k =
data,
98k bss, 160k init)
SLUB: Genslabs=3D12, HWalign=3D32, Order=3D0-3, MinObjects=3D0, CPUs=3D1, N=
odes=3D1
Calibrating delay loop... 66.30 BogoMIPS (lpj=3D33152)
Mount-cache hash table entries: 512
net_namespace: 708 bytes
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Freescale Elo / Elo Plus DMA driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
WDT driver for MPC8xxx initialized. mode:reset timeout=3D65535 (32 seconds)
fsl-elo-dma e00082a8.dma: Probe the Freescale DMA driver for fsl,elo-dma co=
ntrol
ler at e00082a8...
fsl-elo-dma e00082a8.dma: #0 (fsl,elo-dma-channel), irq 71
fsl-elo-dma e00082a8.dma: #1 (fsl,elo-dma-channel), irq 71
fsl-elo-dma e00082a8.dma: #2 (fsl,elo-dma-channel), irq 71
fsl-elo-dma e00082a8.dma: #3 (fsl,elo-dma-channel), irq 71
squashfs: version 4.0 (2009/01/31) Phillip Lougher
Registering unionfs 2.5.1 (for 2.6.29-rc2)
yaffs Mar 31 2009 02:31:59 Installing.
msgmni has been set to 246
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered (default)
io scheduler cfq registered
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq =3D 16) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq =3D 17) is a 16550A
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(nothing after this)
Thanks
--=20
Matthew L. Creech
^ permalink raw reply
* RE: Interrupts on GPIO
From: Yann Pelletier @ 2009-03-31 20:59 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <mailman.3884.1238431353.26545.linuxppc-dev@ozlabs.org>
> Message: 7
> Date: Mon, 30 Mar 2009 10:32:17 -0600
> From: Grant Likely <grant.likely@secretlab.ca>
> Subject: > To: Yann Pelletier <ypelletier@haivision.com>
> Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
> Message-ID:
> <fa686aa40903300932p2c92110g2907bb7bf80d44d@mail.gmail.com>
> Content-Type: text/plain; charset=3DISO-8859-1
>=20
> On Mon, Mar 30, 2009 at 9:57 AM, Yann Pelletier
> <ypelletier@haivision.com> wrote:
> >
> > Hi,
> > I'd like to add supports for interrupts handling from GPIO controller.
> ?Some of these interrupts are from I2C devices and some others are from
> SPI devices.
> >
> > What is the best approach to enable interrupts handling for those
> devices through GPIO.
>=20
> Modify the GPIO driver to also be a cascaded IRQ driver (see
> http://patchwork.ozlabs.org/patch/21914/ for an example).
>=20
I've looked at the patch but I wonder if this would be applicable to the MP=
C8313. If my understanding is good, in the MPC52xx you have 8 gpio only in=
terrupts and 8 gpio/gpt. With the MPC8313, each GPIO can act as an interru=
pt but they are all muxed to only 1 interrupt in the IPIC. So I'm concern =
about making the GPIO controller act as an interrupt controller.
> > Also,
> >
> > # cat /proc/interrupts
> > ? ? ? ? ? CPU0
> > ?16: ? ? ? ? 60 ? IPIC ? Level ? ? serial
> > ?17: ? ? ? ? ?0 ? IPIC ? Level ? ? fpga
> > ?18: ? ? ? ? ?4 ? IPIC ? Level ? ? mpc83xx_spi
> > ?21: ? ? ? ? ?0 ? IPIC ? Level ? ? i2c-mpc
> > ?22: ? ? ? ? ?7 ? IPIC ? Level ? ? i2c-mpc
> >
> > According to my platform device tree, serial irq should be on int9, SPI
> on int16 and i2c on int14,15. ?This causes me some problems as I need
> int18 to map to external IRQ2.
>=20
> These numbers are *Linux internal* virtual irq numbers. They have no
> relation to the physical IRQ number for each interrupt controller.
> Just make sure your Device Tree maps the IRQs correctly and you'll be
> okay.
>=20
This is good now, thanks
> g.
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>=20
>=20
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox