Date: Wed, 28 Jul 2010 11:47:37 -0700 From: Matthew Fleming <mdf356@gmail.com> To: David Naylor <naylor.b.david@gmail.com>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: Interrupt Problems Message-ID: <AANLkTi=%2BK7BRsKx0wsnw69orNVh%2BDHva6AYz9V94U5e3@mail.gmail.com> In-Reply-To: <4C50796C.4070509@FreeBSD.org> References: <201007281953.53131.naylor.b.david@gmail.com> <4C50796C.4070509@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
David Naylor wrote: > I have been having interrupt related problems with various subsystems. I > suspect this is related to the changes in the event timer infrastructure. > > The subsystems that have experienced interrupt problems: > - hda: this is the easiest to reproduce and what I used to isolate the > commits. I get ``pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt > timeout, channel dead'' reported and sound no longer plays. > - nfe: this has happened on occasion with no reliable way to reproduce. > ``watchdog timeouts'' are reported. After this happens all network traffic dies > and doing `ifconfig nfe0 down; ifconfig nfe0 up' panics the computer. > - dc: same thing as above. > - nvidia: has reported interrupt timeouts. This is independent of the > locking problem (that is fixed with recently published patch). No reliable way > to reproduce, appears to happen when under heavy load. X freezes as a result. > - ata: I had a HDD detach twice. I am not sure if this is related. I have > two HDD, each attached to a different controller. > > I tested this by using a kernel built from a cvsup date of 2010/06/20 and > 2010/06/22 (at midnight for both, aka 00:00:00). The former kernel does not > exhibit any problems while the latter does. This problem is also present with > a kernel from today. > > The motherboard is a N650SLI-DS4L with one graphics card. See attached for > more system information. > > Is there anything I can do to help diagnose the problem? When you say midnight on June 22, is that 11:59pm June 22 or 12:01 am June 22? I don't expect it, but there's a possibility that r210377 affected this. Can you check whether sys/sys/_task.h changes between the kernel that does work and the one that doesn't? Thanks, matthewhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=%2BK7BRsKx0wsnw69orNVh%2BDHva6AYz9V94U5e3>