Re: No sound after update to RC2 from RC1.
Jakub Lach wrote: I've lost sound. Dmesg content: hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] Starting default moused . mixer: unknown device: mic (or ogain) hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) pcm0: HDA Conexant CX20561 (Hermosa) PCM #0 Analog at cad 0 nid 1 on hdac0 It was previously working with such device.hints: hint.hdac.0.cad0.nid22.config=as=1 hint.hdac.0.cad0.nid26.config=as=1 seq=1 hint.hdac.0.cad0.nid24.config=as=2 hint.hdac.0.cad0.nid29.config=as=2 seq=1 + sysctl.conf dev.pcm.0.play.vchans=0 dev.pcm.0.bitperfect=1 There was no any changes in snd_hda for last two month in RELENG_8 branch. Show me full verbose boot messages and `cat /dev/sndstat`. -- Alexander Motin ___ 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 unstable on freebsd
* Dewayne Geraghty dewayne.gerag...@heuristicsystems.com.au [2009-10-28 19:02:58 +1100]: Alexs, Would you please provide the output to the following two questions: /usr/local/libexec/slapd -V ~]/usr/local/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.19 (Oct 28 2009 09:02:40) $ r...@bazar:/usr/wrkdir/usr/ports/net/openldap24-server/work/openldap-2.4.19/servers/slapd ldd /usr/local/libexec/slapd ~]ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 = /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 = /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 = /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.7.so.0 = /usr/local/lib/libdb-4.7.so.0 (0x800a97000) libssl.so.5 = /usr/lib/libssl.so.5 (0x800cf7000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x800e41000) libfetch.so.5 = /usr/lib/libfetch.so.5 (0x8010d3000) libcom_err.so.4 = /usr/lib/libcom_err.so.4 (0x8011e1000) libcrypt.so.4 = /lib/libcrypt.so.4 (0x8012e3000) libwrap.so.5 = /usr/lib/libwrap.so.5 (0x8013fc000) libthr.so.3 = /lib/libthr.so.3 (0x801505000) libc.so.7 = /lib/libc.so.7 (0x80161d000) It will be helpful to indicate what libraries that you are linking to; and what version are you using. Currently openldap is 2.4.19. Please note that the FreeBSD-stable list will be helpful to you if there are operating system issues. I don't think that you've established an operating system problem with the information provided. You have asked a good question which would trigger responses if other people were experiencing the same problem. Similar to earlier replies, LDAP has been reliable on my 7.2Stable, and I'm tracking 3 days behind cvs. My production machines with openldap, run on average for 600 days without any crashes or reboots; which is what you should expect. Maybe its my mistake in freebsd and openldap configuration. I cant find it long time. Today I tried on netbsd, (there are openldap 2.4.16 in pkgsrc), work perfect! So it work on linux and netbsd, soon i`ll try on solaris. From your description of your problem, you might need to contact the Openldap mailing list; but you'll need more detail. Kind regards, Dewayne. Yes. But thea are strong moderated. I think its my english why moderator rejected me. -- Email: al...@ulgsm.ru Email/Jabber: al...@ulgsm.ru ___ 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.0-RC1 NFS client timeout issue
On Tue 27 Oct 2009 at 18:01:11 +0100, Claus Guttesen wrote: I used nfs with tcp on a 7.2-client without problems on a solaris nfs-server. When I upgraded to RC1 I had 'server not responding - alive again' messages so I swithced to udp which works flawlessly. I haven't had time to investigate it though. Sounds like the same as my problem. I have switched to UDP and so far, with light useage, I have seen no problem. (It would appear with light useage only, anyway). I have looked at some source, but not being an expert on the terrirory, I haven't seen anything obvious yet. Claus -Olaf. -- ___ 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
Next stable version
Hi! Is there any timeline when 8.0 becomes stable to use it in production? Thx Alex Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic. — unknow ___ 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: Next stable version
Hi, according to the schedule, 8.0-RELEASE is a bit delayed. This is quite usual, but epecially for 8.0 there have been a lot of last minute fixes. The main schedule is here: http://www.freebsd.org/releng/index.html#schedule which links to more updated and detailed information in the wiki: http://wiki.freebsd.org/8.0TODO If the schedule is still accurate, looks like release building will start in about a week. Personally, I often wait untill the X.1 or X.2 release before upgrading systems allready in production, unless I need a new feature, but I advise testing the BETA's and RC's prior to release, so you can report bugs/issues to be fixed prior to the RELEASE. Best regards, Daniel Bond. On Oct 28, 2009, at 12:02 PM, Alex Huth wrote: Hi! Is there any timeline when 8.0 becomes stable to use it in production? Thx Alex Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic. — unknow ___ 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 PGP.sig Description: This is a digitally signed message part
Re: Next stable version
* Daniel Bond schrieb: Hi, Personally, I often wait untill the X.1 or X.2 release before upgrading systems allready in production, unless I need a new feature, but I advise testing the BETA's and RC's prior to release, so you can report bugs/issues to be fixed prior to the RELEASE. We actual have 6.4 on our production server. I don't want to upgrade, because i need a different layout. I need the feature to use several IP in a jail. That's why i am waiting for 8.0. But i have the possibillity to build it on a secondary testing system, which will be later the productive system. Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic. — unknow ___ 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: Next stable version
Daniel Bond d...@danielbond.org writes: If the schedule is still accurate, looks like release building will start in about a week. AFAIC RC2 will be out really soon. But due to many fixes it should be stabilized and RC3 will take place before release is done. -- WBR, bsam ___ 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: Next stable version
On Oct 28, 2009, at 1:24 PM, Alex Huth wrote: We actual have 6.4 on our production server. I don't want to upgrade, because i need a different layout. I need the feature to use several IP in a jail. That's why i am waiting for 8.0. But i have the possibillity to build it on a secondary testing system, which will be later the productive system. You could optionally use 7.2-RELEASE also, which was the first release to support for multiple IP4/6 in jail. Best regards, Daniel Bond. PGP.sig Description: This is a digitally signed message part
Re: Next stable version
Alex Huth wrote: * Daniel Bond schrieb: Hi, Personally, I often wait untill the X.1 or X.2 release before upgrading systems allready in production, unless I need a new feature, but I advise testing the BETA's and RC's prior to release, so you can report bugs/issues to be fixed prior to the RELEASE. We actual have 6.4 on our production server. I don't want to upgrade, because i need a different layout. I need the feature to use several IP in a jail. That's why i am waiting for 8.0. But i have the possibillity to build it on a secondary testing system, which will be later the productive system. If you only need jails with several IPs, IPv6 or noIPs, you can go for 7-STABLE. The multi-IP was committed right after the 7.2-RELEASE and I an running it for half a year without any problems + cpuset ability. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Next stable version
On Oct 28, 2009, at 1:54 PM, Miroslav Lachman wrote: If you only need jails with several IPs, IPv6 or noIPs, you can go for 7-STABLE. The multi-IP was committed right after the 7.2-RELEASE and I an running it for half a year without any problems + cpuset ability. It should be included in 7.2-RELEASE, according to announcements and the manual page. - Daniel PGP.sig Description: This is a digitally signed message part
Re: Next stable version
Boris == Boris Samorodov b...@ipt.ru writes: Boris Daniel Bond d...@danielbond.org writes: If the schedule is still accurate, looks like release building will start in about a week. Boris AFAIC RC2 will be out really soon. But due to many fixes it Boris should be stabilized and RC3 will take place before release Boris is done. I've been followying -STABLE and now it is already RC2 as of today. You can give it a csup and take a look. Boris -- WBR, bsam ___ Boris freebsd-stable@freebsd.org mailing list Boris http://lists.freebsd.org/mailman/listinfo/freebsd-stable To Boris unsubscribe, send any mail to Boris freebsd-stable-unsubscr...@freebsd.org -- (dhg) darcsis AT gmail dot COM ___ 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
8.0-RC2 Available
The second of the Release Candidates for the FreeBSD 8.0 release cycle is now available. At this point we feel most of what has been discovered during public testing that is feasible to fix as part of the release process has been addressed. So the current plan is to have 8.0-RC3 in about two weeks. Details about the current target schedule along with much more detail about the current status of the release is available here: http://wiki.freebsd.org/8.0TODO If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is about to become a stable branch but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a memory stick image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages but no other packages. The DVD image includes the packages that will probably be available on the official release media but is subject to change between now and release. For sparc64 there is now a livefs cdrom, disc1 includes the documentation packages, and the DVD image has the set of packages that currently build for sparc64 (which is a sub-set of the set provided for amd64/i386). If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8_0. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, or 8.0-RC1 can upgrade as follows: # freebsd-update upgrade -r 8.0-RC2 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 8.0-RC2: # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC2-amd64-bootonly.iso) = d8b4a402dd510446d7bec239cb2a5add MD5 (8.0-RC2-amd64-disc1.iso) = 74ae55d888589d759339d736db4e4e15 MD5 (8.0-RC2-amd64-dvd1.iso) = c1772eb971b9c451ebbdd9e82b09b7b7 MD5 (8.0-RC2-amd64-livefs.iso) = ef34d58bc1c6c47acb69d8a772de364a MD5 (8.0-RC2-amd64-memstick.img) = 295815f1b358706a8f39f09f3240dde2 MD5 (8.0-RC2-i386-bootonly.iso) = 2d9e62645603a2d284c787f3505060fa MD5 (8.0-RC2-i386-disc1.iso) = 8883ed3b408b67a265d82467d0659ced MD5 (8.0-RC2-i386-dvd1.iso) = 484792f88bae31fca2846bc2a78d8e95 MD5 (8.0-RC2-i386-livefs.iso) = 7053f9ea329d4751c3361112d33b3caa MD5 (8.0-RC2-i386-memstick.img) = b6a703e47e184e2eef63defd60f11abe MD5 (8.0-RC2-ia64-bootonly.iso) = 803d1d48e4a7c52f028cdd9335f63e95 MD5 (8.0-RC2-ia64-disc1.iso) = eb0a6aea681ae605f1a291e17e92342c MD5 (8.0-RC2-ia64-disc2.iso) = 67471992168e3c93095dae45ae0be773 MD5 (8.0-RC2-ia64-disc3.iso) = 6a076b1abda6ff843b8e8745d8068906 MD5 (8.0-RC2-ia64-dvd1.iso) = caf585b43277c22d6b5da1725764eccb MD5 (8.0-RC2-ia64-livefs.iso) = 7c2251519fd99236af1d6bbda2606c3f MD5 (8.0-RC2-pc98-bootonly.iso) = 37bbc89727b0927b8075573133d0fb9f MD5 (8.0-RC2-pc98-disc1.iso) = 0d1f6a48ebcbac485df40f8825d54863 MD5 (8.0-RC2-pc98-livefs.iso) = 018d7f8d716e2a7a53f3263a4debef4d MD5 (8.0-RC2-powerpc-bootonly.iso) = b481aa9d1b66060ae21f427e4aa2a529 MD5 (8.0-RC2-powerpc-disc1.iso) = 0cc7590fe4a0933d54d0deecf9112129 MD5 (8.0-RC2-powerpc-disc2.iso) = e7a89d93be2bc8a69b54558c9d424c5c MD5 (8.0-RC2-powerpc-disc3.iso) = c549a90991122421dcb631d78ab8f312 MD5 (8.0-RC2-sparc64-bootonly.iso) = 3033c3b3c92eec90ad21b772b4ccd970 MD5 (8.0-RC2-sparc64-disc1.iso) = e4b3470481eb94baa2df115b85a23002 MD5 (8.0-RC2-sparc64-dvd1.iso) = a6571c2735c52dc8e5f83384e827c1ff SHA256 (8.0-RC2-amd64-bootonly.iso) =
Re: No sound after update to RC2 from RC1.
Alexander Motin-3 wrote: Jakub Lach wrote: I've lost sound. Dmesg content: hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] Starting default moused . mixer: unknown device: mic (or ogain) hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) pcm0: HDA Conexant CX20561 (Hermosa) PCM #0 Analog at cad 0 nid 1 on hdac0 It was previously working with such device.hints: hint.hdac.0.cad0.nid22.config=as=1 hint.hdac.0.cad0.nid26.config=as=1 seq=1 hint.hdac.0.cad0.nid24.config=as=2 hint.hdac.0.cad0.nid29.config=as=2 seq=1 + sysctl.conf dev.pcm.0.play.vchans=0 dev.pcm.0.bitperfect=1 There was no any changes in snd_hda for last two month in RELENG_8 branch. Show me full verbose boot messages and `cat /dev/sndstat`. -- Alexander Motin ___ 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 Yes, I tried tracing related changes to no avail, furthermore I didn't change anything related in my configuration. Dmesg gives some insight: hdac0: Tracing association 1 (2) hdac0: Unable to trace pin 24 to ADC 20, undo traces hdac0: Pin 24 traced to ADC 21 hdac0: Unable to trace pin 29 to ADC 21, undo traces hdac0: Association 1 (2) trace failed Full dmesg + sndstat http://senduit.com/8fdabe -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26100325.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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.0-RC1 NFS client timeout issue
First off, I know that cross posting is evil, but I wanted to try
and make sure developers saw it.
On Tue, 27 Oct 2009, Olaf Seibert wrote:
I see an annoying behaviour with NFS over TCP. It happens both with nfs
and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is
some Linux or perhaps Solaris, I'm not entirely sure.
After trying to find something in packet traces, I think I have found
something.
The scenario seems to be as follows. Sorry for the width of the lines.
No. TimeSourceDestination Protocol Info
2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142NFS V3
LOOKUP Call (Reply In 2297), DH:0x3819da36/w
2297 2992.217107 xxx.xxx.16.142xxx.xxx.31.43 NFS V3
LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT
2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142NFS V3
LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin
2299 2992.217334 xxx.xxx.16.142xxx.xxx.31.43 NFS V3
LOOKUP Reply (Call In 2298), FH:0x61b8eb12
2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142NFS V3
ACCESS Call (Reply In 2301), FH:0x61b8eb12
2301 2992.217582 xxx.xxx.16.142xxx.xxx.31.43 NFS V3
ACCESS Reply (Call In 2300)
2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142NFS V3
LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w
2303 2992.217860 xxx.xxx.16.142xxx.xxx.31.43 NFS V3
LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT
2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142TCP 934
nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434
2306 3011.537520 xxx.xxx.16.142xxx.xxx.31.43 NFS V3
GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100
2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142TCP 934
nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366
2308 3371.534980 xxx.xxx.16.142xxx.xxx.31.43 TCP nfs
934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662
The server decides, for whatever reason, to terminate the
connection and sends a FIN.
2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142TCP 934
nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366
Client acknowledges this,
2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142NFS V3
ACCESS Call, FH:0x008002a2
but tries to sneak in another call anyway. [A]
Probably not the best behaviour, but I think it is technically allowed by
TCP. (My TCP is very rusty, but I think the socket should be in
TCPS_CLOSE_WAIT at this point and the BSD code will have called
socantrcvmore(), but not socantsndmore().)
2311 3375.474788 xxx.xxx.16.142xxx.xxx.31.43 TCP nfs
934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423
Server ACKs but doesn't send anything else... [B]
Time passes...
This is where it seems interesting. It looks to me like the socket upcall
for receiving the FIN would have happened before this point, setting the
ct_error.re_status to RPC_CANTRECV, but the code in clnt_vc_call() doesn't
check for this. (It does check for it happening during and after the
sosend(), but not before it, from what I can see.)
[B] would be a bug of the server in my opinion. If it ACKs a call, it
should send a reply. And if it can't, it shouldn't.
I'll leave this one for the TCP wizzards. I'm not sure what the
correct behaviour is when data is received on a connection. (I think
it is waiting for a FIN from the client side at this point.)
If you could try the following patch and see if it helps, that would be
appreciated, rick
ps: I'll try to reproduce the situation here, but I'm not sure if I can.
--- rpc/clnt_vc.c.sav 2009-10-28 15:44:20.0 -0400
+++ rpc/clnt_vc.c 2009-10-28 15:49:57.0 -0400
@@ -413,6 +413,19 @@
cr-cr_xid = xid;
mtx_lock(ct-ct_lock);
+ /*
+* Check to see if the other end has already started to close down
+* the connection. If it happens after this point, it will be
+* detected below, when cr-cr_error is checked.
+*/
+ if (ct-ct_error.re_status == RPC_CANTRECV) {
+ if (errp != ct-ct_error) {
+ errp-re_errno = ct-ct_error.re_errno;
+ errp-re_status = RPC_CANTRECV;
+ }
+ stat = RPC_CANTRECV;
+ goto out;
+ }
TAILQ_INSERT_TAIL(ct-ct_pending, cr, cr_link);
mtx_unlock(ct-ct_lock);
___
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
