Re: Slow shutdown
2015-06-12 1:13 GMT+02:00 Henry Hu henry.hu...@gmail.com: On Thu, Jun 11, 2015 at 1:55 PM Kevin Oberman rkober...@gmail.com wrote: 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. Hi, I have the same issue in my laptop a dual boot FreeBSD/Windows 8. In FreeBSD, the Win8 partition, is mounted via fusefs and is unmounted in a shutdown script. But if I do not unmount this partition in a script, it is not unmounted by the OS or fusefs at shutdown. Probably this is a different or new bug. For the original bug I have opened a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200784 Please comment here if you like. 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
Re: obtaining a minidump from panic() called from NMI handler
Andriy, i have a question about obtaining minidump as result of panic() being called from nmi handler. basically, i have a way to trigger nmi, and, i would like to panic() system and obtain a minidump. i have modified isa_nmi() to appropriately inspect bits and return non-zero return code. i have turned off machdep.kdb_on_nmi knob (set it to zero). i have confirmed that amd64 trap() is called with correct T_NMI type. i've also confirmed that panic() is called from amd64's trap(). the issue i have is that system is rebooting too early. basically, it looks like minidump is started, but, for whatever reason, other cpus are not completely stopped (or may be they are panic()ing again) and system just reboots without having complete the minidump. the issue is not present when machdep.kdb_on_nmi is set to 1. in this case, system drops into ddb prompt and 'call doadump' works as expected. for various reasons i can not use ddb, and, would like to have system save nmi triggered minidump completely unattended. can someone please give me a clue as to what i should be looking into to make this work? could it be that more than one CPUs get the NMI at the same time? i guess, its possible. is there an easy way to check for that? IF yes, then the current code wouldn't handle that well - each of the NMI-ed CPUs will try to stop all others with another NMI and it will wait until each of those CPUs sets an acknowledgement bit in its NMI handler. This scheme works fine if there's only one CPU that wants to become the master, but results in a deadlock otherwise. that makes sense. i don't observe deadlock, but, simple reboot. thanks, max ___ 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: obtaining a minidump from panic() called from NMI handler
On Fri, Jun 12, 2015 at 11:49:01AM -0700, Maksim Yevmenkin wrote: Andriy, i have a question about obtaining minidump as result of panic() being called from nmi handler. basically, i have a way to trigger nmi, and, i would like to panic() system and obtain a minidump. i have modified isa_nmi() to appropriately inspect bits and return non-zero return code. i have turned off machdep.kdb_on_nmi knob (set it to zero). i have confirmed that amd64 trap() is called with correct T_NMI type. i've also confirmed that panic() is called from amd64's trap(). the issue i have is that system is rebooting too early. basically, it looks like minidump is started, but, for whatever reason, other cpus are not completely stopped (or may be they are panic()ing again) and system just reboots without having complete the minidump. the issue is not present when machdep.kdb_on_nmi is set to 1. in this case, system drops into ddb prompt and 'call doadump' works as expected. for various reasons i can not use ddb, and, would like to have system save nmi triggered minidump completely unattended. can someone please give me a clue as to what i should be looking into to make this work? could it be that more than one CPUs get the NMI at the same time? i guess, its possible. is there an easy way to check for that? IF yes, then the current code wouldn't handle that well - each of the NMI-ed CPUs will try to stop all others with another NMI and it will wait until each of those CPUs sets an acknowledgement bit in its NMI handler. This scheme works fine if there's only one CPU that wants to become the master, but results in a deadlock otherwise. that makes sense. i don't observe deadlock, but, simple reboot. I believe I posted patches to serialize ddb entrance or panics due to nmi. I do not have references handy, you could search lists. ___ 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: obtaining a minidump from panic() called from NMI handler
On Fri, 2015-06-12 at 21:55 +0300, Konstantin Belousov wrote: On Fri, Jun 12, 2015 at 11:49:01AM -0700, Maksim Yevmenkin wrote: Andriy, i have a question about obtaining minidump as result of panic() being called from nmi handler. basically, i have a way to trigger nmi, and, i would like to panic() system and obtain a minidump. i have modified isa_nmi() to appropriately inspect bits and return non-zero return code. i have turned off machdep.kdb_on_nmi knob (set it to zero). i have confirmed that amd64 trap() is called with correct T_NMI type. i've also confirmed that panic() is called from amd64's trap(). the issue i have is that system is rebooting too early. basically, it looks like minidump is started, but, for whatever reason, other cpus are not completely stopped (or may be they are panic()ing again) and system just reboots without having complete the minidump. the issue is not present when machdep.kdb_on_nmi is set to 1. in this case, system drops into ddb prompt and 'call doadump' works as expected. for various reasons i can not use ddb, and, would like to have system save nmi triggered minidump completely unattended. can someone please give me a clue as to what i should be looking into to make this work? could it be that more than one CPUs get the NMI at the same time? i guess, its possible. is there an easy way to check for that? IF yes, then the current code wouldn't handle that well - each of the NMI-ed CPUs will try to stop all others with another NMI and it will wait until each of those CPUs sets an acknowledgement bit in its NMI handler. This scheme works fine if there's only one CPU that wants to become the master, but results in a deadlock otherwise. that makes sense. i don't observe deadlock, but, simple reboot. I believe I posted patches to serialize ddb entrance or panics due to nmi. I do not have references handy, you could search lists. ___ 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 That was on freebsd-arch in July 2014. -- Ian ___ 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: obtaining a minidump from panic() called from NMI handler
On 10/06/2015 20:36, Maksim Yevmenkin wrote: hello, i have a question about obtaining minidump as result of panic() being called from nmi handler. basically, i have a way to trigger nmi, and, i would like to panic() system and obtain a minidump. i have modified isa_nmi() to appropriately inspect bits and return non-zero return code. i have turned off machdep.kdb_on_nmi knob (set it to zero). i have confirmed that amd64 trap() is called with correct T_NMI type. i've also confirmed that panic() is called from amd64's trap(). the issue i have is that system is rebooting too early. basically, it looks like minidump is started, but, for whatever reason, other cpus are not completely stopped (or may be they are panic()ing again) and system just reboots without having complete the minidump. the issue is not present when machdep.kdb_on_nmi is set to 1. in this case, system drops into ddb prompt and 'call doadump' works as expected. for various reasons i can not use ddb, and, would like to have system save nmi triggered minidump completely unattended. can someone please give me a clue as to what i should be looking into to make this work? Maksim, could it be that more than one CPUs get the NMI at the same time? IF yes, then the current code wouldn't handle that well - each of the NMI-ed CPUs will try to stop all others with another NMI and it will wait until each of those CPUs sets an acknowledgement bit in its NMI handler. This scheme works fine if there's only one CPU that wants to become the master, but results in a deadlock otherwise. -- Andriy Gapon ___ 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: bug with special bracket expressions in regular expressions
On 02/09/2013 19:45, Andriy Gapon wrote: It seems that the code works like this: - first it matches cd0 and removes it - then it passes cd1 xx for matching with a flag that tells that this is not a real start of the string - thus the matching code o knows that this is not a real line start, so it can't match [[::]] just for that reason o it does _not_ know what was the character before the start of the given substring, so it can not know if it could match [[::]] So matching fails. Not sure if this is an internal problem of regex(3) or a problem of how sed(1) uses regex(3). I've come up with a patch to fix this problem: https://reviews.freebsd.org/D2792 I am not sure who among the developers is interested in the regexp code, so currently the request does not have any reviewers. If know that code well or care about its correctness please add yourself ti the review request. All testers are welcome. The issue could be quite an edge case, but I am more interested to see if no regressions are introduced. Thanks. -- Andriy Gapon ___ 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
