|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
Hi Julien,
thank for your patch -- just like Corey I tried it out and it seems to
work fine and gets
me further. At this point, I'm pretty sure I'm past initial
bootstrapping issues and into
what can be basically described as Xen DMA issue of some kind (so I'm
pretty sure
I will need Stefano's help to debug this further). I'm attaching
verbose logs, but the
culprit seems to be:
[ 2.534292] Unable to handle kernel paging request at virtual
address 000000000026c340
[ 2.542373] Mem abort info:
[ 2.545257] ESR = 0x96000004
[ 2.548421] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2.553877] SET = 0, FnV = 0
[ 2.557023] EA = 0, S1PTW = 0
[ 2.560297] Data abort info:
[ 2.563258] ISV = 0, ISS = 0x00000004
[ 2.567208] CM = 0, WnR = 0
[ 2.570294] [000000000026c340] user address but active_mm is swapper
[ 2.576783] Internal error: Oops: 96000004 [#1] SMP
[ 2.581784] Modules linked in:
[ 2.584950] CPU: 3 PID: 135 Comm: kworker/3:1 Not tainted 5.6.1-default #9
[ 2.591970] Hardware name: Raspberry Pi 4 Model B (DT)
[ 2.597256] Workqueue: events deferred_probe_work_func
[ 2.602509] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 2.607431] pc : xen_swiotlb_free_coherent+0x198/0x1d8
[ 2.612696] lr : dma_free_attrs+0x98/0xd0
[ 2.616827] sp : ffff800011db3970
[ 2.620242] x29: ffff800011db3970 x28: 00000000000f7b00
[ 2.625695] x27: 0000000000001000 x26: ffff000037b68410
[ 2.631129] x25: 0000000000000001 x24: 00000000f7b00000
[ 2.636583] x23: 0000000000000000 x22: 0000000000000000
[ 2.642017] x21: ffff800011b0d000 x20: ffff80001179b548
[ 2.647461] x19: ffff000037b68410 x18: 0000000000000010
[ 2.652905] x17: ffff000035d66a00 x16: 00000000deadbeef
[ 2.658348] x15: ffffffffffffffff x14: ffff80001179b548
[ 2.663792] x13: ffff800091db37b7 x12: ffff800011db37bf
[ 2.669236] x11: ffff8000117c7000 x10: ffff800011db3740
[ 2.674680] x9 : 00000000ffffffd0 x8 : ffff80001071e980
[ 2.680124] x7 : 0000000000000132 x6 : ffff80001197a6ab
[ 2.685568] x5 : 0000000000000000 x4 : 0000000000000000
[ 2.691012] x3 : 00000000f7b00000 x2 : fffffdffffe00000
[ 2.696465] x1 : 000000000026c340 x0 : 000002000046c340
[ 2.701899] Call trace:
[ 2.704452] xen_swiotlb_free_coherent+0x198/0x1d8
[ 2.709367] dma_free_attrs+0x98/0xd0
[ 2.713143] rpi_firmware_property_list+0x1e4/0x240
[ 2.718146] rpi_firmware_property+0x6c/0xb0
[ 2.722535] rpi_firmware_probe+0xf0/0x1e0
[ 2.726760] platform_drv_probe+0x50/0xa0
[ 2.730879] really_probe+0xd8/0x438
[ 2.734567] driver_probe_device+0xdc/0x130
[ 2.738870] __device_attach_driver+0x88/0x108
[ 2.743434] bus_for_each_drv+0x78/0xc8
[ 2.747386] __device_attach+0xd4/0x158
[ 2.751337] device_initial_probe+0x10/0x18
[ 2.755649] bus_probe_device+0x90/0x98
[ 2.759590] deferred_probe_work_func+0x88/0xd8
[ 2.764244] process_one_work+0x1f0/0x3c0
[ 2.768369] worker_thread+0x138/0x570
[ 2.772234] kthread+0x118/0x120
[ 2.775571] ret_from_fork+0x10/0x18
[ 2.779263] Code: d34cfc00 f2dfbfe2 d37ae400 8b020001 (f8626800)
[ 2.785492] ---[ end trace 4c435212e349f45f ]---
[ 2.793340] usb 1-1: New USB device found, idVendor=2109,
idProduct=3431, bcdDevice= 4.20
[ 2.801038] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 2.808297] usb 1-1: Product: USB2.0 Hub
[ 2.813710] hub 1-1:1.0: USB hub found
[ 2.817117] hub 1-1:1.0: 4 ports detected
This is bailing out right here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/firmware/raspberrypi.c?h=v5.6.1#n125
FYIW (since I modified the source to actually print what was returned
right before it bails) we get:
buf[1] == 0x800000004
buf[2] == 0x00000001
Status 0x800000004 is of course suspicious since it is not even listed here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/soc/bcm2835/raspberrypi-firmware.h#n14
So it appears that this DMA request path is somehow busted and it
would be really nice to figure out why.
Thanks,
Roman.
On Mon, May 4, 2020 at 5:44 AM Corey Minyard <minyard@xxxxxxx> wrote:
>
> On Sat, May 02, 2020 at 06:48:27PM +0100, Julien Grall wrote:
> >
> >
> > On 02/05/2020 18:35, Corey Minyard wrote:
> > > On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote:
> > > No. If I am understanding this correctly, all the memory in dom0 below
> > > 1GB would have to be physically below 1GB.
> >
> > Well, dom0 is directly mapped. In other word, dom0 physical address == host
> > physical address. So if we allocate memory below 1GB in Xen, then it will
> > mapped below 1GB on dom0 as well.
> >
> > The patch I suggested would try to allocate as much as possible memory below
> > 1GB. I believe this should do the trick for you here.
>
> Yes, that does seem to do the trick:
>
> root@raspberrypi4-64-xen:~# xl info
> host : raspberrypi4-64-xen
> release : 4.19.115-v8
> version : #1 SMP PREEMPT Thu Apr 16 13:53:57 UTC 2020
> machine : aarch64
> nr_cpus : 4
> max_cpu_id : 3
> nr_nodes : 1
> cores_per_socket : 1
> threads_per_core : 1
> cpu_mhz : 54.000
> hw_caps :
> 00000000:00000000:00000000:00000000:00000000:00000000:00000000:00000000
> virt_caps : hvm hap
> total_memory : 3956
> free_memory : 3634
> sharing_freed_memory : 0
> sharing_used_memory : 0
> outstanding_claims : 0
> free_cpus : 0
> xen_major : 4
> xen_minor : 13
> xen_extra : .0
> xen_version : 4.13.0
> xen_caps : xen-3.0-aarch64 xen-3.0-armv7l
> xen_scheduler : credit2
> xen_pagesize : 4096
> platform_params : virt_start=0x200000
> xen_changeset : Tue Dec 17 14:19:49 2019 +0000 git:a2e84d8e42-dirty
> xen_commandline : console=dtuart dtuart=/soc/serial@7e215040
> sync_console dom0_mem=256M bootscrub=0
> cc_compiler : aarch64-montavista-linux-gcc (GCC) 9.3.0
> cc_compile_by : xen-4.13+gitAUT
> cc_compile_domain : mvista-cgx
> cc_compile_date : 2019-12-17
> build_id : b0e9b4af9d83f67953e1640976f0720452a88f6a
> xend_config_format : 4
>
> Thanks for the fix.
>
> -corey
>
> >
> > Cheers,
> >
> > --
> > Julien Grall
Attachment:
xen.verbose.log
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |