loop back broken in 2.2.14

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

[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

[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

[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

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

[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

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: 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