Panic on RPI boot with revision 335282

2018-06-17 Thread Tom Vijlbrief
I get an:

panic: Assertion zone->uz_flags & UMA_ZONE_PCPU failed at
/media/swan/src.svn/sys/vm/uma_core.c:2239

A one month old kernel runs fine, uma_core.c was edited at that location 9
days ago
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]

2017-04-20 Thread Tom Vijlbrief
Op wo 19 apr. 2017 09:11 schreef Tom Vijlbrief <tvijlbr...@gmail.com>:

> I'm currently rebuilding world and kernel on a just completed SVN checkout.
>
> Note that the normal sendmail daemon which listens for incoming traffic
> does NOT loop.
>
> The sendmail instance which tries local delivery (echo Hi | mail root) or
> the msp_queue instance is looping.
>
> It might be an arm64 specific issue, but a few weeks ago this was not an
> issue.
>

I just completed a full rebuild on the Pine64 and I cannot reproduce the
problem, so there is probably no issue anymore...

(Except the spurious interrupts issue)


> Op di 18 apr. 2017 om 21:15 schreef Mark Millard <mar...@dsl-only.net>:
>
>> Ronald Klop ronald-lists at klop.ws wrote on Tue Apr 18 09:59:50 UTC
>> 2017:
>>
>> > there is a thread ono this list about a problem in syslogd which made
>> > syslog-clients (like sendmail busy-looping on logging.
>> > That might be related to this. (it is fixed in the source already, so
>> > upgrading again might help)
>> > See the thread with subject like 'Re: r316958: booting a server takes
>> >10
>> > minutes!'
>> >
>> > Regards,
>> >
>> > Ronald.
>>
>>
>> Yes. But Tom V.'s report is for -r317039, which is after the reported
>> fixes as far as I can tell. Something besides syslogd might also cause
>> problems?
>>
>> In my nearly-default -r317015 ardm64 context [as a VirtualBox guest]
>> I've not seen the problem, where I did before. (The only reason sendmail
>> runs in my context is for the messages FreeBSD sends to it own local
>> accounts. I do not otherwise use mail in this context.)
>>
>> Tom V.'s report vs. others finding lack of a problem suggests that the
>> coverage of the fixes is incomplete somehow but useful. I happen to not
>> be doing whatever causes the problem to appear. I've no clue what might
>> be different or unusual in Tom V.'s context.
>>
>> There is also the possibility that Tom V.'s report is a fully independent
>> issue. But such does not seem all that likely on the initial information.
>>
>>
>> > On 2017-Apr-17, at 7:57 AM, Mark Millard 
>> wrote:
>> >
>> >> Just an FYI of a more recent report of runaway sendmail on a
>> >> more recent system version ( -r317039 ):
>> >>
>> >> Begin forwarded message:
>> >>
>> >>> From: Tom Vijlbrief 
>> >>> Subject: Sendmail eats CPU on r317039
>> >>> Date: April 17, 2017 at 3:39:37 AM PDT
>> >>> To: "freebsd-current at freebsd.org" ,
>> freebsd-arm 
>> >>>
>> >>> On a recent kernel sendmail is constantly consuming CPU.
>> >>>
>> >>> truss -p PID
>> >>>
>> >>> shows:
>> >>>
>> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
>> 'No
>> >>> buffer space available'
>> >>> nanosleep({ 0.01000 }) = 0 (0x0)
>> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
>> 'No
>> >>> buffer space available'
>> >>> nanosleep({ 0.01000 })
>> >>> ...
>> >>>
>> >>> This is on an arm64 system
>> >>
>> >> Analysis of Tom V.'s context for this may be required.
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> ___
>> freebsd-...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]

2017-04-19 Thread Tom Vijlbrief
I'm currently rebuilding world and kernel on a just completed SVN checkout.

Note that the normal sendmail daemon which listens for incoming traffic
does NOT loop.

The sendmail instance which tries local delivery (echo Hi | mail root) or
the msp_queue instance is looping.

It might be an arm64 specific issue, but a few weeks ago this was not an
issue.

Op di 18 apr. 2017 om 21:15 schreef Mark Millard <mar...@dsl-only.net>:

