Martin Mares wrote:
>
...
> Please distinguish between _wrong_ stepping information and stepping
> information reported being written in format different than by the CPU
> manufacturer if the manufacturer decides to confuse users by having
> two different stepping types (one reported by the CPU and one in the
> documentation).
Sorry, I shouldn't have written "wrong", but "incorrect relative to the
manufacturer's documentation and what most people would like to see".
OTOH, I doubt Cyrix and AMD have chosen to label their processor
revisions ABC or 2.4, 2.5, 2.6 etc... just to confuse users.
Most probably this was the result of internal organizational
decisions/habits, based on their R&D effort and perhaps production
technology. Cyrix, for example, had all its chips manufactured by IBM
until recently, so they didn't control every step of the manufacturing
process.
But the fact is that when the kernel reports stepping 2.2 and the Cyrix
documentation says this is a 6x86L revision 4.2, the average user is
left wondering what kind of CPU he has under the hood.
Similarly for the AMD K6, where most users would rather see clearly that
they have a revision C processor or whatever.
And honestly, it doesn't take that much to fix the kernel code (if I can
do it, I am certain that you can do it too, since you know the kernel
code much better than I do).
The point is that you just don't _want_ to do it.
>
> > Also, I post my fixes to the kernel list, because I believe other people
> > have the same problems, and so perhaps by sharing information, we can
> > help each other.
> >
> > However, I always feel a resistance to change. An example: 7 or 8 months
> > ago, I posted both my observation of a kernel oops and a patch that
> > worked around it. Until now, it had not made it to the kernel. And only
> > because I insisted until I got half-flamed by Linus, people took notice.
>
> Well, as I still partially maintain the x86 detection code, just send
> (or Cc) all patches to me.
I did so eons ago, and more than once. Same applies to the time.c
"workaround" or whatever you want to call it.
>
> > When the average Linux user sees a Bogomips line in /proc/cpuinfo, he
> > doesn't understand what this thing means. If it said MHz, OK.
>
> He doesn't understand and he doesn't need to understand. If he wants
> CPU clock speed, he can simply get a speed measuring utility.
Which is not part of any distribution, and is not even on
sunsite.unc.edu? If we have it all cooked in the kernel, why not just
show it?
>
> > Same goes for all the bug related lines, some of which are so old that
> > they only apply to 386 CPUs (and people who are still using 386s don't
> > parse /proc/cpuinfo, believe me).
>
> I think they do as I know some counterexamples.
Are these people using 2.1.10x kernels?
Cheers,
------------------------
André Balsa
andrebalsa@altern.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu