Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Thu, 3 May 2012 18:53:52 +0200 Bernhard Schmidt bschm...@freebsd.org wrote: Hi folks, As some of you might know there has been some work going on porting support for new Ralink chipsets from OpenBSD. Several different drivers where floating around but nothing seemed to be decent enough to be committed. ray@ and I had been working on cleaning up one of those to get it into a good enough shape, but abandoned this approach as it resulted in more work than starting from scratch. So, attached diff [1] is a from-scratch effort to port over support for the new chipsets. It doesn't contain fancy stuff like 802.11n support as of yet (this will be worked one once the legacy stuff is in HEAD), nonetheless it showed pretty decent performance during the basic sta/adhoc/hostap tests I've done. I'd appreciate testing and feedback ;) at 1st I would say 'Thank You' for all people who working on this :) patch, make, make install, kldload: http://tiger.ipfw.ru/files/rt2860_3090.txt this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012 from time to time on messages: May 5 10:32:47 laptop kernel: ral0: device timeout May 5 10:37:49 laptop kernel: ral0: device timeout May 5 10:42:50 laptop kernel: ral0: device timeout LED... is just glowing, rarely blinks. With patch from Alexander (ray@) it doesn't work [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11% 271MB 1.9MB/s 18:19 ETA ^C Killed by signal 2. where 'tiger' is my desktop The diff requires HEAD due to the firmware being available only there, though, if there are enough requests, I might consider looking into getting it merged to 9. (Simply pulling sys/modules/ralfw/ and sys/contrib/dev/ral/ from HEAD might be enough I guess.) [1] http://techwires.net/~bschmidt/rt2860.diff -- wbr, tiger ___ 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
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote: On Thu, 3 May 2012 18:53:52 +0200 Bernhard Schmidt bschm...@freebsd.org wrote: Hi folks, As some of you might know there has been some work going on porting support for new Ralink chipsets from OpenBSD. Several different drivers where floating around but nothing seemed to be decent enough to be committed. ray@ and I had been working on cleaning up one of those to get it into a good enough shape, but abandoned this approach as it resulted in more work than starting from scratch. So, attached diff [1] is a from-scratch effort to port over support for the new chipsets. It doesn't contain fancy stuff like 802.11n support as of yet (this will be worked one once the legacy stuff is in HEAD), nonetheless it showed pretty decent performance during the basic sta/adhoc/hostap tests I've done. I'd appreciate testing and feedback ;) at 1st I would say 'Thank You' for all people who working on this :) patch, make, make install, kldload: http://tiger.ipfw.ru/files/rt2860_3090.txt this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012 from time to time on messages: May 5 10:32:47 laptop kernel: ral0: device timeout May 5 10:37:49 laptop kernel: ral0: device timeout May 5 10:42:50 laptop kernel: ral0: device timeout That interval is fishy.. can you try do disable bgscan? ifconfig wlan0 -bgscan LED... is just glowing, rarely blinks. With patch from Alexander (ray@) it doesn't work [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11% 271MB 1.9MB/s 18:19 ETA ^C Killed by signal 2. where 'tiger' is my desktop The diff requires HEAD due to the firmware being available only there, though, if there are enough requests, I might consider looking into getting it merged to 9. (Simply pulling sys/modules/ralfw/ and sys/contrib/dev/ral/ from HEAD might be enough I guess.) [1] http://techwires.net/~bschmidt/rt2860.diff -- Bernhard ___ 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
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote:
On Thu, 3 May 2012 18:53:52 +0200
Bernhard Schmidt bschm...@freebsd.org wrote:
Hi folks,
As some of you might know there has been some work going on porting
support for new Ralink chipsets from OpenBSD. Several different
drivers where floating around but nothing seemed to be decent enough
to be committed. ray@ and I had been working on cleaning up one of
those to get it into a good enough shape, but abandoned this approach
as it resulted in more work than starting from scratch.
So, attached diff [1] is a from-scratch effort to port over support
for the new chipsets. It doesn't contain fancy stuff like 802.11n
support as of yet (this will be worked one once the legacy stuff is
in HEAD), nonetheless it showed pretty decent performance during the
basic sta/adhoc/hostap tests I've done.
I'd appreciate testing and feedback ;)
at 1st I would say 'Thank You' for all people who working on this :)
patch, make, make install, kldload:
http://tiger.ipfw.ru/files/rt2860_3090.txt
this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012
from time to time on messages:
May 5 10:32:47 laptop kernel: ral0: device timeout
May 5 10:37:49 laptop kernel: ral0: device timeout
May 5 10:42:50 laptop kernel: ral0: device timeout
LED... is just glowing, rarely blinks. With patch from Alexander (ray@)
it doesn't work
[tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso .
FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11%
271MB 1.9MB/s 18:19 ETA
^C
Killed by signal 2.
where 'tiger' is my desktop
Please apply attached patch (also here [1]) on top of the first one,
it fixes channel switching for = 3070 (called the wrong function,
doh..) as well as a bgscan issue.
[1] http://techwires.net/~bschmidt/rt2860_1.diff
--
Bernhard
Index: sys/dev/ral/rt2860.c
===
--- sys/dev/ral/rt2860.c (revision 234847)
+++ sys/dev/ral/rt2860.c (working copy)
@@ -1605,10 +1605,7 @@ rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni)
ieee80211_radiotap_tx(vap, m);
}
- if (hdrlen 3)
- pad = 4 - (hdrlen 3);
- else
- pad = 0;
+ pad = (hdrlen + 3) ~3;
/* copy and trim 802.11 header */
memcpy(txwi + 1, wh, hdrlen);
@@ -1667,7 +1664,7 @@ rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni)
/* first segment is TXWI + 802.11 header */
txd = ring-txd[ring-cur];
txd-sdp0 = htole32(data-paddr);
- txd-sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen + pad);
+ txd-sdl0 = htole16(sizeof (struct rt2860_txwi) + pad);
txd-flags = qsel;
/* setup payload segments */
@@ -1776,7 +1773,7 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
u_int hdrlen;
uint16_t dur;
uint8_t type, qsel, mcs, pid, tid, qid;
- int i, nsegs, ntxds, rate, ridx, error;
+ int i, nsegs, ntxds, pad, rate, ridx, error;
/* the data pool contains at least one element, pick the first */
data = SLIST_FIRST(sc-data_pool);
@@ -1860,6 +1857,8 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
ieee80211_radiotap_tx(vap, m);
}
+ pad = (hdrlen + 3) ~3;
+
/* copy and trim 802.11 header */
memcpy(txwi + 1, wh, hdrlen);
m_adj(m, hdrlen);
@@ -1917,7 +1916,7 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
/* first segment is TXWI + 802.11 header */
txd = ring-txd[ring-cur];
txd-sdp0 = htole32(data-paddr);
- txd-sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen);
+ txd-sdl0 = htole16(sizeof (struct rt2860_txwi) + pad);
txd-flags = qsel;
/* setup payload segments */
@@ -2336,7 +2335,6 @@ rt2860_scan_start(struct ieee80211com *ic)
tmp ~(RT2860_BCN_TX_EN | RT2860_TSF_TIMER_EN |
RT2860_TBTT_TIMER_EN));
rt2860_set_gp_timer(sc, 0);
- rt2860_set_bssid(sc, ifp-if_broadcastaddr);
}
static void
@@ -2346,10 +2344,10 @@ rt2860_scan_end(struct ieee80211com *ic)
struct rt2860_softc *sc = ifp-if_softc;
struct ieee80211vap *vap = TAILQ_FIRST(ic-ic_vaps);
- rt2860_enable_tsf_sync(sc);
- /* XXX keep local copy */
- rt2860_set_bssid(sc, vap-iv_bss-ni_bssid);
- rt2860_set_gp_timer(sc, 500);
+ if (vap-iv_state == IEEE80211_S_RUN) {
+ rt2860_enable_tsf_sync(sc);
+ rt2860_set_gp_timer(sc, 500);
+ }
}
static void
@@ -2359,7 +2357,7 @@ rt2860_set_channel(struct ieee80211com *ic)
struct rt2860_softc *sc = ifp-if_softc;
RAL_LOCK(sc);
- rt2860_set_chan(sc, ieee80211_chan2ieee(ic, ic-ic_curchan));
+ rt2860_switch_chan(sc, ic-ic_curchan);
RAL_UNLOCK(sc);
}
___
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
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Sat, 5 May 2012 12:51:10 +0200 Bernhard Schmidt bschm...@freebsd.org wrote: On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote: On Thu, 3 May 2012 18:53:52 +0200 Bernhard Schmidt bschm...@freebsd.org wrote: Hi folks, As some of you might know there has been some work going on porting support for new Ralink chipsets from OpenBSD. Several different drivers where floating around but nothing seemed to be decent enough to be committed. ray@ and I had been working on cleaning up one of those to get it into a good enough shape, but abandoned this approach as it resulted in more work than starting from scratch. So, attached diff [1] is a from-scratch effort to port over support for the new chipsets. It doesn't contain fancy stuff like 802.11n support as of yet (this will be worked one once the legacy stuff is in HEAD), nonetheless it showed pretty decent performance during the basic sta/adhoc/hostap tests I've done. I'd appreciate testing and feedback ;) at 1st I would say 'Thank You' for all people who working on this :) patch, make, make install, kldload: http://tiger.ipfw.ru/files/rt2860_3090.txt this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012 from time to time on messages: May 5 10:32:47 laptop kernel: ral0: device timeout May 5 10:37:49 laptop kernel: ral0: device timeout May 5 10:42:50 laptop kernel: ral0: device timeout LED... is just glowing, rarely blinks. With patch from Alexander (ray@) it doesn't work [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11% 271MB 1.9MB/s 18:19 ETA ^C Killed by signal 2. where 'tiger' is my desktop Please apply attached patch (also here [1]) on top of the first one, it fixes channel switching for = 3070 (called the wrong function, doh..) as well as a bgscan issue. [1] http://techwires.net/~bschmidt/rt2860_1.diff * patch applied without errors * build/install - ok kldload and after ~5 minutes: May 5 15:01:20 laptop kernel: ral0: device timeout May 5 15:06:12 laptop kernel: ral0: device timeout without bgscan I didn't see such messages ~30-40 min -- wbr, tiger ___ 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
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Sat, May 5, 2012 at 2:27 PM, Sergey V. Dyatko sergey.dya...@gmail.com wrote: On Sat, 5 May 2012 12:51:10 +0200 Bernhard Schmidt bschm...@freebsd.org wrote: Please apply attached patch (also here [1]) on top of the first one, it fixes channel switching for = 3070 (called the wrong function, doh..) as well as a bgscan issue. [1] http://techwires.net/~bschmidt/rt2860_1.diff * patch applied without errors * build/install - ok kldload and after ~5 minutes: May 5 15:01:20 laptop kernel: ral0: device timeout May 5 15:06:12 laptop kernel: ral0: device timeout without bgscan I didn't see such messages ~30-40 min Ok great, so except bgscan you haven't seen any other issue yet? -- Bernhard ___ 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
OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!
Hello lists.
Since Friday, I have on all of our FreeBSD 10.0-CURRENT/amd64 boxes
massive trouble with net/openldap24-server (SASL enabled, so it is
openldap-sasl-server).
Last time OpenLDAP worked was Thursday last week, when obviously a
problematic update to the OS was made - it is a wild guess, since I did
daily make world and by the end of the day after the last make world
things went worse. I'm sorry having no SVN release tag handy.
Well, here some facts.
1) The update of net/openldap24-server has been performed earlier this
month and has been run successfully (2.4.31).
2) It doesn't matter whether OpenLDAP is compiled with CLANG 3.1 or
legacy GCC 4.2.1, compiled with CLANG, slapd(8C) coredumps immediately,
compiled with gcc, it starts, but when slapd(8C) gets accessed, it
coredumps immediately. A simple id ohartmann is enough.
3) I recompiled OpenLDAP 2.4.31 client and server and it requisites via
portmaster -f net/openldap24-server|client. No effect/success. I also
recompiled every port used with OpenLDAP: security/pam_ldap and
net/nss_ldap.
4) OpenLDAP server uses DB5 based backend.
5) The very same configuration (copied slap.d folder's .ldif files)
works fine on FreeBSD 9.0-STABLE/amd64, even compiled with CLANG. This
makes me believe this is a FreeBSD 10.0-CURRENT specific bug.
6) Following is a truss output of the following comand issued:
/usr/local/libexec/slapd -d32 -o ldap -g ldap -F
/usr/local/etc/openldap/slapd.d :
[...]
connect(8,{ AF_INET 192.168.0.128:389 },16) ERR#61 'Connection refused'
shutdown(8,SHUT_RDWR)ERR#54 'Connection
reset by pee
r'
close(8) = 0 (0x0)
clock_gettime(13,{1336231852.0 })= 0 (0x0)
getpid() = 84297 (0x14949)
sendto(3,163May 5 17:30:52 slapd[84297...,97,0x0,NULL,0x0) = 97 (0x61)
sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGF
PE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|
SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH
|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigaction(SIGPIPE,{ SIG_DFL SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0
(0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
4fa547ac ldif_read_file: checksum error on
/usr/local/etc/openldap/slapd.d//cn=
config/olcDatabase={1}hdb.ldif
4fa547ac hdb_db_open: database dc=walstatt,dc=dyndns,dc=org: unclean
shutdown
detected; attempting recovery.
4fa547ad hdb_db_open: database cn=accesslog: unclean shutdown
detected; attemp
ting recovery.
4fa547ad slapd starting
SIGNAL 11 (SIGSEGV)
setgroups(0x1,0x802c7a000,0x802c7c001,0x,0x0,0x0) ERR#4
'Interrupted sys
tem call'
process exit, rval = 0
7) Desperately, I tried nearly every variation of the configurable
overlays, even those my configuration doesn't use. But this seems
nonesense since OpenLDAP worked before.
I'm floating like a dead man in the water and I was wondering if someone
else doesn't face this problem. FreeBSD is said to be run in large
environments, so at least one should have OpenLDAP as user backend
running ...
I need some help in this case.
Regards,
Oliver
P.S. Please set me CC, I'm not subscribing list questions.
___
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
Re: OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!
On 5 May 2012 16:55, Hartmann, O. ohart...@zedat.fu-berlin.de wrote:
Hello lists.
Since Friday, I have on all of our FreeBSD 10.0-CURRENT/amd64 boxes
massive trouble with net/openldap24-server (SASL enabled, so it is
openldap-sasl-server).
Last time OpenLDAP worked was Thursday last week, when obviously a
problematic update to the OS was made - it is a wild guess, since I did
daily make world and by the end of the day after the last make world
things went worse. I'm sorry having no SVN release tag handy.
Well, here some facts.
1) The update of net/openldap24-server has been performed earlier this
month and has been run successfully (2.4.31).
2) It doesn't matter whether OpenLDAP is compiled with CLANG 3.1 or
legacy GCC 4.2.1, compiled with CLANG, slapd(8C) coredumps immediately,
compiled with gcc, it starts, but when slapd(8C) gets accessed, it
coredumps immediately. A simple id ohartmann is enough.
3) I recompiled OpenLDAP 2.4.31 client and server and it requisites via
portmaster -f net/openldap24-server|client. No effect/success. I also
recompiled every port used with OpenLDAP: security/pam_ldap and
net/nss_ldap.
4) OpenLDAP server uses DB5 based backend.
5) The very same configuration (copied slap.d folder's .ldif files)
works fine on FreeBSD 9.0-STABLE/amd64, even compiled with CLANG. This
makes me believe this is a FreeBSD 10.0-CURRENT specific bug.
6) Following is a truss output of the following comand issued:
/usr/local/libexec/slapd -d32 -o ldap -g ldap -F
/usr/local/etc/openldap/slapd.d :
[...]
connect(8,{ AF_INET 192.168.0.128:389 },16) ERR#61 'Connection
refused'
shutdown(8,SHUT_RDWR)ERR#54 'Connection
reset by pee
r'
close(8) = 0 (0x0)
clock_gettime(13,{1336231852.0 })= 0 (0x0)
getpid() = 84297 (0x14949)
sendto(3,163May 5 17:30:52 slapd[84297...,97,0x0,NULL,0x0) = 97
(0x61)
sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGF
PE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|
SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH
|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigaction(SIGPIPE,{ SIG_DFL SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0
(0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
4fa547ac ldif_read_file: checksum error on
/usr/local/etc/openldap/slapd.d//cn=
config/olcDatabase={1}hdb.ldif
4fa547ac hdb_db_open: database dc=walstatt,dc=dyndns,dc=org: unclean
shutdown
detected; attempting recovery.
4fa547ad hdb_db_open: database cn=accesslog: unclean shutdown
detected; attemp
ting recovery.
4fa547ad slapd starting
SIGNAL 11 (SIGSEGV)
setgroups(0x1,0x802c7a000,0x802c7c001,0x,0x0,0x0) ERR#4
'Interrupted sys
tem call'
process exit, rval = 0
7) Desperately, I tried nearly every variation of the configurable
overlays, even those my configuration doesn't use. But this seems
nonesense since OpenLDAP worked before.
I'm floating like a dead man in the water and I was wondering if someone
else doesn't face this problem. FreeBSD is said to be run in large
environments, so at least one should have OpenLDAP as user backend
running ...
I need some help in this case.
Why are you running -CURRENT in production?
Chris
___
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
Re: OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!
On 05/05/12 18:34, Chris Rees wrote:
On 5 May 2012 16:55, Hartmann, O. ohart...@zedat.fu-berlin.de wrote:
Hello lists.
Since Friday, I have on all of our FreeBSD 10.0-CURRENT/amd64 boxes
massive trouble with net/openldap24-server (SASL enabled, so it is
openldap-sasl-server).
Last time OpenLDAP worked was Thursday last week, when obviously a
problematic update to the OS was made - it is a wild guess, since I did
daily make world and by the end of the day after the last make world
things went worse. I'm sorry having no SVN release tag handy.
Well, here some facts.
1) The update of net/openldap24-server has been performed earlier this
month and has been run successfully (2.4.31).
2) It doesn't matter whether OpenLDAP is compiled with CLANG 3.1 or
legacy GCC 4.2.1, compiled with CLANG, slapd(8C) coredumps immediately,
compiled with gcc, it starts, but when slapd(8C) gets accessed, it
coredumps immediately. A simple id ohartmann is enough.
3) I recompiled OpenLDAP 2.4.31 client and server and it requisites via
portmaster -f net/openldap24-server|client. No effect/success. I also
recompiled every port used with OpenLDAP: security/pam_ldap and
net/nss_ldap.
4) OpenLDAP server uses DB5 based backend.
5) The very same configuration (copied slap.d folder's .ldif files)
works fine on FreeBSD 9.0-STABLE/amd64, even compiled with CLANG. This
makes me believe this is a FreeBSD 10.0-CURRENT specific bug.
6) Following is a truss output of the following comand issued:
/usr/local/libexec/slapd -d32 -o ldap -g ldap -F
/usr/local/etc/openldap/slapd.d :
[...]
connect(8,{ AF_INET 192.168.0.128:389 },16) ERR#61 'Connection
refused'
shutdown(8,SHUT_RDWR)ERR#54 'Connection
reset by pee
r'
close(8) = 0 (0x0)
clock_gettime(13,{1336231852.0 })= 0 (0x0)
getpid() = 84297 (0x14949)
sendto(3,163May 5 17:30:52 slapd[84297...,97,0x0,NULL,0x0) = 97
(0x61)
sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGF
PE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|
SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH
|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigaction(SIGPIPE,{ SIG_DFL SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0
(0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
4fa547ac ldif_read_file: checksum error on
/usr/local/etc/openldap/slapd.d//cn=
config/olcDatabase={1}hdb.ldif
4fa547ac hdb_db_open: database dc=walstatt,dc=dyndns,dc=org: unclean
shutdown
detected; attempting recovery.
4fa547ad hdb_db_open: database cn=accesslog: unclean shutdown
detected; attemp
ting recovery.
4fa547ad slapd starting
SIGNAL 11 (SIGSEGV)
setgroups(0x1,0x802c7a000,0x802c7c001,0x,0x0,0x0) ERR#4
'Interrupted sys
tem call'
process exit, rval = 0
7) Desperately, I tried nearly every variation of the configurable
overlays, even those my configuration doesn't use. But this seems
nonesense since OpenLDAP worked before.
I'm floating like a dead man in the water and I was wondering if someone
else doesn't face this problem. FreeBSD is said to be run in large
environments, so at least one should have OpenLDAP as user backend
running ...
I need some help in this case.
Why are you running -CURRENT in production?
Chris
___
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
Some has to report problems in the field and the new hardware in our
science lab benefits from some advantages in FBSD 10, at least
LLVM/CLANG 3.1.
___
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
Re: make installworld fails
On 05/03/12 20:49, Tim Kientzle wrote: On May 3, 2012, at 1:34 PM, AN wrote: Thu May 3 16:25:27 EDT 2012 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #13 r234872: Tue May 1 13:09:55 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # svn up Updated to revision 234981 I did build world/kernel, after booting into single user mode and trying make installworld I get the following error: /usr/src/Makefile Line:219 check date and time I have seen this failure before, previously I was able to open the make file and comment out the date and time check, but this time the file seems corrupted, I am not able to open the file in vi. What causes this check to fail? Is there any way to detect this possibility before rebboting to single user? Try looking very critically at the system date and time: $ date This check is comparing the system time to the timestamps of the files on disks to try to detect whether your system clock is correct. Since the 'make' program relies on comparing timestamps, you can get very strange results if your system clock is not consistent. You can use the date utility to set the system clock to the approximately correct time (it doesn't need to be very exact). If you have networking, you can use ntpdate pool.ntp.org to set the clock from the network. Tim ___ 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 Did you run adjkerntz -i before mounting disks in single user? Matt ___ 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
ctfmerge core dump
After updating from -CURRENT as of April 5 to one built today, I now get a core dump running ctfmerge on libc: ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So.. Bus error (core dumped) *** [libc.so.7] Error code 138 Anyone else seeing this or have any idea how to avoid it? Let me know if you need more details on my config. Thanks, Steve ___ 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
Re: OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!
On 05/05/12 20:36, Bjoern A. Zeeb wrote: On 5. May 2012, at 15:54 , Hartmann, O. wrote: I'm floating like a dead man in the water and I was wondering if someone else doesn't face this problem. FreeBSD is said to be run in large environments, so at least one should have OpenLDAP as user backend running ... Ok, I am running the same openldap version on HEAD in production on amd64 and i386. My HEAD is from about 20120426 1130 UTC and my packages are cleanly build on that wprld. Here: FreeBSD 10.0-CURRENT #0 r235062: Sat May 5 20:02:26 CEST 2012 I can not say what the last working SVN release tag was, maybe around r234900, I can't say. As I wrote, Thursday last week, ~20120503, a buildworld from 20120502 worked fine. On Thursday 03.05.2012 I did the last source update and buildworld, shutdown the box at home and switched it on on Friday morning before heading to the laboratory - and LDAP failed. At the lab, the box was still working, but I was highly risky in my motivations and recompiled that box with a freshly updates source tree - and it failed, too. I did not follow the tags, sorry. Last I realized flushing into the sources was OpenSSL stuff due to security issues. I use OpenSSL certificates to connect via TLS to the server. There is also usually no core dumped. The differences to what I see with your setups are: 1) I am still on db48. 2) ? Contrary to you I probably have MALLOC_PRODUCTION set for my builds; not sure if that makes a difference but if this problem started recently the jemalloc import could be the cause?You didn't say from when your last and your latest HEAD was. MALLOC_PRODUCTION is set in /etc/make.conf as well as in /etc/src.conf. /etc/src.conf is this on both failing FBSD 10.0-CUR boxes: WITH_CLANG= YES WITH_CLANG_EXTRAS= YES # WITH_BIND_LARGE_FILE= YES WITH_BIND_SIGCHASE= YES WITH_BIND_LIBS= YES # WITH_IDEA= YES WITH_HESIOD=YES # #WITH_BSD_GREP= YES #WITH_ICONV=YES # WITH_LIBCPLUSPLUS= YES # #WITH_OFED= YES # PORTS_MODULES= x11/nvidia-driver # MALLOC_PRODUCTION= YES Grüße, Oliver Gruesse /bz ___ 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
Re: ctfmerge core dump
Steve Wills wrote: After updating from -CURRENT as of April 5 to one built today, I now get a core dump running ctfmerge on libc: ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So.. Bus error (core dumped) *** [libc.so.7] Error code 138 Anyone else seeing this or have any idea how to avoid it? Yes, I'm also seeing such problems when attempting to build a r235052 amd64 kernel on r235035 amd64. (This problem did not occur when building a r235035 amd64 world and kernel on r234854 amd64.) ctfmerge succeeds for several kernel modules but fails with kgssapi.ko.debug, linux.ko.debug, or kernel.debug. I'm not yet sure which change has caused this, or how to avoid it. b. ___ 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
Re: ctfmerge core dump
On 05/05/12 15:43, b. f. wrote: Steve Wills wrote: After updating from -CURRENT as of April 5 to one built today, I now get a core dump running ctfmerge on libc: ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So.. Bus error (core dumped) *** [libc.so.7] Error code 138 Anyone else seeing this or have any idea how to avoid it? Yes, I'm also seeing such problems when attempting to build a r235052 amd64 kernel on r235035 amd64. (This problem did not occur when building a r235035 amd64 world and kernel on r234854 amd64.) ctfmerge succeeds for several kernel modules but fails with kgssapi.ko.debug, linux.ko.debug, or kernel.debug. I'm not yet sure which change has caused this, or how to avoid it. Thanks for the info. I took a look at the dump and see this: % sudo gdb /usr/bin/ctfmerge ctfmerge.core [GDB will not be able to debug user-mode threads: Undefined symbol td_thr_getxmmregs] 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... Core was generated by `ctfmerge'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libctf.so.2...done. Loaded symbols for /lib/libctf.so.2 Reading symbols from /usr/lib/libdwarf.so.3...done. Loaded symbols for /usr/lib/libdwarf.so.3 Reading symbols from /usr/lib/libelf.so.1...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 128 for (i = 0, fn = f-f_head; fn; fn = fn-fn_next, i++); (gdb) bt #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) Not sure what to make of that. Steve ___ 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
Re: ctfmerge core dump
On 5/5/12, Steve Wills swi...@freebsd.org wrote: On 05/05/12 15:43, b. f. wrote: Steve Wills wrote: After updating from -CURRENT as of April 5 to one built today, I now get a core dump running ctfmerge on libc: ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So.. Bus error (core dumped) *** [libc.so.7] Error code 138 Anyone else seeing this or have any idea how to avoid it? Yes, I'm also seeing such problems when attempting to build a r235052 amd64 kernel on r235035 amd64. (This problem did not occur when building a r235035 amd64 world and kernel on r234854 amd64.) ctfmerge succeeds for several kernel modules but fails with kgssapi.ko.debug, linux.ko.debug, or kernel.debug. I'm not yet sure which change has caused this, or how to avoid it. Thanks for the info. I took a look at the dump and see this: % sudo gdb /usr/bin/ctfmerge ctfmerge.core [GDB will not be able to debug user-mode threads: Undefined symbol td_thr_getxmmregs] 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... Core was generated by `ctfmerge'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libctf.so.2...done. Loaded symbols for /lib/libctf.so.2 Reading symbols from /usr/lib/libdwarf.so.3...done. Loaded symbols for /usr/lib/libdwarf.so.3 Reading symbols from /usr/lib/libelf.so.1...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 128 for (i = 0, fn = f-f_head; fn; fn = fn-fn_next, i++); (gdb) bt #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b. ___ 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
Re: ctfmerge core dump
On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@freebsd.org wrote: On 05/05/12 15:43, b. f. wrote: Steve Wills wrote: After updating from -CURRENT as of April 5 to one built today, I now get a core dump running ctfmerge on libc: ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So.. Bus error (core dumped) *** [libc.so.7] Error code 138 Anyone else seeing this or have any idea how to avoid it? Yes, I'm also seeing such problems when attempting to build a r235052 amd64 kernel on r235035 amd64. (This problem did not occur when building a r235035 amd64 world and kernel on r234854 amd64.) ctfmerge succeeds for several kernel modules but fails with kgssapi.ko.debug, linux.ko.debug, or kernel.debug. I'm not yet sure which change has caused this, or how to avoid it. Thanks for the info. I took a look at the dump and see this: % sudo gdb /usr/bin/ctfmerge ctfmerge.core [GDB will not be able to debug user-mode threads: Undefined symbol td_thr_getxmmregs] 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... Core was generated by `ctfmerge'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libctf.so.2...done. Loaded symbols for /lib/libctf.so.2 Reading symbols from /usr/lib/libdwarf.so.3...done. Loaded symbols for /usr/lib/libdwarf.so.3 Reading symbols from /usr/lib/libelf.so.1...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 128 for (i = 0, fn = f-f_head; fn; fn = fn-fn_next, i++); (gdb) bt #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b. I have fixed it in r235068. ___ 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
Re: OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!
On 2012-05-05 17:54, Hartmann, O. wrote:
Since Friday, I have on all of our FreeBSD 10.0-CURRENT/amd64 boxes
massive trouble with net/openldap24-server (SASL enabled, so it is
openldap-sasl-server).
Last time OpenLDAP worked was Thursday last week, when obviously a
problematic update to the OS was made
I managed to reproduce the segfault you are seeing in slapd, which is
caused by a problem in libthr.so, introduced in r234947.
Please apply the attached diff, rebuild lib/libthr and install it, and
then try your slapd tests again. Let us know. :)
@David, can you please review this diff? It looks like there was a
mistake merging from Perforce, where you also moved the line:
sc = SC_LOOKUP(wchan);
to the top of the _sleepq_add() function, just before the call to
_sleepq_lookup(). If this isn't done, sc may be uninitialized when it
is dereferenced later on in the function.
Index: lib/libthr/thread/thr_sleepq.c
===
--- lib/libthr/thread/thr_sleepq.c (revision 234994)
+++ lib/libthr/thread/thr_sleepq.c (working copy)
@@ -113,11 +113,11 @@ _sleepq_add(void *wchan, struct pthread *td)
struct sleepqueue_chain *sc;
struct sleepqueue *sq;
+ sc = SC_LOOKUP(wchan);
sq = _sleepq_lookup(wchan);
if (sq != NULL) {
SLIST_INSERT_HEAD(sq-sq_freeq, td-sleepqueue, sq_flink);
} else {
- sc = SC_LOOKUP(wchan);
sq = td-sleepqueue;
LIST_INSERT_HEAD(sc-sc_queues, sq, sq_hash);
sq-sq_wchan = wchan;
___
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
Re: X220 and all.14.5.patch
Hi, On Saturday 05 May 2012 18:56:33 Lars Engels wrote: On Fri, May 04, 2012 at 06:48:42PM +0700, Erich Dollansky wrote: Hi, one thing I noticed: How does your /etc/make.conf look like? Mine is here: # added by use.perl 2012-05-02 14:49:54 PERL_VERSION=5.12.4 WITH_NEW_XORG ^^^ That doesn't anything as long as you don't set a value. Try WITH_NEW_XORG=true thank you for the hint. Irony is that I am not that far yet. I have a very slow Internet connection here making things not better. Erich ___ 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
Re: X220 and all.14.5.patch
Hi, On Saturday 05 May 2012 04:40:50 matt wrote: On 05/03/12 22:12, Artem Tuchinsky wrote: Is it possibly that the patch got applied twice? I had some errors a not at my side. while back that were resulting from an inconsistent mixture of pre-patch, post-patch and double patched files...I deleted /usr/src and followed the patching instructions after doing a fresh csup. There is also (or was) some sed command that fixes some issues in the files that must not be skipped due to cvs tags. Don't forget to rm /usr/obj. this one? sed -i -e 's/FreeBSD: src.*Exp /FreeBSD/' /usr/src/sys/dev/drm/i915_suspend.c I downloaded a new source tree into an empty directory, applied the patch and get this now: drm_drv.o:(.data+0x100): undefined reference to `drm_gem_close_ioctl' drm_drv.o:(.data+0x118): undefined reference to `drm_gem_flink_ioctl' drm_drv.o:(.data+0x130): undefined reference to `drm_gem_open_ioctl' drm_drv.o:(.data+0x2f8): undefined reference to `drm_setmaster_ioctl' drm_drv.o:(.data+0x310): undefined reference to `drm_dropmaster_ioctl' drm_drv.o:(.data+0xf28): undefined reference to `drm_mode_getresources' drm_drv.o:(.data+0xf40): undefined reference to `drm_mode_getcrtc' drm_drv.o:(.data+0xf58): undefined reference to `drm_mode_setcrtc' drm_drv.o:(.data+0xf70): undefined reference to `drm_mode_cursor_ioctl' drm_drv.o:(.data+0xf88): undefined reference to `drm_mode_gamma_get_ioctl' drm_drv.o:(.data+0xfa0): undefined reference to `drm_mode_gamma_set_ioctl' drm_drv.o:(.data+0xfb8): undefined reference to `drm_mode_getencoder' drm_drv.o:(.data+0xfd0): undefined reference to `drm_mode_getconnector' drm_drv.o:(.data+0xfe8): undefined reference to `drm_mode_attachmode_ioctl' drm_drv.o:(.data+0x1000): undefined reference to `drm_mode_detachmode_ioctl' drm_drv.o:(.data+0x1018): undefined reference to `drm_mode_getproperty_ioctl' drm_drv.o:(.data+0x1030): undefined reference to `drm_mode_connector_property_set_ioctl' drm_drv.o:(.data+0x1048): undefined reference to `drm_mode_getblob_ioctl' drm_drv.o:(.data+0x1060): undefined reference to `drm_mode_getfb' drm_drv.o:(.data+0x1078): undefined reference to `drm_mode_addfb' drm_drv.o:(.data+0x1090): undefined reference to `drm_mode_rmfb' drm_drv.o:(.data+0x10a8): undefined reference to `drm_mode_page_flip_ioctl' drm_drv.o:(.data+0x10c0): undefined reference to `drm_mode_dirtyfb_ioctl' drm_drv.o:(.data+0x10d8): undefined reference to `drm_mode_create_dumb_ioctl' drm_drv.o:(.data+0x10f0): undefined reference to `drm_mode_mmap_dumb_ioctl' drm_drv.o:(.data+0x1108): undefined reference to `drm_mode_destroy_dumb_ioctl' drm_drv.o:(.data+0x1120): undefined reference to `drm_mode_getplane_res' drm_drv.o:(.data+0x1138): undefined reference to `drm_mode_getplane' drm_drv.o:(.data+0x1150): undefined reference to `drm_mode_setplane' drm_drv.o:(.data+0x1168): undefined reference to `drm_mode_addfb2' drm_drv.o:(.data+0x1890): undefined reference to `drm_gem_mmap_single' and many more errors like this. I also did this I get a reject in i915_mem.c. Remove this file, also remove i915_mem.c.rej, i915_mem.c.orig. as stated in the Wiki but then make complains about not finding i915_mem.c. After a touch i915_mem.c, it compiles but does not link. I will investigate further now. Erich ___ 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
Re: X220 and all.14.5.patch
Hi, On Friday 04 May 2012 22:15:44 Artem Tuchinsky wrote: my make.conf: thanks for this. I included most of it into mine. I am still not with a running system. It seems that I miss something very simple. I will redo the whole thing and see what happens then. Erich ___ 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
Re: ctfmerge core dump
On Sat, May 5, 2012 at 7:54 PM, David Xu listlog2...@gmail.com wrote: On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@freebsd.org wrote: On 05/05/12 15:43, b. f. wrote: Steve Wills wrote: After updating from -CURRENT as of April 5 to one built today, I now get a core dump running ctfmerge on libc: ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So.. Bus error (core dumped) *** [libc.so.7] Error code 138 Anyone else seeing this or have any idea how to avoid it? Yes, I'm also seeing such problems when attempting to build a r235052 amd64 kernel on r235035 amd64. (This problem did not occur when building a r235035 amd64 world and kernel on r234854 amd64.) ctfmerge succeeds for several kernel modules but fails with kgssapi.ko.debug, linux.ko.debug, or kernel.debug. I'm not yet sure which change has caused this, or how to avoid it. Thanks for the info. I took a look at the dump and see this: % sudo gdb /usr/bin/ctfmerge ctfmerge.core [GDB will not be able to debug user-mode threads: Undefined symbol td_thr_getxmmregs] 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... Core was generated by `ctfmerge'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libctf.so.2...done. Loaded symbols for /lib/libctf.so.2 Reading symbols from /usr/lib/libdwarf.so.3...done. Loaded symbols for /usr/lib/libdwarf.so.3 Reading symbols from /usr/lib/libelf.so.1...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 128 for (i = 0, fn = f-f_head; fn; fn = fn-fn_next, i++); (gdb) bt #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b. I have fixed it in r235068. hopefully itll fix kernel compilations also halting with signal 10 ___ 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 ___ 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
Re: OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!
On 05/05/12 23:56, Andrzej Tobola wrote:
On Sat, May 05, 2012 at 05:54:50PM +0200, Hartmann, O. wrote:
Hello lists.
Since Friday, I have on all of our FreeBSD 10.0-CURRENT/amd64 boxes
massive trouble with net/openldap24-server (SASL enabled, so it is
openldap-sasl-server).
Last time OpenLDAP worked was Thursday last week, when obviously a
problematic update to the OS was made - it is a wild guess, since I did
daily make world and by the end of the day after the last make world
things went worse. I'm sorry having no SVN release tag handy.
Well, here some facts.
1) The update of net/openldap24-server has been performed earlier this
month and has been run successfully (2.4.31).
2) It doesn't matter whether OpenLDAP is compiled with CLANG 3.1 or
legacy GCC 4.2.1, compiled with CLANG, slapd(8C) coredumps immediately,
compiled with gcc, it starts, but when slapd(8C) gets accessed, it
coredumps immediately. A simple id ohartmann is enough.
3) I recompiled OpenLDAP 2.4.31 client and server and it requisites via
portmaster -f net/openldap24-server|client. No effect/success. I also
recompiled every port used with OpenLDAP: security/pam_ldap and
net/nss_ldap.
4) OpenLDAP server uses DB5 based backend.
5) The very same configuration (copied slap.d folder's .ldif files)
works fine on FreeBSD 9.0-STABLE/amd64, even compiled with CLANG. This
makes me believe this is a FreeBSD 10.0-CURRENT specific bug.
6) Following is a truss output of the following comand issued:
/usr/local/libexec/slapd -d32 -o ldap -g ldap -F
/usr/local/etc/openldap/slapd.d :
[...]
connect(8,{ AF_INET 192.168.0.128:389 },16) ERR#61 'Connection refused'
shutdown(8,SHUT_RDWR)ERR#54 'Connection
reset by pee
r'
close(8) = 0 (0x0)
clock_gettime(13,{1336231852.0 })= 0 (0x0)
getpid() = 84297 (0x14949)
sendto(3,163May 5 17:30:52 slapd[84297...,97,0x0,NULL,0x0) = 97 (0x61)
sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGF
PE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|
SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH
|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigaction(SIGPIPE,{ SIG_DFL SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0
(0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
4fa547ac ldif_read_file: checksum error on
/usr/local/etc/openldap/slapd.d//cn=
config/olcDatabase={1}hdb.ldif
4fa547ac hdb_db_open: database dc=walstatt,dc=dyndns,dc=org: unclean
shutdown
detected; attempting recovery.
4fa547ad hdb_db_open: database cn=accesslog: unclean shutdown
detected; attemp
ting recovery.
4fa547ad slapd starting
SIGNAL 11 (SIGSEGV)
setgroups(0x1,0x802c7a000,0x802c7c001,0x,0x0,0x0) ERR#4
'Interrupted sys
tem call'
process exit, rval = 0
In my case sometimes I needed DB repair:
DBVER=`ldd /usr/local/libexec/slapd | grep libdb | sed
's/.*libdb-\(.*\).so.0 =.*/\1/'` # 4.8 5.1
/usr/local/bin/sudo -u ${slapd_owner%:*} /usr/local/bin/db_recover-$DBVER
-v -h $DATABASEDIR
after not clean shutdwon.
-a
Repair already tried - no effect.
Tried starting with a brand new setup with no effect (empty database
folder).
In times using DB 5, I had lots of problems and broken databases after
unclean shutdowns, but since using DB5, this seems to be gone.
oh
___
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
Re: OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!
On 05/06/12 01:55, Dimitry Andric wrote: On 2012-05-05 17:54, Hartmann, O. wrote: Since Friday, I have on all of our FreeBSD 10.0-CURRENT/amd64 boxes massive trouble with net/openldap24-server (SASL enabled, so it is openldap-sasl-server). Last time OpenLDAP worked was Thursday last week, when obviously a problematic update to the OS was made I managed to reproduce the segfault you are seeing in slapd, which is caused by a problem in libthr.so, introduced in r234947. Please apply the attached diff, rebuild lib/libthr and install it, and then try your slapd tests again. Let us know. :) @David, can you please review this diff? It looks like there was a mistake merging from Perforce, where you also moved the line: sc = SC_LOOKUP(wchan); to the top of the _sleepq_add() function, just before the call to _sleepq_lookup(). If this isn't done, sc may be uninitialized when it is dereferenced later on in the function. Rebuild lib/libthr, installed. Restarted slapd. slapd(8C) now starts as usual and takes queries. BUT: every client using ldap for authetication is now reporting an error like: login: pam_ldap: ldap_starttls_s: Connect error While login on console with LDAP backed users is working although, login with the very same users on xdm fails (replace login with xdm, the error is always the same). I will rebuild a whole system with the patch and report in again, since I rebuilt only libthr and installed the lib, and rebooted in the first approach. oh ___ 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
