Re: Problem with creating a root device

[roger]

On 21/09/2020 10:00, Peter Maydell wrote:

> What is the failure mode here? Does the guest kernel identify
> that there is a virtio-blk device on the PCI bus? If not,
> probably the problem is that the kernel doesn't have the
> necessary virtio drivers built in -- you could fix that if
> you're in a position to rebuild the kernel. Or you could try
> the megasas scsi device, which might have a driver in your kernel.
>
>

After sym device driver fails. All the bus probes fail as follows.

sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 66
sym0: No NVRAM, ID 7, Fast-40, ??, parity checking
random: fast init done
CACHE TEST FAILED: timeout.
sym0: CACHE INCORRECTLY CONFIGURED.
sym0: giving up ...
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:337 dma_free_attrs+0xb8/0xc8
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.4.51 #1
Hardware name: ARM-Versatile (Device Tree Support)
[<c001c84c>] (unwind_backtrace) from [<c0018738>] (show_stack+0x10/0x14)
[<c0018738>] (show_stack) from [<c0025588>] (__warn+0xa8/0xd0)
[<c0025588>] (__warn) from [<c0025624>] (warn_slowpath_fmt+0x74/0xa4)
[<c0025624>] (warn_slowpath_fmt) from [<c0066128>] (dma_free_attrs+0xb8/0xc8)
[<c0066128>] (dma_free_attrs) from [<c03c3548>] (___free_dma_mem_cluster+0x68/0x98)
[<c03c3548>] (___free_dma_mem_cluster) from [<c03c3940>] (__sym_mfree_dma+0x40/0xd0)
[<c03c3940>] (__sym_mfree_dma) from [<c03c31d4>] (sym_hcb_free+0x48/0x1a0)
[<c03c31d4>] (sym_hcb_free) from [<c03bcdb4>] (sym_free_resources+0x50/0x70)
[<c03bcdb4>] (sym_free_resources) from [<c03bb94c>] (sym2_probe+0x608/0x8b8)
[<c03bb94c>] (sym2_probe) from [<c02ce538>] (pci_device_probe+0xa4/0x12c)
[<c02ce538>] (pci_device_probe) from [<c0382ec0>] (really_probe+0xdc/0x404)
[<c0382ec0>] (really_probe) from [<c0383448>] (driver_probe_device+0x5c/0x16c)
[<c0383448>] (driver_probe_device) from [<c03837e0>] (device_driver_attach+0xa8/0xb0)
[<c03837e0>] (device_driver_attach) from [<c0383860>] (__driver_attach+0x78/0x10c)
[<c0383860>] (__driver_attach) from [<c0380ef8>] (bus_for_each_dev+0x74/0xbc)
[<c0380ef8>] (bus_for_each_dev) from [<c038223c>] (bus_add_driver+0xec/0x1d4)
[<c038223c>] (bus_add_driver) from [<c03840f0>] (driver_register+0x88/0x118)
[<c03840f0>] (driver_register) from [<c0a8c9bc>] (sym2_init+0xd4/0x12c)
[<c0a8c9bc>] (sym2_init) from [<c000ad24>] (do_one_initcall+0x4c/0x1cc)
[<c000ad24>] (do_one_initcall) from [<c0a75e70>] (kernel_init_freeable+0xfc/0x1bc)
[<c0a75e70>] (kernel_init_freeable) from [<c0609b0c>] (kernel_init+0x8/0xe8)
[<c0609b0c>] (kernel_init) from [<c00090e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xcf825fb0 to 0xcf825ff8)
5fa0:                                     00000000 00000000 00000000 00000000
5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
---[ end trace c4e11c02c3b79133 ]---
------------[ cut here ]------------

The above is repeated 5 times as different bus probes fail. There are no more log entries related to block device in initialisation, and no real devices listed in the partition list shown when the root mount fails.

FS: Cannot open root device "vda2" or unknown-block(254,2): 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?)
0104            4096 ram4 
 (driver?)
0105            4096 ram5 
 (driver?)
0106            4096 ram6 
 (driver?)
0107            4096 ram7 
 (driver?)
0108            4096 ram8 
 (driver?)
0109            4096 ram9 
 (driver?)
010a            4096 ram10 
 (driver?)
010b            4096 ram11 
 (driver?)
010c            4096 ram12 
 (driver?)
010d            4096 ram13 
 (driver?)
010e            4096 ram14 
 (driver?)
010f            4096 ram15 
 (driver?)
fe00         1208128 vda 
 driver: virtio_blk
1f00           65536 mtdblock0

The above all appear to be ram devices and the flash memory device.

The good news is that going back one raspberry pi kernel release works perfectly! That kernel is a Linux 4 kernel.

So it would appear that this is entirely a Linux 5 kernel issue. I will live the Linux 4 kernel for time being.

I only use the qemu environment for setting up white room testing images.

Roger

> > I think I need to either disable the scsi driver in the kernel, or
> > stop qemu emulating one on the pci bus.
> >       
> My guess is that this won't be necessary -- I think the kernel's
> driver for the scsi card has failed in initialization, which will
> mean the kernel will just act as if the scsi card wasn't there
> at all.
>
> thanks
> -- PMM
>
>