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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Bjorn Helgaas <bjorn.helgaas@xxxxxx>:
> On Friday 22 February 2008 12:28:26 am Shaohua Li wrote:
> > My tiger machine hangs since 2.6.23 with commit above. I always saw oops
> > in ia64_sal_physical_id_info(). In 2.6.22, if ia64_pal_logical_to_phys
> > returns UNIMPLENTED, ia64_sal_physical_id_info() isn't called. Below
> > patch fixes the issue. 
> 
> I added a descriptive subject and copied the author of the change.
> He's been travelling for a month or so and might not be able to respond
> immediately.

Thanks Bjorn.

> > diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c
> > index 32ee597..6e0290b 100644
> > --- a/arch/ia64/kernel/smpboot.c
> > +++ b/arch/ia64/kernel/smpboot.c
> > @@ -878,13 +878,10 @@ identify_siblings(struct cpuinfo_ia64 *c)
> >  			printk(KERN_ERR
> >  				"ia64_pal_logical_to_phys failed with %ld\n",
> >  				status);
> > -			return;
> >  		}
> > -
> > -		info.overview_ppid = 0;
> > -		info.overview_cpp  = 1;
> > -		info.overview_tpc  = 1;
> > +		return;

My original commit relied on fall-through behavior to still try
and call ia64_sal_physical_id_info(), because there are
cases/platforms where PAL_LOGICAL_TO_PHYSICAL is not implemented
but SAL_PHYSICAL_ID_INFO is.

I think the more interesting question is, why is that SAL call
hanging / oops'ing your machine rather than returning with an
error code?

In other words, why doesn't the error path work?

Thanks.

/ac

-
To unsubscribe from this list: 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

[Index of Archives]     [Linux Kernel]     [Sparc Linux]     [DCCP]     [Linux ARM]     [Yosemite News]     [Linux SCSI]     [Linux x86_64]     [Linux for Ham Radio]

  Powered by Linux