Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Jun 2006 11:46:21 -0400 (EDT)
From:      David Gilbert <dgilbert@daveg.ca>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   kern/99649: SiI 3112 controller hangs with read/write load
Message-ID:  <20060630154621.D37E34AC2B@canoe.dclg.ca>
Resent-Message-ID: <200606301550.k5UFoHGd069389@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         99649
>Category:       kern
>Synopsis:       SiI 3112 controller hangs with read/write load
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jun 30 15:50:16 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     David Gilbert
>Release:        FreeBSD 6.1-STABLE i386
>Organization:
DaveG.ca
>Environment:
FreeBSD virtual.accountingreality.com 6.1-RELEASE-p2 FreeBSD 6.1-RELEASE-p2 #2: Wed Jul 26 22:50:39 EDT 2006     root@virtual.accountingreality.ca:/usr/obj/usr/src/sys/VR  amd64

>Description:
The system has an onboard nVidia nForce MCP51 SATA300 controller ...
which (in some other PR) has a known issue where you can only attach
one drive to it.

Since I had a SiI 3112 SATA150 controller PCI card lying around, 
I attached one drive to the motherboard and one drive to the SiI.

The problem occurs under heavy write load with some reading.  fsck
alone will not trigger the problem.  A Geom mirror sync works fine,
too.  The fact that the geom sync worked fine (which writes at
65 to 75 megabytes per second) gave the the idea that write-only
was good.

Anyways... some moderate amount of tars running causes the system to
hang with WRITE_DMA48 timeouts.

The system will run fine with geom_mirror on prefer ... such that the
SiI connected drive receives only write requests.
>How-To-Repeat:
I copy a bunch of data from one place to another place on the drive.

It's possible that this is queue related because the L(q) parameter
on gstat tends to be more than 100 when it hangs.
>Fix:

	None known.


>Release-Note:
>Audit-Trail:
>Unformatted:



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