Update: Well, I was wrong about the size of the initrd.img file causing the "Fast Data Access MMU Miss" (it only happens with some kernels).
This combination (the default Debian SID vmlinux and initrd.img) fails: # ls -l *6.4.0* -rw-r--r-- 1 root root 186222 Jul 29 22:50 config-6.4.0-1-sparc64 -rw-r--r-- 1 root root 23023550 Jul 31 07:05 initrd.img-6.4.0-1-sparc64 -rwxr-xr-x 1 root root 19082504 Jul 29 22:50 vmlinux-6.4.0-1-sparc64 This combination (based on Debian's config file) also fails: # ls -l config*6.4.7 initrd*6.4.7 vmlinux*6.4.7 -rw-r--r-- 1 root root 185601 Aug 3 09:13 config-6.4.7 -rw-r--r-- 1 root root 23139317 Aug 3 10:15 initrd.img-6.4.7 -rwxr-xr-x 1 root root 19114368 Aug 3 09:54 vmlinux-6.4.7 And this combination (built with gzipped modules) also fails: # ls -l config*6.4.7 initrd*6.4.7 vmlinux*6.4.7 -rw-r--r-- 1 root root 185639 Aug 3 10:21 config-6.4.7 -rw-r--r-- 1 root root 5804190 Aug 3 12:13 initrd.img-6.4.7 -rwxr-xr-x 1 root root 19114368 Aug 3 11:00 vmlinux-6.4.7 So I guess I'll need to try a bisect after all. -Stan ----- On 8/2/23 8:33 AM, Stan Johnson wrote: > Hello, > > On 7/31/23 1:06 PM, Stan Johnson wrote: >> ... "Fast Data Access MMU Miss" while loading the initrd > > After doing some more testing (and accidentally erasing my system disk > -- sda is the lower drive, not the upper one!), it's looking like the > "Fast Data Access MMU Miss" error is not caused by a kernel issue. I > think the default initrd has blown past some hard-coded memory limit in > SILO for loading the initrd (that's a guess). I'm able to get any kernel > to boot as long as I keep the initrd to less than around 20 MB. > > Note: Debian's vmlinux-6.4.0-1-sparc64 kernel can't be created using > Debian's config file config-6.4.0-1-sparc64. The config file has debug > options enabled that result in a 300 MB kernel and over 3 GB of modules. > > After re-installing SILO 1.4.14 by installing Debian 7.11 from CD, I > re-learned some interesting things about SILO. Like GRUB, it lives in an > ext2 filesystem (the Sun Boot partition), and it wants to be mounted as > /boot. So by default, SILO is very similar to GRUB. Both silo.conf and > grub.conf can be configured to be static, with no kernels in the Sun > Boot partition, and the Boot partition likely doesn't have to remain > mounted as /boot for GRUB to still work (though I'd probably have to > delete or disable grub-install to manage GRUB manually). > > To test the latest GRUB, I downloaded what I thought was the latest > Debian sparc64 snapshot from here: > https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/debian-12.0.0-sparc64-NETINST-1.iso > > The installation failed with an error regarding Perl -- I didn't save > anything yet because I wanted to make sure I'm using the correct image. > If it's the right image, I'll capture the log file and post it under a > different thread. > > One last question regarding Sun partitions: Is the following warning > while using parted important? > "Warning: The disk CHS geometry (562253,255,2) reported by the operating > system does not match the geometry stored on the disk label > (17849,255,63)." > Using fdisk, I don't see a similar error: > # fdisk -l > Disk /dev/sda: 136.73 GiB, 146815737856 bytes, 286749488 sectors > Disk model: ST3146807LC > Geometry: 255 heads, 63 sectors/track, 17849 cylinders > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: sun > Device Start End Sectors Size Id Type Flags > /dev/sda1 0 257039 257040 125.5M 1 Boot > /dev/sda2 257040 4257224 4000185 1.9G 82 Linux swap > /dev/sda3 0 286744184 286744185 136.7G 5 Whole disk > /dev/sda4 4257225 20257964 16000740 7.6G 83 Linux native > /dev/sda5 20257965 52259444 32001480 15.3G 83 Linux native > /dev/sda6 52259445 84260924 32001480 15.3G 83 Linux native > /dev/sda7 84260925 286744184 202483260 96.6G 83 Linux native > > -Stan >
