Re: kern/45928: Random freeze and interrupt/system storms (netbsd-5/amd64 and -current/amd64)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR kern/45928; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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
 > Cc: 
 > 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 
 > system
 >   >  >  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 
 > far...
 >   >  
 >   >  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
 >  disabled.
 
 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.
 -- 
 Matt