Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-11 Thread Steve Sakoman 
On Mon, Mar 11, 2024 at 4:01 AM Bruce Ashfield  wrote:
>
> On Mon, Mar 11, 2024 at 9:51 AM Steve Sakoman  wrote:
> >
> > On Sun, Mar 10, 2024 at 4:25 PM Steve Sakoman via
> > lists.openembedded.org 
> > wrote:
> > >
> > > On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield  
> > > wrote:
> > > >
> > > > On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via
> > > > lists.openembedded.org
> > > >  wrote:
> > > > >
> > > > > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> > > > > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> > > > > > > lists.openembedded.org 
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > I did fire up a test of Kevin's patch:
> > > > > > > >
> > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > > > > > > >
> > > > > > > > Let's see what happens.
> > > > > > >
> > > > > > > I can confirm that this patch fixes the parted ptest issues and 
> > > > > > > does
> > > > > > > not trigger any other ptest issues.
> > > > > > >
> > > > > > > However since there is a kirkstone release build scheduled for 
> > > > > > > next
> > > > > > > Tuesday, the current plan of record is to revert the previous
> > > > > > > linux-yocto 5.15 version bump series for the release build.
> > > > > > >
> > > > > > > I will then wait for a patch from Bruce that fixes the problem 
> > > > > > > before
> > > > > > > reapplying it post release.
> > > > > >
> > > > > > If it takes a few more days it may be better to slip that release 
> > > > > > (when
> > > > > > QA are likely testing M3 anyway) in order to resolve this rather 
> > > > > > than
> > > > > > reverting a load of things we'll only then end up reapplying.
> > > > > >
> > > > >
> > > > > I'll be working on it over the weekend, along with some other kernel
> > > > > items that I didn't get to as I worked on this today and some 
> > > > > meta-virt
> > > > > things.
> > > >
> > > > Steve: Here's my latest queue:
> > > >
> > > > https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone
> > > >
> > > > It passed the parted and util-linux ptests locally.
> > >
> > > Thanks Bruce!
> > >
> > > I'll grab the patches and run an a-full on the autobuilder.
> >
> > The a-full results are here:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/
> >
> > The ptest runs came back all green, but there were failures in all of
> > the hw-ref tests that use older versions of 5.15 since the patch added
> > with SRC_URI +=  in your final commit doesn't apply to those older
> > kernel versions.
> >
>
> Yah, that's fine.
>
> We'd never merge the patch like I put it in the queue.
>
> I'll actually merge those changes into the linux-yocto tree and send
> SRCREV updates. I just wanted to make sure that they worked in
> your tests, like they worked in mine.
>
> I can also bump the reference BSPs to pick up the change.
>
> Really this is something that -stable should be fixing, but I'm not
> in a position to propose a fix (it is far from my area of expertise)
> so I kept the patches with as minor touches as possible so when
> (if) they fix the issue, I won't have much conflict.
>
> I can do those SRCREV bumps shortly and send the entire queue
> by patches if that works for you.

That would be perfect. Thanks for the quick response on this, I really
appreciate it!

Steve

> > For example, beaglebone:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/8751/steps/11/logs/errors
> >
> > Steve
> >
> > > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > > > thee at its end
> > > > > - "Use the force Harry" - Gandalf, Star Trek II
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > > thee at its end
> > > > - "Use the force Harry" - Gandalf, Star Trek II
> > > >
> > > >
> > > >
> > >
> > > 
> > >
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196941): 
https://lists.openembedded.org/g/openembedded-core/message/196941
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-11 Thread Bruce Ashfield 
On Mon, Mar 11, 2024 at 9:51 AM Steve Sakoman  wrote:
>
> On Sun, Mar 10, 2024 at 4:25 PM Steve Sakoman via
> lists.openembedded.org 
> wrote:
> >
> > On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield  
> > wrote:
> > >
> > > On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via
> > > lists.openembedded.org
> > >  wrote:
> > > >
> > > > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie
> > > >  wrote:
> > > > >
> > > > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> > > > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> > > > > > lists.openembedded.org 
> > > > > > wrote:
> > > > > > >
> > > > > > > I did fire up a test of Kevin's patch:
> > > > > > >
> > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > > > > > >
> > > > > > > Let's see what happens.
> > > > > >
> > > > > > I can confirm that this patch fixes the parted ptest issues and does
> > > > > > not trigger any other ptest issues.
> > > > > >
> > > > > > However since there is a kirkstone release build scheduled for next
> > > > > > Tuesday, the current plan of record is to revert the previous
> > > > > > linux-yocto 5.15 version bump series for the release build.
> > > > > >
> > > > > > I will then wait for a patch from Bruce that fixes the problem 
> > > > > > before
> > > > > > reapplying it post release.
> > > > >
> > > > > If it takes a few more days it may be better to slip that release 
> > > > > (when
> > > > > QA are likely testing M3 anyway) in order to resolve this rather than
> > > > > reverting a load of things we'll only then end up reapplying.
> > > > >
> > > >
> > > > I'll be working on it over the weekend, along with some other kernel
> > > > items that I didn't get to as I worked on this today and some meta-virt
> > > > things.
> > >
> > > Steve: Here's my latest queue:
> > >
> > > https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone
> > >
> > > It passed the parted and util-linux ptests locally.
> >
> > Thanks Bruce!
> >
> > I'll grab the patches and run an a-full on the autobuilder.
>
> The a-full results are here:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/
>
> The ptest runs came back all green, but there were failures in all of
> the hw-ref tests that use older versions of 5.15 since the patch added
> with SRC_URI +=  in your final commit doesn't apply to those older
> kernel versions.
>

Yah, that's fine.

We'd never merge the patch like I put it in the queue.

