Re: [GIT PULL] bzip2/lzma kernel compression

[Ingo Molnar]

* Yinghai Lu <yinghai@xxxxxxxxxx> wrote:

> On Fri, Jan 9, 2009 at 12:52 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
> > On Fri, Jan 9, 2009 at 10:45 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> >> Hi Linus,
> >>
> >> This tree contains the bzip2 and LZMA kernel compression work that
> >> Alain Knaff has done.  Sending this as a separate pull request in case
> >> you think that it is too late or immature for this cycle.
> >>
> >> The good part is that it is a highly "brittle" feature -- if it fails,
> >> it will fail noisily and obviously.
> >>
> >> I have not included the ARM parts that Alain developed; I will leave
> >> those to be fed through rmk.
> >>
> >> One of the main attractions of this patchset is that it uses the newer
> >> lib/zlib_inflate code even for the kernel decompressor.  Once all
> >> architectures that use the older lib/inflate.c have been converted
> >> over, we can remove that code entirely.
> >
> > it seems still have some problem
> > mydisk13_x86_64.lzma is by lzma -9
> >
> > [   47.404316] RAMDISK: lzma image found at block 0
> > [   51.676838] RAMDISK: incomplete write (-28 != 130)
> > [   51.894794] calling  5_generic_delete_inode_async+0x0/0xa9 @ 2316
> > [   51.900895] initcall 5_generic_delete_inode_async+0x0/0xa9 returned
> > 0 after 3 usecs
> > [   51.901117] kjournald starting.  Commit interval 5 seconds
> > [   51.901130] EXT3 FS on ram0, internal journal
> > [   51.901138] EXT3-fs: mounted filesystem with ordered data mode.
> > [   51.901151] VFS: Mounted root (ext3 filesystem) on device 1:0.
> > [   51.901168] async_waiting @ 1
> > [   51.904191] calling  6_generic_delete_inode_async+0x0/0xa9 @ 2317
> > [   51.907123] initcall 6_generic_delete_inode_async+0x0/0xa9 returned
> > 0 after 2861 usecs
> > [   51.947093] async_continuing @ 1 after 44846 usec
> > [   51.951839] Freeing unused kernel memory: 448k freed
> > [   51.957245] init_special_inode: bogus i_mode (4467)
> >
> 
> the .lzma is corrupted. it is strange. i was compiling kernel when lzma 
> it...
> 
> recreate that .lzma the kernel works well.

was the linux/.lzma file corrupted, and once you removed the stale file it 
all works fine and the problem does not come back?

I.e. the tree as offered by hpa is fine?

	Ingo
--
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/