From owner-freebsd-hackers@FreeBSD.ORG  Fri Mar 13 13:27:03 2009
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id EA306106564A
	for <freebsd-hackers@freebsd.org>; Fri, 13 Mar 2009 13:27:03 +0000 (UTC)
	(envelope-from avg@icyb.net.ua)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
	by mx1.freebsd.org (Postfix) with ESMTP id 1EEEE8FC14
	for <freebsd-hackers@freebsd.org>; Fri, 13 Mar 2009 13:27:02 +0000 (UTC)
	(envelope-from avg@icyb.net.ua)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
	[212.40.38.101])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA08386
	for <freebsd-hackers@freebsd.org>; Fri, 13 Mar 2009 15:27:00 +0200 (EET)
	(envelope-from avg@icyb.net.ua)
Message-ID: <49BA5F24.1020105@icyb.net.ua>
Date: Fri, 13 Mar 2009 15:27:00 +0200
From: Andriy Gapon <avg@icyb.net.ua>
User-Agent: Thunderbird 2.0.0.19 (X11/20090110)
MIME-Version: 1.0
To: freebsd-hackers@freebsd.org
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: intpm: multiple salves, collision ??
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2009 13:27:04 -0000


I observe some quite odd behavior with intpm(4).
I have a program that access two slaves at a high rate (no sleeps or
long calculations). The typical pattern of access is:
1. SMB_WRITEB slave1 reg1
2. SMB_READB slave1 reg2
3. SMB_READB *slave2* reg
4. SMB_READB slave1 reg3

There are many iterations of this pattern in a tight loop.
There is definitely only one entity that uses SMBus - no other userland
programs, nothing in kernel, nothing in ACPI and BIOS.

At random iteration smb ioctl would fail with EIO. This happens
consistently at step 4. Debugging printf in intpm gives this:
intsmb0: error = 8, status = 0x8
That is, PIIX4_SMBHSTSTAT_BUSC translated to SMB_ECOLLI.

Error can not be reproduced if only one slave is accessed, no matter in
what patterns.

-- 
Andriy Gapon