Re: netbsd-8 crash in ixg driver during booting

[6bone]

Does your machine boot with the latest -current?


I have tested the current sources from tonignt.

https://suse.uni-leipzig.de/crash/crash-current1.jpg
https://suse.uni-leipzig.de/crash/crash-current2.jpg

Regards
Uwe

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/external/bsd/nvi/dist/vi/vs_refresh.c
P src/external/gpl3/gcc/dist/gcc/toplev.c
P src/external/gpl3/gcc/dist/libiberty/vprintf-support.c
P src/external/gpl3/gcc/lib/liblto_plugin/Makefile
P src/external/gpl3/gcc.old/dist/libiberty/vprintf-support.c
P src/external/gpl3/gcc.old/lib/liblto_plugin/Makefile
P src/sys/arch/amd64/conf/Makefile.amd64
P src/sys/arch/amd64/conf/kern.ldscript.kaslr
P src/sys/arch/amd64/stand/prekern/Makefile
P src/sys/arch/amd64/stand/prekern/console.c
P src/sys/arch/amd64/stand/prekern/elf.c
P src/sys/arch/amd64/stand/prekern/locore.S
P src/sys/arch/amd64/stand/prekern/mm.c
P src/sys/arch/amd64/stand/prekern/prekern.c
P src/sys/arch/amd64/stand/prekern/prekern.h
P src/sys/arch/amd64/stand/prekern/redef.h
P src/sys/arch/arm/sunxi/sunxi_nand.c
P src/sys/arch/i386/stand/boot/boot2.c
P src/sys/arch/sparc64/include/vmparam.h
P src/sys/dev/audio.c
P src/sys/dev/flash/files.flash
P src/sys/dev/raidframe/rf_netbsdkintf.c
P src/sys/dev/raidframe/rf_reconmap.c
P src/sys/kern/kern_subr.c
P src/sys/kern/subr_pool.c
P src/sys/modules/nand/Makefile
P src/sys/opencrypto/cryptodev.c
P src/sys/ufs/chfs/chfs_vfsops.c
P src/sys/uvm/uvm_page.h

Updating xsrc tree:


Killing core files:



Updating release-6 src tree (netbsd-6):

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



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

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



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

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




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  54679897 Nov 15 03:12 ls-lRA.gz

Re: Possible regression in wm(4)?

[Kengo NAKAHARA]

Hi,

On 2017/11/14 21:53, Bert Kiers wrote:
> On Tue, Nov 14, 2017 at 08:07:46PM +0900, Kengo NAKAHARA wrote:
>> I'm sorry I cannot solve it...
>> Hmm, now I think this problem may relate to MSI/MSI-X interrupts
>> setting about ioapic. If it is not a problem, could you try the
>> following patch?
>> I believe this patch let wm(4) do the same behavior as NetBSD-7,
>> that is, wm(4) uses INTx interrupt instead of MSI/MSI-X interrupt.
>>
>> 
>> --- a/sys/dev/pci/if_wm.c
>> +++ b/sys/dev/pci/if_wm.c
>> @@ -174,10 +174,10 @@ intwm_debug = WM_DEBUG_TX | WM_DEBUG_RX | 
>> WM_DEBUG_LINK | WM_DEBUG_GMII
>>  #define WM_MAX_NINTR(WM_MAX_NQUEUEINTR + 1)
>>  
>>  #ifndef WM_DISABLE_MSI
>> -#define WM_DISABLE_MSI 0
>> +#define WM_DISABLE_MSI 1
>>  #endif
>>  #ifndef WM_DISABLE_MSIX
>> -#define WM_DISABLE_MSIX 0
>> +#define WM_DISABLE_MSIX 1
>>  #endif
>>  
>>  int wm_disable_msi = WM_DISABLE_MSI;
>> 
> 
> That still does not work.  The NIC probes as
> 
> yvresse# grep ^wm1 dmesg.netbsd8wmfixC
> wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
> wm1: interrupting at ioapic1 pin 16
> wm1: PCI-Express bus
> wm1: 16384 words (16 address bits) SPI EEPROM, version 1.43, Image Unique ID 
> e606
> wm1: Ethernet address 00:30:48:9e:a9:2f
> wm1: Copper
> wm1: 0x74440
> 
> But still no traffic.

Oh, the dmesg is as expected, but the behavior is not.
Hmm, sorry, could you give me the following information?
+ "intrctl list" result on NetBSD-8
  - before trying traffic and after it
- full dmesg on NetBSD-8 which boot with "-xv" option
- full dmesg on NetBSD-7 (which boot -xv if you can)
- "acpidump -dt" result

> I have two wm(4) cards with different chips.  I'll put them in the
> machine tomorrow and see what happens.

I expect it will work.

> Btw, this is the only device that tries to use MSI(X) in this box.
> 
> Two devices use ioapic pin 16:
> 
> wm1: interrupting at ioapic1 pin 16
> uhci0: interrupting at ioapic0 pin 16
> 
> and systat vmstat shows between 0 and 10 interrupts per second there on
> that pin

Yes, they use pin 16, but wm1 use ioapic1 whereas uhci0 use ioapic0.
Which ioapic's pin 16 interrupts occur?


Thanks,

-- 
//
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA 

Re: Compile failure in nand.c

[Jared McNeill]

Hi Chavdar --

This define is generated by config in locators.h (kernel obj directory). 
Make sure you have sys/dev/flash/files.flash rev 1.4 and that you've run 
config on your kernel since updating.


Cheers,
Jared

On Tue, 14 Nov 2017, Chavdar Ivanov wrote:


Hi,

I am getting:
...
#   compile  nand/nand.o
/home/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -O2 -g   -std=gnu99
 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-
compare  -Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unus
ed-parameter -Wno-sign-compare -Werror   -ffreestanding
-fno-strict-aliasing -Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse
-mno-avx -msoft-fl
oat -mcmodel=kernel -fno-omit-frame-pointer
-I/home/sysbuild/src/common/include
--sysroot=/home/sysbuild/amd64/destdir -I/home/sysbuild/src/commo
n/include  -nostdinc -I. -I/home/sysbuild/src/sys/modules/nand
-isystem /home/sysbuild/src/sys -isystem /home/sysbuild/src/sys/arch
-isystem /home
/sysbuild/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE
-DSYSCTL_INCLUDE_DESCR -c/home/sysbuild/src/sys/dev/nand/nand.c
/home/sysbuild/src/sys/dev/nand/nand.c: In function 'nand_search':
/home/sysbuild/src/sys/dev/nand/nand.c:191:17: error:
'FLASHBUSCF_DYNAMIC' undeclared (first use in this function)
 if (cf->cf_loc[FLASHBUSCF_DYNAMIC] != 0)
^
/home/sysbuild/src/sys/dev/nand/nand.c:191:17: note: each undeclared
identifier is reported only once for each function it appears in
*** [nand.o] Error code 1
...

in my last few builds; I couldn't locate the missing symbol elsewhere.

I am building now with the offending line #if-ed out.

Chavdar Ivanov

--

Compile failure in nand.c

[Chavdar Ivanov]

Hi,

I am getting:
...
#   compile  nand/nand.o
/home/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -O2 -g   -std=gnu99
  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-
compare  -Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unus
ed-parameter -Wno-sign-compare -Werror   -ffreestanding
-fno-strict-aliasing -Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse
-mno-avx -msoft-fl
oat -mcmodel=kernel -fno-omit-frame-pointer
-I/home/sysbuild/src/common/include
--sysroot=/home/sysbuild/amd64/destdir -I/home/sysbuild/src/commo
n/include  -nostdinc -I. -I/home/sysbuild/src/sys/modules/nand
-isystem /home/sysbuild/src/sys -isystem /home/sysbuild/src/sys/arch
-isystem /home
/sysbuild/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE
-DSYSCTL_INCLUDE_DESCR -c/home/sysbuild/src/sys/dev/nand/nand.c
/home/sysbuild/src/sys/dev/nand/nand.c: In function 'nand_search':
/home/sysbuild/src/sys/dev/nand/nand.c:191:17: error:
'FLASHBUSCF_DYNAMIC' undeclared (first use in this function)
  if (cf->cf_loc[FLASHBUSCF_DYNAMIC] != 0)
 ^
/home/sysbuild/src/sys/dev/nand/nand.c:191:17: note: each undeclared
identifier is reported only once for each function it appears in
*** [nand.o] Error code 1
...

in my last few builds; I couldn't locate the missing symbol elsewhere.

I am building now with the offending line #if-ed out.

Chavdar Ivanov

-- 

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

On 2017/11/14 23:09, Martin Husemann wrote:

