Re: Re: Re: loop back broken in 2.2.14

Re: Re: Re: loop back broken in 2.2.14

[joeja]

I think that was suggested a while ago, in the 2.2 days.  It didn't fly! There was however a general consensus that for small bugs that are found in a 'stable' release there should be fixes for just the bug as the next release.  I.E. 2.2.15 should be released with just the one fix.  Linus didn't seem to go for that as well as some other developers .

If 2.5 was open this kind of thing would probably not happen, but that is not to say that there would not be other issues in 2.4

If someone has the web space, they could as you say, post these 2.4.14.fixme kernels and then also maintain the patches between the official Linus kernel and the fixme kernels.  

J  

Michael Peddemors <michael@wizard.ca> wrote:
> Well, the loopback bug is a pain.. but we have had these pains on quite
a few releases in the 2.4.x series... 

I wonder if maybe a new method of distributing kernels should happen..
2.4.14 should become 2.4.14-stable meaning that it never ever changes
after release, and 2.4.14-fixed means that these tiny typos, gotchas,
and backport driver fixes can get into 2.4.14-fixed which may change
from day to day, but not get any enhancements, only minor fixes..

People could try 2.4.14-stable, and if they have a problem, they could
just try the 2.4.14-fixed to see if their problem is already
addressed...

The idea is that at least every major release kernel should compile, and
it would reduce the noise levels from people trying out *stable* kernel
versions..

Just a thought..

On Mon, 2001-11-12 at 12:27, joeja@mindspring.com wrote:
> I thought that the -pre would be the developer kernels, and that an actual release (2.4.14) would have been somewhat tested.  I fully understand that a 'runtime' bug in the vm or some other system could arrise and that is one thing. I also understand when a 'less used' driver like NTFS or VFAT breaks, but to see bugs in the loop device in a 'stabilizing' kernel is something that I thought I'd never see.
> 

-- 
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
Wizard IT Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada

Re: Re: Re: loop back broken in 2.2.14

[Michael Peddemors]

Yes, I seriously considered the feasibility of having 2.4.14-fixed
kernels around, but I could just imagine trying to deal with millions of
people trying to download known good kernels on our bandwidth...

It would be good to be able to point people to a stable kernel.. instead
of having to recommend kernels in the pre-series..

But for now, fixing the 2.4.14. loopback bug has given us a kernel we
are most comfortable with.. 

Just wish that 2.4.14 was that kernel..

On Wed, 2001-11-14 at 10:17, joeja@mindspring.com wrote:
> I think that was suggested a while ago, in the 2.2 days.  It didn't fly! There was however a general consensus that for small bugs that are found in a 'stable' release there should be fixes for just the bug as the next release.  I.E. 2.2.15 should be released with just the one fix.  Linus didn't seem to go for that as well as some other developers .
> 
> If 2.5 was open this kind of thing would probably not happen, but that is not to say that there would not be other issues in 2.4
> 
> If someone has the web space, they could as you say, post these 2.4.14.fixme kernels and then also maintain the patches between the official Linus kernel and the fixme kernels.  

-- 
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
Wizard IT Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada

Re: Re: Re: loop back broken in 2.2.14

[J.A. Magallon]

On 20011115 Michael Peddemors wrote:
>Yes, I seriously considered the feasibility of having 2.4.14-fixed
>kernels around, but I could just imagine trying to deal with millions of
>people trying to download known good kernels on our bandwidth...
>
>It would be good to be able to point people to a stable kernel.. instead
>of having to recommend kernels in the pre-series..
>
...
>On Wed, 2001-11-14 at 10:17, joeja@mindspring.com wrote:
>> I think that was suggested a while ago, in the 2.2 days.  It didn't fly! There was however a general consensus that for small bugs that are found in a 'stable' release there should be fixes for just the bug as the next release.  I.E. 2.2.15 should be released with just the one fix.  Linus didn't seem to go for that as well as some other developers .
>> 

Well, Linus could post a 'errata' patch...
Layout now in ftp space is (reverse date order):

	test-kernels
	ChangeLog-2.4.14
	LATEST-IS-2.4.14
	linux-2.4.14.tar.bz2

A couple files could be posted, named Errata-2.4.14 and linux-2.4.14-errata.bz2,
first being a description of what the second (the patchs) cures...with names like
that so the listing gets them visible near the main tarball...

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.15-pre4-beo-2 #1 SMP Thu Nov 15 13:02:43 CET 2001 i686

Re: loop back broken in 2.2.14

[Joe]

Well I think it is a good idea to do this and have errata patches or something.  I don't think Linus wants the extra work.  I'd do it myself, but I don't have the ftp storage space, the time or the bandwidth.   I am now keeping seperate trees on my box.  One that is the default kernel and then my tree which has fixes to that tree.   I'll be working out a
system of testing and migration now ..................

> Well, Linus could post a 'errata' patch...
> Layout now in ftp space is (reverse date order):
>
>         test-kernels
>         ChangeLog-2.4.14
>         LATEST-IS-2.4.14
>         linux-2.4.14.tar.bz2

Re: loop back broken in 2.2.14

[Mr R A Mercer]

Michael Peddemors wrote:

 > Yes, I seriously considered the feasibility of having 2.4.14-fixed
 > kernels around, but I could just imagine trying to deal with millions of
 > people trying to download known good kernels on our bandwidth...

As has been mentioned before I think that the best way to avoid little
problems like this is to have a 2.4.x-rc1 kernel around for a day, if no
problems are found then that tree becomes 2.4.x if a problem is found
then is becomes 2.4.x-rc2 etc...

Cheers

Adam

Re: Re: loop back broken in 2.2.14

[joeja]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

