Re: troubles with buildworld/sendmail/sasl/clang
On Thu, Mar 21, 2013, Dimitry Andric wrote: > Use the port, or the attached patch, to disable usage of stdbool.h. It might be a better idea to change include/sm/os/sm_os_freebsd.h to set SM_CONF_STDBOOL_H See also libsm/README. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 03/21/13 18:20, Miroslav Lachman wrote:
Jamie Gritton wrote:
On 03/21/13 17:59, Miroslav Lachman wrote:
Jeremie Le Hen wrote:
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):
On 02/15/13 09:27, Harald Schmalzbauer wrote:
Hello,
like already posted, on 9.1-R, I highly appreciate the new jail(8)
and
jail.conf capabilities. Thanks for that extension!
Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...
[...]
I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC
I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.
Even if I set all this in my jail.conf
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;
path = "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}
[...]
Is it a problem in my understanding of manpage / configuration, or is it
a bug in jail command on 9.1-RELEASE?
It's a bug (deficiency) in the jail command.
Is there a workaround or is it impossible to use jails with devfs on
FreeBSD 9.1?
Shouldn't it be mentioned in 9.1 errata?
Is it fixed in stable/9?
Thank you for your reply and your great work on new jails!
It's not fixed anywhere yet - it sometimes works in current, and
sometimes doesn't. I've been meaning to patch it up, but it the problem
is what I think it is, the patching up is a pretty big operation.
It doesn't mean you can't use jails with devfs in 9.1, just that you
can't use them with jail.conf. The old jail rc file that's all
shell-based is still the official jail startup method, and that one
still works. So existing systems will still work as expected, hence no
errata.
- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
Jamie Gritton wrote:
On 03/21/13 17:59, Miroslav Lachman wrote:
Jeremie Le Hen wrote:
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):
On 02/15/13 09:27, Harald Schmalzbauer wrote:
Hello,
like already posted, on 9.1-R, I highly appreciate the new jail(8)
and
jail.conf capabilities. Thanks for that extension!
Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...
[...]
I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC
I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.
Even if I set all this in my jail.conf
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;
path = "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}
[...]
Is it a problem in my understanding of manpage / configuration, or is it
a bug in jail command on 9.1-RELEASE?
Miroslav Lachman
It's a bug (deficiency) in the jail command.
Is there a workaround or is it impossible to use jails with devfs on
FreeBSD 9.1?
Shouldn't it be mentioned in 9.1 errata?
Is it fixed in stable/9?
Thank you for your reply and your great work on new jails!
Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 03/21/13 17:59, Miroslav Lachman wrote:
Jeremie Le Hen wrote:
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):
On 02/15/13 09:27, Harald Schmalzbauer wrote:
Hello,
like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!
Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...
Thanks for any help,
-Harry
devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?
Thanks for your response.
Yes, I have mount.devfs; set.
Otherwise I wouldn't have any device inside my jail. Verified - and like
intended, right?
Another notable discrepancy: The man page tells that devfs_rulset is "4"
by default.
But when I don't set devfs_rulset in jail.conf at all, inside the jail,
'sysctl security.jail.devfs_ruleset': 0
When set, like mentioned above, it returns the corresponding value, but
it doesn't have any effect.
How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like
to help finding the source, but have missed the whole new jail
evolution...
Inside my jails, I don't have a fstab, outside I have them defined and
enabled with "mount" - and noticed the non-reverted umounting.
Look at what's in /dev from you jail. There should a few pseudo
devices (see below), but no real devices:
$ ls /dev
crypto log ptmx random stdin urandom zfs
fd null pts stderr stdout zero
I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC
I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.
Even if I set all this in my jail.conf
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;
path = "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}
# jexec 4 tcsh
root@bali:/ # ls -l /dev/
total 4
crw-r--r-- 1 root wheel 0, 35 Mar 1 19:39 acpi
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad10 -> ada3
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s1 -> ada3s1
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1a -> ada3s1a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1b -> ada3s1b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1d -> ada3s1d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1e -> ada3s1e
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1f -> ada3s1f
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1g -> ada3s1g
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s2 -> ada3s2
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2a -> ada3s2a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2b -> ada3s2b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2d -> ada3s2d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2e -> ada3s2e
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad4 -> ada0
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad6 -> ada1
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad8 -> ada2
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s1 -> ada2s1
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1a -> ada2s1a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1b -> ada2s1b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1d -> ada2s1d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1e -> ada2s1e
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1f -> ada2s1f
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1g -> ada2s1g
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s2 -> ada2s2
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2a -> ada2s2a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2b -> ada2s2b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2d -> ada2s2d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2e -> ada2s2e
crw-r- 1 root operator 0, 106 Mar 1 19:39 ada0
crw-r- 1 root operator 0, 108 Mar 1 19:39 ada1
crw-r- 1 root operator 0, 114 Mar 1 19:39 ada2
crw-r- 1 root operator 0, 120 Mar 1 19:39 ada2s1
crw-r- 1 root operator 0, 130 Mar 1 19:39 ada2s1a
crw-r- 1 root operator 0, 132 Mar 1 19:39 ada2s1b
crw-r- 1 root operator 0, 134 Mar 1 19:39 ada2s1d
crw-r- 1 root operator 0, 136 Mar 1 19:39 ada2s1e
crw-r- 1 root operator 0, 138 Mar 1 19:39 ada2s1f
crw-r- 1 root operator 0, 140 Mar 1 19:39 ada2s1g
crw-r- 1 root operator 0, 122 Mar 1 19:39 ada2s2
crw-r- 1 root operator 0, 142 Mar 1 19:39 ada2s2a
crw-r- 1 root operator 0, 144 Mar 1 19:39 ada2s2b
crw-r- 1 root operator 0, 146 Mar 1 19:39 ada2s2d
crw-r- 1 root operator 0, 148 Mar 1 19:39 ada2s2e
crw-r- 1 root operator 0, 116 Mar 1 19:39 ada3
crw-r- 1 root operator 0, 124 Mar 1 19:39 ada3s1
crw-r- 1 root operator 0, 150 Mar 1 19:39 ada3s1a
crw-r- 1 root operator 0, 154 Mar 1 19:39 ada3s1b
crw-r- 1 root operator 0, 156 Mar
Re: new jail(8) ignoring devfs_ruleset?
Jeremie Le Hen wrote:
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):
On 02/15/13 09:27, Harald Schmalzbauer wrote:
Hello,
like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!
Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...
Thanks for any help,
-Harry
devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?
Thanks for your response.
Yes, I have mount.devfs; set.
Otherwise I wouldn't have any device inside my jail. Verified - and like
intended, right?
Another notable discrepancy: The man page tells that devfs_rulset is "4"
by default.
But when I don't set devfs_rulset in jail.conf at all, inside the jail,
'sysctl security.jail.devfs_ruleset': 0
When set, like mentioned above, it returns the corresponding value, but
it doesn't have any effect.
How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like
to help finding the source, but have missed the whole new jail evolution...
Inside my jails, I don't have a fstab, outside I have them defined and
enabled with "mount" - and noticed the non-reverted umounting.
Look at what's in /dev from you jail. There should a few pseudo
devices (see below), but no real devices:
$ ls /dev
crypto log ptmxrandom stdin urandom zfs
fd nullpts stderr stdout zero
I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC
I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.
Even if I set all this in my jail.conf
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;
path= "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}
# jexec 4 tcsh
root@bali:/ # ls -l /dev/
total 4
crw-r--r-- 1 root wheel 0, 35 Mar 1 19:39 acpi
lrwxr-xr-x 1 root wheel4 Mar 22 00:46 ad10 -> ada3
lrwxr-xr-x 1 root wheel6 Mar 22 00:46 ad10s1 -> ada3s1
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1a -> ada3s1a
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1b -> ada3s1b
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1d -> ada3s1d
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1e -> ada3s1e
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1f -> ada3s1f
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1g -> ada3s1g
lrwxr-xr-x 1 root wheel6 Mar 22 00:46 ad10s2 -> ada3s2
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s2a -> ada3s2a
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s2b -> ada3s2b
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s2d -> ada3s2d
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s2e -> ada3s2e
lrwxr-xr-x 1 root wheel4 Mar 22 00:46 ad4 -> ada0
lrwxr-xr-x 1 root wheel4 Mar 22 00:46 ad6 -> ada1
lrwxr-xr-x 1 root wheel4 Mar 22 00:46 ad8 -> ada2
lrwxr-xr-x 1 root wheel6 Mar 22 00:46 ad8s1 -> ada2s1
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1a -> ada2s1a
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1b -> ada2s1b
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1d -> ada2s1d
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1e -> ada2s1e
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1f -> ada2s1f
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1g -> ada2s1g
lrwxr-xr-x 1 root wheel6 Mar 22 00:46 ad8s2 -> ada2s2
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s2a -> ada2s2a
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s2b -> ada2s2b
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s2d -> ada2s2d
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s2e -> ada2s2e
crw-r- 1 root operator0, 106 Mar 1 19:39 ada0
crw-r- 1 root operator0, 108 Mar 1 19:39 ada1
crw-r- 1 root operator0, 114 Mar 1 19:39 ada2
crw-r- 1 root operator0, 120 Mar 1 19:39 ada2s1
crw-r- 1 root operator0, 130 Mar 1 19:39 ada2s1a
crw-r- 1 root operator0, 132 Mar 1 19:39 ada2s1b
crw-r- 1 root operator0, 134 Mar 1 19:39 ada2s1d
crw-r- 1 root operator0, 136 Mar 1 19:39 ada2s1e
crw-r- 1 root operator0, 138 Mar 1 19:39 ada2s1f
crw-r- 1 root operator0, 140 Mar 1 19:39 ada2s1g
crw-r- 1 root operator0, 122 Mar
Re: troubles with buildworld/sendmail/sasl/clang
On Mar 21, 2013, at 15:16, Anton Shterenlikht wrote: > Kimmo Paasiala writes: ... > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > > error: incompatible pointer types passing 'void ()' to parameter > of type > > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, > ENVELOPE *)' > > > [-Werror,-Wincompatible-pointer-types] > > >getsasldata, NULL, XS_AUTH); > > >^~~ ... > # cat /etc/make.conf > SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 > SENDMAIL_LDFLAGS+= -L/usr/local/lib > SENDMAIL_LDADD+=-lsasl2 Use the port, or the attached patch, to disable usage of stdbool.h. sendmail-disable-stdbool-1.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Core Dump / panic sleeping thread
On Thu, Mar 21, 2013 at 07:59:25PM +0100, Michael Landin Hostbaek wrote: > > On Mar 21, 2013, at 8:58 AM, Konstantin Belousov wrote: > > > On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: > >> Well, read/write sharing of files over NFS is pretty rare, so I suspect > >> a truncation of a file by another client (or locally in the NFS server) > >> is a rare event. As such, not invalidating the buffers here doesn't seem > >> like a big issue? (The client uses np->n_size to determine EOF.) > >> > >> Also, I think close-to-open consistency will typically throw away the > >> buffers on the next open when it sees the mtime changed. (Yes, there > >> won't necessarily be another open, but...) > > nfs buffers are VMIO. Each VMIO buffer wires the pages it references. > > Wired pages cannot be freed by vnode_pager_setsize() if the file is > > truncated. > > Should I wait for a new patch, or should I give the one you sent yesterday a > try? > > Thanks, You should use the r248567 + r248581. pgpMNLfWZLaVc.pgp Description: PGP signature
Re: Core Dump / panic sleeping thread
On Mar 21, 2013, at 8:58 AM, Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: >> Well, read/write sharing of files over NFS is pretty rare, so I suspect >> a truncation of a file by another client (or locally in the NFS server) >> is a rare event. As such, not invalidating the buffers here doesn't seem >> like a big issue? (The client uses np->n_size to determine EOF.) >> >> Also, I think close-to-open consistency will typically throw away the >> buffers on the next open when it sees the mtime changed. (Yes, there >> won't necessarily be another open, but...) > nfs buffers are VMIO. Each VMIO buffer wires the pages it references. > Wired pages cannot be freed by vnode_pager_setsize() if the file is > truncated. Should I wait for a new patch, or should I give the one you sent yesterday a try? Thanks, /mich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic : bad pte
Le mercredi 20 mars 2013 20:09:42 David Demelier a écrit : > 2013/3/19 Jeremy Chadwick : > > On Tue, Mar 19, 2013 at 06:34:24PM +0100, David Demelier wrote: > >> Hello, > >> > >> There it is, all my computers on FreeBSD 9.1-RELEASE had panic. I can > >> just say there is a problem in the 9.1-RELEASE because I had no panic > >> before. What afraid me is that my production server also panic'ed a > >> few days ago, fortunately it does not appears so often. > >> > >> This is a panic that happened on my desktop computer, with a graphic > >> card. The crash usually appears when X starts. > >> > >> 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 "amd64-marcel-freebsd"... > >> > >> Unread portion of the kernel message buffer: > >> panic: bad pte > >> cpuid = 3 > >> KDB: stack backtrace: > >> Uptime: 2m31s > >> Dumping 183 out of 1950 > >> MB:..9%..18%..27%..35%..44%..53%..62%..79%..88%..96% > >> > >> Reading symbols from /boot/modules/nvidia.ko...done. > >> Loaded symbols for /boot/modules/nvidia.ko > >> #0 doadump (textdump=Variable "textdump" is not available. > >> ) at pcpu.h:224 > >> 224 pcpu.h: No such file or directory. > >> > >> in pcpu.h > >> > >> (kgdb) bt > >> #0 doadump (textdump=Variable "textdump" is not available. > >> ) at pcpu.h:224 > >> #1 0x0004 in ?? () > >> #2 0x8048c156 in kern_reboot (howto=260) at > >> /usr/src/sys/kern/kern_shutdown.c:448 > >> #3 0x8048c619 in panic (fmt=0x1 ) > >> at /usr/src/sys/kern/kern_shutdown.c:636 > >> #4 0x8065f88a in pmap_remove_pages (pmap=0xfe0005a2fa60) > >> at /usr/src/sys/amd64/amd64/pmap.c:4156 > >> #5 0x8063d26b in vmspace_exit (td=0xfe0005a05470) at > >> /usr/src/sys/vm/vm_map.c:422 > >> #6 0x8045d725 in exit1 (td=0xfe0005a05470, rv=Variable > >> "rv" is not available. > >> ) at /usr/src/sys/kern/kern_exit.c:315 > >> #7 0x8045e5ce in sys_sys_exit (td=Variable "td" is not > >> available. > >> ) at /usr/src/sys/kern/kern_exit.c:122 > >> #8 0x8066737f in amd64_syscall (td=0xfe0005a05470, > >> traced=0) at subr_syscall.c:135 > >> #9 0x80652d97 in Xfast_syscall () at > >> /usr/src/sys/amd64/amd64/exception.S:387 > >> #10 0x000800d51c1c in ?? () > >> Previous frame inner to this frame (corrupt stack?) > >> (kgdb) > >> > >> Of course I may do something wrong, and I hope so but unfortunately I > >> can't find any solution. May the nvidia driver be the problem? > > > > Interesting timing. Semi-recently (February) src/sys/amd64/amd64/pmap.c > > in 9.1-STABLE (not -RELEASE) was modified to increase the information > > shown for this specific type of panic. See revision 247079: > > > > http://svnweb.freebsd.org/base/stable/9/sys/amd64/amd64/pmap.c?view=log > > > > I've CC'd Konstantin Belousov (kib@), who should be able to help step > > you through getting information out of the crash dump, to help track > > down the root cause. > > > > -- > > > > | Jeremy Chadwick j...@koitsu.org | > > | UNIX Systems Administratorhttp://jdc.koitsu.org/ | > > | Mountain View, CA, US| > > | Making life hard for others since 1977. PGP 4BD6C0CB | > > You will not believe that, when I leave the desktop. I completely > detach the AC adaptor (usually at evening). And everyday when I plug > it and start the machine it panics. But when it reboots and start > again no panic anymore. I just can't believe it. > > The panic is completely different from yesterday's one : > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8010 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x8049db4e > stack pointer = 0x28:0xff8000225a90 > frame pointer = 0x28:0xfe000247c8e0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= resume, IOPL = 0 > current process = 10 (idle: cpu0) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > Uptime: 1m3s > Dumping 324 out of 1950 MB:..5%..15%..25%..35%..45%..55%..65%..74%..84%..94% > > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > 224 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=Variable "textdump" is not available.
Re: troubles with buildworld/sendmail/sasl/clang
Kimmo Paasiala writes: > > =buildworld=== > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > error: incompatible pointer types passing 'void ()' to parameter of type > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' > > [-Werror,-Wincompatible-pointer-types] > >getsasldata, NULL, XS_AUTH); > >^~~ > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: > > passing argument to parameter here > > extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void > > (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); > > ^ > > /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from > > macro '__P' > > #define __P(protos) protos /* full-blown ANSI C */ > > ^ > > 3 errors generated. > > *** [usersmtp.o] Error code 1 > > > I can not help with the error but I really have to make this question: > Does FreeBSD really have to support pre-ANSI C compilers in 2013? I have been getting this also for at least the last two months. (There is no src.conf; make.conf is appended. Current system is: FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012 amd64 and I have cyrus-sasl-2.1.26_2 installed and working with that installation.) Respectfully, Robert Huff me too, also on amd64 -current no src.conf # cat /etc/make.conf SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 WITH_PKGNG=yes PERL_VERSION=5.16.2 Anton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: troubles with buildworld/sendmail/sasl/clang
Kimmo Paasiala writes:
> > =buildworld===
> >
> > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8:
> > error: incompatible pointer types passing 'void ()' to parameter of type
> > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)'
> > [-Werror,-Wincompatible-pointer-types]
> >getsasldata, NULL, XS_AUTH);
> >^~~
> > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67:
> note:
> > passing argument to parameter here
> > extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void
> > (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int));
> >^
> > /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from
> > macro '__P'
> > #define __P(protos) protos /* full-blown ANSI C */
> > ^
> > 3 errors generated.
> > *** [usersmtp.o] Error code 1
>
>
> I can not help with the error but I really have to make this question:
> Does FreeBSD really have to support pre-ANSI C compilers in 2013?
I have been getting this also for at least the last two months.
(There is no src.conf; make.conf is appended. Current system
is:
FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012 amd64
and I have cyrus-sasl-2.1.26_2 installed and working with that
installation.)
Respectfully,
Robert Huff
make.conf
CFLAGS= -O -pipe -g
STRIP=
SYMVER_ENABLED= yes
X_WINDOW_SYSTEM=xorg
HAVE_MOTIF= yes
KERNCONF=JERUSALEM
# To avoid building various parts of the base system:
# (copied from /usr/share/examples/etc/make.conf
NO_BIND_ETC= true# Do not install files to /etc/namedb
NO_BLUETOOTH= true# do not build Bluetooth related stuff
NO_PROFILE= true# Avoid compiling profiled libraries
# to get automatic SASL in sendmail
SENDMAIL_CFLAGS+= -I/usr/local/include/ -DSASL=2
SENDMAIL_LDFLAGS+= -L/usr/local/lib
SENDMAIL_LDADD+=-lsasl2
#
# to make CUPS magically keep working
# See: http://www.csua.berkeley.edu/~ranga/notes/freebsd_cups.html
#
CUPS_OVERWRITE_BASE=yes
NO_LPR= true
# added per /usr/ports/UPDATING entry 20090401
OVERRIDE_LINUX_BASE_PORT=f10
OVERRIDE_LINUX_NONBASE_PORTS=f10
#
WITH_MOZILLA= libxul
WITH_GECKO= libxul
#
# added 2007/03/04 per advice of
# in re science/gramps
#
WITH_BERKELEYDB=db43
WITH_BDB_VER=43
WANT_OPENLDAP_VER=24
WANT_OPENLDAP_SASL=true
#
# as required by ports/UPDATING of 20121012
#
SAMBA_ENABLE=YES
#
# PORTS: use clang unless gcc is explicitly required
#
#
# default to using clang for all port builds, with the following
# exceptions
# ports which will only build with the base system GNU compiler (4.2)
#
# the "make index" target also seems to need this, for some reason
.if target(index) | \
${.CURDIR:M*/devel/antlr*} | \
${.CURDIR:M*/devel/google-perftools* } | \
${.CURDIR:M*/graphics/ImageMagick* } | \
${.CURDIR:M*/graphics/opencv*} | \
${.CURDIR:M*/x11/kdelibs4*} | \
USE_GCC?=4.2
.endif
# ports which need *some* version of the GNU compiler (won't build with
# clang or have runtime issues if built with clang)
# use the highest version of gcc we have installed from ports (4.6)
.if ${.CURDIR:M*/accessibility/jovie*} | \
${.CURDIR:M*/accessibility/kdeaccessibility4*} | \
${.CURDIR:M*/audio/grip*} | \
${.CURDIR:M*/audio/mpg123*} | \
${.CURDIR:M*/audio/rosegarden*} | \
${.CURDIR:M*/databases/virtuoso*} | \
${.CURDIR:M*/deskutils/kdepimlibs4*} | \
${.CURDIR:M*/devel/apache-ant*} | \
${.CURDIR:M*/devel/icu*} | \
${.CURDIR:M*/devel/kdevelop-kde4*} | \
${.CURDIR:M*/devel/kdevplatform*} | \
${.CURDIR:M*/devel/log4j*} | \
${.CURDIR:M*/games/kdegames4*} | \
${.CURDIR:M*/graphics/tonicpoint-viewer*} | \
${.CURDIR:M*/java/* } | \
${.CURDIR:M*/lang/gcc* } | \
${.CURDIR:M*/math/fftw3*} | \
${.CURDIR:M*/multimedia/avidemux2*} | \
${.CURDIR:M*/multimedia/kdemultimedia4*} | \
${.CURDIR:M*/multimedia/vlc*} | \
${.CURDIR:M*/multimedia/xbmc*} | \
${.CURDIR:M*/net/kdenetwork4*} | \
${.CURDIR:M*/net/mpich2*} | \
${.CURDIR:M*/net/opal3*} | \
${.CURDIR:M*/net-p2p/ktorrent*} | \
${.CURDIR:M*/net-p2p/vuze*} | \
${.CURDIR:M*/sysutils/lsof*} | \
${.CURDIR:M*/textproc/docbook-xsl*} | \
${.CURDIR:M*/textproc/fop*} | \
${.CURDIR:M*/www/libxul*} | \
${.CURDIR:M*/x11/kde4-baseapps*} | \
${.CURDIR:M*/x11/kde4-workspace*} | \
${.CURDIR:M*/x11/lxpanel*} | \
USE_GCC?=4.6+
.endif
.if ${.CURDIR:M*/usr/ports/*}
.if !defined(USE_GCC)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
.endif
.endif
WITH_NEW_XORG=yes
WITH_BSD_SO
Re: Core Dump / panic sleeping thread
On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: > Well, read/write sharing of files over NFS is pretty rare, so I suspect > a truncation of a file by another client (or locally in the NFS server) > is a rare event. As such, not invalidating the buffers here doesn't seem > like a big issue? (The client uses np->n_size to determine EOF.) > > Also, I think close-to-open consistency will typically throw away the > buffers on the next open when it sees the mtime changed. (Yes, there > won't necessarily be another open, but...) nfs buffers are VMIO. Each VMIO buffer wires the pages it references. Wired pages cannot be freed by vnode_pager_setsize() if the file is truncated. pgpOJM_BO3RwF.pgp Description: PGP signature
