Re: [linux-yocto] [linux-yocto v5.0/standard/base][PATCH] ALSA: hda: check RIRB to avoid use NULL pointer

2019-04-29 Thread Liwei Song 



On 04/30/2019 03:38 AM, Bruce Ashfield wrote:
> On Sun, Apr 28, 2019 at 4:42 AM Liwei Song  wrote:
> 
>> Fix the following BUG:
>>
>>
> Is this also a bug in the mainline kernel ? If so, what's the resolution
> for the issue there ?

Yes, it is also exist in mainline kernel, I will send the same patch to there.

Thanks,
Liwei.


> 
> Bruce
> 
> 
> 
>> BUG: unable to handle kernel NULL pointer dereference at 000c
>> Workqueue: events azx_probe_work [snd_hda_intel]
>> RIP: 0010:snd_hdac_bus_update_rirb+0x80/0x160 [snd_hda_core]
>> Call Trace:
>>  
>>  azx_interrupt+0x78/0x140 [snd_hda_codec]
>>  __handle_irq_event_percpu+0x49/0x300
>>  handle_irq_event_percpu+0x23/0x60
>>  handle_irq_event+0x3c/0x60
>>  handle_edge_irq+0xdb/0x180
>>  handle_irq+0x23/0x30
>>  do_IRQ+0x6a/0x140
>>  common_interrupt+0xf/0xf
>>
>> The Call Trace happened when run kdump on a NFS rootfs system.
>> Exist the following calling sequence when boot the second kernel:
>>
>> azx_first_init()
>>--> azx_acquire_irq()
>>   <-- interrupt come in, azx_interrupt() was called
>>--> hda_intel_init_chip()
>>   --> azx_init_chip()
>>  --> snd_hdac_bus_init_chip()
>>   --> snd_hdac_bus_init_cmd_io();
>> --> init rirb.buf and corb.buf
>>
>> Interrupt happened after azx_acquire_irq() while RIRB still didn't got
>> initialized, then NULL pointer will be used when process the interrupt.
>>
>> Considering adjust the calling sequence may import new issue like
>> 2eeeb4f4733b ("ASoC: Intel: Skylake: Acquire irq after RIRB allocation")
>> so here simply check the value of RIRB to avoid using NULL pointer.
>>
>> Fixes: 14752412721c ("ALSA: hda - Add the controller helper codes to
>> hda-core module")
>> Signed-off-by: Liwei Song 
>> ---
>>  sound/hda/hdac_controller.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c
>> index 74244d8e2909..2f0fa5353361 100644
>> --- a/sound/hda/hdac_controller.c
>> +++ b/sound/hda/hdac_controller.c
>> @@ -195,6 +195,9 @@ void snd_hdac_bus_update_rirb(struct hdac_bus *bus)
>> return;
>> bus->rirb.wp = wp;
>>
>> +   if (!bus->rirb.buf)
>> +   return;
>> +
>> while (bus->rirb.rp != wp) {
>> bus->rirb.rp++;
>> bus->rirb.rp %= AZX_MAX_RIRB_ENTRIES;
>> --
>> 2.7.4
>>
>>
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] tracing/x86: Save CR2 before tracing irqsoff on error_entry

2019-04-29 Thread He Zhe 


On 4/30/19 3:37 AM, Bruce Ashfield wrote:
>
>
> On Mon, Apr 29, 2019 at 8:34 AM Bruce Ashfield  > wrote:
>
>
>
> On Sun, Apr 28, 2019 at 6:50 AM He Zhe  > wrote:
>
>
>
> On 4/26/19 11:14 PM, Bruce Ashfield wrote:
> >
> >
> > On Wed, Apr 24, 2019 at 9:38 PM He Zhe    >> wrote:
> >
> >
> >
> >     On 4/24/19 8:34 PM, Bruce Ashfield wrote:
> >     >
> >     >
> >     > On Wed, Apr 24, 2019 at 3:47 AM He Zhe    >     >     >
> >     >     This is for standard/base and all sub-level branches. For 
> explanation, see the
> >     >     bottom of the commit log I append.
> >     >
> >     >
> >     > Which kernel versions ? I didn't notice a version it the 
> shortlog or temporary section, but I may have overlooked it.
> >
> >     >From 4.19 to 5.0
> >
> >
> > Thanks, this is now merged.
>
> This is missing on v5.0/standard/intel-x86.
>
>
> Not in my tree, but I'll double check as I'm merging more changes later 
> today.
>
>
> I confirmed that this really is in the branches that I pushed, are you really 
> not seeing commit b470fb994ebd5b9ae8e520c85029449bf847289c in that branch ?

Oops, I see it now after re-sync, there must be something wrong in the sync 
process back then. Thanks.

Zhe

>
> https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.0/standard/intel-x86=b470fb994ebd5b9ae8e520c85029449bf847289c
>  
>
> Bruce 
>
>  
>
>
> Bruce
>
>  
>
> Zhe
>
> >
> > Bruce
> >
> >  
> >
> >     Zhe
> >
> >     >
> >     > Bruce
> >     >
> >     >  
> >     >
> >     >
> >     >     Zhe
> >     >
> >     >     On 4/24/19 3:42 PM, zhe...@windriver.com 
>   >    >> wrote:
> >     >     > From: "Steven Rostedt (VMware)"    >     >     >     >
> >     >     > He Zhe reported a crash by enabling trace events and 
> selecting
> >     >     > "userstacktrace" which will read the stack of userspace 
> for every trace
> >     >     > event recorded. Zhe narrowed it down to:
> >     >     >
> >     >     >  c3bc8fd637a9 ("tracing: Centralize preemptirq 
> tracepoints and unify their usage")
> >     >     >
> >     >     > With the problem config, I was able to also reproduce 
> the error. I
> >     >     > narrowed it down to just having to do the following:
> >     >     >
> >     >     >  # cd /sys/kernel/tracing
> >     >     >  # echo 1 > options/userstacktrace
> >     >     >  # echo 1 > events/preemptirq/irq_disable/enable
> >     >     >
> >     >     > And sure enough, I triggered a crash. Well, it was 
> systemd crashing
> >     >     > with a bad memory access??
> >     >     >
> >     >     >  systemd-journal[537]: segfault at ed8cb8 ip 
> 7f7fffc9fef5 sp 7ffc4062cb10 error 7
> >     >     >
> >     >     > And it would crash similarly each time I tried it, but 
> always at a
> >     >     > different place. After spending the day on this, I 
> finally figured it
> >     >     > out. The bug is happening in entry_64.S right after 
> error_entry.
> >     >     > There's two TRACE_IRQS_OFF in that code path, which if 
> I comment out,
> >     >     > the bug goes away. Then it dawned on me that the crash 
> always happens
> >     >     > when systemd does a normal page fault. We had this bug 
> before, and it
> >     >     > was with the exception trace points.
> >     >     >
> >     >     > The issue is that a tracepoint can fault (reading 
> vmalloc or whatever).
> >     >     > And doing a userspace stack trace most definitely will 
> fault. But if we
> >     >     > are coming from a legitimate page fault, the address of 
> that fault (in
> >     >     > the CR2 register) will be lost if we fault before we 
> get to the page
> > 

[yocto] Tomorrow - Live Coding with Yocto Project

2019-04-29 Thread Volosincu, Andreea S 
Happening tomorrow @5 PM CET - Join us for a download to first build live 
tutorial.

When: April 30, 2019, 5:00 PM CET
Where: Yocto Project Twitch channel - https://www.twitch.tv/yocto_project

Add it to your calendar -  
https://calendar.google.com/calendar/ical/d7umm3pdhorsnnjbe1cvbgfhlk%40group.calendar.google.com/public/basic.ics

See you soon!
Yocto Project Advocacy Team
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Disabling sshd is harder than it should be

2019-04-29 Thread Loïc Domaigné 
Guten Abend Richard, 

> > When selecting systemd as the init manager, the following line is
> > recommended.
> > DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> > Then you should only need: SYSTEMD_AUTO_ENABLE = "disable"
> 
> Thanks a lot for your suggestion!
> But doesn't this line imply that recipes which don't supply systemd servies
> files won't work since the init.d scipt fallback will be disabled?

As per Mega-manual (section "using systemd Exclusively"):
# switch to systemd init
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd" 

# The next 2 lines:
# -prevent sysvinit of being automatically added to the image 
(BACKFILL_CONSIDERED), 
# -remove the initscripts from the image (VIRTUAL-RUNTIME_initscripts) 
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""

Now "pokying around" further in meta/ and meta-poky/, it turns out that that 
later variable might be what you're looking for. 

As far as I can see, it can be set to:
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_initscripts = "initscripts"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

Also using "+=" operator for BACKFILL_CONSIDERED as suggested by Qi sounds more 
generic to me than using a plain assignment.

Speaking of which... Additional findings 
(meta/conf/distro/include/maintainers.inc) let me also think that Qi is simply 
just the right address for these kind of questions ;-) 

Ah, and yes. If you are moving from sysvinit -> systemd for an existing 
project, you might need a clean build as DISTRO_FEATURES is changed.

Hope this helps!
Loic.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] do_rootfs fails - corner case QA/heuristics?

