From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 06:52:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CABBE1065672; Thu, 30 Sep 2010 06:52:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2723C8FC15; Thu, 30 Sep 2010 06:52:58 +0000 (UTC) Received: by bwz15 with SMTP id 15so1522865bwz.13 for ; Wed, 29 Sep 2010 23:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=f3QaxUIuFk3vemwHpjNq87f+ivw86Vr7wN7Zs46ErHI=; b=vbHdMqLV3nDK/N37ivoX7kGYMHDRNv4uoZwdUXza61tzC5ho9KfaT6TEZogd5u8gyL SOBNLoEClIhHXMj6luMH5IiHmYbXd65gVqIwaK/t8kS9bRVpzaapSIbhWjej42l3DMui rHoZIEypq0mKYO9lzeu31BbK5kJpQJgqXrQPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=aZ7PlqEIxyqDvNDfnE/LW5Mg+PW75XMAZOMsMtdw+qUUUYCV7LrbEWAv3mW07XysG7 TUqHBXLCKpXqdKCbuHo30JwOFmEn9aSSNFYSJTY/kcOqoBe8qlO4AiW+oZ/6QzEXthNT I/LgmKp4sOaQxVQngl0hBYsmN24yMi39vI+OY= Received: by 10.204.69.18 with SMTP id x18mr2323293bki.34.1285829576603; Wed, 29 Sep 2010 23:52:56 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f18sm7453786bkf.3.2010.09.29.23.52.54 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 23:52:55 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA433B7.9010306@FreeBSD.org> Date: Thu, 30 Sep 2010 09:52:39 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Naylor References: <201009291207.53146.naylor.b.david@gmail.com> <201009292048.11194.naylor.b.david@gmail.com> <4CA41ED6.5060208@FreeBSD.org> <201009300755.46989.naylor.b.david@gmail.com> In-Reply-To: <201009300755.46989.naylor.b.david@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 06:53:00 -0000 David Naylor wrote: > On Thursday 30 September 2010 07:23:34 Alexander Motin wrote: >> David Naylor wrote: >>> On Wednesday 29 September 2010 18:25:13 Alexander Motin wrote: >>>> David Naylor wrote: >>>>> On Wednesday 29 September 2010 16:19:08 Andriy Gapon wrote: >>>>>> What do you try to actually achieve? >>>>> I was trying to boot a system and it was panicking due to stray >>>>> interrupts. It turned out to be caused by HPET. I found >>>>> `hint.hpet.0.clock=0' which fixed the problem. >>>>> >>>>> This means HPET does not work on any of my machines. The other one's >>>>> symptoms are hda losing interrupts after a period of up-time. >>>> What chipset do you use? Nvidia MCP5x? Could you send me your verbose >>>> dmesg? >>> Yes, the one is a MCP51, the other is a ICH8M. >>> >>> The desktop is a Gigabyte N650SLI-DS4L. Its symptom is hda losing >>> interrupts after a period of time. >> There are too many reports about different lost interrupts problems on >> different controllers of MCP5x. I don't know the reason. Attached patch >> should disable using regular HPET interrupts on NVidia chipsets. I hope >> it will work as workaround. May be it is too aggressive, but better to >> be safe then sorry. I assume that legacy_route mode may still work fine >> there. It would be nice to test it. > > I assume you mean hint.hpet.0.legacy_route=1? I'll give that a try later > today on both machines. Make sure that both attimer and atrtc disabled, as mentioned in hpet(4). > Is your patch the same as hint.hpet.0.clock=0? By default - effectively yes. But it still allows to configure legacy_route, which is, for example, default for Linux. >>> The laptop is a Acer 2920. Its symptom for a GENERIC is a panic saying >>> stray interrupt (irq7), with a custom kernel booting stalls. >> This is strange, as my Acer with the same ICH8M works fine in all >> possible modes. Also IMHO stray interrupts are not a reason to panic. >> Could you show what it looks like? > > See http://markmail.org/message/smxnofrdmmkxyvnd for my previous email that > includes the backtrace from that panic. When I booted in i386 safe mode the > kernel reported stray interrupts on irq7. vmstat -i shows irq7 as "stray > irq7". I am not sure "stray irq7" related here. Instead more suspicious looks probable irq20 interrupt sharing between HPET and uhci0 and the fact that system panicked during interrupt handler registration by uhci0. I can't be sure what IRQ was used by HPET there, as in only present dmesg it was disabled, but as soon as HPET registered early, I think it grabbed first possible - irq20. On my system HPET also uses irq20, but uhci0 lives on irq16 and so irq20 is not shared. To collect more data you may try to hint HPET driver to avoid irq20 by setting hint.hpet.0.allowed_irqs=0x00e00000 or other values. I've tried same recipy to create sharing on my system, but still found no problem. -- Alexander Motin