Re: [RFQ] make witness panic an option
On Thu, Nov 15, 2012 at 7:15 AM, Adrian Chadd wrote: > Hi all, > > When debugging and writing wireless drivers/stack code, I like to > sprinkle lots of locking assertions everywhere. However, this does > cause things to panic quite often during active development. > > This patch (against stable/9) makes the actual panic itself > configurable. It still prints the message regardless. > This has allowed me to sprinkle more locking assertions everywhere to > investigate whether particular paths have been hit or not. I don't > necessarily want those to panic the kernel. > > I'd like everyone to consider this for FreeBSD-HEAD. I really do think that is a very bad idea. When a locking assertion fails you have just to stop your mind and think what's wrong, no way to postpone on this. -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Context Switch
On Thu, Mar 29, 2012 at 7:18 PM, Mahesh Babu wrote: > Which part of the source code in FreeBSD 9 is responsible for making context > switching i.e. storing and restoring the process state. > Context switch is split up in machine indipendent code (MI Code) and machine dependent code (MD Code) For MI part take a look at mi_switch in sys/kern/kern_sync.c sched_switch in sys/kern/sched_ule.c and sys/kern_4bsd.c depending on configurated scheduler in the kernel config file. For MD part search for symbol cpu_switch inside the specific arch directory. -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Per-mount syncer threads and fanout for pagedaemon cleaning
On Mon, Dec 26, 2011 at 9:24 PM, Venkatesh Srinivas wrote: > Hi! > > I've been playing with two things in DragonFly that might be of interest > here. > > Thing #1 := > > First, per-mountpoint syncer threads. Currently there is a single thread, > 'syncer', which periodically calls fsync() on dirty vnodes from every mount, > along with calling vfs_sync() on each filesystem itself (via syncer vnodes). > > My patch modifies this to create syncer threads for mounts that request it. > For these mounts, vnodes are synced from their mount-specific thread rather > than the global syncer. > > The idea is that periodic fsync/sync operations from one filesystem should > not > stall or delay synchronization for other ones. > The patch was fairly simple: > http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/50e4012a4b55e1efc595db0db397b4365f08b640 > There's something WIP by attilio@ on that area. you might want to take a look at http://people.freebsd.org/~attilio/syncer_alpha_15.diff I don't know what hammerfs needs but UFS/FFS and buffer cache make a good job performance-wise and so the authors are skeptical about the boost that such a change can give. We believe that brain cycles need to be spent on other pieces of the system such as ARC and ZFS. -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PANIC: thread_exit: Last thread exiting on its own.
On 03/gen/2011, at 18:23, Lev Serebryakov wrote: Hello, John. You wrote 3 января 2011 г., 19:26:00: I've got this panic on reboot from geom_raid5. Could you please provide some backtrace? Have you got a core? Backtrace was were simple (I've reproduce it from my memory, but it really was that simple): panic() thread_exit() kthread_exit() g_raid5_worker() fork_trampoline() ... No core, because I didn't have dumpdev configured :( Which revision of -STABLE are you running(or when last src update)? uname shows: FreeBSD 8.2-PRERELEASE #2: Tue Dec 21 01:17:16 MSK 2010 I've rebuilt kernel RIGHT after `csup', so difference is no more than several hours. Looks like 204087 needs to be MFC'd. I've looked at this patch, and it seems to be relevant. -- // Black Lion AKA Lev Serebryakov Please, let's us to know if that patch resolve your issue Thank you -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PANIC: thread_exit: Last thread exiting on its own.
2010/12/30 Lev Serebryakov : > Hello, Hackers. > > I've got this panic on reboot from geom_raid5. Could you please provide some backtrace? Have you got a core? Which revision of -STABLE are you running(or when last src update)? Thank you. -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kernel micro-benchmarking framework
Hi all,
based on a work of rwatson@ about micro-benchmarking,
I managed to have a kernel module that exposes some sysctls.
Reading sysctl associated to test start the benchmark and print the results.
The code is split up in this way:
test.h, test.c
where the infrastructure work lives.
test_sync_timing.c
test_mem_timing.c
where the actual micro-benchmarks live:
I wrote some macros to simplify adding more benchmarks. (test.h)
The idea is to have a struct for every benchmark/test
struct timing_proc {
void (*setup)(void *); /* called before
starting timing */
void (*test)(void *); /* what we want
microbenchmark */
void (*tear_down)(void *); /* called after the end of timing */
void *args; /* pointer passed to
the above funcs */
};
and let an agnostic code deals with it.
Every test can specify a setup and tear_down function for
allocate/deallocate resources and a test function to benchmark things.
The great difference with Robert's code is that the test function cannot be
inline as it's a pointer to function. I don't know if that could
influence the results.
The test function is called with interrupt disabled.
We could further extent this framework to add regression test support.
You could get the code here:
http://www.trematerra.net/patches/timing.tbz
Feedback and reviews are welcome.
Thanks
--
Gianni
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: System freezes unexpectly
On Wed, Sep 1, 2010 at 1:29 AM, Davide Italiano wrote: > On 31/08/10 07:53, John Baldwin wrote: >> On Monday, August 30, 2010 12:45:40 pm Garrett Cooper wrote: >> > On Mon, Aug 30, 2010 at 9:24 AM, Davide Italiano >> > wrote: >> > > removing ~/.mozilla works fine. I think that problem's related to >> > > add-on Xmarks I've been installer or to "Restore session" >> > > functionality >> > >> > It would have been interesting to capture what `froze' the machine, in >> > particular because it could have been a valuable bug for either >> > Mozilla to capture and fix, or for us to capture and fix. Unless your >> > machine doesn't meet the hardware requirements, I don't see a reason >> > why a userland application should lock up a system. >> > >> > There are other ways you can debug this further, using -safe-mode as a >> > next step, then choose to not restore the last session (which is >> > available from within the javascript settings file -- nsPrefs.js?). >> >> If only firefox is frozen, then you can always ssh in from another machine >> and >> use top/ps, etc., or even gdb on the firefox process itself. >> >> -- >> John Baldwin >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > I tried to ssh from another machine or ping but I can't perform this > operation (hostname lookup failure). > I also noticed that the cause of the problem is pretty surely Xmarks. So, if > I remove ~/.mozilla firefox3 works again. When I reinstall Xmarks the system > freezes. > Attilio Rao (rookie), an italian kernel developer suggest me to recompile the > kernel using the options, KDB, DDB, GDB, KDB_UNATTENDED (in particular the > last one, that reboot the machine if a panic occurs), but I didn't obtain > nothin' useful, because isn't a panic (the machine doesn't reboot) neither > dmesg is more verbose about the problem. I also tried to recompile firefox > from ports w/ DEBUG flag enable, but I don't see anythin' good launching > firefox from xterm. > If I'm not wrong Xmarks firefox add-on hasn't a native FreeBSD port so perhaps the issue lies into linuxator. -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Panic: sleeping thread
On Tue, Apr 6, 2010 at 9:17 PM, Paul Halliday wrote: > -- Forwarded message -- > From: Paul Halliday > Date: Thu, Apr 1, 2010 at 8:38 AM > Subject: Re: panic: sleeping thread > To: questi...@freebsd.org > > > On Mon, Mar 22, 2010 at 9:28 AM, Paul Halliday > wrote: >> I have a couple VM's that randomly halt with this error: >> >> Sleeping thread (tid 10018, pid 1058) owns a non-sleepable lock >> panic: sleeping thread >> cpuid = 0 >> Uptime 11h14m31s >> Cannot dump. Device not defined or unavailable. >> >> FreeBSD 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC >> 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> These systems run nightly Nessus scans and these halts are very >> sporadic; I can go a week w/o seeing one. >> >> What should I do to start to troubleshoot this? You might want to obtain a kernel dump. Take a look at http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Allocating physical memory without a kernel mapping
On Tue, Mar 2, 2010 at 9:34 AM, Alexander Eichner wrote: > Giovanni Trematerra wrote: >> On Mon, Mar 1, 2010 at 10:59 AM, Alexander Eichner >> wrote: >> > Hi, >> > > > Thanks for your help but I don't see how that patch could help with my > problem. rtR0MemObjNativeAllocPage allocates pages with a kernel > mapping but the problem appears when using rtR0MemObjNativeAllocPhysNC > + rtR0MemObjNativeMapUser and freeing the pages later. > rtR0MemObjNativeAllocPage is used if I use the old allocation mode which > does not use rtR0MemObjNativeAllocPhysNC and this works fine here. > The double wiring problem should also be solved with the latest source. Sorry, the patch was intended *only* as alternative way to resolve double wired paging issue. I don't know if the patch is correct though. Maybe you can attach a textdump of your panic(or at least a bt), that might be useful to understand the problem. Thank you. -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Allocating physical memory without a kernel mapping
On Mon, Mar 1, 2010 at 10:59 AM, Alexander Eichner wrote:
> Hi,
>
> I'm currently trying to finish the R0 memory implementation[1] of FreeBSD for
> VirtualBox. One of the missing methods allocates physical non contiguous
> pages which don't need to have a kernel mapping
> (rtR0MemObjNativeAllocPhysNC). I'm using vm_phys_alloc_contig to achieve
> this. The pages are than mapped into the user space VM process using
> pmap_enter (rtR0MemObjNativeMapUser) and if they are not needed anymore
> vm_page_free_toq is used to free the pages (rtR0MemObjNativeFree).
> Everything works as long as the VM runs but if the VM process terminates and
> I do something else the host will panic at some point (usually when I try to
> start a gnome session) with "pmap_enter: missing reference to page table page
> "[2].
> There seems to some problem with the wire count of that page but I can't see
> what I'm doing wrong at the moment.
> Thanks in advance for any help.
Please, try this patch against revision 26898.
--- memobj-r0drv-freebsd.c.orig 2010-02-26 10:28:44.0 +0100
+++ memobj-r0drv-freebsd.c 2010-02-26 13:55:35.0 +0100
@@ -209,8 +209,7 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
vm_page_t pPage;
pPage = vm_page_alloc(pMemFreeBSD->pObject, PageIndex,
- VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM |
- VM_ALLOC_WIRED);
+ VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM);
#if __FreeBSD_version >= 80 /** @todo Find exact version number */
/* Fixes crashes during VM termination on
FreeBSD8-CURRENT amd64
@@ -220,9 +219,6 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
if (pPage)
{
-vm_page_lock_queues();
-vm_page_wire(pPage);
-vm_page_unlock_queues();
/* Put the page into the page table now. */
#if __FreeBSD_version >= 701105
pmap_enter(kernel_map->pmap, AddressDst,
VM_PROT_NONE, pPage,
@@ -253,6 +249,8 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
if (rc == VINF_SUCCESS)
{
+ vm_map_wire(kernel_map, MapAddress,
MapAddress + cb,
+ VM_MAP_WIRE_SYSTEM |
VM_MAP_WIRE_NOHOLES);
pMemFreeBSD->Core.pv = (void *)MapAddress;
*ppMem = &pMemFreeBSD->Core;
return VINF_SUCCESS;
>
> Regards,
> Alexander Eichner
>
> [1]
> http://www.virtualbox.org/browser/trunk/src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c?rev=26899
> [2]http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c?im=bigexcerpts#L3076
>
> __
> Do You Yahoo!?
> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
> gegen Massenmails.
> http://mail.yahoo.com
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: VirtualBox and vtophys
On Wed, Feb 24, 2010 at 12:41 PM, Jacques Fourie wrote: > I've noticed that my virtualbox vboxdrv.ko started crashing after > updating my 8.0-stable install. The crash occurs when vboxdrv calls > vtophys() on a userland virtual address. Prior to r202894 this was > working fine. Modifying pmap_kextract() to use vtopte() for non-kernel > virtual adresses fixes the problem. Is it intended for vtophys() to > still work on userland virtual addresses? No, vtophys is not intended to be used along with user virtual addresses. -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