I'll actually merge those changes into the linux-yocto tree and send
SRCREV updates. I just wanted to make sure that they worked in
your tests, like they worked in mine.

I can also bump the reference BSPs to pick up the change.

Really this is something that -stable should be fixing, but I'm not
in a position to propose a fix (it is far from my area of expertise)
so I kept the patches with as minor touches as possible so when
(if) they fix the issue, I won't have much conflict.

I can do those SRCREV bumps shortly and send the entire queue
by patches if that works for you.

Bruce

> For example, beaglebone:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/8751/steps/11/logs/errors
>
> Steve
>
> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > > thee at its end
> > > > - "Use the force Harry" - Gandalf, Star Trek II
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > thee at its end
> > > - "Use the force Harry" - Gandalf, Star Trek II
> > >
> > >
> > >
> >
> > 
> >



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196940): 
https://lists.openembedded.org/g/openembedded-core/message/196940
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-11 Thread Steve Sakoman 
On Sun, Mar 10, 2024 at 4:25 PM Steve Sakoman via
lists.openembedded.org 
wrote:
>
> On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield  
> wrote:
> >
> > On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via
> > lists.openembedded.org
> >  wrote:
> > >
> > > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie
> > >  wrote:
> > > >
> > > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> > > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> > > > > lists.openembedded.org 
> > > > > wrote:
> > > > > >
> > > > > > I did fire up a test of Kevin's patch:
> > > > > >
> > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > > > > >
> > > > > > Let's see what happens.
> > > > >
> > > > > I can confirm that this patch fixes the parted ptest issues and does
> > > > > not trigger any other ptest issues.
> > > > >
> > > > > However since there is a kirkstone release build scheduled for next
> > > > > Tuesday, the current plan of record is to revert the previous
> > > > > linux-yocto 5.15 version bump series for the release build.
> > > > >
> > > > > I will then wait for a patch from Bruce that fixes the problem before
> > > > > reapplying it post release.
> > > >
> > > > If it takes a few more days it may be better to slip that release (when
> > > > QA are likely testing M3 anyway) in order to resolve this rather than
> > > > reverting a load of things we'll only then end up reapplying.
> > > >
> > >
> > > I'll be working on it over the weekend, along with some other kernel
> > > items that I didn't get to as I worked on this today and some meta-virt
> > > things.
> >
> > Steve: Here's my latest queue:
> >
> > https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone
> >
> > It passed the parted and util-linux ptests locally.
>
> Thanks Bruce!
>
> I'll grab the patches and run an a-full on the autobuilder.

The a-full results are here:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/

The ptest runs came back all green, but there were failures in all of
the hw-ref tests that use older versions of 5.15 since the patch added
with SRC_URI +=  in your final commit doesn't apply to those older
kernel versions.

For example, beaglebone:

https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/8751/steps/11/logs/errors

Steve

> > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > thee at its end
> > > - "Use the force Harry" - Gandalf, Star Trek II
> > >
> > >
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196938): 
https://lists.openembedded.org/g/openembedded-core/message/196938
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-10 Thread Steve Sakoman 
On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield  wrote:
>
> On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via
> lists.openembedded.org
>  wrote:
> >
> > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie
> >  wrote:
> > >
> > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> > > > lists.openembedded.org 
> > > > wrote:
> > > > >
> > > > > I did fire up a test of Kevin's patch:
> > > > >
> > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > > > >
> > > > > Let's see what happens.
> > > >
> > > > I can confirm that this patch fixes the parted ptest issues and does
> > > > not trigger any other ptest issues.
> > > >
> > > > However since there is a kirkstone release build scheduled for next
> > > > Tuesday, the current plan of record is to revert the previous
> > > > linux-yocto 5.15 version bump series for the release build.
> > > >
> > > > I will then wait for a patch from Bruce that fixes the problem before
> > > > reapplying it post release.
> > >
> > > If it takes a few more days it may be better to slip that release (when
> > > QA are likely testing M3 anyway) in order to resolve this rather than
> > > reverting a load of things we'll only then end up reapplying.
> > >
> >
> > I'll be working on it over the weekend, along with some other kernel
> > items that I didn't get to as I worked on this today and some meta-virt
> > things.
>
> Steve: Here's my latest queue:
>
> https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone
>
> It passed the parted and util-linux ptests locally.

Thanks Bruce!

I'll grab the patches and run an a-full on the autobuilder.

Steve

> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196908): 
https://lists.openembedded.org/g/openembedded-core/message/196908
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-10 Thread Bruce Ashfield 
On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via
lists.openembedded.org
 wrote:
>
> On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie
>  wrote:
> >
> > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> > > lists.openembedded.org 
> > > wrote:
> > > >
> > > > I did fire up a test of Kevin's patch:
> > > >
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > > >
> > > > Let's see what happens.
> > >
> > > I can confirm that this patch fixes the parted ptest issues and does
> > > not trigger any other ptest issues.
> > >
> > > However since there is a kirkstone release build scheduled for next
> > > Tuesday, the current plan of record is to revert the previous
> > > linux-yocto 5.15 version bump series for the release build.
> > >
> > > I will then wait for a patch from Bruce that fixes the problem before
> > > reapplying it post release.
> >
> > If it takes a few more days it may be better to slip that release (when
> > QA are likely testing M3 anyway) in order to resolve this rather than
> > reverting a load of things we'll only then end up reapplying.
> >
>
> I'll be working on it over the weekend, along with some other kernel
> items that I didn't get to as I worked on this today and some meta-virt
> things.

Steve: Here's my latest queue:

https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone

It passed the parted and util-linux ptests locally.

Bruce

>
> Bruce
>
> > Cheers,
> >
> > Richard
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196907): 
https://lists.openembedded.org/g/openembedded-core/message/196907
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Bruce Ashfield 
On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie
 wrote:
