Don Zickus <[email protected]> writes:
>> The length error comes from lib/inflate.c
>>
>> I think it would be interesting to look at orig_len and bytes_out.
>>
>> My hunch is that I have tripped over a tool chain bug or a weird
>> alignment issue.
>
> I thought so too, but I took vmlinuz images from people (Vivek) who had it
> boot on their systems but those images still failed on my two machines.
Odd. That might narrow things down. This is just booting with grub
so there is no relocation specific weirdness coming into play.
>> The error is the uncompressed length does not math the stored length
>> of the data before from before we compressed it. Now what is
>> fascinating is that our crc's match (as that check is performed first).
>>
>> Something is very slightly off and I don't see what it is.
>
> I printed out orig_len -> 5910532 (which matches vmlinux.bin)
> bytes_out -> 5910531
Is the last byte of vmlinux.bin 0?
One byte off certainly, fits my patter of something slightly off.
>> After looking at the state variables I would probably start looking
>> at the uncompressed data to see if it really was decompressing
>> properly. If nothing else that is the kind of process that would tend
>> to spark a clue.
>
> I am not familiar with the code, so very few sparks are flying. I'll
> still dig through though. Thanks for the tips.
Welcome.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
