bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Uwe Bugla]

Hi folks,
Second attempt now:
I already reported to Linus Torvalds and Andrew Morton that it is impossible to mount a conventional floppy drive without hanging up the whole system.
Andrew's reaction was quite ambiguous: "We did not break it"

Once again and for the last time: I do not state that floppy.c is broken. I only state that it is immpossible to mount a floppy drive with kernel 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely buggy!
I did some work already:
a. I copied the following modules from the intact and sane kernel 2.6.20 into the 2.6.21-rc1-git1 tree:
cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h, uaccess.h
b. I adjusted some hunks of the patch for module main.c (part of patch-2.6.21-rc1) to make the kernel compile without errors.
But the problem still persists, and I do not have any idea anymore where the offensive hunks in patch-2.6.21-rc1 could reside.

Questions:
a. Can someone please confirm the described problem?
b. Can someone please take action to find out where the buggy code resides?
c. Why is this untested material being pushed into main vanilla - what is going on at kernel.org please?

Please take action! The bug was introduced somewhere at the transition of 2.6.20 towards 2.6.20-git14.

Yours sincerely

Uwe

P. S.: I once again repeat my proposal: Every patch code should be tested before it is being pushed into main vanilla.
The testing tree is the mm-tree.
If this policy producing regressions persists noone takes advantage of! So please avoid those regressions in future!
If this rule "test your changes, however small, on at least 4 or 5 people" does not apply to absolutely everybody then it is worth nothing!
My platform is i386, Intel ICH4 and I am using floppy.c (Normal floppy disk support).

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Andrew Morton]

> On Sat, 24 Feb 2007 18:54:24 +0100 "Uwe Bugla" <uwe.bugla@gmx.de> wrote:
> Hi folks,
> Second attempt now:
> I already reported to Linus Torvalds and Andrew Morton that it is impossible to mount a conventional floppy drive without hanging up the whole system.
> Andrew's reaction was quite ambiguous: "We did not break it"

Sorry, what I meant was "Neither Linus nor I broke it".  ie: please report
this in a place where the person who did break it can see it.  This you have
done.

> Once again and for the last time: I do not state that floppy.c is broken. I only state that it is immpossible to mount a floppy drive with kernel 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely buggy!
> I did some work already:
> a. I copied the following modules from the intact and sane kernel 2.6.20 into the 2.6.21-rc1-git1 tree:
> cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h, uaccess.h
> b. I adjusted some hunks of the patch for module main.c (part of patch-2.6.21-rc1) to make the kernel compile without errors.
> But the problem still persists, and I do not have any idea anymore where the offensive hunks in patch-2.6.21-rc1 could reside.
> 
> Questions:
> a. Can someone please confirm the described problem?
> b. Can someone please take action to find out where the buggy code resides?
> c. Why is this untested material being pushed into main vanilla - what is going on at kernel.org please?
> 
> Please take action! The bug was introduced somewhere at the transition of 2.6.20 towards 2.6.20-git14.
> 

I think we'll find that it works OK for hundreds of other people, so it got
broken in some manner which is specific to a very small number of machines,
of which yours is one.

If that theory proves to be correct, I'm afraid that the most proactical
way of fixing this is to ask you to run a git-bisect to find the changeset
which introduced the regression.

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Sat, 24 Feb 2007 10:07:29 -0800
Von: Andrew Morton <akpm@linux-foundation.org>
An: "Uwe Bugla" <uwe.bugla@gmx.de>
CC: torvalds@linux-foundation.org, bunk@stusta.de, linux-kernel@vger.kernel.org
Betreff: Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

