Subject: Re: File corruption on HEAD
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
List: port-mac68k
Date: 06/16/2007 17:07:06
At 15:23 Uhr +0900 16.6.2007, Izumi Tsutsui wrote:
>hauke@Espresso.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)