Re: Linux 2.4.2ac7
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 (Celeron) has that bit 27 set suggests that we ought to extend mult[] table appropriately. The values for that Celeron do not match anything in the Table 14 so we have to extend mult[] emprirically. (so I now come back to the idea of 4bit representation of 'bus'). I will stop here/now but I will definitely come back to this interesting problem in 24 hours. But if anyone fixes it before then, I won't cry :) Of course, before sending anything I will make sure my patch works on _all_ my machines without any exceptions. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
> 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 very quickly build buscode[] table that works on all other > machines I have. > > also, a pointer to anything written down about bus encoding in 2E MSR > would be nice. Cyrix III samuel data book Mobile Intel(R) Pentium III Processor in BGA2 and ,, [24940903.pdf] Table 14 in paticular gives the config bits This also implies a bus selection table of 00 66MHz 01 100Mhz 10 Reserved 11 133 Mhz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
> 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, imho, thing is that the (bus, mul) pair is > _not_ constant when I vary the bus/cpu speed settings in the "soft cpu > BIOS". If the bits of the 0x2A msr are supposed to be used for finding out > the "true" i.e. intended bus/cpu speeds (hence the label "overclocked" in > the code) then they should remain constant when one is overclocking, > right? The values are read from the poweron register. The values in that can be wrong in certain cases. The real goal is to get the bus/multiplier values for the processors on an SMP box reliably. In fact the 'overclocked' hack is probably not something I'd feed to Linus Ultimately we need this to detect SMP boxes where the cpus have different multipliers, as we must disable the TSC in these cases. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
> 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 that the (bus, mul) pair is _not_ constant when I vary the bus/cpu speed settings in the "soft cpu BIOS". If the bits of the 0x2A msr are supposed to be used for finding out the "true" i.e. intended bus/cpu speeds (hence the label "overclocked" in the code) then they should remain constant when one is overclocking, right? As for my question on the evenness of the calls to identify_cpu() -- ignore it, it was obvious, of course (called from check_bugs() on boot_cpu_data and then on SMP on each cpu_data + id) Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpu/bus speed detection (was Re: Linux 2.4.2ac7
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=%x hi=%x\n", lo, hi); produces the output: # dmesg | grep lo= lo=c5100800 hi=0 lo=c5100800 hi=0 lo=c5000800 hi=0 Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpu/bus speed detection (was Re: Linux 2.4.2ac7
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=%x hi=%x\n", lo, hi); produces the output: # dmesg | grep lo= lo=c5100800 hi=0 lo=c5100800 hi=0 lo=c5000800 hi=0 Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 that the (bus, mul) pair is _not_ constant when I vary the bus/cpu speed settings in the "soft cpu BIOS". If the bits of the 0x2A msr are supposed to be used for finding out the "true" i.e. intended bus/cpu speeds (hence the label "overclocked" in the code) then they should remain constant when one is overclocking, right? As for my question on the evenness of the calls to identify_cpu() -- ignore it, it was obvious, of course (called from check_bugs() on boot_cpu_data and then on SMP on each cpu_data + id) Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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, imho, thing is that the (bus, mul) pair is _not_ constant when I vary the bus/cpu speed settings in the "soft cpu BIOS". If the bits of the 0x2A msr are supposed to be used for finding out the "true" i.e. intended bus/cpu speeds (hence the label "overclocked" in the code) then they should remain constant when one is overclocking, right? The values are read from the poweron register. The values in that can be wrong in certain cases. The real goal is to get the bus/multiplier values for the processors on an SMP box reliably. In fact the 'overclocked' hack is probably not something I'd feed to Linus Ultimately we need this to detect SMP boxes where the cpus have different multipliers, as we must disable the TSC in these cases. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 very quickly build buscode[] table that works on all other machines I have. also, a pointer to anything written down about bus encoding in 2E MSR would be nice. Cyrix III samuel data book Mobile Intel(R) Pentium III Processor in BGA2 and ,, [24940903.pdf] Table 14 in paticular gives the config bits This also implies a bus selection table of 00 66MHz 01 100Mhz 10 Reserved 11 133 Mhz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 (Celeron) has that bit 27 set suggests that we ought to extend mult[] table appropriately. The values for that Celeron do not match anything in the Table 14 so we have to extend mult[] emprirically. (so I now come back to the idea of 4bit representation of 'bus'). I will stop here/now but I will definitely come back to this interesting problem in 24 hours. But if anyone fixes it before then, I won't cry :) Of course, before sending anything I will make sure my patch works on _all_ my machines without any exceptions. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
> > 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 bus. Actually, it is wrong in 2.4.2-ac6 > as well -- don't know about ac5: Please send me the value of your 0x2A MTRR. Because this isnt properly intel documented there is a certain amount of research still required. 363 / 66 would be a 66Mhz bus 5.5 multiplier. It got the multiplier right but it appears the bus speed encoding may be different. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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, it is wrong in 2.4.2-ac6 as well -- don't know about ac5: here is info from bootlog: NT 05 Int: type 0, pol 0, trig 0, bus 3, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 3, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 1, trig 1, bus 3, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 3, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 0, trig 0, bus 3, IRQ 0a, APIC ID 2, APIC INT 0a Int: type 0, pol 0, trig 0, bus 3, IRQ 0b, APIC ID 2, APIC INT 0b Int: type 0, pol 0, trig 0, bus 3, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 0, trig 0, bus 3, IRQ 0d, APIC ID 2, APIC INT 0d Int: type 0, pol 0, trig 0, bus 3, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 3, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 11 Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 29, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 2, IRQ 10, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 2, IRQ 14, APIC ID 2, APIC INT 10 Int: type 2, pol 3, trig 1, bus 3, IRQ 00, APIC ID 2, APIC INT 17 Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=242-ac6 ro root=341 BOOT_FILE=/boot/vmlinuz-2.4.2-ac6 video=matrox:vesa:0x118 parport=0x378,7 console=ttyS1,38400 console=tty0 nmi_watchdog=0 Initializing CPU#0 Detected 548.547 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1094.45 BogoMIPS Memory: 1026616k/1048512k available (1855k kernel code, 21508k reserved, 477k data, 248k init, 131008k highmem) Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0387fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0387fbff CPU serial number disabled. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU0: Intel Pentium III (Katmai) stepping 03 per-CPU timeslice cutoff: 1462.42 usecs. Getting VERSION: 40011 Getting VERSION: 40011 Getting ID: 0 Getting ID: f00 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: CPU present map: 3 Booting processor 1/1 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1. After apic_write. Initializing CPU#1 Startup point 1. CPU#1 (phys ID: 1) waiting for CALLOUT Waiting for send to finish... +Sending STARTUP #2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before setup_local_APIC(). masked ExtINT on CPU#1 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 1094.45 BogoMIPS Stack at about c221dfbc CPU: Before vendor init, caps: 0387fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check reporting enabled on CPU#1. CPU: After vendor init, caps: 0387fbff CPU serial number disabled. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff
Re: Linux 2.4.2ac7
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 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. Linux 2.2.18 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 598.475 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat p se36 mmx fxsr xmm bogomips: 1192.75 Linux 2.4.2-ac4 --- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 598.481 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat p se36 mmx fxsr sse bogomips: 1192.75 Linux 2.4.2-ac7 --- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Heavily Overclocked Pentium III (Katmai) (300Mhz/66Mhz FSB) stepping: 3 cpu MHz : 598.495 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat p se36 mmx fxsr sse bogomips: 1192.75 -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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. I disagree. It's just a dirty hack and it obscures the APIC code even more than it already is. I propose to make it cleanly. Please let me do some code and we may get back to the discussion then. > Any BIOS of a real SMP box that is so blatantly broken to specify a NULL > ioapic in the mptable deserves SMP mode being disabled altogether. I suppose such BIOS doesn't exist and isn't going to. An SMP configuration with no I/O APIC is legal from the hw point of view though and it's sane (modulo errata), even if not permitted by the MPS. We may handle it for free and we will handle UP systems with an MP-table and no APIC automatically as well. > lets not overcomplicate things. Sure -- I just want to simplify them. :-) Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 APIC case around setup_IO_APIC() then. This would be similar to specifying "noapic" in the command line. There is absolutely no need to disable SMP support if there is no I/O APIC -- we don't insist on having it. We are able to route interrupts through 8259A controllers if needed (we'd better avoid it if at all possible due to various chip errata, though). I'll implement the idea together with my pending APIC clean-ups. We don't handle P4-compatible I/O APICs at the moment, anyway... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 BIOS of a real SMP box that is so blatantly broken to specify a NULL ioapic in the mptable deserves SMP mode being disabled altogether. lets not overcomplicate things. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 BIOS of a real SMP box that is so blatantly broken to specify a NULL ioapic in the mptable deserves SMP mode being disabled altogether. lets not overcomplicate things. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 APIC case around setup_IO_APIC() then. This would be similar to specifying "noapic" in the command line. There is absolutely no need to disable SMP support if there is no I/O APIC -- we don't insist on having it. We are able to route interrupts through 8259A controllers if needed (we'd better avoid it if at all possible due to various chip errata, though). I'll implement the idea together with my pending APIC clean-ups. We don't handle P4-compatible I/O APICs at the moment, anyway... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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. I disagree. It's just a dirty hack and it obscures the APIC code even more than it already is. I propose to make it cleanly. Please let me do some code and we may get back to the discussion then. Any BIOS of a real SMP box that is so blatantly broken to specify a NULL ioapic in the mptable deserves SMP mode being disabled altogether. I suppose such BIOS doesn't exist and isn't going to. An SMP configuration with no I/O APIC is legal from the hw point of view though and it's sane (modulo errata), even if not permitted by the MPS. We may handle it for free and we will handle UP systems with an MP-table and no APIC automatically as well. lets not overcomplicate things. Sure -- I just want to simplify them. :-) Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
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 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. Linux 2.2.18 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 598.475 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat p se36 mmx fxsr xmm bogomips: 1192.75 Linux 2.4.2-ac4 --- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 598.481 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat p se36 mmx fxsr sse bogomips: 1192.75 Linux 2.4.2-ac7 --- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Heavily Overclocked Pentium III (Katmai) (300Mhz/66Mhz FSB) stepping: 3 cpu MHz : 598.495 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat p se36 mmx fxsr sse bogomips: 1192.75 -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo AT internautas DOT org = Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac7
On Thu, 1 Mar 2001, Jos Luis Domingo Lpez 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, it is wrong in 2.4.2-ac6 as well -- don't know about ac5: here is info from bootlog: NT 05 Int: type 0, pol 0, trig 0, bus 3, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 3, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 1, trig 1, bus 3, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 3, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 0, trig 0, bus 3, IRQ 0a, APIC ID 2, APIC INT 0a Int: type 0, pol 0, trig 0, bus 3, IRQ 0b, APIC ID 2, APIC INT 0b Int: type 0, pol 0, trig 0, bus 3, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 0, trig 0, bus 3, IRQ 0d, APIC ID 2, APIC INT 0d Int: type 0, pol 0, trig 0, bus 3, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 3, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 11 Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 29, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 2, IRQ 10, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 2, IRQ 14, APIC ID 2, APIC INT 10 Int: type 2, pol 3, trig 1, bus 3, IRQ 00, APIC ID 2, APIC INT 17 Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=242-ac6 ro root=341 BOOT_FILE=/boot/vmlinuz-2.4.2-ac6 video=matrox:vesa:0x118 parport=0x378,7 console=ttyS1,38400 console=tty0 nmi_watchdog=0 Initializing CPU#0 Detected 548.547 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1094.45 BogoMIPS Memory: 1026616k/1048512k available (1855k kernel code, 21508k reserved, 477k data, 248k init, 131008k highmem) Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0387fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0387fbff CPU serial number disabled. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU0: Intel Pentium III (Katmai) stepping 03 per-CPU timeslice cutoff: 1462.42 usecs. Getting VERSION: 40011 Getting VERSION: 40011 Getting ID: 0 Getting ID: f00 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: CPU present map: 3 Booting processor 1/1 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1. After apic_write. Initializing CPU#1 Startup point 1. CPU#1 (phys ID: 1) waiting for CALLOUT Waiting for send to finish... +Sending STARTUP #2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before setup_local_APIC(). masked ExtINT on CPU#1 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 1094.45 BogoMIPS Stack at about c221dfbc CPU: Before vendor init, caps: 0387fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check reporting enabled on CPU#1. CPU: After vendor init, caps: 0387fbff CPU serial number disabled. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff
Re: Linux 2.4.2ac7
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 bus. Actually, it is wrong in 2.4.2-ac6 as well -- don't know about ac5: Please send me the value of your 0x2A MTRR. Because this isnt properly intel documented there is a certain amount of research still required. 363 / 66 would be a 66Mhz bus 5.5 multiplier. It got the multiplier right but it appears the bus speed encoding may be different. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
