> Date: Thu, 30 Dec 2010 08:44:33 +1100 > From: Jonathan Gray <j...@goblin.cx> > > On Wed, Dec 29, 2010 at 01:51:44PM +0100, Mark Kettenis wrote: > > Gets rid of the "unknown i686 model 0xXX, can't get bus clock" message > > on the Xeon 3600/5600. Also pre-emptively adds the Xeon 6500/7500. I > > updated the comments to include the names of the matching Xeon > > variants; the market people seem to have less influence on those. > > > > ok? > > fwiw, I've had this sitting in my tree for a while with some other bits: > > case 0x1a: /* Core i7/Xeon 5500 */ > case 0x1e: /* Core i5/i7 */ > case 0x1f: /* Core i5/i7 */ > case 0x25: /* Core i3/i5/i7/Xeon 5600 */ > case 0x2c: /* Core i3/i5/i7/Xeon 5600 */ > perf_status = 0; > bus_clock = BUS133; > break; > case 0x2a: /* Sandy Bridge Core */ > case 0x2d: /* Sandy Bridge Xeon */ > perf_status = 0; > bus_clock = BUS100; > break; > case 0x1d: /* Xeon MP 7400 */ > case 0x2e: /* Xeon 7500 */ > default: > perf_status = 0;
That means you'll have a conflict now. Don't think we actually want to set bus_clock. On modern machines, ACPI will provide us a list of frequencies and MSR settings, so we don't need bus_clock to calculate a table of fake entries. I believe my comments are a bit more accurate. But the Intel marketing droids obviously fucked up the meaning of i3/i5/i7 completely. Where did you get the model IDs for the Sandy Bridge CPUs?
