|
Description
|
After bfu'ing pretty much the b76 bits, both PIII systems I use failed rather
spectacularly:
features: 1003fff<cpuid,sse,sep,pat,cx8,pae,mca,mmx,cmov,de,pge,mtrr,msr,tsc,lgpg>
mem = 3145212K (0xbff7f000)
panic[cpu0]/thread=fec1f7a0: BAD TRAP: type=0 (#de Divide error) rp=fec3881c addr=fec20a38
#de Divide error
addr=0xfec20a38
pid=0, pc=0xfe8042b8, sp=0xfec1f7a0, eflags=0x10046
cr0: 80050011<pg,wp,et,pe> cr4: 98<pge,pse,de>
cr2: 0cr3: 2538000
gs: c43c01b0 fs:
panic[cpu0]/thread=fec1f7a0: BAD TRAP: type=8 (#df Double fault) rp=fec24a4c addr=0
The panics appears to be here:
uint_t
cmi_ntv_hwcoreid(cpu_t *cp)
{
return (cpuid_get_coreid(cp) % cpuid_get_ncore_per_chip(cp));
}
and on inspection the code never sets the number of cores in some systems:
if (cpi->cpi_xmaxeax & 0x80000000) {
....
cpi->cpi_ncore_per_chip = ....
}
Unfortunately, if the first test fails, the number of cores per chip remains 0 and
the divide error panic is triggered.
Oops, test base did not include PIII :-(
It looks like cpi_ncpu_per_chip *is* always initialized in cpuid.c, but
cpi_ncore_per_chip is only initialized in certain cases and otherwise
left as 0. So callers of cpuid_get_ncpu_per_chip (which includes the new
cmi_ntv_hwstrandid) and a number of long-established callers) are ok,
but it appears that my recent putback is the first actual caller of
cpuid_get_ncore_per_chip so it's unhappy when it finds 0.
Obviously we can protect against this in cmi_ntv_hwcoreid and
cmi_ntv_hwstrandid, but it also seems correct to default
the number of cores per chip to 1 - not sure if the value 0
has any magic powers there, however.
|