>
> On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> > lists.openembedded.org 
> > wrote:
> > >
> > > I did fire up a test of Kevin's patch:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > >
> > > Let's see what happens.
> >
> > I can confirm that this patch fixes the parted ptest issues and does
> > not trigger any other ptest issues.
> >
> > However since there is a kirkstone release build scheduled for next
> > Tuesday, the current plan of record is to revert the previous
> > linux-yocto 5.15 version bump series for the release build.
> >
> > I will then wait for a patch from Bruce that fixes the problem before
> > reapplying it post release.
>
> If it takes a few more days it may be better to slip that release (when
> QA are likely testing M3 anyway) in order to resolve this rather than
> reverting a load of things we'll only then end up reapplying.
>

I'll be working on it over the weekend, along with some other kernel
items that I didn't get to as I worked on this today and some meta-virt
things.

Bruce

> Cheers,
>
> Richard
>
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196866): 
https://lists.openembedded.org/g/openembedded-core/message/196866
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Richard Purdie 
On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> lists.openembedded.org 
> wrote:
> > 
> > I did fire up a test of Kevin's patch:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > 
> > Let's see what happens.
> 
> I can confirm that this patch fixes the parted ptest issues and does
> not trigger any other ptest issues.
> 
> However since there is a kirkstone release build scheduled for next
> Tuesday, the current plan of record is to revert the previous
> linux-yocto 5.15 version bump series for the release build.
> 
> I will then wait for a patch from Bruce that fixes the problem before
> reapplying it post release.

If it takes a few more days it may be better to slip that release (when
QA are likely testing M3 anyway) in order to resolve this rather than
reverting a load of things we'll only then end up reapplying.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196864): 
https://lists.openembedded.org/g/openembedded-core/message/196864
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Steve Sakoman 
On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
lists.openembedded.org 
wrote:
>
> On Fri, Mar 8, 2024 at 5:05 AM Bruce Ashfield  
> wrote:
> >
> > On Fri, Mar 8, 2024 at 9:59 AM Kevin Hao  wrote:
> > >
> > > On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote:
> > > > > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I
> > > > > haven't tried that.
> > > > >
> > > > > Do you have a kirkstone patch that I can try on the autobuilder?
> > > > >
> > > >
> > > > I'd still rather not go the ubuntu patch route. It is my last choice in 
> > > > the
> > > > options.
> > > >
> > > > If this is caused by upstream commits, there should also be upstream
> > > > commits that fix the issues. I need to identify those commits and
> > > > document why they aren't appropriate for our 5.15 kernel before I pick
> > > > up someone's else patch .. since at that point, I have no idea about 
> > > > their
> > > > logic and other issues it may introduce.
> > >
> > > Agreed. But that patch is indeed a backport of upstream commit 
> > > b9684a71fca7 and
> > > the tweak in order to port to v5.15 also seems pretty reasonable. I 
> > > generated
> > > a patch based on the latest kirkstone branch. Steve, could you give the 
> > > attachment
> > > a try?
> >
> > You can give it a try, but I won't merge it as-is.
> >
> > I'll just go ahead and do it myself, since I won't be ignored on the format
> > that I'm looking for in this change.
>
> We wouldn't even think of ignoring you!!
>
> I did fire up a test of Kevin's patch:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
>
> Let's see what happens.

I can confirm that this patch fixes the parted ptest issues and does
not trigger any other ptest issues.

However since there is a kirkstone release build scheduled for next
Tuesday, the current plan of record is to revert the previous
linux-yocto 5.15 version bump series for the release build.

I will then wait for a patch from Bruce that fixes the problem before
reapplying it post release.

I apologize to all for not catching this prior to merging the version
bump series :-(

Steve

> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196860): 
https://lists.openembedded.org/g/openembedded-core/message/196860
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Steve Sakoman 
On Fri, Mar 8, 2024 at 5:05 AM Bruce Ashfield  wrote:
>
> On Fri, Mar 8, 2024 at 9:59 AM Kevin Hao  wrote:
> >
> > On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote:
> > > > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I
> > > > haven't tried that.
> > > >
> > > > Do you have a kirkstone patch that I can try on the autobuilder?
> > > >
> > >
> > > I'd still rather not go the ubuntu patch route. It is my last choice in 
> > > the
> > > options.
> > >
> > > If this is caused by upstream commits, there should also be upstream
> > > commits that fix the issues. I need to identify those commits and
> > > document why they aren't appropriate for our 5.15 kernel before I pick
> > > up someone's else patch .. since at that point, I have no idea about their
> > > logic and other issues it may introduce.
> >
> > Agreed. But that patch is indeed a backport of upstream commit b9684a71fca7 
> > and
> > the tweak in order to port to v5.15 also seems pretty reasonable. I 
> > generated
> > a patch based on the latest kirkstone branch. Steve, could you give the 
> > attachment
> > a try?
>
> You can give it a try, but I won't merge it as-is.
>
> I'll just go ahead and do it myself, since I won't be ignored on the format
> that I'm looking for in this change.

We wouldn't even think of ignoring you!!

I did fire up a test of Kevin's patch:

https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373

Let's see what happens.

Steve

> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196855): 
https://lists.openembedded.org/g/openembedded-core/message/196855
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Bruce Ashfield 
On Fri, Mar 8, 2024 at 9:59 AM Kevin Hao  wrote:
>
> On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote:
> > > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I
> > > haven't tried that.
> > >
> > > Do you have a kirkstone patch that I can try on the autobuilder?
> > >
> >
> > I'd still rather not go the ubuntu patch route. It is my last choice in the
> > options.
> >
> > If this is caused by upstream commits, there should also be upstream
> > commits that fix the issues. I need to identify those commits and
> > document why they aren't appropriate for our 5.15 kernel before I pick
> > up someone's else patch .. since at that point, I have no idea about their
> > logic and other issues it may introduce.
>
> Agreed. But that patch is indeed a backport of upstream commit b9684a71fca7 
> and
> the tweak in order to port to v5.15 also seems pretty reasonable. I generated
> a patch based on the latest kirkstone branch. Steve, could you give the 
> attachment
> a try?

