On 2012/4/16 14:48, cz li wrote:
The user-mode stack space is how many bytes, the kernel stack is how
many bytes. I've written a driver.I want to add it to the kernel
source. How should I do?
Thank you.
lichaozhong
2012-4-16
___
freebsd-hackers@freebs
Hi,
the XDR library implementation of xdr_enum() is currently:
/*
* XDR enumerations
*/
bool_t
xdr_enum(XDR *xdrs, enum_t *ep)
{
enum sizecheck { SIZEVAL }; /* used to find the size of an enum */
/*
* enums are treated as ints
*/
/* LINTED */ if (
On Sat, Apr 14, 2012 at 1:37 PM, Damjan Marion wrote:
>
> On Apr 14, 2012, at 6:02 PM, Ian Lepore wrote:
>
>> It's been my growing impression for about a year that the arm support in
>> FreeBSD has atrophied to the point where it can barely be said that it's
>> supported at all. Now I see this mo
On Saturday, April 14, 2012 1:35:35 pm Andriy Gapon wrote:
> on 14/04/2012 18:37 Andriy Gapon said the following:
> >
> > I would like to ask for a review and/or testing of the following three
> > patches:
> > http://people.freebsd.org/~avg/zfsboot.patches.diff
> >
> > These patches add support
On Sunday, April 15, 2012 5:30:29 am Konstantin Belousov wrote:
> On Sun, Apr 15, 2012 at 01:54:42AM -0700, Yuri wrote:
> > On 04/05/2012 07:06, John Baldwin wrote:
> > >In this case we probably should become the upstream maintainer. My patch
> > >actually bumps the version to 1.3 as it is sort of
Konstantin Belousov wrote:
> My opinion is that such tool should be imported into the base.
Why?
Don't optional tools belong in ports?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe,
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
In FreeBSD 6.*, we have been seeing crashes in pmap_remove_pages() that only
seem to occur in scaling scenarios:
2564#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2565pte = vtopte(pv->pv_va);
2566#else
2567pte = pmap_pte(pmap, pv->pv_va);
2568#endif
256
On 11 April 2012 10:21, Gary Jennejohn wrote:
> Just for the archive my bad disk performance seems to have been fixed in
> HEAD by svn commit r234074. Seems that all interrupts were being handled
> by a single CPU/core (I have 6), which resulted in abysmal interrupt
> handling when mutltiple dis
9 matches
Mail list logo