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
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?
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>
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.
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
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.
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
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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
> 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.
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