From owner-freebsd-bugs@FreeBSD.ORG Tue Jan 15 19:30:02 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 851A216A469 for ; Tue, 15 Jan 2008 19:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE9213C4F9 for ; Tue, 15 Jan 2008 19:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0FJU2o7023029 for ; Tue, 15 Jan 2008 19:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0FJU2uG023021; Tue, 15 Jan 2008 19:30:02 GMT (envelope-from gnats) Resent-Date: Tue, 15 Jan 2008 19:30:02 GMT Resent-Message-Id: <200801151930.m0FJU2uG023021@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Sven Berkvens-Matthijsse Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D41BE16A421 for ; Tue, 15 Jan 2008 19:26:44 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id CFA1113C458 for ; Tue, 15 Jan 2008 19:26:44 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m0FJPRmx039847 for ; Tue, 15 Jan 2008 19:25:27 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m0FJPRZM039846; Tue, 15 Jan 2008 19:25:27 GMT (envelope-from nobody) Message-Id: <200801151925.m0FJPRZM039846@www.freebsd.org> Date: Tue, 15 Jan 2008 19:25:27 GMT From: Sven Berkvens-Matthijsse To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/119696: ral device causes massive interrupt storm sometimes X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2008 19:30:02 -0000 >Number: 119696 >Category: kern >Synopsis: ral device causes massive interrupt storm sometimes >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jan 15 19:30:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Sven Berkvens-Matthijsse >Release: FreeBSD 7.0-PRERELEASE #5: Thu Jan 10 18:27:04 CET 2008 amd64 >Organization: De Kattenfabriek >Environment: FreeBSD paws.berkvens.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #5: Thu Jan 10 18:27:04 CET 2008 sven@paws.berkvens.net:/usr/obj/usr/src/sys/PAWS amd64 >Description: In some environments, like my home, my ral WiFi device works like a charm. No problems whatsoever. But in some environments, like my office, it causes a massive interrupt storm (in the order of 70000 interrupts per second) to occur. I have the following device in my laptop (output of pciconf -l -v): ral0@pci0:5:9:0: class=0x028000 card=0xb8331462 chip=0x03021814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp' device = 'RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless a/b' class = network In my office environment, the device does not detect any networks at all. My colleague's laptop, which has a recent Intel chipset-based WiFi card (and also runs the same version of FreeBSD), has no problems with the environment, and in fact it detects more than ten networks. Stopping the interface with "/etc/rc.d/netif stop ral0" causes the interrupt storm to stop. Starting the interface again (it's configured for DHCP and WPA by the way in /etc/rc.conf) causes the interrupt storm to resume as before. But even if the device is not up, it produces around 30 interrupts per second. No idea is that's normal or not, though. >How-To-Repeat: I don't know how other people could reproduce the problem. I know how to reproduce it in my two described environments, though, so if anyone wants me to test anything (custom patches, etc are no problem) in either environment, that's certainly possible. >Fix: I'm not sure what the problem is, let alone a solution. >Release-Note: >Audit-Trail: >Unformatted: