On 29.08.2022 17:26, Dylanger Daly wrote:
> Please see the attached iomem and meminfo text files from both Qubes under
> Xen and functional Fedora Workstation.
>
> After some investigation, I've seen that I'm able to run a few small VMs just
> fine, however as soon as I start a larger VM, PCI de
On 27.08.2022 19:52, Dylanger Daly wrote:
> Thank you for your reply, Xen appears to crash immediately on startup and
> appears to hit the patch
Oh, yes, silly me - map_domain_page() can't be used that way. You
may want to give the replacement patch (below) a try, albeit later
replies of yours ha
On 01.09.2022 00:12, Dylanger Daly wrote:
> I think I've narrowed the issue down to a PCI device, if I start 2 large VM,
> then simply run lspci in dom0, it'll trigger a crash.
>
> This makes sense as sys-net works fine until I start a larger VM, then I see
> a 'chip reset' error in the appVM's
Hi Jan,
I've managed to finangle a very unstable environment together
What I'm seeing is the following:
1. All appVMs including dom0 must have 1 core assigned
2. This means I'm able to launch 4 appVMs, as soon as I launch a 5th, it puts
all PCIe devices into a bad state
3. If I shut the 5th VM
Hi Jan,
I think I've narrowed the issue down to a PCI device, if I start 2 large VM,
then simply run lspci in dom0, it'll trigger a crash.
This makes sense as sys-net works fine until I start a larger VM, then I see a
'chip reset' error in the appVM's dmesg, I assume the entire PCI Bus goes int
On 25.08.2022 13:10, Dylanger Daly wrote:
> Yes please, I have Qubes's Build System setup with sourcehut so I can add
> patches at will, however please be aware Qubes currently uses Xen 4.14.
>
> I'll take a look and see if I can access that location
>
> With the added logging I should be able t
Hi Jan,
Yes please, I have Qubes's Build System setup with sourcehut so I can add
patches at will, however please be aware Qubes currently uses Xen 4.14.
I'll take a look and see if I can access that location
With the added logging I should be able to trigger the crash and get to the
bottom of
On 24.08.2022 20:15, Dylanger Daly wrote:
> I'm sorry I didn't get where in /sys/firmware you'd like to take a look at.
It's been a long time since I last needed to access that, when it
was still /proc/mem and/or /proc/kmem. Their modern equivalents might
be /sys/devices/virtual/mem/{,k}mem ... Bu
Hi Jan,
I'm sorry I didn't get where in /sys/firmware you'd like to take a look at.
Sometimes when I power the laptop off I can see it's crashing somewhere in
ACPI/weird address issue
Is there anyone else struggling with AMD Ryzen 6000 on Xen?
On 15.08.2022 18:54, Dylanger Daly wrote:
> Please see the attached dom0 dmesg log, verbose lspci output and a tar of all
> SSDT and DSDT decompiled ACPI tables.
The only way I can currently explain all aspects of the behavior that
I'm aware of is for Dom0's kernel somehow not identifying the pag
On 16.08.2022 11:19, Dylanger Daly wrote:
> Opening sound settings in dom0 and setting the HD Audio Controller to "Off"
> allowed the VM to boot! đ
"The HD Audio Controller" is somewhat ambiguous - according to lspci
apparently you've got three of them, one named as "multimedia controller"
(and h
Hi Jan,
Interesting morning indeed!
Opening sound settings in dom0 and setting the HD Audio Controller to "Off"
allowed the VM to boot! đ
Very strange indeed
Cheers
On 16.08.2022 10:34, Dylanger Daly wrote:
> Indeed no devices are being passed into the domU, I'm simply trying to start
> a vanilla VM with no PCIe devices attached.
Hmm, looking more closely it's the sound device which is being opened by
some ALSA process. I have no clue at all why this would h
Hi Jan,
Indeed no devices are being passed into the domU, I'm simply trying to start a
vanilla VM with no PCIe devices attached.
Could it be a misconfiguration with ACPI tables? I originally thought it could
be AMD's SEV but I think it might just be that Xen is attempting to use a
memory regio
On 15.08.2022 18:54, Dylanger Daly wrote:
> Please see the attached dom0 dmesg log, verbose lspci output and a tar of all
> SSDT and DSDT decompiled ACPI tables.
>
> Please let let me know if I can send anything else
The lspci output reminds me of having forgotten to ask which device it
is that
On 15.08.2022 17:39, Dylanger Daly wrote:
> Great news! I managed to get it to log the error with your cmdlines
>
> Please see the attached images
>
> The error "BUG: unable to handle page fault for address: c90040639019"
>
> It appears to be a memory violation error?
Yes, there's an attemp
On 15.08.2022 13:50, Dylanger Daly wrote:
> Indeed adding noreboot does result in the device just hanging there after
> starting a VM.
>
> I wonder if it's possible to have Xen write out it's log to some memory
> address, hoping it's doing a warm reset the log messages should still be
> present
Hi Jan,
Indeed adding noreboot does result in the device just hanging there after
starting a VM.
I wonder if it's possible to have Xen write out it's log to some memory
address, hoping it's doing a warm reset the log messages should still be
present.
Cheers
On 15.08.2022 13:07, Dylanger Daly wrote:
> It would appear this issue isn't specific to the Lenovo Yoga Slim 7 ProX,
> someone else in the Qubes community is having the same issue
> (https://github.com/QubesOS/qubes-issues/issues/7620#issuecomment-1209114810)
>
> Can anyone shed some light on w
Hi All,
It would appear this issue isn't specific to the Lenovo Yoga Slim 7 ProX,
someone else in the Qubes community is having the same issue
(https://github.com/QubesOS/qubes-issues/issues/7620#issuecomment-1209114810)
Can anyone shed some light on what possibly might be making a Xen 4.14
Hy
On 20.07.2022 10:11, Jan Beulich wrote:
> On 20.07.2022 02:33, Dylanger Daly wrote:
>>> I'd focus on the booting issues first. And I guess you can take a video
>>> of that (assuming that a single screenshot likely isn't going to be
>>> enough), possibly with "vga=keep" in place (albeit that introdu
On 20.07.2022 02:33, Dylanger Daly wrote:
>> I'd focus on the booting issues first. And I guess you can take a video
>> of that (assuming that a single screenshot likely isn't going to be
>> enough), possibly with "vga=keep" in place (albeit that introduces
>> extra slowness)?
>>
>> There's also th
> I'd focus on the booting issues first. And I guess you can take a video
> of that (assuming that a single screenshot likely isn't going to be
> enough), possibly with "vga=keep" in place (albeit that introduces
> extra slowness)?
>
> There's also the option of using an EHCI debug port for the ser
On 19.07.2022 08:47, Dylanger Daly wrote:
> Yes âšī¸, do you know if it's possible to obtain logs some other way for a
> system that doesn't have a COM port? console=vga exists but I can't seem to
> flip over to the vga "console" after I trigger the start of a VM
I'd focus on the booting issues fi
Dom0 (being a VM itself) boots just perfectly, it's any other domU that
triggers the issue, I'm hoping I can somehow hook up gdb or something to Xen
somehow
Original Message
On Jul 19, 2022, 4:29 PM, Jan Beulich wrote:
> On 19.07.2022 01:04, Dylanger Daly wrote: > I'm having i
Yes âšī¸, do you know if it's possible to obtain logs some other way for a system
that doesn't have a COM port? console=vga exists but I can't seem to flip over
to the vga "console" after I trigger the start of a VM
Original Message
On Jul 19, 2022, 4:29 PM, Jan Beulich wrote:
>
On 19.07.2022 01:04, Dylanger Daly wrote:
> I'm having issues getting QubesOS running on my Lenovo Yoga Slim 7 ProX (AMD
> Ryzen 6800HS)
>
> Firstly in order to boot the device at all, I'm required to add
> `dom0_max_vcpus=1 dom0_vcpus_pin` to dom0's CMDLINE, this is similar to what
> I had to
Hi All,
I'm having issues getting QubesOS running on my Lenovo Yoga Slim 7 ProX (AMD
Ryzen 6800HS)
Firstly in order to boot the device at all, I'm required to add
`dom0_max_vcpus=1 dom0_vcpus_pin` to dom0's CMDLINE, this is similar to what I
had to do previously -
https://xen.markmail.org/sea
28 matches
Mail list logo
