Hi!
> > > > For the
> > > > upstream kernel, I think it is more appropriate to expose and fix
> > > > the fundamental problems. For distro kernels, I'm less concerned
> > > > if you hide bugs instead of fixing them.
> > >
> > > This is okay as long as you are willing to work around the
Hi!
For the
upstream kernel, I think it is more appropriate to expose and fix
the fundamental problems. For distro kernels, I'm less concerned
if you hide bugs instead of fixing them.
This is okay as long as you are willing to work around the fundamental
problems in
On Tue 2007-08-07 14:58:45, Len Brown wrote:
> On Monday 06 August 2007 05:55, Pavel Machek wrote:
> > > For the
> > > upstream kernel, I think it is more appropriate to expose and fix
> > > the fundamental problems. For distro kernels, I'm less concerned
> > > if you hide bugs instead of fixing
On Monday 06 August 2007 05:55, Pavel Machek wrote:
> > For the
> > upstream kernel, I think it is more appropriate to expose and fix
> > the fundamental problems. For distro kernels, I'm less concerned
> > if you hide bugs instead of fixing them.
>
> This is okay as long as you are willing to
On Monday 06 August 2007 05:55, Pavel Machek wrote:
For the
upstream kernel, I think it is more appropriate to expose and fix
the fundamental problems. For distro kernels, I'm less concerned
if you hide bugs instead of fixing them.
This is okay as long as you are willing to work around
On Tue 2007-08-07 14:58:45, Len Brown wrote:
On Monday 06 August 2007 05:55, Pavel Machek wrote:
For the
upstream kernel, I think it is more appropriate to expose and fix
the fundamental problems. For distro kernels, I'm less concerned
if you hide bugs instead of fixing them.
Hi!
> > If we have something like this, we could still discuss a config option,
> > that also allows to increase trip points, marking it with "If you set
> > this you can destroy your machine, you have been warned...". While this
> > would not be an option for distributions to compile in, some
Hi!
If we have something like this, we could still discuss a config option,
that also allows to increase trip points, marking it with If you set
this you can destroy your machine, you have been warned While this
would not be an option for distributions to compile in, some people may
On Friday 03 August 2007 07:16, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 20:38 +0200, Andi Kleen wrote:
> > On Thu, Aug 02, 2007 at 03:57:54PM +, Pavel Machek wrote:
> > > On Thu 2007-08-02 15:16:22, Andi Kleen wrote:
> > > > On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
> >
On Friday 03 August 2007 07:43, Renato S. Yamane wrote:
> Len Brown escreveu:
> > On Thursday 02 August 2007 04:40, Knut Petersen wrote:
> >> mainboard: AOpen i915GMm-hfs, AWARD BIOS
> >> cpu: Pentium-M 750 (0.8 to 1.86 MHz)
> >> openSuSE 10.2 with kernel 2.6.22.1
> >>
> >> The cpu fan can not be
On Friday 03 August 2007 08:53, Knut Petersen wrote:
> Len Brown :
> >
> >
> > Thanks for the sighting, Knut!
> > This regression is dramatic when put in the terms of 50% performance hit!
> > I guess the good news is that thermal throttling is doing the job
> > we are asking it to:-)
> >
> >
> >
Len Brown :
>
>
> Thanks for the sighting, Knut!
> This regression is dramatic when put in the terms of 50% performance hit!
> I guess the good news is that thermal throttling is doing the job
> we are asking it to:-)
>
>
>
Thermal management by cpufreq is working really fine ;-)
My problems
Len Brown escreveu:
On Thursday 02 August 2007 04:40, Knut Petersen wrote:
mainboard: AOpen i915GMm-hfs, AWARD BIOS
cpu: Pentium-M 750 (0.8 to 1.86 MHz)
openSuSE 10.2 with kernel 2.6.22.1
The cpu fan can not be controled by linux kernel.
The BIOS will switch on the cpu fan a bit above 50 deg.
On Thu, 2007-08-02 at 20:38 +0200, Andi Kleen wrote:
> On Thu, Aug 02, 2007 at 03:57:54PM +, Pavel Machek wrote:
> > On Thu 2007-08-02 15:16:22, Andi Kleen wrote:
> > > On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
> > > > > > Set a taint flag,
> > > > > That's hardly any useful
On Thu, 2007-08-02 at 20:38 +0200, Andi Kleen wrote:
On Thu, Aug 02, 2007 at 03:57:54PM +, Pavel Machek wrote:
On Thu 2007-08-02 15:16:22, Andi Kleen wrote:
On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
Set a taint flag,
That's hardly any useful if the machine is
Len Brown :
Thanks for the sighting, Knut!
This regression is dramatic when put in the terms of 50% performance hit!
I guess the good news is that thermal throttling is doing the job
we are asking it to:-)
Thermal management by cpufreq is working really fine ;-)
My problems are
Len Brown escreveu:
On Thursday 02 August 2007 04:40, Knut Petersen wrote:
mainboard: AOpen i915GMm-hfs, AWARD BIOS
cpu: Pentium-M 750 (0.8 to 1.86 MHz)
openSuSE 10.2 with kernel 2.6.22.1
The cpu fan can not be controled by linux kernel.
The BIOS will switch on the cpu fan a bit above 50 deg.
On Friday 03 August 2007 08:53, Knut Petersen wrote:
Len Brown :
Thanks for the sighting, Knut!
This regression is dramatic when put in the terms of 50% performance hit!
I guess the good news is that thermal throttling is doing the job
we are asking it to:-)
Thermal
On Friday 03 August 2007 07:43, Renato S. Yamane wrote:
Len Brown escreveu:
On Thursday 02 August 2007 04:40, Knut Petersen wrote:
mainboard: AOpen i915GMm-hfs, AWARD BIOS
cpu: Pentium-M 750 (0.8 to 1.86 MHz)
openSuSE 10.2 with kernel 2.6.22.1
The cpu fan can not be controled by linux
On Friday 03 August 2007 07:16, Thomas Renninger wrote:
On Thu, 2007-08-02 at 20:38 +0200, Andi Kleen wrote:
On Thu, Aug 02, 2007 at 03:57:54PM +, Pavel Machek wrote:
On Thu 2007-08-02 15:16:22, Andi Kleen wrote:
On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
Set a
On Thursday 02 August 2007 05:45, Adrian Schröter wrote:
> On Thursday 02 August 2007 11:42:27 wrote Thomas Renninger:
> > On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote:
> > > Hi everybody!
> > >
> > > Kernel 2.6.22 decreases performance by about 50% on my system.
> > > No, I do not like
On Thursday 02 August 2007 04:40, Knut Petersen wrote:
> Kernel 2.6.22 decreases performance by about 50% on my system.
> No, I do not like that. The reason is a broken BIOS, granted, but there
> was a perfect workaround in the kernel that has been dropped.
>
> mainboard: AOpen i915GMm-hfs,
Knut Petersen <[EMAIL PROTECTED]> writes:
> echo "I know what I am doing" >
> /proc/acpi/thermal_zone/THRM/enable_really_dangerous_options
There is a shorter version:
$ su
Password:
#
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Thu, Aug 02, 2007 at 08:38:30PM +0200, Andi Kleen wrote:
> On Thu, Aug 02, 2007 at 03:57:54PM +, Pavel Machek wrote:
> > Yes, but it was original BIOS trip points that were wrong. And yes,
> > its failsafe shutdown was too late. At least lowering the trip points
> > would allow me to run it
On Thu, Aug 02, 2007 at 03:57:54PM +, Pavel Machek wrote:
> On Thu 2007-08-02 15:16:22, Andi Kleen wrote:
> > On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
> > > > > Set a taint flag,
> > > > That's hardly any useful if the machine is dead afterwards.
> > >
> > > It won't be the
Hi!
> Well, it would not be the first time to eliminate a regression by
> reverting a
> patch after it was accepted previously.
> >> Sanity checks that trip points only can get lowered (compared to initial
> >> provided ones) needs to be added.
> >> Len, Rui: For short-term can some
> But I
On Thu 2007-08-02 15:16:22, Andi Kleen wrote:
> On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
> > > > Set a taint flag,
> > > That's hardly any useful if the machine is dead afterwards.
> >
> > It won't be the hardware will do a failsafe shutdown first.
>
> Not necessarily. At SUSE
Hi!
> > I didn't understand the arguments either, actually.
>
> The issue is that you can actually kill hardware by setting this wrong.
> We've had such cases where trip point problems eventually lead
> to overheated laptops with hard disks dying etc.
Actually, that was my machine. Omnibook
On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
> > > Set a taint flag,
> > That's hardly any useful if the machine is dead afterwards.
>
> It won't be the hardware will do a failsafe shutdown first.
Not necessarily. At SUSE we had at least one broken laptop
with wrong trip points.
> > Andi, would the above be mechanism sufficiently safe for your taste?
>
> No.
I don't beleve Andi's taste (or lack thereof) is relevant to this
discussion. He's not for example explained why its better to force people
to disable all the APCI power and thermal control on their system rather
> > Set a taint flag,
> That's hardly any useful if the machine is dead afterwards.
It won't be the hardware will do a failsafe shutdown first.
> You'll just end up with "Linux destroyed my laptop" headlines all
> over the internet and rightfully very annoyed users.
You have to systematically
On Thu, Aug 02, 2007 at 02:42:19PM +0200, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 12:56 +0100, Matthew Garrett wrote:
> > The policy has been to attempt to be bug-compatible with Windows
> > whenever possible for some time now.
> *whenever possible*
But there's no evidence whatsoever
On Thu, Aug 02, 2007 at 02:35:18PM +0200, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 13:15 +0100, Matthew Garrett wrote:
> > That machine has no active thermal trip points, so I'm not sure how it's
> > relevant here.
> >From above: "Windows as I understand it has vendor mechanisms to..."
>
On Thu, 2007-08-02 at 12:56 +0100, Matthew Garrett wrote:
> On Thu, Aug 02, 2007 at 01:45:00PM +0200, Thomas Renninger wrote:
> > On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
> > > I strongly suspect that the vast majority[1] of hardware that "needs"
> > > the trip points changing
On Thu, 2007-08-02 at 13:15 +0100, Matthew Garrett wrote:
> On Thu, Aug 02, 2007 at 02:06:26PM +0200, Thomas Renninger wrote:
> > On Thu, 2007-08-02 at 12:57 +0100, Matthew Garrett wrote:
> > > On Thu, Aug 02, 2007 at 12:59:47PM +0100, Alan Cox wrote:
> > > > Windows as I understand it has vendor
On Thu, Aug 02, 2007 at 02:06:26PM +0200, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 12:57 +0100, Matthew Garrett wrote:
> > On Thu, Aug 02, 2007 at 12:59:47PM +0100, Alan Cox wrote:
> > > Windows as I understand it has vendor mechanisms to allow the bits
> > > shipped with the OS to
> Andi Kleen wrote:
>
> > I don't think it's that unreasonable to require source code
> modifications
> > for anything that can kill hardware. At least that raises the barrier
> > a bit and hopefully ensures people think twice about it and then really
> > only blame themselves if
On Thu, 2007-08-02 at 12:57 +0100, Matthew Garrett wrote:
> On Thu, Aug 02, 2007 at 12:59:47PM +0100, Alan Cox wrote:
> > > I strongly suspect that the vast majority[1] of hardware that "needs"
> > > the trip points changing works perfectly well under Windows, so it's
> >
> > Windows as I
> Set a taint flag,
That's hardly any useful if the machine is dead afterwards.
> print a loud message
Neither.
You'll just end up with "Linux destroyed my laptop" headlines all
over the internet and rightfully very annoyed users.
> Or have you forgotten the original Unix
> philosophy too
On Thu, Aug 02, 2007 at 12:59:47PM +0100, Alan Cox wrote:
> > I strongly suspect that the vast majority[1] of hardware that "needs"
> > the trip points changing works perfectly well under Windows, so it's
>
> Windows as I understand it has vendor mechanisms to allow the bits
> shipped with the
On Thu, Aug 02, 2007 at 01:45:00PM +0200, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
> > I strongly suspect that the vast majority[1] of hardware that "needs"
> > the trip points changing works perfectly well under Windows, so it's
> > likely to be
> I strongly suspect that the vast majority[1] of hardware that "needs"
> the trip points changing works perfectly well under Windows, so it's
Windows as I understand it has vendor mechanisms to allow the bits
shipped with the OS to override/ignore just about everything trip points
included.
On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
> On Thu, Aug 02, 2007 at 12:02:21PM +0100, Alan Cox wrote:
> > > Anyway, only solution/workaround to use these machines with current
> > > kernels is to override trip points, maybe the patch should really just
> > > be reverted...
> >
> >
Thomas Renninger wrote:
>> mainboard: AOpen i915GMm-hfs, AWARD BIOS
>> cpu: Pentium-M 750 (0.8 to 1.86 MHz)
>> openSuSE 10.2 with kernel 2.6.22.1
> Is this a DELL laptop that gets throttled by 75% to throttling state 6
> if 60 degrees are exceeded?
No, it is a Pentium M desktop board.:
Chipset
On Thu, Aug 02, 2007 at 12:02:21PM +0100, Alan Cox wrote:
> > Anyway, only solution/workaround to use these machines with current
> > kernels is to override trip points, maybe the patch should really just
> > be reverted...
>
> The question really is whether the vendors will all revert it and
> Anyway, only solution/workaround to use these machines with current
> kernels is to override trip points, maybe the patch should really just
> be reverted...
The question really is whether the vendors will all revert it and carry
it as a patch or whether the main tree will accept reality on
> Also it runs the system out of spec and is similar to overclocking
> which we also do not support.
We do not systematically prevent overclocking. There are lots of cases
where altering the trip points is helpful, and if you look in vendor
bugzilla databases there are multiple moans from people
On Thu, 2007-08-02 at 11:45 +0200, Adrian Schröter wrote:
> On Thursday 02 August 2007 11:42:27 wrote Thomas Renninger:
> > On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote:
> > > Hi everybody!
> > >
> > > Kernel 2.6.22 decreases performance by about 50% on my system.
> > > No, I do not like
Andrew Morton <[EMAIL PROTECTED]> writes:
> I didn't understand the arguments either, actually.
The issue is that you can actually kill hardware by setting this wrong.
We've had such cases where trip point problems eventually lead
to overheated laptops with hard disks dying etc.
Also it runs
On Thursday 02 August 2007 11:42:27 wrote Thomas Renninger:
> On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote:
> > Hi everybody!
> >
> > Kernel 2.6.22 decreases performance by about 50% on my system.
> > No, I do not like that. The reason is a broken BIOS, granted, but there
> > was a
On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote:
> Hi everybody!
>
> Kernel 2.6.22 decreases performance by about 50% on my system.
> No, I do not like that. The reason is a broken BIOS, granted, but there
> was a perfect workaround in the kernel that has been dropped.
>
> mainboard:
On Thu, 02 Aug 2007 10:40:44 +0200 Knut Petersen <[EMAIL PROTECTED]> wrote:
> Hi everybody!
>
> Kernel 2.6.22 decreases performance by about 50% on my system.
> No, I do not like that. The reason is a broken BIOS, granted, but there
> was a perfect workaround in the kernel that has been dropped.
On Thu, 02 Aug 2007 10:40:44 +0200 Knut Petersen [EMAIL PROTECTED] wrote:
Hi everybody!
Kernel 2.6.22 decreases performance by about 50% on my system.
No, I do not like that. The reason is a broken BIOS, granted, but there
was a perfect workaround in the kernel that has been dropped.
On Thu, 2007-08-02 at 11:45 +0200, Adrian Schröter wrote:
On Thursday 02 August 2007 11:42:27 wrote Thomas Renninger:
On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote:
Hi everybody!
Kernel 2.6.22 decreases performance by about 50% on my system.
No, I do not like that. The
On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote:
Hi everybody!
Kernel 2.6.22 decreases performance by about 50% on my system.
No, I do not like that. The reason is a broken BIOS, granted, but there
was a perfect workaround in the kernel that has been dropped.
mainboard: AOpen
On Thursday 02 August 2007 11:42:27 wrote Thomas Renninger:
On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote:
Hi everybody!
Kernel 2.6.22 decreases performance by about 50% on my system.
No, I do not like that. The reason is a broken BIOS, granted, but there
was a perfect
Andrew Morton [EMAIL PROTECTED] writes:
I didn't understand the arguments either, actually.
The issue is that you can actually kill hardware by setting this wrong.
We've had such cases where trip point problems eventually lead
to overheated laptops with hard disks dying etc.
Also it runs the
Also it runs the system out of spec and is similar to overclocking
which we also do not support.
We do not systematically prevent overclocking. There are lots of cases
where altering the trip points is helpful, and if you look in vendor
bugzilla databases there are multiple moans from people
Anyway, only solution/workaround to use these machines with current
kernels is to override trip points, maybe the patch should really just
be reverted...
The question really is whether the vendors will all revert it and carry
it as a patch or whether the main tree will accept reality on this
On Thu, Aug 02, 2007 at 12:02:21PM +0100, Alan Cox wrote:
Anyway, only solution/workaround to use these machines with current
kernels is to override trip points, maybe the patch should really just
be reverted...
The question really is whether the vendors will all revert it and carry
it
Thomas Renninger wrote:
mainboard: AOpen i915GMm-hfs, AWARD BIOS
cpu: Pentium-M 750 (0.8 to 1.86 MHz)
openSuSE 10.2 with kernel 2.6.22.1
Is this a DELL laptop that gets throttled by 75% to throttling state 6
if 60 degrees are exceeded?
No, it is a Pentium M desktop board.:
Chipset i915GM,
On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
On Thu, Aug 02, 2007 at 12:02:21PM +0100, Alan Cox wrote:
Anyway, only solution/workaround to use these machines with current
kernels is to override trip points, maybe the patch should really just
be reverted...
The question
On Thu, Aug 02, 2007 at 01:45:00PM +0200, Thomas Renninger wrote:
On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
I strongly suspect that the vast majority[1] of hardware that needs
the trip points changing works perfectly well under Windows, so it's
likely to be papering over
I strongly suspect that the vast majority[1] of hardware that needs
the trip points changing works perfectly well under Windows, so it's
Windows as I understand it has vendor mechanisms to allow the bits
shipped with the OS to override/ignore just about everything trip points
included. Lots
On Thu, Aug 02, 2007 at 02:06:26PM +0200, Thomas Renninger wrote:
On Thu, 2007-08-02 at 12:57 +0100, Matthew Garrett wrote:
On Thu, Aug 02, 2007 at 12:59:47PM +0100, Alan Cox wrote:
Windows as I understand it has vendor mechanisms to allow the bits
shipped with the OS to override/ignore
On Thu, Aug 02, 2007 at 12:59:47PM +0100, Alan Cox wrote:
I strongly suspect that the vast majority[1] of hardware that needs
the trip points changing works perfectly well under Windows, so it's
Windows as I understand it has vendor mechanisms to allow the bits
shipped with the OS to
Set a taint flag,
That's hardly any useful if the machine is dead afterwards.
print a loud message
Neither.
You'll just end up with Linux destroyed my laptop headlines all
over the internet and rightfully very annoyed users.
Or have you forgotten the original Unix
philosophy too ?
The
Andi Kleen wrote:
I don't think it's that unreasonable to require source code
modifications
for anything that can kill hardware. At least that raises the barrier
a bit and hopefully ensures people think twice about it and then really
only blame themselves if anything goes
On Thu, 2007-08-02 at 12:57 +0100, Matthew Garrett wrote:
On Thu, Aug 02, 2007 at 12:59:47PM +0100, Alan Cox wrote:
I strongly suspect that the vast majority[1] of hardware that needs
the trip points changing works perfectly well under Windows, so it's
Windows as I understand it has
On Thu, 2007-08-02 at 12:56 +0100, Matthew Garrett wrote:
On Thu, Aug 02, 2007 at 01:45:00PM +0200, Thomas Renninger wrote:
On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
I strongly suspect that the vast majority[1] of hardware that needs
the trip points changing works
On Thu, Aug 02, 2007 at 02:35:18PM +0200, Thomas Renninger wrote:
On Thu, 2007-08-02 at 13:15 +0100, Matthew Garrett wrote:
That machine has no active thermal trip points, so I'm not sure how it's
relevant here.
From above: Windows as I understand it has vendor mechanisms to...
Maybe
On Thu, Aug 02, 2007 at 02:42:19PM +0200, Thomas Renninger wrote:
On Thu, 2007-08-02 at 12:56 +0100, Matthew Garrett wrote:
The policy has been to attempt to be bug-compatible with Windows
whenever possible for some time now.
*whenever possible*
But there's no evidence whatsoever that this
Set a taint flag,
That's hardly any useful if the machine is dead afterwards.
It won't be the hardware will do a failsafe shutdown first.
You'll just end up with Linux destroyed my laptop headlines all
over the internet and rightfully very annoyed users.
You have to systematically sit
On Thu, 2007-08-02 at 13:15 +0100, Matthew Garrett wrote:
On Thu, Aug 02, 2007 at 02:06:26PM +0200, Thomas Renninger wrote:
On Thu, 2007-08-02 at 12:57 +0100, Matthew Garrett wrote:
On Thu, Aug 02, 2007 at 12:59:47PM +0100, Alan Cox wrote:
Windows as I understand it has vendor mechanisms
On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
Set a taint flag,
That's hardly any useful if the machine is dead afterwards.
It won't be the hardware will do a failsafe shutdown first.
Not necessarily. At SUSE we had at least one broken laptop
with wrong trip points. The
Andi, would the above be mechanism sufficiently safe for your taste?
No.
I don't beleve Andi's taste (or lack thereof) is relevant to this
discussion. He's not for example explained why its better to force people
to disable all the APCI power and thermal control on their system rather
than
Hi!
I didn't understand the arguments either, actually.
The issue is that you can actually kill hardware by setting this wrong.
We've had such cases where trip point problems eventually lead
to overheated laptops with hard disks dying etc.
Actually, that was my machine. Omnibook xe3;
On Thu 2007-08-02 15:16:22, Andi Kleen wrote:
On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
Set a taint flag,
That's hardly any useful if the machine is dead afterwards.
It won't be the hardware will do a failsafe shutdown first.
Not necessarily. At SUSE we had at
Hi!
Well, it would not be the first time to eliminate a regression by
reverting a
patch after it was accepted previously.
Sanity checks that trip points only can get lowered (compared to initial
provided ones) needs to be added.
Len, Rui: For short-term can some
But I _need_ to raise
On Thu, Aug 02, 2007 at 03:57:54PM +, Pavel Machek wrote:
On Thu 2007-08-02 15:16:22, Andi Kleen wrote:
On Thu, Aug 02, 2007 at 02:04:42PM +0100, Alan Cox wrote:
Set a taint flag,
That's hardly any useful if the machine is dead afterwards.
It won't be the hardware will do a
On Thu, Aug 02, 2007 at 08:38:30PM +0200, Andi Kleen wrote:
On Thu, Aug 02, 2007 at 03:57:54PM +, Pavel Machek wrote:
Yes, but it was original BIOS trip points that were wrong. And yes,
its failsafe shutdown was too late. At least lowering the trip points
would allow me to run it
Knut Petersen [EMAIL PROTECTED] writes:
echo I know what I am doing
/proc/acpi/thermal_zone/THRM/enable_really_dangerous_options
There is a shorter version:
$ su
Password:
#
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Thursday 02 August 2007 04:40, Knut Petersen wrote:
Kernel 2.6.22 decreases performance by about 50% on my system.
No, I do not like that. The reason is a broken BIOS, granted, but there
was a perfect workaround in the kernel that has been dropped.
mainboard: AOpen i915GMm-hfs, AWARD
On Thursday 02 August 2007 05:45, Adrian Schröter wrote:
On Thursday 02 August 2007 11:42:27 wrote Thomas Renninger:
On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen wrote:
Hi everybody!
Kernel 2.6.22 decreases performance by about 50% on my system.
No, I do not like that. The
84 matches
Mail list logo
