Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 08 Aug 2005 21:20:10 -0700
From:      Sam Leffler <sam@errno.com>
To:        Mike Tancsa <mike@sentex.net>
Cc:        Poul-Henning Kamp <phk@haven.freebsd.dk>, Michael Reifenberger <mike@Reifenberger.com>, freebsd-current@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>
Subject:   Re: Hifn driver in SMP (was Re: GELI - disk encryption GEOM class committed.)
Message-ID:  <42F82EFA.1010001@errno.com>
In-Reply-To: <6.2.1.2.0.20050808162711.04d40c28@64.7.153.2>
References:  <Your message of "Mon, 08 Aug 2005 10:49:07 %2B0200."	<20050808084907.GB1578@garage.freebsd.pl>	<42475.1123513974@phk.freebsd.dk> <6.2.1.2.0.20050808162711.04d40c28@64.7.153.2>

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Tancsa wrote:
> At 11:12 AM 08/08/2005, Poul-Henning Kamp wrote:
> 
> 
>> I belive there is a bug in the HiFn chips that makes them do a soft reset
>> under some set of circumstances which we have never been able to nail
>> down.
> 
> 
> Actually,
>         I think this is something different.  I know the issue you are 
> referring to, and it seems to happen on many (but not all) motherboards. 
> Note, this problem does not happen in UP mode on this box, only on SMP.  
> Also, I just booted RELENG_4_11 on the box and installed an SMP kernel.
> 
> hippo# hifnstats
> input 7648447680 bytes 2338053 packets
> output 7648431264 bytes 2338052 packets
> invalid 0 nomem 0 abort 0
> noirq 1263291 unaligned 0
> totbatch 0 maxbatch 0
> nomem: map 0 load 0 mbuf 0 mcl 0 cr 0 sd 0
> hippo#
> 
> I am able to run
> /usr/bin/openssl aes-128-cbc -in big -k pass | ssh -c aes128-cbc 
> mdtancsa@127.0.0.1 "cat - >  /dev/null"
> until the cows come home without issue, even with an SMP kernel built. 
> So it seems like its something with this box and RELENG_6 that causes 
> the box to totally lock up

I much prefer cryptotest for exercising the hardware.  If you increase 
the number of concurrent threads (-t I think) you can really load the 
device.

I wouldn't be surprised if there were an smp locking bug in the crypto 
code as I'm not sure it's been well-exercised recently and with more of 
the kernel coming out from under Giant the locking within the subsystem 
is getting more testing.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42F82EFA.1010001>