2019-04-29 Thread Felix Lelchuk 

Hi,

I'm facing some strange problems trying to backport old 1.9 Ruby to Thud Poky.
All packages build fine but the image's do_rootfs fails with below message and
without any image winding up in tmp/deploy/images/:

-
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: my-image-1.0-r0 do_rootfs: [log_check] my-image: found 2 error messages 
in the logfile:
[log_check] D: create 040755  1 (   0,   0) 0 
/usr/share/ri/1.9.1/system/Net/HTTPExpectationFailed
[log_check] D: create 040755  1 (   0,   0) 0 
/usr/share/ri/1.9.1/system/Net/HTTPPreconditionFailed

ERROR: my-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/1.0-r0/temp/log.do_rootfs.19421
ERROR: Task (my-image.bb:do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 7927 tasks of which 7800 didn't need to be rerun 
and 1 failed.
-

I believe there are some QA-related heuristics in place which dislike the naming of the 
two mentioned files for they contain "Failed" in their filename. Unlike Thud, 
that used to work in Krogoth.

If this was a pure QA-warning I'd assume there is a switch to ignore it but it 
seems to be treated like an actual error.

I'd be glad to hear about the best way to proceed with this. Thank you!

Best Regards,

Felix Lelchuk

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH] tracing/x86: Fix compilation failure when CONFIG_TRACE_IRQFLAGS is off

