David Woodhouse wrote:
>[EMAIL PROTECTED] said:
>> i prefer clear oopses and bug reports instead of ignoring them. A
>> failed MSR write is not something to be taken easily. MSR writes if
>> fail mean that there is a serious kernel bug - we want to stop the
>> kernel and complain ASAP. And
On Thu, 11 Jan 2001, David Woodhouse wrote:
> The bug here seems to be that we're using the same bit
> (X86_FEATURE_APIC) to report two _different_ features.
i think that the AMD APIC is truly 'compatible', but we are trying to
enable the APIC and program performance counters in an Intel-way.
[EMAIL PROTECTED] said:
> i prefer clear oopses and bug reports instead of ignoring them. A
> failed MSR write is not something to be taken easily. MSR writes if
> fail mean that there is a serious kernel bug - we want to stop the
> kernel and complain ASAP. And correct code will be much more
[EMAIL PROTECTED] said:
i prefer clear oopses and bug reports instead of ignoring them. A
failed MSR write is not something to be taken easily. MSR writes if
fail mean that there is a serious kernel bug - we want to stop the
kernel and complain ASAP. And correct code will be much more
On Thu, 11 Jan 2001, David Woodhouse wrote:
The bug here seems to be that we're using the same bit
(X86_FEATURE_APIC) to report two _different_ features.
i think that the AMD APIC is truly 'compatible', but we are trying to
enable the APIC and program performance counters in an Intel-way.
On Wed, 10 Jan 2001, Alan Cox wrote:
> > it. I could never persuade Ingo to use wrmsr_eio() and check the
> > return code, maybe this will change his mind. Extract from kdb v1.7.
>
> I have a patch from Ingo to fix this one properly. Its just getting tested
i prefer clear oopses and bug
> This is why my original NMI for UP code in kdb uses wrmsr_eio() instead
> of wrmsr. wrmsr_eio() catches errors where the APIC does not support
> the msr and returns EIO instead of oopsing and taking the kernel with
> it. I could never persuade Ingo to use wrmsr_eio() and check the
> return
On Wed, 10 Jan 2001 15:23:14 -0500,
Nathan Walp <[EMAIL PROTECTED]> wrote:
>Here it is... I opted to cut out the 1200-odd warnings, which from the
>look of them were all because i'm running it under 2.4.0-ac4 (which
>boots fine).
ksymoops defaults to using /proc entries from the current system.
Hans Grobler wrote:
>
> On Wed, 10 Jan 2001, Nathan Walp wrote:
> > Here it is... I opted to cut out the 1200-odd warnings, which from the
> > look of them were all because i'm running it under 2.4.0-ac4 (which
> > boots fine).
>
> Thanks! My local mirror does not have -ac5 yet so I can't help
On Wed, 10 Jan 2001, Nathan Walp wrote:
> Here it is... I opted to cut out the 1200-odd warnings, which from the
> look of them were all because i'm running it under 2.4.0-ac4 (which
> boots fine).
Thanks! My local mirror does not have -ac5 yet so I can't help
immediately. From the -ac5 log &
Hans Grobler wrote:
>
> On Wed, 10 Jan 2001, Nathan Walp wrote:
> > First post to the list, hope I get this right...
>
> Could you please run this through ksymoops on your machine.
> Depending on which distribution you're using, this can be as
> simple as:
>
> ksymoops < oops.txt
>
>
On Wed, 10 Jan 2001, Nathan Walp wrote:
> First post to the list, hope I get this right...
Could you please run this through ksymoops on your machine.
Depending on which distribution you're using, this can be as
simple as:
ksymoops < oops.txt
Remember to set the System.map to the correct
First post to the list, hope I get this right...
2.4.0-ac5 oopses very early on in the boot process. I can't get the
actual oops off of the machine, but this is what i managed to type into
my laptop:
...
Getting VERSION: 40010
Getting VERSION: 40010
Getting ID: 0
Getting ID: f00
Getting
First post to the list, hope I get this right...
2.4.0-ac5 oopses very early on in the boot process. I can't get the
actual oops off of the machine, but this is what i managed to type into
my laptop:
stuff that's scrolled off screen
...
Getting VERSION: 40010
Getting VERSION: 40010
Getting ID:
On Wed, 10 Jan 2001, Nathan Walp wrote:
First post to the list, hope I get this right...
Could you please run this through ksymoops on your machine.
Depending on which distribution you're using, this can be as
simple as:
ksymoops oops.txt
Remember to set the System.map to the correct one,
Hans Grobler wrote:
On Wed, 10 Jan 2001, Nathan Walp wrote:
First post to the list, hope I get this right...
Could you please run this through ksymoops on your machine.
Depending on which distribution you're using, this can be as
simple as:
ksymoops oops.txt
Remember to set
On Wed, 10 Jan 2001, Nathan Walp wrote:
Here it is... I opted to cut out the 1200-odd warnings, which from the
look of them were all because i'm running it under 2.4.0-ac4 (which
boots fine).
Thanks! My local mirror does not have -ac5 yet so I can't help
immediately. From the -ac5 log the
Hans Grobler wrote:
On Wed, 10 Jan 2001, Nathan Walp wrote:
Here it is... I opted to cut out the 1200-odd warnings, which from the
look of them were all because i'm running it under 2.4.0-ac4 (which
boots fine).
Thanks! My local mirror does not have -ac5 yet so I can't help
On Wed, 10 Jan 2001 15:23:14 -0500,
Nathan Walp [EMAIL PROTECTED] wrote:
Here it is... I opted to cut out the 1200-odd warnings, which from the
look of them were all because i'm running it under 2.4.0-ac4 (which
boots fine).
ksymoops defaults to using /proc entries from the current system.
This is why my original NMI for UP code in kdb uses wrmsr_eio() instead
of wrmsr. wrmsr_eio() catches errors where the APIC does not support
the msr and returns EIO instead of oopsing and taking the kernel with
it. I could never persuade Ingo to use wrmsr_eio() and check the
return code,
On Wed, 10 Jan 2001, Alan Cox wrote:
it. I could never persuade Ingo to use wrmsr_eio() and check the
return code, maybe this will change his mind. Extract from kdb v1.7.
I have a patch from Ingo to fix this one properly. Its just getting tested
i prefer clear oopses and bug reports
21 matches
Mail list logo
