Isn't the right answer here to have the simulator simulate the actual
hardware and have the setup initilize itv to a correct value?
Thanks,
Robin
On Mon, May 01, 2006 at 05:20:55PM +1000, Ian Wienand wrote:
> On Mon, Jan 30, 2006 at 03:11:57PM -0700, Bjorn Helgaas wrote:
> > +static void __init
> > +check_sal_cache_flush (void)
> > +{
> > + /*
> > + * Schedule a timer interrupt, wait until it's reported, and see if
> > + * SAL_CACHE_FLUSH drops it.
> > + */
> > + itv = ia64_get_itv();
> > + BUG_ON((itv & (1 << 16)) == 0);
> > +
> > + ia64_set_itv(IA64_TIMER_VECTOR);
> ... [stuff] ...
> > + ia64_set_itv(itv);
>
> Sorry I didn't notice earlier, but that BUG_ON triggers for me on the
> simulator. AFAICS the mask for itv is set in cpu_init(), which comes
> after sal_init(). Consequently on the simulator the itv still has its
> start value of zero. I've probably missed something, but I wonder why
> at this stage of the boot you even need to save and restore the itv?
>
> -i
>
> Signed-Off-By: Ian Wienand <ianw@xxxxxxxxxxxxxxxxxx>
>
> --- linux-2.6.17-rc3-lvhpt/arch/ia64/kernel/sal.c 2006-03-20 16:53:29.000000000 +1100
> +++ linux-2.6.17-rc3/arch/ia64/kernel/sal.c 2006-05-01 17:20:11.000000000 +1000
> @@ -227,7 +227,7 @@
> static void __init
> check_sal_cache_flush (void)
> {
> - unsigned long flags, itv;
> + unsigned long flags;
> int cpu;
> u64 vector;
>
> @@ -238,9 +238,6 @@
> * Schedule a timer interrupt, wait until it's reported, and see if
> * SAL_CACHE_FLUSH drops it.
> */
> - itv = ia64_get_itv();
> - BUG_ON((itv & (1 << 16)) == 0);
> -
> ia64_set_itv(IA64_TIMER_VECTOR);
> ia64_set_itm(ia64_get_itc() + 1000);
>
> @@ -260,7 +257,6 @@
> ia64_eoi();
> }
>
> - ia64_set_itv(itv);
> local_irq_restore(flags);
> put_cpu();
> }
>
>
>
-
: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|