daily CVS update output

[NetBSD source update]

Updating src tree:
P src/external/gpl3/gcc/dist/gcc/auto-profile.c
P src/external/gpl3/gcc/dist/gcc/graphite-isl-ast-to-gimple.c
P src/external/gpl3/gcc/dist/gcc/system.h
P src/share/man/man4/vioscsi.4
P src/sys/dev/pci/if_rtwn.c
P src/sys/dev/pci/if_vioif.c
P src/sys/dev/usb/uts.c
P src/sys/kern/vfs_mount.c
P src/sys/kern/vfs_vnode.c
P src/sys/net/npf/npf_ctl.c
P src/sys/opencrypto/crypto.c
P src/sys/opencrypto/cryptodev.c
P src/sys/opencrypto/cryptodev.h
P src/sys/opencrypto/cryptosoft.c
P src/sys/opencrypto/deflate.c
P src/sys/opencrypto/ocryptodev.c
P src/sys/uvm/uvm_extern.h
P src/sys/uvm/uvm_map.h
P src/tests/net/net_common.sh
P src/tests/net/ipsec/t_ipsec_misc.sh
P src/usr.sbin/npf/npftest/npftest.c

Updating xsrc tree:


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Thu May 18 03:01:41 2017
SUP Scan for current completed at Thu May 18 03:01:57 2017
SUP Scan for mirror starting at Thu May 18 03:01:57 2017
SUP Scan for mirror completed at Thu May 18 03:04:33 2017




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  53966792 May 18 03:06 ls-lRA.gz

Re: re0 watchdog timeouts

[Thomas Mueller]

FreeBSD also has some problems with Ethernet re driver, at least on some 
versions of the Realtek 8111/8168/8169 chip.

> On Mon, May 15, 2017 at 11:19:55PM -0700, Soren Jacobsen wrote:
> > On 05/16 12:27, sc dying wrote:
> > > Is the condition at line 1919 of ic/rtl8169.c inverted?
> > > It should be `!=' to make it act as before patch when
> > > RTKQ_IM_HW is disabed in if_re_pci.c.

> > Good eye.  Fixed.

> With this (ic/rtl8169.c 1.151), and if_re_pci.c 1.46 (i.e., 1.47 reverted)
> I have a happy network! (No timeouts, delays nor file corruption seen so far
> despite trying.)

> Cheers,

> Patrick

I actually tested this update, building from NetBSD 7.99.71 i386 installation 
for amd64.

Intel Sandy Bridge motherboard, MSI Z68MA-ED55(B3).

I booted custom kernel, haven't tried generic on this computer yet for 7.99.71.

I tested this by running "cvs up -dP -A" from top of src tree, and there were 
no re0 watchdog timeouts.

But the kernel still won't boot on other computer,
Intel Ivy Bridge MSI Z77 MPOWER motherboard; I mentioned this about 10(?) days 
ago.

Tom

Re: re0 watchdog timeouts

[Patrick Welche]

On Wed, May 17, 2017 at 01:12:14PM +, Jared McNeill wrote:
> Are you able to get performance numbers before/after this set of changes? It
> has a noticeable impact on my arm board.

No - the change is from broken to working (I had a long "file corruption"
thread that was inconclusive, but which involved cvs protocol ending up
inside cvs checkout files - just did a few checkouts, and all is well.
Just to make it non-deterministic, I did a BIOS update at some point
during the troubles.)

Cheers,

Patrick

Re: re0 watchdog timeouts

[Jared McNeill]

Are you able to get performance numbers before/after this set of changes? 
It has a noticeable impact on my arm board.


Cheers,
Jared

On Wed, 17 May 2017, Patrick Welche wrote:


On Mon, May 15, 2017 at 11:19:55PM -0700, Soren Jacobsen wrote:

On 05/16 12:27, sc dying wrote:

Is the condition at line 1919 of ic/rtl8169.c inverted?
It should be `!=' to make it act as before patch when
RTKQ_IM_HW is disabed in if_re_pci.c.


Good eye.  Fixed.


With this (ic/rtl8169.c 1.151), and if_re_pci.c 1.46 (i.e., 1.47 reverted)
I have a happy network! (No timeouts, delays nor file corruption seen so far
despite trying.)

