Re: Slow shutdown
On Thu, Jun 11, 2015 at 1:55 PM Kevin Oberman wrote: > On Thu, Jun 11, 2015 at 1:50 AM, Ranjan1018 . <21474...@gmail.com> wrote: > > > 2015-05-24 22:33 GMT+02:00 Garrett Cooper : > > > > > On May 24, 2015, at 6:33, Ranjan1018 . <21474...@gmail.com> wrote: > > > > > > > On my laptop running r283297, after the message “All buffers synced.” > > and > > > > before “Uptime: …..” it takes more than 55 seconds. > > > > > > Not a lot of info here to diagnose your issue... > > > - What happens if you hit control-t, i.e. what wait channel does it > print > > > out? > > > - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? > > > - What’s your root media (SSDs, SATA/PATA hard drives, etc)? > > > > > > Thanks.. > > > > > > > Solved ! > > > > The slow shutdown is caused by some remote smbfs shares mounted via > > openvpn: the remote drives are unmounted after the openvpn daemon > > termination, this induces some long timeout. The solution is to unmount > the > > smbfs shares in a shutdown script before the openvpn daemon termination. > I > > have discovered this issue with this ‘dirty’ patch that displays the > > unmounted fs at shutdown: > > > > http://pastebin.com/Xfiz9nsv > > > > With this patch shutting down my laptop appear as: > > > > > > > https://drive.google.com/file/d/0BzoWQoMqq1sfcHZyRnlEeTRobFU/view?usp=sharing > > . > > > > For testing the the patch apply it in /sys/kern, rebuild and install the > > kernel. > > > > Set the new OID: > > > > # sysctl kern.shutdown.show_umountfs=1 > > > > Halt the system: > > > > # shutdown -h now > > > > Regards, > > > > Maurizio > > ___ > > 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" > > > The same issue exists in fusefs, but has an uglier result. The fuse daemon > shuts down before any fusefs based file systems are unmounted, but, for > several R/W file systems including NTFS and exFAT, the result is a corrupt > file system. I did the same thing to work around this problem... an init > script, but I wonder if this should not be handled in some cleaner and more > global manner. (No, I have no idea right now of how to implement this.) > I think that I've hit this problem several times, because I've lost files on my NTFS portable harddisk several times. Now I force an unmount in the shutdown script. I remember that when fuse module was still in fusefs-kmod, the rc script unmounts the file systems, and there's even a _safe flag to ensure safety. -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > ___ > 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: Slow shutdown
On Thu, Jun 11, 2015 at 1:50 AM, Ranjan1018 . <21474...@gmail.com> wrote: > 2015-05-24 22:33 GMT+02:00 Garrett Cooper : > > > On May 24, 2015, at 6:33, Ranjan1018 . <21474...@gmail.com> wrote: > > > > > On my laptop running r283297, after the message “All buffers synced.” > and > > > before “Uptime: …..” it takes more than 55 seconds. > > > > Not a lot of info here to diagnose your issue... > > - What happens if you hit control-t, i.e. what wait channel does it print > > out? > > - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? > > - What’s your root media (SSDs, SATA/PATA hard drives, etc)? > > > > Thanks.. > > > > Solved ! > > The slow shutdown is caused by some remote smbfs shares mounted via > openvpn: the remote drives are unmounted after the openvpn daemon > termination, this induces some long timeout. The solution is to unmount the > smbfs shares in a shutdown script before the openvpn daemon termination. I > have discovered this issue with this ‘dirty’ patch that displays the > unmounted fs at shutdown: > > http://pastebin.com/Xfiz9nsv > > With this patch shutting down my laptop appear as: > > > https://drive.google.com/file/d/0BzoWQoMqq1sfcHZyRnlEeTRobFU/view?usp=sharing > . > > For testing the the patch apply it in /sys/kern, rebuild and install the > kernel. > > Set the new OID: > > # sysctl kern.shutdown.show_umountfs=1 > > Halt the system: > > # shutdown -h now > > Regards, > > Maurizio > ___ > 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" The same issue exists in fusefs, but has an uglier result. The fuse daemon shuts down before any fusefs based file systems are unmounted, but, for several R/W file systems including NTFS and exFAT, the result is a corrupt file system. I did the same thing to work around this problem... an init script, but I wonder if this should not be handled in some cleaner and more global manner. (No, I have no idea right now of how to implement this.) -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: Those at BSDCan 2015: please test: iwn(4) patch to buffer 5ghz frames before transmitting
On 11 June 2015 at 05:03, Poul-Henning Kamp wrote: > > In message > > , Ed Maste writes: > >>I'm running with the patch at BSDCan. Failed to associate several >>times at 5Ghz before settling on channel 11 (2462 MHz 11g ht/20). A >>log with: >> >>wlandebug +assoc +state +rate >>sysctl dev.iwn.0.debug=0x1 > > I have had no luck getting my T430s to associate at 5GHz either, so > much so that I started wondering if I even have 5G antennas in this > laptop or not... > > wn0: mem 0xd1c0-0xd1c01fff irq 17 at > device 0.0 on pci3 > iwn0: iwn_read_firmware: ucode rev=0x12a80601 It's a firmware quirk that the driver never really dealt with right. :( That NIC should be dual-band. Try doing the above debugging (with IEEE80211_DEBUG / IWN_DEBUG compiled in) and let me see what happens. -adrian ___ 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: Those at BSDCan 2015: please test: iwn(4) patch to buffer 5ghz frames before transmitting
In message , Ed Maste writes: >I'm running with the patch at BSDCan. Failed to associate several >times at 5Ghz before settling on channel 11 (2462 MHz 11g ht/20). A >log with: > >wlandebug +assoc +state +rate >sysctl dev.iwn.0.debug=0x1 I have had no luck getting my T430s to associate at 5GHz either, so much so that I started wondering if I even have 5G antennas in this laptop or not... wn0: mem 0xd1c0-0xd1c01fff irq 17 at device 0.0 on pci3 iwn0: iwn_read_firmware: ucode rev=0x12a80601 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: setting tunables in stable/10 vs head?
On 06/10/15 22:13, Rick Macklem wrote: So, is this correct or have I done something stupid? Yes, this is correct. --HPS ___ 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: setting tunables in stable/10 vs head?
On 06/11/15 06:23, hiren panchasara wrote:
On 06/10/15 at 10:07P, Ian Lepore wrote:
On Wed, 2015-06-10 at 20:44 -0700, hiren panchasara wrote:
On 06/10/15 at 04:13P, Rick Macklem wrote:
Hi,
I just MFC'd a patch from head to stable/10 that defines some
tunables using CTLFLAG_RDTUN. Although the MFC didn't break
anything, the tunables don't get changed by the values in /boot/loader.conf.
By applying a patch like this:
SYSCTL_DECL(_vfs_nfsd);
int nfsrv_statehashsize = NFSSTATEHASHSIZE;
+TUNABLE_INT("vfs.nfsd.statehashsize", &nfsrv_statehashsize);
SYSCTL_INT(_vfs_nfsd, OID_AUTO, statehashsize, CTLFLAG_RDTUN,
&nfsrv_statehashsize, 0,
"Size of state hash table set via loader.conf");
they get set ok.
So, is this correct or have I done something stupid?
I believe that is correct. hans changed how they are declared with r267961
and now you do not need TUNABLE_INT() on -head.
And, if it correct, do I commit a patch like the above directly
to stable/10. (It seems that TUNABLE_INT() is discouraged for -head.)
That's the correct way, afaik.
Cheers,
Hiren
Is there a reason the sysctl tunable flag changes can't be MFC'd?
Leaving changes that widespread un-mfc'd just makes for lots of merge
conflicts as time goes on (and can also lead to merged code behaving
differently than expected).
Added Hans to answer the question.
Hi,
I wasn't sure if MFC'ing would break anything with regard to binary
compatibility, so the change was kept in -head and only the broken
SYSCTLs were fixed in 10- and 9- .
--HPS
___
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: Those at BSDCan 2015: please test: iwn(4) patch to buffer 5ghz frames before transmitting
Hi , Thanks. It didn't look like it even attempted to transmit on the 5ghz band at all (no SCAN -> AUTH, then xmit attempts.) -a ___ 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: Pluggable frame buffer devices
Hello I have an AOC e2251fwu monitor which I have used under debian using libdlo with success in the past. I have used the same driver under OpenBSD for testing purpose only with "make check" and it's rendering the test on the attached monitor. I have spend one week and trying to figure out how to make the monitor work under FreeBSD. I have recompile the kernel using you're support for the udl.c and loaded the module in the kernel. kldstat: Id Refs AddressSize Name 41 0x81fd6000 9e20 udl.ko 52 0x81fe 71b0 videomode.ko I have installed the xf86-video-scfb from the ports. And I'm stuck, can't figure out why in the dmsg the adapter is still recognize as a generic usb device shouldn't the drivers kicked in at this point making the monitor available as a framebuffer adapter in /dev ? dmsg | grep DisplayLink ugen2.3: at usbus2 Can you please provide some instructions regarding the steps involved in making this monitor work? Thank you. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Pluggable-frame-buffer-devices-tp5989022p6017846.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: Those at BSDCan 2015: please test: iwn(4) patch to buffer 5ghz frames before transmitting
On 8 June 2015 at 11:29, Adrian Chadd wrote: > Sigh. > > This patch: > > https://people.freebsd.org/~adrian/net80211/20150524-iwn-delay-xmit-passive-1.diff > > along with the latest net80211 tree in -HEAD will buffer frames until > the first beacon is received after association. It doesn't (yet!) > purge frames in all the right places, but it should be enough to at > least get you associated to the 5GHz networks at bsdcan. I'm running with the patch at BSDCan. Failed to associate several times at 5Ghz before settling on channel 11 (2462 MHz 11g ht/20). A log with: wlandebug +assoc +state +rate sysctl dev.iwn.0.debug=0x1 can be found at https://people.freebsd.org/~emaste/logs/wlan-uottawa-5dcaf10a.log. It includes the failed attempts and the final successful association. ___ 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: Slow shutdown
2015-05-24 22:33 GMT+02:00 Garrett Cooper : > On May 24, 2015, at 6:33, Ranjan1018 . <21474...@gmail.com> wrote: > > > On my laptop running r283297, after the message “All buffers synced.” and > > before “Uptime: …..” it takes more than 55 seconds. > > Not a lot of info here to diagnose your issue... > - What happens if you hit control-t, i.e. what wait channel does it print > out? > - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? > - What’s your root media (SSDs, SATA/PATA hard drives, etc)? > > Thanks.. > Solved ! The slow shutdown is caused by some remote smbfs shares mounted via openvpn: the remote drives are unmounted after the openvpn daemon termination, this induces some long timeout. The solution is to unmount the smbfs shares in a shutdown script before the openvpn daemon termination. I have discovered this issue with this ‘dirty’ patch that displays the unmounted fs at shutdown: http://pastebin.com/Xfiz9nsv With this patch shutting down my laptop appear as: https://drive.google.com/file/d/0BzoWQoMqq1sfcHZyRnlEeTRobFU/view?usp=sharing . For testing the the patch apply it in /sys/kern, rebuild and install the kernel. Set the new OID: # sysctl kern.shutdown.show_umountfs=1 Halt the system: # shutdown -h now Regards, Maurizio ___ 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"
