Re: Stale NFS file handles on 8.x amd64
On 11/29/2010 17:06, Adam McDougall wrote: I've been running dovecot 1.1 on FreeBSD 7.x for a while with a bare minimum of NFS problems, but it got worse with 8.x. I have 2-4 servers (usually just 2) accessing mail on a Netapp over NFSv3 via imapd. There are a whole lot more variables that I haven't seen covered yet. Are you using TCP mounts or UDP mounts? Try toggling that setting and see if your performance increases. Are you using rpc.lockd, or not? Try toggling that. What mount options are you using other than TCP/UDP? What does the network topology look like? It's very likely that we can help you here, but more information is needed. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: reboot halts on atom D525
2010/11/29 Xin LI delp...@delphij.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/28/10 23:28, Andrei Kolu wrote: Hi, trouble with rebooting on Intel Atom motherboard D525MWV. -- ... All buffers synced. Uptime 4m 27s. Rebooting... CPU_reset: Stopping other CPUs _ -- System halts completely- no response to CTRL+ALT+DEL. Only way to restart is to press reset or power off. No error messages. Will a sysctl hw.acpi.handle_reboot=1 before rebooting help? No: --- acpi0: reset failed - timeout Rebooting... cpu_reset: Stopping other CPUs --- system halts completely. ___ 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: reboot halts on atom D525
on 30/11/2010 10:55 Andrei Kolu said the following: 2010/11/29 Xin LI delp...@delphij.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/28/10 23:28, Andrei Kolu wrote: Hi, trouble with rebooting on Intel Atom motherboard D525MWV. -- ... All buffers synced. Uptime 4m 27s. Rebooting... CPU_reset: Stopping other CPUs _ -- System halts completely- no response to CTRL+ALT+DEL. Only way to restart is to press reset or power off. No error messages. Will a sysctl hw.acpi.handle_reboot=1 before rebooting help? No: --- acpi0: reset failed - timeout Rebooting... cpu_reset: Stopping other CPUs --- system halts completely. I wonder if it still would be possible to enter DDB at that stage... -- 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: Stale NFS file handles on 8.x amd64
On 11/30/10 02:49, Doug Barton wrote: On 11/29/2010 17:06, Adam McDougall wrote: I've been running dovecot 1.1 on FreeBSD 7.x for a while with a bare minimum of NFS problems, but it got worse with 8.x. I have 2-4 servers (usually just 2) accessing mail on a Netapp over NFSv3 via imapd. There are a whole lot more variables that I haven't seen covered yet. Are you using TCP mounts or UDP mounts? Try toggling that setting and see if your performance increases. Are you using rpc.lockd, or not? Try toggling that. What mount options are you using other than TCP/UDP? What does the network topology look like? It's very likely that we can help you here, but more information is needed. Doug I am using tcp mounts, the mounts in question are either using rw,bg,tcp,nosuid or rw,bg,tcp,noexec in fstab which is what I was using in 7.x except for intr. I'm much more concerned about the corruption rather than the performance at this point but I could try UDP when I get a chance, although I wasn't using it on 7. I am running lockd and statd and was on 7 too. I was using options NFSLOCKD on both 7 and 8. The Netapp I am accessing is on the same local /24 subnet and it does not traverse any firewalls or routers to get there. Two of the four clients are on the same switch as the NFS server, the other two clients are on a different layer 2 switch but same vlan. Today is a bit busy so I may only have time for discussion or simple non-invasive changes during the day but I'll compile a list of suggestions at least. Thanks. ___ 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: Stale NFS file handles on 8.x amd64
I've been running dovecot 1.1 on FreeBSD 7.x for a while with a bare minimum of NFS problems, but it got worse with 8.x. I have 2-4 servers (usually just 2) accessing mail on a Netapp over NFSv3 via imapd. delivery is via procmail which doesn't touch the dovecot metadata and webmail uses imapd. Client connections to imapd go to random servers and I don't yet have solid means to keep certain users on certain servers. I upgraded some of the servers to 8.x and dovecot 1.2 and ran into Stale NFS file handles causing index/uidlist corruption causing inboxes to appear as empty when they were not. In some situations their corrupt index had to be deleted manually. I first suspected dovecot 1.2 since it was upgraded at the same time but I downgraded to 1.1 and its doing the same thing. I don't really have a wealth of details to go on yet and I usually stay quiet until I do, and half the time it is difficult to reproduce myself so I've had to put it in production to get a feel for progress. This only happens a dozen or so times per weekday but I feel the need to start taking bigger steps. I'll probably do what I can to get IMAP back on a stable base (7.x?) and also try to debug 8.x on the remaining servers. A binary search is within possibility if I can reproduce the symptoms often enough even if I have to put a test server in production for a few hours. Any tips on where we could start looking, or alterations I could try making such as sysctls to return to older behavior? It might be worth noting that I've seen a considerable increase in traffic from my mail servers since the 8.x upgrade timeframe, on the order of 5-10x as much traffic to the NFS server. dovecot tries its hardest to flush out the access cache when needed and it was working well enough since about 1.0.16 (years ago). It seems like FreeBSD is what regressed in this scenario. dovecot 2.x is going in a different direction from my situation and I'm not ready to start testing that immediately if I can avoid it as it will involve some restructuring. Thanks for any input. For now the following errors are about all I have to go on: Nov 29 11:07:54 server1 dovecot: IMAP(user1): o_stream_send(/home/user1/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 13:19:51 server1 dovecot: IMAP(user1): o_stream_send(/home/user1/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 14:35:41 server1 dovecot: IMAP(user2): o_stream_send(/home/user2/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 15:07:05 server1 dovecot: IMAP(user3): read(mail, uid=128990) failed: Stale NFS file handle Nov 29 11:57:22 server2 dovecot: IMAP(user4): open(/egr/mail/shared/vprgs/dovecot-acl-list) failed: Stale NFS file handle Nov 29 14:04:22 server2 dovecot: IMAP(user5): o_stream_send(/home/user5/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 14:27:21 server2 dovecot: IMAP(user6): o_stream_send(/home/user6/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 15:44:38 server2 dovecot: IMAP(user7): open(/egr/mail/shared/decs/dovecot-acl-list) failed: Stale NFS file handle Nov 29 19:04:54 server2 dovecot: IMAP(user8): o_stream_send(/home/user8/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 06:32:11 server3 dovecot: IMAP(user9): open(/egr/mail/shared/cmsc/dovecot-acl-list) failed: Stale NFS file handle Nov 29 10:03:58 server3 dovecot: IMAP(user10): o_stream_send(/home/user10/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Others have made good suggestions. One more you could try is disabling the negative name caching by setting the option negnametimeo=0. The addition of negative name caching is also in FreeBSD7, but it is a fairly recent change, so your FreeBSD7 boxes may not have had it. I also think trying the dot-locking and running without statd and lockd (you can mount with the nolock option) would be worth trying. And, of course, disabling attribute caching is mentioned on the web page others cited. Good luck with it, rick ps: Unfortunately the NFS protocol cannot support for POSIX file system semantics, so some apps can never run correctly on NFS mounted volumes. NFSv4 comes closer, but it still can't provide full POSIX semantics. ___ 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: Stale NFS file handles on 8.x amd64
I've been running dovecot 1.1 on FreeBSD 7.x for a while with a bare minimum of NFS problems, but it got worse with 8.x. I have 2-4 servers (usually just 2) accessing mail on a Netapp over NFSv3 via imapd. delivery is via procmail which doesn't touch the dovecot metadata and webmail uses imapd. Client connections to imapd go to random servers and I don't yet have solid means to keep certain users on certain servers. I upgraded some of the servers to 8.x and dovecot 1.2 and ran into Stale NFS file handles causing index/uidlist corruption causing inboxes to appear as empty when they were not. In some situations their corrupt index had to be deleted manually. I first suspected dovecot 1.2 since it was upgraded at the same time but I downgraded to 1.1 and its doing the same thing. I don't really have a wealth of details to go on yet and I usually stay quiet until I do, and half the time it is difficult to reproduce myself so I've had to put it in production to get a feel for progress. This only happens a dozen or so times per weekday but I feel the need to start taking bigger steps. I'll probably do what I can to get IMAP back on a stable base (7.x?) and also try to debug 8.x on the remaining servers. A binary search is within possibility if I can reproduce the symptoms often enough even if I have to put a test server in production for a few hours. Any tips on where we could start looking, or alterations I could try making such as sysctls to return to older behavior? It might be worth noting that I've seen a considerable increase in traffic from my mail servers since the 8.x upgrade timeframe, on the order of 5-10x as much traffic to the NFS server. dovecot tries its hardest to flush out the access cache when needed and it was working well enough since about 1.0.16 (years ago). It seems like FreeBSD is what regressed in this scenario. dovecot 2.x is going in a different direction from my situation and I'm not ready to start testing that immediately if I can avoid it as it will involve some restructuring. Thanks for any input. For now the following errors are about all I have to go on: Nov 29 11:07:54 server1 dovecot: IMAP(user1): o_stream_send(/home/user1/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 13:19:51 server1 dovecot: IMAP(user1): o_stream_send(/home/user1/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 14:35:41 server1 dovecot: IMAP(user2): o_stream_send(/home/user2/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 15:07:05 server1 dovecot: IMAP(user3): read(mail, uid=128990) failed: Stale NFS file handle Nov 29 11:57:22 server2 dovecot: IMAP(user4): open(/egr/mail/shared/vprgs/dovecot-acl-list) failed: Stale NFS file handle Nov 29 14:04:22 server2 dovecot: IMAP(user5): o_stream_send(/home/user5/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 14:27:21 server2 dovecot: IMAP(user6): o_stream_send(/home/user6/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 15:44:38 server2 dovecot: IMAP(user7): open(/egr/mail/shared/decs/dovecot-acl-list) failed: Stale NFS file handle Nov 29 19:04:54 server2 dovecot: IMAP(user8): o_stream_send(/home/user8/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 06:32:11 server3 dovecot: IMAP(user9): open(/egr/mail/shared/cmsc/dovecot-acl-list) failed: Stale NFS file handle Nov 29 10:03:58 server3 dovecot: IMAP(user10): o_stream_send(/home/user10/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Oh, and just in case you weren't aware of it, ESTALE means that the client is trying to access a file that has already been deleted on the server, but I don't think that tells you much w.r.t. how to work around it. The author of dovecot might have more insight into when the above files are being deleted, which might hint at a workaround? rick ___ 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: Stale NFS file handles on 8.x amd64
On Monday, November 29, 2010 8:06:54 pm Adam McDougall wrote: I've been running dovecot 1.1 on FreeBSD 7.x for a while with a bare minimum of NFS problems, but it got worse with 8.x. I have 2-4 servers (usually just 2) accessing mail on a Netapp over NFSv3 via imapd. delivery is via procmail which doesn't touch the dovecot metadata and webmail uses imapd. Client connections to imapd go to random servers and I don't yet have solid means to keep certain users on certain servers. I upgraded some of the servers to 8.x and dovecot 1.2 and ran into Stale NFS file handles causing index/uidlist corruption causing inboxes to appear as empty when they were not. In some situations their corrupt index had to be deleted manually. I first suspected dovecot 1.2 since it was upgraded at the same time but I downgraded to 1.1 and its doing the same thing. I don't really have a wealth of details to go on yet and I usually stay quiet until I do, and half the time it is difficult to reproduce myself so I've had to put it in production to get a feel for progress. This only happens a dozen or so times per weekday but I feel the need to start taking bigger steps. I'll probably do what I can to get IMAP back on a stable base (7.x?) and also try to debug 8.x on the remaining servers. A binary search is within possibility if I can reproduce the symptoms often enough even if I have to put a test server in production for a few hours. There were some changes to allow more concurrency in the NFS client in 8 (and 7.2+) that caused ESTALE errors to occur on open(2) more frequently. You can try setting 'vfs.lookup_shared=0' to disable the extra concurrency (but at a performance cost) as a workaround. The most recent 7.x and 8.x have some changes to open(2) to minimize ESTALE errors that I think get it back to the same level as when lookup_shared is set to 0. -- John Baldwin ___ 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-RELEASE: snd_hda works as module only, suspend/resume leaves display off
Stefan Walter, 15.11.10, 10:37h CET: Audio with snd_hda(4) works, but only if loaded as a module AND only if I load the module AFTER booting. If I compile it into the kernel or add snd_hda_load=YES to /boot/loader.conf, dmesg shows the following: hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC885 pcm1: HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac1 pcm2: HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac1 pcm3: HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac1 mixer(8) shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 There is no audio in that case. Unloading and reloading the module (or just loading the module manually after the boot process) logs: hdac0: ATI SB600 High Definition Audio Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC885 hdac1: ATI (Unknown) High Definition Audio Controller mem 0xfdffc000-0xfdff irq 19 at device 5.1 on pci1 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI RS690/780 HDMI pcm0: HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac0 pcm1: HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac0 pcm2: HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac0 pcm3: HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac1 mixer then shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75 Mixer line is currently set to 75:75 Mixer mic is currently set to 0:0 Mixer mix is currently set to 0:0 Mixer rec is currently set to 75:75 Mixer igainis currently set to 0:0 Audio then seems to work fine. (Plugging earphones into the computer's case's front plugs doesn't do anything, though - audio still comes from the speakers attached to the plug at the back of the case. Any ideas about that?) Loading snd_hda from a startup script would probably work, but I guess that's not the way it was meant to work. Unfortunately, the recent update to 8-STABLE didn't change anything with these problems - any ideas, anyone? Regards, Stefan pgpMTvhWqAOok.pgp Description: PGP signature
Re: 8.1-RELEASE: snd_hda works as module only, suspend/resume leaves display off
On 30.11.2010 22:12, Stefan Walter wrote: Stefan Walter, 15.11.10, 10:37h CET: Audio with snd_hda(4) works, but only if loaded as a module AND only if I load the module AFTER booting. If I compile it into the kernel or add snd_hda_load=YES to /boot/loader.conf, dmesg shows the following: hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0:HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC885 pcm1:HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac1 pcm2:HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac1 pcm3:HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac1 mixer(8) shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 There is no audio in that case. Unloading and reloading the module (or just loading the module manually after the boot process) logs: hdac0:ATI SB600 High Definition Audio Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC885 hdac1:ATI (Unknown) High Definition Audio Controller mem 0xfdffc000-0xfdff irq 19 at device 5.1 on pci1 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI RS690/780 HDMI pcm0:HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac0 pcm1:HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac0 pcm2:HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac0 pcm3:HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac1 mixer then shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75 Mixer line is currently set to 75:75 Mixer mic is currently set to 0:0 Mixer mix is currently set to 0:0 Mixer rec is currently set to 75:75 Mixer igainis currently set to 0:0 Audio then seems to work fine. (Plugging earphones into the computer's case's front plugs doesn't do anything, though - audio still comes from the speakers attached to the plug at the back of the case. Any ideas about that?) Loading snd_hda from a startup script would probably work, but I guess that's not the way it was meant to work. Unfortunately, the recent update to 8-STABLE didn't change anything with these problems - any ideas, anyone? Loading driver aftre boot seems have different device probe order. That causes HDMI HDA codec on video card to be probed either first or second. It is not snd_hda problem and could be handled just by choosing right pcm device to use (possibly via hw.snd.default_unit sysctl). Lack of audio redirection can probably be explained by CODEC configuration made by BIOS. I suppose that front connectors are configured as separate pcm device. -- 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
FreeBSD supported branches update
Hello Everyone, The branches supported by the FreeBSD Security Officer have been updated to reflect the EoL (end-of-life) of FreeBSD 6.4 and FreeBSD 8.0. Since FreeBSD 6.4 was the last remaining supported release from the FreeBSD 6.x stable branch, support for the FreeBSD 6.x stable branch has also ended. The new list of supported branches is below and at http://security.freebsd.org/ . Users of FreeBSD 6.4 and 8.0 are advised to upgrade promptly to a newer release, either by downloading an updated source tree and building updates manually, or (for i386 and amd64 systems) using the FreeBSD Update utility as described in the relevant release announcement. The FreeBSD Ports Management Team wishes to remind users that November 30 is also the end of support for the Ports Collection for both FreeBSD 6.4 RELEASE and the FreeBSD 6.x STABLE branch. Neither the infrastructure nor individual ports are guaranteed to work on these FreeBSD versions after that date. A CVS tag will be created for users who cannot upgrade for some reason, at which time these users are advised to stop tracking the latest ports CVS repository and use the RELEASE_6_EOL tag instead. The current supported branches and expected EoL dates are: +-+ | Branch | Release | Type | Release date | Estimated EoL | |---+++-+-| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |---+++-+-| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |---+++-+-| |RELENG_7_4 |7.4-RELEASE |Extended|not yet |release + 2 years| |---+++-+-| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010|July 31, 2012| |---+++-+-| |RELENG_8_2 |8.2-RELEASE |Normal |not yet |release + 1 year | +-+ ___ 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: Stale NFS file handles on 8.x amd64
On 11/30/10 09:33, John Baldwin wrote: On Monday, November 29, 2010 8:06:54 pm Adam McDougall wrote: I've been running dovecot 1.1 on FreeBSD 7.x for a while with a bare minimum of NFS problems, but it got worse with 8.x. I have 2-4 servers (usually just 2) accessing mail on a Netapp over NFSv3 via imapd. delivery is via procmail which doesn't touch the dovecot metadata and webmail uses imapd. Client connections to imapd go to random servers and I don't yet have solid means to keep certain users on certain servers. I upgraded some of the servers to 8.x and dovecot 1.2 and ran into Stale NFS file handles causing index/uidlist corruption causing inboxes to appear as empty when they were not. In some situations their corrupt index had to be deleted manually. I first suspected dovecot 1.2 since it was upgraded at the same time but I downgraded to 1.1 and its doing the same thing. I don't really have a wealth of details to go on yet and I usually stay quiet until I do, and half the time it is difficult to reproduce myself so I've had to put it in production to get a feel for progress. This only happens a dozen or so times per weekday but I feel the need to start taking bigger steps. I'll probably do what I can to get IMAP back on a stable base (7.x?) and also try to debug 8.x on the remaining servers. A binary search is within possibility if I can reproduce the symptoms often enough even if I have to put a test server in production for a few hours. There were some changes to allow more concurrency in the NFS client in 8 (and 7.2+) that caused ESTALE errors to occur on open(2) more frequently. You can try setting 'vfs.lookup_shared=0' to disable the extra concurrency (but at a performance cost) as a workaround. The most recent 7.x and 8.x have some changes to open(2) to minimize ESTALE errors that I think get it back to the same level as when lookup_shared is set to 0. I tried vfs.lookup_shared=0 on two of the three already with no help (forgot what it was called or I would have mentioned it), and I also tried vfs.nfs.prime_access_cache=1 on a guess on all three but that didn't help either. I'll go through the other suggestions and see where it gets me. Thanks all for the input. ___ 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: Stale NFS file handles on 8.x amd64
On 11/30/10 08:33, Rick Macklem wrote: I've been running dovecot 1.1 on FreeBSD 7.x for a while with a bare minimum of NFS problems, but it got worse with 8.x. I have 2-4 servers (usually just 2) accessing mail on a Netapp over NFSv3 via imapd. delivery is via procmail which doesn't touch the dovecot metadata and webmail uses imapd. Client connections to imapd go to random servers and I don't yet have solid means to keep certain users on certain servers. I upgraded some of the servers to 8.x and dovecot 1.2 and ran into Stale NFS file handles causing index/uidlist corruption causing inboxes to appear as empty when they were not. In some situations their corrupt index had to be deleted manually. I first suspected dovecot 1.2 since it was upgraded at the same time but I downgraded to 1.1 and its doing the same thing. I don't really have a wealth of details to go on yet and I usually stay quiet until I do, and half the time it is difficult to reproduce myself so I've had to put it in production to get a feel for progress. This only happens a dozen or so times per weekday but I feel the need to start taking bigger steps. I'll probably do what I can to get IMAP back on a stable base (7.x?) and also try to debug 8.x on the remaining servers. A binary search is within possibility if I can reproduce the symptoms often enough even if I have to put a test server in production for a few hours. Any tips on where we could start looking, or alterations I could try making such as sysctls to return to older behavior? It might be worth noting that I've seen a considerable increase in traffic from my mail servers since the 8.x upgrade timeframe, on the order of 5-10x as much traffic to the NFS server. dovecot tries its hardest to flush out the access cache when needed and it was working well enough since about 1.0.16 (years ago). It seems like FreeBSD is what regressed in this scenario. dovecot 2.x is going in a different direction from my situation and I'm not ready to start testing that immediately if I can avoid it as it will involve some restructuring. Thanks for any input. For now the following errors are about all I have to go on: Nov 29 11:07:54 server1 dovecot: IMAP(user1): o_stream_send(/home/user1/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 13:19:51 server1 dovecot: IMAP(user1): o_stream_send(/home/user1/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 14:35:41 server1 dovecot: IMAP(user2): o_stream_send(/home/user2/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 15:07:05 server1 dovecot: IMAP(user3): read(mail, uid=128990) failed: Stale NFS file handle Nov 29 11:57:22 server2 dovecot: IMAP(user4): open(/egr/mail/shared/vprgs/dovecot-acl-list) failed: Stale NFS file handle Nov 29 14:04:22 server2 dovecot: IMAP(user5): o_stream_send(/home/user5/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 14:27:21 server2 dovecot: IMAP(user6): o_stream_send(/home/user6/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 15:44:38 server2 dovecot: IMAP(user7): open(/egr/mail/shared/decs/dovecot-acl-list) failed: Stale NFS file handle Nov 29 19:04:54 server2 dovecot: IMAP(user8): o_stream_send(/home/user8/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Nov 29 06:32:11 server3 dovecot: IMAP(user9): open(/egr/mail/shared/cmsc/dovecot-acl-list) failed: Stale NFS file handle Nov 29 10:03:58 server3 dovecot: IMAP(user10): o_stream_send(/home/user10/Maildir/dovecot/private/control/.INBOX/dovecot-uidlist) failed: Stale NFS file handle Others have made good suggestions. One more you could try is disabling the negative name caching by setting the option negnametimeo=0. The addition of negative name caching is also in FreeBSD7, but it is a fairly recent change, so your FreeBSD7 boxes may not have had it. I also think trying the dot-locking and running without statd and lockd (you can mount with the nolock option) would be worth trying. And, of course, disabling attribute caching is mentioned on the web page others cited. Good luck with it, rick ps: Unfortunately the NFS protocol cannot support for POSIX file system semantics, so some apps can never run correctly on NFS mounted volumes. NFSv4 comes closer, but it still can't provide full POSIX semantics. I'll give negnametimeo=0 a try on one server starting tonight, I'll be busy tomorrow and don't want to risk making anything potentially worse than it is yet. I can't figure out how to disable the attr cache in FreeBSD. Neither suggestions seem to be valid, and years ago when I looked into it I got the impression that you can't, but I'd love to be proven wrong. I'll try dotlock when I can. Would disabling statd and lockd be the same as using nolock on all mounts? The vacation binary is the only
Re: 8.1-RELEASE: snd_hda works as module only, suspend/resume leaves display off
Alexander Motin, 30.11.10, 22:07h CET: On 30.11.2010 22:12, Stefan Walter wrote: Stefan Walter, 15.11.10, 10:37h CET: Audio with snd_hda(4) works, but only if loaded as a module AND only if I load the module AFTER booting. If I compile it into the kernel or add snd_hda_load=YES to /boot/loader.conf, dmesg shows the following: hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0:HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC885 pcm1:HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac1 pcm2:HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac1 pcm3:HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac1 mixer(8) shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 There is no audio in that case. Unloading and reloading the module (or just loading the module manually after the boot process) logs: hdac0:ATI SB600 High Definition Audio Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC885 hdac1:ATI (Unknown) High Definition Audio Controller mem 0xfdffc000-0xfdff irq 19 at device 5.1 on pci1 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI RS690/780 HDMI pcm0:HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac0 pcm1:HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac0 pcm2:HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac0 pcm3:HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac1 mixer then shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75 Mixer line is currently set to 75:75 Mixer mic is currently set to 0:0 Mixer mix is currently set to 0:0 Mixer rec is currently set to 75:75 Mixer igainis currently set to 0:0 Audio then seems to work fine. (Plugging earphones into the computer's case's front plugs doesn't do anything, though - audio still comes from the speakers attached to the plug at the back of the case. Any ideas about that?) Loading snd_hda from a startup script would probably work, but I guess that's not the way it was meant to work. Unfortunately, the recent update to 8-STABLE didn't change anything with these problems - any ideas, anyone? Loading driver aftre boot seems have different device probe order. That causes HDMI HDA codec on video card to be probed either first or second. It is not snd_hda problem and could be handled just by choosing right pcm device to use (possibly via hw.snd.default_unit sysctl). Indeed - setting hw.snd.default_unit to 1 helped. Lack of audio redirection can probably be explained by CODEC configuration made by BIOS. I suppose that front connectors are configured as separate pcm device. Ah, OK - seems like you're right again. Setting hw.snd.default_unit to the other analog one directed the sound to the front plugs. Thanks a lot! Regards, Stefan pgpou3WUk7XfU.pgp Description: PGP signature