> Ronald Klop ronald-lists at klop.ws wrote on Tue Apr 18 09:59:50 UTC 2017:
>
> > there is a thread ono this list about a problem in syslogd which made
> > syslog-clients (like sendmail busy-looping on logging.
> > That might be related to this. (it is fixed in the source already, so
> > upgrading again might help)
> > See the thread with subject like 'Re: r316958: booting a server takes >10
> > minutes!'
> >
> > Regards,
> >
> > Ronald.
>
>
> Yes. But Tom V.'s report is for -r317039, which is after the reported
> fixes as far as I can tell. Something besides syslogd might also cause
> problems?
>
> In my nearly-default -r317015 ardm64 context [as a VirtualBox guest]
> I've not seen the problem, where I did before. (The only reason sendmail
> runs in my context is for the messages FreeBSD sends to it own local
> accounts. I do not otherwise use mail in this context.)
>
> Tom V.'s report vs. others finding lack of a problem suggests that the
> coverage of the fixes is incomplete somehow but useful. I happen to not
> be doing whatever causes the problem to appear. I've no clue what might
> be different or unusual in Tom V.'s context.
>
> There is also the possibility that Tom V.'s report is a fully independent
> issue. But such does not seem all that likely on the initial information.
>
>
> > On 2017-Apr-17, at 7:57 AM, Mark Millard  wrote:
> >
> >> Just an FYI of a more recent report of runaway sendmail on a
> >> more recent system version ( -r317039 ):
> >>
> >> Begin forwarded message:
> >>
> >>> From: Tom Vijlbrief 
> >>> Subject: Sendmail eats CPU on r317039
> >>> Date: April 17, 2017 at 3:39:37 AM PDT
> >>> To: "freebsd-current at freebsd.org" ,
> freebsd-arm 
> >>>
> >>> On a recent kernel sendmail is constantly consuming CPU.
> >>>
> >>> truss -p PID
> >>>
> >>> shows:
> >>>
> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
> 'No
> >>> buffer space available'
> >>> nanosleep({ 0.01000 }) = 0 (0x0)
> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
> 'No
> >>> buffer space available'
> >>> nanosleep({ 0.01000 })
> >>> ...
> >>>
> >>> This is on an arm64 system
> >>
> >> Analysis of Tom V.'s context for this may be required.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Sendmail eats CPU on r317039

2017-04-17 Thread Tom Vijlbrief
On a recent kernel sendmail is constantly consuming CPU.

truss -p PID

shows:

sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
buffer space available'
nanosleep({ 0.01000 }) = 0 (0x0)
sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
buffer space available'
nanosleep({ 0.01000 })
...

This is on an arm64 system
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Installworld fails with TMPDIR pointing to NFS mounted directory

2016-01-12 Thread Tom Vijlbrief
Op di 12 jan. 2016 om 18:08 schreef NGie Cooper <yaneurab...@gmail.com>:

>
> > On Jan 12, 2016, at 08:42, Tom Vijlbrief <tvijlbr...@gmail.com> wrote:
> >
> > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not
> > think it is raspberry related or even 11-CURRENT related.
> >
> > export TMPDIR=/media/usbdisk/tmp
> >
> > make installword MAKEOBJDIRPREFIX=/media/swan/obj
>
> Hi Tom,
> MAKEOBJDIRPREFIX should always be set via the environment, not the
> command line, e.g.
>
> export MAKEOBJDIRPREFIX=/media/swan/obj
> make installworld
>
> Cheers,
> -NGie


I think I actually did the export and not as I typed in my mail,
the export is in my shell history :-)

I also added:

rpc_lockd_enable="YES"

to my /etc/rc.conf and rebooted (rpc.lockd is now running) as Bryan
suggested, but I don't think that it is needed if the only client accessing
the NFS tmp dir is the local client?

[root@rpibsd /media/swan/src]# env | grep swan
TMPDIR=/media/swan/tmp
PWD=/media/swan/src
MAKEOBJDIRPREFIX=/media/swan/obj

make installworld DESTDIR=/d/root11

Same result:

