Re: Linux 2.4.2ac7

2001-03-02 Thread Tigran Aivazian
On Fri, 2 Mar 2001, Alan Cox wrote: > [24940903.pdf] > Table 14 in paticular gives the config bits ok, thank you. Now I understand (maybe) whats' going on. Linux treated bits 22,23,24,25 but ignored 27 which it shouldn't have. Now, coupled with the fact that the problematic box I have

Re: Linux 2.4.2ac7

2001-03-02 Thread Alan Cox
> the bad news to this "rule" is that I just found one "exception". Namely, > I have Celeron-600/100 and PentiumII-333/66 and both evaluate to > bus/mul=0/0 even in 4bit bus representation which is impossible. So, this > is my big stumbling block if you tell me how to overcome > this, I can ve

Re: Linux 2.4.2ac7

2001-03-02 Thread Alan Cox
> If I extend 'bus' to be 4 bits instead of 2 then I can make it work on all > of my machines (or all those I tried), of course, extending the buscode[] > table appropriately. That would be interesting to see. Certainly the mul code got extended by a bit later on > However, the radically broken,

Re: Linux 2.4.2ac7

2001-03-02 Thread Alan Cox
> ah, I see, so we are using the Reserved (14 upwards) bits of the > MSR_EBC_HARD_POWERON? Ok, so the task is to understand how the bus info is > encoded. Well actually they are documented in part by some of the intel and other docs. But all the docs agree on the bus speed encoding ... - To un

Re: Linux 2.4.2ac7

2001-03-02 Thread Tigran Aivazian
Alan, Those formulae (both 'bus' and 'mul' calculation) are broken, I think. If I extend 'bus' to be 4 bits instead of 2 then I can make it work on all of my machines (or all those I tried), of course, extending the buscode[] table appropriately. However, the radically broken, imho, thing is th

cpu/bus speed detection (was Re: Linux 2.4.2ac7

2001-03-02 Thread Tigran Aivazian
On Thu, 1 Mar 2001, Alan Cox wrote: > Please send me the value of your 0x2A MTRR. Because this isnt properly intel > documented there is a certain amount of research still required. > ok, adding this to init_intel(): u32 lo, hi; rdmsr(0x2A, lo, hi); printk(KERN_ERR "lo

Re: Linux 2.4.2ac7

2001-03-01 Thread Alan Cox
> > Linux 2.4.2-ac7 reports wrong CPU speed and model name for a Pentium II= > I > > correctly detected on, at least, 2.2.18, 2.4.2 and 2.4.2-ac4. The > > processor is a 600 MHz one, with a 133 MHz front bus. The model name printing has not changed. Not at all. > same here with PIII550MHz/100MHz

Re: Linux 2.4.2ac7

2001-03-01 Thread Tigran Aivazian
On Thu, 1 Mar 2001, José Luis Domingo López wrote: > Linux 2.4.2-ac7 reports wrong CPU speed and model name for a Pentium III > correctly detected on, at least, 2.2.18, 2.4.2 and 2.4.2-ac4. The > processor is a 600 MHz one, with a 133 MHz front bus. same here with PIII550MHz/100MHz bus. Actually,

Re: Linux 2.4.2ac7

2001-03-01 Thread José Luis Domingo López
On Thursday, 01 March 2001, at 01:31:10 +, Alan Cox wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > 2.4.2-ac7 > o Fix the non booting winchip/cyrix problem (me) > Linux 2.4.2-ac7 reports wrong CPU speed and model name for a Pentium III correctly detect

Re: Linux 2.4.2ac7

2001-03-01 Thread Maciej W. Rozycki
On Thu, 1 Mar 2001, Ingo Molnar wrote: > > > o Handle broken PIV MP tables with a NULL ioapic > > > > That's not a right fix. [...] > > Maciej, it *is* the right fix. These are UP systems not SMP systems, but > if we boot an SMP kernel then we find a (largely bogus) mptable during the > scan.

Re: Linux 2.4.2ac7

2001-03-01 Thread Maciej W. Rozycki
On Thu, 1 Mar 2001, Alan Cox wrote: > o Handle broken PIV MP tables with a NULL ioapic That's not a right fix. We should make a check in MP_ioapic_info() and do not register bogus I/O APICs (hmm, I wonder what the next thing to be broken in MP-tables is...). We should handle the no I/O AP

Re: Linux 2.4.2ac7

2001-03-01 Thread Ingo Molnar
On Thu, 1 Mar 2001, Maciej W. Rozycki wrote: > > o Handle broken PIV MP tables with a NULL ioapic > > That's not a right fix. [...] Maciej, it *is* the right fix. These are UP systems not SMP systems, but if we boot an SMP kernel then we find a (largely bogus) mptable during the scan. Any B