Re: The user-mode stack space is how many bytes?
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" You can use limits(1) to show the user-mode stack space size. As I know, the kernel stack size is 2 pages. ___ 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"
XDR Library and Short Enums
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 (sizeof (enum sizecheck) == sizeof (long)) {
return (xdr_long(xdrs, (long *)(void *)ep));
} else /* LINTED */ if (sizeof (enum sizecheck) == sizeof (int)) {
return (xdr_int(xdrs, (int *)(void *)ep));
} else /* LINTED */ if (sizeof (enum sizecheck) == sizeof (short)) {
return (xdr_short(xdrs, (short *)(void *)ep));
} else {
return (FALSE);
}
}
The enum_t is defined as:
typedef int32_t enum_t;
This is problematic with short enums (variable sized enums). I case of short
enums sizeof (enum sizecheck) would be 1. The ARM EABI lets you a choice
between two alternatives described in the document issued by ARM. See also
section 7.1.3 "Enumerated Types"
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
How would you implement and use the XDR library with short enums? The
xdr_enum() can be easily changed to:
/*
* XDR enumerations
*/
bool_t
xdr_enum(XDR *xdrs, enum_t *ep)
{
/*
* enums are treated as ints
*/
/* LINTED */ if (sizeof (enum_t) == sizeof (long)) {
return (xdr_long(xdrs, (long *)(void *)ep));
} else /* LINTED */ if (sizeof (enum_t) == sizeof (int)) {
return (xdr_int(xdrs, (int *)(void *)ep));
} else /* LINTED */ if (sizeof (enum_t) == sizeof (short)) {
return (xdr_short(xdrs, (short *)(void *)ep));
} else {
return (FALSE);
}
}
The problem is in the XDR library usage. An example is this (rpc_msg.h):
enum msg_type {
CALL=0,
REPLY=1
};
How would you fix this? What about
enum msg_type {
CALL=0,
REPLY=1,
_MSG_TYPE_INVALID = 0x
};
?
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
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: [GSoC] [ARM] arm cleanup - my own proposal
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 morning that marius@ has committed a >> set of style cleanups to the at91 code (r234281), so maybe it's not >> quite as dead as I feared. > > Hi Ian, > > Are you aware of projects/armv6[1] in svn? > > Due to big changes in architecture introduced with ARMv6 we have > separate tree where all ongoing development is happening. > Hopefully we will be able to merge back changes to HEAD soon. > > We have (partially) working support for recent Marvel SoC and some TI boards > (PandaBoard/OMAP4, Beaglebone/AM335x). There is also OMAP3 code waiting > to be integrated. > > Also Andrew is working on moving to ARM EABI[2] which will > allow us to use llvm/clang and all new ARM goodies which are > not supported in our aged gcc. > > Any help is welcome... > > Damjan > > [1] http://svnweb.freebsd.org/base/projects/armv6/ > [2] http://svnweb.freebsd.org/base/projects/arm_eabi There is a lot of ARM work going on in the shadows. I know of other things, but will let them say what they are doing. I am doing an experimental implementation using the ARMv7 hardware features on the pandaboard getting ready for ARMv8. As of this weekend, the ARMv7 experimental pmap/support is booting multi-user. There is a lot of improvements, fixing, tweeking, and polishing. (I am taking out domains shared level1 pagetables, remove the pv_entry. I will eventually start doing the 64 bit extended address support, etc). I eventually want to change the boot (fold chunks of initarm() into pmap/machdep because they are constant for every platform. --Mark Tinguely. ___ 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: [review request] zfsboot/zfsloader: support accessing filesystems within a pool
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 for booting from an arbitrary filesystem of any > > detected ZFS pool. A filesystem could be selected in zfsboot and thus will > > affectfrom where zfsloader would be loaded. zfsboot passes information > > about > > the boot pool and filesystem to zfsloader, which uses those for loaddev and > > default value of currdev. A different pool+filesystem could be selected in > > zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly > > set > > and is not derived from fstab, then it gets set to the selected boot > > filesystem. > > A note for prospective testers: the patched loader expect to be started by the > patched zfs boot as it passes an additional parameter for a filesystem guid. > I should probably add some way to distinguish between the older and newer zfs > boot blocks. Maybe an extra bit in bootflags? What do you think? An extra bit (similar to existing flags for detecting PXE and CD booting) sounds fine to me. (Note, I'm only replying to the question, have not looked at patches yet). -- 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"
Re: Is there any modern alternative to pstack?
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 intended to do that. > > > > bsd-pstack on SourceForge is dead. Sole project owner isn't responsive, > > and as per SF policy they don't allow anyone to take over such project. > > They suggest to fork. > > So will you object if I create a new project on SF, say bsd-pstack-new, > > will import the current source and apply your patch and make a release? > > I will also update pstack port so that it will become current. > It seems that the license is two-clause BSD. > My opinion is that such tool should be imported into the base. I'm fine with putting it into the base. If so, we should import 1.2 first I think and then apply the 1.3 patch. -- 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"
Re: Is there any modern alternative to pstack?
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, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN
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 probably should map the
> whole
> stack at once, prefaulting all pages.
>
> Below are two patches. The change for vm_mmap.c would fix
> your immediate
> problem by allowing holes in wired region.
>
> The change for vm_map.c prefaults the whole stack instead of
> the
> initial fragment. The single-threaded programs still get a
> fault
> on stack growth.
>
> diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
> index 6198629..2fd18d1 100644
> --- a/sys/vm/vm_map.c
> +++ b/sys/vm/vm_map.c
> @@ -3259,7 +3259,10 @@ vm_map_stack(vm_map_t map,
> vm_offset_t addrbos, vm_size_t max_ssize,
> addrbos + max_ssize <
> addrbos)
> return
> (KERN_NO_SPACE);
>
> - init_ssize = (max_ssize < sgrowsiz) ?
> max_ssize : sgrowsiz;
> + if (map->flags & MAP_WIREFUTURE)
> + init_ssize =
> max_ssize;
> + else
> + init_ssize =
> (max_ssize < sgrowsiz) ? max_ssize : sgrowsiz;
>
> PROC_LOCK(curthread->td_proc);
> vmemlim = lim_cur(curthread->td_proc,
> RLIMIT_VMEM);
> diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
> index 2588c85..3fccd9e 100644
> --- a/sys/vm/vm_mmap.c
> +++ b/sys/vm/vm_mmap.c
> @@ -1561,9 +1561,11 @@ vm_mmap(vm_map_t map, vm_offset_t
> *addr, vm_size_t size, vm_prot_t prot,
> * If the
> process has requested that all future mappings
> * be
> wired, then heed this.
> */
> - if (map->flags
> & MAP_WIREFUTURE)
> + if (map->flags
> & MAP_WIREFUTURE) {
>
> vm_map_wire(map, *addr, *addr + size,
> -
> VM_MAP_WIRE_USER | VM_MAP_WIRE_NOHOLES);
> +
> VM_MAP_WIRE_USER | ((flags & MAP_STACK) ?
> +
> VM_MAP_WIRE_HOLESOK : VM_MAP_WIRE_NOHOLES));
> + }
> } else {
> /*
> * If this
> mapping was accounted for in the vnode's
>
___
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"
Corrupted pmap pm_vlist - pmap_remove_pte()
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
2569tpte = *pte; <= page fault here
The suspicion is that the pmap's pm_pvlist list is getting corrupted. To this
end, I have a question on the following logic in pmap_remove_pte() (see in-line
comment):
1533 static int
1534 pmap_remove_pte(pmap_t pmap, pt_entry_t *ptq, vm_offset_t va,
pd_entry_t ptepde)
1535 {
1536 pt_entry_t oldpte;
1537 vm_page_t m;
1538
1539 PMAP_LOCK_ASSERT(pmap, MA_OWNED);
1540 oldpte = pte_load_clear(ptq);
1541 if (oldpte & PG_W)
1542 pmap->pm_stats.wired_count -= 1;
1543 /*
1544 * Machines that don't support invlpg, also don't support
1545 * PG_G.
1546 */
1547 if (oldpte & PG_G)
1548 pmap_invalidate_page(kernel_pmap, va);
1549 pmap->pm_stats.resident_count -= 1;
1550 if (oldpte & PG_MANAGED) {
1551 m = PHYS_TO_VM_PAGE(oldpte & PG_FRAME);
1552 if (oldpte & PG_M) {
1553 #if defined(PMAP_DIAGNOSTIC)
1554 if (pmap_nw_modified((pt_entry_t) oldpte)) {
1555 printf(
1556 "pmap_remove: modified page not writable: va: 0x%lx, pte:
0x%lx\n",
1557 va, oldpte);
1558 }
1559 #endif
1560 if (pmap_track_modified(va))
1561 vm_page_dirty(m);
1562 }
1563 if (oldpte & PG_A)
1564 vm_page_flag_set(m, PG_REFERENCED);
1565 pmap_remove_entry(pmap, m, va);
1566 }
1567 return (pmap_unuse_pt(pmap, va, ptepde)); <=== *** under
what circumstances is it valid to free the page but not remove it from the
pmap's pm_vlist? Even the code comment for pmap_unuse_pt() commences "After
removing a page table entry ... ". ***
1568 }
If the tail end of the above function is changed as follows:
1565 pmap_remove_entry(pmap, m, va);
1565.5 return (pmap_unuse_pt(pmap, va, ptepde));
1566 }
1567 return (0);
Then we don't see any crashes ... but is it the right thing to do?
Ewart
___
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: CAM disk I/O starvation
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 disks were busy. > > Since this commit my disk preformance is back to normal and long lags > are a thing of the past. Hi, This is kind of worrying. You only have a few disks, a single core SHOULD be able to handle all the interrupts for those disks whilst leaving plenty of cycles to spare to drive the rest of your system. And you have 5 other cores. Would you be willing to help out diagnose exactly why that particular behaviour is causing you so much trouble? It almost sounds like something in the IO path is blocking for far too long, not allowing the rest of the system to move forward. That's very worrying for an interrupt handler. :) Adrian ___ 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"
