>> 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>
> 
> 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?  :-)

	- Greg