[PATCH v3 12/70] dm: part: Update test to use mmc2

[Simon Glass]

Hi Tom,

On Tue, 24 Jan 2023 at 11:28, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Jan 24, 2023 at 11:15:15AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 24 Jan 2023 at 08:49, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Jan 24, 2023 at 03:56:00AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 23 Jan 2023 at 18:39, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
> > > > >
> > > > > > At present this test sets up a partition table on mmc1. But this is used
> > > > > > by the bootstd tests, so it is not possible to run those after this test
> > > > > > has run, without restarting the Python test harness.
> > > > > >
> > > > > > This is inconvenient when running tests repeatedly with 'ut dm'. Move the
> > > > > > test to use mmc2, which is not used by anything.
> > > > > >
> > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > >
> > > > > When I run tests like this:
> > > > > TEST="not sleep and not event_dump and not bootmgr and not extension"
> > > > > ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> > > > > ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST" -ra
> > > > > I get:
> > > > > ========================================== FAILURES ===========================================
> > > > > _________________________________ test_ut[ut_dm_dm_test_part] _________________________________
> > > > > test/py/tests/test_ut.py:341: in test_ut
> > > > >     assert output.endswith('Failures: 0')
> > > > > E   assert False
> > > > > E    +  where False = <built-in method endswith of str object at 0x2776470>('Failures: 0')
> > > > > E    +    where <built-in method endswith of str object at 0x2776470> = 'Test: dm_test_part: part.c\r\r\n** No device specified **\r\r\nCouldn\'t find partition mmc <NULL>\r\r\n** No device ...: 0 == do_test(uts, 2, "1:2", 0): Expected 0x0 (0), got 0x1 (1)\r\r\nTest dm_test_part failed 4 times\r\r\nFailures: 4'.endswith
> > > > > ------------------------------------ Captured stdout call -------------------------------------
> > > > > => ut dm dm_test_part
> > > > > Test: dm_test_part: part.c
> > > > > ** No device specified **
> > > > > Couldn't find partition mmc <NULL>
> > > > > ** No device specified **
> > > > > Couldn't find partition mmc
> > > > > ** No partition table - mmc 0 **
> > > > > Couldn't find partition mmc 0
> > > > > Could not find "test1" partition
> > > > > ** Bad device specification mmc #test1 **
> > > > > ** Bad device specification mmc #test1 **
> > > > > Couldn't find partition mmc #test1
> > > > > ** Bad partition specification mmc 1:0 **
> > > > > Couldn't find partition mmc 1:0
> > > > > ** Invalid partition 2 **
> > > > > Couldn't find partition mmc 1:2
> > > > > test/dm/part.c:20, do_test(): expected == part_get_info_by_dev_and_name_or_num("mmc", part_str, &mmc_dev_desc, &part_info, whole): Expected 0x2 (2), got 0xfffffffe (-2)
> > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0): Expected 0x0 (0), got 0x1 (1)
> > > > > Test: dm_test_part: part.c (flat tree)
> > > > > ** No device specified **
> > > > > Couldn't find partition mmc <NULL>
> > > > > ** No device specified **
> > > > > Couldn't find partition mmc
> > > > > ** No partition table - mmc 0 **
> > > > > Couldn't find partition mmc 0
> > > > > Could not find "test1" partition
> > > > > ** Bad device specification mmc #test1 **
> > > > > ** Bad device specification mmc #test1 **
> > > > > Couldn't find partition mmc #test1
> > > > > ** Bad partition specification mmc 1:0 **
> > > > > Couldn't find partition mmc 1:0
> > > > > ** Invalid partition 2 **
> > > > > Couldn't find partition mmc 1:2
> > > > > test/dm/part.c:20, do_test(): expected == part_get_info_by_dev_and_name_or_num("mmc", part_str, &mmc_dev_desc, &part_info, whole): Expected 0x2 (2), got 0xfffffffe (-2)
> > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0): Expected 0x0 (0), got 0x1 (1)
> > > > > Test dm_test_part failed 4 times
> > > > > Failures: 4
> > > > > =>
> > > >
> > > > Oh dear. I believe this is an ordering problem. These two patches need
> > > > to be applied together because the first one changes mmc1.img and the
> > > > second one relies on that change:
> > > >
> > > > part: Add a function to find the first bootable partition
> > > > dm: part: Update test to use mmc2
> > > >
> > > > I have them quite far apart in the series.
> > > >
> > > > I can merge them into one commit, perhaps?
> > > >
> > > > >
> > > > > And further tests down the series also fail / introduce failures, but
> > > > > this is the first one, and why I thought v2 had more problems.
> > > >
> > > > For some reason I'm not seeing this, but it could be another ordering
> > > > thing. I don't see failures on CI but it only tests the whole.
> > > >
> > > > Let me know what you'd like me to do. I don't currently have a way to
> > > > run tests on every commit, so my testing there is a bit random. I
> > > > normally just build-test the series and then check with CI.
> > >
> > > Well, your ordering comment is interesting. I bisect'd down to this
> > > patch being a problem because with the full series applied I see:
> > > ========================================== FAILURES ===========================================
> > > ___________________________________ test_ut_dm_init_bootstd ___________________________________
> > > test/py/tests/test_ut.py:320: in test_ut_dm_init_bootstd
> > >     setup_bootflow_image(u_boot_console)
> > > test/py/tests/test_ut.py:226: in setup_bootflow_image
> > >     fname, mnt = setup_image(cons, mmc_dev, 0xc, second_part=True)
> > > test/py/tests/test_ut.py:45: in setup_image
> > >     u_boot_utils.run_and_log(cons, 'sudo sfdisk %s' % fname,
> > > test/py/u_boot_utils.py:180: in run_and_log
> > >     output = runner.run(cmd, ignore_errors=ignore_errors, stdin=stdin)
> > > test/py/multiplexed_log.py:182: in run
> > >     raise exception
> > > E   ValueError: Exit code: 1
> > > ------------------------------------ Captured stdout call -------------------------------------
> > > +qemu-img create /home/trini/work/u-boot/u-boot/mmc1.img 20M
> > > Formatting '/home/trini/work/u-boot/u-boot/mmc1.img', fmt=raw size=20971520
> > > +sudo sfdisk /home/trini/work/u-boot/u-boot/mmc1.img
> > > Checking that no-one is using this disk right now ... OK
> > >
> > > Disk /home/trini/work/u-boot/u-boot/mmc1.img: 20 MiB, 20971520 bytes, 40960 sectors
> > > Units: sectors of 1 * 512 = 512 bytes
> > > Sector size (logical/physical): 512 bytes / 512 bytes
> > > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > >
> > > >>> Created a new DOS disklabel with disk identifier 0xab7e7834.
> > > /home/trini/work/u-boot/u-boot/mmc1.img1: Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 18 MiB.
> > > /home/trini/work/u-boot/u-boot/mmc1.img2: All space for primary partitions is in use.
> >
> > I see this on my Ubuntu 20.04 machine but it doesn't happen on 22.04.
> > Is it a bug in sfdisk? What version are you using?
> >
> > Works: 2.37.2-4ubuntu3
> > Fails: 2.34-0.1ubuntu9.3
> >
> > Do you see this in CI at all?
>
> Ah, so that's the fun part of this then.  Yes, CI is fine since it's on
> 22.04, but my workstation is on 20.04, and so fails. Doing a quick try
> and running sandbox tests in Docker on my workstation does have the
> series passing. So, the series is fine, but I need to adjust my local
> flow a little bit now.

OK ta.

Yes I actually only found that out when I tried it on another machine
this morning. It was a surprise, but a bit of fiddling made me suspect
it is a bug, e.g. that it doesn't allow partitions as small as 2MB?

Regards,
Simon