> > On Sat, 24 Feb 2007 18:54:24 +0100 "Uwe Bugla" <uwe.bugla@gmx.de> wrote:
> > Hi folks,
> > Second attempt now:
> > I already reported to Linus Torvalds and Andrew Morton that it is
> impossible to mount a conventional floppy drive without hanging up the whole
> system.
> > Andrew's reaction was quite ambiguous: "We did not break it"
> 
> Sorry, what I meant was "Neither Linus nor I broke it".  ie: please report
> this in a place where the person who did break it can see it.  This you
> have
> done.
OK, accepted - sorry!
> 
> > Once again and for the last time: I do not state that floppy.c is
> broken. I only state that it is immpossible to mount a floppy drive with kernel
> 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely
> buggy!
> > I did some work already:
> > a. I copied the following modules from the intact and sane kernel 2.6.20
> into the 2.6.21-rc1-git1 tree:
> > cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h,
> uaccess.h
> > b. I adjusted some hunks of the patch for module main.c (part of
> patch-2.6.21-rc1) to make the kernel compile without errors.
> > But the problem still persists, and I do not have any idea anymore where
> the offensive hunks in patch-2.6.21-rc1 could reside.
> > 
> > Questions:
> > a. Can someone please confirm the described problem?
> > b. Can someone please take action to find out where the buggy code
> resides?
> > c. Why is this untested material being pushed into main vanilla - what
> is going on at kernel.org please?
> > 
> > Please take action! The bug was introduced somewhere at the transition
> of 2.6.20 towards 2.6.20-git14.
> > 
> 
> I think we'll find that it works OK for hundreds of other people, so it
> got
> broken in some manner which is specific to a very small number of
> machines,
> of which yours is one.
> 
> If that theory proves to be correct, I'm afraid that the most proactical
> way of fixing this is to ask you to run a git-bisect to find the changeset
> which introduced the regression.
Guess this theory is wrong but lets wait and see to prove who is right!
> 
OK, Andrew,
Problem: I do not have internet at home, I am sitting in a friends flat now.
So you cannot expect me to download all git patches of 2.6.20 to test.
Could you please explain the procedure of bisecting?
Above that I've spent hours to find out the essence of the problem and I am really beat to the bone!
And my linuxtv patches should be ported into kernel please, with or without Abraham, with or without Chehab. I swear you that they are OK and not buggy at all.
It is the wrong policy to execute protectionism on people having lots of administration power but in reality lacking the experience, who are not able to tolerate justified criticism.
I enjoyed Gerd and I enjoyed most of all german guys of the convergence crew. Those were real fine and honest people, especially Gerd himself.

Sincerely

Uwe

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Sat, 24 Feb 2007 10:07:29 -0800
Von: Andrew Morton <akpm@linux-foundation.org>
An: "Uwe Bugla" <uwe.bugla@gmx.de>
CC: torvalds@linux-foundation.org, bunk@stusta.de, linux-kernel@vger.kernel.org
Betreff: Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

> > On Sat, 24 Feb 2007 18:54:24 +0100 "Uwe Bugla" <uwe.bugla@gmx.de> wrote:
> > Hi folks,
> > Second attempt now:
> > I already reported to Linus Torvalds and Andrew Morton that it is
> impossible to mount a conventional floppy drive without hanging up the whole
> system.
> > Andrew's reaction was quite ambiguous: "We did not break it"
> 
> Sorry, what I meant was "Neither Linus nor I broke it".  ie: please report
> this in a place where the person who did break it can see it.  This you
> have
> done.
> 
> > Once again and for the last time: I do not state that floppy.c is
> broken. I only state that it is immpossible to mount a floppy drive with kernel
> 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely
> buggy!
> > I did some work already:
> > a. I copied the following modules from the intact and sane kernel 2.6.20
> into the 2.6.21-rc1-git1 tree:
> > cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h,
> uaccess.h
> > b. I adjusted some hunks of the patch for module main.c (part of
> patch-2.6.21-rc1) to make the kernel compile without errors.
> > But the problem still persists, and I do not have any idea anymore where
> the offensive hunks in patch-2.6.21-rc1 could reside.
> > 
> > Questions:
> > a. Can someone please confirm the described problem?
> > b. Can someone please take action to find out where the buggy code
> resides?
> > c. Why is this untested material being pushed into main vanilla - what
> is going on at kernel.org please?
> > 
> > Please take action! The bug was introduced somewhere at the transition
> of 2.6.20 towards 2.6.20-git14.
> > 
> 
> I think we'll find that it works OK for hundreds of other people, so it
> got
> broken in some manner which is specific to a very small number of
> machines,
> of which yours is one.
> 
> If that theory proves to be correct, I'm afraid that the most proactical
> way of fixing this is to ask you to run a git-bisect to find the changeset
> which introduced the regression.
> 
Andrew,
it is definitely NOT my job to repair errors that other responsibility-free people pushed into vanilla mainline without the slightest test effort in some mm-tree for example. Who wasted it must repair it, without the slightest discussion!
I have provided enough information and energy to establish guidelines how to fix that error.
Above that I am still waiting for my linuxtv patches being applied which would be a nice and honest gesture.
Any further questions, Mr. Morton, or did I pronounce clear?
So take action now please!

