On Mon, Feb 12, 2001 at 10:46:30AM +0000, Philip Blundell wrote: > Hmm. Well, I tried the `gzip' from Peter's base_2.2.tgz on my ARM7 > with a current 2.4 kernel and couldn't reproduce your segfault. > Dbootstrap doesn't seem to work in a NFS-root environment so I can't > test that. But I wonder if it's something else about your machine > causing problems, rather than the ARM7. Is it unusual in any way? > How much RAM do you have, and does that match what the kernel says > when it starts up?
I really fail to see anything unusual about it! The only modifications to the standard model were: - Added a Hitachi ATAPI CD ROM. I have tried unplugging this - it doesn't make a difference - Upgraded to RO3.7 and a StrongARM. Later I downgraded to the ARM710 again, while leaving the 3.7 ROMs in. (I'd rather *not* change the ROMs again, it was enough hassle that once.) - Upgraded the 540MB hard drive to a 3.2GB drive - Upgraded the memory to 40MB (32MB + 8MB). I've just tried removing one of the SIMMs and start Linux with just 32MB or 8MB - no difference. I have no extension cards in the machine. It's got 1MB of VRAM. Russell's ancient RedHat ARMLinux port worked all right. During booting, the memory is detected correctly, e.g. as "Memory: 16MB 16MB 4MB 4MB = 40MB total". The VRAM is also detected. On Mon, Feb 12, 2001 at 11:58:53AM +0000, Philip Blundell wrote: > I've now put in ftp.armlinux.org:/users/philb a RiscPC zImage built > with the various CONFIG_DEBUG_ME_HARDER type of options set. This > ought to elicit some diagnostics when programs segfault, which might > just be enough to figure out what's going on. You could give it a > try, anyway. Many thanks for uploading this! Here's what the kernel logs. After pressing Return on the installer splash screen: dbootstrap: unhandled page fault at pc=0x4008c314, lr=0x02004050 (bad address=0x00000008, code 0) When entering "gzip --help" after chrooting into the partition I managed to set up (by extracting base2_2.tgz): gzip: unhandled page fault at pc=0x4007350c, lr=0x40074678 (bad address=0x00000002, code 0) Yes - apparently just "--help" alone is sufficient to crash it! The gzip binary I'm talking about has an md5sum of 1f979af1d626a947a29be2c5735d4e8b I'm at a complete loss... Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GPG key: | \/¯| http://atterer.net | Universität München, Germany | 888354F7 ¯ ´` ¯
