daily CVS update output

[NetBSD source update]

Updating src tree:
P src/distrib/alpha/instkernel/fdset/Makefile
P src/distrib/sets/lists/comp/mi
P src/distrib/sets/lists/debug/mi
P src/lib/libkvm/kvm_aarch64.c
P src/libexec/httpd/CHANGES
P src/sys/sys/cdefs.h
P src/tests/lib/libc/net/getaddrinfo/no_serv_v4v6.exp
P src/tests/sys/uvm/t_uvm_physseg.c

Updating xsrc tree:


Killing core files:



Updating release-7 src tree (netbsd-7):
U doc/CHANGES-7.3
P usr.bin/telnet/telnet.c
P usr.bin/telnet/utilities.c

Updating release-7 xsrc tree (netbsd-7):



Updating release-8 src tree (netbsd-8):
U doc/CHANGES-8.1
P share/man/man4/urtwn.4
P sys/dev/pci/ahcisata_pci.c
P sys/dev/pci/if_wm.c
P sys/dev/usb/if_urtwn.c
P usr.bin/telnet/telnet.c
P usr.bin/telnet/utilities.c

Updating release-8 xsrc tree (netbsd-8):




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  50591748 Dec 19 03:08 ls-lRA.gz

Re: Panic on a -current from 13/12/2018

[Masanobu SAITOH]

On 2018/12/18 20:13, Masanobu SAITOH wrote:

Hi!

On 2018/12/17 19:38, Chavdar Ivanov wrote:

I went through a series of tests. It is indeed that point the panic
takes place, the two parts of the screendump are in

http://ci4ic4.tx0.org/nb-panic-wm-03.png and
http://ci4ic4.tx0.org/nb-panic-wm-04.png .


  Thanks. This is the workaround code for broken lapic timer
counter which was added in:

 http://mail-index.netbsd.org/source-changes/2017/11/23/msg089946.html
 
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/x86/x86/lapic.c.diff?r1=1.63=1.64=h

Your VM is configured act as KVM
(See system->acceleration(L) tab or see .box file's "Paravirt provider=")

I set up my vm to KVM and


VirtualBox gives three Intel NIC options:

Intel PRO/1000 MT Desktop (82540EM)
Intel PRO/1000 T Server   (82543GC)
Intel PRO/1000 MT Server  (82545EM)

I was able to get a panic with the same kernel from 13/12/2018 only
when I select the second option:


  I changed my VM's setting to use 82543GC. I tried hibernation
three times but I couldn't reproduce the problem. I couldn't reproduce
the same problem, but this problem must be exist because you had the
problem.

  The possibilities are:
 a) VirtualBox's lapic is not good.
 b) Our workaround code is not perfect or somewhere is not good.
 c) any others

I suspect this problem is not from if_wm.c. but from

There was a VirtualBox upgrade a few weeks ago, perhaps the problem is there.



  I read vbox/src/VBox/Devices/Network/DevE1000.cpp. One of the
difference between 82543GC emulation and other two is that
it generates interrupt when chip reset occurred. If other network
device emulation works well, I suspect that the reset timing in vbox
is not good and it makes no update of lapic timer.

  Workarounds are:
 a) Don't use KVM mode and use "Default" or other.
    On my Windows7's virtual box, "Default" makes
    CPUID2_RAZ bit not set. It makes NetBSD recognize
    it's not on KVM.


 If the problem which lapic timer stops also exist on the "Defalut" mode,
that workaround isn't used and delay() won't work. If so, b) is the best
to avoid the problem.


 b) Use Other than 82543GC.
 c) any others

BTW, when I use 82543GC emulation, I got the following bug:

makphy0 at wm0 phy 0: Marvell 88E1000 Gigabit PHY, rev. 0
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
makphy1 at wm0 phy 1: Marvell 88E1000 Gigabit PHY, rev. 0
makphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

(snip)

makphy31 at wm0 phy 31: Marvell 88E1000 Gigabit PHY, rev. 0
makphy31: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ifmedia_match: multiple match for 0x20/0xfbff9ff, selected instance 0


This _IS_ a bug of VirtualBox's 82543GC emulation.
DevE1000Phy.cpp line 568 says:

 /* Note: A single PHY is supported, ignore PHYADR */

So I recommend all users not to use 82543GC emulation until this PHY
bug is fixed.


..
-rw--- 1 root wheel   2199810 Dec 17 09:24 netbsd.9
-rw--- 1 root wheel 147348504 Dec 17 09:24 netbsd.9.core
/var/crash # gdb netbsd.9
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from netbsd.9...(no debugging symbols found)...done.
(gdb) target kvm netbsd.9.core
0x80222d75 in cpu_reboot ()
(gdb) bt
#0  0x80222d75 in cpu_reboot ()
#1  0x8076e6f7 in db_reboot_cmd ()
#2  0x8076ee92 in db_command ()
#3  0x8076f20c in db_command_loop ()
#4  0x80772b80 in db_trap ()
#5  0x8021f5c2 in kdb_trap ()
#6  0x802244b1 in trap ()
#7  0x8021d568 in alltraps ()
#8  0x8021de45 in breakpoint ()
#9  0x809d54b0 in vpanic ()
#10 0x809d5550 in panic ()
#11 0x802514f0 in lapic_delay ()
#12 0x80353270 in wm_gmii_i82543_readreg ()
#13 0x807b1aa5 in makphy_status ()
#14 0x807b1cf7 in makphy_service ()
#15 0x807a826c in mii_tick ()
#16 0x80360926 in wm_tick ()
#17 0x809b6b96 in callout_softclock ()
#18 0x809aaa55 in softint_dispatch ()
#19 0x8021d21f in Xsoftintr ()


  I rebuilt the kernel (on a different physical host, but there may
have been an update on the 14th there) and tried to get a panic with
the .gdb kernel, but it never happened.

Obviously it is not a problem for me or anyone running NetBSD as a

Re: Panic on a -current from 13/12/2018

[Masanobu SAITOH]

Hi!

On 2018/12/17 19:38, Chavdar Ivanov wrote:

I went through a series of tests. It is indeed that point the panic
takes place, the two parts of the screendump are in

http://ci4ic4.tx0.org/nb-panic-wm-03.png and
http://ci4ic4.tx0.org/nb-panic-wm-04.png .


 Thanks. This is the workaround code for broken lapic timer
counter which was added in:

http://mail-index.netbsd.org/source-changes/2017/11/23/msg089946.html

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/x86/x86/lapic.c.diff?r1=1.63=1.64=h

Your VM is configured act as KVM
(See system->acceleration(L) tab or see .box file's "Paravirt provider=")

I set up my vm to KVM and


VirtualBox gives three Intel NIC options:

Intel PRO/1000 MT Desktop (82540EM)
Intel PRO/1000 T Server   (82543GC)
Intel PRO/1000 MT Server  (82545EM)

I was able to get a panic with the same kernel from 13/12/2018 only
when I select the second option:


 I changed my VM's setting to use 82543GC. I tried hibernation
three times but I couldn't reproduce the problem. I couldn't reproduce
the same problem, but this problem must be exist because you had the
problem.

 The possibilities are:
a) VirtualBox's lapic is not good.
b) Our workaround code is not perfect or somewhere is not good.
c) any others

I suspect this problem is not from if_wm.c. but from

There was a VirtualBox upgrade a few weeks ago, perhaps the problem is there.



 I read vbox/src/VBox/Devices/Network/DevE1000.cpp. One of the
difference between 82543GC emulation and other two is that
it generates interrupt when chip reset occurred. If other network
device emulation works well, I suspect that the reset timing in vbox
is not good and it makes no update of lapic timer.

 Workarounds are:
a) Don't use KVM mode and use "Default" or other.
   On my Windows7's virtual box, "Default" makes
   CPUID2_RAZ bit not set. It makes NetBSD recognize
   it's not on KVM.
b) Use Other than 82543GC.
c) any others

BTW, when I use 82543GC emulation, I got the following bug:

makphy0 at wm0 phy 0: Marvell 88E1000 Gigabit PHY, rev. 0
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
makphy1 at wm0 phy 1: Marvell 88E1000 Gigabit PHY, rev. 0
makphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

(snip)

makphy31 at wm0 phy 31: Marvell 88E1000 Gigabit PHY, rev. 0
makphy31: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ifmedia_match: multiple match for 0x20/0xfbff9ff, selected instance 0


This _IS_ a bug of VirtualBox's 82543GC emulation.
DevE1000Phy.cpp line 568 says:

/* Note: A single PHY is supported, ignore PHYADR */

So I recommend all users not to use 82543GC emulation until this PHY
bug is fixed.


..
-rw--- 1 root wheel   2199810 Dec 17 09:24 netbsd.9
-rw--- 1 root wheel 147348504 Dec 17 09:24 netbsd.9.core
/var/crash # gdb netbsd.9
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from netbsd.9...(no debugging symbols found)...done.
(gdb) target kvm netbsd.9.core
0x80222d75 in cpu_reboot ()
(gdb) bt
#0  0x80222d75 in cpu_reboot ()
#1  0x8076e6f7 in db_reboot_cmd ()
#2  0x8076ee92 in db_command ()
#3  0x8076f20c in db_command_loop ()
#4  0x80772b80 in db_trap ()
#5  0x8021f5c2 in kdb_trap ()
#6  0x802244b1 in trap ()
#7  0x8021d568 in alltraps ()
#8  0x8021de45 in breakpoint ()
#9  0x809d54b0 in vpanic ()
#10 0x809d5550 in panic ()
#11 0x802514f0 in lapic_delay ()
#12 0x80353270 in wm_gmii_i82543_readreg ()
#13 0x807b1aa5 in makphy_status ()
#14 0x807b1cf7 in makphy_service ()
#15 0x807a826c in mii_tick ()
#16 0x80360926 in wm_tick ()
#17 0x809b6b96 in callout_softclock ()
#18 0x809aaa55 in softint_dispatch ()
#19 0x8021d21f in Xsoftintr ()


  I rebuilt the kernel (on a different physical host, but there may
have been an update on the 14th there) and tried to get a panic with
the .gdb kernel, but it never happened.

Obviously it is not a problem for me or anyone running NetBSD as a
VirtualBox guest, as using vioif / virtio is almost as twice as fast,
but I reported the panic thinking it may be relevant in other use
cases.


 Thank you for your report!




On Mon, 17