Yours sincerely

Uwe

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Ray Lee]

> it is definitely NOT my job to repair errors that other responsibility-free people pushed into vanilla mainline without the slightest test effort in some mm-tree for example. Who wasted it must repair it, without the slightest discussion!

You're assuming the author didn't test it. For things like floppy.c,
it's possible it was tested and worked on their system just fine, but
is broken on yours. As you can replicate the problem, you're the
natural person to help narrow down the cause. This is the way all
development works, not just Linux or free software.

Please start by assuming that people mean well and are trying to do
the right thing, and you'll get a lot more productive responses.

> So take action now please!

And please remember that the vast majority of us, just like you, are volunteers.

Ray

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Jiri Slaby]

Uwe Bugla napsal(a):
> Hi folks,

Hi.

> Once again and for the last time: I do not state that floppy.c is broken. I only state that it is immpossible to mount a floppy drive with kernel 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely buggy!
> I did some work already:
> a. I copied the following modules from the intact and sane kernel 2.6.20 into the 2.6.21-rc1-git1 tree:
> cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h, uaccess.h
> b. I adjusted some hunks of the patch for module main.c (part of patch-2.6.21-rc1) to make the kernel compile without errors.
> But the problem still persists, and I do not have any idea anymore where the offensive hunks in patch-2.6.21-rc1 could reside.
> 
> Questions:
> a. Can someone please confirm the described problem?

Yup (last -mm).

> b. Can someone please take action to find out where the buggy code resides?

I'll take a look. I've seen here and tried to debug it down some time ago
without any result. Sysrq is dead, probably some kind of locking issue. LOCKDEP
screams silence, code reading returned nothing. I thought, it's problem inside
my setup, I gave it up (even reporting). But it seems to be real problem now.

> c. Why is this untested material being pushed into main vanilla - what is going on at kernel.org please?

Hard to say, nobody is perfect, this should never happen, but unfortunately it does.

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Jiri Slaby]

Jiri Slaby napsal(a):
>> Once again and for the last time: I do not state that floppy.c is 
>> broken. I only state that it is immpossible to mount a floppy drive 
>> with kernel 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 
>> is definitely buggy!
>> I did some work already:
>> a. I copied the following modules from the intact and sane kernel 
>> 2.6.20 into the 2.6.21-rc1-git1 tree:
>> cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h, uaccess.h
>> b. I adjusted some hunks of the patch for module main.c (part of 
>> patch-2.6.21-rc1) to make the kernel compile without errors.
>> But the problem still persists, and I do not have any idea anymore 
>> where the offensive hunks in patch-2.6.21-rc1 could reside.
>>
>> Questions:
>> a. Can someone please confirm the described problem?
> 
> Yup (last -mm).

Ok, this commit is the culprit:
Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
Author: Stephane Eranian <eranian@hpl.hp.com> Tue, 13 Feb 2007 13:26:22 +0100

     [PATCH] i386: add idle notifier

     Add a notifier mechanism to the low level idle loop.  You can register a
     callback function which gets invoked on entry and exit from the low level id
     loop.  The low level idle loop is defined as the polling loop, low-power cal
     or the mwait instruction.  Interrupts processed by the idle thread are not
     considered part of the low level loop.

     The notifier can be used to measure precisely how much is spent in useless
     execution (or low power mode).  The perfmon subsystem uses it to turn on/off
     monitoring.

     Signed-off-by: stephane eranian <eranian@hpl.hp.com>
     Signed-off-by: Andrew Morton <akpm@osdl.org>
     Signed-off-by: Andi Kleen <ak@suse.de>

---

Reverting (some manual work due to irq.c changes) this on latest -mm allows me 
to mount floppy again.

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Linus Torvalds]

On Mon, 26 Feb 2007, Jiri Slaby wrote:
> 
> Ok, this commit is the culprit:
> Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
> Author: Stephane Eranian <eranian@hpl.hp.com> Tue, 13 Feb 2007 13:26:22 +0100
> 
>     [PATCH] i386: add idle notifier

Interesting. It doesn't touch floppy at all, but it *does* seem to play 
around with irq state. 

In particular, the floppy uses IRQF_DISABLED (which means that it doesn't 
want interrupts enabled when in the irq handler), and I get the feeling 
that the poll_idle() stuff made that not work.

That said, the only thing that *really* seems to change (as far as a 
floopy driver could notice) is the added "exit_idle()" in the do_IRQ() 
sequence, and I'm not seeing that one enabling interrupts. 

But the idle sequence definitely does (ie now we disable/enable interrupts 
in cpu_idle(). I'm not seeing why that should matter, though.

Stephane, any ideas?

		Linus

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Jiri Slaby]

Linus Torvalds napsal(a):
> 
> On Mon, 26 Feb 2007, Jiri Slaby wrote:
>> Ok, this commit is the culprit:
>> Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
>> Author: Stephane Eranian <eranian@hpl.hp.com> Tue, 13 Feb 2007 13:26:22 +0100
>>
>>     [PATCH] i386: add idle notifier
> 
> Interesting. It doesn't touch floppy at all, but it *does* seem to play 
> around with irq state. 
> 
> In particular, the floppy uses IRQF_DISABLED (which means that it doesn't 
> want interrupts enabled when in the irq handler), and I get the feeling 
> that the poll_idle() stuff made that not work.

$ grep flags /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr

i.e. 'ht' and no 'monitor'; both poll_idle and mwait_idle are not involved, 
default_idle is.

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Benjamin LaHaise]

On Mon, Feb 26, 2007 at 07:51:19AM -0800, Linus Torvalds wrote:
> > Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
> > Author: Stephane Eranian <eranian@hpl.hp.com> Tue, 13 Feb 2007 13:26:22 +0100
> > 
> >     [PATCH] i386: add idle notifier
> 
> Interesting. It doesn't touch floppy at all, but it *does* seem to play 
> around with irq state. 

Side note: this patch adds several function calls (4), several additional 
L1 cache touches and a generally inefficient code path to *every single 
interrupt that exits from the idle poll*, not to mention the extra (useless, 
as it doesn't get used on 99.9% of deployed systems) function call and cache 
touches to every single interrupt.  Keep in mind that systems acting as 
routers will often be sitting in the idle loop when processing interrupts.  
At the very least this overhead (which is noticable on profiles) should be 
configurable.  I don't think that my 586 class embedded routers really need 
this crap to be going into the kernel.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <zyntrop@kvack.org>.

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Linus Torvalds]

On Mon, 26 Feb 2007, Benjamin LaHaise wrote:
> 
> Side note: this patch adds several function calls (4), several additional 
> L1 cache touches and a generally inefficient code path to *every single 
> interrupt that exits from the idle poll*, not to mention the extra (useless, 
> as it doesn't get used on 99.9% of deployed systems) function call and cache 
> touches to every single interrupt.

It is in fact possible that the floppy failure might just be from some 
timing-dependent thing, and the slowdown itself is the problem.

Although I do find that a bit unlikely, since machines these days are 
about a million times faster than they used to be, so even if it's 
unnecessarily slow, it shouldn't be noticeable for a floppy drive.

>  Keep in mind that systems acting as routers will often be sitting in 
> the idle loop when processing interrupts.  At the very least this 
> overhead (which is noticable on profiles) should be configurable.  I 
> don't think that my 586 class embedded routers really need this crap to 
> be going into the kernel.

I'm inclined to agree. Considering that the patch is known to cause 
problems, and that it's apparently broken on x86 *anyway* (the 
idle_notifier_register function isn't even exported), and considering that 
it's clearly bad for interrupt performance and could have been done a lot 
better, I would suggest just ripping it all out.

And I think we should do the same for x86-64 too..

		Linus

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Stephane Eranian]