===> etc/sendmail (install)
cd /media/swan/src/etc/../share/man; make makedb
makewhatis /d/root11/usr/share/man
makewhatis /d/root11/usr/share/openssl/man
rm: /media/swan/tmp/install.sy3BjziY/locale/en_US.UTF-8: Directory not empty
rm: /media/swan/tmp/install.sy3BjziY/locale: Directory not empty
rm: /media/swan/tmp/install.sy3BjziY: Directory not empty
*** Error code 1

Stop.
make[1]: stopped in /media/swan/src
*** Error code 1

Stop.
make: stopped in /media/swan/src
[root@rpibsd /media/swan/src]#
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Installworld fails with TMPDIR pointing to NFS mounted directory

2016-01-12 Thread Tom Vijlbrief
https://lists.freebsd.org/pipermail/freebsd-current/2010-September/019820.html
Op 12 jan. 2016 20:39 schreef "Garrett Cooper" <yaneurab...@gmail.com>:

>
> On Jan 12, 2016, at 11:21, Tom Vijlbrief <tvijlbr...@gmail.com> wrote:
>
>
> Op di 12 jan. 2016 om 18:08 schreef NGie Cooper <yaneurab...@gmail.com>:
>
>>
>> > On Jan 12, 2016, at 08:42, Tom Vijlbrief <tvijlbr...@gmail.com> wrote:
>> >
>> > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not
>> > think it is raspberry related or even 11-CURRENT related.
>> >
>> > export TMPDIR=/media/usbdisk/tmp
>> >
>> > make installword MAKEOBJDIRPREFIX=/media/swan/obj
>>
>> Hi Tom,
>> MAKEOBJDIRPREFIX should always be set via the environment, not
>> the command line, e.g.
>>
>> export MAKEOBJDIRPREFIX=/media/swan/obj
>> make installworld
>>
>> Cheers,
>> -NGie
>
>
> I think I actually did the export and not as I typed in my mail,
> the export is in my shell history :-)
>
> I also added:
>
> rpc_lockd_enable="YES"
>
> to my /etc/rc.conf and rebooted (rpc.lockd is now running) as Bryan
> suggested, but I don't think that it is needed if the only client accessing
> the NFS tmp dir is the local client?
>
> [root@rpibsd /media/swan/src]# env | grep swan
> TMPDIR=/media/swan/tmp
> PWD=/media/swan/src
> MAKEOBJDIRPREFIX=/media/swan/obj
>
> make installworld DESTDIR=/d/root11
>
> Same result:
>
> ===> etc/sendmail (install)
> cd /media/swan/src/etc/../share/man; make makedb
> makewhatis /d/root11/usr/share/man
> makewhatis /d/root11/usr/share/openssl/man
> rm: /media/swan/tmp/install.sy3BjziY/locale/en_US.UTF-8: Directory not
> empty
> rm: /media/swan/tmp/install.sy3BjziY/locale: Directory not empty
> rm: /media/swan/tmp/install.sy3BjziY: Directory not empty
> *** Error code 1
>
> Stop.
> make[1]: stopped in /media/swan/src
> *** Error code 1
>
> Stop.
> make: stopped in /media/swan/src
> [root@rpibsd /media/swan/src]#
>
>
> The NFS "directory not empty" issue has been a common annoyance for me for
> several years. It's not just you... It deserves a bug though.
> Thanks!
> -NGie
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Installworld fails with TMPDIR pointing to NFS mounted directory

2016-01-12 Thread Tom Vijlbrief
If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not
think it is raspberry related or even 11-CURRENT related.

export TMPDIR=/media/usbdisk/tmp

make installword MAKEOBJDIRPREFIX=/media/swan/obj

Works as expected but fails cleaning up when TMPDIR points to an NFS
mounted directory:

export TMPDIR=/media/swan/tmp

The NFS server exports /media/swan which has a src/ obj/ and tmp/
subdirectory.
src/ has the sources, obj/ is filled correctly by makeworld.
The tmp dir has the correct permissions. The installworld runs till the
end, except for the last cleanup action which fails:

===> etc/sendmail (install)
cd /media/swan/src/etc/../share/man; make makedb
makewhatis /d/root11/usr/share/man
makewhatis /d/root11/usr/share/openssl/man
rm: /media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8: Directory not empty
rm: /media/swan/tmp/install.xrgbPMy8/locale: Directory not empty
rm: /media/swan/tmp/install.xrgbPMy8: Directory not empty
*** Error code 1

