Am Mittwoch, 22. Juli 2009 schrieb Matthias Klose: > On 21.07.2009 07:23, Wolfgang Walter wrote: > > Package: binutils > > Version: 2.19.51.20090714-1 > > > >> There were no error messages or anything from the kernel; just the > >> spontaneous reboot or hang. No configuration kernel configuration > >> changes either; the only difference in a working test case and a > >> non-working test case was building with different versions of binutils. > >> > >> There's nothing special about the PC that had the problem booting the > >> kernel. It's an old machine that has never had problems with Linux. > > > > I can confirm that. I had to downgrade binutils to build a working > > 2.6.30.2 (or 2.6.30.1). > > > > In LKML other people also tracked down non-booting 2.6.30.x to be caused > > by the actual binutils package in sid. > > I can't see this kind of report for current Fedora and Ubuntu, which are > both based to a subset of the hjl's binutils patches (the Debian package is > pure upstream without these patches applied). As a quick check, please > could you recheck with the package found here: > > http://packages.ubuntu.com/karmic/amd64/binutils/download > http://packages.ubuntu.com/karmic/i386/binutils/download
I'll try tonight. Maybe this mail from Bastian Blank to 537...@bugs.debian.org has an hint: ===================================== On Mon, Jul 20, 2009 at 03:02:36PM -0700, Linus Torvalds wrote: > On Mon, 20 Jul 2009, Kiko Piris wrote: > > Yes, as Marcel Beister pointed, it resulted some binutils bug. > > Downgrading the package produced a perfectly bootable 2.6.30.2. > Ok, so it's been narrowed down to binutils. Good. Okay, I did some work and now got one working and one not working kernel. The setup code it, except the payload size and the version string, identical. Now to vmlinux. First difference (1-vmlinux is the broken, 2-vmlinux is the working version): | 2-vmlinux: file format elf32-i386 | 2-vmlinux | architecture: i386, flags 0x00000113: | HAS_RELOC, EXEC_P, HAS_SYMS, D_PAGED vs. | 1-vmlinux: file format elf32-i386 | 1-vmlinux | architecture: i386, flags 0x00000013: | HAS_RELOC, EXEC_P, HAS_SYMS The file lost its D_PAGED flag. Next: | 16 .init.rodata 00000394 c05057e0 005057e0 004067e0 2**4 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 17 .data.page_aligned 00000800 c0506000 00506000 00407000 2**5 | CONTENTS, ALLOC, LOAD, DATA vs. | 16 .init.rodata 00000394 c0506000 00506000 00407000 2**4 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 17 .data_nosave 00000c6c c0506394 00506394 00407394 2**0 | ALLOC | 18 .data.page_aligned 00000800 c0507000 00506394 00407394 2**5 | CONTENTS, ALLOC, LOAD, DATA So suddenly there apears a .data_nosave with some content, but it is marked the same then a bss section and not even properly aligned according to the linker script. The same sections of another working kernel, built with the new binutils: | 18 .init.rodata 000003bd c040f4c0 0040f4c0 003104c0 2**2 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 19 .data_nosave 00001000 c0410000 00410000 00311000 2**2 | CONTENTS, ALLOC, LOAD, DATA | 20 .data.page_aligned 00000800 c0411000 00411000 00312000 2**2 | CONTENTS, ALLOC, LOAD, DATA The .data_nosave section is a real one here. I would say, such holes won't survive the objcopy to create a binary and all code is at the wrong location. Bastian ========================================= Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