Hi,

On Mon, Feb 26, 2007 at 07:51:19AM -0800, Linus Torvalds wrote:
> 
> 
> On Mon, 26 Feb 2007, Jiri Slaby wrote:
> > 
> > Ok, this commit is the culprit:
> > Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
> > Author: Stephane Eranian <eranian@hpl.hp.com> Tue, 13 Feb 2007 13:26:22 +0100
> > 
> >     [PATCH] i386: add idle notifier
> 
> Interesting. It doesn't touch floppy at all, but it *does* seem to play 
> around with irq state. 
> 
> In particular, the floppy uses IRQF_DISABLED (which means that it doesn't 
> want interrupts enabled when in the irq handler), and I get the feeling 
> that the poll_idle() stuff made that not work.
> 
> That said, the only thing that *really* seems to change (as far as a 
> floopy driver could notice) is the added "exit_idle()" in the do_IRQ() 
> sequence, and I'm not seeing that one enabling interrupts. 
> 
> But the idle sequence definitely does (ie now we disable/enable interrupts 
> in cpu_idle(). I'm not seeing why that should matter, though.
> 
> Stephane, any ideas?
> 
I think this may be related to the issue fixed by Venkatesh here:
	http://www.ussg.iu.edu/hypermail/linux/kernel/0611.3/1264.html

The same code was used for i386 but I think for both architectures, the patch
is missing default_idle(). I believe deault idle should look as follows:

void default_idle(void)
{
        if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
                current_thread_info()->status &= ~TS_POLLING;
                /*
                 * TS_POLLING-cleared state must be visible before we
                 * test NEED_RESCHED:
                 */
                smp_mb();

                local_irq_disable();
                if (!need_resched())
                        safe_halt();    /* enables interrupts racelessly */
                else
                        local_irq_enable();
                current_thread_info()->status |= TS_POLLING;
        } else {
                /* loop is done by the caller */
---->		local_irq_enable();
                cpu_relax();
        }
}
I do not have any machine with floppy drives. Could you try this?

Thanks.

-- 
-Stephane

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Linus Torvalds]

On Mon, 26 Feb 2007, Stephane Eranian wrote:
> 
> The same code was used for i386 but I think for both architectures, the patch
> is missing default_idle(). I believe deault idle should look as follows:

Side note - I'll revert it regardless.

We can re-merge it later after

 - it has been tested better

 - people have added code to make all the expensive stuff go away if there 
   are no idle notifiers registered (ie "enter_idle" should NOT set the 
   idle-notify bit unconditionally in the idle loop, it should set if only 
   if there are people who care.

As it is, that patch was not only apparently buggy, but even if you fix 
the actual bug, it's still broken from a performance angle.

		Linus

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Stephane Eranian]

Linus,

On Mon, Feb 26, 2007 at 09:10:22AM -0800, Linus Torvalds wrote:
> > 
> > Side note: this patch adds several function calls (4), several additional 
> > L1 cache touches and a generally inefficient code path to *every single 
> > interrupt that exits from the idle poll*, not to mention the extra (useless, 
> > as it doesn't get used on 99.9% of deployed systems) function call and cache 
> > touches to every single interrupt.
> 
> It is in fact possible that the floppy failure might just be from some 
> timing-dependent thing, and the slowdown itself is the problem.
> 
> Although I do find that a bit unlikely, since machines these days are 
> about a million times faster than they used to be, so even if it's 
> unnecessarily slow, it shouldn't be noticeable for a floppy drive.
> 
I don't know enough about the floppy driver to comment on this but I would
agree with you here.

> >  Keep in mind that systems acting as routers will often be sitting in 
> > the idle loop when processing interrupts.  At the very least this 
> > overhead (which is noticable on profiles) should be configurable.  I 
> > don't think that my 586 class embedded routers really need this crap to 
> > be going into the kernel.
> 
> I'm inclined to agree. Considering that the patch is known to cause 
> problems, and that it's apparently broken on x86 *anyway* (the 
> idle_notifier_register function isn't even exported), and considering that 
> it's clearly bad for interrupt performance and could have been done a lot 
> better, I would suggest just ripping it all out.
> 
The notifier was exported initially but then some people argued I should take
this out because there was no actual users just yet.

As for the performance impact, for non idle tasks, this translates into an
if() return. For the idle, if this is not used, you have a bitop + call
to notifier call chain with empty chain.

With perfmon, we would like to exclude useless kernel execution from being
monitored. That means poll_idle(), default_idle(), mwait_idle(). Yet we
want to capture interrupt handler execution by the idle thread because this
represents useful execution.

The notifier is one mechanism whereby we can dynamically register a callback
to start/stop monitoring to achieve our goal. One could argue the mechanism
is heavy for the usage we make of it. We could certainly add two more
perfmon hooks in the idle code and we would save the atomic call chain notifier
altogether.

Another solution would be to just rely on firmware to stop/restart performance
counters when using mwait or hlt. But we would need something for poll_idle().
An issue with this solution is that it depends on the processor architecture or
implementation, some may not always stop the counters. Yet, we would like to
provide for 'useless execution exclusion' at the interface level for all
architectures. Explicit code may be the only way to provide such guarantee.

If you think there maybe a better way to do this, I am certainly open to suggestions.

Thanks.

-- 
-Stephane

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Alan]

> The bidirectional use is/was PL/IP, aka "laplink" connections. Yes, I 
> still have a machine I installed that way, and it will run 2.2.19 
> forever before I try it again. ;-)

PLIP/Laplink runs bidirectional on ordinary parallel ports. The
bidirectional part of parallel ports in "normal" modes is still used for
things like PnP detection of printer and drivers.

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Rene Herman]

On 02/28/2007 02:04 PM, Alan wrote:

> PLIP/Laplink runs bidirectional on ordinary parallel ports. The 
> bidirectional part of parallel ports in "normal" modes is still used
> for things like PnP detection of printer and drivers.

And my parallel port Iomega ZIP drive, it seems. I actually checked 
earlier and although it doesn't use DMA (it says it's using "EPP 
32-bit") it does use bidrectional communication; it's an sd device.

I admit most of those will be confined to history as well with respect 
to actual use (they existed with 100MB, 250 and 750MB disks, although 
the 750 one probably not as parallel) but they looked cool, so people 
haven't just thrown them away yet :)

Rene

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Bill Davidsen]

Linus Torvalds wrote:
> 
> On Mon, 26 Feb 2007, Rene Herman wrote:
>> Other than these two, ECP parallel ports are the other remaining users.
>> Now, even though on a machine that still has a parallel port it might usually
>> indeed be set to ECP in its BIOS; having anything attached to the port also
>> use it as such seems quite seldom.
> 
> Well, if it's some kind of cache coherency problem (the same way much more 
> modern CPU's have cache coherency issues with DMA during C3 sleep), then 
> it's entirely possible that the normal ECP parallel port behaviour would 
> never show it, since most people tend to use it for output only (yeah, I 
> realize you can use it bidirectionally, but at least on old hardware it 
> tends to be "talk AT printer" rather than "talk WITH printer".

The bidirectional use is/was PL/IP, aka "laplink" connections. Yes, I 
still have a machine I installed that way, and it will run 2.2.19 
forever before I try it again. ;-)
> 
> I frankly forget what hardware platforms had problems with the DMA thing, 
> and what the exact behaviour even was (I think there was some possibility 
> of corrupt data on the floppy). We also used to have the "nohlt" flag to 
> turn off hlt entirely, and that was due to some other legacy issues, iirc.
> 
> I seriously doubt we will ever see anybody who has this problem ever 
> again, but on the other hand, I also seriously doubt that most modern 
> machines even *have* a floppy drive any more, so I'd rather not even 
> change it. It's just not worth even a miniscule risk..