2019-04-29 Thread Bruce Ashfield 
merged to all branches.

Bruce

On Sun, Apr 28, 2019 at 6:53 AM He Zhe  wrote:

> This is for all branches from 4.19 to 5.0.
>
> Zhe
>
> On 4/28/19 6:52 PM, zhe...@windriver.com wrote:
> > From: He Zhe 
> >
> > b470fb994ebd ("tracing/x86: Save CR2 before tracing irqsoff on
> error_entry")
> > misses a "#ifdef".
> >
> > Signed-off-by: He Zhe 
> > ---
> >  arch/x86/entry/common.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > index 48a0a59..56d54d30 100644
> > --- a/arch/x86/entry/common.c
> > +++ b/arch/x86/entry/common.c
> > @@ -308,6 +308,7 @@ __visible void do_syscall_64(unsigned long nr,
> struct pt_regs *regs)
> >   syscall_return_slowpath(regs);
> >  }
> >
> > +#ifdef CONFIG_TRACE_IRQFLAGS
> >  extern void trace_hardirqs_on_caller(unsigned long caller_addr);
> >  __visible void trace_hardirqs_on_caller_cr2(unsigned long caller_addr)
> >  {
> > @@ -334,6 +335,7 @@ __visible void
> trace_hardirqs_off_caller_cr2(unsigned long caller_addr)
> >   exception_exit(prev_state);
> >  }
> >  #endif
> > +#endif
> >
> >  #if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
> >  /*
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto v5.0/standard/base][PATCH] ALSA: hda: check RIRB to avoid use NULL pointer

2019-04-29 Thread Bruce Ashfield 
On Sun, Apr 28, 2019 at 4:42 AM Liwei Song  wrote:

> Fix the following BUG:
>
>
Is this also a bug in the mainline kernel ? If so, what's the resolution
for the issue there ?

Bruce



> BUG: unable to handle kernel NULL pointer dereference at 000c
> Workqueue: events azx_probe_work [snd_hda_intel]
> RIP: 0010:snd_hdac_bus_update_rirb+0x80/0x160 [snd_hda_core]
> Call Trace:
>  
>  azx_interrupt+0x78/0x140 [snd_hda_codec]
>  __handle_irq_event_percpu+0x49/0x300
>  handle_irq_event_percpu+0x23/0x60
>  handle_irq_event+0x3c/0x60
>  handle_edge_irq+0xdb/0x180
>  handle_irq+0x23/0x30
>  do_IRQ+0x6a/0x140
>  common_interrupt+0xf/0xf
>
> The Call Trace happened when run kdump on a NFS rootfs system.
> Exist the following calling sequence when boot the second kernel:
>
> azx_first_init()
>--> azx_acquire_irq()
>   <-- interrupt come in, azx_interrupt() was called
>--> hda_intel_init_chip()
>   --> azx_init_chip()
>  --> snd_hdac_bus_init_chip()
>   --> snd_hdac_bus_init_cmd_io();
> --> init rirb.buf and corb.buf
>
> Interrupt happened after azx_acquire_irq() while RIRB still didn't got
> initialized, then NULL pointer will be used when process the interrupt.
>
> Considering adjust the calling sequence may import new issue like
> 2eeeb4f4733b ("ASoC: Intel: Skylake: Acquire irq after RIRB allocation")
> so here simply check the value of RIRB to avoid using NULL pointer.
>
> Fixes: 14752412721c ("ALSA: hda - Add the controller helper codes to
> hda-core module")
> Signed-off-by: Liwei Song 
> ---
>  sound/hda/hdac_controller.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c
> index 74244d8e2909..2f0fa5353361 100644
> --- a/sound/hda/hdac_controller.c
> +++ b/sound/hda/hdac_controller.c
> @@ -195,6 +195,9 @@ void snd_hdac_bus_update_rirb(struct hdac_bus *bus)
> return;
> bus->rirb.wp = wp;
>
> +   if (!bus->rirb.buf)
> +   return;
> +
> while (bus->rirb.rp != wp) {
> bus->rirb.rp++;
> bus->rirb.rp %= AZX_MAX_RIRB_ENTRIES;
> --
> 2.7.4
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] tracing/x86: Save CR2 before tracing irqsoff on error_entry

2019-04-29 Thread Bruce Ashfield 
On Mon, Apr 29, 2019 at 8:34 AM Bruce Ashfield 
wrote:

>
>
> On Sun, Apr 28, 2019 at 6:50 AM He Zhe  wrote:
>
>>
>>
>> On 4/26/19 11:14 PM, Bruce Ashfield wrote:
>> >
>> >
>> > On Wed, Apr 24, 2019 at 9:38 PM He Zhe > zhe...@windriver.com>> wrote:
>> >
>> >
>> >
>> > On 4/24/19 8:34 PM, Bruce Ashfield wrote:
>> > >
>> > >
>> > > On Wed, Apr 24, 2019 at 3:47 AM He Zhe >   zhe...@windriver.com>>> wrote:
>> > >
>> > > This is for standard/base and all sub-level branches. For
>> explanation, see the
>> > > bottom of the commit log I append.
>> > >
>> > >
>> > > Which kernel versions ? I didn't notice a version it the shortlog
>> or temporary section, but I may have overlooked it.
>> >
>> > >From 4.19 to 5.0
>> >
>> >
>> > Thanks, this is now merged.
>>
>> This is missing on v5.0/standard/intel-x86.
>>
>>
> Not in my tree, but I'll double check as I'm merging more changes later
> today.
>

I confirmed that this really is in the branches that I pushed, are you
really not seeing commit b470fb994ebd5b9ae8e520c85029449bf847289c in that
branch ?

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.0/standard/intel-x86=b470fb994ebd5b9ae8e520c85029449bf847289c


Bruce



>
> Bruce
>
>
>
>> Zhe
>>
>> >
>> > Bruce
>> >
>> >
>> >
>> > Zhe
>> >
>> > >
>> > > Bruce
>> > >
>> > >
>> > >
>> > >
>> > > Zhe
>> > >
>> > > On 4/24/19 3:42 PM, zhe...@windriver.com > zhe...@windriver.com>  zhe...@windriver.com>> wrote:
>> > > > From: "Steven Rostedt (VMware)" >   rost...@goodmis.org>>>
>> > > >
>> > > > He Zhe reported a crash by enabling trace events and
>> selecting
>> > > > "userstacktrace" which will read the stack of userspace for
>> every trace
>> > > > event recorded. Zhe narrowed it down to:
>> > > >
>> > > >  c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints
>> and unify their usage")
>> > > >
>> > > > With the problem config, I was able to also reproduce the
>> error. I
>> > > > narrowed it down to just having to do the following:
>> > > >
>> > > >  # cd /sys/kernel/tracing
>> > > >  # echo 1 > options/userstacktrace
>> > > >  # echo 1 > events/preemptirq/irq_disable/enable
>> > > >
>> > > > And sure enough, I triggered a crash. Well, it was systemd
>> crashing
>> > > > with a bad memory access??
>> > > >
>> > > >  systemd-journal[537]: segfault at ed8cb8 ip
>> 7f7fffc9fef5 sp 7ffc4062cb10 error 7
>> > > >
>> > > > And it would crash similarly each time I tried it, but
>> always at a
>> > > > different place. After spending the day on this, I finally
>> figured it
>> > > > out. The bug is happening in entry_64.S right after
>> error_entry.
>> > > > There's two TRACE_IRQS_OFF in that code path, which if I
>> comment out,
>> > > > the bug goes away. Then it dawned on me that the crash
>> always happens
>> > > > when systemd does a normal page fault. We had this bug
>> before, and it
>> > > > was with the exception trace points.
>> > > >
>> > > > The issue is that a tracepoint can fault (reading vmalloc
>> or whatever).
>> > > > And doing a userspace stack trace most definitely will
>> fault. But if we
>> > > > are coming from a legitimate page fault, the address of
>> that fault (in
>> > > > the CR2 register) will be lost if we fault before we get to
>> the page
>> > > > fault handler. That's exactly what is happening.
>> > > >
>> > > > To solve this, a TRACE_IRQS_OFF_CR2 (and ON for
>> consistency) was added
>> > > > that saves the CR2 register. A new
>> trace_hardirqs_off_thunk_cr2 is
>> > > > created that stores the cr2 register, calls the
>> > > > trace_hardirqs_off_caller, then on return restores the cr2
>> register if
>> > > > it changed, before returning.
>> > > >
>> > > > On my tests this fixes the issue. I just want to know if
>> this is a
>> > > > legitimate fix or if someone can come up with a better fix?
>> > > >
>> > > > Note: this also saves the exception context just like the
>> > > > do_page_fault() function does.
>> > > >
>> > > > Note2: This only gets enabled when lockdep or irq tracing
>> is enabled,
>> > > > which is not recommended for production environments.
>> > > >
>> > > > Link:
>> http://lkml.kernel.org/r/897cf5cf-fc24-8a64-cb28-847f2d2e6...@windriver.com
>> > > >
>> > > > Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq
>> tracepoints and unify their usage")
>> > > > Signed-off-by: Steven Rostedt

Re: [yocto] Disabling sshd is harder than it should be

2019-04-29 Thread Richard Weinberger 
On Mon, Apr 29, 2019 at 9:23 AM ChenQi  wrote:
> When selecting systemd as the init manager, the following line is
> recommended.
> DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> Then you should only need: SYSTEMD_AUTO_ENABLE = "disable"

Thanks a lot for your suggestion!
But doesn't this line imply that recipes which don't supply systemd servies
files won't work since the init.d scipt fallback will be disabled?

-- 
Thanks,
//richard
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Replacing a configuration file from another recipe

2019-04-29 Thread Damien LEFEVRE 
Hi,

In our base image we use nginx. I created a nginx.bbappend to add our PHP
configuration in a separated layer.

For a specific variant of the image I need to add an extra bit of nginx
configuration.

I though I could create a new recipe to overwrite nginx.conf and include
that recipe in the variant image definition, but bitbake shouts at me that
I cannot modify a file from another recipe.

If that's the case, is it possible to create image name based bbappend
files? Or do I need to create a separate nginx overwrite layer with higher
priority than the base image nginx.bbappend for that image variant? (I
wouldn't like that)

Thanks,
-Damien
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH] tracing/x86: Save CR2 before tracing irqsoff on error_entry

2019-04-29 Thread Bruce Ashfield 
On Sun, Apr 28, 2019 at 6:50 AM He Zhe  wrote:

>
>
> On 4/26/19 11:14 PM, Bruce Ashfield wrote:
> >
> >
> > On Wed, Apr 24, 2019 at 9:38 PM He Zhe  zhe...@windriver.com>> wrote:
> >
> >
> >
> > On 4/24/19 8:34 PM, Bruce Ashfield wrote:
> > >
> > >
> > > On Wed, Apr 24, 2019 at 3:47 AM He Zhe   >> wrote:
> > >
> > > This is for standard/base and all sub-level branches. For
> explanation, see the
> > > bottom of the commit log I append.
> > >
> > >
> > > Which kernel versions ? I didn't notice a version it the shortlog
> or temporary section, but I may have overlooked it.
> >
> > >From 4.19 to 5.0
> >
> >
> > Thanks, this is now merged.
>
> This is missing on v5.0/standard/intel-x86.
>
>
Not in my tree, but I'll double check as I'm merging more changes later
today.

Bruce



> Zhe
>
> >
> > Bruce
> >
> >
> >
> > Zhe
> >
> > >
> > > Bruce
> > >
> > >
> > >
> > >
> > > Zhe
> > >
> > > On 4/24/19 3:42 PM, zhe...@windriver.com  zhe...@windriver.com> > wrote:
> > > > From: "Steven Rostedt (VMware)"   >>
> > > >
> > > > He Zhe reported a crash by enabling trace events and
> selecting
> > > > "userstacktrace" which will read the stack of userspace for
> every trace
> > > > event recorded. Zhe narrowed it down to:
> > > >
> > > >  c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints
> and unify their usage")
> > > >
> > > > With the problem config, I was able to also reproduce the
> error. I
> > > > narrowed it down to just having to do the following:
> > > >
> > > >  # cd /sys/kernel/tracing
> > > >  # echo 1 > options/userstacktrace
> > > >  # echo 1 > events/preemptirq/irq_disable/enable
> > > >
> > > > And sure enough, I triggered a crash. Well, it was systemd
> crashing
> > > > with a bad memory access??
> > > >
> > > >  systemd-journal[537]: segfault at ed8cb8 ip
> 7f7fffc9fef5 sp 7ffc4062cb10 error 7
> > > >
> > > > And it would crash similarly each time I tried it, but
> always at a
> > > > different place. After spending the day on this, I finally
> figured it
> > > > out. The bug is happening in entry_64.S right after
> error_entry.
> > > > There's two TRACE_IRQS_OFF in that code path, which if I
> comment out,
> > > > the bug goes away. Then it dawned on me that the crash
> always happens
> > > > when systemd does a normal page fault. We had this bug
> before, and it
> > > > was with the exception trace points.
> > > >
> > > > The issue is that a tracepoint can fault (reading vmalloc or
> whatever).
> > > > And doing a userspace stack trace most definitely will
> fault. But if we
> > > > are coming from a legitimate page fault, the address of that
> fault (in
> > > > the CR2 register) will be lost if we fault before we get to
> the page
> > > > fault handler. That's exactly what is happening.
> > > >
> > > > To solve this, a TRACE_IRQS_OFF_CR2 (and ON for consistency)
> was added
> > > > that saves the CR2 register. A new
> trace_hardirqs_off_thunk_cr2 is
> > > > created that stores the cr2 register, calls the
> > > > trace_hardirqs_off_caller, then on return restores the cr2
> register if
> > > > it changed, before returning.
> > > >
> > > > On my tests this fixes the issue. I just want to know if
> this is a
> > > > legitimate fix or if someone can come up with a better fix?
> > > >
> > > > Note: this also saves the exception context just like the
> > > > do_page_fault() function does.
> > > >
> > > > Note2: This only gets enabled when lockdep or irq tracing is
> enabled,
> > > > which is not recommended for production environments.
> > > >
> > > > Link:
> http://lkml.kernel.org/r/897cf5cf-fc24-8a64-cb28-847f2d2e6...@windriver.com
> > > >
> > > > Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq
> tracepoints and unify their usage")
> > > > Signed-off-by: Steven Rostedt (VMware)   >>
> > > >
> > > > Link:
> https://lore.kernel.org/lkml/20190320221534.165ab...@oasis.local.home/
> > > >
> > > > This might not be the final solution. But the upstream
> thread has stopped over
> > > > a month and there is unlikely a final solution in the near
> future.
> > > >
> > > > Since the diff looks quite clear and does not affect other
> functions. It

Re: [yocto] include own script - custon location

2019-04-29 Thread Burton, Ross 
On Mon, 29 Apr 2019 at 10:48, Zolee K  wrote:

> I guess something is wrong with the do-install function, I thought it would 
> put the file in the image, but it doesn't. Please help me out on this.

Bitbake is literally telling you want to do:

> Please set FILES such that these items are packaged.

FILES_${PN} += "/usr/local/www"

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] .pc files are not avilable at build time

2019-04-29 Thread Archana Polampalli 
Thank you for your responce

whaile configuration time getting this error
checking for EXT2FS... no
 INFO - | checking for EXT2FS... no
 INFO - | configure: error: Package requirements (ext2fs) were not 
met:
 INFO - |
 INFO - | No package 'ext2fs' found
 INFO - |
 INFO - | Consider adjusting the PKG_CONFIG_PATH
environment
variable if you installed software in a non-standardprefix.
 INFO - |
 INFO - | Alternatively, you may set the environment
variables  
EXT2FS_CFLAGS and EXT2FS_LIBS to avoid the need to
call pkg-
config See the pkg-config man page for more details.

ex2fs.pc is provided by e2fsprogs package.i have alredy installed it 

Regards
Archana



On Tue, 2019-04-23 at 10:51 +0100, Burton, Ross wrote:
> Works for me.  What is the actual error you're seeing?
> 
> On Tue, 23 Apr 2019 at 10:17, Archana Polampalli
>  wrote:
> > 
> > 
> > Hi all,
> > 
> > I am trying to build btrfs-tools recipes.it needs the ex2fs.pc
> > pkgconfig file.i have alredy installed e2fsprogs recipe it created
> > the
> > ex2fs.pc in image directory.but btrfstools unable to take the
> > pkgconfig
> > file.
> > 
> > plese any help me how to provide ex2fs.pc file for build btrfs-
> > tools
> > 
> > Regards
> > Archana
> > The information contained in this e-mail message and in any
> > attachments/annexure/appendices is confidential to the
> > recipient and may contain privileged information.
> > If you are not the intended recipient, please notify the
> > sender and delete the message along with any
> > attachments/annexure/appendices. You should not disclose,
> > copy or otherwise use the information contained in the
> > message or any annexure. Any views expressed in this e-mail
> > are those of the individual sender except where the sender
> > specifically states them to be the views of
> > Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> > 
> > Although this transmission and any attachments are believed to be
> > free of any virus or other defect that might affect any computer
> > system into which it is received and opened, it is the
> > responsibility
> > of the recipient to ensure that it is virus free and no
> > responsibility
> > is accepted by Toshiba Embedded Software India Pvt. Ltd, for any
> > loss or
> > damage arising in any way from its use.
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] include own script - custon location

2019-04-29 Thread Zolee K 
Hi,

I'd like to include a javascript file in the target machine in a custom
location.
I got an warning while bitbake:
wavesurfer-1.0-r0 do_package: QA Issue: wavesurfer: Files/directories were
installed but not shipped in any package:
  /usr
  /usr/local
  /usr/local/www
  /usr/local/www/sys
  /usr/local/www/sys/js
  /usr/local/www/sys/js/wavesurfer.js
Please set FILES such that these items are packaged. Alternatively if they
are unneeded, avoid installing them or delete them within do_install.
wavesurfer: 6 installed and not shipped files. [installed-vs-shipped]

Here is the bb file:

SUMMARY = "Waveform generator"
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

SRC_URI = "file://wavesurfer.js"

SRC_URI[md5sum] = "523052e51d8668b849abaa303404de3e"

FILESEXTRAPATHS_prepend := "${THISDIR}/file:"

S= "${WORKDIR}"

do_install() {
install -d ${D}/usr/local/www/sys/js
install -m 0644 wavesurfer.js ${D}/usr/local/www/sys/js
}


I guess something is wrong with the do-install function, I thought it would
put the file in the image, but it doesn't. Please help me out on this.

Thanks,

Zolee
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] yacto build filesystem link dpkg or package

2019-04-29 Thread rammohanreddy medapati 
Hi,

i want to link the dpkg package or source code for yacto build system .If
it possible please guide me for adding packages to yacto build system


Thanks,
Rammohan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Disabling sshd is harder than it should be

2019-04-29 Thread ChenQi 

On 04/26/2019 09:26 PM, Richard Weinberger wrote:

My thud based system installs openssh-sshd but I want to have sshd
disabled by default.
So I checked the docs how to disabled a systemd service by default and
found SYSTEMD_AUTO_ENABLE, perfect.

After I put that into my bbappend file I figured that sshd is still
enabled by default.
With one difference, it was no longer present as sshd.socket, but as
sshd.service.
This seemed odd and after another hour I realized that now sshd is
stared as good old sysvinist script. Hmm.

To finally disable sshd by default I had to disable it via systemd
_and_ sysvinit.
Is this really the expected way? :-(

For reference, this is my bbappend file which works:
SYSTEMD_AUTO_ENABLE = "disable"
INITSCRIPT_PARAMS_${PN}-sshd = "remove"



When selecting systemd as the init manager, the following line is 
recommended.

DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
Then you should only need: SYSTEMD_AUTO_ENABLE = "disable"

Best Regards,
Chen Qi
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [patchtest-oe][PATCH] test_metadata_src_uri: new unittest detecting added patch files without modifying SRC_URI

2019-04-29 Thread Changqing Li 

ping

On 3/5/19 5:59 PM, changqing...@windriver.com wrote:

From: Changqing Li 

Adds new unittest detecting when a patch file is added but no corresponding
change to the SRC_URI is done.

This patch is from , get from commit
49201c19cfe4cadd127b112d2858d5b28db49c20, this commit is reverted by commit
6108d97f83b211f9eb245f339a412debd0ec5db4.

The added test case is ok, reason of series 9949 patchtest failed is:
recipe weston have REQUIRED_DISTRO_FEATURES, so parse recipe skipped,
cause self.modified is none, actually .bb is mofified, so make the testcase 
failed.

during patchtest, we don't really need DISTRO_FEATURES, so fix the problem
by set REQUIRED_DISTRO_FEATURES to "" in repo patchtest, meantime, add this
testcase back.

[Yocto #13005]

Signed-off-by: Changqing Li 
---
  tests/test_metadata_src_uri.py | 25 +
  1 file changed, 25 insertions(+)

diff --git a/tests/test_metadata_src_uri.py b/tests/test_metadata_src_uri.py
index a4c5caa..f684ced 100644
--- a/tests/test_metadata_src_uri.py
+++ b/tests/test_metadata_src_uri.py
@@ -85,3 +85,28 @@ class SrcUri(base.Metadata):
'Amend the patch containing the software patch 
file removal',
data=[('Patch', f) for f in not_removed])
  
+def test_src_uri_path_not_updated(self):

+new_patches = set()
+for patch in self.patchset:
+if patch.is_added_file and patch.path.endswith('.patch'):
+new_patches.add(os.path.basename(patch.path))
+
+if not new_patches:
+self.skip('No new patches added, skipping test')
+
+if not self.modified:
+self.fail('New patch path missing in SRC_URI',
+   "Add the patch path to the recipe's SRC_URI",
+   data=[('New patch(es)', '\n'.join(new_patches))])
+
+for pn in self.modified:
+rd = self.tinfoil.parse_recipe(pn)
+
+patchtestdata.PatchTestDataStore['%s-%s-%s' % (self.shortid(), 
self.metadata, pn)] = rd.getVar(self.metadata)
+test_src_uri= patchtestdata.PatchTestDataStore['%s-%s-%s' % 
(self.shortid(), self.metadata, pn)].split()
+test_files= set([os.path.basename(patch) for patch in 
test_src_uri if patch.startswith('file://')])
+
+if not test_files.issuperset(new_patches):
+self.fail('New patch path missing in SRC_URI',
+  "Add the patch path in the recipe's SRC_URI",
+  data=[('New patch(es)', p) for p in 
new_patches.difference(test_files)])


--
BRs

Sandy(Li Changqing)

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [patchtest][PATCH] core-image-patchtest: avoid skip parse recipe

2019-04-29 Thread Changqing Li 

ping

On 3/5/19 5:59 PM, changqing...@windriver.com wrote:

From: Changqing Li 

patchtest [1] failed since the recipe is skipparsed since it defines
REQUIRED_DISTRO_FEATURES.  patchtest don't really need
DISTRO_FEATURES, so fix the problem by set REQUIRED_DISTRO_FEATURES/
COMPATIBLE_MACHINE/COMPATIBLE_HOST to "" to avoid skip parse

[Yocto #13005]

[1] https://patchwork.openembedded.org/series/9949/

Signed-off-by: Changqing Li 
---
  meta-patchtest/recipes-core/images/core-image-patchtest.bb | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta-patchtest/recipes-core/images/core-image-patchtest.bb 
b/meta-patchtest/recipes-core/images/core-image-patchtest.bb
index 47e4041..95279d2 100644
--- a/meta-patchtest/recipes-core/images/core-image-patchtest.bb
+++ b/meta-patchtest/recipes-core/images/core-image-patchtest.bb
@@ -30,6 +30,9 @@ TMPBUILD="\$(mktemp -d)"
  BRANCH="\$(get-target-branch \$REPO \$MBOX | awk '{print \$NF}')"
  cd \$REPO
  source ./oe-init-build-env \$TMPBUILD
+echo "COMPATIBLE_MACHINE_qemuall = \\"\\"" >> \$TMPBUILD/conf/local.conf
+echo "COMPATIBLE_HOST_qemuall = \\"\\"" >> \$TMPBUILD/conf/local.conf
+echo "REQUIRED_DISTRO_FEATURES_qemuall = \\"\\"" >> \$TMPBUILD/conf/local.conf
  test-mboxes -r \$REPO -s \$SUITESTART -m \$MBOX -o \$RESULTS -- --base-branch 
\$BRANCH
  rm -rf \$TMPBUILD
   }


--
BRs

Sandy(Li Changqing)

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto