Re: Tiger oops in ia64_sal_physical_id_info (was [RFC] regression:113134fcbca83619be4c68d0ca66db6093

Russ Anderson
2008-02-26T23:46:53Z

On Tue, Feb 26, 2008 at 03:45:40PM -0700, Alex Chiang wrote:
>
> I looked through some SAL specs, and it turns out that
> SAL_PHYSICAL_ID_INFO was introduced in v3.2, but this tiger
> implements v3.1.
>
> SAL *should* be returning -1 for unimplemented calls, but
> something is going fantastically wrong here. Bjorn pointed out
> that both r2 and b6 contain the IP. Maybe SAL isn't computing
> branches correctly or something?
>
> So what to do to work around a broken SAL? Seems like a chicken
> and egg problem to me -- the only way to try and check if a call
> is implemented or not is to call it, and calling it hangs the
> machine... :(
>
> Thoughts?

How about putting back some of the code that avoided the problem?

The previous code must have bailed out before getting to
ia64_sal_physical_id_info(). Did it print out an error message,
such as "No logical to physical processor mapping " or
"ia64_pal_logical_to_phys failed with"? What does ia64_pal_logical_to_phys()
return on a tiger box?

--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@sgi.com