>> While trying to FTP the source tarballs, I'm getting a serious rash of
	>> the following hme0 error:
	>> 
	>> 	hme0: invalid packet size 2048; dropping
	> 
	> I'm not sure that's [an] error, if there are packets larger than expected
	> (mtu?) [the] driver drops them.  I'd check who sends them.

	It could only be the incoming FTP packets, absolutely nothing else was
	going on at that time other than the FTP session.

	>> with other intermittent diagnostic messages interspersed like
	>> 
	>> 	hme0: status=30001<GOTFRAME,RXTOHOST,NORXD>
	>> 	hme0: status=20001<GOTFRAME,NORXD>
	>> 	hme0: status=30101<GOTFRAME,SENTFRAME,RXTOHOST,NORXD>

You should ask Paul about those.  I think it's probably 1.5
interrupt lossage.  Probably fixed in -current.

	> 
	> I saw this, primarily it means that driver doesn't have enough receive
	> buffers, i.e. input traffic is too big for driver/os.  Could be caused
	> on a busy network when card is in promisc. mode.
	> Is this thing happenning all the time or only during download?

	It only happened during these FTP downloads.  I've barely done anything else
	with the machine as of yet, much less tax it network-wise.

	> Do you run tcpdump when this happens?

	Not yet.

	> You can increase the number of buffers(descriptors), it is _HME_NDESC in
	> hme.c (line 186 for 1.19).  It can be set to 32,64,128 or 256, nothing else.

	Thanks for the tip, I'll try 128.

	> Another thing, I don't know if console output can slowdown the kernel,
	> if it does then it explains why [the] driver can't keep up with traffic.

	PROM console output has slowed down everything on Suns since time immemorial :)

	Probably a vicious cycle - if the kernel/drive thinks it's seen a 2K packet
	and complains via outputting a console message, then that printf slows the
	machine down - perhaps enough to cause it to happen again, I dunno.

	This one's difficult, because there's no RASTERCONSOLE support in 1.5 for
	sparc64, and with no graphics/X support, it's at the raw console all the time.

	Anyway ... next problem.  I tried to build a new kernel with the stock
	vanilla 1.5 sources, and ran into this problem with the file
	/usr/src/sys/arch/sparc64/sparc64/pmap.c:

	cc  -O2 -Wimplicit -Wunused -Wswitch -Wcomment -Wtrigraphs -Wchar-subscripts 
	-Wparentheses -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
	-Wa,-Av9a -mno-fpu -I. -I../../../../arch -I../../../.. -nostdinc -DSUN4U 
	-D__ELF__ -DUVM_PAGE_TRKOWN -DLKM -DDIAGNOSTIC -D_LP64 -DMAXUSERS=64 -D_KERNEL 
	  -c ../../../../arch/sparc64/sparc64/pmap.c
	../../../../arch/sparc64/sparc64/pmap.c: In function `pmap_enter_kpage':
	../../../../arch/sparc64/sparc64/pmap.c:466: warning: implicit declaration of 
	function `BDPRINTF'
	../../../../arch/sparc64/sparc64/pmap.c:466: `PDB_BOOT1' undeclared (first use 
	in this function)
	../../../../arch/sparc64/sparc64/pmap.c:466: (Each undeclared identifier is 
	reported only once
	../../../../arch/sparc64/sparc64/pmap.c:466: for each function it appears in.)
	../../../../arch/sparc64/sparc64/pmap.c:468: warning: left-hand operand of 
	comma expression has no effect
	../../../../arch/sparc64/sparc64/pmap.c:468: warning: left-hand operand of 
	comma expression has no effect
	../../../../arch/sparc64/sparc64/pmap.c:468: warning: left-hand operand of 
	comma expression has no effect
	../../../../arch/sparc64/sparc64/pmap.c:468: warning: left-hand operand of 
	comma expression has no effect
	../../../../arch/sparc64/sparc64/pmap.c: In function `pmap_bootstrap':
	../../../../arch/sparc64/sparc64/pmap.c:557: `PDB_BOOT' undeclared (first use 
	in this function)
	[... and so on ... more warnings and complaints about PDB_BOOT ...]

	There are "BDPRINTF(PDB_BOOT1, [...])" statements scattered throughout
	pmap.c which are outside of "#ifdef DEBUG" ..."#endif" clauses, even
	though PDB_BOOT, PDB_BOOT1 and the BDPRINTF() macro are all #define'd inside
	of an #ifdef DEBUG clause.

	Does this mean noone's ever built a sparc64 kernel with DEBUG turned off?  :-)

Are you building a 1.5 kernel?  Don't -- switch to -current.  1.5 is
obsolete on sparc64.  Too many bugs fixed in current. 

I don't have that problem with -current:

#ifdef DEBUG
struct {
.....
#else
#define	BDPRINTF(n, f)
#define	DPRINTF(n, f)
#endif

Eduardo