[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/45928: Random freeze and interrupt/system storms (netbsd-5/amd64 and -current/amd64)
The following reply was made to PR kern/45928; it has been noted by GNATS.
From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Subject: Re: kern/45928: Random freeze and interrupt/system storms
(netbsd-5/amd64 and -current/amd64)
Date: Tue, 21 Feb 2012 15:52:50 -0500
On Tue, 21 Feb 2012 17:00:09 +0000 (UTC)
David Holland <dholland-bugs%netbsd.org@localhost> wrote:
> The following reply was made to PR kern/45928; it has been noted by GNATS.
> From: David Holland <dholland-bugs%netbsd.org@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Subject: Re: kern/45928: Random freeze and interrupt/system storms
> (netbsd-5/amd64 and -current/amd64)
> Date: Tue, 21 Feb 2012 16:59:09 +0000
> On Mon, Feb 06, 2012 at 05:55:03AM +0000, Matthew Mondor wrote:
> > > Afterwards I disabled the re0 interface and decided to leave the
> > > running. The problem so far hasn't occurred. However, when I looked
> > > at rtl8169.c I couldn't find any obvious spl or locking issue so
> > And today I used netbsd-5 a while with re0 disabled, without issue
> > whatsoever. Then I enabled re0 and three times I could reproduce the
> > issue and recover by quickly disabling the interface before the system
> > was permanently frozen. Interestingly, I also left a systat-vmstat
> > command running and I could not really notice abnormal pin interrupt
> > floods. However, top will show two of the cores in "100% interrupt"
> > and the two others in "100% system", as usual.
> The problem could be in ACPI; it might be worth testing with ACPI
Although I remember doing this in an earlier test, I could retest
again. So far to mitigate this problem I avoid the re(4) onboard
interface and instead am using an added PCI ethernet card.
Another issue which affected performance and stability, albeit not as
drastically as using re(4), had to do with the onboard IDE/PATA
controller which viaide(4) does not yet support (kern/45917). PIO mode
was used, and with transfers of ~1.2MB/s maximum on the disks on that
adaptor, the system would slow down dramatically with seemingly random
non-involved processes accumulating a lot of CPU time. Fortunately, I
could for now force DMA using the 0x0001 pciide(4) flag, which makes
PATA drives much more usable.
Main Index |
Thread Index |