Re: Netbooting VS4k60

[David Brownlee <abs%netbsd.org@localhost>]

On 8 February 2013 16:02, Charles Dickman <chd%chdickman.com@localhost> wrote:
> After some experimentation I determined that the probe of the le
> device was failing because the lance chip detected a memory timeout
> during a DMA cycle. During the probe, the lance is initialized which
> includes loading a configuration table from memory. If the init
> succeeds then the chip is detected. If it fails The KA46 System Board
> Specification says that the lance memory timeout error occurs when
> there is a memory parity on the previous DMA cycle.

I wonder if its possible that something is attached sooner in NetBSD-4
onwards which perturbs the le0 probe?

Does it definitely attach fine in 3.1.1 and not in 4.0? Could you
attach dmesg (or links to same) from youngest working and oldest
failing versions?

Running:
cvs diff -kk -u -rnetbsd-3-1-1-RELEASE -rnetbsd-4-0-RELEASE
sys/arch/vax/if/if_le.c sys/arch/vax/if/if_le_vsbus.c
sys/dev/ic/am79900.c sys/dev/ic/lance.c

picks some some updates to ANSI prototypes, the dropping of X25 glue,
and an update from uvm_km_valloc() to uvm_km_alloc(...
UVM_KMF_VAONLY), which all *seem* safe enough...
Its possible there was a gcc version update between which has caused
different code to be generated from the same source, or even now
requires volatile to guarantee the desired behaviour...

If its failing in attach.... I wonder, maybe try adding a delay before
trying the attach, to see if something else needs to settle, or
running whatever failing section twice to see if the second time
works.

Obviously, just to try to collect data - not as a "fix" :)

> The interesting thing is that the boot loaders from ROM and NetBSD
> always work without any indication of error. There has also never been
> any memory errors. The machine has a full complement of memory
> (104MB).
>
> If there are any comments or suggestions I would like to hear them. I
> hate to think there is a hardware problem that is unlikely to be
> fixable.

If the hardware is working reliably in all other ways, and under
earlier versions, then a fallback might be a local patch to try to
ignore the error, but definitely try to track down a real fix first :)