Okay, I can delete out those two lines to get loop working.

Is 2.4.x really a stable tree?  Or should I wait for 2.4.25 before I consider it really stable?

> > François Cami wrote:
> >
> > > yes, see 2.4.15pre1
> > > warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
> >
> > and further it is likely that pre3 fixes iptables code :)
> > (it looks like the patch got reverted)
>
> Actually it doesn't seem to be reverted,
> just reworked -

hmm, spoke too soon -

looks like they were reverted after all...

cu

jjs

Re: loop back broken in 2.2.14

[J Sloan]

joeja@mindspring.com wrote:

> Okay, I can delete out those two lines to get loop working.
>
> Is 2.4.x really a stable tree?  Or should I wait for 2.4.25 before I consider it really stable?

If by stable you mean "unchanging", of course not -

much development is still happening.

If however by stable you mean "does not crash",
it has been very stable here, with a few known
needed patches applied.  2.4.14 is stable for me
on all systems, but compaq smart controllers do
need a small patch - I am also running the low
latency and/or preempt patches with excellent
stability.

cu

jjs

loop back broken in 2.2.14

[Joe]

compile 2.2.14.

Then

# modprobe -a loop
/lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
deactivate_page
/lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
/lib/modules/2.4.14/kernel/drivers/block/loop.o failed
/lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed

do recursive grep through kernel tree:

# rgrep -rl  deactivate_page *
drivers/block/loop.c
drivers/block/loop.o

Is there a fix for this?

Joe

Re: loop back broken in 2.2.14

[François Cami]

Joe wrote:

> compile 2.2.14.
> 
> Then
> 
> # modprobe -a loop
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
> deactivate_page
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
> /lib/modules/2.4.14/kernel/drivers/block/loop.o failed
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
> 
> do recursive grep through kernel tree:
> 
> # rgrep -rl  deactivate_page *
> drivers/block/loop.c
> drivers/block/loop.o
> 
> Is there a fix for this?


yes, see 2.4.15pre1
warning, the iptables code in 2.4.15pre1 and pre2 seems broken.

François

Re: loop back broken in 2.2.14

[Jeff Garzik]

François Cami wrote:
> 
> Joe wrote:
> 
> > compile 2.2.14.
> >
> > Then
> >
> > # modprobe -a loop
> > /lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
> > deactivate_page
> > /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
> > /lib/modules/2.4.14/kernel/drivers/block/loop.o failed
> > /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
> >
> > do recursive grep through kernel tree:
> >
> > # rgrep -rl  deactivate_page *
> > drivers/block/loop.c
> > drivers/block/loop.o
> >
> > Is there a fix for this?
> 
> yes, see 2.4.15pre1
> warning, the iptables code in 2.4.15pre1 and pre2 seems broken.

and further it is likely that pre3 fixes iptables code :)
(it looks like the patch got reverted)

-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: loop back broken in 2.2.14

[J Sloan]

Jeff Garzik wrote:

> François Cami wrote:
>
> > yes, see 2.4.15pre1
> > warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
>
> and further it is likely that pre3 fixes iptables code :)
> (it looks like the patch got reverted)

Actually it doesn't seem to be reverted,
just reworked -

I'll be testing it out -

cu

jjs

Re: loop back broken in 2.2.14

[J Sloan]

J Sloan wrote:

> Jeff Garzik wrote:
>
> > François Cami wrote:
> >
> > > yes, see 2.4.15pre1
> > > warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
> >
> > and further it is likely that pre3 fixes iptables code :)
> > (it looks like the patch got reverted)
>
> Actually it doesn't seem to be reverted,
> just reworked -

hmm, spoke too soon -

looks like they were reverted after all...

cu

jjs

Re: loop back broken in 2.2.14

[elko]

On Sunday 11 November 2001 22:27, Joe wrote:
> compile 2.2.14.
>
> Then
>
> # modprobe -a loop
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
> deactivate_page
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
> /lib/modules/2.4.14/kernel/drivers/block/loop.o failed
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
>
> do recursive grep through kernel tree:
>
> # rgrep -rl  deactivate_page *
> drivers/block/loop.c
> drivers/block/loop.o
>
> Is there a fix for this?

2.4.15-pre1 fixed this and there are also some patches on lkml-archives..
-- 
ElkOS: 10:35pm up  2:26, 3 users, load average: 0.05, 0.25, 0.30
bofhX: The data on your hard drive is out of balance.
\x04

Re: loop back broken in 2.2.14

[Adrian Bunk]

On Sun, 11 Nov 2001, Joe wrote:

> compile 2.2.14.
>
> Then
>
> # modprobe -a loop
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
> deactivate_page
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
> /lib/modules/2.4.14/kernel/drivers/block/loop.o failed
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
>
> do recursive grep through kernel tree:
>
> # rgrep -rl  deactivate_page *
> drivers/block/loop.c
> drivers/block/loop.o
>
> Is there a fix for this?

This is a known bug.

The following patch fixes it:

--- linux-2.4.14-broken/drivers/block/loop.c	Thu Oct 25 13:58:34 2001
+++ linux-2.4.14/drivers/block/loop.c	Mon Nov  5 17:06:08 2001
@@ -207,7 +207,6 @@
 		index++;
 		pos += size;
 		UnlockPage(page);
-		deactivate_page(page);
 		page_cache_release(page);
 	}
 	return 0;
@@ -218,7 +217,6 @@
 	kunmap(page);
 unlock:
 	UnlockPage(page);
-	deactivate_page(page);
 	page_cache_release(page);
 fail:
 	return -1;

> Joe

cu
Adrian

-- 

Get my GPG key: finger bunk@debian.org | gpg --import

Fingerprint: B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400