* Re: [POWERPC] add U-Boot bootcount driver.
From: Vitaly Bordug @ 2009-12-18 5:50 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20091217093434.GA19931@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
В Thu, 17 Dec 2009 10:34:34 +0100
Wolfram Sang <w.sang@pengutronix.de> пишет:
> On Wed, Dec 16, 2009 at 02:47:30AM +0300, Vitaly Bordug wrote:
> >
> > From: Heiko Schocher <hs@denx.de>
> >
> > This driver provides (read/write) access to the
> > U-Boot bootcounter via PROC FS or sysFS.
> >
> > in u-boot, it uses a 8 byte mem area (it must hold the value over a
> > soft reset of course), for storing a bootcounter (it counts many
> > soft resets are done, on hard reset it starts with 0). If the
> > bootcountvalue exceeds the value in the env variable "bootlimit",
> > and alternative bootcmd stored in the env variable "altbootcmd" is
> > run.
>
> Hmm, both in my inbox and in patchwork, the patch seems line-wrapped.
> Also, there are a few printk without loglevel. As probe has access to
> a device structure, dev_* should be a nice option here.
>
OK, makes sense.
-Vitaly
> Regards,
>
> Wolfram
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [POWERPC] add U-Boot bootcount driver.
From: Vitaly Bordug @ 2009-12-18 5:50 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20091217081607.4B621D43F21@gemini.denx.de>
=D0=92 Thu, 17 Dec 2009 09:16:07 +0100
Wolfgang Denk <wd@denx.de> =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> Dear Vitaly Bordug,
>=20
>=20
> repl: bad addresses:
> linuxppc-dev@ozlabs.org <linuxppc-dev@ozlabs.org> -- junk
> after local@domain (<) In message <20091216024730.455b90fd@vitb-lp>
> you wrote:
> >=20
> > From: Heiko Schocher <hs@denx.de>
> >=20
> > This driver provides (read/write) access to the
> > U-Boot bootcounter via PROC FS or sysFS.
> >=20
> > in u-boot, it uses a 8 byte mem area (it must hold the value over a
> > soft reset of course), for storing a bootcounter (it counts many
> > soft resets are done, on hard reset it starts with 0). If the
> > bootcountvalue exceeds the value in the env variable "bootlimit",
> > and alternative bootcmd stored in the env variable "altbootcmd" is
> > run.
> >=20
> > The bootcountregister gets configured via DTS.
> > for example on the mgsuvd board:
> >=20
> > bootcount@0x3eb0 {
> > device_type =3D "bootcount";
> > compatible =3D "uboot,bootcount";
> > reg =3D <0x3eb0 0x08>;
> > };
> >=20
> > This driver is tested on the mgcoge(82xx) and mgsuvd(8xx) board.
> >=20
> > Signed-off-by: Heiko Schocher <hs@denx.de>
> > Signed-off-by: Wolfgang Denk <wd@denx.de>
> > Signed-off-by: Vitaly Bordyug <vitb@kernel.crashing.org>
>=20
> I think it would be good if the text of the commit message could be
> reworked by a native English speaker.
>=20
OK.=20
> Regarding the subject: it is probably important to point out that this
> driver implements the Linux kernel half of the boot count feature -
> the boot counter can only be reset after it is clear that the
> application has been started and is running correctly, which usually
> can only be determined by the application code itself. Thus the reset
> of the boot counter must be done by application code, which thus needs
> an appropriate driver.
>=20
I'll rework the commit message to make it more clear, thanks for the
details!
-Vitaly
> > I think there is no reason not to have this in mainline. Thoughts?
> > And I'm not sure what is right direction to push this - it's
> > representation of u-boot feature in fact, pretty useful tho.
>=20
> It's not only useful, it's actually a required feature by the Carrier
> Grade Linux Requirements Definition; see for example document "Carrier
> Grade Linux Requirements Definition Overview V3.0" at
> https://www.linux-foundation.org/images/1/1a/Cgl_req_def_overview_30.pdf
> Page 49:
>=20
> ID PLT.4.0 (2.3 in v1.1) Boot Cycle Detection
>=20
> Description: OSDL CGL specifies that carrier grade Linux
> shall provide support for detecting a repeating reboot cycle
> due to recurring failures and going to an offline state if
> this occurs.
>=20
>=20
>=20
>=20
> Best regards,
>=20
> Wolfgang Denk
>=20
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Mahesh Jagannath Salgaonkar @ 2009-12-18 5:10 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Masami Hiramatsu
In-Reply-To: <12450.1261043861@neuling.org>
Michael Neuling wrote:
> In message <4B29EE5F.9020801@linux.vnet.ibm.com> you wrote:
>> Hi Michael,
>>
>> Michael Neuling wrote:
>>>> + * regs_get_argument_nth() - get Nth argument at function call
>>>> + * @regs: pt_regs which contains registers at function entry.
>>>> + * @n: argument number.
>>>> + *
>>>> + * regs_get_argument_nth() returns @n th argument of a function call.
>>>> + * Since usually the kernel stack will be changed right after function en
> try
>>> ,
>>>> + * you must use this at function entry. If the @n th entry is NOT in the
>>>> + * kernel stack or pt_regs, this returns 0.
>>>> + */
>>>> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned int n)
>>>> +{
>>>> + if (n < ARRAY_SIZE(arg_offs_table))
>>>> + return *(unsigned long *)((char *)regs + arg_offs_table[n]);
>>>> + else {
>>>> + /*
>>>> + * If more arguments are passed that can be stored in
>>>> + * registers, the remaining arguments are stored in the
>>>> + * parameter save area located at fixed offset from stack
>>>> + * pointer.
>>>> + * Following the PowerPC ABI, the first few arguments are
>>>> + * actually passed in registers (r3-r10), with equivalent space
>>>> + * left unused in the parameter save area.
>>>> + */
>>>> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
>>>> + return regs_get_kernel_stack_nth(regs, n);
>>> How do we handle FP args?
>> Currently this patch does not support FP args.
>
> This might be OK. I don't think we use floating point parameters in any
> function definitions in the kernel.
>
> We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
> they are static inline, so they probably don't even end up as
> functions.
>
> I guess we need to make sure that we're not limiting the interface in
> such a way that we can't support it later if the above changes.
>
> regs_get_argument_nth returns an unsigned long which makes returning a
> 128 bit VMX register impossible. This might be a show stopper for me.
> How are the x86 guys dealing with this?
>
Nope, x86 does not deal with bigger registers (Masami, correct me if I
am wrong). The return data type is opaque to user. Hence this enables us
to handle any such situations in future without effecting user space API.
>>>> + }
>>>> +}
>>>> +/*
>>>> * does not yet catch signals sent when the child dies.
>>>> * in exit.c or in signal.c.
>>>> */
>>>> Index: linux-2.6-tip/kernel/trace/Kconfig
>>>> ===================================================================
>>>> --- linux-2.6-tip.orig/kernel/trace/Kconfig
>>>> +++ linux-2.6-tip/kernel/trace/Kconfig
>>>> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
>>>>
>>>> config KPROBE_EVENT
>>>> depends on KPROBES
>>>> - depends on X86
>>>> + depends on X86 || PPC
>>>> bool "Enable kprobes-based dynamic events"
>>>> select TRACING
>>>> default y
>>>>
>>>> _______________________________________________
>>>> Linuxppc-dev mailing list
>>>> Linuxppc-dev@lists.ozlabs.org
>>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>>>
>> Thanks for reviewing.
>
> We are creating a new user space API here, so I'm keen for others to take
> a good look at the interface before we commit to something we are going
> to have to keep forever.
>
> Who is the main consumer of this (/me is pretty ignorant of kprobes)?
> What do they think of the interface?
>
The user space API are already present in the upstream kernel and
currently only supported architecture is x86. This patch provides ppc
architecture specific interfaces that enables powerpc also in par with x86.
The main consumer would be kernel developers who would like to see
register values, arguments and stack when the probe hits at given text
address.
> Mikey
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: 2.6.32 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds..
From: Barry Song @ 2009-12-18 6:50 UTC (permalink / raw)
To: Zhiyong Wu; +Cc: linuxppc-dev, agraf, llim, linux-kernel, Herbert Xu
In-Reply-To: <b1e768440912172008g605bade0ledc77f91eeaa9d36@mail.gmail.com>
On Fri, Dec 18, 2009 at 12:08 PM, Zhiyong Wu <zwu.kernel@gmail.com> wrote:
> HI,
>
> linux-2.6.32 is compiled on a p6 machine with RH5.4 OS and KVM option is =
enable.
>
> When rebooting this machine, a crash takes place such as:
>
> Loading ramdisk...
> ramdisk loaded at 01700000, size: 2700 Kbytes
> OF stdout device is: /vdevice/vty@30000000
> Preparing to boot Linux version 2.6.32 (root@p6ml4n07.clusters.com)
> (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18
> 06:53:27 EST 2009
> Calling ibm,client-architecture-support.../
> Elapsed time since release of system processors: 1212 mins 30 secs
>
> Config file read, 1024 bytes
>
> Welcome
> Welcome to yaboot version 1.3.13 (Red Hat 1.3.13-8.el5)
> Enter "help" to get some basic usage information
> boot: linux-32
> Please wait, loading kernel...
> =C2=A0 Elf64 kernel loaded...
> Loading ramdisk...
> ramdisk loaded at 01700000, size: 2700 Kbytes
> OF stdout device is: /vdevice/vty@30000000
> Preparing to boot Linux version 2.6.32 (root@p6ml4n07.clusters.com)
> (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18
> 06:53:27 EST 2009
> Calling ibm,client-architecture-support... done
> command line: ro console=3Dhvc0 rhgb quiet root=3DLABEL=3D/
> memory layout at init:
> =C2=A0memory_limit : 0000000000000000 (16 MB aligned)
> =C2=A0alloc_bottom : 00000000019b0000
> =C2=A0alloc_top =C2=A0 =C2=A0: 0000000008000000
> =C2=A0alloc_top_hi : 0000000008000000
> =C2=A0rmo_top =C2=A0 =C2=A0 =C2=A0: 0000000008000000
> =C2=A0ram_top =C2=A0 =C2=A0 =C2=A0: 0000000008000000
> instantiating rtas at 0x0000000006e10000... done
> boot cpu hw idx 0000000000000000
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x0000000001bc0000 -> 0x0000000001bc15bb
> Device tree struct =C2=A00x0000000001bd0000 -> 0x0000000001bf0000
> Calling quiesce...
> returning from prom_init
> Red Hat nash version 5.1.19.6 starting
> ibmvscsi 30000002: fast_fail not supported in server
> sd 0:0:1:0: [sda] Assuming drive cache: write through
> sd 0:0:1:0: [sda] Assuming drive cache: write through
> sd 0:0:1:0: [sda] Assuming drive cache: write through
> insmod: error inserting '/lib/dm-region-hash.ko': -1 File exists
> mount: could not find filesystem '/dev/root'
> setuproot: moving /dev failed: No such file or directory
> setuproot: error mounting /proc: No such file or directory
> setuproot: error mounting /sys: No such file or directory
> switchroot: mount failed: No such file or directory
> Kernel panic - not syncing: Attempted to kill init!
> Rebooting in 180 seconds..[disconnect]
Your rootfs is not ready. No console, no /dev, then init process can't star=
t-up.
>
> Can anyone give me a warm hand?
>
>
> Cheers,
>
> Zhiyong Wu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =C2=A0http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: 2.6.32 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds..
From: Américo Wang @ 2009-12-18 7:12 UTC (permalink / raw)
To: Zhiyong Wu; +Cc: linuxppc-dev, agraf, llim, linux-kernel, Herbert Xu
In-Reply-To: <b1e768440912172008g605bade0ledc77f91eeaa9d36@mail.gmail.com>
On Fri, Dec 18, 2009 at 12:08 PM, Zhiyong Wu <zwu.kernel@gmail.com> wrote:
> HI,
>
> linux-2.6.32 is compiled on a p6 machine with RH5.4 OS and KVM option is =
enable.
>
> When rebooting this machine, a crash takes place such as:
>
> Loading ramdisk...
> ramdisk loaded at 01700000, size: 2700 Kbytes
> OF stdout device is: /vdevice/vty@30000000
> Preparing to boot Linux version 2.6.32 (root@p6ml4n07.clusters.com)
> (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18
> 06:53:27 EST 2009
> Calling ibm,client-architecture-support.../
> Elapsed time since release of system processors: 1212 mins 30 secs
>
> Config file read, 1024 bytes
>
> Welcome
> Welcome to yaboot version 1.3.13 (Red Hat 1.3.13-8.el5)
> Enter "help" to get some basic usage information
> boot: linux-32
> Please wait, loading kernel...
> =C2=A0 Elf64 kernel loaded...
> Loading ramdisk...
> ramdisk loaded at 01700000, size: 2700 Kbytes
> OF stdout device is: /vdevice/vty@30000000
> Preparing to boot Linux version 2.6.32 (root@p6ml4n07.clusters.com)
> (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18
> 06:53:27 EST 2009
> Calling ibm,client-architecture-support... done
> command line: ro console=3Dhvc0 rhgb quiet root=3DLABEL=3D/
> memory layout at init:
> =C2=A0memory_limit : 0000000000000000 (16 MB aligned)
> =C2=A0alloc_bottom : 00000000019b0000
> =C2=A0alloc_top =C2=A0 =C2=A0: 0000000008000000
> =C2=A0alloc_top_hi : 0000000008000000
> =C2=A0rmo_top =C2=A0 =C2=A0 =C2=A0: 0000000008000000
> =C2=A0ram_top =C2=A0 =C2=A0 =C2=A0: 0000000008000000
> instantiating rtas at 0x0000000006e10000... done
> boot cpu hw idx 0000000000000000
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x0000000001bc0000 -> 0x0000000001bc15bb
> Device tree struct =C2=A00x0000000001bd0000 -> 0x0000000001bf0000
> Calling quiesce...
> returning from prom_init
> Red Hat nash version 5.1.19.6 starting
> ibmvscsi 30000002: fast_fail not supported in server
> sd 0:0:1:0: [sda] Assuming drive cache: write through
> sd 0:0:1:0: [sda] Assuming drive cache: write through
> sd 0:0:1:0: [sda] Assuming drive cache: write through
> insmod: error inserting '/lib/dm-region-hash.ko': -1 File exists
> mount: could not find filesystem '/dev/root'
> setuproot: moving /dev failed: No such file or directory
> setuproot: error mounting /proc: No such file or directory
> setuproot: error mounting /sys: No such file or directory
> switchroot: mount failed: No such file or directory
> Kernel panic - not syncing: Attempted to kill init!
> Rebooting in 180 seconds..[disconnect]
>
> Can anyone give me a warm hand?
Probably this is not a problem of kernel, maybe it's
a problem of your initial ramdisk, or something wrong with
your root filesystem.
Does changing "root=3DLABEL=3D/" to "root=3D/dev/XXX" help?
Where "/dev/XXX" is your root filesystem.
^ permalink raw reply
* Re: 2.6.32 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds..
From: Zhiyong Wu @ 2009-12-18 7:38 UTC (permalink / raw)
To: Américo Wang; +Cc: linuxppc-dev, agraf, llim, linux-kernel, Herbert Xu
In-Reply-To: <2375c9f90912172312x7d324979r10da5ecd7edc61d3@mail.gmail.com>
It does'nt still work based on your method.
Cheers,
Zhiyong Wu
On Fri, Dec 18, 2009 at 3:12 PM, Am=E9rico Wang <xiyou.wangcong@gmail.com> =
wrote:
> On Fri, Dec 18, 2009 at 12:08 PM, Zhiyong Wu <zwu.kernel@gmail.com> wrote=
:
>> HI,
>>
>> linux-2.6.32 is compiled on a p6 machine with RH5.4 OS and KVM option is=
enable.
>>
>> When rebooting this machine, a crash takes place such as:
>>
>> Loading ramdisk...
>> ramdisk loaded at 01700000, size: 2700 Kbytes
>> OF stdout device is: /vdevice/vty@30000000
>> Preparing to boot Linux version 2.6.32 (root@p6ml4n07.clusters.com)
>> (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18
>> 06:53:27 EST 2009
>> Calling ibm,client-architecture-support.../
>> Elapsed time since release of system processors: 1212 mins 30 secs
>>
>> Config file read, 1024 bytes
>>
>> Welcome
>> Welcome to yaboot version 1.3.13 (Red Hat 1.3.13-8.el5)
>> Enter "help" to get some basic usage information
>> boot: linux-32
>> Please wait, loading kernel...
>> =A0 Elf64 kernel loaded...
>> Loading ramdisk...
>> ramdisk loaded at 01700000, size: 2700 Kbytes
>> OF stdout device is: /vdevice/vty@30000000
>> Preparing to boot Linux version 2.6.32 (root@p6ml4n07.clusters.com)
>> (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18
>> 06:53:27 EST 2009
>> Calling ibm,client-architecture-support... done
>> command line: ro console=3Dhvc0 rhgb quiet root=3DLABEL=3D/
>> memory layout at init:
>> =A0memory_limit : 0000000000000000 (16 MB aligned)
>> =A0alloc_bottom : 00000000019b0000
>> =A0alloc_top =A0 =A0: 0000000008000000
>> =A0alloc_top_hi : 0000000008000000
>> =A0rmo_top =A0 =A0 =A0: 0000000008000000
>> =A0ram_top =A0 =A0 =A0: 0000000008000000
>> instantiating rtas at 0x0000000006e10000... done
>> boot cpu hw idx 0000000000000000
>> copying OF device tree...
>> Building dt strings...
>> Building dt structure...
>> Device tree strings 0x0000000001bc0000 -> 0x0000000001bc15bb
>> Device tree struct =A00x0000000001bd0000 -> 0x0000000001bf0000
>> Calling quiesce...
>> returning from prom_init
>> Red Hat nash version 5.1.19.6 starting
>> ibmvscsi 30000002: fast_fail not supported in server
>> sd 0:0:1:0: [sda] Assuming drive cache: write through
>> sd 0:0:1:0: [sda] Assuming drive cache: write through
>> sd 0:0:1:0: [sda] Assuming drive cache: write through
>> insmod: error inserting '/lib/dm-region-hash.ko': -1 File exists
>> mount: could not find filesystem '/dev/root'
>> setuproot: moving /dev failed: No such file or directory
>> setuproot: error mounting /proc: No such file or directory
>> setuproot: error mounting /sys: No such file or directory
>> switchroot: mount failed: No such file or directory
>> Kernel panic - not syncing: Attempted to kill init!
>> Rebooting in 180 seconds..[disconnect]
>>
>> Can anyone give me a warm hand?
>
> Probably this is not a problem of kernel, maybe it's
> a problem of your initial ramdisk, or something wrong with
> your root filesystem.
>
> Does changing "root=3DLABEL=3D/" to "root=3D/dev/XXX" help?
> Where "/dev/XXX" is your root filesystem.
>
^ permalink raw reply
* Re: 2.6.32 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds..
From: Américo Wang @ 2009-12-18 7:50 UTC (permalink / raw)
To: Zhiyong Wu; +Cc: linuxppc-dev, agraf, llim, linux-kernel, Herbert Xu
In-Reply-To: <b1e768440912172338k8849393ye23f5e277f554caf@mail.gmail.com>
On Fri, Dec 18, 2009 at 3:38 PM, Zhiyong Wu <zwu.kernel@gmail.com> wrote
> On Fri, Dec 18, 2009 at 3:12 PM, Am=C3=A9rico Wang <xiyou.wangcong@gmail.=
com> wrote:
>> On Fri, Dec 18, 2009 at 12:08 PM, Zhiyong Wu <zwu.kernel@gmail.com> wrot=
e:
>>> HI,
>>>
>>> linux-2.6.32 is compiled on a p6 machine with RH5.4 OS and KVM option i=
s enable.
>>>
>>> When rebooting this machine, a crash takes place such as:
>>>
<snip>
>>> command line: ro console=3Dhvc0 rhgb quiet root=3DLABEL=3D/
>>> memory layout at init:
>>> =C2=A0memory_limit : 0000000000000000 (16 MB aligned)
>>> =C2=A0alloc_bottom : 00000000019b0000
>>> =C2=A0alloc_top =C2=A0 =C2=A0: 0000000008000000
>>> =C2=A0alloc_top_hi : 0000000008000000
>>> =C2=A0rmo_top =C2=A0 =C2=A0 =C2=A0: 0000000008000000
>>> =C2=A0ram_top =C2=A0 =C2=A0 =C2=A0: 0000000008000000
>>> instantiating rtas at 0x0000000006e10000... done
>>> boot cpu hw idx 0000000000000000
>>> copying OF device tree...
>>> Building dt strings...
>>> Building dt structure...
>>> Device tree strings 0x0000000001bc0000 -> 0x0000000001bc15bb
>>> Device tree struct =C2=A00x0000000001bd0000 -> 0x0000000001bf0000
>>> Calling quiesce...
>>> returning from prom_init
>>> Red Hat nash version 5.1.19.6 starting
>>> ibmvscsi 30000002: fast_fail not supported in server
>>> sd 0:0:1:0: [sda] Assuming drive cache: write through
>>> sd 0:0:1:0: [sda] Assuming drive cache: write through
>>> sd 0:0:1:0: [sda] Assuming drive cache: write through
>>> insmod: error inserting '/lib/dm-region-hash.ko': -1 File exists
>>> mount: could not find filesystem '/dev/root'
>>> setuproot: moving /dev failed: No such file or directory
>>> setuproot: error mounting /proc: No such file or directory
>>> setuproot: error mounting /sys: No such file or directory
>>> switchroot: mount failed: No such file or directory
>>> Kernel panic - not syncing: Attempted to kill init!
>>> Rebooting in 180 seconds..[disconnect]
>>>
>>> Can anyone give me a warm hand?
>>
>> Probably this is not a problem of kernel, maybe it's
>> a problem of your initial ramdisk, or something wrong with
>> your root filesystem.
>>
>> Does changing "root=3DLABEL=3D/" to "root=3D/dev/XXX" help?
>> Where "/dev/XXX" is your root filesystem.
>>
>
> It does'nt still work based on your method.
Hmm, so I would guess it's a problem in your initial ramdisk.
So you can boot RH5 native kernel with the same boot options
but only this one not??
Or maybe the udev your are using doesn't work with 2.6.32?
Only another guess...
But anyway, checking your 'mkinitrd' would help.
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Wolfgang Grandegger @ 2009-12-18 8:24 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <200912161237.09796.roman.fietze@telemotive.de>
Roman Fietze wrote:
> Hello Wolfram,
>
> On Wednesday 09 December 2009 15:57:48 Wolfram Sang wrote:
>
>> Do you have a way to measure performance penalties?
>
> As I said, I do.
>
> And here they are. They won't win a price for the most impartial
> benchmarks ever seen, but thet'll be a good starting point to get a
> feeling what stability might cost.
>
> The board is using the MPC5200B on a board derived from the old
> lite5200, but with the fixes for the MPC5200B. All tests are run using
> an ST940813AM hard drive with an ext2 and an ext3 of 10GB each,
> default mkfs options. The OS is Debian 4.0. The network connection is
> between a fast Athlon XP2 6400 and the target, using 100MBit/s wiring
> and a 100MBit/s switch.
>
> The F always stands for fast settings, coherent cache, XLB features
> like snooping, etc. turned on, XLB config 0x0000a006 or 0x0001a006
> (makes no or no big difference).
>
> The S always stands for slow settings, non coherent cache, XLB
> features like snooping, etc. turned on, XLB config 0x80012006.
What disc access modes, (pio, mwdma or udma) did you use for these tests.
Wolfgang.
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Roman Fietze @ 2009-12-18 9:07 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev
In-Reply-To: <4B2B3C3D.4090308@grandegger.com>
Hello Wolfgang,
On Friday 18 December 2009 09:24:29 Wolfgang Grandegger wrote:
> What disc access modes, (pio, mwdma or udma) did you use for these tests.
MWDMA2.
On our hardware Linux 2.6 UDMA2 only works with very few disks. And on
top of that, UDMA seems to have problems on the MPC5200B with
concurrent traffic to or from the LPC (chips selects of peripherals
while a DMA transfer is active).
The same disks work without problems using UDMA2 on the old 2.4.25 on
exctly the same HW. Why? I don't know yet.
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* Oprofile 0.9.6 on ppc 603 - samples reported for wrong function/symbol?
From: Preben Rynning Myrvoll @ 2009-12-18 12:40 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]
Hi all.
I'm running oprofile on a ppc 603 (in timer mode) and believe I'm getting
reports on samples for the wrong symbol/function.
When running opreport for a specific network module (MyEth), I get a number
of samples reported in a function (below: MyCos_Init) used when loading the
module. This occurs for every test (iperf), although I reset the profiling
data in between I do not reload the module for each run, so there should be
no reason for the opreport to report samples for this function. I've also
instrumented the module, to verify that i do not call the MyCos_Init
repeatedly (in fact it is not called at all after I've loaded it)
The report looks like this..
>~# opreport -l -p /lib/modules/ MyEth
Overflow stats not available
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
warning: could not check that the binary file /lib/modules/MyEth has not
been modified since the profile was taken. Results may be inaccurate.
samples % symbol name
228 39.3782 MyEth_TxThread
219 37.8238 MyEth_TxDone
83 14.3351 MyCos_Init
49 8.4629 MyEth_start_xmit
Looking at a more detailed report (with "-d" option in opreport), I see
where the samples for the function MyCos_Init are taken (from address 230c
to 238c). MyCos_Init is located at 1e3c.
00001e3c 83 14.3351 MyCos_Init
0000230c 9 10.8434
00002318 5 6.0241
0000231c 1 1.2048
00002324 9 10.8434
00002338 21 25.3012
0000233c 2 2.4096
00002344 10 12.0482
0000237c 14 16.8675
00002384 10 12.0482
0000238c 2 2.4096
Running "nm -n /lib/modules/MyEth" to list symbols (sorted), I find the
MyCos_Init at the bottom of the list (Last function / higest address). Is
Oprofile just
reporting defaulting to the last symbol if it can find any reasonable
symbol/function?
If I then look in "/proc/kallsyms" I find where the function is located, and
see there are functions below it belonging to my module. The
list shows me that the function MyCos_Init takes 3E8 address..
c9088e3c t MyCos_Init [MyEth]
c9089224 t MyEth_p_cleanup [MyEth]
c90892a4 t MyEth_exit [MyEth]
c90892a4 t cleanup_module [MyEth]
c9089e58 r __func__.0 [MyEth]
c9089e60 r __func__.1 [MyEth]
Then finally. Adding 3E8 (size allocated for function in kernel) to the
address found from "opreport" /"nm" for the MyCos_Init function (
0x00001e3c) I get 0x00002224.
So the reported samples from opreport is after the addresses for this
function. So is oprofile reporting samples for a wrong function or what? Or
I'm I doing something wrong?
Thanks for any assistance.
Best Regards
Preben
[-- Attachment #2: Type: text/html, Size: 2973 bytes --]
^ permalink raw reply
* Re: [PATCH] Adding PCI-E support for 460SX based redwood board.
From: Josh Boyer @ 2009-12-18 14:03 UTC (permalink / raw)
To: tmarri; +Cc: writetomarri, linuxppc-dev
In-Reply-To: <1259621903-9666-1-git-send-email-tmarri@amcc.com>
On Mon, Nov 30, 2009 at 02:58:23PM -0800, tmarri@amcc.com wrote:
>+ PCIE0: pciex@d00000000 {
>+ device_type = "pci";
>+ #interrupt-cells = <1>;
>+ #size-cells = <2>;
>+ #address-cells = <3>;
>+ compatible = "ibm,plb-pciex-460sx", "ibm,plb-pciex";
>+ primary;
>+ port = <0x0>; /* port number */
>+ reg = <0x0000000d 0x00000000 0x20000000 /* Config space access */
>+ 0x0000000c 0x10000000 0x00001000>; /* Registers */
>+ dcr-reg = <0x100 0x020>;
>+ sdr-base = <0x300>;
>+
>+ /* Outbound ranges, one memory and one IO,
>+ * later cannot be changed
>+ */
>+ ranges = <0x02000000 0x00000000 0x80000000 0x0000000e 0x00000000 0x00000000 0x80000000
>+ 0x01000000 0x00000000 0x00000000 0x0000000f 0x80000000 0x00000000 0x00010000>;
>+
DTC complains about this:
jwboyer@zod:~/src/linux-2.6> make ARCH=powerpc CROSS_COMPILE=ppcnf-unknown- -j2 redwood.dtb
/home/jwboyer/src/linux-2.6/scripts/dtc/dtc -O dtb -o arch/powerpc/boot/redwood.dtb -b 0 -p 1024 /home/jwboyer/src/linux-2.6/arch/powerpc/boot/dts/redwood.dts
DTC: dts->dtb on file "/home/jwboyer/src/linux-2.6/arch/powerpc/boot/dts/redwood.dts"
Warning (ranges_format): "ranges" property in /plb/opb/pciex@d00000000 has invalid length (56 bytes) (parent #address-cells == 1, child #address-cells == 3, #size-cells == 2)
Warning (ranges_format): "ranges" property in /plb/opb/pciex@d20000000 has invalid length (56 bytes) (parent #address-cells == 1, child #address-cells == 3, #size-cells == 2)
Warning (ranges_format): "ranges" property in /plb/opb/pciex@d40000000 has invalid length (56 bytes) (parent #address-cells == 1, child #address-cells == 3, #size-cells == 2)
jwboyer@zod:~/src/linux-2.6>
My guess is that you meant to have this under the PLB bus node, and not the OPB
bus?
josh
^ permalink raw reply
* Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2009-12-18 14:08 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi Ben,
A couple more small commits for .33 below.
I'd like to get the 460SX patch in still, but it's not quite ready. I also plan
on doing some defconfig updates around -rc2. Other than that, I don't have
any outstanding patches other than those below.
thx,
josh
The following changes since commit e090aa80321b64c3b793f3b047e31ecf1af9538d:
Benjamin Herrenschmidt (1):
powerpc: Fix usage of 64-bit instruction in 32-bit altivec code
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next
Anatolij Gustschin (1):
powerpc/44x: Extend Katmai dts for ADMA and RAID56 support
Sean MacLennan (1):
powerpc/44x: Increase warp SD buffer
arch/powerpc/boot/dts/katmai.dts | 52 +++++++++++++++++++++++++++++++++++++-
arch/powerpc/boot/dts/warp.dts | 2 +-
2 files changed, 52 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 5/6 v5] CPU probe/release files
From: Andreas Schwab @ 2009-12-18 14:33 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AE8B072.1070603@austin.ibm.com>
Nathan Fontenot <nfont@austin.ibm.com> writes:
> Index: powerpc/arch/powerpc/Kconfig
> ===================================================================
> --- powerpc.orig/arch/powerpc/Kconfig 2009-10-28 15:21:47.000000000 -0500
> +++ powerpc/arch/powerpc/Kconfig 2009-10-28 15:21:53.000000000 -0500
> @@ -320,6 +320,10 @@
>
> Say N if you are unsure.
>
> +config ARCH_CPU_PROBE_RELEASE
> + def_bool y
> + depends on HOTPLUG_CPU
> +
That does not work.
drivers/built-in.o: In function `.store_online':
cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
make: *** [.tmp_vmlinux1] Error 1
cpu_hotplug_driver_lock is only defined on pseries, but HOTPLUG_CPU is
also defined on pmac.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Masami Hiramatsu @ 2009-12-18 14:35 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <4B2B0EBF.5040302@linux.vnet.ibm.com>
Mahesh Jagannath Salgaonkar wrote:
> Michael Neuling wrote:
>> In message <4B29EE5F.9020801@linux.vnet.ibm.com> you wrote:
>>> Hi Michael,
>>>
>>> Michael Neuling wrote:
>>>>> + * regs_get_argument_nth() - get Nth argument at function call
>>>>> + * @regs: pt_regs which contains registers at function entry.
>>>>> + * @n: argument number.
>>>>> + *
>>>>> + * regs_get_argument_nth() returns @n th argument of a function call.
>>>>> + * Since usually the kernel stack will be changed right after
>>>>> function en
>> try
>>>> ,
>>>>> + * you must use this at function entry. If the @n th entry is NOT
>>>>> in the
>>>>> + * kernel stack or pt_regs, this returns 0.
>>>>> + */
>>>>> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned
>>>>> int n)
>>>>> +{
>>>>> + if (n < ARRAY_SIZE(arg_offs_table))
>>>>> + return *(unsigned long *)((char *)regs + arg_offs_table[n]);
>>>>> + else {
>>>>> + /*
>>>>> + * If more arguments are passed that can be stored in
>>>>> + * registers, the remaining arguments are stored in the
>>>>> + * parameter save area located at fixed offset from stack
>>>>> + * pointer.
>>>>> + * Following the PowerPC ABI, the first few arguments are
>>>>> + * actually passed in registers (r3-r10), with equivalent
>>>>> space
>>>>> + * left unused in the parameter save area.
>>>>> + */
>>>>> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
>>>>> + return regs_get_kernel_stack_nth(regs, n);
>>>> How do we handle FP args?
>>> Currently this patch does not support FP args.
>>
>> This might be OK. I don't think we use floating point parameters in any
>> function definitions in the kernel.
>> We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
>> they are static inline, so they probably don't even end up as
>> functions.
>> I guess we need to make sure that we're not limiting the interface in
>> such a way that we can't support it later if the above changes.
>> regs_get_argument_nth returns an unsigned long which makes returning a
>> 128 bit VMX register impossible. This might be a show stopper for me.
>> How are the x86 guys dealing with this?
>>
> Nope, x86 does not deal with bigger registers (Masami, correct me if I
> am wrong). The return data type is opaque to user. Hence this enables us
> to handle any such situations in future without effecting user space API.
Right, we don't use those bigger registers in the kernel context.
(some special functions use it inside, but most of codes
are just using general regs)
And regs_get_argument_nth is just an accessor of pt_regs field.
This means that it just provides field in pt_regs.
>>>>> + }
>>>>> +}
>>>>> +/*
>>>>> * does not yet catch signals sent when the child dies.
>>>>> * in exit.c or in signal.c.
>>>>> */
>>>>> Index: linux-2.6-tip/kernel/trace/Kconfig
>>>>> ===================================================================
>>>>> --- linux-2.6-tip.orig/kernel/trace/Kconfig
>>>>> +++ linux-2.6-tip/kernel/trace/Kconfig
>>>>> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
>>>>>
>>>>> config KPROBE_EVENT
>>>>> depends on KPROBES
>>>>> - depends on X86
>>>>> + depends on X86 || PPC
>>>>> bool "Enable kprobes-based dynamic events"
>>>>> select TRACING
>>>>> default y
>>>>>
>>>>> _______________________________________________
>>>>> Linuxppc-dev mailing list
>>>>> Linuxppc-dev@lists.ozlabs.org
>>>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>>>>
>>> Thanks for reviewing.
>>
>> We are creating a new user space API here, so I'm keen for others to take
>> a good look at the interface before we commit to something we are going
>> to have to keep forever.
>> Who is the main consumer of this (/me is pretty ignorant of kprobes)?
>> What do they think of the interface?
>>
> The user space API are already present in the upstream kernel and
> currently only supported architecture is x86. This patch provides ppc
> architecture specific interfaces that enables powerpc also in par with x86.
Yes, there is a kprobe tracer in ftrace (see Documentation/trace/kprobetrace.txt).
and this tracer is only for probing kernel (not userspace).
>
> The main consumer would be kernel developers who would like to see
> register values, arguments and stack when the probe hits at given text
> address.
Right.
BTW, there is a user-space tools we have (tools/perf/builtin-probe.c).
Currently, it's only for x86. Mahesh, You just need to add a register
translation table in tools/perf/util/probe-finder.c for ppc support.
Thank you!
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
^ permalink raw reply
* RE: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Li Yang-R58472 @ 2009-12-18 14:46 UTC (permalink / raw)
To: Ira W. Snyder, Dan Williams
Cc: herbert, Suresh Vishnu-B05022, Tabi Timur-B04825, linux-kernel,
linux-raid, linuxppc-dev, linux-crypto, Gupta Maneesh-B18878,
Dudhat Dipen-B09055
In-Reply-To: <20091217170958.GE18271@ovro.caltech.edu>
>Subject: Re: [PATCH v2 2/2] Crypto: Talitos: Support for=20
>Async_tx XOR offload
>
>On Wed, Dec 16, 2009 at 03:47:48PM -0700, Dan Williams wrote:
>> Kumar Gala wrote:
>> >>> Changes with respect to v1 as per comments received o.=20
>Rebased to=20
>> >>> linux-next as of 20091216 o. The selection is based exclusive of=20
>> >>> fsldma o. Intoduced a new Kernel Configuration variable
>> >>> *. This enables selecting the Cryptographic functionality
>> >>> of Talitos along with fsldma.
>> >>> *. Disables the XOR parity calculation offload, if=20
>fsldma enabled
>> >>> either as kernel in-built or as a module
>> >>> *. Once the inter-operability with fsldma is resolved,=20
>this option
>> >>> can be removed
>> >> wait, why can't the interoperability bug be fixed in the=20
>first place?
>> >=20
>> > I agree w/Kim. We need to better understand what the bug=20
>is and how to reproduce it so we can get to the root cause.
>> >=20
>> > Paper taping over it by disabling fsldma is not the right solution.
>>=20
>> Hopefully this prompts fsldma authors to get involved because the=20
>> interoperability issue has been out there without comment*, just=20
>> band-aids, since October.
>>=20
>> --
>> Dan
>>=20
>> * well one comment from Ira saying the interrupt=20
>functionality worked=20
>> for him.
>
>Yes, I have used the device_prep_dma_interrupt() functionality=20
>quite a while back. However, I found it to be pretty much=20
>useless. Any functionality I need is covered by adding a=20
>callback to the last DMA
>memcpy() operation. Since the operations happen in-order, I=20
>can be sure that the entire set of memcpy()s cas completed. I=20
>never needed the capability to generate an interrupt without a=20
>memcpy().
>
>I agree that the fsldma driver could use some love. There are=20
>places where I am still not confident in the locking. Perhaps=20
>I can find some time over Christmas to work on it, but I need=20
>someone with 85xx/86xx hardware to test the changes. I only=20
>have 83xx hardware.
I can also help with the 85xx testing when I finish the busy project
soon.
- Leo
^ permalink raw reply
* RE: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Li Yang-R58472 @ 2009-12-18 15:02 UTC (permalink / raw)
To: Dan Williams, Ira W. Snyder
Cc: herbert, Suresh Vishnu-B05022, Tabi Timur-B04825, linux-kernel,
linux-raid, linuxppc-dev, linux-crypto, Gupta Maneesh-B18878,
Dudhat Dipen-B09055
In-Reply-To: <4B2A6DFA.6000504@intel.com>
>Subject: Re: [PATCH v2 2/2] Crypto: Talitos: Support for=20
>Async_tx XOR offload
>
>Ira W. Snyder wrote:
>> Yes, I have used the device_prep_dma_interrupt()=20
>functionality quite a=20
>> while back. However, I found it to be pretty much useless.
>
>The specific case it is needed for Talitos/raid is a channel=20
>switch interrupt. The interrupt causes the cleanup operation=20
>to be run which will kick off any pending dependent operations=20
>on the xor channel. In the raid case we only have callbacks=20
>at the end of a chain, so we need the interrupt to kick the=20
>engine in an operation chain like=20
>xor->copy->xor->callback.
I am wondering if can use more callbacks to kick off pending dependent =
operations?
Like xor->callback->copy->callback->xor->callback?
- Leo
^ permalink raw reply
* Re: [PATCH 5/6 v5] CPU probe/release files
From: Nathan Fontenot @ 2009-12-18 16:24 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <m2oclw9wt4.fsf@igel.home>
Andreas Schwab wrote:
> Nathan Fontenot <nfont@austin.ibm.com> writes:
>
>> Index: powerpc/arch/powerpc/Kconfig
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/Kconfig 2009-10-28 15:21:47.000000000 -0500
>> +++ powerpc/arch/powerpc/Kconfig 2009-10-28 15:21:53.000000000 -0500
>> @@ -320,6 +320,10 @@
>>
>> Say N if you are unsure.
>>
>> +config ARCH_CPU_PROBE_RELEASE
>> + def_bool y
>> + depends on HOTPLUG_CPU
>> +
>
> That does not work.
>
> drivers/built-in.o: In function `.store_online':
> cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
> cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
> make: *** [.tmp_vmlinux1] Error 1
>
> cpu_hotplug_driver_lock is only defined on pseries, but HOTPLUG_CPU is
> also defined on pmac.
These two routines should be defined as a no-op if CONFIG_ARCH_CPU_PROBE_RELEASE
is not defined in linux/cpu.h. The update below should be in the patch set
you are looking at.
from linux/cpu.h:
#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
extern void cpu_hotplug_driver_lock(void);
extern void cpu_hotplug_driver_unlock(void);
#else
static inline void cpu_hotplug_driver_lock(void)
{
}
static inline void cpu_hotplug_driver_unlock(void)
{
}
#endif
-Nathan Fontenot
^ permalink raw reply
* Re: [PATCH] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
From: Randy Dunlap @ 2009-12-18 16:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Geert Uytterhoeven, linuxppc-dev, linux-wireless
In-Reply-To: <1261115574.2173.18.camel@pasglop>
On Fri, 18 Dec 2009 16:52:54 +1100 Benjamin Herrenschmidt wrote:
> The option to support the old style PSK interface in the PS3
> GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Please send to Linus asap (or I can put it in powerpc.git) as it's
> breaking one of my test build configs :-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index e58a653..c0ecc77 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2358,6 +2358,7 @@ config GELIC_WIRELESS
> config GELIC_WIRELESS_OLD_PSK_INTERFACE
> bool "PS3 Wireless private PSK interface (OBSOLETE)"
> depends on GELIC_WIRELESS
> + select WEXT_PRIV
> help
> This option retains the obsolete private interface to pass
> the PSK from user space programs to the driver. The PSK
Probably also needs
depends on WLAN
to prevent build failures.
---
~Randy
^ permalink raw reply
* Re: [PATCH 5/6 v5] CPU probe/release files
From: Andreas Schwab @ 2009-12-18 17:29 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4B2BACD3.7010903@austin.ibm.com>
Nathan Fontenot <nfont@austin.ibm.com> writes:
> Andreas Schwab wrote:
>> Nathan Fontenot <nfont@austin.ibm.com> writes:
>>
>>> Index: powerpc/arch/powerpc/Kconfig
>>> ===================================================================
>>> --- powerpc.orig/arch/powerpc/Kconfig 2009-10-28 15:21:47.000000000 -0500
>>> +++ powerpc/arch/powerpc/Kconfig 2009-10-28 15:21:53.000000000 -0500
>>> @@ -320,6 +320,10 @@
>>> Say N if you are unsure.
>>> +config ARCH_CPU_PROBE_RELEASE
>>> + def_bool y
>>> + depends on HOTPLUG_CPU
>>> +
>>
>> That does not work.
>>
>> drivers/built-in.o: In function `.store_online':
>> cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
>> cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> cpu_hotplug_driver_lock is only defined on pseries, but HOTPLUG_CPU is
>> also defined on pmac.
>
> These two routines should be defined as a no-op if CONFIG_ARCH_CPU_PROBE_RELEASE
> is not defined in linux/cpu.h.
??? CONFIG_ARCH_CPU_PROBE_RELEASE *is* defined.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH v2] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
From: Geoff Levand @ 2009-12-18 18:24 UTC (permalink / raw)
To: Randy Dunlap
Cc: Geert Uytterhoeven, linux-wireless@vger.kernel.org, linuxppc-dev,
Hamish Guthrie
In-Reply-To: <20091218085547.fb8bdaf5.randy.dunlap@oracle.com>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The option to support the old style PSK interface in the PS3
GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
v2: Added 'depends on WLAN'.
Please send to Linus asap (or I can put it in powerpc.git) as it's
breaking one of my test build configs :-)
Just as a note, I asked Hamish to work to remove this option.
No distros use it anymore, so we don't need it.
-Geoff
---
drivers/net/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2357,7 +2357,9 @@ config GELIC_WIRELESS
config GELIC_WIRELESS_OLD_PSK_INTERFACE
bool "PS3 Wireless private PSK interface (OBSOLETE)"
+ depends on WLAN
depends on GELIC_WIRELESS
+ select WEXT_PRIV
help
This option retains the obsolete private interface to pass
the PSK from user space programs to the driver. The PSK
^ permalink raw reply
* Re: [PATCH v2] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
From: Geoff Levand @ 2009-12-18 19:01 UTC (permalink / raw)
To: Johannes Berg
Cc: Randy Dunlap, linux-wireless@vger.kernel.org, Geert Uytterhoeven,
linuxppc-dev, Hamish Guthrie
In-Reply-To: <1261161036.14206.3.camel@johannes.local>
On 12/18/2009 10:30 AM, Johannes Berg wrote:
> On Fri, 2009-12-18 at 10:24 -0800, Geoff Levand wrote:
>> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>
>> The option to support the old style PSK interface in the PS3
>> GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
>>
>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>> ---
>> v2: Added 'depends on WLAN'.
>
> Won't you want 'depends on WLAN' for GELIC_WIRELESS instead of here?
Yes, that seems correct. I'll post an update v3.
-Geoff
^ permalink raw reply
* Re: [PATCH v2] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
From: Johannes Berg @ 2009-12-18 18:30 UTC (permalink / raw)
To: Geoff Levand
Cc: Randy Dunlap, linux-wireless@vger.kernel.org, Geert Uytterhoeven,
linuxppc-dev, Hamish Guthrie
In-Reply-To: <4B2BC8E6.9090007@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 501 bytes --]
On Fri, 2009-12-18 at 10:24 -0800, Geoff Levand wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> The option to support the old style PSK interface in the PS3
> GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> v2: Added 'depends on WLAN'.
Won't you want 'depends on WLAN' for GELIC_WIRELESS instead of here?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH v3] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
From: Geoff Levand @ 2009-12-18 19:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Geert Uytterhoeven, linuxppc-dev, linux-wireless@vger.kernel.org
In-Reply-To: <1261115574.2173.18.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The option to support the old style PSK interface in the PS3
GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
v2: Added 'depends on WLAN'.
v3: Moved 'depends on WLAN' to GELIC_WIRELESS.
Please send to Linus asap (or I can put it in powerpc.git) as it's
breaking one of my test build configs :-)
---
drivers/net/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2346,6 +2346,7 @@ config GELIC_NET
config GELIC_WIRELESS
bool "PS3 Wireless support"
+ depends on WLAN
depends on GELIC_NET
select WIRELESS_EXT
help
@@ -2358,6 +2359,7 @@ config GELIC_WIRELESS
config GELIC_WIRELESS_OLD_PSK_INTERFACE
bool "PS3 Wireless private PSK interface (OBSOLETE)"
depends on GELIC_WIRELESS
+ select WEXT_PRIV
help
This option retains the obsolete private interface to pass
the PSK from user space programs to the driver. The PSK
^ permalink raw reply
* [PATCH v2.6.33] powerpc: flipper-pic/hlwd-pic: remove get_irq_desc()
From: Albert Herranz @ 2009-12-18 20:04 UTC (permalink / raw)
To: linuxppc-dev, glikely; +Cc: Albert Herranz
Fix the following build failures:
arch/powerpc/platforms/embedded6xx/flipper-pic.c: In function 'flipper_pic_map':
arch/powerpc/platforms/embedded6xx/flipper-pic.c:105: error: implicit declaration of function 'get_irq_desc'
arch/powerpc/platforms/embedded6xx/hlwd-pic.c: In function 'hlwd_pic_map':
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:98: error: implicit declaration of function 'get_irq_desc'
These failures are caused by the changes introduced in commit
"powerpc: Remove get_irq_desc()". The reason these drivers were not
updated is that they weren't merged yet.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
---
arch/powerpc/platforms/embedded6xx/flipper-pic.c | 2 +-
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/flipper-pic.c b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
index d596328..c278bd3 100644
--- a/arch/powerpc/platforms/embedded6xx/flipper-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
@@ -102,7 +102,7 @@ static int flipper_pic_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hwirq)
{
set_irq_chip_data(virq, h->host_data);
- get_irq_desc(virq)->status |= IRQ_LEVEL;
+ irq_to_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_and_handler(virq, &flipper_pic, handle_level_irq);
return 0;
}
diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
index dd20bff..fe0ff06 100644
--- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
@@ -95,7 +95,7 @@ static int hlwd_pic_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hwirq)
{
set_irq_chip_data(virq, h->host_data);
- get_irq_desc(virq)->status |= IRQ_LEVEL;
+ irq_to_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_and_handler(virq, &hlwd_pic, handle_level_irq);
return 0;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2.6.33] powerpc: hlwd-pic: convert irq_desc.lock to raw_spinlock
From: Albert Herranz @ 2009-12-18 20:04 UTC (permalink / raw)
To: linuxppc-dev, glikely; +Cc: Albert Herranz
Fix the following build failures:
arch/powerpc/platforms/embedded6xx/hlwd-pic.c: In function 'hlwd_pic_irq_cascade':
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:135: error: passing argument 1 of 'spin_lock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:137: error: passing argument 1 of 'spin_unlock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:145: error: passing argument 1 of 'spin_lock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:149: error: passing argument 1 of 'spin_unlock' from incompatible pointer type
These failures are caused by the changes introduced in commit
"genirq: Convert irq_desc.lock to raw_spinlock". The reason this driver
was not updated is that it wasn't merged yet.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
---
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
index fe0ff06..a771f91 100644
--- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
@@ -132,9 +132,9 @@ static void hlwd_pic_irq_cascade(unsigned int cascade_virq,
struct irq_host *irq_host = get_irq_data(cascade_virq);
unsigned int virq;
- spin_lock(&desc->lock);
+ raw_spin_lock(&desc->lock);
desc->chip->mask(cascade_virq); /* IRQ_LEVEL */
- spin_unlock(&desc->lock);
+ raw_spin_unlock(&desc->lock);
virq = __hlwd_pic_get_irq(irq_host);
if (virq != NO_IRQ)
@@ -142,11 +142,11 @@ static void hlwd_pic_irq_cascade(unsigned int cascade_virq,
else
pr_err("spurious interrupt!\n");
- spin_lock(&desc->lock);
+ raw_spin_lock(&desc->lock);
desc->chip->ack(cascade_virq); /* IRQ_LEVEL */
if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
desc->chip->unmask(cascade_virq);
- spin_unlock(&desc->lock);
+ raw_spin_unlock(&desc->lock);
}
/*
--
1.6.3.3
^ permalink raw reply related
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