Re: [PULL 18/42] tests: avocado: boot_linux_console: Add test case for bpim2u

From: Peter Maydell <peter.maydell@linaro.org>
To: Thomas Huth <thuth@redhat.com>
Cc: qianfan <qianfanguijin@163.com>,
	qemu-devel@nongnu.org,
	"Niek Linnenbank" <nieklinnenbank@gmail.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Guenter Roeck" <linux@roeck-us.net>
Subject: Re: [PULL 18/42] tests: avocado: boot_linux_console: Add test case for bpim2u
Date: Mon, 3 Jul 2023 12:14:26 +0100	[thread overview]
Message-ID: <CAFEAcA_3a7jzFQDg9G3uuBcayE1DRDYN2yjt=6xcrRU67j91CA@mail.gmail.com> (raw)
In-Reply-To: <091ce590-1499-1aea-9cfa-67e4035615b4@redhat.com>

On Fri, 30 Jun 2023 at 16:45, Thomas Huth <thuth@redhat.com> wrote:
>
> On 30/06/2023 11.04, qianfan wrote:
> >
> >
> > 在 2023/6/30 16:53, Thomas Huth 写道:
> >> On 30/06/2023 10.45, qianfan wrote:
> >>>
> >>>
> >>> 在 2023/6/30 15:27, Thomas Huth 写道:
> >>>> On 30/06/2023 08.15, qianfan wrote:
> >>>>>
> >>>>>
> >>>>> 在 2023/6/29 19:35, Thomas Huth 写道:
> >>>>>> On 06/06/2023 11.47, Peter Maydell wrote:
> >>>>>>> From: qianfan Zhao <qianfanguijin@163.com>
> >>>>>>>
> >>>>>>> Add test case for booting from initrd and sd card.
> ...
> >>>>>>
> >>>>>> FYI, the test_arm_bpim2u_gmac test just failed during one of my CI runs:
> >>>>>>
> >>>>>> https://gitlab.com/thuth/qemu/-/jobs/4565108610#L300
> ...
> >>>> Oh, that's ugly, I think the problem is likely that the numbering
> >>>> of device names that are directly in /dev/ is never guaranteed by
> >>>> the Linux kernel.
> >>>>
> >>>> Could you please try whether this work more reliably for you
> >>>> instead:
> >>>>
> >>>> diff a/tests/avocado/boot_linux_console.py
> >>>> b/tests/avocado/boot_linux_console.py
> >>>> --- a/tests/avocado/boot_linux_console.py
> >>>> +++ b/tests/avocado/boot_linux_console.py
> >>>> @@ -869,7 +869,7 @@ def test_arm_bpim2u_gmac(self):
> >>>>          self.vm.set_console()
> >>>>          kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
> >>>>                                 'console=ttyS0,115200 '
> >>>> -                               'root=/dev/mmcblk0 rootwait rw '
> >>>> +                               'root=b300 rootwait rw '
> >>>>                                 'panic=-1 noreboot')
> >>>>          self.vm.add_args('-kernel', kernel_path,
> >>>>                           '-dtb', dtb_path,
> >>>>
> >>>> ?
> >>> Yes, this patch is useful.
> >>>
> >>> The rootfs can mount successful even if the mmc block enumed as mmcblk1,
> >>> next is the
> >>> kernel logs:
> >>>
> >>> mmc1: new high speed SD card at address 4567
> >>> mmcblk1: mmc1:4567 QEMU! 64.0 MiB
> >>> EXT4-fs (mmcblk1): mounting ext2 file system using the ext4 subsystem
> >>> EXT4-fs (mmcblk1): mounted filesystem without journal. Opts: (null)
> >>> VFS: Mounted root (ext2 filesystem) on device 179:0.
> >>
> >> Great!
> >>
> >>> But the test scripts still fail due to it always waiting mmc0blk:
> >>>
> >>>      exec_command_and_wait_for_pattern(self, 'cat /proc/partitions',
> >>> 'mmcblk0')
> >>
> >> Ok, so the "0" likely got to be dropped here?
> >>
> >>> Could you please explain where is the "b300" come from?
> >>
> >> I ran the kernel once without the "root=/dev/mmcblk0 rootwait"
> >> part in its command line. Then it prints out something like this:
> >>
> >>  VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
> >>  Please append a correct "root=" boot option; here are the available
> >> partitions:
> >>  0100            4096 ram0
> >>  (driver?)
> >>  0101            4096 ram1
> >>  (driver?)
> >>  0102            4096 ram2
> >>  (driver?)
> >>  0103            4096 ram3
> >>  (driver?)
> >>  b300           65536 mmcblk0
> >>  driver: mmcblk
> >>  Kernel panic - not syncing: VFS: Unable to mount root fs on
> >> unknown-block(0,0)
> >>
> >> Seems like the "b300" is stable here, no matter whether
> >> its mmcblk0 or mmcblk1.
> > This way is really hack.
>
> Ack, it's not really nice - but it's still better than a flaky, unreliable
> test, isn't it?
>
> I'll send it as a proper patch for discussion.
>
> > And who case this issue, linux kernel or qemu? I
> > can't make sure.
>
> It's likely the Linux kernel - I think the numbering of entries in /dev/ is
> not guaranteed.

See the thread
https://lore.kernel.org/qemu-devel/01087628-44c0-2b15-61bc-8677b7d1b459@roeck-us.net/
where Guenter concluded that this is a bug in the device tree:
it tells the kernel to probe all 3 MMC controllers in parallel
and doesn't give them specific names, so the order is always
random.

The fix is probably for the kernel to update its DT and then
our test case can be updated to use a fixed DT.

thanks
-- PMM