Hi,
ext Andi Kleen wrote:
So what can we do about the clflush on this CPU?
I'll just remove that CLFLUSH statement. It was just supposed
to be an optimization, but is not strictly needed.
2.6.23-rc6 boots up fine on my box. Regression fixed. Thanks.
Regards,
Stefan
---
Stefan
Hi,
ext Andi Kleen wrote:
So what can we do about the clflush on this CPU?
I'll just remove that CLFLUSH statement. It was just supposed
to be an optimization, but is not strictly needed.
2.6.23-rc6 boots up fine on my box. Regression fixed. Thanks.
Regards,
Stefan
---
Stefan
Hi,
ext Andi Kleen wrote:
This kernel boots up OK. Looking at the preprocessed C code the
I assume you tested it a few times to make sure it really was the
problem? Perhaps reenable it also once again and see if it hangs
again just to be sure.
I booted each kernel at least 5 times:
Hi,
ext Dave Jones wrote:
Could be that even though it advertises clflush support there are
errata on some revs of the CPU. Can you paste your /proc/cpuinfo,
and I'll check with VIA to find out if they're aware of any
known problems and if so, find out the range of steppings we
need to not
On Wed, Sep 05, 2007 at 10:24:07PM +0300, Stefan Becker wrote:
> #if 0
> if (cpu_has_clflush)
> asm("clflush (%0) " :: "r" (addr) : "memory");
> #endif
> }
>
> This kernel boots up OK. Looking at the preprocessed C code the
> following code in
On Wed, Sep 05, 2007 at 10:24:07PM +0300, Stefan Becker wrote:
#if 0
if (cpu_has_clflush)
asm(clflush (%0) :: r (addr) : memory);
#endif
}
This kernel boots up OK. Looking at the preprocessed C code the
following code in alternative_instructions() is compiled
Hi,
ext Dave Jones wrote:
Could be that even though it advertises clflush support there are
errata on some revs of the CPU. Can you paste your /proc/cpuinfo,
and I'll check with VIA to find out if they're aware of any
known problems and if so, find out the range of steppings we
need to not
Hi,
ext Andi Kleen wrote:
This kernel boots up OK. Looking at the preprocessed C code the
I assume you tested it a few times to make sure it really was the
problem? Perhaps reenable it also once again and see if it hangs
again just to be sure.
I booted each kernel at least 5 times:
> This kernel boots up OK. Looking at the preprocessed C code the
I assume you tested it a few times to make sure it really was the
problem? Perhaps reenable it also once again and see if it hangs
again just to be sure.
> So what can we do about the clflush on this CPU?
I'll just remove that
Hi,
ext Andi Kleen wrote:
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge cmov pat
clflush acpi mmx fxsr sse sse2 tm up pni est tm2 rng rng_en ace ace_en
Hmm, I can't really see anything wrong. This means the original
version of the patch you found had a few problems, but they
were
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge cmov pat
> clflush acpi mmx fxsr sse sse2 tm up pni est tm2 rng rng_en ace ace_en
Hmm, I can't really see anything wrong. This means the original
version of the patch you found had a few problems, but they
were all fixed later
Hi,
ext Andi Kleen wrote:
Please report for mainline kernels.
I compiled a vanilla 2.6.23-rc5 kernel. Same problem. Still no sensible
debug information though...
Thanks. If you can easily reproduce it would it be possible to
do a git bisect to track down which change caused it?
See
> >Please report for mainline kernels.
>
> I compiled a vanilla 2.6.23-rc5 kernel. Same problem. Still no sensible
> debug information though...
Thanks. If you can easily reproduce it would it be possible to
do a git bisect to track down which change caused it?
See
Please report for mainline kernels.
I compiled a vanilla 2.6.23-rc5 kernel. Same problem. Still no sensible
debug information though...
Thanks. If you can easily reproduce it would it be possible to
do a git bisect to track down which change caused it?
See http://kerneltrap.org/node/11753
Hi,
ext Andi Kleen wrote:
Please report for mainline kernels.
I compiled a vanilla 2.6.23-rc5 kernel. Same problem. Still no sensible
debug information though...
Thanks. If you can easily reproduce it would it be possible to
do a git bisect to track down which change caused it?
See
Hi,
ext Andi Kleen wrote:
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge cmov pat
clflush acpi mmx fxsr sse sse2 tm up pni est tm2 rng rng_en ace ace_en
Hmm, I can't really see anything wrong. This means the original
version of the patch you found had a few problems, but they
were
Stefan Becker <[EMAIL PROTECTED]> writes:
> while trying to debug a hibernation/rtc_cmos alarm wakeup problem in
> 2.6.22 (or later) I noticed that the latest kernel crashes (or gets
> stuck sometimes) during boot after the message:
>
> SMP alternatives: switching to UP code
>
> Every kernel up
On Mon, 03 Sep 2007 08:59:58 +0300 Stefan Becker wrote:
> Hi,
>
> > Stefan Becker wrote:
> >>
> >> while trying to debug a hibernation/rtc_cmos alarm wakeup problem in
> >> 2.6.22 (or later) I noticed that the latest kernel crashes (or gets
> >> stuck sometimes) during boot after the message:
Hi,
Stefan Becker wrote:
while trying to debug a hibernation/rtc_cmos alarm wakeup problem in
2.6.22 (or later) I noticed that the latest kernel crashes (or gets
stuck sometimes) during boot after the message:
SMP alternatives: switching to UP code
Retested with 2.6.23-rc4. Same result.
Hi,
Stefan Becker wrote:
while trying to debug a hibernation/rtc_cmos alarm wakeup problem in
2.6.22 (or later) I noticed that the latest kernel crashes (or gets
stuck sometimes) during boot after the message:
SMP alternatives: switching to UP code
Retested with 2.6.23-rc4. Same result.
On Mon, 03 Sep 2007 08:59:58 +0300 Stefan Becker wrote:
Hi,
Stefan Becker wrote:
while trying to debug a hibernation/rtc_cmos alarm wakeup problem in
2.6.22 (or later) I noticed that the latest kernel crashes (or gets
stuck sometimes) during boot after the message:
SMP
Stefan Becker [EMAIL PROTECTED] writes:
while trying to debug a hibernation/rtc_cmos alarm wakeup problem in
2.6.22 (or later) I noticed that the latest kernel crashes (or gets
stuck sometimes) during boot after the message:
SMP alternatives: switching to UP code
Every kernel up to
Hi,
Stefan Becker wrote:
while trying to debug a hibernation/rtc_cmos alarm wakeup problem in
2.6.22 (or later) I noticed that the latest kernel crashes (or gets
stuck sometimes) during boot after the message:
SMP alternatives: switching to UP code
Retested with 2.6.23-rc3-git10. Same
Hi,
Stefan Becker wrote:
while trying to debug a hibernation/rtc_cmos alarm wakeup problem in
2.6.22 (or later) I noticed that the latest kernel crashes (or gets
stuck sometimes) during boot after the message:
SMP alternatives: switching to UP code
Retested with 2.6.23-rc3-git10. Same
24 matches
Mail list logo
