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

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Sat, 24 Feb 2007 10:07:29 -0800
Von: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
An: "Uwe Bugla" <uwe.bugla@xxxxxx>
CC: torvalds@xxxxxxxxxxxxxxxxxxxx, bunk@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
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@xxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/