Stop.
make[1]: stopped in /media/swan/src
*** Error code 1

Stop.
make: stopped in /media/swan/src

On some runs just a single error message that complains about:
/media/swan/tmp/install.xyz
not being empty, but an "ls" shows no files and an "rmdir /media/swan/tmp/
install.xyz" succeeds!
In the example above  "/media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8"
IS empty!

It is as if a removed file remains visible for the client for a while.

The NFS server is running Ubuntu 15.10, NFSv3 is used, no other clients
access the NFS tmp directory,
no error messages on the client or server dmesg.

/etc/exports on the server:

/export/all/bsd
192.168.0.0/24(rw,no_root_squash,nohide,insecure,no_subtree_check,async)

The systems have completed many build/install world/kernel cycles using
this NFS mount and are rock solid.

Any hints would be appreciated.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: BETA1 IPv6 crash

2011-08-22 Thread Tom Vijlbrief
2011/8/22 Sergey Kandaurov pluk...@gmail.com:
 On 8 August 2011 22:06, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote:
 2011/8/7 Sergey Kandaurov pluk...@gmail.com:
 On 7 August 2011 17:11, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote:
 I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the
 new installer.

 Major issue I noticed was the missing /home.

 It took me quite some time to get IPv6 working in the guest (a Linux
 configuration issue), but now that it works
 BETA1 panics in about 50% of the boot attempts:

 testbsd dumped core - see /var/crash/vmcore.0

 Sun Aug  7 08:25:28 CEST 2011

 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16
 UTC 2011     r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 i386

 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
 /usr/src/sys/netinet6/mld6.c:1676

 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you 
 are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-marcel-freebsd...
 [..]
 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
 /usr/src/sys/netinet6/mld6.c:1676

 cpuid = 0
 KDB: enter: panic
 Uptime: 28s
 Physical memory: 491 MB
 Dumping 45 MB: 30 14

 #0  doadump (textdump=1) at pcpu.h:244
 244     pcpu.h: No such file or directory.
        in pcpu.h
 (kgdb) #0  doadump (textdump=1) at pcpu.h:244
 #1  0xc0a04965 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:430
 #2  0xc0a04291 in panic (fmt=Variable fmt is not available.
 ) at /usr/src/sys/kern/kern_shutdown.c:595
 #3  0xc09f4a4a in _mtx_lock_sleep (m=0xc35f3a28, tid=3278693824, opts=0,
    file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676)
    at /usr/src/sys/kern/kern_mutex.c:341
 #4  0xc09f4c67 in _mtx_lock_flags (m=0xc35f3a28, opts=0,
    file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676)
    at /usr/src/sys/kern/kern_mutex.c:203
 #5  0xc0bbf007 in mld_set_version (mli=0xc3589a00, version=Variable
 version is not available.
 )
    at /usr/src/sys/netinet6/mld6.c:1676
 #6  0xc0bc0c00 in mld_input (m=0xc3951e00, off=48, icmp6len=24)
    at /usr/src/sys/netinet6/mld6.c:690
 #7  0xc0ba5696 in icmp6_input (mp=0xc3313a54, offp=0xc3313a68, proto=58)
    at /usr/src/sys/netinet6/icmp6.c:654
 #8  0xc0bba23a in ip6_input (m=0xc3951e00)
    at /usr/src/sys/netinet6/ip6_input.c:964
 #9  0xc0ac9b1c in netisr_dispatch_src (proto=10, source=0, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1013
 #10 0xc0ac9da0 in netisr_dispatch (proto=10, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1104
 #11 0xc0abecf1 in ether_demux (ifp=0xc35f3800, m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:936
 #12 0xc0abf1b3 in ether_nh_input (m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:755
 #13 0xc0ac9b1c in netisr_dispatch_src (proto=9, source=0, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1013
 #14 0xc0ac9da0 in netisr_dispatch (proto=9, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1104
 #15 0xc0abe7f5 in ether_input (ifp=0xc35f3800, m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:796
 #16 0xc0672bc9 in lem_handle_rxtx (context=0xc3732000, pending=1)
    at /usr/src/sys/dev/e1000/if_lem.c:3554
 #17 0xc0a468ab in taskqueue_run_locked (queue=0xc359ca80)
    at /usr/src/sys/kern/subr_taskqueue.c:306
 #18 0xc0a47307 in taskqueue_thread_loop (arg=0xc37365ec)
    at /usr/src/sys/kern/subr_taskqueue.c:495
 #19 0xc09d7af8 in fork_exit (callout=0xc0a472a0 taskqueue_thread_loop,
    arg=0xc37365ec, frame=0xc3313d28) at /usr/src/sys/kern/kern_fork.c:941
 #20 0xc0d1d714 in fork_trampoline () at 
 /usr/src/sys/i386/i386/exception.s:275
 (kgdb)


 This is the same as in PR kern/158426.
 Can you try the patch from PR followup and report us whether it helps?
 Full link to PR with patch:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158426


 I applied the patch and tried about 15 reboots and all went fine


 Hi, Tom.
 A better fix for this problem has been developed since then. Would you
 please try it as well? For doing that, you need to revert a previous
 patch and apply this one.
 Please report if this change also fixes the panic for you, so it  has
 better chances to get into 9.0 release.


 Index: sys/netinet6/mld6.c
 ===
 --- sys/netinet6/mld6.c (revision 224471)
 +++ sys/netinet6/mld6.c (working copy)
 @@ -680,7 +680,6 @@ mld_v1_input_query(struct ifnet *ifp, const struct

        IN6_MULTI_LOCK();
        MLD_LOCK();
 -       IF_ADDR_LOCK(ifp);

        /*
         * Switch to MLDv1 host compatibility mode.
 @@ -693,6 +692,7 @@ mld_v1_input_query(struct ifnet *ifp, const struct
        if (timer == 0)
                timer = 1;

 +       IF_ADDR_LOCK(ifp

Re: BETA1 IPv6 crash

2011-08-08 Thread Tom Vijlbrief
2011/8/7 Sergey Kandaurov pluk...@gmail.com:
 On 7 August 2011 17:11, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote:
 I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the
 new installer.

 Major issue I noticed was the missing /home.

 It took me quite some time to get IPv6 working in the guest (a Linux
 configuration issue), but now that it works
 BETA1 panics in about 50% of the boot attempts:

 testbsd dumped core - see /var/crash/vmcore.0

 Sun Aug  7 08:25:28 CEST 2011

 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16
 UTC 2011     r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 i386

 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
 /usr/src/sys/netinet6/mld6.c:1676

 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-marcel-freebsd...
 [..]
 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
 /usr/src/sys/netinet6/mld6.c:1676

 cpuid = 0
 KDB: enter: panic
 Uptime: 28s
 Physical memory: 491 MB
 Dumping 45 MB: 30 14

 #0  doadump (textdump=1) at pcpu.h:244
 244     pcpu.h: No such file or directory.
        in pcpu.h
 (kgdb) #0  doadump (textdump=1) at pcpu.h:244
 #1  0xc0a04965 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:430
 #2  0xc0a04291 in panic (fmt=Variable fmt is not available.
 ) at /usr/src/sys/kern/kern_shutdown.c:595
 #3  0xc09f4a4a in _mtx_lock_sleep (m=0xc35f3a28, tid=3278693824, opts=0,
    file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676)
    at /usr/src/sys/kern/kern_mutex.c:341
 #4  0xc09f4c67 in _mtx_lock_flags (m=0xc35f3a28, opts=0,
    file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676)
    at /usr/src/sys/kern/kern_mutex.c:203
 #5  0xc0bbf007 in mld_set_version (mli=0xc3589a00, version=Variable
 version is not available.
 )
    at /usr/src/sys/netinet6/mld6.c:1676
 #6  0xc0bc0c00 in mld_input (m=0xc3951e00, off=48, icmp6len=24)
    at /usr/src/sys/netinet6/mld6.c:690
 #7  0xc0ba5696 in icmp6_input (mp=0xc3313a54, offp=0xc3313a68, proto=58)
    at /usr/src/sys/netinet6/icmp6.c:654
 #8  0xc0bba23a in ip6_input (m=0xc3951e00)
    at /usr/src/sys/netinet6/ip6_input.c:964
 #9  0xc0ac9b1c in netisr_dispatch_src (proto=10, source=0, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1013
 #10 0xc0ac9da0 in netisr_dispatch (proto=10, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1104
 #11 0xc0abecf1 in ether_demux (ifp=0xc35f3800, m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:936
 #12 0xc0abf1b3 in ether_nh_input (m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:755
 #13 0xc0ac9b1c in netisr_dispatch_src (proto=9, source=0, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1013
 #14 0xc0ac9da0 in netisr_dispatch (proto=9, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1104
 #15 0xc0abe7f5 in ether_input (ifp=0xc35f3800, m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:796
 #16 0xc0672bc9 in lem_handle_rxtx (context=0xc3732000, pending=1)
    at /usr/src/sys/dev/e1000/if_lem.c:3554
 #17 0xc0a468ab in taskqueue_run_locked (queue=0xc359ca80)
    at /usr/src/sys/kern/subr_taskqueue.c:306
 #18 0xc0a47307 in taskqueue_thread_loop (arg=0xc37365ec)
    at /usr/src/sys/kern/subr_taskqueue.c:495
 #19 0xc09d7af8 in fork_exit (callout=0xc0a472a0 taskqueue_thread_loop,
    arg=0xc37365ec, frame=0xc3313d28) at /usr/src/sys/kern/kern_fork.c:941
 #20 0xc0d1d714 in fork_trampoline () at 
 /usr/src/sys/i386/i386/exception.s:275
 (kgdb)


 This is the same as in PR kern/158426.
 Can you try the patch from PR followup and report us whether it helps?
 Full link to PR with patch:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158426

 --
 wbr,
 pluknet



I applied the patch and tried about 15 reboots and all went fine
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


BETA1 IPv6 crash

2011-08-07 Thread Tom Vijlbrief
I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the
new installer.

Major issue I noticed was the missing /home.

It took me quite some time to get IPv6 working in the guest (a Linux
configuration issue), but now that it works
BETA1 panics in about 50% of the boot attempts:

testbsd dumped core - see /var/crash/vmcore.0

Sun Aug  7 08:25:28 CEST 2011

FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16
UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
i386

panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
/usr/src/sys/netinet6/mld6.c:1676

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...

Unread portion of the kernel message buffer:
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 UTC 2011
r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
WARNING: WITNESS option enabled, expect reduced performance.
CPU: QEMU Virtual CPU version 0.14.0 (3013.63-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x623  Family = 6  Model = 2  Stepping = 3
  
Features=0x783fbfdFPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2
  Features2=0x80802001SSE3,CX16,POPCNT,HV
  AMD Features=0x100800SYSCALL,NX
  AMD Features2=0x61LAHF,ABM,SSE4A
real memory  = 536870912 (512 MB)
avail memory = 501788672 (478 MB)
Event timer LAPIC quality 400
ACPI APIC Table: BOCHS  BXPCAPIC
ioapic0: Changing APIC ID to 1
ioapic0 Version 1.1 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: BOCHS BXPCRSDT on motherboard
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0
cpu0: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci_link4: Unable to route IRQs: AE_NOT_FOUND
isab0: PCI-ISA bridge at device 1.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX3 WDMA2 controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc580-0xc58f at device 1.1 on
pci0
ata0: ATA channel 0 on atapci0
ata1: ATA channel 1 on atapci0
uhci0: Intel 82371SB (PIIX3) USB controller port 0xc540-0xc55f irq
11 at device 1.2 on pci0
usbus0: controller did not stop
usbus0: Intel 82371SB (PIIX3) USB controller on uhci0
pci0: bridge at device 1.3 (no driver attached)
vgapci0: VGA-compatible display mem
0xfc00-0xfdff,0xfebf-0xfebf0fff at device 2.0 on pci0
em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port
0xc500-0xc53f mem 0xfebc-0xfebd irq 11 at device 3.0 on pci0
em0: Memory Access and/or Bus Master bits were not set!
em0: Ethernet address: 52:54:00:d6:ff:9e
pcm0: Intel ICH (82801AA) port 0xc000-0xc3ff,0xc400-0xc4ff irq 11 at
device 4.0 on pci0
pcm0: SigmaTel STAC9700/83/84 AC97 Codec
pci0: memory, RAM at device 5.0 (no driver attached)
hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
Timecounter HPET frequency 1 Hz quality 950
atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0
Event timer RTC frequency 32768 Hz quality 0
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse Explorer, device ID 4
fdc0: floppy drive controller port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: does not respond
device_attach: fdc0 attach returned 6
pmtimer0 on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
attimer0: AT timer at port 0x40 on isa0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
ppc0: parallel port not found.
uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
Timecounters tick every 10.000 msec
pcm0: measured ac97 link rate at 64028 Hz
usbus0: 12Mbps Full Speed USB v1.0
ugen0.1: Intel at usbus0
uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: QEMU HARDDISK 0.14.0 ATA-7 device
ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes)
ada0: 12288MB (25165824 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad0
cd0 at ata1 bus 0 scbus1 target 0 lun 0
cd0: QEMU QEMU DVD-ROM 0.14 Removable CD-ROM SCSI-0 device
cd0: 16.700MB/s transfers (WDMA2, ATAPI 

Freezing PC with start of X with ATI Rage

2010-12-25 Thread Tom Vijlbrief
On Sunday 19 December 2010 09:49:21 Vladislav Movchan wrote:
 On Sat, Dec 18, 2010 at 10:34 PM, Vladislav Movchan

 vladislav.movc...@gmail.com wrote:
  On Sat, Dec 18, 2010 at 11:14 AM, Christian Gusenbauer c...@gmx.at
wrote:
  Hi!
 
  With commit r216333 to pmap.c my PC (i386 32 bit) freezes within a few
  seconds when X (with nvidia-driver 256.53) starts. I already recompiled
  and reinstalled the nvidia driver, but this didn't change anything. I
  also tried the latest nvidia-driver 260.19.29 but without luck, too
  :-(.
 
  By chance I saw a panic message vm_page_unwire: page 0x... wire count
  is zero, but no crash dump was generated.
 
  Any clues?
 
  Thanks,
  Christian.
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
  freebsd-current-unsubscr...@freebsd.org
 
  I can only add me too - I am experiencing the same problem with two
  i386 machines. Both PCs work fine on revision 216332 and hanging on
  revision 216333 or later.
  I've tried to use different nvidia-driver versions (195.36.24, 256.53
  and 260.19.29), tried disabling glx/dri xorg extensions but nothing
  changed. Freeze happening before the moment when nvidia logo
  appears.
  Unfortunately I was never able to see panic message or obtain crash dump.
 
  If anybody have ideas I can help with testing.
 
  First machine:
  pciconf:
  vgap...@pci0:1:0:0: class=0x03 card=0x04421028 chip=0x0a2910de
  rev=0xa2 hdr=0x00
 vendor = 'NVIDIA Corporation'
 class  = display
 subclass   = VGA
 
  Xorg log:
  (--) PCI:*(0:1:0:0) 10de:0a29:1028:0442 nVidia Corporation GT216
  [GeForce GT 330M] rev 162, Mem @ 0xfa00/16777216,
  0xc000/268435456, 0xd000/33554432, I/O @ 0xe000/128, BIOS
  @ 0x/65536
 
  Second one:
  pciconf:
  vgap...@pci0:1:0:0: class=0x03 card=0x34681458 chip=0x061110de
  rev=0xa2 hdr=0x00
 vendor = 'NVIDIA Corporation'
 device = 'NVIDIA GeForce 8800 GT (G92)'
 class  = display
 subclass   = VGA
 
  Xorg log:
  (--) PCI:*(0:1:0:0) 10de:0611:1458:3468 nVidia Corporation G92
  [GeForce 8800 GT] rev 162, Mem @ 0xf600/16777216,
  0xe000/268435456, 0xf400/33554432, I/O @ 0xb000/128, BIOS
  @ 0x/65536
 
  --
  Have a nice(1) day,
  Vladislav Movchan

 Update to r216555 fixed this problem for me.

I have similar problems on my old Pentium-II with an ATI Rage, but the
actual current still freezes. Stable is fine.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org