Hi,
Does freebsd have some functionality similar to Linux's NMI watchdog ? I'm
aware of ichwd driver, but that depends to WDT to be available in the hardware.
Even when it is available, BIOS needs to support a mechanism to trigger a OS
level recovery to get any useful information when system i
Basically I would like to get kernel backtrace of a bunch of threads from the
live kernel under some conditions. When the condition is seen I would like to
run kgdb, collect kernel backtrace of specific threads and exit. Is there a way
run kgdb in batch mode ? Or any other way to get the stack t
Is there a equivalent of Linux "Leases" functionality in FreeBSD ? If not, are
there any plans of adding it in the future release?
Thanks,
Sushanth
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To
--- On Mon, 11/12/12, Alan Cox wrote:
> From: Alan Cox
> Subject: Re: Memory reserves or lack thereof
> To: "Konstantin Belousov"
> Cc: "Sushanth Rai" , a...@freebsd.org,
> p...@freebsd.org, "StevenSears" ,
> "freebsd-hackers@freebsd.org
This patch still doesn't address the issue of M_NOWAIT calls driving the memory
the all the way down to 2 pages, right ? It would be nice to have M_NOWAIT just
do non-sleep version of M_WAITOK and M_USE_RESERVE flag to dig deep.
Sushanth
--- On Mon, 11/12/12, Konstantin Belousov wrote:
> Fr
I was trying to co-relate the o/p from "top" to that I get from vmstat -z. I
don't have any user programs that wires memory. Given that, I'm assuming the
wired memory count shown by "top" is memory used by kernel. Now I would like
find out how the kernel is using this "wired" memory. So, I look
which cannot
reclaimed even when the system is under memory pressure.
Sushanth
--- On Mon, 4/16/12, Sushanth Rai wrote:
> From: Sushanth Rai
> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
> To: "Konstantin Belousov"
> Cc: a...@freebsd.org, freebsd-hack
Many thanks. I verified the patch you provided and it works fine.
Sushanth
> Oh, I see. The problem is the VM_MAP_WIRE_NOHOLES flag.
> Since we
> map only the initial stack fragment even for the
> MCL_WIREFUTURE maps,
> there is a hole in the stack region.
>
> In fact, for MCL_WIREFUTURE, we pr
sleep(5);
}
}
--- On Fri, 4/13/12, Sushanth Rai wrote:
> From: Sushanth Rai
> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
> To: "Konstantin Belousov"
> Cc: freebsd-hackers@freebsd.org
> Date: Friday, April 13, 2012, 11:37 AM
>
W NNC
wired default -
--- On Fri, 4/13/12, Konstantin Belousov wrote:
> From: Konstantin Belousov
> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
> To: "Sushanth Rai"
> Cc: freebsd-hackers@freebsd.org
> Date: Friday, April 13, 2012, 1:11 AM
> O
>
> Then it should be fixed in r190885.
>
Thanks. That works like a charm.
mlockall() mostly works now. There is still a, issue in wiring the stacks of
multithreaded program when the program uses default stack allocation scheme.
Thread library allocates stack for each thread by calling mmap(
> > I don't know if that has anything to do with failure.
> The snippet of code that returns failure in vm_fault() is
> the following:
> >
> > if (fs.pindex >= fs.object->size) {
> >
> unlock_and_deallocate(&fs);
> > return
> (KERN_PROTECTION_FAILURE);
> > }
> >
> > Any help would be
Thanks. I'll try to back port locally.
Sushanth
--- On Tue, 4/10/12, John Baldwin wrote:
> From: John Baldwin
> Subject: Re: Startvation of realtime piority threads
> To: "Sushanth Rai"
> Cc: freebsd-hackers@freebsd.org
> Date: Tuesday, April 10, 2012, 6:57 AM
Hello,
I have a simple program that links with the math library. The only thing that
program does is to call mlockall(MCL_CURRENT | MCL_FUTURE). This call to
mlockall fails with EAGAIN. I figured out that kernel vm_fault() is returning
KERN_PROTECTION_FAILURE when it tries to fault-in the mmap'
which explicitly sleeps at PUSER.
Sushanth
--- On Mon, 4/9/12, John Baldwin wrote:
> From: John Baldwin
> Subject: Re: Startvation of realtime piority threads
> To: "Sushanth Rai"
> Cc: freebsd-hackers@freebsd.org
> Date: Monday, April 9, 2012, 11:37 AM
> On
I'm on 7.2. sched_sleep() on 7.2 just records the sleep time. That's why I
though _sleep might the right place to do the check.
Thanks,
Sushanth
--- On Mon, 4/9/12, John Baldwin wrote:
> From: John Baldwin
> Subject: Re: Startvation of realtime piority threads
> To: &
AM
> On Thursday, April 05, 2012 1:07:55
> am David Xu wrote:
> > On 2012/4/5 11:56, Konstantin Belousov wrote:
> > > On Wed, Apr 04, 2012 at 06:54:06PM -0700, Sushanth
> Rai wrote:
> > >> I have a multithreaded user space program that
> basically runs at realti
I have a multithreaded user space program that basically runs at realtime
priority. Synchronization between threads are done using spinlock. When running
this program on a SMP system under heavy memory pressure I see that thread
holding the spinlock is starved out of cpu. The cpus are effectivel
--- On Sat, 3/24/12, Konstantin Belousov wrote:
> No, I mentioned exactly this in paragraph you replied to.
> To actually start executing from runq, thread needs to
> transition
> from kernel to userspace (in other words, thread appears on
> runq
> due to interrupt, thus entering kernel space)
--- On Fri, 3/23/12, Konstantin Belousov wrote:
Can we
> > safely remove them out of the runq ?
> No, since thread on runq shall be considered the same as the
> thread
> actually executing on CPU. It is unsafe to suspend the
> thread in this
> state, due to it potentially owning a kernel resou
x27;m running on 7.2. Cursory look at trunk version didn't show major changes in
this area.
Thanks,
Sushanth
--- On Thu, 3/22/12, Konstantin Belousov wrote:
> From: Konstantin Belousov
> Subject: Re: Improving gcore
> To: "Sushanth Rai"
> Cc: freebsd-hackers@free
Sometimes I have trouble capturing the "correct" state of a multithreaded
process using gcore. That is, it looks like target process might have done some
work since the time command was issued and the core file was generated.
Looking at the code, gcore calls ptrace(PT_ATTACH...), which internall
. With 3400 no
longer generating NMI on WDT expiry, I'm trying to figure out how I can force
memory dump on watchdog expiry.
Sushanth
--- On Sat, 2/11/12, Andriy Gapon wrote:
> From: Andriy Gapon
> Subject: Re: Generating NMI due to WDT expiry
> To: "Sushanth Rai"
Basically I would like to force system panic (and take kernel dump) when
watchdog time expires. Assuming that timer expired due to some OS bug, kernel
memory dump would be very useful. I'm running freebsd 7.2 on Intel IbexPeak
chipset. According to specs, the watchdog timer on IbexPeak first gen
Hi,
I'm planning to use kqueue/kevent mechanism to notify a user application from
the kernel. Basically I set up a file descriptor for read event from the user
application by calling kevent(). Now, I would like to wake-up the process from
within the kernel. The wake-up will happen due to one of
Hi,
I would like to understand little bit about the FreeBSD interrupt handling on
x86.
When a cpu is processing an IPI, let's say cpu is running IPI_STOP handler, are
I/O interrupts like the timer interrupt disabled ? Conversely if the cpu is
holding a spinlock, which means it has disabled int
26 matches
Mail list logo