You can give it a try, but I won't merge it as-is.

I'll just go ahead and do it myself, since I won't be ignored on the format
that I'm looking for in this change.

Cheers,

Bruce

>
> Thanks,
> Kevin



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196854): 
https://lists.openembedded.org/g/openembedded-core/message/196854
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Kevin Hao 
On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote:
> > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I
> > haven't tried that.
> >
> > Do you have a kirkstone patch that I can try on the autobuilder?
> >
> 
> I'd still rather not go the ubuntu patch route. It is my last choice in the
> options.
> 
> If this is caused by upstream commits, there should also be upstream
> commits that fix the issues. I need to identify those commits and
> document why they aren't appropriate for our 5.15 kernel before I pick
> up someone's else patch .. since at that point, I have no idea about their
> logic and other issues it may introduce.

Agreed. But that patch is indeed a backport of upstream commit b9684a71fca7 and
the tweak in order to port to v5.15 also seems pretty reasonable. I generated
a patch based on the latest kirkstone branch. Steve, could you give the 
attachment
a try?

Thanks,
Kevin
From dca6a0cec06a161d697bd255eff05b474c3e Mon Sep 17 00:00:00 2001
From: Kevin Hao 
Date: Fri, 8 Mar 2024 22:31:26 +0800
Subject: [PATCH] linux-yocto: Don't merge: Fix the parted ptest failues

Signed-off-by: Kevin Hao 
---
 ...-support-partitions-without-scanning.patch | 104 ++
 meta/recipes-kernel/linux/linux-yocto_5.15.bb |   3 +-
 2 files changed, 106 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch

diff --git 
a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
 
b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
new file mode 100644
index ..f77b0e9eb00a
--- /dev/null
+++ 
b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
@@ -0,0 +1,104 @@
+From 82fad6e9334f1239fe090def17ca947c89fc4308 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig 
+Date: Fri, 27 May 2022 07:58:06 +0200
+Subject: [PATCH] block, loop: support partitions without scanning
+
+BugLink: https://bugs.launchpad.net/bugs/2056143
+
+Historically we did distinguish between a flag that surpressed partition
+scanning, and a combinations of the minors variable and another flag if
+any partitions were supported.  This was generally confusing and doesn't
+make much sense, but some corner case uses of the loop driver actually
+do want to support manually added partitions on a device that does not
+actively scan for partitions.  To make things worsee the loop driver
+also wants to dynamically toggle the scanning for partitions on a live
+gendisk, which makes the disk->flags updates non-atomic.
+
+Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
+just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
+in the loop driver.
+
+Upstream-Status: Backport [c3032b60ff7b3948325b8f2bd688b9a74be3cfb9]
+
+Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
+Reported-by: Ming Lei 
+Signed-off-by: Christoph Hellwig 
+Reviewed-by: Ming Lei 
+Link: https://lore.kernel.org/r/20220527055806.1972352-1-...@lst.de
+Signed-off-by: Jens Axboe 
+
+(backported from commit b9684a71fca793213378dd410cd11675d973eaa1)
+[smb: Flag and test for partition scan in genhd.h instead]
+Signed-off-by: Stefan Bader 
+Acked-by: Roxana Nicolescu 
+Acked-by: Manuel Diewald 
+Signed-off-by: Stefan Bader 
+---
+ drivers/block/loop.c  | 8 
+ include/linux/genhd.h | 3 +++
+ 2 files changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/block/loop.c b/drivers/block/loop.c
+index 4769caab9ff9..a76302450c46 100644
+--- a/drivers/block/loop.c
 b/drivers/block/loop.c
+@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, 
fmode_t mode,
+   lo->lo_flags |= LO_FLAGS_PARTSCAN;
+   partscan = lo->lo_flags & LO_FLAGS_PARTSCAN;
+   if (partscan)
+-  lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
++  clear_bit(GD_SUPPRESS_PART_SCAN, >lo_disk->state);
+ 
+   /* enable and uncork uevent now that we are done */
+   dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0);
+@@ -1481,7 +1481,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool 
release)
+   mutex_lock(>lo_mutex);
+   lo->lo_flags = 0;
+   if (!part_shift)
+-  lo->lo_disk->flags |= GENHD_FL_NO_PART;
++  set_bit(GD_SUPPRESS_PART_SCAN, >lo_disk->state);
+   lo->lo_state = Lo_unbound;
+   mutex_unlock(>lo_mutex);
+ 
+@@ -1598,7 +1598,7 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
+ 
+   if (!err && (lo->lo_flags & LO_FLAGS_PARTSCAN) &&
+!(prev_lo_flags & LO_FLAGS_PARTSCAN)) {
+-  lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
++  clear_bit(GD_SUPPRESS_PART_SCAN, >lo_disk->state);
+   partscan = true;
+   }
+ out_unlock:
+@@ -2428,7 +2428,7 @@ static int loop_add(int i)
+* userspace tools. Parameters like this in general should be

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Bruce Ashfield 
On Fri, Mar 8, 2024 at 9:21 AM Steve Sakoman  wrote:
>
> On Fri, Mar 8, 2024 at 3:35 AM Kevin Hao  wrote:
> >
> > On Thu, Mar 07, 2024 at 06:13:35PM -0500, Bruce Ashfield wrote:
> > > Adding Kevin,
> > >
> > > I'm not going to be able to debug this more for a week or so.
> > >
> > > The alternate ways to fix it would be to try that ubuntu patch (fixed
> > > for our tree), and / or see what else needs
> > > to be cherry picked to -stable to fix util-linux. It is likely just a
> > > return code difference to userspace when
> > > resizing is being done.
> > >
> > > Kevin: I'm not sure if Wind River is seeing this, but you might want to 
> > > look
> > > into those ptests and see if they pass on your end.
> >
> > A silly question, which branch are these three patches supposed to apply to?
> > I have tried the kirkstone branch, but it seems that they can't apply 
> > cleanly.
> > I also tried to manually apply the two kernel patches to the latest
> > linux-yocto/v5.15/standard/base branch, but they also can't be applied 
> > cleanly.
> > Am I miss something?
>
> No, you haven't missed anything.  Bruce was assuming that kirkstone
> contained  patches that he hasn't sent yet. I wasn't able to apply the
> second two patches either.