Cheers,

Patrick

Re: re0 watchdog timeouts

[Patrick Welche]

On Mon, May 15, 2017 at 11:19:55PM -0700, Soren Jacobsen wrote:
> On 05/16 12:27, sc dying wrote:
> > Is the condition at line 1919 of ic/rtl8169.c inverted?
> > It should be `!=' to make it act as before patch when
> > RTKQ_IM_HW is disabed in if_re_pci.c.
> 
> Good eye.  Fixed.

With this (ic/rtl8169.c 1.151), and if_re_pci.c 1.46 (i.e., 1.47 reverted)
I have a happy network! (No timeouts, delays nor file corruption seen so far
despite trying.)

Cheers,

Patrick

Re: change "panic: i82489_icr_wait: busy" when entering DDB to warning

[Kimihiro Nonaka]

Hi,

On Wed, Oct 28, 2015 at 12:56 AM, Christoph Badura  wrote:

> I get an annoying recursive "panic: i82489_icr_wait: busy" when invoking
> DDB from the console on my Dell PE1400SC machines. C.f. the console log at
> the end.

Could you try the attached patch.

Regards,
-- 
Kimihiro Nonaka
diff --git a/sys/arch/amd64/amd64/db_interface.c 
b/sys/arch/amd64/amd64/db_interface.c
index 5b07bf197f3..df64670046f 100644
--- a/sys/arch/amd64/amd64/db_interface.c
+++ b/sys/arch/amd64/amd64/db_interface.c
@@ -131,11 +131,25 @@ db_suspend_others(void)
win = (ddb_cpu == cpu_me);
__cpu_simple_unlock(_lock);
if (win) {
+   CPU_INFO_ITERATOR cii;
+   struct cpu_info *ci, *self = curcpu();
+   bool do_ipi = false;
+
+   for (CPU_INFO_FOREACH(cii, ci)) {
+   if (ci == self)
+   continue;
+   if ((ci->ci_flags & CPUF_RUNNING) == 0)
+   continue;
+   do_ipi = true;
+   break;
+   }
+   if (do_ipi) {
 #ifdef XEN
-   xen_broadcast_ipi(XEN_IPI_DDB);
+   xen_broadcast_ipi(XEN_IPI_DDB);
 #else
-   x86_ipi(ddb_vec, LAPIC_DEST_ALLEXCL, LAPIC_DLMODE_FIXED);
+   x86_ipi(ddb_vec, LAPIC_DEST_ALLEXCL, 
LAPIC_DLMODE_FIXED);
 #endif /* XEN */
+   }
 
}
ddb_mp_online = x86_mp_online;
diff --git a/sys/arch/i386/i386/db_interface.c 
b/sys/arch/i386/i386/db_interface.c
index 5b51554eefa..c8580801de7 100644
--- a/sys/arch/i386/i386/db_interface.c
+++ b/sys/arch/i386/i386/db_interface.c
@@ -142,11 +142,25 @@ db_suspend_others(void)
win = (ddb_cpu == cpu_me);
__cpu_simple_unlock(_lock);
if (win) {
+   CPU_INFO_ITERATOR cii;
+   struct cpu_info *ci, *self = curcpu();
+   bool do_ipi = false;
+
+   for (CPU_INFO_FOREACH(cii, ci)) {
+   if (ci == self)
+   continue;
+   if ((ci->ci_flags & CPUF_RUNNING) == 0)
+   continue;
+   do_ipi = true;
+   break;
+   }
+   if (do_ipi) {
 #ifdef XEN
-   xen_broadcast_ipi(XEN_IPI_DDB);
+   xen_broadcast_ipi(XEN_IPI_DDB);
 #else
-   x86_ipi(ddb_vec, LAPIC_DEST_ALLEXCL, LAPIC_DLMODE_FIXED);
+   x86_ipi(ddb_vec, LAPIC_DEST_ALLEXCL, 
LAPIC_DLMODE_FIXED);
 #endif /* XEN */
+   }
}
ddb_mp_online = x86_mp_online;
x86_mp_online = false;