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

Tom Rini trini at konsulko.com
Tue Jan 24 19:27:58 CET 2023


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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230124/58cfacbc/attachment.sig>


More information about the U-Boot mailing list