Re: having 'src' and 'obj' in some other place
On 31 October 2010 23:15, Matthias Apitz wrote:
>
> Hello,
>
> I compiled a 9-CURRENT from SVN but having it in a non default place,
> in /home/guru/9-CURRENT/src. To compile kernel and world I set
> MAKEOBJDIRPREFIX to /home/guru/9-CURRENT/obj and all went fine. Then I
> installed kernel und world to the USB key using DESTDIR set to /mnt.
>
> Because the idea is to use the USB key for further installation a copied
> the 'src' and 'obj' to it as well with:
>
> # cp -Rp /home/guru/9-CURRENT/src /mnt/usr
> # cp -Rp /home/guru/9-CURRENT/obj /mnt/usr
>
> The USB key boots fine. From this USB key I now wanted to install the
> system to a partitioned hard disk, again with something like:
>
> # cd /usr/src
> # make installworld DESTDIR=/mnt
>
> where below /mnt now the file system of the disk was mounted. This failed
> with messages about 'install: ... not found' and the way around was to
> move /usr/src again on the USB key to a faked location of
> /home/guru/9-CURRENT/src, and as well 'obj'. After this all went fine.
>
You can experiment with moving /usr/obj//home/guru/9-CURRENT/src to
/usr/obj/usr/src
> Question: Why is this so hardwired bound to the original location of
> 'src' and 'obj'?
>
you can see /usr/share/mk/bsd.obj.mk for details. make(1) creates
directory ${MAKEOBJDIRPREFIX}/${.CURDIR} . It is useful when you make
world for yourself, do some development stuff with another things,
etc.
> Thanks
>
> matthias
> --
> Matthias Apitz
> t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
> e - w http://www.unixarea.de/
> ___
> 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"
>
I do installation with another method:
On build server I make world, install it into some directory, and make
cpio(1) archive to save file rights. Then I copy archive to usb and
unpack it into new system.
One more question for community: does cpio(1) archive format save file
flags (see chflags(1))?
___
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: serious issue caused by usb device, stalling almost all operations
On Mon Oct 25 10, Alexander Motin wrote: > Hans Petter Selasky wrote: > > On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: > >> hi there, > >> > >> i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: > >> > >> after attaching my mobile phone, it simply resets without doing mount or > >> anything. however after letting the device come up again it won't show up > >> in the console. after detaching it the usb subsystem seemed to have > >> completely crashed. but that's not all. the following programs now simply > >> hang without producing any output C-C won't do anything: > >> > >> - dmesg > >> - top > >> - ps > >> - killall > >> - camcontrol devlist > >> - usbconfig > > > > That's most likely because USB's umass driver is waiting for cam to drain. > > Possibly some refcounting is not correct. I suspect this is not a USB > > problem. > > Try to enter into the debugger, and look for backtrace for function stuck > > in > > umass_detach. i set debug.kdb.panic=1, but didn't work, because writing the core dump stalled and watchdog came up. any advice? cheers. alex > > It is a bit suspicious that problem happens only when device dies during > request. Are you sure that running command was properly aborted when > device got detached? Every running command has own set of references, > denying detach. > > -- > Alexander Motin -- a13x ___ 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: panic in uma_startup for many-core amd64 system
On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote:
> on 19/10/2010 00:01 Giovanni Trematerra said the following:
>>
>> Your patch seems just a work around about initial slab size where the
>> keg is backed.
>
> Well, setting aside my confusion with the terminology - yes, the patch is just
> that, and precisely because I only tried to solve that particular problem.
>
>> Having dynamic slab sizes would allow to have the keg backed on a larger slab
>> without going OFFPAGE.
>
> I agree in principle.
> But without seeing code that implements that I can't guess if it would really
> be
> more efficient or more maintainable, i.e. more useful in general.
> Still a very good idea.
>
Here the patch that was in my mind.
The patch doesn't implement dynamic slab size just allow
to have a multipage slab to back uma_zone objects.
I'm going to work more on the topic "dynamic slab size" soon.
I tested the patch on qemu with -smp 32.
I'm looking for real hw to test the patch on.
here some interesting output:
qemulab# vmstat -z | more
ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP
UMA Kegs: 208, 0, 149, 4, 149, 0, 0
UMA Zones: 4480, 0, 149, 0, 149, 0, 0
UMA Slabs: 568, 0, 836, 4,1187, 0, 0
UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0
UMA Hash: 256, 0, 2, 13, 3, 0, 0
qemulab# sysctl kern | grep cpu
kern.ccpu: 0
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
28, 29, 30, 31
kern.smp.cpus: 32
kern.smp.maxcpus: 32
Any feedback will be appreciate.
--
Giovanni Trematerra
==
diff -r 36572cbc6817 sys/vm/uma_core.c
--- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400
+++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400
@@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes
{
uma_keg_t keg;
uma_slab_t tmps;
-
- keg = zone_first_keg(zone);
+ u_int16_t pages;
+
+ keg = zone_first_keg(zone);
+ pages = bytes / PAGE_SIZE;
+
+ /* Account for remainder */
+ if ((pages * PAGE_SIZE) < bytes)
+ pages++;
+ KASSERT(pages > 0, ("startup_alloc can't reserve 0 pages\n"));
/*
* Check our small startup cache to see if it has pages remaining.
*/
mtx_lock(&uma_boot_pages_mtx);
- if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL) {
- LIST_REMOVE(tmps, us_link);
+ do {
+ if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL)
+ LIST_REMOVE(tmps, us_link);
+ } while (--pages && tmps != NULL);
+ if (tmps != NULL) {
mtx_unlock(&uma_boot_pages_mtx);
*pflag = tmps->us_flags;
return (tmps->us_data);
- }
+ } else if (booted == 0)
+ panic("UMA: Increase vm.boot_pages");
mtx_unlock(&uma_boot_pages_mtx);
- if (booted == 0)
- panic("UMA: Increase vm.boot_pages");
/*
* Now that we've booted reset these users to their real allocator.
*/
#ifdef UMA_MD_SMALL_ALLOC
- keg->uk_allocf = uma_small_alloc;
+ keg->uk_allocf = (keg->uk_ppera > 1) ? page_alloc : uma_small_alloc;
#else
keg->uk_allocf = page_alloc;
#endif
@@ -1163,7 +1172,7 @@ keg_small_init(uma_keg_t keg)
static void
keg_large_init(uma_keg_t keg)
{
- int pages;
+ u_int16_t pages;
KASSERT(keg != NULL, ("Keg is null in keg_large_init"));
KASSERT((keg->uk_flags & UMA_ZFLAG_CACHEONLY) == 0,
@@ -1177,12 +1186,15 @@ keg_large_init(uma_keg_t keg)
keg->uk_ppera = pages;
keg->uk_ipers = 1;
+ keg->uk_rsize = keg->uk_size;
+
+ /* We can't do OFFPAGE if we're internal, bail out here. */
+ if (keg->uk_flags & UMA_ZFLAG_INTERNAL)
+ return;
keg->uk_flags |= UMA_ZONE_OFFPAGE;
if ((keg->uk_flags & UMA_ZONE_VTOSLAB) == 0)
keg->uk_flags |= UMA_ZONE_HASH;
-
- keg->uk_rsize = keg->uk_size;
}
static void
@@ -1301,7 +1313,8 @@ keg_ctor(void *mem, int size, void *udat
#endif
if (booted == 0)
keg->uk_allocf = startup_alloc;
- }
+ } else if (booted == 0 && (keg->uk_flags & UMA_ZFLAG_INTERNAL))
+ keg->uk_allocf = startup_alloc;
/*
* Initialize keg's lock (shared among zones).
@@ -1330,7 +1343,7 @@ keg_ctor(void *mem, int size, void *udat
if (totsize & UMA_ALIGN_PTR)
totsize = (totsize & ~UMA_ALIGN_PTR) +
(UMA_ALIGN_PTR + 1);
- keg->uk_pgoff = UMA_SLAB_SIZE - totsize;
+ keg->uk_pgoff = (UMA_SLAB_SIZE * keg->uk_ppera) - totsize;
if (keg->uk_flags & UMA_ZONE_REFCNT)
Re: re(4) driver dropping packets when reading NFS files
On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote: > I recently purchased a laptop that has a re(4) Realtek 8101E/8102E/8103E net > chip in it and I find that it is dropping packets like crazy when reading > files over an NFS mount. (It seems that bursts of receive traffic cause it, > since when I look over wireshark, typically the 2nd packet in a read reply > is not received, although it was sent at the other end.) > Are you using NFS over UDP? > Adding "options DEVICE_POLLING" helps a lot. (ie. order of magnitude faster > reading) Does this hint that interrupts are being lost or delayed too much? > Actually I'm not a fan of polling(4) but re(4) controllers might be exceptional one due to controller limitation but order of magnitude faster indicates something is wrong in driver. > Anyhow, if anyone has an idea on what the cause/fix might be or are familiar > with the driver/hardware, I'd appreciate hearing about it. > AFAIK re(4) controllers lacks interrupts moderation so re(4) used to rely on taskqueue to reduce number of interrupts. It was written long time ago by Bill and I'm not sure whether it's still valid for recent PCIe RealTek controllers. One of problem is getting stand-alone PCIe controllers in market and I was not able to buy recent controllers. This is one of reason why re(4) still lacks TSO, jumbo frame and 64bit DMA support for newer controllers. Another problem is RealTek no longer releases data sheet so it's hard to write new features that may present on recent controllers. Recent re(4) controllers started to support small set of hardware MAC statistics counters and that may help to understand how many frames were lost under heavy load. I'll let you know when I have a patch for that. Flow-control may also enhance performance a little bit but it was not implemented yet like most other consumer grade ethernet drivers. But this may change in near future, marius@ is actively working on this so we'll get generic flow-control framework in tree. I'll see what can be done in interrupt handler and I'll let you know when patch is ready. > Thanks, rick > ps: This laptop is running a low end AMD cpu and I did install amd64 on it, > instead of i386, in case that might be relevent? I don't think so. ___ 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: panic in uma_startup for many-core amd64 system
On Monday, November 01, 2010 1:09:22 pm Giovanni Trematerra wrote:
> On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote:
> > on 19/10/2010 00:01 Giovanni Trematerra said the following:
> >>
> >> Your patch seems just a work around about initial slab size where the
> >> keg is backed.
> >
> > Well, setting aside my confusion with the terminology - yes, the patch is
just
> > that, and precisely because I only tried to solve that particular problem.
> >
> >> Having dynamic slab sizes would allow to have the keg backed on a larger
slab
> >> without going OFFPAGE.
> >
> > I agree in principle.
> > But without seeing code that implements that I can't guess if it would
really be
> > more efficient or more maintainable, i.e. more useful in general.
> > Still a very good idea.
> >
>
> Here the patch that was in my mind.
> The patch doesn't implement dynamic slab size just allow
> to have a multipage slab to back uma_zone objects.
> I'm going to work more on the topic "dynamic slab size" soon.
> I tested the patch on qemu with -smp 32.
> I'm looking for real hw to test the patch on.
>
> here some interesting output:
> qemulab# vmstat -z | more
> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP
>
> UMA Kegs: 208, 0, 149, 4, 149, 0, 0
> UMA Zones: 4480, 0, 149, 0, 149, 0, 0
> UMA Slabs: 568, 0, 836, 4,1187, 0, 0
> UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0
> UMA Hash: 256, 0, 2, 13, 3, 0, 0
>
> qemulab# sysctl kern | grep cpu
> kern.ccpu: 0
> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
> 28, 29, 30, 31
> kern.smp.cpus: 32
> kern.smp.maxcpus: 32
>
> Any feedback will be appreciate.
>
> --
> Giovanni Trematerra
>
>
> ==
> diff -r 36572cbc6817 sys/vm/uma_core.c
> --- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400
> +++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400
> @@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes
> {
> uma_keg_t keg;
> uma_slab_t tmps;
> -
> - keg = zone_first_keg(zone);
> + u_int16_t pages;
> +
> + keg = zone_first_keg(zone);
> + pages = bytes / PAGE_SIZE;
> +
> + /* Account for remainder */
> + if ((pages * PAGE_SIZE) < bytes)
> + pages++;
> + KASSERT(pages > 0, ("startup_alloc can't reserve 0 pages\n"));
You can use 'pages = howmany(bytes, PAGE_SIZE)' here. Also, why did you make
pages a uint16_t instead of an int? An int is generally more convenient
unless you really need a uint16_t (and C99 spells it without an _ after the
leading 'u'.. FYI).
> /*
>* Check our small startup cache to see if it has pages remaining.
>*/
> mtx_lock(&uma_boot_pages_mtx);
> - if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL) {
> - LIST_REMOVE(tmps, us_link);
> + do {
> + if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL)
> + LIST_REMOVE(tmps, us_link);
> + } while (--pages && tmps != NULL);
> + if (tmps != NULL) {
> mtx_unlock(&uma_boot_pages_mtx);
> *pflag = tmps->us_flags;
> return (tmps->us_data);
> - }
> + } else if (booted == 0)
> + panic("UMA: Increase vm.boot_pages");
> mtx_unlock(&uma_boot_pages_mtx);
> - if (booted == 0)
> - panic("UMA: Increase vm.boot_pages");
Probably best to make the pages test here explicit. Also, is there any reason
you can't do this as:
while (--pages > 0) {
tmps = LIST_FIRST(&uma_boot_pages);
if (tmps != NULL)
LIST_REMOVE(tmps, us_link);
else if (booted == 0)
panic(...);
}
One question btw, how does this work since if you need to allocate more than 1
page it seems that the 'tmps' values for all but the last are simply ignored
and leaked?
Is there some unwritten assumption that the free pages are all virtually
contiguous (and in order), so you can just pull off a run of X and use
the address from X?
> /*
>* Now that we've booted reset these users to their real allocator.
>*/
> #ifdef UMA_MD_SMALL_ALLOC
> - keg->uk_allocf = uma_small_alloc;
> + keg->uk_allocf = (keg->uk_ppera > 1) ? page_alloc : uma_small_alloc;
> #else
> keg->uk_allocf = page_alloc;
> #endif
> @@ -1163,7 +1172,7 @@ keg_small_init(uma_keg_t keg)
> static void
> keg_large_init(uma_keg_t keg)
> {
> - int pages;
> + u_int16_t pages;
>
> KASSERT(keg != NULL, ("Keg is null in keg_large_init"));
> KASSERT((keg->uk_flags & UMA_ZFLAG_CACHEONLY) == 0,
> @@ -1177,12 +1186,15 @@ keg_large_init(uma_keg_t keg)
>
> keg->uk_ppera = pages;
> keg->uk_iper
[RFC] Outline of USB process integration in the kernel taskqueue system
Hi!
I've wrapped up an outline patch for what needs to be done to integrate the
USB process framework into the kernel taskqueue system in a more direct way
that to wrap it.
The limitation of the existing taskqueue system is that it only guarantees
execution at a given priority level. USB requires more. USB also requires a
guarantee that the last task queued task also gets executed last. This is for
example so that a deferred USB detach event does not happen before any pending
deferred I/O for example in case of multiple occurring events.
Mostly this new feature is targeted for GPIO-alike system using slow busses
like the USB. Typical use case:
2 tasks to program GPIO on.
2 tasks to program GPIO off.
Example:
a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc-
>sc_task_on[1]);
b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc-
>sc_task_off[1]);
No matter how the call ordering of code-line a) and b), we are always
guaranteed that the last queued state "on" or "off" is reached before the head
of the taskqueue empties.
In lack of a better name, the new function was called taskqueue_enqueue_odd
[some people obviously think that USB processes are odd, but not taskqueues
:-)]
Manpage:
.Ft int
.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct
task *t1"
..
The function
.Fn taskqueue_enqueue_odd
should be used if it is important that the last queued task is also
executed last in the task queue at the given priority level. This
function requires two valid task pointers. Depending on which of the
tasks passed are queued at the calling moment, the last queued task of
the two will get dequeued and put last in the task queue, while not
touching the first queued task. If no tasks are queued at the calling
moment, this function behaves like
.Fn taskqueue_enqueue .
This function returns zero if the first task was queued last, one if
the second task was queued last.
Preliminary patch - see e-mail attachment.
Comments are welcome!
--HPS
More docs: Also see talk about the new USB stack in FreeBSD on Youtube.
=== share/man/man9/taskqueue.9
==
--- share/man/man9/taskqueue.9 (revision 214211)
+++ share/man/man9/taskqueue.9 (local)
@@ -46,11 +46,15 @@
typedef void (*taskqueue_enqueue_fn)(void *context);
struct task {
- STAILQ_ENTRY(task) ta_link;/* link for queue */
- u_short ta_pending; /* count times queued */
- u_short ta_priority;/* priority of task in queue */
- task_fn_t ta_func;/* task handler */
- void*ta_context;/* argument for handler */
+ TAILQ_ENTRY(task) ta_link; /* link for queue */
+#defineTASKQUEUE_SEQUENCE_MAX 255
+ u_char ta_sequence;/* sequence number */
+#defineTASKQUEUE_PENDING_MAX 255
+ u_char ta_pending; /* count times queued */
+#defineTASKQUEUE_PRIORITY_MAX 65535U
+ u_short ta_priority;/* priority of task in queue */
+ task_fn_t *ta_func; /* task handler */
+ void*ta_context;/* argument for handler */
};
.Ed
.Ft struct taskqueue *
@@ -62,6 +66,8 @@
.Ft int
.Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task"
.Ft int
+.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct
task *t1"
+.Ft int
.Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *task"
.Ft void
.Fn taskqueue_drain "struct taskqueue *queue" "struct task *task"
@@ -134,6 +140,19 @@
if the queue is being freed.
.Pp
The function
+.Fn taskqueue_enqueue_odd
+should be used if it is important that the last queued task is also
+executed last in the task queue at the given priority level. This
+function requires two valid task pointers. Depending on which of the
+tasks passed are queued at the calling moment, the last queued task of
+the two will get dequeued and put last in the task queue, while not
+touching the first queued task. If no tasks are queued at the calling
+moment, this function behaves like
+.Fn taskqueue_enqueue .
+This function returns zero if the first task was queued last, one if
+the second task was queued last.
+.Pp
+The function
.Fn taskqueue_enqueue_fast
should be used in place of
.Fn taskqueue_enqueue
=== sys/sys/_task.h
==
--- sys/sys/_task.h (revision 214433)
+++ sys/sys/_task.h (local)
@@ -44,9 +44,13 @@
typedef void task_fn_t(void *context, int pending);
struct task {
- STAILQ_ENTRY(task) ta_link; /* (q) link for queue */
- u_short ta_pending; /* (q) count times queued */
- u_short ta_priority;/* (c) Priority */
+ TAILQ_ENTRY(task) ta_link; /* (q) link for queue */
+#defineTASKQUEUE_SEQUENCE_MAX 25
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky wrote:
> Hi!
>
> I've wrapped up an outline patch for what needs to be done to integrate the
> USB process framework into the kernel taskqueue system in a more direct way
> that to wrap it.
>
> The limitation of the existing taskqueue system is that it only guarantees
> execution at a given priority level. USB requires more. USB also requires a
> guarantee that the last task queued task also gets executed last. This is for
> example so that a deferred USB detach event does not happen before any pending
> deferred I/O for example in case of multiple occurring events.
>
> Mostly this new feature is targeted for GPIO-alike system using slow busses
> like the USB. Typical use case:
>
> 2 tasks to program GPIO on.
> 2 tasks to program GPIO off.
>
> Example:
>
> a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc-
>>sc_task_on[1]);
>
>
> b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc-
>>sc_task_off[1]);
>
>
> No matter how the call ordering of code-line a) and b), we are always
> guaranteed that the last queued state "on" or "off" is reached before the head
> of the taskqueue empties.
>
>
> In lack of a better name, the new function was called taskqueue_enqueue_odd
> [some people obviously think that USB processes are odd, but not taskqueues
> :-)]
I'd like to make sure I understand the USB requirements.
(1) does USB need the task priority field? Many taskqueue(9) consumers do not.
(2) if there was a working taskqueue_remove(9) that removed the task
if pending or returned error if the task was currently running, would
that be sufficient to implement the required USB functionality?
(assuming that taskqueue_enqueue(9) put all tasks with equal priority
in order of queueing).
Thanks,
matthew
> Manpage:
>
> .Ft int
> .Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct
> task *t1"
>
> ..
>
> The function
> .Fn taskqueue_enqueue_odd
> should be used if it is important that the last queued task is also
> executed last in the task queue at the given priority level. This
> function requires two valid task pointers. Depending on which of the
> tasks passed are queued at the calling moment, the last queued task of
> the two will get dequeued and put last in the task queue, while not
> touching the first queued task. If no tasks are queued at the calling
> moment, this function behaves like
> .Fn taskqueue_enqueue .
> This function returns zero if the first task was queued last, one if
> the second task was queued last.
>
> Preliminary patch - see e-mail attachment.
>
> Comments are welcome!
>
> --HPS
>
> More docs: Also see talk about the new USB stack in FreeBSD on Youtube.
>
> === share/man/man9/taskqueue.9
> ==
> --- share/man/man9/taskqueue.9 (revision 214211)
> +++ share/man/man9/taskqueue.9 (local)
> @@ -46,11 +46,15 @@
> typedef void (*taskqueue_enqueue_fn)(void *context);
>
> struct task {
> - STAILQ_ENTRY(task) ta_link; /* link for queue */
> - u_short ta_pending; /* count times queued */
> - u_short ta_priority; /* priority of task in queue
> */
> - task_fn_t ta_func; /* task handler */
> - void *ta_context; /* argument for handler */
> + TAILQ_ENTRY(task) ta_link; /* link for queue */
> +#define TASKQUEUE_SEQUENCE_MAX 255
> + u_char ta_sequence; /* sequence number */
> +#define TASKQUEUE_PENDING_MAX 255
> + u_char ta_pending; /* count times queued */
> +#define TASKQUEUE_PRIORITY_MAX 65535U
> + u_short ta_priority; /* priority of task in queue */
> + task_fn_t *ta_func; /* task handler */
> + void *ta_context; /* argument for handler */
> };
> .Ed
> .Ft struct taskqueue *
> @@ -62,6 +66,8 @@
> .Ft int
> .Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task"
> .Ft int
> +.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0"
> "struct task *t1"
> +.Ft int
> .Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *task"
> .Ft void
> .Fn taskqueue_drain "struct taskqueue *queue" "struct task *task"
> @@ -134,6 +140,19 @@
> if the queue is being freed.
> .Pp
> The function
> +.Fn taskqueue_enqueue_odd
> +should be used if it is important that the last queued task is also
> +executed last in the task queue at the given priority level. This
> +function requires two valid task pointers. Depending on which of the
> +tasks passed are queued at the calling moment, the last queued task of
> +the two will get dequeued and put last in the task queue, while not
> +touching the first queued task. If no tasks are queued at the calling
> +moment, this function behaves like
> +.Fn taskqueue_enqueue .
> +This function returns zero if the first t
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky wrote: > > Hi! > > > > I've wrapped up an outline patch for what needs to be done to integrate > > the USB process framework into the kernel taskqueue system in a more > > direct way that to wrap it. > > > > The limitation of the existing taskqueue system is that it only > > guarantees execution at a given priority level. USB requires more. USB > > also requires a guarantee that the last task queued task also gets > > executed last. This is for example so that a deferred USB detach event > > does not happen before any pending deferred I/O for example in case of > > multiple occurring events. > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > busses like the USB. Typical use case: > > > > 2 tasks to program GPIO on. > > 2 tasks to program GPIO off. > > > > Example: > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > >>sc_task_on[1]); > >> > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > >>sc_task_off[1]); > >> > > No matter how the call ordering of code-line a) and b), we are always > > guaranteed that the last queued state "on" or "off" is reached before the > > head of the taskqueue empties. > > > > > > In lack of a better name, the new function was called > > taskqueue_enqueue_odd [some people obviously think that USB processes > > are odd, but not taskqueues > > > > :-)] > > I'd like to make sure I understand the USB requirements. > > (1) does USB need the task priority field? Many taskqueue(9) consumers do > not. No, USB does not need a task priority field, but a sequence field associated with the task and task queue head to figure out which task was queued first without having to scan all the tasks queued. > (2) if there was a working taskqueue_remove(9) that removed the task > if pending or returned error if the task was currently running, would > that be sufficient to implement the required USB functionality? > (assuming that taskqueue_enqueue(9) put all tasks with equal priority > in order of queueing). No, not completely. See comment above. I also need information about which task was queued first, or else I have to keep this information separately, which again, confuse people. The more layers the more confusion? --HPS ___ 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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > Hi! > > I've wrapped up an outline patch for what needs to be done to integrate the > USB process framework into the kernel taskqueue system in a more direct way > that to wrap it. > > The limitation of the existing taskqueue system is that it only guarantees > execution at a given priority level. USB requires more. USB also requires a > guarantee that the last task queued task also gets executed last. This is for > example so that a deferred USB detach event does not happen before any > pending > deferred I/O for example in case of multiple occurring events. > > Mostly this new feature is targeted for GPIO-alike system using slow busses > like the USB. Typical use case: > > 2 tasks to program GPIO on. > 2 tasks to program GPIO off. > > Example: > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > >sc_task_on[1]); > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > >sc_task_off[1]); > > > No matter how the call ordering of code-line a) and b), we are always > guaranteed that the last queued state "on" or "off" is reached before the > head > of the taskqueue empties. > > > In lack of a better name, the new function was called taskqueue_enqueue_odd > [some people obviously think that USB processes are odd, but not taskqueues > :-)] It feels like this should be something you could manage with a state machine internal to USB rather than forcing that state into the taskqueue code itself. If you wanted a simple barrier task (where a barrier task is always queued at the tail of the list and all subsequent tasks are queued after the barrier task) then I would be fine with adding that. You could manage this without having to alter the task KBI by having the taskqueue maintain a separate pointer to the current "barrier" task and always enqueue entries after that task (the barrier would be NULL before a barrier is queued, and set to NULL when a barrier executes). I think this sort of semantic is a bit simpler and also used in other parts of the tree (e.g. in bio queues). -- John Baldwin ___ 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: panic in uma_startup for many-core amd64 system
On Mon, Nov 1, 2010 at 8:14 PM, John Baldwin wrote:
> On Monday, November 01, 2010 1:09:22 pm Giovanni Trematerra wrote:
>> On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote:
>> > on 19/10/2010 00:01 Giovanni Trematerra said the following:
>> >>
>> >> Your patch seems just a work around about initial slab size where the
>> >> keg is backed.
>> >
>> > Well, setting aside my confusion with the terminology - yes, the patch is
> just
>> > that, and precisely because I only tried to solve that particular problem.
>> >
>> >> Having dynamic slab sizes would allow to have the keg backed on a larger
> slab
>> >> without going OFFPAGE.
>> >
>> > I agree in principle.
>> > But without seeing code that implements that I can't guess if it would
> really be
>> > more efficient or more maintainable, i.e. more useful in general.
>> > Still a very good idea.
>> >
>>
>> Here the patch that was in my mind.
>> The patch doesn't implement dynamic slab size just allow
>> to have a multipage slab to back uma_zone objects.
>> I'm going to work more on the topic "dynamic slab size" soon.
>> I tested the patch on qemu with -smp 32.
>> I'm looking for real hw to test the patch on.
>>
>> here some interesting output:
>> qemulab# vmstat -z | more
>> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP
>>
>> UMA Kegs: 208, 0, 149, 4, 149, 0, 0
>> UMA Zones: 4480, 0, 149, 0, 149, 0, 0
>> UMA Slabs: 568, 0, 836, 4, 1187, 0, 0
>> UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0
>> UMA Hash: 256, 0, 2, 13, 3, 0, 0
>>
>> qemulab# sysctl kern | grep cpu
>> kern.ccpu: 0
>> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
>> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
>> 28, 29, 30, 31
>> kern.smp.cpus: 32
>> kern.smp.maxcpus: 32
>>
>> Any feedback will be appreciate.
>>
>> --
>> Giovanni Trematerra
>>
>>
>> ==
>> diff -r 36572cbc6817 sys/vm/uma_core.c
>> --- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400
>> +++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400
>> @@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes
>> {
>> uma_keg_t keg;
>> uma_slab_t tmps;
>> -
>> - keg = zone_first_keg(zone);
>> + u_int16_t pages;
>> +
>> + keg = zone_first_keg(zone);
>> + pages = bytes / PAGE_SIZE;
>> +
>> + /* Account for remainder */
>> + if ((pages * PAGE_SIZE) < bytes)
>> + pages++;
>> + KASSERT(pages > 0, ("startup_alloc can't reserve 0 pages\n"));
>
> You can use 'pages = howmany(bytes, PAGE_SIZE)' here.
Thanks for the hint.
> Also, why did you make
> pages a uint16_t instead of an int? An int is generally more convenient
> unless you really need a uint16_t (and C99 spells it without an _ after the
> leading 'u'.. FYI).
Uhm just to be coherent with field uk_ppera of struct keg, but I think
I can just use an int.
BTW is new code supposed to use C99 form even if the rest of the file
use u_int* form?
>
>> /*
>> * Check our small startup cache to see if it has pages remaining.
>> */
>> mtx_lock(&uma_boot_pages_mtx);
>> - if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL) {
>> - LIST_REMOVE(tmps, us_link);
>> + do {
>> + if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL)
>> + LIST_REMOVE(tmps, us_link);
>> + } while (--pages && tmps != NULL);
>> + if (tmps != NULL) {
>> mtx_unlock(&uma_boot_pages_mtx);
>> *pflag = tmps->us_flags;
>> return (tmps->us_data);
>> - }
>> + } else if (booted == 0)
>> + panic("UMA: Increase vm.boot_pages");
>> mtx_unlock(&uma_boot_pages_mtx);
>> - if (booted == 0)
>> - panic("UMA: Increase vm.boot_pages");
>
> Probably best to make the pages test here explicit. Also, is there any reason
> you can't do this as:
>
> while (--pages > 0) {
> tmps = LIST_FIRST(&uma_boot_pages);
> if (tmps != NULL)
> LIST_REMOVE(tmps, us_link);
> else if (booted == 0)
> panic(...);
> }
>
Well, no, even if I'll need to initialize tmps to NULL otherwise the
compiler will
raise a warning.
do {} while(); might be still better than a while(){}. bytes parameter
will never be
zero so pages will always be at least one and KASSERT will catch some
wired behavior.
Anyway that looks to me more readable, thanks. I could add an "else
break;" just in
the few cases that "pages" is still > 0 and tmps == NULL, that could
be useless though.
> One question btw, how does this work since if you need to allocate more than 1
> page it seems that the 'tmps' values for all but the last are simply ignored
> and leaked?
When you extract one item from the list y
Re: re(4) driver dropping packets when reading NFS files
> On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote: > > I recently purchased a laptop that has a re(4) Realtek > > 8101E/8102E/8103E net > > chip in it and I find that it is dropping packets like crazy when > > reading > > files over an NFS mount. (It seems that bursts of receive traffic > > cause it, > > since when I look over wireshark, typically the 2nd packet in a read > > reply > > is not received, although it was sent at the other end.) > > > > Are you using NFS over UDP? The test I referred to was over TCP, which works fine until reading a file and then about the second TCP data segment that is sent by the server isn't received by the client with the re(4). (I had tcpdump capturing on both machines and then compared them using wireshark.) The read does progress slowly, after TCP retransmits the segment that was dropped. The result is a rate of about 10 reads/sec. A test over UDP gets nowhere. You just gets lots of "IP fragments timed out" when you "netstat -s", so it seems to consistently drop a fragment in the read UDP reply. > > > Adding "options DEVICE_POLLING" helps a lot. (ie. order of magnitude > > faster > > reading) Does this hint that interrupts are being lost or delayed > > too much? > > > > Actually I'm not a fan of polling(4) but re(4) controllers might be > exceptional one due to controller limitation but order of magnitude > faster indicates something is wrong in driver. > Yep, I'd agree. I can print out the exact chip device info, but if you don't have data sheets, it may not help. It seems to be a low end chip, since it doesn't support 1Gbps --> closer to an 8139. It might be called an 8036, since that # shows up in the device resources under windoze. > > AFAIK re(4) controllers lacks interrupts moderation so re(4) used > to rely on taskqueue to reduce number of interrupts. It was written > long time ago by Bill and I'm not sure whether it's still valid for > recent PCIe RealTek controllers. One of problem is getting > stand-alone PCIe controllers in market and I was not able to buy > recent controllers. This is one of reason why re(4) still lacks TSO, > jumbo frame and 64bit DMA support for newer controllers. Another > problem is RealTek no longer releases data sheet so it's hard to > write new features that may present on recent controllers. > > Recent re(4) controllers started to support small set of hardware > MAC statistics counters and that may help to understand how many > frames were lost under heavy load. I'll let you know when I have a > patch for that. Flow-control may also enhance performance a little > bit but it was not implemented yet like most other consumer grade > ethernet drivers. But this may change in near future, marius@ is > actively working on this so we'll get generic flow-control > framework in tree. It drops a frame as soon as the read starts and there is a burst of more than one. (I can email you the tcpdump captures if you're interested and you won't have to look far into it to see it happen.) It seems to do it consistently and then recovers when the TCP segment is resent, but repeats the fun on the next one. (I'm wondering if it can't support a 64 entry receive ring. I'll try making it smaller and see what happens? Probably won't help, but can't hurt to try:-) > > I'll see what can be done in interrupt handler and I'll let you > know when patch is ready. > > > Thanks, rick > > ps: This laptop is running a low end AMD cpu and I did install amd64 > > on it, > > instead of i386, in case that might be relevent? > > I don't think so. > Ok. I didn't think so, but someone recently mentioned that some drivers for wifi chips don't work for amd64. It actually works fairly well (and quite well with DEVICE_POLLING), except for this issue where it drops received packets when it gets bursts of them. (It almost looks like it only handles the first received packet, although it appears to be using a receive ring of 64 buffers.) Anyhow, I'll keep poking at it and will appreciate any patches/suggestions that you might have. Thanks, rick ___ 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"
wpa_supplicant gets points for trying, I suppose....
FreeBSD 9.0-CURRENT #31 r214621M Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:10:10 d130 last message repeated 3 times Nov 1 15:10:50 d130 last message repeated 4 times ... Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:12:10 d130 last message repeated 2 times Nov 1 15:14:10 d130 last message repeated 12 times I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? I don't recall stable/8 doing this, though I could be wrong. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpZS0owaJ52B.pgp Description: PGP signature
Re: wpa_supplicant gets points for trying, I suppose....
On 11/1/10, David Wolfskill wrote: > FreeBSD 9.0-CURRENT #31 r214621M > > Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. > Nov 1 15:10:10 d130 last message repeated 3 times > Nov 1 15:10:50 d130 last message repeated 4 times > ... > Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. > Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. > ... > Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. > Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. > ... > Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. > ... > Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. > Nov 1 15:12:10 d130 last message repeated 2 times > Nov 1 15:14:10 d130 last message repeated 12 times > > I have the switch on this laptop in position to disable the wireless > device (iwn(4)). Is there some way wpa_supplicant (or something) might > be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? > > I don't recall stable/8 doing this, though I could be wrong. ___ 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: re(4) driver dropping packets when reading NFS files
On Mon, Nov 01, 2010 at 06:18:13PM -0400, Rick Macklem wrote: > > On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote: > > > I recently purchased a laptop that has a re(4) Realtek > > > 8101E/8102E/8103E net > > > chip in it and I find that it is dropping packets like crazy when > > > reading > > > files over an NFS mount. (It seems that bursts of receive traffic > > > cause it, > > > since when I look over wireshark, typically the 2nd packet in a read > > > reply > > > is not received, although it was sent at the other end.) > > > > > > > Are you using NFS over UDP? > > The test I referred to was over TCP, which works fine until reading a > file and then about the second TCP data segment that is sent by the > server isn't received by the client with the re(4). (I had tcpdump > capturing on both machines and then compared them using wireshark.) Hmm, this is not what I initially thought. re(4) has much more preference on handling RX traffic over TX so it should have received that even though it couldn't send response packets. I'm not sure my patch can mitigate the issue. > The read does progress slowly, after TCP retransmits the segment that > was dropped. The result is a rate of about 10 reads/sec. > > A test over UDP gets nowhere. You just gets lots of > "IP fragments timed out" when you "netstat -s", so it seems to > consistently drop a fragment in the read UDP reply. > > > > > Adding "options DEVICE_POLLING" helps a lot. (ie. order of magnitude > > > faster > > > reading) Does this hint that interrupts are being lost or delayed > > > too much? > > > > > > > Actually I'm not a fan of polling(4) but re(4) controllers might be > > exceptional one due to controller limitation but order of magnitude > > faster indicates something is wrong in driver. > > > > Yep, I'd agree. I can print out the exact chip device info, but if you > don't have data sheets, it may not help. It seems to be a low end chip, > since it doesn't support 1Gbps --> closer to an 8139. It might be > called an 8036, since that # shows up in the device resources under > windoze. > > > > > AFAIK re(4) controllers lacks interrupts moderation so re(4) used > > to rely on taskqueue to reduce number of interrupts. It was written > > long time ago by Bill and I'm not sure whether it's still valid for > > recent PCIe RealTek controllers. One of problem is getting > > stand-alone PCIe controllers in market and I was not able to buy > > recent controllers. This is one of reason why re(4) still lacks TSO, > > jumbo frame and 64bit DMA support for newer controllers. Another > > problem is RealTek no longer releases data sheet so it's hard to > > write new features that may present on recent controllers. > > > > Recent re(4) controllers started to support small set of hardware > > MAC statistics counters and that may help to understand how many > > frames were lost under heavy load. I'll let you know when I have a > > patch for that. Flow-control may also enhance performance a little > > bit but it was not implemented yet like most other consumer grade > > ethernet drivers. But this may change in near future, marius@ is > > actively working on this so we'll get generic flow-control > > framework in tree. > > It drops a frame as soon as the read starts and there is a burst > of more than one. (I can email you the tcpdump captures if you're > interested and you won't have to look far into it to see it happen.) > I'm more interested in number of dropped frames. See below how to extract that information. > It seems to do it consistently and then recovers when the TCP > segment is resent, but repeats the fun on the next one. > (I'm wondering if it can't support a 64 entry receive ring. I'll > try making it smaller and see what happens? Probably won't help, > but can't hurt to try:-) > > > > > I'll see what can be done in interrupt handler and I'll let you > > know when patch is ready. > > > > > Thanks, rick > > > ps: This laptop is running a low end AMD cpu and I did install amd64 > > > on it, > > > instead of i386, in case that might be relevent? > > > > I don't think so. > > > Ok. I didn't think so, but someone recently mentioned that some drivers > for wifi chips don't work for amd64. > All drivers touched by me should work on any architectures. The code is the same so there is no difference. > It actually works fairly well (and quite well with DEVICE_POLLING), except > for this issue where it drops received packets when it gets bursts of them. Actually this is one of advantage of using interrupts against polling. Interrupts tend to give more fast response. To achieve the similar behavior with polling you should have used high hz. Your test indicates quite opposite result though. > (It almost looks like it only handles the first received packet, although > it appears to be using a receive ring of 64 buffers.) > No, re(4) uses 256 TX/RX buffers for RTL810xE controllers. > Anyhow, I'll keep poking at it and
9-CURRENT: ports/net/kdenetwork3 does not compile
Hello,
$ uname -a
FreeBSD tinyCurrent 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r21: Thu Oct 28
10:56:32 CEST 2010
with /usr/ports from CVS October, 30;
compiling KDE3 gives:
...
gmake[4]: Entering directory
`/usr/ports/net/kdenetwork3/work/kdenetwork-3.5.10/ktalkd/ktalkd'
c++ -DHAVE_CONFIG_H -I. -I../.. -I../../kopete/protocols/gadu/libgadu
-I/usr/local/include -I/usr/local/include -DHAVE_KDE -D_THREAD_SAFE -pthread
-DQT_THREAD_SUPPORT -I/usr/local/include -I/usr/local/include
-I/usr/local/include -D_GETOPT_H -D_THREAD_SAFE -D_LARGE_FILES=1
-Wno-long-long -Wundef -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2
-pipe -fno-strict-aliasing -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -MT find_user.o -MD -MP -MF .deps/find_user.Tpo -c -o
find_user.o find_user.cpp
find_user.cpp: In function 'int find_user(char*, char*, char*)':
find_user.cpp:344: error: aggregate 'utmp ubuf' has incomplete type and cannot
be defined
gmake[4]: *** [find_user.o] Error 1
The code in find_user.cpp reads:
...
#endif /*UTMP_AND_PROC_FIND_USER*/
#else /*not PROC_FIND_USER*/
int find_user(char *name, char *tty, char *disp) {
struct utmp ubuf;<< line 344
int status;
FILE *fd;
struct stat statb;
char ftty[20+UT_LINESIZE];
char ttyFound[UT_LINESIZE] = "";
char dispFound[UT_HOSTSIZE+1] = "";
if (!(fd = fopen(_PATH_UTMP, "r"))) {
fprintf(stderr, "talkd: can't read %s.\n", _PATH_UTMP);
return (FAILED);
}
Something wrong with 'struct utmp ubuf' in HEAD?
Thanks
mattihas
--
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e - w http://www.unixarea.de/
___
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"
