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

[Thomas Huth <thuth@redhat.com>]

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.

  Thomas