Re: xhci panic

On 01/20/17 10:56, Patrick Welche wrote: Just tried a this morning's kernel on amd64 (was looking forward to the new xhci.c :-) ), and (laptop so no serial console): xhci0 at pci4 dev 0 function 0: NEC USB3 Houst Controller (rev. 0x04) xhci0: interrupting at msi2 vec 0 uvm_fault(0x..., 0x0, 1)

Re: wm devices don't work under current amd64

Christos Zoulas writes: > I don't know about that. It is pretty stable with me... I guess I worded that a bit clumsily. :) I meant that there seem to be a number of rather deep changes going on, accompanied by more reports of crashes than I'm used to seeing on

daily CVS update output

Updating src tree: P src/external/gpl2/xcvs/dist/doc/cvs.1 P src/external/gpl2/xcvs/dist/doc/cvs.texinfo P src/lib/libm/shlib_version P src/libexec/httpd/bozohttpd.8 P src/sys/dev/drm/vbox_drv.c P src/sys/dev/gpio/gpiolock.c P src/sys/dev/gpio/gpiopwm.c P src/sys/dev/gpio/gpiosim.c P

Re: wm devices don't work under current amd64

In article , Tom Ivar Helbekkmo wrote: >Christos Zoulas writes: > >> Perhaps we want a lock? > >OK, that makes sense - and might explain why my problem returned. >(Especially as it's not quite the same as

Re: i386 GENERIC_PAE panics (i915drmkms related?)

I see similar behavior on NetBSD/i386-7.1_RC1 except instead of panicking, it just hangs. If console is VGA, one can break into DDB with Ctrl-Alt-Esc. If console is serial port, sending BREAK does not drop into DDB. Partial dmesg captured from serial console: NetBSD 7.1_RC1 (GENERIC_PAE) #0:

Re: wm devices don't work under current amd64

Christos Zoulas writes: > Perhaps we want a lock? OK, that makes sense - and might explain why my problem returned. (Especially as it's not quite the same as before, and the differences may well be locking related.) But should I pursue this on 7.99.39, or should I upgrade

Re: wm devices don't work under current amd64

In article , Tom Ivar Helbekkmo wrote: >Tom Ivar Helbekkmo writes: > >> Masanobu SAITOH writes: >> >>> Please test the latest -current. knakahara found a problem: >> >> That worked fine!

Automated report: NetBSD-current/i386 test failure

This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/npf/t_npf:npf_nbuf net/npf/t_npf:npf_state The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The

Re: wm devices don't work under current amd64

Tom Ivar Helbekkmo writes: > However, another amd64 system that doesn't use VLANs, and is an NFS > client, is unable to write to NFS file systems if it runs a kernel > with the patch applied. Don't mind me - after a little while, the problem returned on this system, even

Re: wm devices don't work under current amd64

Tom Ivar Helbekkmo writes: > Masanobu SAITOH writes: > >> Please test the latest -current. knakahara found a problem: > > That worked fine! No longer any need for the tcpdump hack. :) > > (I didn't get the latest -current; I just added those patches

Re: xhci panic

On 01/20/17 14:35, Patrick Welche wrote: On Fri, Jan 20, 2017 at 02:10:24PM +, Nick Hudson wrote: On 01/20/17 11:50, Patrick Welche wrote: On Fri, Jan 20, 2017 at 11:08:14AM +, Nick Hudson wrote: On 01/20/17 10:56, Patrick Welche wrote: Just tried a this morning's kernel on amd64

Re: i386 GENERIC_PAE panics (i915drmkms related?)

Booting GENERIC_PAE with -c (userconf) and disabling "i915drmkms": NetBSD 7.99.59 (GENERIC_PAE) #1: Tue Jan 17 16:17:00 CST 2017 sy...@dpe2850b.technoskunk.fur:/d0/build/current/obj/i386/sys/arch/i386/compile/GENERIC_PAE total memory = 8025 MB avail memory = 7864 MB WARNING: module

Re: xhci panic

On 01/20/17 11:50, Patrick Welche wrote: On Fri, Jan 20, 2017 at 11:08:14AM +, Nick Hudson wrote: On 01/20/17 10:56, Patrick Welche wrote: Just tried a this morning's kernel on amd64 (was looking forward to the new xhci.c :-) ), and (laptop so no serial console): xhci0 at pci4 dev 0

Re: xhci panic

On Fri, Jan 20, 2017 at 03:52:57PM +, Nick Hudson wrote: > On 01/20/17 14:35, Patrick Welche wrote: > >On Fri, Jan 20, 2017 at 02:10:24PM +, Nick Hudson wrote: > >>On 01/20/17 11:50, Patrick Welche wrote: > >>>On Fri, Jan 20, 2017 at 11:08:14AM +, Nick Hudson wrote: > On 01/20/17

Re: xhci panic

On Fri, Jan 20, 2017 at 02:10:24PM +, Nick Hudson wrote: > On 01/20/17 11:50, Patrick Welche wrote: > > On Fri, Jan 20, 2017 at 11:08:14AM +, Nick Hudson wrote: > > > On 01/20/17 10:56, Patrick Welche wrote: > > > > Just tried a this morning's kernel on amd64 (was looking forward to the >

Automated report: NetBSD-current/i386 build success

The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2017.01.20.09.45.13 skrll src/sys/kern/vfs_bio.c,v 1.269 Log files can be found at:

Re: xhci panic

On Fri, Jan 20, 2017 at 11:08:14AM +, Nick Hudson wrote: > On 01/20/17 10:56, Patrick Welche wrote: > >Just tried a this morning's kernel on amd64 (was looking forward to the > >new xhci.c :-) ), and (laptop so no serial console): > > > >xhci0 at pci4 dev 0 function 0: NEC USB3 Houst

Re: xhci panic

On 01/20/17 10:56, Patrick Welche wrote: Just tried a this morning's kernel on amd64 (was looking forward to the new xhci.c :-) ), and (laptop so no serial console): xhci0 at pci4 dev 0 function 0: NEC USB3 Houst Controller (rev. 0x04) xhci0: interrupting at msi2 vec 0 uvm_fault(0x..., 0x0, 1)

xhci panic

Just tried a this morning's kernel on amd64 (was looking forward to the new xhci.c :-) ), and (laptop so no serial console): xhci0 at pci4 dev 0 function 0: NEC USB3 Houst Controller (rev. 0x04) xhci0: interrupting at msi2 vec 0 uvm_fault(0x..., 0x0, 1) -> e Stopped in pid 0.1 (system) at

Automated report: NetBSD-current/i386 build failure

This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2017.01.20.08.16.31. An extract from the build.sh output follows: --- vfs_cwd.po --- # compile