On Tue, Nov 14, 2017 at 01:58:54PM +, NetBSD Test Fixture wrote:

This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:


This was fallout fromt the gcc import, it should be fixed now.


All these tests are passed on amd64 built from -current as of few hours ago.

rin

Re: Automated report: NetBSD-current/i386 test failure

[Martin Husemann]

On Tue, Nov 14, 2017 at 01:58:54PM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
> 
> The newly failing test cases are:

This was fallout fromt the gcc import, it should be fixed now.

Martin

Automated report: NetBSD-current/i386 test failure

[NetBSD Test Fixture]

This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:

share/mk/t_lib:defaults__build_and_install
share/mk/t_prog:defaults__build_and_install
share/mk/t_prog:without_man__build_and_install
share/mk/t_test:one_c
share/mk/t_test:one_cxx
usr.bin/c++/t_cxxruntime:cxxruntime
usr.bin/c++/t_cxxruntime:cxxruntime_pic
usr.bin/c++/t_cxxruntime:cxxruntime_pie
usr.bin/c++/t_hello:hello
usr.bin/c++/t_hello:hello_pic
usr.bin/c++/t_hello:hello_pie
usr.bin/c++/t_hello:hello_profile
usr.bin/c++/t_static_destructor:static_destructor
usr.bin/c++/t_static_destructor:static_destructor_pic
usr.bin/c++/t_static_destructor:static_destructor_pie
usr.bin/cc/t_hello:hello
usr.bin/cc/t_hello:hello_pic
usr.bin/cc/t_hello:hello_pie
usr.bin/cc/t_hello:hello_profile
usr.bin/ld/t_script:order_default
usr.bin/ld/t_script:order_merge
usr.bin/ld/t_script:order_reorder
usr.bin/ld/t_script:order_sort
usr.bin/ld/t_section:orphan
usr.bin/ld/t_section:startstop
usr.bin/nbperf/t_nbperf:bdz
usr.bin/nbperf/t_nbperf:chm
usr.bin/nbperf/t_nbperf:chm3
usr.bin/pkill/t_pgrep:pr50934

The above tests failed in each of the last 3 test runs, and passed in
at least 27 consecutive runs before that.

Between the last successful test and the failed test, a total of 827
revisions were committed, by the following developers:

jmcneill
martin
mrg
nakayama
wiz

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2017.11.html#2017.11.13.15.01.16

Re: Possible regression in wm(4)?

[Bert Kiers]

On Tue, Nov 14, 2017 at 08:07:46PM +0900, Kengo NAKAHARA wrote:
> Hi,

Hi,

> I'm sorry I cannot solve it...
> Hmm, now I think this problem may relate to MSI/MSI-X interrupts
> setting about ioapic. If it is not a problem, could you try the
> following patch?
> I believe this patch let wm(4) do the same behavior as NetBSD-7,
> that is, wm(4) uses INTx interrupt instead of MSI/MSI-X interrupt.
> 
> 
> --- a/sys/dev/pci/if_wm.c
> +++ b/sys/dev/pci/if_wm.c
> @@ -174,10 +174,10 @@ int wm_debug = WM_DEBUG_TX | WM_DEBUG_RX | 
> WM_DEBUG_LINK | WM_DEBUG_GMII
>  #define WM_MAX_NINTR (WM_MAX_NQUEUEINTR + 1)
>  
>  #ifndef WM_DISABLE_MSI
> -#define  WM_DISABLE_MSI 0
> +#define  WM_DISABLE_MSI 1
>  #endif
>  #ifndef WM_DISABLE_MSIX
> -#define  WM_DISABLE_MSIX 0
> +#define  WM_DISABLE_MSIX 1
>  #endif
>  
>  int wm_disable_msi = WM_DISABLE_MSI;
> 

That still does not work.  The NIC probes as

yvresse# grep ^wm1 dmesg.netbsd8wmfixC
wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
wm1: interrupting at ioapic1 pin 16
wm1: PCI-Express bus
wm1: 16384 words (16 address bits) SPI EEPROM, version 1.43, Image Unique ID 
e606
wm1: Ethernet address 00:30:48:9e:a9:2f
wm1: Copper
wm1: 0x74440

But still no traffic.

I have two wm(4) cards with different chips.  I'll put them in the
machine tomorrow and see what happens.

Btw, this is the only device that tries to use MSI(X) in this box.

Two devices use ioapic pin 16:

wm1: interrupting at ioapic1 pin 16
uhci0: interrupting at ioapic0 pin 16

and systat vmstat shows between 0 and 10 interrupts per second there on
that pin

Grtnx,
-- 
B*E*R*T

Re: Possible regression in wm(4)?

[Kengo NAKAHARA]

Hi,

On 2017/11/14 19:33, Bert Kiers wrote:
> On Tue, Nov 14, 2017 at 12:34:40PM +0900, Kengo NAKAHARA wrote:
> 
> I am sorry to have to say they both do not fix the problem.
> 
>> == (A) ==
>> --- a/sys/dev/pci/if_wm.c
>> +++ b/sys/dev/pci/if_wm.c
>> @@ -4883,8 +4883,8 @@ wm_adjust_qnum(struct wm_softc *sc, int nvectors)
>>  hw_nrxqueues = 4;
>>  break;
>>  case WM_T_82576:
>> -hw_ntxqueues = 16;
>> -hw_nrxqueues = 16;
>> +hw_ntxqueues = 1;
>> +hw_nrxqueues = 1;
>>  break;
>>  case WM_T_82580:
>>  case WM_T_I350:
>> == (A) ==
> 
> With this patch, it probes as
> 
> yvresse# cat dmesg.netbsd8wmfixA|grep wm1
> wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
> wm1: for TX and RX interrupting at msix1 vec 0 affinity to 1
> wm1: for LINK interrupting at msix1 vec 1
> wm1: PCI-Express bus
> wm1: 16384 words (16 address bits) SPI EEPROM, version 1.43, Image Unique ID 
> e606
> wm1: Ethernet address 00:30:48:9e:a9:2f
> wm1: Copper
> wm1: 0x74440
> igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1
> 
> but there is no incoming traffic
>  
>> == (B) ==
>> --- a/sys/dev/pci/if_wm.c
>> +++ b/sys/dev/pci/if_wm.c
>> @@ -177,7 +177,7 @@ int  wm_debug = WM_DEBUG_TX | WM_DEBUG_RX | 
>> WM_DEBUG_LINK | WM_DEBUG_GMII
>>  #define WM_DISABLE_MSI 0
>>  #endif
>>  #ifndef WM_DISABLE_MSIX
>> -#define WM_DISABLE_MSIX 0
>> +#define WM_DISABLE_MSIX 1
>>  #endif
>>  
>>  int wm_disable_msi = WM_DISABLE_MSI;
>> == (B) ==
> 
> With this one,
> 
> yvresse# cat dmesg.netbsd8wmfixB|grep wm1
> wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
> wm1: interrupting at msi1 vec 0
> wm1: PCI-Express bus
> wm1: 16384 words (16 address bits) SPI EEPROM, version 1.43, Image Unique ID 
> e606
> wm1: Ethernet address 00:30:48:9e:a9:2f
> wm1: Copper
> wm1: 0x74440
> igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1
> 
> and also no traffic

I'm sorry I cannot solve it...
Hmm, now I think this problem may relate to MSI/MSI-X interrupts
setting about ioapic. If it is not a problem, could you try the
following patch?
I believe this patch let wm(4) do the same behavior as NetBSD-7,
that is, wm(4) uses INTx interrupt instead of MSI/MSI-X interrupt.


--- a/sys/dev/pci/if_wm.c
+++ b/sys/dev/pci/if_wm.c
@@ -174,10 +174,10 @@ int   wm_debug = WM_DEBUG_TX | WM_DEBUG_RX | 
WM_DEBUG_LINK | WM_DEBUG_GMII
 #define WM_MAX_NINTR   (WM_MAX_NQUEUEINTR + 1)
 
 #ifndef WM_DISABLE_MSI
-#defineWM_DISABLE_MSI 0
+#defineWM_DISABLE_MSI 1
 #endif
 #ifndef WM_DISABLE_MSIX
-#defineWM_DISABLE_MSIX 0
+#defineWM_DISABLE_MSIX 1
 #endif
 
 int wm_disable_msi = WM_DISABLE_MSI;



Thanks,

-- 
//
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA 

Re: Possible regression in wm(4)?

[Bert Kiers]

On Tue, Nov 14, 2017 at 12:34:40PM +0900, Kengo NAKAHARA wrote:
> Hi,

Hi,

I am sorry to have to say they both do not fix the problem.

> == (A) ==
> --- a/sys/dev/pci/if_wm.c
> +++ b/sys/dev/pci/if_wm.c
> @@ -4883,8 +4883,8 @@ wm_adjust_qnum(struct wm_softc *sc, int nvectors)
>   hw_nrxqueues = 4;
>   break;
>   case WM_T_82576:
> - hw_ntxqueues = 16;
> - hw_nrxqueues = 16;
> + hw_ntxqueues = 1;
> + hw_nrxqueues = 1;
>   break;
>   case WM_T_82580:
>   case WM_T_I350:
> == (A) ==

With this patch, it probes as

yvresse# cat dmesg.netbsd8wmfixA|grep wm1
wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
wm1: for TX and RX interrupting at msix1 vec 0 affinity to 1
wm1: for LINK interrupting at msix1 vec 1
wm1: PCI-Express bus
wm1: 16384 words (16 address bits) SPI EEPROM, version 1.43, Image Unique ID 
e606
wm1: Ethernet address 00:30:48:9e:a9:2f
wm1: Copper
wm1: 0x74440
igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1

but there is no incoming traffic
 
> == (B) ==
> --- a/sys/dev/pci/if_wm.c
> +++ b/sys/dev/pci/if_wm.c
> @@ -177,7 +177,7 @@ int   wm_debug = WM_DEBUG_TX | WM_DEBUG_RX | 
> WM_DEBUG_LINK | WM_DEBUG_GMII
>  #define  WM_DISABLE_MSI 0
>  #endif
>  #ifndef WM_DISABLE_MSIX
> -#define  WM_DISABLE_MSIX 0
> +#define  WM_DISABLE_MSIX 1
>  #endif
>  
>  int wm_disable_msi = WM_DISABLE_MSI;
> == (B) ==

With this one,

yvresse# cat dmesg.netbsd8wmfixB|grep wm1
wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
wm1: interrupting at msi1 vec 0
wm1: PCI-Express bus
wm1: 16384 words (16 address bits) SPI EEPROM, version 1.43, Image Unique ID 
e606
wm1: Ethernet address 00:30:48:9e:a9:2f
wm1: Copper
wm1: 0x74440
igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1

and also no traffic

Grtnx,
-- 
B*E*R*T

Re: netbsd 8 (beta) failing to load ixg device

[Masanobu SAITOH]

 Hi, all.

On 2017/11/14 7:01, Jaromír Doleček wrote:

I had a very brief look on the crashing function ixgbe_update_stats_count(). The 
only division there is in the one using adapter->num_queue.

Looking at ixgbe_configure_interrups(), seems that one can happily set it to 0 
if number of MSI vectors is 1, as is the case according to your dmesg.

SAITOH Masanobu, could you please have a closer look? I wonder if this could 
have been introduced around rev. 1.96/1.97/1.98 of dev/pci/ixgbe/ixgbe.c, 
that's when the code related to this changed.


 I could reproduce the problem. Yes, it's my fault.

 I sent a new pullup request:

http://releng.netbsd.org/cgi-bin/req-8.cgi?show=361

It's little hard to fix that problem with small patch. I'm going to
send a jumbo patch for ixg(4) to fix a lot of bugs and it'll fix this
problemcleanly.

 Sorry and thank you all.



Jaromir

2017-11-13 16:03 GMT+01:00 Derrick Lobo >:
 >
 > HI Thor
 >
 > I have attached the logs..  I am able to use the server in 7.99 but cannot
 > upgrade to 8.0 beta. Theres a kernel panic when the driver is loaded.. its
 > not like the bootup progresses and marks the driver as unconfigured.
 >
 > -Original Message-
 > From: Thor Lancelot Simon [mailto:t...@panix.com ]
 > Sent: Sunday, November 12, 2017 10:30 PM
 > To: Derrick Lobo
 > Cc: port-am...@netbsd.org ; current-users@netbsd.org 

 > Subject: Re: netbsd 8 (beta) failing to load ixg device
 >
 > On Thu, Nov 09, 2017 at 09:15:53AM -0500, Derrick Lobo wrote:
 > > The daily beta version of nebtsd 8 does not support ixg 5gb NIC's, the
 > > support was enabled in 7.99
 >
 > That doesn't make sense - if it's in 7.anything, it's in 8.  When we cut
 > the 8 branch, we move the version number on HEAD to 8.99.
 >
 > Thor



--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)