re: port-sparc/49202: 6.1.4 GENERIC kernel does not boot on SPARCstation IPX

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR port-sparc/49202; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: matthew green <mrg%eterna.com.au@localhost>,
    Martin Husemann <martin%duskware.de@localhost>,
    port-sparc-maintainer%netbsd.org@localhost
Subject: re: port-sparc/49202: 6.1.4 GENERIC kernel does not boot on 
SPARCstation IPX
Date: Wed, 17 Sep 2014 16:37:26 +0300

 Some more observertions...
 
 The message "read header" appears before "Cannot load netbsd: error=27"
 in the unsuccessful boots, but does not appear in successful boots.
 
 The string "read header" appears in fdloadfile() in old versions of
 src/sys/lib/libsa/loadfile.c (in the current version, it has been
 split into two separate messages, "read header failed" and "read header
 short").
 
 So, it looks like the read() call to read the ELF header is returning
 EFBIG.
 
 One place where this EFBIG could originate from is block_map()
 in src/sys/lib/libsa/ufs.c, after the comment /* Block number too high */.
 
 This lead me to look at the block numbers of the kernel files using
 fsdb.  It turns out the kernels that boot successfully all have small
 block numbers, and the one that doesn't has much larger block numbers.
 Here's what the fsdb "blks" command has to say about my successfully
 booting custom kernel:
 
   fsdb (inum: 397513)> inode 6
   current inode: regular file
   I=6 MODE=100755 SIZE=4421888
          MTIME=Sep 13 21:12:11 2014 [200000000 nsec]
          CTIME=Sep 13 23:54:39 2014 [476824999 nsec]
          ATIME=Sep 17 16:40:22 2014 [122303999 nsec]
   OWNER=root GRP=wheel LINKCNT=1 FLAGS=0x0 BLKCNT=0x21d0 GEN=0x4
   fsdb (inum: 6)> blks
   I=6 8656 blocks
   Direct blocks:
   0: 1280 1288 1296 1304 1312 1320 1328 1336 1344 1352 1360 1368 
   Indirect block 1376 (level 1):
   12: 1384 1392 1400 1408 1416 1424 1432 1440 1448 1456 1464 1472 1480 1488 
   26: 1496 1504 1512 1520 1528 1536 1544 1552 1560 1568 1576 1584 1592 1600 
   40: 1608 1616 1624 1632 1640 1648 1656 1664 1672 1680 1688 1696 1704 1712 
   54: 1720 1728 1736 1744 1752 1760 1768 1776 1784 1792 1800 1808 1816 1824 
   68: 1832 1840 1848 1856 1864 1872 1880 1888 1896 1904 1912 1920 1928 1936 
   82: 1944 1952 1960 1968 1976 1984 1992 2000 2008 2016 2024 2032 2040 2048 
 
 And the non-booting GENERIC kernel:
 
   fsdb (inum: 2)> inode 397513 
   current inode: regular file
   I=397513 MODE=100755 SIZE=4650072
          MTIME=Apr 13 11:14:45 2014 [0 nsec]
          CTIME=Sep 17 12:56:57 2014 [860000000 nsec]
          ATIME=Sep 17 16:26:46 2014 [560868999 nsec]
   OWNER=root GRP=wheel LINKCNT=1 FLAGS=0x0 BLKCNT=0x22f0 GEN=0xc
   fsdb (inum: 397513)> blks
   I=397513 8944 blocks
   Direct blocks:
   0: 1780000 1780008 1780016 1780024 1780136 1780144 1780152 1780160 
   8: 1780168 1780176 1780184 1780192 
   Indirect block 1780200 (level 1):
   12: 1780208 1780216 1780224 1780232 1780240 1780248 1780256 1780264 
   20: 1780272 1780280 1780288 1780296 1780304 1780312 1780320 1780328 
   28: 1780336 1780344 1780352 1780360 1780368 1780376 1780384 1780392 
   36: 1780400 1780408 1780416 1780424 1780432 1780440 1780448 1780456 
   44: 1780464 1780472 1780480 1780488 1780496 1780504 1780512 1780520 
 
 So, next I tried overwriting my custom kernel by the GENERIC kernel
 using cp(1), resulting in a GENERIC kernel identical to the one that
 failed to boot, but residing at lower block numbers.  This kernel
 booted just fine.
 
 I guess the next step would be to update the bootloader to the 6.1.4
 one and see if it still has the same problem...
 -- 
 Andreas Gustafsson, gson%gson.org@localhost