Chen Gang writes:
> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have
> already implemented it (e.g. alpha, arc, arm, avr32, blackf
Thanks anton.
> -Original Message-
> From: Anton Vorontsov [mailto:an...@scarybugs.org] On Behalf Of Anton
> Vorontsov
> Sent: Friday, May 24, 2013 1:34 AM
> To: Wang Dongsheng-B40534
> Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org;
> johan...@sipsolutions.net; Wood Scott-B0
On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> wrote:
On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>
OK, here is clearer stack output from the run.
CAI Qian
+ ./check
FSTYP -- xfs (non-debug)
PLATFORM -- Linux/s390x ibm-z10-23 3.9.3
001 29s
002 3s
003 2s
004 [not run] this test requires a valid $SCRATCH_DEV
005 2s
006 9s
007 10s
008 7s
009
On 05/24/2013 12:56 AM, Alex Williamson wrote:
> On Tue, 2013-05-21 at 13:33 +1000, Alexey Kardashevskiy wrote:
>> The series adds support for VFIO on POWERPC in user space (such as QEMU).
>> The in-kernel real mode IOMMU support is added by another series posted
>> separately.
>>
>> As the first a
On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
> wrote:
>> > On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>> >> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>> > This is the problem you guys are miss
This adds the remaining two hypercalls defined by PAPR for manipulating
the XICS interrupt controller, H_IPOLL and H_XIRR_X. H_IPOLL returns
information about the priority and pending interrupts for a virtual
cpu, without changing any state. H_XIRR_X is like H_XIRR in that it
reads and acknowledg
On 05/23/2013 08:40 PM, Jason Cooper wrote:
On Thu, May 23, 2013 at 11:53:57AM -0600, Jason Gunthorpe wrote:
On Thu, May 23, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
Shouldn't it rather be
compatible = "marvell,kirkwood-eth", "marvell,orion-eth";
Not sure about orion-eth?
Jaso
Hi!
On Tue, May 14, 2013 at 08:59:13AM +, Wang Dongsheng-B40534 wrote:
> I send to a wrong email address "Anton Vorontsov "
>
> Add Anton Vorontsov to this email.
I don't have any means to test it, but the patch itself looks good and the
description makes sense. So,
Reviewed-by: Anton Voro
On Thu, May 23, 2013 at 02:40:28PM -0400, Jason Cooper wrote:
> > But there is a larger problem here then just this one bit.
> >
> > The PSC1 register must be set properly for the board layout, and today
> > we rely on the bootloader to set it. In fact, even with Sebastian's
> > change the ethern
On Thu, May 23, 2013 at 11:53:57AM -0600, Jason Gunthorpe wrote:
> On Thu, May 23, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
>
> > Shouldn't it rather be
> >
> > compatible = "marvell,kirkwood-eth", "marvell,orion-eth";
>
> Not sure about orion-eth?
>
> > I'm inclined to go with of_mac
On Thu, May 23, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> Shouldn't it rather be
>
> compatible = "marvell,kirkwood-eth", "marvell,orion-eth";
Not sure about orion-eth?
> I'm inclined to go with of_machine_is_compatible() since the only
> concrete difference we know is that the twe
On Thu, May 23, 2013 at 11:11:12AM -0600, Jason Gunthorpe wrote:
> On Thu, May 23, 2013 at 12:01:11PM -0400, Jason Cooper wrote:
> > > > + /* Kirkwood resets some registers on gated clocks. Especially
> > > > +* CLK125_BYPASS_EN must be cleared but is not available on
> > > > +
On Thu, May 23, 2013 at 12:01:11PM -0400, Jason Cooper wrote:
> > > + /* Kirkwood resets some registers on gated clocks. Especially
> > > + * CLK125_BYPASS_EN must be cleared but is not available on
> > > + * all other SoCs/System Controllers using this driver.
> > > + */
> > > + if (of_machine_
Sebastian,
On Wed, May 22, 2013 at 02:16:07PM -0600, Jason Gunthorpe wrote:
> On Wed, May 22, 2013 at 10:04:02PM +0200, Sebastian Hesselbarth wrote:
>
> > Ethernet controllers found on Kirkwood SoCs not only suffer from loosing
> > MAC address register contents on clock gating but also some impor
Shaohui --
Apologies, a minor clarification is needed:
Anthony Foiani writes:
> Shaohui --
>
> Xie Shaohui-B21989 writes:
>
>> If stop NOR write, could the SATA recover and work?
>
> Earlier in my development, I was seeing this error and it would
> recover:
>
> ata2: exception Emask 0x10 SAc
Shaohui --
Xie Shaohui-B21989 writes:
> Thanks for the confirmation.
You're very welcome.
> So it seems the NOR write break the signal Integrity of SATA.
> I don't have schematic and board right now, could you please measure
> signals related to NOR write to see if anything abnormal? Is the b
On Tue, 2013-05-21 at 13:33 +1000, Alexey Kardashevskiy wrote:
> The series adds support for VFIO on POWERPC in user space (such as QEMU).
> The in-kernel real mode IOMMU support is added by another series posted
> separately.
>
> As the first and main aim of this series is the POWERNV platform su
On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
wrote:
> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>> > This is the problem you guys are missing - unreachable() means "we lose
>> > control of the CPU at this
On Wed, May 22, 2013 at 8:22 AM, Anshuman Khandual
wrote:
> Adding documentation support for conditional branch filter.
>
Reviewed-by: Stephane Eranian
> Signed-off-by: Anshuman Khandual
> ---
> tools/perf/Documentation/perf-record.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
On Wed, May 22, 2013 at 8:22 AM, Anshuman Khandual
wrote:
> From: Peter Zijlstra
>
> This patch adds conditional branch filtering support,
> enabling it for PERF_SAMPLE_BRANCH_COND in perf branch
> stack sampling framework by utilizing an available
> software filter X86_BR_JCC.
>
Reviewed-by: Ste
On Wed, May 22, 2013 at 8:22 AM, Anshuman Khandual
wrote:
> POWER8 PMU based BHRB supports filtering for conditional branches.
> This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which
> will extend the existing perf ABI. Other architectures can provide
> this functionality with eith
On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > This is the problem you guys are missing - unreachable() means "we lose
> > control of the CPU at this point".
>
> I'm absolutely aware of this. Again, the current behaviou
On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> This is the problem you guys are missing - unreachable() means "we lose
> control of the CPU at this point".
I'm absolutely aware of this. Again, the current behaviour of doing nothing
at all isn't very different from undefined behavior wh
On Thu, May 23, 2013 at 12:59:43PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> >
> > Warning: if CONFIG_BUG is turned off, and cont
On 05/23/2013 06:59 PM, Arnd Bergmann wrote:
> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing t
David Laight wrote:
strcpy(ssi_private->name, p) in probe() sets "name" by "p", gotten from dts,
>while the length of "p", if the devicetree node name of SSI is commonly set,
>would always be larger than 1 char size, so need a larger size for "name".
Are you sure this isn't allowed for when the
Arnd Bergmann writes:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
>> > The problem is: trying to fix that will mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats th
On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
On 05/23/2013 06:04 PM, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
>
On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann writes:
>
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of plac
> strcpy(ssi_private->name, p) in probe() sets "name" by "p", gotten from dts,
> while the length of "p", if the devicetree node name of SSI is commonly set,
> would always be larger than 1 char size, so need a larger size for "name".
Are you sure this isn't allowed for when the structure is alloc
On Thu, May 23, 2013 at 11:39:37AM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > > The problem is: trying to fix that will mean the result is a larger
> > > kernel than if you just do the usual arch-implemented thing of placing
> > > an defined faulting instru
On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
> wrote:
>> > On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>>> >> On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
>> > -config BUG
>> > - bool "B
On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > The problem is: trying to fix that will mean the result is a larger
> > kernel than if you just do the usual arch-implemented thing of placing
> > an defined faulting instruction at the BUG() site - which defeats the
> > purpose of turning off
On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
wrote:
> On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
>> > -config BUG
>> > - bool "BUG() support" if EXPERT
>> > - default y
>> > - help
>> > -
On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
> > -config BUG
> > - bool "BUG() support" if EXPERT
> > - default y
> > - help
> > - Disabling this option eliminates support for BUG and WARN,
> > r
On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > -config BUG
> > - bool "BUG() support" if EXPERT
> > - default y
> > - help
> > - Disabling this option eliminates support for BUG and WARN,
> > reducing
> > - the size of your kernel image and potentially q
strcpy(ssi_private->name, p) in probe() sets "name" by "p", gotten from dts,
while the length of "p", if the devicetree node name of SSI is commonly set,
would always be larger than 1 char size, so need a larger size for "name".
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_ssi.c |2 +-
On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have
Sorry, but we don't. I think
The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".
But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, m
41 matches
Mail list logo
