[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced
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. When I actually got it programmed properly, it worked to increment pit0_ticks. I also made timer_interrupt() unconditionally pit0_ticks++ though that may not matter.Hmm, at the first glance I would imply the system gets handed to Xen with a HPET state that we don't (and probably also shouldn't) expect. Could you provide HPET_CFG as well as all HPET_Tn_CFG and HPET_Tn_ROUTE values as hpet_resume() finds them before doing any adjustments to them? What are the components / parties involved in getting Xen loaded and started?Of course much depends on what exactly you mean you've done to the HPET by saying "I programmed the HPET to provide ...".Below is the diff. It was messier and I tidied it up some. It's mainly the change to hpet_resume() to mimic Linux's legacy HPET setup on T0. It turns on HPET_CFG_LEGACY to ensure the timer interrupt is running. And it also includes the printing of the initial HPET config: HPET_CFG 00000001 HPET_T0_CFG 00008030 HPET_T0_ROUTE 0000016c HPET_T1_CFG 00008000 HPET_T1_ROUTE 00000000 HPET_T2_CFG 00008000 HPET_T2_ROUTE 00000000 HPET_T3_CFG 00008000 HPET_T3_ROUTE 00000000 HPET_T4_CFG 0000c000 HPET_T4_ROUTE 00000000 HPET_T5_CFG 0000c000 HPET_T5_ROUTE 00000000 HPET_T6_CFG 0000c000 HPET_T6_ROUTE 00000000 HPET_T7_CFG 0000c000 HPET_T7_ROUTE 00000000 Other changes are to try to prevent Xen from clobbering T0 as a periodic timer. Why "clobbering"? According to the values above T0 is neither enabled nor set to periodic. --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -585,16 +585,27 @@ void __init hpet_broadcast_init(void) pv_rtc_handler = handle_rtc_once; }+ printk(XENLOG_INFO "%s cfg %d\n", __func__, cfg);hpet_write32(cfg, HPET_CFG);for ( i = 0; i < n; i++ ){ - if ( i == 0 && (cfg & HPET_CFG_LEGACY) ) + printk(XENLOG_INFO "hpet cfg %d legacy %d\n", i, cfg & HPET_CFG_LEGACY); + if ( i == 1 && (cfg & HPET_CFG_LEGACY) ) { /* set HPET T0 as oneshot */ - cfg = hpet_read32(HPET_Tn_CFG(0)); + cfg = hpet_read32(HPET_Tn_CFG(1)); cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC); cfg |= HPET_TN_ENABLE | HPET_TN_32BIT; + hpet_write32(cfg, HPET_Tn_CFG(1)); + } + + if ( i == 0 && (cfg & HPET_CFG_LEGACY) ) + { + /* set HPET T0 as periodic */ + cfg = hpet_read32(HPET_Tn_CFG(0)); + cfg |= (HPET_TN_LEVEL | HPET_TN_PERIODIC); A change like this of course won't be acceptable outside of your own repo, but I assume you're clear about this. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |