On Fri, Apr 17, 2020 at 5:31 AM Jan Beulich wrote:
>
> On 17.03.2020 16:23, Jason Andryuk wrote:
> > Below is the diff. It was messier and I tidied it up some.
>
> I've looked into this some more. I can see how what we currently
> do is not in line with firmware handing off with
On 17.03.2020 16:23, Jason Andryuk wrote:
> Below is the diff. It was messier and I tidied it up some.
I've looked into this some more. I can see how what we currently
do is not in line with firmware handing off with LegacyReplacement
mode enabled. However, this case doesn't look to apply here:
On Wed, Mar 18, 2020 at 10:04 AM Jason Andryuk wrote:
> On Wed, Mar 18, 2020 at 6:38 AM Jan Beulich wrote:
> > On 17.03.2020 16:23, Jason Andryuk wrote:
> > > On 17.03.2020 15:08, Jan Beulich wrote:
> > >> On 17.03.2020 15:08, Jan Beulich wrote:
> > >>> On 17.03.2020 14:48, Jason Andryuk wrote:
On Wed, Mar 18, 2020 at 6:38 AM Jan Beulich wrote:
>
> On 17.03.2020 16:23, Jason Andryuk wrote:
> > On 17.03.2020 15:08, Jan Beulich wrote:
> >> On 17.03.2020 15:08, Jan Beulich wrote:
> >>> On 17.03.2020 14:48, Jason Andryuk wrote:
> I got it to boot past "IO-APIC + timer doesn't work". I
On 17.03.2020 16:23, Jason Andryuk wrote:
On 17.03.2020 15:08, Jan Beulich wrote:
On 17.03.2020 15:08, Jan Beulich wrote:
On 17.03.2020 14:48, Jason Andryuk wrote:
I got it to boot past "IO-APIC + timer doesn't work". I programmed
the HPET to provide a periodic timer in hpet_resume() on T0.
On Tue, Mar 17, 2020 at 11:23 AM Jason Andryuk wrote:
>
> On 17.03.2020 15:08, Jan Beulich wrote:
> >On 17.03.2020 15:08, Jan Beulich wrote:
> >> On 17.03.2020 14:48, Jason Andryuk wrote:
> >>> I got it to boot past "IO-APIC + timer doesn't work". I programmed
> >>> the HPET to provide a
On 17.03.2020 15:08, Jan Beulich wrote:
>On 17.03.2020 15:08, Jan Beulich wrote:
>> On 17.03.2020 14:48, Jason Andryuk wrote:
>>> I got it to boot past "IO-APIC + timer doesn't work". I programmed
>>> the HPET to provide a periodic timer in hpet_resume() on T0. When I
>>> actually got it
On 17.03.2020 15:08, Jason Andryuk wrote:
> On Tue, Mar 17, 2020 at 9:48 AM Jason Andryuk wrote:
>> I got it to boot past "IO-APIC + timer doesn't work". I programmed
>> the HPET to provide a periodic timer in hpet_resume() on T0. When I
>> actually got it programmed properly, it worked to
On 17.03.2020 15:08, Jan Beulich wrote:
> On 17.03.2020 14:48, Jason Andryuk wrote:
>> I got it to boot past "IO-APIC + timer doesn't work". I programmed
>> the HPET to provide a periodic timer in hpet_resume() on T0. When I
>> actually got it programmed properly, it worked to increment
>>
On 17.03.2020 14:48, Jason Andryuk wrote:
> On Wed, Mar 4, 2020 at 11:06 AM Jason Andryuk wrote:
>>
>> On Wed, Feb 19, 2020 at 3:25 AM Jan Beulich wrote:
>>>
>>> On 18.02.2020 22:45, Andrew Cooper wrote:
On 18/02/2020 18:43, Jason Andryuk wrote:
> On Mon, Feb 17, 2020, 8:22 PM Andrew
On Tue, Mar 17, 2020 at 9:48 AM Jason Andryuk wrote:
> I got it to boot past "IO-APIC + timer doesn't work". I programmed
> the HPET to provide a periodic timer in hpet_resume() on T0. When I
> actually got it programmed properly, it worked to increment
> pit0_ticks. I also made
On Wed, Mar 4, 2020 at 11:06 AM Jason Andryuk wrote:
>
> On Wed, Feb 19, 2020 at 3:25 AM Jan Beulich wrote:
> >
> > On 18.02.2020 22:45, Andrew Cooper wrote:
> > > On 18/02/2020 18:43, Jason Andryuk wrote:
> > >> On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper
> > >> wrote:
> > >>> On 17/02/2020
On Wed, Feb 19, 2020 at 3:25 AM Jan Beulich wrote:
>
> On 18.02.2020 22:45, Andrew Cooper wrote:
> > On 18/02/2020 18:43, Jason Andryuk wrote:
> >> On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper
> >> wrote:
> >>> On 17/02/2020 20:41, Jason Andryuk wrote:
> On Mon, Feb 17, 2020 at 2:46 PM
> > >>> One other thing that might be noteworthy. Linux only prints ACPI IRQ0
> > >>> and IRQ9 used by override where Xen lists IRQ 0, 2 & 9.
> > >> Huh - this is supposed to come directly from the ACPI tables, so Linux
> > >> and Xen should be using the same source of information.
Both Xen and
On 18.02.2020 22:45, Andrew Cooper wrote:
> On 18/02/2020 18:43, Jason Andryuk wrote:
>> On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper
>> wrote:
>>> On 17/02/2020 20:41, Jason Andryuk wrote:
On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper
wrote:
> On 17/02/2020 19:19, Jason Andryuk
On 18/02/2020 18:43, Jason Andryuk wrote:
> On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper wrote:
>> On 17/02/2020 20:41, Jason Andryuk wrote:
>>> On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper
>>> wrote:
On 17/02/2020 19:19, Jason Andryuk wrote:
> enabling vecOn Tue, Dec 31, 2019 at 5:43
On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper wrote:
>
> On 17/02/2020 20:41, Jason Andryuk wrote:
> > On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper
> > wrote:
> >> On 17/02/2020 19:19, Jason Andryuk wrote:
> >>> enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse
> >>> wrote:
> On
On 17/02/2020 20:41, Jason Andryuk wrote:
On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper wrote:
On 17/02/2020 19:19, Jason Andryuk wrote:
enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse wrote:
On Tue, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
Is there any full boot log in the
On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper wrote:
>
> On 17/02/2020 19:19, Jason Andryuk wrote:
> > enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse
> > wrote:
> >> On Tue, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
> >>> Is there any full boot log in the bad case? Debugging via
On 17/02/2020 19:19, Jason Andryuk wrote:
> enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse
> wrote:
>> On Tue, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
>>> Is there any full boot log in the bad case? Debugging via divination
>>> isn't an effective way to get things done.
>>
enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse wrote:
>
> On Tue, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
> > Is there any full boot log in the bad case? Debugging via divination
> > isn't an effective way to get things done.
>
> Agreed. I included some more verbose logs towards
On 06.01.2020 01:35, Aaron Janse wrote:
> On Fri, Jan 3, 2020, at 4:51 AM, Jan Beulich wrote:
>> Did you try disabling use of the IOMMU ("iommu=0" on the Xen
>> command line)?
>
> Unfortunately, Qubes requires iommu. Setting "iommu=0" results in a panic:
>
> ```
> Couldn't enable IOMMU and
On Fri, Jan 3, 2020, at 4:51 AM, Jan Beulich wrote:
> On 31.12.2019 08:52, Aaron Janse wrote:
> > I'd like to note that Ubuntu, unlike Qubes, doesn't need to try
> > any `MP-BIOS bug` fallbacks.
>
> "Doesn't need to try" is supposed to mean what? That it gets past
> the timer interrupt
On 31.12.2019 08:52, Aaron Janse wrote:
> I'd like to note that Ubuntu, unlike Qubes, doesn't need to try
> any `MP-BIOS bug` fallbacks.
"Doesn't need to try" is supposed to mean what? That it gets past
the timer interrupt initialization, meaning if it crashes another
way, it's a different
On 31/12/2019 07:52, Aaron Janse wrote:
> Hello all,
>
> After attempting to install QubesOS on a new laptop, I've stumbled upon
> a group of people with an assortment of laptops but all the same
> problem: a Xen panic stating "IO-APIC + timer doesn't work!"
>
> Many of us are on different stages
Hello all,
After attempting to install QubesOS on a new laptop, I've stumbled upon
a group of people with an assortment of laptops but all the same
problem: a Xen panic stating "IO-APIC + timer doesn't work!"
Many of us are on different stages of debugging this, so I'll cite all
our efforts
26 matches
Mail list logo
