* Console output stops on dbgp=xhci
@ 2022-09-14 18:18 Tamas K Lengyel
2022-09-14 21:57 ` Marek Marczykowski-Górecki
0 siblings, 1 reply; 16+ messages in thread
From: Tamas K Lengyel @ 2022-09-14 18:18 UTC (permalink / raw)
To: Marek Marczykowski-Górecki; +Cc: Xen-devel
Hi Marek,
I'm testing the latest Xen master git branch
(942ac5fc15ecc2f7ef1d9331c76d89d2cef10e5c) with the now merged xue
patches. My current boot command line includes dbgp=xhci@pci00:14.0
console=dbgp and this works in that the Xen boot log shows up on the
other side of the debug cable:
...
(XEN) Dom0 has maximum 8 VCPUs
(XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff82c5cdac
(XEN) ELF: phdr 1 at 0xffffffff82e00000 -> 0xffffffff831a1000
(XEN) ELF: phdr 2 at 0xffffffff831a1000 -> 0xffffffff831d5000
(XEN) ELF: phdr 3 at 0xffffffff831d5000 -> 0xffffffff84000000
However, debug output on the USB3 port stops at this point. I would
expect to see the same as xl dmesg shows:
(XEN) Dom0 has maximum 8 VCPUs
(XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff82c5cdac
(XEN) ELF: phdr 1 at 0xffffffff82e00000 -> 0xffffffff831a1000
(XEN) ELF: phdr 2 at 0xffffffff831a1000 -> 0xffffffff831d5000
(XEN) ELF: phdr 3 at 0xffffffff831d5000 -> 0xffffffff84000000
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM in background
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) Freed 2048kB init memory
...
Do you have any idea what might be going on and preventing the output
from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
present on the receiving side, just nothing is being received over it.
Thanks,
Tamas
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-14 18:18 Console output stops on dbgp=xhci Tamas K Lengyel
@ 2022-09-14 21:57 ` Marek Marczykowski-Górecki
2022-09-15 0:41 ` Tamas K Lengyel
0 siblings, 1 reply; 16+ messages in thread
From: Marek Marczykowski-Górecki @ 2022-09-14 21:57 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Xen-devel
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]
On Wed, Sep 14, 2022 at 02:18:34PM -0400, Tamas K Lengyel wrote:
> Hi Marek,
> I'm testing the latest Xen master git branch
> (942ac5fc15ecc2f7ef1d9331c76d89d2cef10e5c) with the now merged xue
> patches. My current boot command line includes dbgp=xhci@pci00:14.0
> console=dbgp and this works in that the Xen boot log shows up on the
> other side of the debug cable:
>
> ...
>
> (XEN) Dom0 has maximum 8 VCPUs
>
> (XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff82c5cdac
>
> (XEN) ELF: phdr 1 at 0xffffffff82e00000 -> 0xffffffff831a1000
>
> (XEN) ELF: phdr 2 at 0xffffffff831a1000 -> 0xffffffff831d5000
>
> (XEN) ELF: phdr 3 at 0xffffffff831d5000 -> 0xffffffff84000000
>
> However, debug output on the USB3 port stops at this point. I would
> expect to see the same as xl dmesg shows:
>
> (XEN) Dom0 has maximum 8 VCPUs
> (XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff82c5cdac
> (XEN) ELF: phdr 1 at 0xffffffff82e00000 -> 0xffffffff831a1000
> (XEN) ELF: phdr 2 at 0xffffffff831a1000 -> 0xffffffff831d5000
> (XEN) ELF: phdr 3 at 0xffffffff831d5000 -> 0xffffffff84000000
> (XEN) Initial low memory virq threshold set at 0x4000 pages.
> (XEN) Scrubbing Free RAM in background
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
> (XEN) Freed 2048kB init memory
> ...
>
> Do you have any idea what might be going on and preventing the output
> from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
> present on the receiving side, just nothing is being received over it.
There are few more patches in the series that are de facto required.
Especially those about IOMMU, otherwise it can only possibly work with
iommu=0 (which I'm not sure if even is enough).
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-14 21:57 ` Marek Marczykowski-Górecki
@ 2022-09-15 0:41 ` Tamas K Lengyel
2022-09-15 1:28 ` Marek Marczykowski-Górecki
2022-09-15 7:55 ` Jan Beulich
0 siblings, 2 replies; 16+ messages in thread
From: Tamas K Lengyel @ 2022-09-15 0:41 UTC (permalink / raw)
To: Marek Marczykowski-Górecki; +Cc: Xen-devel
> > Do you have any idea what might be going on and preventing the output
> > from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
> > present on the receiving side, just nothing is being received over it.
>
> There are few more patches in the series that are de facto required.
> Especially those about IOMMU, otherwise it can only possibly work with
> iommu=0 (which I'm not sure if even is enough).
Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
on the console:
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0011]
(XEN) Faulting linear address: 00000000328b3a54
Not sure what's up with that. Either way, can you post a git branch
with the remaining patches that are not yet merged in master? Want to
check if those patches resolve the issue.
Thanks,
Tamas
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-15 0:41 ` Tamas K Lengyel
@ 2022-09-15 1:28 ` Marek Marczykowski-Górecki
2022-09-15 7:55 ` Jan Beulich
1 sibling, 0 replies; 16+ messages in thread
From: Marek Marczykowski-Górecki @ 2022-09-15 1:28 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Xen-devel
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On Wed, Sep 14, 2022 at 08:41:59PM -0400, Tamas K Lengyel wrote:
> > > Do you have any idea what might be going on and preventing the output
> > > from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
> > > present on the receiving side, just nothing is being received over it.
> >
> > There are few more patches in the series that are de facto required.
> > Especially those about IOMMU, otherwise it can only possibly work with
> > iommu=0 (which I'm not sure if even is enough).
>
> Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
> on the console:
>
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0011]
> (XEN) Faulting linear address: 00000000328b3a54
>
> Not sure what's up with that. Either way, can you post a git branch
> with the remaining patches that are not yet merged in master? Want to
> check if those patches resolve the issue.
I keep it at https://github.com/marmarek/xen/tree/master-xue
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-15 0:41 ` Tamas K Lengyel
2022-09-15 1:28 ` Marek Marczykowski-Górecki
@ 2022-09-15 7:55 ` Jan Beulich
2022-09-15 14:05 ` Tamas K Lengyel
1 sibling, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2022-09-15 7:55 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Xen-devel, Marek Marczykowski-Górecki
On 15.09.2022 02:41, Tamas K Lengyel wrote:
>>> Do you have any idea what might be going on and preventing the output
>>> from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
>>> present on the receiving side, just nothing is being received over it.
>>
>> There are few more patches in the series that are de facto required.
>> Especially those about IOMMU, otherwise it can only possibly work with
>> iommu=0 (which I'm not sure if even is enough).
>
> Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
> on the console:
>
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0011]
> (XEN) Faulting linear address: 00000000328b3a54
Perhaps in another thread, could you post details about this? I guess
we want to address this independent of your XHCI issue. That's an
attempt to execute code outside of the Xen image - the only reason I
can think of for this would be an EFI boot services or runtime
services call, with (possibly but not necessarily) quirky EFI firmware.
Any other context this is appearing in would quite certainly require a
fix in Xen, and I don't see how "iommu=0" could affect the set of EFI
calls we make.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-15 7:55 ` Jan Beulich
@ 2022-09-15 14:05 ` Tamas K Lengyel
2022-09-15 14:10 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Tamas K Lengyel @ 2022-09-15 14:05 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel, Marek Marczykowski-Górecki
On Thu, Sep 15, 2022 at 3:56 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 15.09.2022 02:41, Tamas K Lengyel wrote:
> >>> Do you have any idea what might be going on and preventing the output
> >>> from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
> >>> present on the receiving side, just nothing is being received over it.
> >>
> >> There are few more patches in the series that are de facto required.
> >> Especially those about IOMMU, otherwise it can only possibly work with
> >> iommu=0 (which I'm not sure if even is enough).
> >
> > Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
> > on the console:
> >
> > (XEN) Panic on CPU 0:
> > (XEN) FATAL PAGE FAULT
> > (XEN) [error_code=0011]
> > (XEN) Faulting linear address: 00000000328b3a54
>
> Perhaps in another thread, could you post details about this? I guess
> we want to address this independent of your XHCI issue. That's an
> attempt to execute code outside of the Xen image - the only reason I
> can think of for this would be an EFI boot services or runtime
> services call, with (possibly but not necessarily) quirky EFI firmware.
> Any other context this is appearing in would quite certainly require a
> fix in Xen, and I don't see how "iommu=0" could affect the set of EFI
> calls we make.
This was indeed observed with a xen.efi booted directly from UEFI.
Beside the limited boot log I get through xhci I don't have more
insight but happy to send that (and anything else you think would be
useful).
Tamas
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-15 14:05 ` Tamas K Lengyel
@ 2022-09-15 14:10 ` Jan Beulich
2022-09-15 14:16 ` Tamas K Lengyel
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2022-09-15 14:10 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Xen-devel, Marek Marczykowski-Górecki
On 15.09.2022 16:05, Tamas K Lengyel wrote:
> On Thu, Sep 15, 2022 at 3:56 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 15.09.2022 02:41, Tamas K Lengyel wrote:
>>>>> Do you have any idea what might be going on and preventing the output
>>>>> from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
>>>>> present on the receiving side, just nothing is being received over it.
>>>>
>>>> There are few more patches in the series that are de facto required.
>>>> Especially those about IOMMU, otherwise it can only possibly work with
>>>> iommu=0 (which I'm not sure if even is enough).
>>>
>>> Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
>>> on the console:
>>>
>>> (XEN) Panic on CPU 0:
>>> (XEN) FATAL PAGE FAULT
>>> (XEN) [error_code=0011]
>>> (XEN) Faulting linear address: 00000000328b3a54
>>
>> Perhaps in another thread, could you post details about this? I guess
>> we want to address this independent of your XHCI issue. That's an
>> attempt to execute code outside of the Xen image - the only reason I
>> can think of for this would be an EFI boot services or runtime
>> services call, with (possibly but not necessarily) quirky EFI firmware.
>> Any other context this is appearing in would quite certainly require a
>> fix in Xen, and I don't see how "iommu=0" could affect the set of EFI
>> calls we make.
>
> This was indeed observed with a xen.efi booted directly from UEFI.
> Beside the limited boot log I get through xhci I don't have more
> insight but happy to send that (and anything else you think would be
> useful).
And with "iommu=0" but no use of XHCI it doesn't crash? Or there you have
no way to collect the log then?
In any event, from your description the interesting part might be the
EFI memory map. That ought to be pretty stable between boots, so you may
be able to collect that in full via "xl dmesg" in a run without "iommu=0".
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-15 14:10 ` Jan Beulich
@ 2022-09-15 14:16 ` Tamas K Lengyel
2022-09-15 14:39 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Tamas K Lengyel @ 2022-09-15 14:16 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel, Marek Marczykowski-Górecki
On Thu, Sep 15, 2022 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 15.09.2022 16:05, Tamas K Lengyel wrote:
> > On Thu, Sep 15, 2022 at 3:56 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 15.09.2022 02:41, Tamas K Lengyel wrote:
> >>>>> Do you have any idea what might be going on and preventing the output
> >>>>> from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
> >>>>> present on the receiving side, just nothing is being received over it.
> >>>>
> >>>> There are few more patches in the series that are de facto required.
> >>>> Especially those about IOMMU, otherwise it can only possibly work with
> >>>> iommu=0 (which I'm not sure if even is enough).
> >>>
> >>> Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
> >>> on the console:
> >>>
> >>> (XEN) Panic on CPU 0:
> >>> (XEN) FATAL PAGE FAULT
> >>> (XEN) [error_code=0011]
> >>> (XEN) Faulting linear address: 00000000328b3a54
> >>
> >> Perhaps in another thread, could you post details about this? I guess
> >> we want to address this independent of your XHCI issue. That's an
> >> attempt to execute code outside of the Xen image - the only reason I
> >> can think of for this would be an EFI boot services or runtime
> >> services call, with (possibly but not necessarily) quirky EFI firmware.
> >> Any other context this is appearing in would quite certainly require a
> >> fix in Xen, and I don't see how "iommu=0" could affect the set of EFI
> >> calls we make.
> >
> > This was indeed observed with a xen.efi booted directly from UEFI.
> > Beside the limited boot log I get through xhci I don't have more
> > insight but happy to send that (and anything else you think would be
> > useful).
>
> And with "iommu=0" but no use of XHCI it doesn't crash? Or there you have
> no way to collect the log then?
>
> In any event, from your description the interesting part might be the
> EFI memory map. That ought to be pretty stable between boots, so you may
> be able to collect that in full via "xl dmesg" in a run without "iommu=0".
I see the same crash with no xhci debug use. The EFI map is:
(XEN) EFI memory map:
(XEN) 0000000000000-000000009bfff type=7 attr=000000000000000f
(XEN) 000000009c000-000000009dfff type=2 attr=000000000000000f
(XEN) 000000009e000-000000009efff type=0 attr=000000000000000f
(XEN) 000000009f000-000000009ffff type=4 attr=000000000000000f
(XEN) 0000000100000-00000175a6fff type=7 attr=000000000000000f
(XEN) 00000175a7000-00000175e6fff type=4 attr=000000000000000f
(XEN) 00000175e7000-0000021e9efff type=7 attr=000000000000000f
(XEN) 0000021e9f000-0000028587fff type=2 attr=000000000000000f
(XEN) 0000028588000-000002ab79fff type=1 attr=000000000000000f
(XEN) 000002ab7a000-000002bcd7fff type=7 attr=000000000000000f
(XEN) 000002bcd8000-000002c6cafff type=2 attr=000000000000000f
(XEN) 000002c6cb000-000002cd8cfff type=4 attr=000000000000000f
(XEN) 000002cd8d000-000002cdcefff type=7 attr=000000000000000f
(XEN) 000002cdcf000-000002ce77fff type=4 attr=000000000000000f
(XEN) 000002ce78000-000002ced4fff type=7 attr=000000000000000f
(XEN) 000002ced5000-000002ced7fff type=4 attr=000000000000000f
(XEN) 000002ced8000-000002cedafff type=7 attr=000000000000000f
(XEN) 000002cedb000-000002cedcfff type=4 attr=000000000000000f
(XEN) 000002cedd000-000002ceddfff type=7 attr=000000000000000f
(XEN) 000002cede000-000002e179fff type=4 attr=000000000000000f
(XEN) 000002e17a000-000002e194fff type=3 attr=000000000000000f
(XEN) 000002e195000-000002e1bffff type=4 attr=000000000000000f
(XEN) 000002e1c0000-000002e1c9fff type=3 attr=000000000000000f
(XEN) 000002e1ca000-000002e1e3fff type=4 attr=000000000000000f
(XEN) 000002e1e4000-000002e1edfff type=3 attr=000000000000000f
(XEN) 000002e1ee000-000002e1f2fff type=4 attr=000000000000000f
(XEN) 000002e1f3000-000002e20dfff type=3 attr=000000000000000f
(XEN) 000002e20e000-000002e22cfff type=4 attr=000000000000000f
(XEN) 000002e22d000-000002e22efff type=3 attr=000000000000000f
(XEN) 000002e22f000-000002e233fff type=4 attr=000000000000000f
(XEN) 000002e234000-000002e236fff type=3 attr=000000000000000f
(XEN) 000002e237000-000002e23dfff type=4 attr=000000000000000f
(XEN) 000002e23e000-000002e23ffff type=3 attr=000000000000000f
(XEN) 000002e240000-000002e245fff type=4 attr=000000000000000f
(XEN) 000002e246000-000002e246fff type=3 attr=000000000000000f
(XEN) 000002e247000-000002e24bfff type=4 attr=000000000000000f
(XEN) 000002e24c000-000002e250fff type=3 attr=000000000000000f
(XEN) 000002e251000-000002e26afff type=4 attr=000000000000000f
(XEN) 000002e26b000-000002e29dfff type=3 attr=000000000000000f
(XEN) 000002e29e000-000002e2d4fff type=4 attr=000000000000000f
(XEN) 000002e2d5000-000002e2d5fff type=3 attr=000000000000000f
(XEN) 000002e2d6000-000002e2e6fff type=4 attr=000000000000000f
(XEN) 000002e2e7000-000002e2e7fff type=3 attr=000000000000000f
(XEN) 000002e2e8000-000002e2f8fff type=4 attr=000000000000000f
(XEN) 000002e2f9000-000002e2fbfff type=3 attr=000000000000000f
(XEN) 000002e2fc000-000002e30efff type=4 attr=000000000000000f
(XEN) 000002e30f000-000002e30ffff type=3 attr=000000000000000f
(XEN) 000002e310000-000002e320fff type=4 attr=000000000000000f
(XEN) 000002e321000-000002e340fff type=3 attr=000000000000000f
(XEN) 000002e341000-000002e341fff type=4 attr=000000000000000f
(XEN) 000002e342000-000002e352fff type=3 attr=000000000000000f
(XEN) 000002e353000-000002e3edfff type=4 attr=000000000000000f
(XEN) 000002e3ee000-000002e3f4fff type=3 attr=000000000000000f
(XEN) 000002e3f5000-000002e40bfff type=4 attr=000000000000000f
(XEN) 000002e40c000-000002e417fff type=3 attr=000000000000000f
(XEN) 000002e418000-000002e42efff type=4 attr=000000000000000f
(XEN) 000002e42f000-000002e42ffff type=3 attr=000000000000000f
(XEN) 000002e430000-000002e440fff type=4 attr=000000000000000f
(XEN) 000002e441000-000002e444fff type=3 attr=000000000000000f
(XEN) 000002e445000-000002f56cfff type=4 attr=000000000000000f
(XEN) 000002f56d000-000002f588fff type=3 attr=000000000000000f
(XEN) 000002f589000-0000031ca5fff type=4 attr=000000000000000f
(XEN) 0000031ca6000-0000031f71fff type=7 attr=000000000000000f
(XEN) 0000031f72000-0000032a95fff type=3 attr=000000000000000f
(XEN) 0000032a96000-0000034f95fff type=0 attr=000000000000000f
(XEN) 0000034f96000-0000035215fff type=9 attr=000000000000000f
(XEN) 0000035216000-0000035323fff type=10 attr=000000000000000f
(XEN) 0000035324000-0000035efefff type=6 attr=800000000000000f
(XEN) 0000035eff000-0000035ffefff type=5 attr=800000000000000f
(XEN) 0000035fff000-0000035ffffff type=4 attr=000000000000000f
(XEN) 0000100000000-00008c07fffff type=7 attr=000000000000000f
(XEN) 00000000a0000-00000000fffff type=0 attr=0000000000000000
(XEN) 0000036000000-0000039ffffff type=0 attr=000000000000000f
(XEN) 000003a000000-000003affffff type=0 attr=0000000000000009
(XEN) 000003b000000-000003f7fffff type=0 attr=0000000000000000
(XEN) 00000e0000000-00000efffffff type=11 attr=8000000000000001
(XEN) 00000fc000000-00000fc01ffff type=11 attr=800000000000100d
(XEN) 00000fe000000-00000fe010fff type=11 attr=8000000000000001
(XEN) 00000fec00000-00000fec00fff type=11 attr=8000000000000001
(XEN) 00000fed00000-00000fed00fff type=11 attr=8000000000000001
(XEN) 00000fed20000-00000fed7ffff type=0 attr=0000000000000000
(XEN) 00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN) 00000ff000000-00000ffffffff type=11 attr=800000000000100d
(XEN) alt table ffff82d0406953b0 -> ffff82d040697686
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-15 14:16 ` Tamas K Lengyel
@ 2022-09-15 14:39 ` Jan Beulich
2022-09-15 16:48 ` Tamas K Lengyel
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2022-09-15 14:39 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Xen-devel, Marek Marczykowski-Górecki
On 15.09.2022 16:16, Tamas K Lengyel wrote:
> On Thu, Sep 15, 2022 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 15.09.2022 16:05, Tamas K Lengyel wrote:
>>> On Thu, Sep 15, 2022 at 3:56 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 15.09.2022 02:41, Tamas K Lengyel wrote:
>>>>>>> Do you have any idea what might be going on and preventing the output
>>>>>>> from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
>>>>>>> present on the receiving side, just nothing is being received over it.
>>>>>>
>>>>>> There are few more patches in the series that are de facto required.
>>>>>> Especially those about IOMMU, otherwise it can only possibly work with
>>>>>> iommu=0 (which I'm not sure if even is enough).
>>>>>
>>>>> Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
>>>>> on the console:
>>>>>
>>>>> (XEN) Panic on CPU 0:
>>>>> (XEN) FATAL PAGE FAULT
>>>>> (XEN) [error_code=0011]
>>>>> (XEN) Faulting linear address: 00000000328b3a54
>>>>
>>>> Perhaps in another thread, could you post details about this? I guess
>>>> we want to address this independent of your XHCI issue. That's an
>>>> attempt to execute code outside of the Xen image - the only reason I
>>>> can think of for this would be an EFI boot services or runtime
>>>> services call, with (possibly but not necessarily) quirky EFI firmware.
>>>> Any other context this is appearing in would quite certainly require a
>>>> fix in Xen, and I don't see how "iommu=0" could affect the set of EFI
>>>> calls we make.
>>>
>>> This was indeed observed with a xen.efi booted directly from UEFI.
>>> Beside the limited boot log I get through xhci I don't have more
>>> insight but happy to send that (and anything else you think would be
>>> useful).
>>
>> And with "iommu=0" but no use of XHCI it doesn't crash? Or there you have
>> no way to collect the log then?
>>
>> In any event, from your description the interesting part might be the
>> EFI memory map. That ought to be pretty stable between boots, so you may
>> be able to collect that in full via "xl dmesg" in a run without "iommu=0".
>
> I see the same crash with no xhci debug use. The EFI map is:
>
> (XEN) EFI memory map:
>[...]
> (XEN) 0000031f72000-0000032a95fff type=3 attr=000000000000000f
This is the entry covering the address, which is EfiBootServicesCode
with no unusual attributes. Assuming the crash was still during boot
(of Xen, not Dom0), do you also have at least the full stack walk
from the crash, to know where in Xen the call chain started?
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-15 14:39 ` Jan Beulich
@ 2022-09-15 16:48 ` Tamas K Lengyel
2022-09-16 5:57 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Tamas K Lengyel @ 2022-09-15 16:48 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel, Marek Marczykowski-Górecki
On Thu, Sep 15, 2022 at 10:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 15.09.2022 16:16, Tamas K Lengyel wrote:
> > On Thu, Sep 15, 2022 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 15.09.2022 16:05, Tamas K Lengyel wrote:
> >>> On Thu, Sep 15, 2022 at 3:56 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 15.09.2022 02:41, Tamas K Lengyel wrote:
> >>>>>>> Do you have any idea what might be going on and preventing the output
> >>>>>>> from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
> >>>>>>> present on the receiving side, just nothing is being received over it.
> >>>>>>
> >>>>>> There are few more patches in the series that are de facto required.
> >>>>>> Especially those about IOMMU, otherwise it can only possibly work with
> >>>>>> iommu=0 (which I'm not sure if even is enough).
> >>>>>
> >>>>> Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
> >>>>> on the console:
> >>>>>
> >>>>> (XEN) Panic on CPU 0:
> >>>>> (XEN) FATAL PAGE FAULT
> >>>>> (XEN) [error_code=0011]
> >>>>> (XEN) Faulting linear address: 00000000328b3a54
> >>>>
> >>>> Perhaps in another thread, could you post details about this? I guess
> >>>> we want to address this independent of your XHCI issue. That's an
> >>>> attempt to execute code outside of the Xen image - the only reason I
> >>>> can think of for this would be an EFI boot services or runtime
> >>>> services call, with (possibly but not necessarily) quirky EFI firmware.
> >>>> Any other context this is appearing in would quite certainly require a
> >>>> fix in Xen, and I don't see how "iommu=0" could affect the set of EFI
> >>>> calls we make.
> >>>
> >>> This was indeed observed with a xen.efi booted directly from UEFI.
> >>> Beside the limited boot log I get through xhci I don't have more
> >>> insight but happy to send that (and anything else you think would be
> >>> useful).
> >>
> >> And with "iommu=0" but no use of XHCI it doesn't crash? Or there you have
> >> no way to collect the log then?
> >>
> >> In any event, from your description the interesting part might be the
> >> EFI memory map. That ought to be pretty stable between boots, so you may
> >> be able to collect that in full via "xl dmesg" in a run without "iommu=0".
> >
> > I see the same crash with no xhci debug use. The EFI map is:
> >
> > (XEN) EFI memory map:
> >[...]
> > (XEN) 0000031f72000-0000032a95fff type=3 attr=000000000000000f
>
> This is the entry covering the address, which is EfiBootServicesCode
> with no unusual attributes. Assuming the crash was still during boot
> (of Xen, not Dom0), do you also have at least the full stack walk
> from the crash, to know where in Xen the call chain started?
I don't see a stack walk right now, but it looks like the path to it
is a previous panic that wants to restart the machine:
(XEN) Panic on CPU 0:
(XEN) Couldn't enable IOMMU and iommu=required/force
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN) ----[ Xen-4.17-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<00000000328b3a54>] 00000000328b3a54
(XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor
(XEN) rax: 0000000035efe498 rbx: 0000000035efe4d0 rcx: 0000000000000001
(XEN) rdx: 000000000311100a rsi: 0000000000000000 rdi: 0000000000000001
(XEN) rbp: 0000000000000001 rsp: ffff82d040657b18 r8: 0000000000000000
(XEN) r9: 0000000035fc2080 r10: 0000000000000001 r11: 0c00000000000000
(XEN) r12: 0000000000000000 r13: 000000000311100a r14: 000000000000001f
(XEN) r15: 0000000035fc2080 cr0: 0000000080050033 cr4: 00000000007506e0
(XEN) cr3: 00000008a12ae000 cr2: 00000000328b3a54
(XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen code around <00000000328b3a54> (00000000328b3a54):
(XEN) 49 8b e3 5d c3 cc cc cc <33> c0 c3 cc 40 53 48 83 ec 20 44 8b d1 44 8b da
(XEN) Xen stack trace from rsp=ffff82d040657b18:
(XEN) 0000000035ff6737 ffff82d040657b60 0000000000000046 ffff82d040657b40
(XEN) ffff82d04024f48f 0000000000000000 ffff82d04024f50a 0000000000000000
(XEN) ffff82d040968d40 0000000000000000 0000000035fc2080 ffff82d04041a848
(XEN) ffff82d040930400 0000000000000001 0000000035ff67c9 0000000000000001
(XEN) 000000000311100a 0000000000000000 0000000000000000 0000000000000000
(XEN) ffff82d040922980 0000000000000000 0000000000000000 ffff82d04041a848
(XEN) 0000000035fc18e4 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000035fc15b0 0000000000000000 ffff82d040657fff 0000000000000000
(XEN) 00000000007506e0 000000000000000f 0000000000000000 ffff82d040930400
(XEN) 0000000035fba737 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 ffff82d040657cb0 ffff82d04028332c 0000000000000065
(XEN) ffff82d0402835d6 0000000000000000 ffff82d040657ce8 0000000000000000
(XEN) 00000008a12ae000 0000000028e16000 0000000000000000 000000000000e008
(XEN) 0000000000000287 0000000000000000 ffff82d040657d38 ffff82d04032dbee
(XEN) 0000138840657d48 000082d040657d08 0000000000000000 0000000000000296
(XEN) ffff82d040930400 00000000ffffffff ffff82d04080b400 000000000000000f
(XEN) ffff82d040657da0 ffff82d04024d682 0c00000000000010 ffff82d040657db0
(XEN) ffff82d040657d60 0000000000000000 ffff82d04043f16c 0000000000000001
(XEN) 0000000000171240 0000000000000000 7fffffffffffffff 00000000ffffffed
(XEN) Xen call trace:
(XEN) [<00000000328b3a54>] R 00000000328b3a54
(XEN) [<0000000035ff6737>] S 0000000035ff6737
(XEN)
(XEN) Pagetable walk from 00000000328b3a54:
(XEN) L4[0x000] = 00000008a12ad063 ffffffffffffffff
(XEN) L3[0x000] = 0000000028e0e063 ffffffffffffffff
(XEN) L2[0x194] = 80000000328001e3 ffffffffffffffff (PSE)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0011]
(XEN) Faulting linear address: 00000000328b3a54
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Console output stops on dbgp=xhci
2022-09-15 16:48 ` Tamas K Lengyel
@ 2022-09-16 5:57 ` Jan Beulich
2022-09-16 9:53 ` Default reboot method (was: Re: Console output stops on dbgp=xhci) Marek Marczykowski-Górecki
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2022-09-16 5:57 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Xen-devel, Marek Marczykowski-Górecki
On 15.09.2022 18:48, Tamas K Lengyel wrote:
> On Thu, Sep 15, 2022 at 10:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 15.09.2022 16:16, Tamas K Lengyel wrote:
>>> On Thu, Sep 15, 2022 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 15.09.2022 16:05, Tamas K Lengyel wrote:
>>>>> On Thu, Sep 15, 2022 at 3:56 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 15.09.2022 02:41, Tamas K Lengyel wrote:
>>>>>>>>> Do you have any idea what might be going on and preventing the output
>>>>>>>>> from showing over USB3 afterwards? The /dev/ttyUSB0 device is still
>>>>>>>>> present on the receiving side, just nothing is being received over it.
>>>>>>>>
>>>>>>>> There are few more patches in the series that are de facto required.
>>>>>>>> Especially those about IOMMU, otherwise it can only possibly work with
>>>>>>>> iommu=0 (which I'm not sure if even is enough).
>>>>>>>
>>>>>>> Unfortunately with iommu=0 Xen doesn't boot at all for me. I see this
>>>>>>> on the console:
>>>>>>>
>>>>>>> (XEN) Panic on CPU 0:
>>>>>>> (XEN) FATAL PAGE FAULT
>>>>>>> (XEN) [error_code=0011]
>>>>>>> (XEN) Faulting linear address: 00000000328b3a54
>>>>>>
>>>>>> Perhaps in another thread, could you post details about this? I guess
>>>>>> we want to address this independent of your XHCI issue. That's an
>>>>>> attempt to execute code outside of the Xen image - the only reason I
>>>>>> can think of for this would be an EFI boot services or runtime
>>>>>> services call, with (possibly but not necessarily) quirky EFI firmware.
>>>>>> Any other context this is appearing in would quite certainly require a
>>>>>> fix in Xen, and I don't see how "iommu=0" could affect the set of EFI
>>>>>> calls we make.
>>>>>
>>>>> This was indeed observed with a xen.efi booted directly from UEFI.
>>>>> Beside the limited boot log I get through xhci I don't have more
>>>>> insight but happy to send that (and anything else you think would be
>>>>> useful).
>>>>
>>>> And with "iommu=0" but no use of XHCI it doesn't crash? Or there you have
>>>> no way to collect the log then?
>>>>
>>>> In any event, from your description the interesting part might be the
>>>> EFI memory map. That ought to be pretty stable between boots, so you may
>>>> be able to collect that in full via "xl dmesg" in a run without "iommu=0".
>>>
>>> I see the same crash with no xhci debug use. The EFI map is:
>>>
>>> (XEN) EFI memory map:
>>> [...]
>>> (XEN) 0000031f72000-0000032a95fff type=3 attr=000000000000000f
>>
>> This is the entry covering the address, which is EfiBootServicesCode
>> with no unusual attributes. Assuming the crash was still during boot
>> (of Xen, not Dom0), do you also have at least the full stack walk
>> from the crash, to know where in Xen the call chain started?
>
> I don't see a stack walk right now, but it looks like the path to it
> is a previous panic that wants to restart the machine:
>
> (XEN) Panic on CPU 0:
>
> (XEN) Couldn't enable IOMMU and iommu=required/force
>
> (XEN) ****************************************
Okay, so there's a panic initially, and since it's unlikely that you
passed iommu=force alongside iommu=0, I'd assume it's because of the
IOMMU being needed to support running in x2APIC mode (earlier
messages would tell us). Then ...
> (XEN) Reboot in five seconds...
... this leads to the crash, which effectively tells us that this is
likely yet another system where one needs to override the reboot
method (e.g. reboot=acpi).
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Default reboot method (was: Re: Console output stops on dbgp=xhci)
2022-09-16 5:57 ` Jan Beulich
@ 2022-09-16 9:53 ` Marek Marczykowski-Górecki
2022-09-16 10:28 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Marek Marczykowski-Górecki @ 2022-09-16 9:53 UTC (permalink / raw)
To: Jan Beulich; +Cc: Tamas K Lengyel, Xen-devel
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
> ... this leads to the crash, which effectively tells us that this is
> likely yet another system where one needs to override the reboot
> method (e.g. reboot=acpi).
At least Linux, but also XenServer uses reboot=acpi by default (even on
EFI systems), can we make it default in upstream Xen? Issues with
reboot=efi are rather common, while reboot=acpi just works.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Default reboot method (was: Re: Console output stops on dbgp=xhci)
2022-09-16 9:53 ` Default reboot method (was: Re: Console output stops on dbgp=xhci) Marek Marczykowski-Górecki
@ 2022-09-16 10:28 ` Jan Beulich
2022-09-16 10:55 ` Marek Marczykowski-Górecki
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2022-09-16 10:28 UTC (permalink / raw)
To: Marek Marczykowski-Górecki; +Cc: Tamas K Lengyel, Xen-devel
On 16.09.2022 11:53, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
>> ... this leads to the crash, which effectively tells us that this is
>> likely yet another system where one needs to override the reboot
>> method (e.g. reboot=acpi).
>
> At least Linux, but also XenServer uses reboot=acpi by default (even on
> EFI systems), can we make it default in upstream Xen? Issues with
> reboot=efi are rather common, while reboot=acpi just works.
But rebooting by means other than the EFI runtime service has always been
against the spirit of EFI.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Default reboot method (was: Re: Console output stops on dbgp=xhci)
2022-09-16 10:28 ` Jan Beulich
@ 2022-09-16 10:55 ` Marek Marczykowski-Górecki
2022-09-16 11:10 ` Roger Pau Monné
2022-09-16 11:44 ` Jan Beulich
0 siblings, 2 replies; 16+ messages in thread
From: Marek Marczykowski-Górecki @ 2022-09-16 10:55 UTC (permalink / raw)
To: Jan Beulich; +Cc: Tamas K Lengyel, Xen-devel
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
On Fri, Sep 16, 2022 at 12:28:46PM +0200, Jan Beulich wrote:
> On 16.09.2022 11:53, Marek Marczykowski-Górecki wrote:
> > On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
> >> ... this leads to the crash, which effectively tells us that this is
> >> likely yet another system where one needs to override the reboot
> >> method (e.g. reboot=acpi).
> >
> > At least Linux, but also XenServer uses reboot=acpi by default (even on
> > EFI systems), can we make it default in upstream Xen? Issues with
> > reboot=efi are rather common, while reboot=acpi just works.
>
> But rebooting by means other than the EFI runtime service has always been
> against the spirit of EFI.
I'm afraid firmware developers (apparently) haven't heard of it. Can we
have "works by default" behaviour?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Default reboot method (was: Re: Console output stops on dbgp=xhci)
2022-09-16 10:55 ` Marek Marczykowski-Górecki
@ 2022-09-16 11:10 ` Roger Pau Monné
2022-09-16 11:44 ` Jan Beulich
1 sibling, 0 replies; 16+ messages in thread
From: Roger Pau Monné @ 2022-09-16 11:10 UTC (permalink / raw)
To: Marek Marczykowski-Górecki; +Cc: Jan Beulich, Tamas K Lengyel, Xen-devel
On Fri, Sep 16, 2022 at 12:55:06PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 16, 2022 at 12:28:46PM +0200, Jan Beulich wrote:
> > On 16.09.2022 11:53, Marek Marczykowski-Górecki wrote:
> > > On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
> > >> ... this leads to the crash, which effectively tells us that this is
> > >> likely yet another system where one needs to override the reboot
> > >> method (e.g. reboot=acpi).
> > >
> > > At least Linux, but also XenServer uses reboot=acpi by default (even on
> > > EFI systems), can we make it default in upstream Xen? Issues with
> > > reboot=efi are rather common, while reboot=acpi just works.
> >
> > But rebooting by means other than the EFI runtime service has always been
> > against the spirit of EFI.
>
> I'm afraid firmware developers (apparently) haven't heard of it. Can we
> have "works by default" behaviour?
We could make it a Kconfig option and set the default to acpi IMO.
Thanks, Roger.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Default reboot method (was: Re: Console output stops on dbgp=xhci)
2022-09-16 10:55 ` Marek Marczykowski-Górecki
2022-09-16 11:10 ` Roger Pau Monné
@ 2022-09-16 11:44 ` Jan Beulich
1 sibling, 0 replies; 16+ messages in thread
From: Jan Beulich @ 2022-09-16 11:44 UTC (permalink / raw)
To: Marek Marczykowski-Górecki; +Cc: Tamas K Lengyel, Xen-devel
On 16.09.2022 12:55, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 16, 2022 at 12:28:46PM +0200, Jan Beulich wrote:
>> On 16.09.2022 11:53, Marek Marczykowski-Górecki wrote:
>>> On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
>>>> ... this leads to the crash, which effectively tells us that this is
>>>> likely yet another system where one needs to override the reboot
>>>> method (e.g. reboot=acpi).
>>>
>>> At least Linux, but also XenServer uses reboot=acpi by default (even on
>>> EFI systems), can we make it default in upstream Xen? Issues with
>>> reboot=efi are rather common, while reboot=acpi just works.
>>
>> But rebooting by means other than the EFI runtime service has always been
>> against the spirit of EFI.
>
> I'm afraid firmware developers (apparently) haven't heard of it. Can we
> have "works by default" behaviour?
Just like with e.g. the RTC, assuming availability of ACPI reboot is
wrong under EFI. A fully conforming implementation may not support
the ACPI method, while supporting the EFI runtime service. It is such
a (well written) implementation where I want Xen to work correctly by
default.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-09-16 11:45 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-14 18:18 Console output stops on dbgp=xhci Tamas K Lengyel
2022-09-14 21:57 ` Marek Marczykowski-Górecki
2022-09-15 0:41 ` Tamas K Lengyel
2022-09-15 1:28 ` Marek Marczykowski-Górecki
2022-09-15 7:55 ` Jan Beulich
2022-09-15 14:05 ` Tamas K Lengyel
2022-09-15 14:10 ` Jan Beulich
2022-09-15 14:16 ` Tamas K Lengyel
2022-09-15 14:39 ` Jan Beulich
2022-09-15 16:48 ` Tamas K Lengyel
2022-09-16 5:57 ` Jan Beulich
2022-09-16 9:53 ` Default reboot method (was: Re: Console output stops on dbgp=xhci) Marek Marczykowski-Górecki
2022-09-16 10:28 ` Jan Beulich
2022-09-16 10:55 ` Marek Marczykowski-Górecki
2022-09-16 11:10 ` Roger Pau Monné
2022-09-16 11:44 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.