Thank you.
> 
> 		Linus


-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Linus Torvalds]

On Mon, 26 Feb 2007, Rene Herman wrote:
> 
> Other than these two, ECP parallel ports are the other remaining users.
> Now, even though on a machine that still has a parallel port it might usually
> indeed be set to ECP in its BIOS; having anything attached to the port also
> use it as such seems quite seldom.

Well, if it's some kind of cache coherency problem (the same way much more 
modern CPU's have cache coherency issues with DMA during C3 sleep), then 
it's entirely possible that the normal ECP parallel port behaviour would 
never show it, since most people tend to use it for output only (yeah, I 
realize you can use it bidirectionally, but at least on old hardware it 
tends to be "talk AT printer" rather than "talk WITH printer".

I frankly forget what hardware platforms had problems with the DMA thing, 
and what the exact behaviour even was (I think there was some possibility 
of corrupt data on the floppy). We also used to have the "nohlt" flag to 
turn off hlt entirely, and that was due to some other legacy issues, iirc.

I seriously doubt we will ever see anybody who has this problem ever 
again, but on the other hand, I also seriously doubt that most modern 
machines even *have* a floppy drive any more, so I'd rather not even 
change it. It's just not worth even a miniscule risk..

		Linus

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Rene Herman]

On 02/26/2007 07:13 PM, Linus Torvalds wrote:

> The floppy is still pretty much the only user of native motherboard
> (aka i8237) DMA'ing for most people. Some old ISA sound-cards may do
> it, of course.

Other than these two, ECP parallel ports are the other remaining users.
Now, even though on a machine that still has a parallel port it might 
usually indeed be set to ECP in its BIOS; having anything attached to 
the port also use it as such seems quite seldom.

Rene.

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Linus Torvalds]

On Mon, 26 Feb 2007, Oleg Nesterov wrote:
> 
> I know nothing about floppy, but I guess the reason is floppy_disable_hlt().
> 
> Sorry for the offtopic question, is it really needed? According to grep, floppy
> is the only one user of disable_hlt().

I suspect you'd have a hard time finding a machine where it was broken any 
more.

But it used to be that the native (aka "braindamaged and idiotic") DMA by 
the motherboard southbridge chipset (and apparently _only_ that) had 
problems with the CPU being halted on some motherboards, and would corrupt 
data if the CPU was halted while the DMA took place.

We never bothered to even figure out why it happened, though. It was 
undeniable that there were people who had trouble with "hlt" and the 
floppy driver, but it is not clear what the cause was.

That's a _loong_ time ago, though, and it *probably* hasn't been an issue 
on any recent machine. People just don't care enough to test, especially 
since the upside is negligible, and the downside for when it would trigger 
is huge.

The floppy is still pretty much the only user of native motherboard (aka 
i8237) DMA'ing for most people. Some old ISA sound-cards may do it, of 
course. But any PCI device will do its own DMA rather than rely on the 
broken 8237 DMA engine, so for all I know, the bug - whatever it ever 
ended up being - could still be there.

			Linus

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Oleg Nesterov]

Stephane Eranian wrote:
>
> On Mon, Feb 26, 2007 at 09:10:22AM -0800, Linus Torvalds wrote:
> >
> > It is in fact possible that the floppy failure might just be from some
> > timing-dependent thing, and the slowdown itself is the problem.
> >
> > Although I do find that a bit unlikely, since machines these days are
> > about a million times faster than they used to be, so even if it's
> > unnecessarily slow, it shouldn't be noticeable for a floppy drive.
> >
> I don't know enough about the floppy driver to comment on this but I would
> agree with you here.

