From owner-freebsd-usb@FreeBSD.ORG Sat Jan 10 11:52:20 2015 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C3D8963; Sat, 10 Jan 2015 11:52:20 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0A50C8C; Sat, 10 Jan 2015 11:52:18 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id ADB281FE022; Sat, 10 Jan 2015 12:52:09 +0100 (CET) Message-ID: <54B11299.6040909@selasky.org> Date: Sat, 10 Jan 2015 12:52:57 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Daniel Kolesa , Adrian Chadd , freebsd-usb@freebsd.org Subject: Re: Lynx Point USB - large amount of interrupts (300k / second) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 11:52:20 -0000 On 01/10/15 00:37, Daniel Kolesa wrote: > 2015-01-09 23:26 GMT+00:00 Daniel Kolesa : >> 2015-01-09 20:24 GMT+00:00 Adrian Chadd : >>> hi, >>> >>> I have a haswell desktop box at home: >>> >>> CPU: Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz (3192.67-MHz K8-class CPU) >>> >>> With lynx point USB: >> >> Also Haswell here, but with H97 chipset, which means Wildcat Point >> USB. Not getting the issue. >> >>> >>> adrian@test-2:~ % dmesg | grep ehci >>> ehci0: mem >>> 0xf7f1c000-0xf7f1c3ff irq 16 at device 26.0 on pci0 >>> usbus1 on ehci0 >>> ehci1: mem >>> 0xf7f1b000-0xf7f1b3ff irq 23 at device 29.0 on pci0 >>> usbus2 on ehci1 >>> Hi, You can easily check who's generating the interrupts by setting: hw.usb.ehci.debug=16 hw.usb.xhci.debug=16 If the interrupt status is all-zero, then it is a bug somewhere else! --HPS