Yes, exactly. I did the patches against a different queue than what
Steve had in test.

>
> > On the latest linux-yocto/v5.15/standard/base kernel, the parted ptest
> > does have three failures. Then I have tried the ubuntu kernel patch [1] 
> > which is
> > mentioned in the previous discussion about this issue. This patch can apply 
> > to
> > the linux-yocto/v5.15/standard/base cleanly and it indeed resolve the parted
> > failures, and I also don't find util-linux ptest failure after applying this
> > patch. I attached my logs.
>
> Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I
> haven't tried that.
>
> Do you have a kirkstone patch that I can try on the autobuilder?
>

I'd still rather not go the ubuntu patch route. It is my last choice in the
options.

If this is caused by upstream commits, there should also be upstream
commits that fix the issues. I need to identify those commits and
document why they aren't appropriate for our 5.15 kernel before I pick
up someone's else patch .. since at that point, I have no idea about their
logic and other issues it may introduce.

Bruce

> Thanks!
>
> Steve
>
> > [1] 
> > https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next--2024.03.04-1=c3032b60ff7b3948325b8f2bd688b9a74be3cfb9
> >
> > Thanks,
> > Kevin
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196852): 
https://lists.openembedded.org/g/openembedded-core/message/196852
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Steve Sakoman 
On Fri, Mar 8, 2024 at 3:35 AM Kevin Hao  wrote:
>
> On Thu, Mar 07, 2024 at 06:13:35PM -0500, Bruce Ashfield wrote:
> > Adding Kevin,
> >
> > I'm not going to be able to debug this more for a week or so.
> >
> > The alternate ways to fix it would be to try that ubuntu patch (fixed
> > for our tree), and / or see what else needs
> > to be cherry picked to -stable to fix util-linux. It is likely just a
> > return code difference to userspace when
> > resizing is being done.
> >
> > Kevin: I'm not sure if Wind River is seeing this, but you might want to look
> > into those ptests and see if they pass on your end.
>
> A silly question, which branch are these three patches supposed to apply to?
> I have tried the kirkstone branch, but it seems that they can't apply cleanly.
> I also tried to manually apply the two kernel patches to the latest
> linux-yocto/v5.15/standard/base branch, but they also can't be applied 
> cleanly.
> Am I miss something?

No, you haven't missed anything.  Bruce was assuming that kirkstone
contained  patches that he hasn't sent yet. I wasn't able to apply the
second two patches either.

> On the latest linux-yocto/v5.15/standard/base kernel, the parted ptest
> does have three failures. Then I have tried the ubuntu kernel patch [1] which 
> is
> mentioned in the previous discussion about this issue. This patch can apply to
> the linux-yocto/v5.15/standard/base cleanly and it indeed resolve the parted
> failures, and I also don't find util-linux ptest failure after applying this
> patch. I attached my logs.

Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I
haven't tried that.

Do you have a kirkstone patch that I can try on the autobuilder?

Thanks!

Steve

> [1] 
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next--2024.03.04-1=c3032b60ff7b3948325b8f2bd688b9a74be3cfb9
>
> Thanks,
> Kevin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196851): 
https://lists.openembedded.org/g/openembedded-core/message/196851
Mute This Topic: https://lists.openembedded.org/mt/104794844/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-08 Thread Kevin Hao 
On Thu, Mar 07, 2024 at 06:13:35PM -0500, Bruce Ashfield wrote:
> Adding Kevin,
> 
> I'm not going to be able to debug this more for a week or so.
> 
> The alternate ways to fix it would be to try that ubuntu patch (fixed
> for our tree), and / or see what else needs
> to be cherry picked to -stable to fix util-linux. It is likely just a
> return code difference to userspace when
> resizing is being done.
> 
> Kevin: I'm not sure if Wind River is seeing this, but you might want to look
> into those ptests and see if they pass on your end.

A silly question, which branch are these three patches supposed to apply to?
I have tried the kirkstone branch, but it seems that they can't apply cleanly.
I also tried to manually apply the two kernel patches to the latest
linux-yocto/v5.15/standard/base branch, but they also can't be applied cleanly.
Am I miss something?

On the latest linux-yocto/v5.15/standard/base kernel, the parted ptest
does have three failures. Then I have tried the ubuntu kernel patch [1] which is
mentioned in the previous discussion about this issue. This patch can apply to
the linux-yocto/v5.15/standard/base cleanly and it indeed resolve the parted
failures, and I also don't find util-linux ptest failure after applying this
patch. I attached my logs.

[1] 
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next--2024.03.04-1=c3032b60ff7b3948325b8f2bd688b9a74be3cfb9

