junneyang / zumastor

Automatically exported from code.google.com/p/zumastor
0 stars 1 forks source link

2.6.24.2 patches #72

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The 2.6.23.8 patches do not all apply cleanly to the 2.6.24.2 tree.  I'll
commit the ones that do apply cleanly to the beginnings of a 2.6.24.2 patch
set.

2.6.24 seems to be the kernel many projects are solidifying on.  For
OpenVZ, it's the first post-2.6.18 kernel with checkpoint working, which
we'd like to merge the zumastor patches into.  2.6.24 is also being built
as the release kernel for sid, hardy, and probably other distributions.

On build, ignoring all the rejects, dm-ddsnap.c failed to compile with:

drivers/md/dm-ddsnap.c: In function ‘snapshot_read_end_io’:
drivers/md/dm-ddsnap.c:339: error: too many arguments to function
‘bio->bi_end_io’
drivers/md/dm-ddsnap.c:339: error: void value not ignored as it ought to be
drivers/md/dm-ddsnap.c:412:34: error: macro "bio_io_error" passed 2
arguments, but takes just 1
drivers/md/dm-ddsnap.c: In function ‘replied_rw’:
drivers/md/dm-ddsnap.c:412: error: ‘bio_io_error’ undeclared (first use in
this function)
drivers/md/dm-ddsnap.c:412: error: (Each undeclared identifier is reported
only once
drivers/md/dm-ddsnap.c:412: error: for each function it appears in.)
drivers/md/dm-ddsnap.c:420:34: error: macro "bio_io_error" passed 2
arguments, but takes just 1
drivers/md/dm-ddsnap.c:451: warning: assignment from incompatible pointer type
drivers/md/dm-ddsnap.c:908:33: error: macro "bio_io_error" passed 2
arguments, but takes just 1
drivers/md/dm-ddsnap.c: In function ‘flush_list’:
drivers/md/dm-ddsnap.c:908: error: ‘bio_io_error’ undeclared (first use in
this function)
drivers/md/dm-ddsnap.c:905: warning: unused variable ‘bio’
drivers/md/dm-ddsnap.c: In function ‘ddsnap_map’:
drivers/md/dm-ddsnap.c:1103: warning: left shift count >= width of type
make[3]: *** [drivers/md/dm-ddsnap.o] Error 1
make[2]: *** [drivers/md] Error 2
make[1]: *** [drivers] Error 2
make[1]: *** Waiting for unfinished jobs....

And unsurprisingly, the bio.throttle patch had rejects:
dld@unexpected:/tmp/linux-2.6.24.2$ patch -p1
</home/dld/zuma/zumastor-rw/ddsnap/patches/2.6.23.8/bio.throttle.patch
patching file block/ll_rw_blk.c
Hunk #1 FAILED at 3139.
Hunk #2 succeeded at 3241 (offset 59 lines).
1 out of 2 hunks FAILED -- saving rejects to file block/ll_rw_blk.c.rej
patching file drivers/md/dm.c
Hunk #1 succeeded at 889 (offset 4 lines).
Hunk #2 succeeded at 983 (offset 4 lines).
Hunk #3 succeeded at 1026 (offset 7 lines).
Hunk #4 succeeded at 1593 (offset 34 lines).
patching file fs/bio.c
Hunk #1 FAILED at 142.
Hunk #2 FAILED at 1027.
2 out of 2 hunks FAILED -- saving rejects to file fs/bio.c.rej
patching file include/linux/bio.h
patching file include/linux/blkdev.h
Hunk #1 succeeded at 384 (offset -16 lines).
patching file include/linux/device-mapper.h
Hunk #1 succeeded at 196 (offset 5 lines).

Original issue reported on code.google.com by drake.di...@gmail.com on 13 Feb 2008 at 7:06

GoogleCodeExporter commented 9 years ago
2.6.24.2 builds under ARCH=i386 and ARCH=um, but the resulting kernels still 
have
issues, which will be filed as separate issues.

Martin's patch to our syscalls doesn't affect the issues, so I'll patch it in.
ARCH=um boots and is debuggable from userspace.  ARCH=i386 locks up early in 
boot,
and may just need a different .config.

Until these problems are resolved I'm rolling back the default build to 2.6.22. 
 Feel
free to set KernelVersion to 2.6.24.2 though and jump in to these issues.

Original comment by drake.di...@gmail.com on 15 Feb 2008 at 7:14

GoogleCodeExporter commented 9 years ago
After rebuilding with a known-good 2.6.24.2 .config file, the system still 
refused to
boot past INIT:, and the problem appeared to be one of the zumastor patches.

On bisecting, it looks like the bio.throttle patch is to blame.  The kernel is 
still
responsive, just not doing I/O.  So it's been successfully throttled all the 
way down.

Original comment by drake.di...@gmail.com on 27 Feb 2008 at 10:56

GoogleCodeExporter commented 9 years ago
I think we can resolve this, and track the issues through the open mkfs related 
bug 
against 2.6.24.2

Original comment by williama...@gmail.com on 27 Mar 2008 at 12:46