Prev: drivercore: Add of_match_table to the common device drivers
Next: Is SG the only way to flush a disk cache from userspace?
From: Tim Abbott on 7 Mar 2010 13:40 Has this fix been merged yet? It seems to me that the patch Michael sent is a totally reasonable solution to this problem, and I had assumed that it was going to get picked up in the m68k tree when I saw this patch 2 months ago... -Tim Abbott On Mon, 11 Jan 2010, Michael Schmitz wrote: > Followup on this: You are absolutely right - the problem appears to be related > to the the .init_end section _only_ having the ALIGN, and nothing else (i.e. > no actual section content). > > Placing the align in the .m68k_fixup section like such: > > --- arch/m68k/kernel/vmlinux-std.lds.org 2010-01-09 11:01:05.000000000 > +1300 > +++ arch/m68k/kernel/vmlinux-std.lds 2010-01-12 08:43:07.000000000 +1300 > @@ -42,6 +42,7 @@ > __start_fixup = .; > *(.m68k_fixup) > __stop_fixup = .; > + . = ALIGN(PAGE_SIZE); > } > NOTES > .init_end : { > > still puts .init_end, __init_end and _end on a page boundary, but also extends > the load section up to that page boundary. (Unfortunately, it also extends the > kernel file size by a bit). > > Can the same be achieved in a more elegant way? The reason why the old script > worked with my binutils appears to be the placement of the initramfs data right > at the end - the start of initramfs is page aligned, and the size of the > initramfs is an integer number of pages, so the end of initramfs data, > __init_end and _end all are on a page boundary. With the fixup section now > placed after the initramfs explicitly, this no longer happens by accident... > > Cheers, > > Michael > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |