File corruption on HEAD

All,

I've run into an interesting case of file corruption just
now, trying to
upgrade a 4.99.3 installation on a Quadra 650 from last
November to a
4.99.20 snapshot of today's sources.

As always, I rcp(1)ed the result of the cross build over
from the
fileserver, installed the new GENERIC kernel, rebooted, went
to single user
mode and started a script that checks the tarballs against
the MD5 hashes
and goes on to untar them.

Now, although the MD5 comparison went fine, four of the
tarballs came up
with gzip crc errors. A 'gzip --test' run came up with three
corrupted
archives. Since I suspected the network transfer, I
re-fetched the three
tarballs, this time with ftp, and unfortunately overwrote
what I had
already fetched. Unsurprisingly, the re-fetched tarballs
were also corrupt.

The tarballs on the fileserver are fine. Using a nubus sm(4)
adapter
instead of the obio sn(4) also results in corrupted tarballs
(which
probably means that Izumi-san's driver changes are not
responsible here). A
memory test came up negative. The machine has built quite a
few kernels
with 4.99.3, and has run a 'build.sh tools' from nfs-mounted
sources a week
ago just fine.

While I go on thinking of how to recover the machine - does
anyone run
bleeding-edge current, and can report their experience with
an update?

	hauke


--
"It's never straight up and down"     (DEVO)

Hauke Fath wrote:
>I've run into an interesting case of file corruption
just now, trying to
>upgrade a 4.99.3 installation on a Quadra 650 from last
November to a
>4.99.20 snapshot of today's sources.

[snip]

>While I go on thinking of how to recover the machine -
does anyone run
>bleeding-edge current, and can report their experience
with an update?

I run current on my Q950.

It seemed fine with a kernel built last week, but will try
tomorrow
with a newer one and report back.

Robert Swindells

haukeEspresso.Rhein-Neckar.DE wrote:

> The tarballs on the fileserver are fine. Using a nubus
sm(4) adapter
> instead of the obio sn(4) also results in corrupted
tarballs (which
> probably means that Izumi-san's driver changes are not
responsible here).

Both sm(4) and new sn(4) use bus_dma(9) so my changes
against
m68k/bus_dma.c might cause the trouble, but with some quick
tests
(ftp base.tgz via sn0 to sd0 then "gzip -t
base.tgz" several times)
don't show any errors on my LC630 running -current GENERIC
updated today.
---
Izumi Tsutsui

At 23:26 Uhr +0900 15.6.2007, Izumi Tsutsui wrote:
>haukeEspresso.Rhein-Neckar.DE wrote:
>
>> The tarballs on the fileserver are fine. Using a
nubus sm(4) adapter
>> instead of the obio sn(4) also results in corrupted
tarballs (which
>> probably means that Izumi-san's driver changes are
not responsible here).
>
>Both sm(4) and new sn(4) use bus_dma(9)

sys/dev/ic/sm91cxx.c is DMA free, AFAICS? Unfortunately, I
might add... I
get exactly the same speed over ftp (~650 KByte/sec) as with
the onboard
sn(4), although the interface is 100 MBit.

> so my changes against
>m68k/bus_dma.c might cause the trouble, but with some
quick tests
>(ftp base.tgz via sn0 to sd0 then "gzip -t
base.tgz" several times)
>don't show any errors on my LC630 running -current
GENERIC updated today.

Can you try the equivalent of a 'for ff in `ls *.tgz`; do
gzip --test $ff;
done' in a snapshot's binary/sets directory? I see crc
errors on every
second or third set, but never on the first one.

I'll run a memory test overnight to be sure, though, and
then try to
downgrade to the 4.99.3 snapshot to rule out memory issues.

	hauke


--
"It's never straight up and down"     (DEVO)