LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
@ 2007-02-26 18:06 Oleg Nesterov
  2007-02-26 18:13 ` Linus Torvalds
  0 siblings, 1 reply; 24+ messages in thread
From: Oleg Nesterov @ 2007-02-26 18:06 UTC (permalink / raw)
  To: Stephane Eranian; +Cc: Linus Torvalds, linux-kernel

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.


^ permalink raw reply	[flat|nested] 24+ messages in thread
* bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
@ 2007-02-25 18:29 Uwe Bugla
  2007-02-25 21:04 ` Alexey Dobriyan
  2007-02-26  3:55 ` Mike Galbraith
  0 siblings, 2 replies; 24+ messages in thread
From: Uwe Bugla @ 2007-02-25 18:29 UTC (permalink / raw)
  To: torvalds; +Cc: akpm, bunk, linux-kernel

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

^ permalink raw reply	[flat|nested] 24+ messages in thread
* bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
@ 2007-02-24 17:54 Uwe Bugla
  2007-02-24 18:07 ` Andrew Morton
  2007-02-26 10:38 ` Jiri Slaby
  0 siblings, 2 replies; 24+ messages in thread
From: Uwe Bugla @ 2007-02-24 17:54 UTC (permalink / raw)
  To: torvalds; +Cc: akpm, bunk, linux-kernel

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2007-02-28 12:21 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-26 18:06 bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system Oleg Nesterov
2007-02-26 18:13 ` Linus Torvalds
2007-02-26 20:55   ` Rene Herman
2007-02-26 21:14     ` Linus Torvalds
2007-02-28  2:42       ` Bill Davidsen
2007-02-28 13:04         ` Alan
2007-02-28 12:20           ` Rene Herman
  -- strict thread matches above, loose matches on Subject: below --
2007-02-25 18:29 Uwe Bugla
2007-02-25 21:04 ` Alexey Dobriyan
2007-02-26  3:55 ` Mike Galbraith
2007-02-24 17:54 Uwe Bugla
2007-02-24 18:07 ` Andrew Morton
2007-02-24 18:29   ` Uwe Bugla
2007-02-24 19:23   ` Uwe Bugla
2007-02-24 19:49     ` Ray Lee
2007-02-26 10:38 ` Jiri Slaby
2007-02-26 15:12   ` Jiri Slaby
2007-02-26 15:51     ` Linus Torvalds
2007-02-26 16:28       ` Jiri Slaby
2007-02-26 16:34       ` Benjamin LaHaise
2007-02-26 17:10         ` Linus Torvalds
2007-02-26 17:45           ` Stephane Eranian
2007-02-26 17:28       ` Stephane Eranian
2007-02-26 17:37         ` Linus Torvalds

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).