Thanks,
Kevin
START: ptest-runner
2024-03-08T13:02
BEGIN: /usr/lib/parted/ptest
make: Entering directory '/usr/lib/parted/ptest/tests'
PASS: help-version.sh
PASS: t-basic.sh
PASS: t0001-tiny.sh
PASS: t0010-script-no-ctrl-chars.sh
PASS: t0100-print.sh
PASS: t0101-print-empty.sh
PASS: t0200-gpt.sh
PASS: t0201-gpt.sh
PASS: t0202-gpt-pmbr.sh
PASS: t0203-gpt-tiny-device-abort.sh
PASS: t0203-gpt-shortened-device-primary-valid.sh
PASS: t0203-gpt-create-on-min-sized-device.sh
PASS: t0205-gpt-list-clobbers-pmbr.sh
PASS: t0206-gpt-print-with-corrupt-primary-clobbers-pmbr.sh
PASS: t0207-IEC-binary-notation.sh
PASS: t0208-mkpart-end-in-IEC.sh
PASS: t0209-gpt-pmbr_boot.sh
t0210-gpt-resized-partition-entry-array.sh: skipped test: this test requires 
Perl's Digest::CRC module
SKIP: t0210-gpt-resized-partition-entry-array.sh
t0211-gpt-rewrite-header.sh: skipped test: this test requires Perl's 
Digest::CRC module
SKIP: t0211-gpt-rewrite-header.sh
PASS: t0212-gpt-many-partitions.sh
PASS: t0213-mkpart-start-negative.sh
PASS: t0220-gpt-msftres.sh
PASS: t0250-gpt.sh
PASS: t0251-gpt-unicode.sh
PASS: t0280-gpt-corrupt.sh
PASS: t0281-gpt-grow.sh
PASS: t0282-gpt-move-backup.sh
PASS: t0283-overlap-partitions.sh
PASS: t0300-dos-on-gpt.sh
PASS: t0301-overwrite-gpt-pmbr.sh
PASS: t0350-mac-PT-increases-sector-size.sh
PASS: t0400-loop-clobber-infloop.sh
PASS: t0500-dup-clobber.sh
PASS: t0501-duplicate.sh
t1100-busy-label.sh: skipped test: you lack the scsi_debug kernel module
SKIP: t1100-busy-label.sh
t1101-busy-partition.sh: skipped test: you lack the scsi_debug kernel module
SKIP: t1101-busy-partition.sh
t1102-loop-label.sh: skipped test: you lack the scsi_debug kernel module
SKIP: t1102-loop-label.sh
PASS: t1104-remove-and-add-partition.sh
: no xfs support
: no nilfs2 support
: no ntfs support
: no hfsplus support
: no udf support
: no f2fs support
PASS: t1700-probe-fs.sh
t1701-rescue-fs.sh: skipped test: you lack the scsi_debug kernel module
SKIP: t1701-rescue-fs.sh
PASS: t2200-dos-label-recog.sh
PASS: t2201-pc98-label-recog.sh
PASS: t2300-dos-label-extended-bootcode.sh
t2310-dos-extended-2-sector-min-offset.sh: skipped test: you lack the 
scsi_debug kernel module
SKIP: t2310-dos-extended-2-sector-min-offset.sh
t2320-dos-extended-noclobber.sh: skipped test: you lack the scsi_debug kernel 
module
SKIP: t2320-dos-extended-noclobber.sh
PASS: t2400-dos-hfs-partition-type.sh
PASS: t2410-dos-udf-partition-type.sh
PASS: t2500-probe-corrupt-hfs.sh
t3000-resize-fs.sh: skipped test: mkfs.hfs: command not found
SKIP: t3000-resize-fs.sh
t3200-resize-partition.sh: skipped test: you lack the scsi_debug kernel module
SKIP: t3200-resize-partition.sh
t3200-type-change.sh: skipped test: you lack the scsi_debug kernel module
SKIP: t3200-type-change.sh
PASS: t3300-palo-prep.sh
PASS: t3310-flags.sh
PASS: t3400-whole-disk-FAT-partition.sh
PASS: t4000-sun-raid-type.sh
PASS: t4001-sun-vtoc.sh
t4100-msdos-partition-limits.sh: skipped test: this test requires XFS support
SKIP: t4100-msdos-partition-limits.sh
t4100-dvh-partition-limits.sh: skipped test: this test requires XFS support
SKIP: t4100-dvh-partition-limits.sh
PASS: t4100-msdos-starting-sector.sh
t4200-partprobe.sh: skipped test: This test requires an erasable device and you 
have not properly set the $DEVICE_TO_ERASE and $DEVICE_TO_ERASE_SIZE envvars.
SKIP: t4200-partprobe.sh
PASS: t4300-nilfs2-tiny.sh
PASS: t4301-nilfs2-badsb2.sh
PASS: t4302-nilfs2-lessbadsb2.sh
PASS: t5000-tags.sh
t6000-dm.sh: skipped test: no device-mapper support
SKIP: t6000-dm.sh
t6001-psep.sh: skipped test:

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-07 Thread Bruce Ashfield 
Adding Kevin,

I'm not going to be able to debug this more for a week or so.

The alternate ways to fix it would be to try that ubuntu patch (fixed
for our tree), and / or see what else needs
to be cherry picked to -stable to fix util-linux. It is likely just a
return code difference to userspace when
resizing is being done.

Kevin: I'm not sure if Wind River is seeing this, but you might want to look
into those ptests and see if they pass on your end.

Bruce

