On Tue, 2008-02-26 at 16:50 -0700, Alex Chiang wrote: > * Matthew Wilcox <matthew@xxxxxx>: > > > > While you can check to see what SAL revision is supported, do > > be wary of some prototype HP SAL implementations which report > > numbers in the 60-90 range. It's probably safe to say 'if sal > > revision < 3.2 answer = -1', but we were burned with extended > > PCI config space many moons ago when we said 'if sal > 3.1 use > > new method'. > > Ah, good idea, Willy. > > I believe that the current implementation of check_versions() > does the proper workaround for this bug? > > /* Check for broken firmware */ > if ((sal_revision == SAL_VERSION_CODE(49, 29)) > && (sal_version == SAL_VERSION_CODE(49, 29))) > { > /* > * Old firmware for zx2000 prototypes have this weird version number, > * reset it to something sane. > */ > sal_revision = SAL_VERSION_CODE(2, 8); > sal_version = SAL_VERSION_CODE(0, 0); > } > > In light of that, how about this patch? It allows my Tiger to > boot. > > /ac > > From: Alex Chiang <achiang@xxxxxx> > Subject: [PATCH] ia64: ia64_sal_physical_id_info work around broken SAL > > Unimplemented SAL calls should return -1, but on at least one > platform (Tiger with SAL v3.1), attempting to call SAL_PHYSICAL_ID_INFO > (which was defined in SAL v3.2 and later) results in an oops and > a hang. > > Signed-off-by: Alex Chiang <achiang@xxxxxx> > --- > diff --git a/include/asm-ia64/sal.h b/include/asm-ia64/sal.h > index 2251118..f4904db 100644 > --- a/include/asm-ia64/sal.h > +++ b/include/asm-ia64/sal.h > @@ -807,6 +807,10 @@ static inline s64 > ia64_sal_physical_id_info(u16 *splid) > { > struct ia64_sal_retval isrv; > + > + if (sal_revision < SAL_VERSION_CODE(3,2)) > + return -1; > + > SAL_CALL(isrv, SAL_PHYSICAL_ID_INFO, 0, 0, 0, 0, 0, 0, 0); > if (splid) > *splid = isrv.v0; This works for me too. - 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
![]() |