[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Issues on Zen4 (hw12) runner
On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-Górecki wrote: > On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monné wrote: > > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki wrote: > > > Hi, > > > > > > I wanted to post another revision of the series adding hw12 runner, > > > hoping that all known issues are fixed now, but unfortunately there is > > > still something broken. I've rebased my series on top of staging > > > (ed9488a0d) and got this pipeline: > > > > > > https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1807819142 > > > (note due to some added debugging, some tests are incorrectly marked as > > > success even if they failed...) > > > > > > 1. USB ethernet doesn't work on PVH dom0: > > > https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739 > > > There supposed to be an USB ethernet device connected to the USB > > > controller at c3:00.4. In the PV dom0 case it's detected as: > > > > > > [ 3.911555] usb 7-1.4: new high-speed USB device number 3 using > > > xhci_hcd > > > [ 4.004201] usb 7-1.4: New USB device found, idVendor=0bda, > > > idProduct=8153, bcdDevice=30.00 > > > [ 4.004675] usb 7-1.4: New USB device strings: Mfr=1, Product=2, > > > SerialNumber=6 > > > [ 4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN > > > [ 4.005349] usb 7-1.4: Manufacturer: Realtek > > > [ 4.005599] usb 7-1.4: SerialNumber: 684D35 > > > > > > But it's not there on PVH. The USB controller itself is detected, just > > > not device(s) connected to it. This applies to other controllers too > > > (there should be about 3 or 4 other USB devices - none of them show up). > > > > > > 2. There is a bunch of "unhandled memory read" errors during PVH dom0 > > > startup: > > > https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739 > > > > > > (XEN) [ 4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory > > > read from 0xfedc0020 size 1 > > > (XEN) [ 4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory > > > read from 0xfedc0021 size 1 > > > (XEN) [ 4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory > > > read from 0xfedc0020 size 1 > > > (XEN) [ 4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory > > > read from 0xfedc0021 size 1 > > > ... > > > > > > This repeats several times. Could be related to the USB issue above? > > > > Can you try with dom0=pf-fixup? Those unhandled accesses might be the > > cause of the USB issues. > > It did got rid of those messages, but USB still doesn't work: > https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/10006580289 Hm, is it possible that the usage of console=xhci is interfering with USB devices? Could you try to boot without console=xhci and see if you can still reproduce the issue? You will need the physical device by your side, which I'm not sure it's possible. Don't know if you host those remotely somewhere. > > > There is also, likely related: > > > > > > (XEN) [ 5.002036] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ > > > 2484: unsupported address 0 > > > (XEN) [ 5.002365] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ > > > 2484: unsupported address 0 > > > (XEN) [ 5.002693] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ > > > 2484: unsupported address 0 > > > > Is this at shutdown? (doesn't look like by the timestamps). There are > > cases where Linux zeroes the MSR entries while the capability is still > > enabled, and that results in those messages. They are usually benign. > > That's not shutdown. But also it's a different device than I care the > most, so I guess I can ignore it for now. Even if you see those messages the device might work OK - it's just that at some point Linux has set the MSI address field as 0. Xen won't print anything when the address is switched from 0 (invalid) to a valid value. Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |