On Mon, Jan 23, 2017 at 08:33:34AM +, Chavdar Ivanov wrote:
> Hi,
>
> The last few days I am getting repeated panics on amd64 -current running
> under VirtualBox (latest 5.1.14 version at the moment) as follows:
> ---
> panic: auidui_init_ringbuffer: blksize=0
There were some changes in this
Hi,
The last few days I am getting repeated panics on amd64 -current running
under VirtualBox (latest 5.1.14 version at the moment) as follows:
---
panic: auidui_init_ringbuffer: blksize=0
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 80115455 cs 8 rflags 246 cr2 0 ileve
On Tuesday 2017-01-24 15:59 +1100, Geoff Wing output:
:starting -current on amd64, I get a crash during (presumably) /etc/rc.d/npf
Panics from previous message were when I had
pseudo-device npf
in my kernel config. Removing that I get panics at the same
place (npfctl) as
mutex_v
Hi,
starting -current on amd64, I get a crash during (presumably) /etc/rc.d/npf
I have some dynamic tables in /etc/npf.conf, e.g.
table type tree dynamic
though maybe not relevant.
Panics are copied from phone video. I can't get a crash dump, nor
does my computer keep system message log
On Tue, Jan 24, 2017 at 12:53 AM, Tom Ivar Helbekkmo
wrote:
> Ryota Ozaki writes:
>
>> The latest pfil.c (v1.34) should fix the panic. Could you try it?
>
> I'll give it a go tonight, and report back.
Thanks.
>
> Meanwhile, do you think this ongoing MPSAFE work may have some unwanted
> conseque
Updating src tree:
P src/external/bsd/dhcpcd/dist/dhcpcd-run-hooks.8.in
P src/external/bsd/dhcpcd/dist/dhcpcd.8.in
P src/external/bsd/dhcpcd/dist/dhcpcd.conf.5.in
P src/share/man/man9/disk.9
P src/share/man/man9/vnode.9
P src/sys/arch/amd64/conf/XEN3_DOM0
P src/sys/arch/amd64/conf/XEN3_DOMU
P src/
Spam detection software, running on the system "vbsd.hertenberger.bayern",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
postmaster for details.
Content preview:
In article <20170123211552.562439cc@bsd64.localdomain>,
Stefan Hertenberger wrote:
>
>Content preview: hello, latest current panics when my usb wireless device is
> attached. i made a screenshot of the stack trace =>
>https://www.alarum.de/netbsd/20170123_205754.jpg
> urtwn0 at uhub4 port 4
Spam detection software, running on the system "vbsd.hertenberger.bayern",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
postmaster for details.
Content preview:
In article ,
<6b...@6bone.informatik.uni-leipzig.de> wrote:
>Hello,
>
>on NetBSD 7.1_RC1 (and earlier) I can create a kernel crash as follows:
>
>ifconfig ixg0 ip4csum tcp4csum udp4csum tcp6csum udp6csum ip4csum-tx
>ip4csum-rx tcp4csum-tx tcp4csum-rx udp4csum-tx udp4csum-rx tcp6csum-tx
>tcp6csum-r
Tom Ivar Helbekkmo writes:
[ ... ]
> Oh, and it's the client that hangs; the server seems to be just fine,
> and a reboot of the client makes NFS reads behave normally again. On
> the server, the output file got created, but is zero bytes. The error
> logged on the client when it gets stuck is t
Ryota Ozaki writes:
> The latest pfil.c (v1.34) should fix the panic. Could you try it?
I'll give it a go tonight, and report back.
Meanwhile, do you think this ongoing MPSAFE work may have some unwanted
consequences for NFS? There's a problem that's been around for at least
a couple of months
Hello,
on NetBSD 7.1_RC1 (and earlier) I can create a kernel crash as follows:
ifconfig ixg0 ip4csum tcp4csum udp4csum tcp6csum udp6csum ip4csum-tx ip4csum-rx
tcp4csum-tx tcp4csum-rx udp4csum-tx udp4csum-rx tcp6csum-tx tcp6csum-rx
udp6csum-tx udp6csum-rx tso4 tso6
ifconfig vlan850 create
ifcon
13 matches
Mail list logo