I know nothing about floppy, but I guess the reason is floppy_disable_hlt().

Sorry for the offtopic question, is it really needed? According to grep, floppy
is the only one user of disable_hlt().

Oleg.

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Mike Galbraith]

On Sun, 2007-02-25 at 19:29 +0100, Uwe Bugla wrote:
> Hi everybody,
> "The bug was introduced somewhere at the transition of 2.6.20 towards 2.6.20-git14."
> I fortunately had some git9 patch at home and found out that it is sane.
> In so far the floppy mount bug was introduced somewhen between 2.6.20-git10 and 2.6.20-git14.
> "I'm afraid that the most proactical (it spells "practical", Mr. Morton) way of fixing this is to ask you to run a git-bisect to find the changeset which introduced the regression."
> Until you aren't even ready to explain me the exact technique of bisecting I won't do it and I can't do it.

Feeding google "how to git bisect" returns the below as it's first hit.
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

<psyco-blather deleted>

Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Alexey Dobriyan]

On Sun, Feb 25, 2007 at 07:29:39PM +0100, Uwe Bugla wrote:
> "The bug was introduced somewhere at the transition of 2.6.20 towards
> 2.6.20-git14."
> I fortunately had some git9 patch at home and found out that it is sane.

> "I'm afraid that the most proactical
> way of fixing this is to ask you to run a git-bisect to find the
> changeset which introduced the regression."
> Until you aren't even ready to explain me the exact technique of bisecting
> I won't do it and I can't do it.

Do you have something called git installed?
If yes, have you cloned mainline git tree?

bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system

[Uwe Bugla]

Hi everybody,
"The bug was introduced somewhere at the transition of 2.6.20 towards 2.6.20-git14."
I fortunately had some git9 patch at home and found out that it is sane.
In so far the floppy mount bug was introduced somewhen between 2.6.20-git10 and 2.6.20-git14.
"I'm afraid that the most proactical (it spells "practical", Mr. Morton) way of fixing this is to ask you to run a git-bisect to find the changeset which introduced the regression."
Until you aren't even ready to explain me the exact technique of bisecting I won't do it and I can't do it. I do not like the gesture behind your words.
I am still expecting you to get my linuxtv patches applied, which is definitely being compromised by you, Mr. Morton. Forget about Chehab - he will never step in the shoes of the standards that have been set by Gerd Knorr and the old german convergence crew.
Apart from that it is definitely your job to build up mailing chains to get kernel errors fixed, not mine. For my feedbacks concerning the buggy mm-stuff you didn't even send a reply. A "thank you" or whatever. Real "honest" gesture, isn't it?
But of course it seems to be easier to push buggy code into mainline vanilla, or did I get something wrong? If I did get something wrong then please correct me.
Fact is: The buggy code residing somewhere in git10, git11, git12, git13 or git14 resides in 2.6.20-mm2 at the same time. And if git is finished this buggy code is being pushed into mainline!
If I would say yes now and do all the bisecting dirty work this would be like a license to push bad untested code into vanilla mainline!
And this is the policy that needs urgently to be stopped, without any discussion!
And exactly this does not happen for the first time: The regression confusing nerolinux (happened at the transition from 2.6.19 to 2.6.20-rc1 in December 2006) followed exactly the same dramaturgic rules. And this is the irresponsible, regressive, wrong and counterproductive policy that I am talking about! And exactly in that context the following statement by Mister Andrew Morton is completely displaced:
"I think we'll find that it works OK for hundreds of other people, so it got broken in some manner which is specific to a very small number of machines, of which yours is one." From where do you know, and what is going on in your brain please?
Excuse me please, but the gesture behind sounds like: "99 % of all bttv cards need dvb-pll.c." (Mauro Carvalho Chehab)
A real honest and accurate man would reply: "Sorry and thank you for your contributions, but I do not have any idea either! And as soon as I see my limits I will try my best to get some help from people who really have an idea."

Best Regards

Uwe
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer