Re: File corruption on HEAD

haukeEspresso.Rhein-Neckar.DE wrote:

> >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.

Ah, you are right.
I blindly thought 100Base-TX chips must have DMA
capability...

> 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 get *.tgz sets from daily-build and try the above checks
(~10 times),
but I see no errors.

Is your kernel is GENERIC or some custom one?
---
Izumi Tsutsui

At 15:23 Uhr +0900 16.6.2007, Izumi Tsutsui wrote:
>haukeEspresso.Rhein-Neckar.DE wrote:
>
>> >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.
>
>Ah, you are right.
>I blindly thought 100Base-TX chips must have DMA
capability...

>From the data sheet that I looked at, the sm91c100 is
DMA capable. But the
MI driver code apparently supports a family of mostly 10
MBit adapters
which are not. For all I know, after your switch of sn(4) to
the MI driver,
a sonic Nubus card will be the first Nubus card doing DMA on
NetBSD/mac68k.

>> 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 get *.tgz sets from daily-build and try the above
checks (~10 times),
>but I see no errors.

That's good (for MacBSD), but doesn't solve my problem.  ;)

>Is your kernel is GENERIC or some custom one?

GENERIC (GENERICSBC actually, but that doesn't make a
difference on a Quadra).

The nightly memory test went flawless. I'll downgrade the
machine to a
netbsd-4 snapshot for now, and try a newer current snapshot
kernel then.

	hauke


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

At 15:23 Uhr +0900 16.6.2007, Izumi Tsutsui wrote:
>> 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 get *.tgz sets from daily-build and try the above
checks (~10 times),
>but I see no errors.

Sigh...

To summarize a day of experimenting, and swapping
components: The 40 MHz
clock was too much for the 68040/33 cpu. Going back from a
20 MHz
oscillator to an 18 MHz one "fixed" the problem.

Obviously no amount of overclocking can catch up time wasted
that way.

Sorry for the fuzz,

	hauke


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