On Thu, Mar 7, 2024 at 6:05 PM Steve Sakoman  wrote:
>
> Hi Bruce,
>
> This patch seems to fix the parted ptest problems, but now util-linux
> ptest is failing :-(
>
> Also seems to be partition resize related:
>
> AssertionError: Failed ptests:
> {'util-linux': ['fdisk:_gpt-resize']}
>
> Steve
>
> On Thu, Mar 7, 2024 at 9:34 AM Bruce Ashfield  
> wrote:
> >
> > From: Bruce Ashfield 
> >
> > Signed-off-by: Bruce Ashfield 
> > ---
> >  ...partitions-if-GD_SUPPRESS_PART_SCAN-.patch | 43 +
> >  ...-support-partitions-without-scanning.patch | 87 +++
> >  meta/recipes-kernel/linux/linux-yocto_5.15.bb |  4 +
> >  3 files changed, 134 insertions(+)
> >  create mode 100644 
> > meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> >  create mode 100644 
> > meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> >
> > diff --git 
> > a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> >  
> > b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> > new file mode 100644
> > index 00..cde4f317e9
> > --- /dev/null
> > +++ 
> > b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> > @@ -0,0 +1,43 @@
> > +From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001
> > +From: Ming Lei 
> > +Date: Tue, 23 Aug 2022 18:38:19 +0800
> > +Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is 
> > set
> > +
> > +Commit b9684a71fca7 ("block, loop: support partitions without scanning")
> > +adds GD_SUPPRESS_PART_SCAN for replacing part function of
> > +GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since
> > +loop doesn't want to add partitions if GENHD_FL_NO_PART was set.
> > +And it causes regression on libblockdev (as called from udisks) which
> > +operates with the LO_FLAGS_PARTSCAN.
> > +
> > +Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is
> > +set.
> > +
> > +Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c]
> > +
> > +Fixes: b9684a71fca7 ("block, loop: support partitions without scanning")
> > +Signed-off-by: Ming Lei 
> > +Reviewed-by: Christoph Hellwig 
> > +Link: https://lore.kernel.org/r/20220823103819.395776-1-ming@redhat.com
> > +Signed-off-by: Jens Axboe 
> > +---
> > + block/partitions/core.c | 3 +++
> > + 1 file changed, 3 insertions(+)
> > +
> > +diff --git a/block/partitions/core.c b/block/partitions/core.c
> > +index fc1d70384825..b8112f52d388 100644
> > +--- a/block/partitions/core.c
> >  b/block/partitions/core.c
> > +@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk)
> > +   if (disk->flags & GENHD_FL_NO_PART)
> > +   return 0;
> > +
> > ++  if (test_bit(GD_SUPPRESS_PART_SCAN, >state))
> > ++  return 0;
> > ++
> > +   state = check_partition(disk);
> > +   if (!state)
> > +   return 0;
> > +--
> > +2.39.2
> > +
> > diff --git 
> > a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> >  
> > b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> > new file mode 100644
> > index 00..9522c2d2cc
> > --- /dev/null
> > +++ 
> > b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> > @@ -0,0 +1,87 @@
> > +From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001
> > +From: Christoph Hellwig 
> > +Date: Fri, 27 May 2022 07:58:06 +0200
> > +Subject: [PATCH] block, loop: support partitions without scanning
> > +
> > +Historically we did distinguish between a flag that surpressed partition
> > +scanning, and a combinations of the minors variable and another flag if
> > +any partitions were supported.  This was generally confusing and doesn't
> > +make much sense, but some corner case uses of the loop driver actually
> > +do want to support manually added partitions on a device that does not
> > +actively scan for partitions.  To make things worsee the loop driver
> > +also wants to dynamically toggle the scanning for partitions on a live
> > +gendisk, which makes the disk->flags updates non-atomic.
> > +
> > +Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
> > +just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
> > +in the loop driver.
> > +
> > +Upstream-Status:

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-07 Thread Steve Sakoman 
Hi Bruce,

This patch seems to fix the parted ptest problems, but now util-linux
ptest is failing :-(

Also seems to be partition resize related:

AssertionError: Failed ptests:
{'util-linux': ['fdisk:_gpt-resize']}

Steve

On Thu, Mar 7, 2024 at 9:34 AM Bruce Ashfield  wrote:
>
> From: Bruce Ashfield 
>
> Signed-off-by: Bruce Ashfield 
> ---
>  ...partitions-if-GD_SUPPRESS_PART_SCAN-.patch | 43 +
>  ...-support-partitions-without-scanning.patch | 87 +++
>  meta/recipes-kernel/linux/linux-yocto_5.15.bb |  4 +
>  3 files changed, 134 insertions(+)
>  create mode 100644 
> meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
>  create mode 100644 
> meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
>
> diff --git 
> a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
>  
> b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> new file mode 100644
> index 00..cde4f317e9
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> @@ -0,0 +1,43 @@
> +From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001
> +From: Ming Lei 
> +Date: Tue, 23 Aug 2022 18:38:19 +0800
> +Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is set
> +
> +Commit b9684a71fca7 ("block, loop: support partitions without scanning")
> +adds GD_SUPPRESS_PART_SCAN for replacing part function of
> +GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since
> +loop doesn't want to add partitions if GENHD_FL_NO_PART was set.
> +And it causes regression on libblockdev (as called from udisks) which
> +operates with the LO_FLAGS_PARTSCAN.
> +
> +Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is
> +set.
> +
> +Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c]
> +
> +Fixes: b9684a71fca7 ("block, loop: support partitions without scanning")
> +Signed-off-by: Ming Lei 
> +Reviewed-by: Christoph Hellwig 
> +Link: https://lore.kernel.org/r/20220823103819.395776-1-ming@redhat.com
> +Signed-off-by: Jens Axboe 
> +---
> + block/partitions/core.c | 3 +++
> + 1 file changed, 3 insertions(+)
> +
> +diff --git a/block/partitions/core.c b/block/partitions/core.c
> +index fc1d70384825..b8112f52d388 100644
> +--- a/block/partitions/core.c
>  b/block/partitions/core.c
> +@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk)
> +   if (disk->flags & GENHD_FL_NO_PART)
> +   return 0;
> +
> ++  if (test_bit(GD_SUPPRESS_PART_SCAN, >state))
> ++  return 0;
> ++
> +   state = check_partition(disk);
> +   if (!state)
> +   return 0;
> +--
> +2.39.2
> +
> diff --git 
> a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
>  
> b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> new file mode 100644
> index 00..9522c2d2cc
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> @@ -0,0 +1,87 @@
> +From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001
> +From: Christoph Hellwig 
> +Date: Fri, 27 May 2022 07:58:06 +0200
> +Subject: [PATCH] block, loop: support partitions without scanning
> +
> +Historically we did distinguish between a flag that surpressed partition
> +scanning, and a combinations of the minors variable and another flag if
> +any partitions were supported.  This was generally confusing and doesn't
> +make much sense, but some corner case uses of the loop driver actually
> +do want to support manually added partitions on a device that does not
> +actively scan for partitions.  To make things worsee the loop driver
> +also wants to dynamically toggle the scanning for partitions on a live
> +gendisk, which makes the disk->flags updates non-atomic.
> +
> +Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
> +just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
> +in the loop driver.
> +
> +Upstream-Status: Backport [b9684a71fca793213378dd410cd11675d973eaa1]
> +
> +Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
> +Reported-by: Ming Lei 
> +Signed-off-by: Christoph Hellwig 
> +Reviewed-by: Ming Lei 
> +Link: https://lore.kernel.org/r/20220527055806.1972352-1-...@lst.de
> +Signed-off-by: Jens Axboe 
> +Signed-off-by: Bruce Ashfield 
> +---
> + drivers/block/loop.c   | 8 
> + include/linux/blkdev.h | 1 +
> + 2 files changed, 5 insertions(+), 4 deletions(-)
> +
> +diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> +index 4769caab9ff9..a76302450c46 100644
> +--- a/drivers/block/loop.c
>  b/drivers/block/loop.c
> +@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, 
> fmode_t mode,
> +

[OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-07 Thread Bruce Ashfield 
From: Bruce Ashfield 

Signed-off-by: Bruce Ashfield 
---
 ...partitions-if-GD_SUPPRESS_PART_SCAN-.patch | 43 +
 ...-support-partitions-without-scanning.patch | 87 +++
 meta/recipes-kernel/linux/linux-yocto_5.15.bb |  4 +
 3 files changed, 134 insertions(+)
 create mode 100644 
meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
 create mode 100644 
meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch

diff --git 
a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
 
b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
new file mode 100644
index 00..cde4f317e9
--- /dev/null
+++ 
b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
@@ -0,0 +1,43 @@
+From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001
+From: Ming Lei 
+Date: Tue, 23 Aug 2022 18:38:19 +0800
+Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is set
+
+Commit b9684a71fca7 ("block, loop: support partitions without scanning")
+adds GD_SUPPRESS_PART_SCAN for replacing part function of
+GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since
+loop doesn't want to add partitions if GENHD_FL_NO_PART was set.
+And it causes regression on libblockdev (as called from udisks) which
+operates with the LO_FLAGS_PARTSCAN.
+
+Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is
+set.
+
+Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c]
+
+Fixes: b9684a71fca7 ("block, loop: support partitions without scanning")
+Signed-off-by: Ming Lei 
+Reviewed-by: Christoph Hellwig 
+Link: https://lore.kernel.org/r/20220823103819.395776-1-ming@redhat.com
+Signed-off-by: Jens Axboe 
+---
+ block/partitions/core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/block/partitions/core.c b/block/partitions/core.c
+index fc1d70384825..b8112f52d388 100644
+--- a/block/partitions/core.c
 b/block/partitions/core.c
+@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk)
+   if (disk->flags & GENHD_FL_NO_PART)
+   return 0;
+ 
++  if (test_bit(GD_SUPPRESS_PART_SCAN, >state))
++  return 0;
++
+   state = check_partition(disk);
+   if (!state)
+   return 0;
+-- 
+2.39.2
+
diff --git 
a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
 
b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
new file mode 100644
index 00..9522c2d2cc
--- /dev/null
+++ 
b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
@@ -0,0 +1,87 @@
+From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig 
+Date: Fri, 27 May 2022 07:58:06 +0200
+Subject: [PATCH] block, loop: support partitions without scanning
+
+Historically we did distinguish between a flag that surpressed partition
+scanning, and a combinations of the minors variable and another flag if
+any partitions were supported.  This was generally confusing and doesn't
+make much sense, but some corner case uses of the loop driver actually
+do want to support manually added partitions on a device that does not
+actively scan for partitions.  To make things worsee the loop driver
+also wants to dynamically toggle the scanning for partitions on a live
+gendisk, which makes the disk->flags updates non-atomic.
+
+Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
+just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
+in the loop driver.
+
+Upstream-Status: Backport [b9684a71fca793213378dd410cd11675d973eaa1]
+
+Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
+Reported-by: Ming Lei 
+Signed-off-by: Christoph Hellwig 
+Reviewed-by: Ming Lei 
+Link: https://lore.kernel.org/r/20220527055806.1972352-1-...@lst.de
+Signed-off-by: Jens Axboe 
+Signed-off-by: Bruce Ashfield 
+---
+ drivers/block/loop.c   | 8 
+ include/linux/blkdev.h | 1 +
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/block/loop.c b/drivers/block/loop.c
+index 4769caab9ff9..a76302450c46 100644
+--- a/drivers/block/loop.c
 b/drivers/block/loop.c
+@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, 
fmode_t mode,
+   lo->lo_flags |= LO_FLAGS_PARTSCAN;
+   partscan = lo->lo_flags & LO_FLAGS_PARTSCAN;
+   if (partscan)
+-  lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
++  clear_bit(GD_SUPPRESS_PART_SCAN, >lo_disk->state);
+ 
+   /* enable and uncork uevent now that we are done */
+   dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0);
+@@ -1481,7 +1481,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool 
release)
+   mutex_lock(>lo_mutex);
+   lo->lo_flags = 0;
+