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 <qianfangui...@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
