Re: 8.1-PRERELEASE: CPU packages not detected correctly
David Xu wrote: Do you have patch for i386 branch ? I want to test. On my Pentium-D machine: $ sysctl kern.sched.topology_spec kern.sched.topology_spec: groups group level=1 cache-level=0 cpu count=2 mask=0x30, 1/cpu flags/flags children group level=3 cache-level=2 cpu count=2 mask=0x30, 1/cpu flags/flags /group /children /group /groups it seems the kernel thinks that the Pentuim-D is sharing L2 cache, but in fact, the design of the Pentium Ds was simply two P4 cores sitting side by side. They do not share anything and they basically work independently. Same thing on my intel Atom 330 board at home: groups group level=1 cache-level=0 cpu count=4 mask=0xf0, 1, 2, 3/cpu flags/flags children group level=3 cache-level=2 cpu count=4 mask=0xf0, 1, 2, 3/cpu flags/flags children group level=5 cache-level=1 cpu count=2 mask=0x30, 1/cpu flagsflag name=HTTHTT group/flag /flags /group group level=5 cache-level=1 cpu count=2 mask=0xc2, 3/cpu flagsflag name=HTTHTT group/flag /flags /group /children /group /children /group /groups The intel Atom 330 consists of two Diamondville dies on one package, each with its own 512 KB of L2 cache. There is no L3 cache, or any other shared cache. (Or maybe I misinterpret the XML output; I think that the level and cache-level numbers are confusing.) BTW, I noticed that the indentation problem (newline before /flags) is already fixed in -current, 5 weeks ago. Any plan to MFC this? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python tricks is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure wink. -- Tim Peters ___ 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: update on kern/145064?
on 16/07/2010 00:02 Petr Holub said the following: Dear stable list, is there any update on bug hunting of the issue described here? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/145064 I've attempted to install PC BSD 8.1-RC1 on my desktop and I'm facing the same problem with the Marvell SATA driver. Therefore, PC BSD is not installable on my machine as it deterministically panics on boot. The same machine runs FreeBSD 7.3 just fine. I guess that your best bet is to directly ping mav@ in case he missed the PR and this thread. -- Andriy Gapon ___ 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: 8.1-PRERELEASE: CPU packages not detected correctly
On Thu, Jul 15, 2010 at 10:01:48PM +0200, Oliver Fromme wrote: Jung-uk Kim wrote: On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: on 15/07/2010 19:57 Oliver Fromme said the following: I patched topo_probe() so it calls topo_probe_0x4() after topo_probe_0xb() if cpu_cores is still 0. I think this is a better fallback procedure. With this patch, cpu_cores gets the value 4 which is the correct one, finally: [...] I think that your addition achieves this effect, perhaps just not as explicitly as I would preferred. Jung-uk, what do you think? Yes, you're right. Please try new patch: http://people.freebsd.org/~jkim/mp_machdep2.diff Thank you! I will have access to that particular machine on Monday again, so testing the new patch will have to wait until Monday. But from looking at your patch it should have the same result as my simpler patch, so it should work fine. I have a general question for everyone involved in this thread (which is highly educational/interesting -- thank you for all the info!): Does the problem reported affect actual performance/behaviour of FreeBSD kernel-wise at all, or is it just a cosmetical issue with regards to showing how many cores/threads there are? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote: Furthermore, relevant bug (PR 144754) indicates there's an easier way to induce this problem, so I'm going to see if I can reproduce it here locally. It's almost certainly the same problem but induced via a slightly different context. http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html I'll report back once I poke around with that. I've tried to reproduce what's in the PR and can't. Running cyradm works fine: testbox# pkg_info cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 protocols cyrus-sasl-2.1.23 RFC SASL (Simple Authentication and Security Layer) db41-4.1.25_4 The Berkeley DB package, revision 4.1 libtool-2.2.6b Generic shared library support script perl-5.10.1_1 Practical Extraction and Report Language portaudit-0.5.15Checks installed ports against a list of security vulnerabi rsync-3.0.7 A network file distribution/synchronization utility vim-lite-7.2.411Vi workalike, with many additional features (Lite package testbox# cyradm cyradm I should note this machine **does** have Kerberos installed as part of the FreeBSD base system (meaning src.conf does not contain WITHOUT_KERBEROS). Mikhail, is there something I need to configure within cyrus-imapd23 first? Three things to note: 1) I didn't modify /usr/local/etc/cyrus.conf or imapd.conf. 2) I have not started the imapd service. 3) /var/log/all.log shows the following errors (but the daemon starts anyway): Jul 15 23:25:25 testbox master[46529]: process started Jul 15 23:25:25 testbox master[46530]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db/__db.001: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db/__db.001: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: dbenv-open '/var/imap/db' failed: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: dbenv-open '/var/imap/db' failed: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on berkeley Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on berkeley Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: writing /var/imap/db/skipstamp: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: writing /var/imap/db/skipstamp: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on skiplist Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on skiplist Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: recovering cyrus databases Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: IOERROR: creating directory /var/imap: Permission denied Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: IOERROR: creating directory /var/imap: Permission denied Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: opening /var/imap: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: opening /var/imap: cyrusdb error Jul 15 23:25:25 testbox master[46529]: process 46530 exited, status 75 Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox master[46529]: process 46530 exited, status 75 Jul 15 23:25:25 testbox master[46529]: unable to create lmtpunix listener socket: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox master[46529]: unable to create lmtpunix listener socket: No such file or directory Jul 15 23:25:25 testbox master[46529]: ready for work Jul 15 23:25:25 testbox master[46531]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: /var/imap/db/__db.001: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: dbenv-open '/var/imap/db' failed: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: dbenv-open '/var/imap/db' failed: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: init() on berkeley Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: init() on berkeley Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: reading /var/imap/db/skipstamp, assuming the worst: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: reading /var/imap/db/skipstamp, assuming the worst: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: checkpointing cyrus databases Jul 15 23:25:25 testbox
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote:
Furthermore, relevant bug (PR 144754) indicates there's an easier
way to
induce this problem, so I'm going to see if I can reproduce it here
locally. It's almost certainly the same problem but induced via a
slightly different context.
http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html
I'll report back once I poke around with that.
testbox# cyradm
cyradm
Try giving command cyradm localhost instead - the cyradm without
connection starts, but trying to connect to the local server triggers
the bug. Or you can give 'server localhost' instead from the cyradm
command line.
I should note this machine **does** have Kerberos installed as part
of
the FreeBSD base system (meaning src.conf does not contain
WITHOUT_KERBEROS).
Similar as my setup - kerberos isn't excluded even if it's not really
used.
Mikhail, is there something I need to configure within cyrus-imapd23
first? Three things to note:
1) I didn't modify /usr/local/etc/cyrus.conf or imapd.conf.
2) I have not started the imapd service.
3) /var/log/all.log shows the following errors (but the daemon
starts
anyway):
Let me know as I'm doing my best to track this down. Thanks.
Another datapoint that might or might not have some connection with
the issue is that in _gss_mg_error (m=0x28a86480, maj=851968, min=2)
at /usr/src/lib/libgssapi/gss_display_status.c
void
232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj,
OM_uint32 min)
233 {
234 OM_uint32 major_status, minor_status;
235 OM_uint32 message_content;
236 struct mg_thread_ctx *mg;
237
238 mg = last_error_context;
239
240 gss_release_buffer(minor_status, mg-maj_error);
241 gss_release_buffer(minor_status, mg-min_error);
242
243 mg-mech = m-gm_mech_oid;
244 mg-maj_stat = maj;
when I give following comands, gdb tells me:
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p mg
No symbol mg in current context.
(gdb)
Thank you very much for your effort in the issue!
-Reko
___
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
bgpd tuning
Hi, I'm setting up a (future) 8.1 box to run as bgpd. I know in 8.x there are some improvements in networking, has someone any advice to tuning this machine? bgpd, routing only. CPU: Intel(R) Xeon(R) CPU5130 @ 2.00GHz (1995.01-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f6 Family = 6 Model = f Stepping = 6 real memory = 2147483648 (2048 MB) avail memory = 2055630848 (1960 MB) ACPI APIC Table: DELL PE_SC3 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 thanks in advance -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ 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: bgpd tuning
W dniu 10-07-16 11:11, Cristiano Deana pisze: Hi, I'm setting up a (future) 8.1 box to run as bgpd. I know in 8.x there are some improvements in networking, has someone any advice to tuning this machine? bgpd, routing only. How many peerings will You have, and how many prefixes You intend to receive? What is the estimated total bandwidth. mjb ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Fri, Jul 16, 2010 at 11:56:17AM +0300, Reko Turja wrote:
Another datapoint that might or might not have some connection with
the issue is that in _gss_mg_error (m=0x28a86480, maj=851968, min=2)
at /usr/src/lib/libgssapi/gss_display_status.c
void
232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj,
OM_uint32 min)
233 {
234 OM_uint32 major_status, minor_status;
235 OM_uint32 message_content;
236 struct mg_thread_ctx *mg;
237
238 mg = last_error_context;
239
240 gss_release_buffer(minor_status, mg-maj_error);
241 gss_release_buffer(minor_status, mg-min_error);
242
243 mg-mech = m-gm_mech_oid;
244 mg-maj_stat = maj;
when I give following comands, gdb tells me:
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p mg
No symbol mg in current context.
(gdb)
I'm not sure if you're familiar with C or not.
This is because gdb's context is at the wrong frame. In the backtrace
you provided originally, you'd need to do:
(gdb) frame 2
To look at the variables associated with gss_display_status.c.
last_error_context could be an exported variable (you'd need to look
through the source to find out where it's declared), so you might have
to print it with its source filename referenced. The print command I
gave you before (p/x filename.c::variable) didn't work, and that's a
surprise since the gdb documentation I read says it should.
Also be aware that mg is a struct, so p mg won't tell you much, other
than whether or not it's null. You're probably more interested in
members of the struct, such as mg-maj_error and mg-min_error, and
other struct members.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Fri, Jul 16, 2010 at 11:56:17AM +0300, Reko Turja wrote: On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote: Furthermore, relevant bug (PR 144754) indicates there's an easier way to induce this problem, so I'm going to see if I can reproduce it here locally. It's almost certainly the same problem but induced via a slightly different context. http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html I'll report back once I poke around with that. testbox# cyradm cyradm Try giving command cyradm localhost instead - the cyradm without connection starts, but trying to connect to the local server triggers the bug. Or you can give 'server localhost' instead from the cyradm command line. This doesn't help. The problem is that Cyrus imapd is completely freaking out, continually dying and re-forking itself, with my kernel message buffer filling rapidly + all.log filling. So, there is further configuration of this daemon that's needed (meaning it does not work straight out of the box), and I need those configuration details. Proof -- note the imapd pid changing constantly: testbox# ps -auxw | grep cyrus cyrus 46529 5.0 0.4 22376 3920 ?? Rs 11:25PM 0:05.36 /usr/local/cyrus/bin/master -d cyrus 51859 0.0 0.4 22376 3920 ?? R12:14AM 0:00.00 /usr/local/cyrus/bin/master -d testbox# ps -auxw | grep cyrus cyrus 46529 6.0 0.4 22376 3920 ?? Ss 11:25PM 0:05.43 /usr/local/cyrus/bin/master -d cyrus 51928 0.0 0.3 22512 3572 ?? R12:15AM 0:00.02 imapd testbox# ps -auxw | grep cyrus cyrus 46529 6.0 0.4 22376 3920 ?? Ss 11:25PM 0:05.55 /usr/local/cyrus/bin/master -d cyrus 52046 0.0 0.1 1560 1360 ?? R12:15AM 0:00.00 imapd testbox# ps -auxw | grep cyrus cyrus 46529 6.0 0.4 22376 3920 ?? Ss 11:25PM 0:05.61 /usr/local/cyrus/bin/master -d cyrus 52114 0.0 0.1 1560 1360 ?? R12:15AM 0:00.00 imapd -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: bgpd tuning
On Fri, Jul 16, 2010 at 11:15 AM, Maciej Jan Broniarz gau...@gausus.net wrote: I'm setting up a (future) 8.1 box to run as bgpd. I know in 8.x there are some improvements in networking, has someone any advice to tuning this machine? bgpd, routing only. How many peerings will You have, and how many prefixes You intend to receive? What is the estimated total bandwidth. 30 peering + 1 route server, 320k prefixes, 200M bw. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
This doesn't help. The problem is that Cyrus imapd is completely
freaking out, continually dying and re-forking itself, with my
kernel
message buffer filling rapidly + all.log filling. So, there is
further
configuration of this daemon that's needed (meaning it does not work
straight out of the box), and I need those configuration details.
Below is the relevant parts of my config that should get you going:
my /usr/local/etc/cyrus.conf:
START {
# do not delete this entry!
recover cmd=ctl_cyrusdb -r
# this is only necessary if using idled for IMAP IDLE
idled cmd=idled
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=imapd -C /usr/local/etc/imapd.conf listen=imap
prefork=0
# pop3 cmd=pop3d listen=pop3 prefork=0
# pop3scmd=pop3d -s listen=pop3s prefork=0
sieve cmd=timsieved listen=sieve prefork=0
# at least one LMTP is required for delivery
# lmtp cmd=lmtpd listen=lmtp prefork=0
lmtpunix cmd=/usr/local/cyrus/bin/lmtpd
listen=/var/imap/socket/lmtp prefork=0
# this is only necessary if using notifications
notifycmd=notifyd listen=/var/imap/socket/notify
proto=udp prefork=1
}
EVENTS {
# this is required
checkpointcmd=ctl_cyrusdb -c period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd=cyr_expire -E 3 at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd=tls_prune period=1440
}
And /usr/local/etc/imapd.conf
#
# $FreeBSD: ports/mail/cyrus-imapd2/files/imapd.conf,v 1.8 2002/08/08
14:06:48 ume Exp $
#
# Sample configurations file for Cyrus IMAPd
# Most lines in this file are commented; in this case the default is
used.
# The commented lines (usually) contain the default value
configdirectory: /var/imap
partition-default: /usr/local/imap
unixhierarchysep: yes
lmtp_downcase_rcpt: yes
imap_allowanonymouslogin: no
sieve_allowanonymouslogin: no
imap_allowplaintext: no
sieve_allowplaintext: yes
imapidresponse: yes
admins: cyrus toor
autocreatequota: -128
duplicatesuppression: yes
sendmail: /usr/local/sbin/sendmail
postmaster: postmaster
sieve_maxscripts: 15
sasl_maximum_layer: 256
sasl_minimum_layer: 0
sasl_pwcheck_method: saslauthd
sasl_auto_transition: yes
lmtpsocket: /var/imap/socket/lmtp
idlesocket: /var/imap/socket/idle
notifysocket: /var/imap/socket/notify
#
# EOF
In addition, check that you have the following directories created +
run the mkimap for creating the rest of directories/db's
Create the configuration directory specified by the configdirectory
option in imapd.conf. The configuration directory is similar in
concept to the /usr/lib/news directory. It stores information about
the IMAP server as a whole.
This document uses the configuration directory /var/imap in its
examples. This directory should be owned by the cyrus user and group
and should not permit access to other users.
cd /var
mkdir imap
chown cyrus imap
chgrp mail imap
chmod 750 imap
Create the default partition directories specified in the
/etc/imapd.conf file.
This document uses a default partition directory of /var/spool/imap
in the following example:
cd /var/spool
mkdir imap
chown cyrus imap
chgrp mail imap
chmod 750 imap
Change to the Cyrus user and use the tool tools/mkimap to create the
rest of the directories (subdirectories of the directories you just
created).
su cyrus
tools/mkimap
exit
Hope this helps
-Reko
___
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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
void
232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj,
OM_uint32 min)
233 {
234 OM_uint32 major_status, minor_status;
235 OM_uint32 message_content;
236 struct mg_thread_ctx *mg;
237
238 mg = last_error_context;
239
240 gss_release_buffer(minor_status, mg-maj_error);
241 gss_release_buffer(minor_status, mg-min_error);
242
243 mg-mech = m-gm_mech_oid;
244 mg-maj_stat = maj;
when I give following comands, gdb tells me:
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p mg
No symbol mg in current context.
(gdb)
I'm not sure if you're familiar with C or not.
This is because gdb's context is at the wrong frame. In the
backtrace
you provided originally, you'd need to do:
(gdb) frame 2
To look at the variables associated with gss_display_status.c.
last_error_context could be an exported variable (you'd need to look
through the source to find out where it's declared), so you might
have
to print it with its source filename referenced. The print command
I
gave you before (p/x filename.c::variable) didn't work, and that's a
surprise since the gdb documentation I read says it should.
Also be aware that mg is a struct, so p mg won't tell you much,
other
than whether or not it's null. You're probably more interested in
members of the struct, such as mg-maj_error and mg-min_error, and
other struct members.
I gave f 2 before entering the commands above, and unless I'm much
mistaken, 'p mg' should at least give the pointer to the start of the
struct in question, so 'No symbol mg in current context' is mildly
interesting reply from GDB :) If I understand the code in question
right the last_error_context's address should be copied to mg for
accessing the error structure defined elsewhere in the scope of the
while.
the definition is in same file and is as follows:
176 #if defined(__sparc64__) || defined(__arm__) ||
defined(__mips__)
177
178 /*
179 * These platforms don't support TLS on FreeBSD - threads will
just
180 * have to step on each other's error values for now.
181 */
182 #define __thread
183
184 #endif
185
186 struct mg_thread_ctx {
187 gss_OID mech;
188 OM_uint32 maj_stat;
189 OM_uint32 min_stat;
190 gss_buffer_desc maj_error;
191 gss_buffer_desc min_error;
192 };
193 static __thread struct mg_thread_ctx last_error_context
-Reko
___
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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Fri, Jul 16, 2010 at 12:43:22PM +0300, Reko Turja wrote: This doesn't help. The problem is that Cyrus imapd is completely freaking out, continually dying and re-forking itself, with my kernel message buffer filling rapidly + all.log filling. So, there is further configuration of this daemon that's needed (meaning it does not work straight out of the box), and I need those configuration details. Below is the relevant parts of my config that should get you going: [...] Thanks. Most of this worked, except the following: And /usr/local/etc/imapd.conf [...] partition-default: /usr/local/imap [...] Change to the Cyrus user and use the tool tools/mkimap to create the rest of the directories (subdirectories of the directories you just created). su cyrus tools/mkimap exit I changed partition-default to /var/spool/imap, which I think is what was needed, otherwise mkimap complained about being unable to create /usr/local/imap. Also, for the su portion, I had to do: # su cyrus % cd /usr/local/cyrus % bin/mkimap Which worked. I hope this was the right thing to do. However, upon startup, I now see the following in all.log: Jul 16 03:56:12 testbox master[1521]: process started Jul 16 03:56:12 testbox master[1522]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: recovering cyrus databases Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: done recovering cyrus databases Jul 16 03:56:12 testbox master[1523]: about to exec /usr/local/cyrus/bin/idled Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for startup: No such file or directory Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for startup: No such file or directory Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71 Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71 Which is true: testbox# find /usr/local -name idled -follow -ls testbox# I'm not sure if this feature is needed for reproducing the crash, so I modified cyrus.conf and commented the line out, then restarted imapd, which got me: Jul 16 04:00:22 testbox master[1594]: process started Jul 16 04:00:22 testbox master[1595]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: recovering cyrus databases Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed /var/imap/mailboxes.db (0 records, 144 bytes) in 0 seconds Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed /var/imap/annotations.db (0 records, 144 bytes) in 0 seconds Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: done recovering cyrus databases Jul 16 04:00:22 testbox master[1594]: ready for work Jul 16 04:00:22 testbox master[1596]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 04:00:22 testbox master[1597]: about to exec /usr/local/cyrus/bin/notifyd Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: checkpointing cyrus databases Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: /var/imap/annotations.db Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.01 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.01 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: /var/imap/mailboxes.db Jul 16 04:00:22 testbox notify[1597]: executed Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.01 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.01 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: done checkpointing cyrus databases Jul 16 04:00:22 testbox master[1594]: process 1596 exited, status 0 testbox# ps -auxw | grep cyrus cyrus 1594 0.0 0.4 22376 3916 ?? Ss4:00AM 0:00.01 /usr/local/cyrus/bin/master -d cyrus 1597 0.0 0.4 53292 4412 ?? I 4:00AM 0:00.01 notifyd testbox# sockstat -l | grep cyrus cyrusnotifyd1597 4 dgram /var/imap/socket/notify cyrusmaster 1594 7 tcp4 *:143 *:* cyrusmaster 1594 10 tcp4 *:4190*:* cyrusmaster 1594 13 stream /var/imap/socket/lmtp cyrusmaster 1594 16 dgram /var/imap/socket/notify Then for the final test: testbox# cyradm cyradm quit testbox# cyradm localhost Password: Where I hit enter/blank, which got me: Login disabled. cyradm: cannot authenticate to server with as root testbox# And no sign of a crash. So what's next? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Fri, Jul 16, 2010 at 04:04:27AM -0700, Jeremy Chadwick wrote: On Fri, Jul 16, 2010 at 12:43:22PM +0300, Reko Turja wrote: This doesn't help. The problem is that Cyrus imapd is completely freaking out, continually dying and re-forking itself, with my kernel message buffer filling rapidly + all.log filling. So, there is further configuration of this daemon that's needed (meaning it does not work straight out of the box), and I need those configuration details. Below is the relevant parts of my config that should get you going: [...] Thanks. Most of this worked, except the following: And /usr/local/etc/imapd.conf [...] partition-default: /usr/local/imap [...] Change to the Cyrus user and use the tool tools/mkimap to create the rest of the directories (subdirectories of the directories you just created). su cyrus tools/mkimap exit I changed partition-default to /var/spool/imap, which I think is what was needed, otherwise mkimap complained about being unable to create /usr/local/imap. Also, for the su portion, I had to do: # su cyrus % cd /usr/local/cyrus % bin/mkimap Which worked. I hope this was the right thing to do. However, upon startup, I now see the following in all.log: Jul 16 03:56:12 testbox master[1521]: process started Jul 16 03:56:12 testbox master[1522]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: recovering cyrus databases Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: done recovering cyrus databases Jul 16 03:56:12 testbox master[1523]: about to exec /usr/local/cyrus/bin/idled Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for startup: No such file or directory Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for startup: No such file or directory Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71 Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71 Which is true: testbox# find /usr/local -name idled -follow -ls testbox# I'm not sure if this feature is needed for reproducing the crash, so I modified cyrus.conf and commented the line out, then restarted imapd, which got me: Jul 16 04:00:22 testbox master[1594]: process started Jul 16 04:00:22 testbox master[1595]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: recovering cyrus databases Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed /var/imap/mailboxes.db (0 records, 144 bytes) in 0 seconds Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed /var/imap/annotations.db (0 records, 144 bytes) in 0 seconds Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: done recovering cyrus databases Jul 16 04:00:22 testbox master[1594]: ready for work Jul 16 04:00:22 testbox master[1596]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 04:00:22 testbox master[1597]: about to exec /usr/local/cyrus/bin/notifyd Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: checkpointing cyrus databases Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: /var/imap/annotations.db Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.01 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.01 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: /var/imap/mailboxes.db Jul 16 04:00:22 testbox notify[1597]: executed Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.01 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.01 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: done checkpointing cyrus databases Jul 16 04:00:22 testbox master[1594]: process 1596 exited, status 0 testbox# ps -auxw | grep cyrus cyrus 1594 0.0 0.4 22376 3916 ?? Ss4:00AM 0:00.01 /usr/local/cyrus/bin/master -d cyrus 1597 0.0 0.4 53292 4412 ?? I 4:00AM 0:00.01 notifyd testbox# sockstat -l | grep cyrus cyrusnotifyd1597 4 dgram /var/imap/socket/notify cyrusmaster 1594 7 tcp4 *:143 *:* cyrusmaster 1594 10 tcp4 *:4190*:* cyrusmaster 1594 13 stream /var/imap/socket/lmtp cyrusmaster 1594 16 dgram /var/imap/socket/notify Then for the final test: testbox# cyradm cyradm quit testbox# cyradm localhost Password: Where I hit enter/blank, which got me: Login disabled. cyradm: cannot authenticate to server with as root testbox# And no sign of a crash. So what's next? I forgot to check all.log. It contains errors. Hopefully someone will know what to do about this: Jul 16 04:03:50 testbox imap[1619]: executed Jul 16 04:03:50 testbox imap[1619]: accepted connection Jul 16 04:03:50 testbox imap[1619]: OTP
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On 15 July 2010 23:18, Jung-uk Kim j...@freebsd.org wrote: On Thursday 15 July 2010 03:07 pm, Jung-uk Kim wrote: On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: on 15/07/2010 19:57 Oliver Fromme said the following: In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is called. But the cpuid 0xb instruction doesn't seem to return useful data: All values are zero already in the first level, so cpu_cores remains 0. Back in topo_probe(), there is a fallback if cpu_cores is stil 0: It assigns mp_ncpu to cpu_cores, so it gets 8 which is wrong. I patched topo_probe() so it calls topo_probe_0x4() after topo_probe_0xb() if cpu_cores is still 0. I think this is a better fallback procedure. With this patch, cpu_cores gets the value 4 which is the correct one, finally: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) Thank you for debugging this issue! Not sure if this is the best patch that there can be, but its direction is definitely correct. As the Intel document says (translated to our x86 mp_machdep.c terms): if cpu_high = 0xb then we should execute cpuid_count(0xb, 0, p) and examine EBX value (p[1]), only if it's non-zero should we proceed with topo_probe_0xb(), otherwise we should fall back to topo_probe_0x4, etc. I think that your addition achieves this effect, perhaps just not as explicitly as I would preferred. Jung-uk, what do you think? Yes, you're right. Please try new patch: http://people.freebsd.org/~jkim/mp_machdep2.diff I uploaded the patch again, it's compile-tested this now. Just tried with the patch against 8.1-rc2. 2x E5520 - OK, no changes FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads 2x E5440 - now OK FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) 1x 5050 - OK, no changes FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads -- wbr, pluknet ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
Thanks. Most of this worked, except the following: [SNIP] Which worked. I hope this was the right thing to do. My bad there, I was slightly pressed for time and did not check if default cyrus documentation was sane in freebsd context - what you did was quite correct. However, upon startup, I now see the following in all.log: [SNIP] I'm not sure if this feature is needed for reproducing the crash, so I modified cyrus.conf and commented the line out, then restarted imapd, which got me: Yep, idled can be disabled as far as I'm aware, so nothing drastic there either. Then for the final test: testbox# cyradm cyradm quit testbox# cyradm localhost Password: Where I hit enter/blank, which got me: Login disabled. cyradm: cannot authenticate to server with as root testbox# And no sign of a crash. So what's next? I forgot to check all.log. It contains errors. Hopefully someone will know what to do about this: Jul 16 04:03:50 testbox imap[1619]: executed Jul 16 04:03:50 testbox imap[1619]: accepted connection Jul 16 04:03:50 testbox imap[1619]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox imap[1619]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Jul 16 04:03:50 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 04:03:50 testbox perl: DIGEST-MD5 client step 2 Jul 16 04:04:00 testbox imap[1619]: badlogin: localhost [127.0.0.1] DIGEST-MD5 [SASL(-17): One time use of a plaintext password will enable requested mechanism for user: no secret in database] Jul 16 04:04:03 testbox perl: NTLM client step 1 Jul 16 04:04:03 testbox imap[1619]: NTLM server step 1 Jul 16 04:04:03 testbox imap[1619]: client flags: 207 Jul 16 04:04:03 testbox perl: NTLM client step 2 Jul 16 04:04:03 testbox perl: No worthy mechs found Jul 16 04:04:03 testbox kernel: Jul 16 04:04:03 testbox perl: No worthy mechs found You can move the surplus mechs (libopie*, libntlm*) from /usr/local/lib/sasl2 to for example /usr/local/lib/sasl2/disabled check that you have the following in /etc/rc.conf and restart saslauthd afterwards saslauthd_enable=YES saslauthd_flags=-a pam -Reko ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Fri, Jul 16, 2010 at 02:33:17PM +0300, Reko Turja wrote: You can move the surplus mechs (libopie*, libntlm*) from /usr/local/lib/sasl2 to for example /usr/local/lib/sasl2/disabled To deal with this in a more clean manner, I rebuilt security/cyrus-sasl23 with the following OPTIONS unchecked: OTP NTLM check that you have the following in /etc/rc.conf and restart saslauthd afterwards saslauthd_enable=YES saslauthd_flags=-a pam saslauthd isn't in use/installed on this system: testbox# pkg_info cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 protocols cyrus-sasl-2.1.23 RFC SASL (Simple Authentication and Security Layer) db41-4.1.25_4 The Berkeley DB package, revision 4.1 libtool-2.2.6b Generic shared library support script perl-5.10.1_1 Practical Extraction and Report Language portaudit-0.5.15Checks installed ports against a list of security vulnerabi rsync-3.0.7 A network file distribution/synchronization utility vim-lite-7.2.411Vi workalike, with many additional features (Lite package Same situation: testbox# cyradm localhost Password: Login disabled. cyradm: cannot authenticate to server with as root all.log: Jul 16 05:13:19 testbox master[10873]: about to exec /usr/local/cyrus/bin/imapd Jul 16 05:13:19 testbox imap[10873]: executed Jul 16 05:13:19 testbox imap[10873]: accepted connection Jul 16 05:13:19 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 05:13:19 testbox kernel: Jul 16 05:13:19 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 05:13:19 testbox perl: DIGEST-MD5 client step 2 Jul 16 05:13:20 testbox imap[10873]: badlogin: localhost [127.0.0.1] DIGEST-MD5 [SASL(-17): One time use of a plaintext password will enable requested mechanism for user: no secret in database] Jul 16 05:13:23 testbox perl: No worthy mechs found Jul 16 05:13:23 testbox kernel: Jul 16 05:13:23 testbox perl: No worthy mechs found It looks like authentication isn't working, probably because I haven't added any users into the SASL authentication DB. I believe saslauthd can also solve this (allowing use of things like /etc/master.passwd for authentication, as well as other frameworks), but it doesn't look like it's required. When I did make install for security/cyrus-sasl23, I saw this message near the end: You can use sasldb2 for authentication, to add users use: saslpasswd2 -c username So I tried doing exactly that: testbox# saslpasswd2 -c root Password: Again (for verification): testbox# Now let's try cyradm again. Note that at this point I *have not* entered a password below: testbox# cyradm localhost Password: I immediately see this in syslog: Jul 16 05:19:47 testbox imap[10881]: accepted connection Jul 16 05:19:47 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 05:19:47 testbox perl: DIGEST-MD5 client step 2 Now if I enter the correct password, I get a new prompt: localhost And syslog then shows: Jul 16 05:21:06 testbox imap[10881]: IOERROR: opening /var/imap/user_deny.db: No such file or directory Jul 16 05:21:06 testbox perl: DIGEST-MD5 client step 3 Jul 16 05:21:06 testbox imap[10881]: login: localhost [127.0.0.1] root DIGEST-MD5 User logged in Jul 16 05:21:06 testbox imap[10881]: IOERROR: opening /var/imap/user_deny.db: No such file or directory So it looks like SASL-wise things are functioning correctly, but GSSAPI isn't in use (you can see from the error it spits out above). I think we need the OP of the PR[1], Mikhail T., to chime in here with his setup. [1]: http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
I think we need the OP of the PR[1], Mikhail T., to chime in here with his setup. While waiting, can you test the following: In the /usr/local/etc/imapd.conf file comment out #sasl_pwcheck_method: saslauthd and add below it: sasl_mech_list: gssapi pam plain -Reko ___ 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: bgpd tuning
At 05:25 AM 7/16/2010, Cristiano Deana wrote: 30 peering + 1 route server, 320k prefixes, 200M bw. For 8.x, make sure you turn off flowtables. It does not do well with a full view. ---Mike ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Fri, Jul 16, 2010 at 03:58:04PM +0300, Reko Turja wrote: I think we need the OP of the PR[1], Mikhail T., to chime in here with his setup. While waiting, can you test the following: In the /usr/local/etc/imapd.conf file comment out #sasl_pwcheck_method: saslauthd and add below it: sasl_mech_list: gssapi pam plain Thanks -- I did so + restarted imapd, and now we have: testbox# cyradm localhost Login disabled. cyradm: cannot authenticate to server with as root Jul 16 06:46:02 testbox master[11087]: about to exec /usr/local/cyrus/bin/imapd Jul 16 06:46:02 testbox imap[11087]: executed Jul 16 06:46:02 testbox imap[11087]: accepted connection Jul 16 06:46:02 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 06:46:02 testbox perl: No worthy mechs found Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: No worthy mechs found -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: 8.1-PRERELEASE: CPU packages not detected correctly
On Thursday 15 July 2010 09:34 pm, David Xu wrote: Jung-uk Kim wrote: On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote: On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: on 14/07/2010 17:14 Oliver Fromme said the following: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC | 2010 [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz | (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = | 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC |, SE | P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE |, SSE 2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE |3 ,C X16,xTPR,PDCM,DCA,SSE4.1,XSAVE AMD | Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBMSERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a cosmetic issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Could you please try to do the following? 1. Fetch topo-12212009.tar from the top of this page: http://software.intel.com/en-us/articles/intel-64-architecture- pr oc essor-topology-enumeration/ 2. Untar it and apply this patch to the code: http://people.freebsd.org/~avg/cpu-topology.diff 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) 4. Run cpu_topology64.out and report back its output. It's funny that I actually wrote a convenience script (and cleaned up today): http://people.freebsd.org/~jkim/cpu_topology-12212009.sh BTW, current topology detection code is not optimal for some Intel processors if my memory serves. Surprisingly, I found a patch I wrote last year from /tmp of my desktop and it is still applied cleanly. 8-) Just in case, it is available from here: http://people.freebsd.org/~jkim/mp_machdep.diff It is applicable to both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. I have to warn you, though, it hasn't been used for more than a year, so it may not work at all. ;-) Jung-uk Kim Do you have patch for i386 branch ? I want to test. The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. http://people.freebsd.org/~jkim/mp_machdep2.diff On my Pentium-D machine: $ sysctl kern.sched.topology_spec kern.sched.topology_spec: groups group level=1 cache-level=0 cpu count=2 mask=0x30, 1/cpu flags/flags children group level=3 cache-level=2 cpu count=2 mask=0x30, 1/cpu flags/flags /group /children /group /groups it seems the kernel thinks that the Pentuim-D is sharing L2 cache, but in fact, the design of the Pentium Ds was simply two P4 cores sitting side by side. They do not share anything and they basically work independently. cpu_topo() in mp_machdep.c is not that smart to distinguish whether two cores in one package is sharing L2 cache or not: /* * Only HTT no multi-core. */ if (cpu_logical 1 cpu_cores == 1) return (smp_topo_1level(CG_SHARE_L1, cpu_logical, cg_flags)); /* * Only multi-core no HTT. */ if (cpu_cores 1 cpu_logical == 1) return (smp_topo_1level(CG_SHARE_L2, cpu_cores, cg_flags)); /* * Both HTT and multi-core. */ return (smp_topo_2level(CG_SHARE_L2, cpu_cores, CG_SHARE_L1, cpu_logical, cg_flags)); In other words, if one package contains multiple cores, it is *assumed* sharing L2 cache. The same is true for HTT/SMT case (i.e., assumed sharing L1 cache). It does not care about L3 cache at all. Yes, we need some improvement in this area. Jung-uk Kim ___ 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: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 16 July 2010 03:55 am, Jeremy Chadwick wrote: On Thu, Jul 15, 2010 at 10:01:48PM +0200, Oliver Fromme wrote: Jung-uk Kim wrote: On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: on 15/07/2010 19:57 Oliver Fromme said the following: I patched topo_probe() so it calls topo_probe_0x4() after topo_probe_0xb() if cpu_cores is still 0. I think this is a better fallback procedure. With this patch, cpu_cores gets the value 4 which is the correct one, finally: [...] I think that your addition achieves this effect, perhaps just not as explicitly as I would preferred. Jung-uk, what do you think? Yes, you're right. Please try new patch: http://people.freebsd.org/~jkim/mp_machdep2.diff Thank you! I will have access to that particular machine on Monday again, so testing the new patch will have to wait until Monday. But from looking at your patch it should have the same result as my simpler patch, so it should work fine. I have a general question for everyone involved in this thread (which is highly educational/interesting -- thank you for all the info!): Does the problem reported affect actual performance/behaviour of FreeBSD kernel-wise at all, or is it just a cosmetical issue with regards to showing how many cores/threads there are? Theoretically there is behavioral changes from scheduler. jeff@ should be able to tell you more about this. Jung-uk Kim ___ 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: Strange video mode output with VESA
2010/6/19 paradox ddkp...@yahoo.com: On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: Hi there, I was so happy to see that VESA is available for amd64, but unfortunately it does not work really well for me. Take a look at this picture : http://img717.imageshack.us/img717/7311/dsc00399h.jpg My laptop is a 15,6 so the best resolution is 1366x768, I tried this : vidcontrol MODE_496. As you can see on the picture all the lines : are completely everywhere, if I mouse the cursor they move away (I'm not drunk!). I have SC_PIXEL_MODE in my kernel config. The console terminal is okay until I don't excess 1280x960x32 video mode. Do you have any idea to fix this ? It is kinda known problem. If the mode has larger bytes per scan line than the minimum, few characters per line are lost when the screen is scrolled up or down, i.e., framebuffer copies of whole screen. When you move the mouse onto the line, entire line is redrawn and restored. That's what you are seeing. Ed might have a better idea how to fix it (CC'ed). Jung-uk Kim this is incorrent calculate the scan lines in the vesa driver Jung-uk Kim should to fix it But Jung-uk Kim said Ed' should fix it so we are in an infinite loop :- -- Demelier David ___ 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: Strange video mode output with VESA
can you set less resolution? is the same bug? as example MODE_277 need more verbose information On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: Hi there, I was so happy to see that VESA is available for amd64, but unfortunately it does not work really well for me. Take a look at this picture : http://img717.imageshack.us/img717/7311/dsc00399h.jpg My laptop is a 15,6 so the best resolution is 1366x768, I tried this : vidcontrol MODE_496. As you can see on the picture all the lines : are completely everywhere, if I mouse the cursor they move away (I'm not drunk!). I have SC_PIXEL_MODE in my kernel config. The console terminal is okay until I don't excess 1280x960x32 video mode. Do you have any idea to fix this ? It is kinda known problem. If the mode has larger bytes per scan line than the minimum, few characters per line are lost when the screen is scrolled up or down, i.e., framebuffer copies of whole screen. When you move the mouse onto the line, entire line is redrawn and restored. That's what you are seeing. Ed might have a better idea how to fix it (CC'ed). Jung-uk Kim this is incorrent calculate the scan lines in the vesa driver Jung-uk Kim should to fix it But Jung-uk Kim said Ed' should fix it so we are in an infinite loop :- -- Demelier David ___ 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: Strange video mode output with VESA
On Friday 16 July 2010 03:00 pm, David DEMELIER wrote: 2010/6/19 paradox ddkp...@yahoo.com: On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: Hi there, I was so happy to see that VESA is available for amd64, but unfortunately it does not work really well for me. Take a look at this picture : http://img717.imageshack.us/img717/7311/dsc00399h.jpg My laptop is a 15,6 so the best resolution is 1366x768, I tried this : vidcontrol MODE_496. As you can see on the picture all the : lines are completely everywhere, if I mouse the cursor they move away (I'm not drunk!). I have SC_PIXEL_MODE in my kernel config. The console terminal is okay until I don't excess 1280x960x32 video mode. Do you have any idea to fix this ? It is kinda known problem. ��If the mode has larger bytes per scan line than the minimum, few characters per line are lost when the screen is scrolled up or down, i.e., framebuffer copies of whole screen. ��When you move the mouse onto the line, entire line is redrawn and restored. ��That's what you are seeing. ��Ed might have a better idea how to fix it (CC'ed). Jung-uk Kim this is incorrent calculate the scan lines in the vesa driver Jung-uk Kim should to fix it But Jung-uk Kim said Ed' should fix it so we are in an infinite loop :- No, I didn't say that. What I meant was Ed may be a better qualified person to fix syscons vs. terminal emulator interaction issues. :-( Jung-uk Kim ___ 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: Strange video mode output with VESA
On Friday 16 July 2010 03:22 pm, Jung-uk Kim wrote:
On Friday 16 July 2010 03:00 pm, David DEMELIER wrote:
2010/6/19 paradox ddkp...@yahoo.com:
On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote:
Hi there,
I was so happy to see that VESA is available for amd64, but
unfortunately it does not work really well for me. Take a
look at this picture :
http://img717.imageshack.us/img717/7311/dsc00399h.jpg
My laptop is a 15,6 so the best resolution is 1366x768, I
tried this
: vidcontrol MODE_496. As you can see on the picture all the
: lines are
completely everywhere, if I mouse the cursor they move away
(I'm not drunk!).
I have SC_PIXEL_MODE in my kernel config.
The console terminal is okay until I don't excess 1280x960x32
video mode.
Do you have any idea to fix this ?
It is kinda known problem. 占쏙옙If the mode has larger bytes per
scan line than the minimum, few characters per line are lost
when the screen is scrolled up or down, i.e., framebuffer
copies of whole screen. 占쏙옙When you move the mouse onto the
line, entire line is redrawn and restored. 占쏙옙That's what you
are seeing. 占쏙옙Ed might have a better idea how to fix it
(CC'ed).
Jung-uk Kim
this is incorrent calculate the scan lines in the vesa driver
Jung-uk Kim should to fix it
But Jung-uk Kim said Ed' should fix it so we are in an infinite
loop :-
No, I didn't say that. What I meant was Ed may be a better
qualified person to fix syscons vs. terminal emulator interaction
issues. :-(
Can you please try the attached patch?
--- sys/dev/syscons/scvgarndr.c 2010-03-24 11:40:18.0 -0400
+++ sys/dev/syscons/scvgarndr.c 2010-07-16 19:05:12.0 -0400
@@ -728,12 +728,15 @@
vm_offset_t e;
u_char *f;
u_short col1, col2, color;
- int line_width, pixel_size;
+ int line_width, off_width;
+ int font_size, pixel_size;
int i, j, k;
int a;
line_width = scp-sc-adp-va_line_width;
pixel_size = scp-sc-adp-va_info.vi_pixel_size;
+ off_width = line_width - scp-xpixel * pixel_size;
+ font_size = scp-font_size;
d = VIDEO_MEMORY_POS(scp, from, 8 * pixel_size);
@@ -752,9 +755,9 @@
}
e = d;
- f = (scp-font[sc_vtb_getc(scp-vtb, i) * scp-font_size]);
+ f = (scp-font[sc_vtb_getc(scp-vtb, i) * font_size]);
- for (j = 0; j scp-font_size; ++j, ++f) {
+ for (j = 0; j font_size; ++j, ++f) {
for (k = 0; k 8; ++k) {
color = *f (1 (7 - k)) ? col1 : col2;
vga_drawpxl(e + pixel_size * k, color);
@@ -766,8 +769,8 @@
d += 8 * pixel_size;
if ((i % scp-xsize) == scp-xsize - 1)
- d += scp-xoff * 16 * pixel_size +
-(scp-font_size - 1) * line_width;
+ d += off_width + scp-xoff * pixel_size * font_size +
+ (font_size - 1) * line_width;
}
}
___
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
interrupt issues 8_RELENG from two days ago
Hello everyone, having upgraded my laptop to a recent 8_RELENG from an earlier 8_RELENG from the time of the 8.0 release, I find it behaves very strangely. When booting devd hangs often until cancelled with ctrl+c. Sometimes it seems that pending work is waiting for disk activity until it is kicked off. I noticed this when setting up the keycodes for zsh and the duration for reading each key differed significantly depending whether there was disk activity or not. This happens as well in X as in console. I tried disabling powerd, setting kern.hz to 100 and using the timers ACPI- FAST (default), HPET, i8254 and TSC - no change so far. I am not sure if it is because an ancient configuration setting I had in place earlier and that I am missing now or whether this is due to a code change. However, I am at a loss and would appreciate further input on the matter. Due to the upcoming release I am posting to -stable just to get this tracked in case this is the symptom of some obscure bug. Thank you in advance Regards Christof This is vmstat -i: % vmstat -i ~ interrupt total rate irq1: atkbd0 28 0 irq9: acpi0 173 0 irq12: psm0 17 0 irq14: ata0 3009 8 irq16: wpi0 uhci3+ 5516 15 irq18: uhci2 14 0 irq21: fwohci0 2 0 irq22: bfe0 sdhci0 608 1 irq23: uhci0 ehci0 2 0 cpu0: timer18165 51 irq256: hdac0 17 0 cpu1: timer17986 50 Total 45537127 this is dmesg: % dmesg ~ Copyright (c) 1992-2010 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 8.1-PRERELEASE #0: Thu Jul 15 14:29:16 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz (1662.52-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2684354560 (2560 MB) avail memory = 2562097152 (2443 MB) ACPI APIC Table: INTEL CALISTGA FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: PTLTD Capell00 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_ec0: Embedded Controller: GPE 0x17 port 0x62,0x66 on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_acad0: AC Adapter on acpi0 battery0: ACPI Control Method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0x1800-0x1807 mem 0xd810-0xd817,0xc000-0xcfff,0xd820-0xd823 irq 16 at device 2.0 on pci0 agp0: Intel 82945GM (945GM GMCH) SVGA controller on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: VGA-compatible display mem 0xd818-0xd81f at device 2.1 on pci0 hdac0: Intel 82801G High Definition Audio Controller mem 0xd824-0xd8243fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib1 wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xd400-0xd4000fff irq 16 at device 0.0 on pci2 wpi0: Driver Revision 20071127 wpi0: Hardware Revision (0x1) adding chan 1 (2412MHz) flags=0x2b maxpwr=15 passive=0, offset 2 adding chan 2 (2417MHz) flags=0x2b maxpwr=15 passive=0, offset 4 adding chan 3 (2422MHz) flags=0x2b maxpwr=15 passive=0, offset 6 adding chan 4 (2427MHz) flags=0x2b maxpwr=15 passive=0, offset 8 adding chan 5 (2432MHz)
