[PATCH 1/2] longhaul: Mark it as dangerous in Kconfig

[PATCH 1/2] longhaul: Mark it as dangerous in Kconfig

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

longhaul quickly caused hard lockups and possibly killed the memory
module on my EPIA-PD board.  It is commented as:

'BIG FAT DISCLAIMER: Work in progress code. Possibly *dangerous*'

Let's put another warning where people are more likely to see it.

References: https://bugs.debian.org/707047
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 drivers/cpufreq/Kconfig.x86 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index d369349..a3877c6 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -247,12 +247,13 @@ config X86_LONGRUN
 	  If in doubt, say N.
 
 config X86_LONGHAUL
-	tristate "VIA Cyrix III Longhaul"
+	tristate "VIA Cyrix III Longhaul (DANGEROUS)"
 	depends on X86_32 && ACPI_PROCESSOR
 	help
 	  This adds the CPUFreq driver for VIA Samuel/CyrixIII,
 	  VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T
-	  processors.
+	  processors.  It does not work with all motherboards and may
+	  cause hardware damage.
 
 	  For details, take a look at <file:Documentation/cpu-freq/>.
 

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 1/2] longhaul: Mark it as dangerous in Kconfig

[Dave Jones]

On Mon, Jun 09, 2014 at 12:20:42AM +0100, Ben Hutchings wrote:
 > longhaul quickly caused hard lockups and possibly killed the memory
 > module on my EPIA-PD board.  It is commented as:
 > 
 > 'BIG FAT DISCLAIMER: Work in progress code. Possibly *dangerous*'

that last part may have been overly dramatic. When I was originally
writing this driver I was using pre-production cpu's which were
marginal to begin with. Production hw should have been more tolerant.
What didn't help was a lot of the EPIAs were made with *Really*
shitty capacitors that would pop open and ooze over the boards. Might want
to eyeball those, you can usually tell when they've gone bad.

 > Let's put another warning where people are more likely to see it.

That said, I'm not against itbeing marked BROKEN (I thought it
already was), and certainly don't recommend distros enabling it.

I'd also not stand in the way of someone throwing it out completely
given the small amount of systems out there likely still running this.

	Dave

Re: [PATCH 1/2] longhaul: Mark it as dangerous in Kconfig

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

On Sun, 2014-06-08 at 20:02 -0400, Dave Jones wrote:
> On Mon, Jun 09, 2014 at 12:20:42AM +0100, Ben Hutchings wrote:
>  > longhaul quickly caused hard lockups and possibly killed the memory
>  > module on my EPIA-PD board.  It is commented as:
>  > 
>  > 'BIG FAT DISCLAIMER: Work in progress code. Possibly *dangerous*'
> 
> that last part may have been overly dramatic. When I was originally
> writing this driver I was using pre-production cpu's which were
> marginal to begin with. Production hw should have been more tolerant.
> What didn't help was a lot of the EPIAs were made with *Really*
> shitty capacitors that would pop open and ooze over the boards. Might want
> to eyeball those, you can usually tell when they've gone bad.

I threw the board out last year, but didn't notice any such damage.  The
failure occurred *immediately* after I loaded the driver (when
auto-loading was enabled), while the board had been stable for several
years up to that point.  And the board started working again after I
replaced the memory module and prevented the driver from loading.  Of
course, it *could* just be coincidence that the memory went bad then.  I
didn't feel like testing that!

Activation of the driver is now guarded by a module parameter, so even
with auto-loading enabled it doesn't do any damage by default.

Ben.

>  > Let's put another warning where people are more likely to see it.
> 
> That said, I'm not against itbeing marked BROKEN (I thought it
> already was), and certainly don't recommend distros enabling it.
> 
> I'd also not stand in the way of someone throwing it out completely
> given the small amount of systems out there likely still running this.
> 
> 	Dave
> 

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 1/2] longhaul: Mark it as dangerous in Kconfig

[Viresh Kumar]

On 9 June 2014 04:50, Ben Hutchings <ben@decadent.org.uk> wrote:
> longhaul quickly caused hard lockups and possibly killed the memory
> module on my EPIA-PD board.  It is commented as:
>
> 'BIG FAT DISCLAIMER: Work in progress code. Possibly *dangerous*'
>
> Let's put another warning where people are more likely to see it.
>
> References: https://bugs.debian.org/707047
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
>  drivers/cpufreq/Kconfig.x86 | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
> index d369349..a3877c6 100644
> --- a/drivers/cpufreq/Kconfig.x86
> +++ b/drivers/cpufreq/Kconfig.x86
> @@ -247,12 +247,13 @@ config X86_LONGRUN
>           If in doubt, say N.
>
>  config X86_LONGHAUL
> -       tristate "VIA Cyrix III Longhaul"
> +       tristate "VIA Cyrix III Longhaul (DANGEROUS)"
>         depends on X86_32 && ACPI_PROCESSOR
>         help
>           This adds the CPUFreq driver for VIA Samuel/CyrixIII,
>           VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T
> -         processors.
> +         processors.  It does not work with all motherboards and may
> +         cause hardware damage.
>
>           For details, take a look at <file:Documentation/cpu-freq/>.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

Re: [PATCH 1/2] longhaul: Mark it as dangerous in Kconfig

[Rafał Bilski]

W dniu 09.06.2014 01:02, Dave Jones pisze:
> On Mon, Jun 09, 2014 at 12:20:42AM +0100, Ben Hutchings wrote:
>   > longhaul quickly caused hard lockups and possibly killed the memory
>   > module on my EPIA-PD board.  It is commented as:
>   >
>   > 'BIG FAT DISCLAIMER: Work in progress code. Possibly *dangerous*'
>
> that last part may have been overly dramatic. When I was originally
> writing this driver I was using pre-production cpu's which were
> marginal to begin with. Production hw should have been more tolerant.
> What didn't help was a lot of the EPIAs were made with *Really*
> shitty capacitors that would pop open and ooze over the boards. Might want
> to eyeball those, you can usually tell when they've gone bad.
>
>   > Let's put another warning where people are more likely to see it.
>
> That said, I'm not against itbeing marked BROKEN (I thought it
> already was), and certainly don't recommend distros enabling it.
>
> I'd also not stand in the way of someone throwing it out completely
> given the small amount of systems out there likely still running this.
>
> 	Dave
>
>
If I may I would like to agree with Dave Jones. There is no point
in changing text which nobody will see in their logs. If somebody
wants to use the driver it is very easy now to compile module outside
the kernel tree. I didn't expected possibility of hardware damage
because driver just puts CPU to sleep to change frequency, but
VIA products have been full of bugs so looks like anything is
possible. Another matter is we have got these "dynamic ticks" in kernel
now and code in driver expects monotonic ticks and abuses them a bit
in order to be able to wake CPU from sleep. Does it make it obsolete?

Rafał Bilski