floppy: revert floppy disable halt warning
Subsystems (2)
PATCH 1/1 floppy: revert floppy disable halt warning
Remove the stupid floppy disable halt warning. It is meaningless since the API is local to floppy driver. Our boot scripts check for the floppy drive, and this causes the warning to trigger every time. This confuses support, breaks automated tests that look for backtraces on boot, and adds no value.
The message is being displayed to the wrong audience, it looks like it was intended as a compromise of a long discussion on LKML about supporting older x86 hardware; but users don't know or understand what it is saying.
If you want to change halt handling then just fix
the floppy driver, don't whine about it.
drivers/block/floppy.c +0 -1
@@ -1037,7 +1037,6 @@ static void floppy_disable_hlt(void) {unsigned long flags; -WARN_ONCE (1 ,"floppy_disable_hlt() scheduled for removal in 2012" );spin_lock_irqsave (&floppy_hlt_lock, flags);if (!hlt_disabled) { hlt_disabled =1 ;
(cc some x86 greybeards)
Quoted 19 lines · On Sun, 11 Mar 2012 09:38:53 -0700 Stephen Hemminger <[email protected]>…
Remove the stupid floppy disable halt warning. It is meaningless since the API is local to floppy driver. Our boot scripts check for the floppy drive, and this causes the warning to trigger every time. This confuses support, breaks automated tests that look for backtraces on boot, and adds no value.
The message is being displayed to the wrong audience, it looks like it was intended as a compromise of a long discussion on LKML about supporting older x86 hardware; but users don't know or understand what it is saying.
If you want to change halt handling then just fix
the floppy driver, don't whine about it....
drivers/block/floppy.c static void floppy_disable_hlt(void) · line 1042
Quoted 7 lines
drivers/block/floppy.c +0
-1@@ -1037,7 +1037,6 @@ static void floppy_disable_hlt(void) {unsigned long flags; -WARN_ONCE (1 ,"floppy_disable_hlt() scheduled for removal in 2012" );spin_lock_irqsave (&floppy_hlt_lock, flags);if (!hlt_disabled) { hlt_disabled =1 ;
It would have been nice to have provided a pointer to this "long discussion on LKML". I tried for a while, then gave up.
In my search I came across
http://lkml.indiana.edu/hypermail/linux/kernel/1104.0/00461.html which does indeed remove all the disable_hlt() code as well as the warning and the feature-removal-schedule.txt record. Why didn't we merge that? Why shouldn't we merge that now?
Quoted 35 lines · Andrew Morton
(cc some x86 greybeards)
Quoted 19 lines · On Sun, 11 Mar 2012 09:38:53 -0700 Stephen Hemminger <[email protected]>…
Remove the stupid floppy disable halt warning. It is meaningless since the API is local to floppy driver. Our boot scripts check for the floppy drive, and this causes the warning to trigger every time. This confuses support, breaks automated tests that look for backtraces on boot, and adds no value.
The message is being displayed to the wrong audience, it looks like it was intended as a compromise of a long discussion on LKML about supporting older x86 hardware; but users don't know or understand what it is saying.
If you want to change halt handling then just fix
the floppy driver, don't whine about it....
drivers/block/floppy.c 2012-03-11 09:28:29.286579201 -0700 static void floppy_disable_hlt(void) · line 1042
Quoted 7 lines
drivers/block/floppy.c 2012-03-11 09:28:29.286579201 -0700 renamed from drivers/block/floppy.c 2012-03-11 09:27:52.866459327 -0700 +0
-1@@ -1037,7 +1037,6 @@ static void floppy_disable_hlt(void) { unsigned long flags; - WARN_ONCE(1, "floppy_disable_hlt() scheduled for removal in 2012"); spin_lock_irqsave(&floppy_hlt_lock, flags); if (!hlt_disabled) { hlt_disabled = 1;It would have been nice to have provided a pointer to this "long discussion on LKML". I tried for a while, then gave up.
Quoted 5 lines
In my search I came across
http://lkml.indiana.edu/hypermail/linux/kernel/1104.0/00461.html which does indeed remove all thedisable_hlt()code as well as the warning and the feature-removal-schedule.txt record. Why didn't we merge that? Why shouldn't we merge that now?
And again 5 months later:
https://lkml.org/lkml/2011/10/28/313
Third time's a charm? I'd buy someone a beverage if we actually went through our planned feature removal here...
josh
Quoted 43 lines · Josh Boyer
Quoted 35 lines · Andrew Morton
(cc some x86 greybeards)
Quoted 19 lines · On Sun, 11 Mar 2012 09:38:53 -0700 Stephen Hemminger <[email protected]>…
Remove the stupid floppy disable halt warning. It is meaningless since the API is local to floppy driver. Our boot scripts check for the floppy drive, and this causes the warning to trigger every time. This confuses support, breaks automated tests that look for backtraces on boot, and adds no value.
The message is being displayed to the wrong audience, it looks like it was intended as a compromise of a long discussion on LKML about supporting older x86 hardware; but users don't know or understand what it is saying.
If you want to change halt handling then just fix
the floppy driver, don't whine about it....
drivers/block/floppy.c 2012-03-11 09:28:29.286579201 -0700 static void floppy_disable_hlt(void) · line 1042
Quoted 7 lines
drivers/block/floppy.c 2012-03-11 09:28:29.286579201 -0700 renamed from drivers/block/floppy.c 2012-03-11 09:27:52.866459327 -0700 +0
-1@@ -1037,7 +1037,6 @@ static void floppy_disable_hlt(void) { unsigned long flags; - WARN_ONCE(1, "floppy_disable_hlt() scheduled for removal in 2012"); spin_lock_irqsave(&floppy_hlt_lock, flags); if (!hlt_disabled) { hlt_disabled = 1;It would have been nice to have provided a pointer to this "long discussion on LKML". I tried for a while, then gave up.
Quoted 5 lines
In my search I came across
http://lkml.indiana.edu/hypermail/linux/kernel/1104.0/00461.html which does indeed remove all thedisable_hlt()code as well as the warning and the feature-removal-schedule.txt record. Why didn't we merge that? Why shouldn't we merge that now?
Quoted 6 lines
And again 5 months later:
https://lkml.org/lkml/2011/10/28/313
Third time's a charm? I'd buy someone a beverage if we actually went through our planned feature removal here...
No objections from me.
Please resubmit against latest -tip, we unified the idle routines which likely interacts with that patch.
Thanks,
Ingo
Quoted 6 lines · Ingo Molnar
No objections from me.
Please resubmit against latest -tip, we unified the idle routines which likely interacts with that patch.
To the best of my knowledge, no-hlt only existed because of flaky power distributions on 386/486 systems which were sold to run DOS. Since DOS did no power management of any kind, including HLT, the power draw was fairly uniform; when exposed to the much higher noise levels you got when Linux used HLT caused some of these systems to fail.
They were by far in the minority even back then.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 7 lines · H. Peter Anvin
Quoted 5 lines · Ingo Molnar
No objections from me.
Please resubmit against latest -tip, we unified the idle routines which likely interacts with that patch.
Quoted 8 lines
To the best of my knowledge, no-hlt only existed because of flaky power distributions on 386/486 systems which were sold to run DOS. Since DOS did no power management of any kind, including HLT, the power draw was fairly uniform; when exposed to the much higher noise levels you got when Linux used HLT caused some of these systems to fail.
They were by far in the minority even back then.
This information should be added to the changelog.
Thanks,
Ingo
Quoted 8 lines · On Wed, 28 Mar 2012 00:20:46 -0700 "H. Peter Anvin" <[email protected]> wrote:
Quoted 6 lines · Ingo Molnar
No objections from me.
Please resubmit against latest -tip, we unified the idle routines which likely interacts with that patch.
Quoted 5 lines
To the best of my knowledge, no-hlt only existed because of flaky power distributions on 386/486 systems which were sold to run DOS. Since DOS did no power management of any kind, including HLT, the power draw was fairly uniform; when exposed to the much higher noise levels you got when Linux used HLT caused some of these systems to fail.
Also for the Cyrix 5510 which tended to go castors up if a HLT occurred during a DMA cycle and on a few other boxes HLT during DMA tended to go astray.
Do we care ? I doubt it. The 5510 was pretty obscure, the 5520 fixed it, the 5530 is probably the oldest still in any kind of use.
Alan