Re: copyin+copyout in one step ?
On 28 May 2013, at 05:56, Zaphod Beeblebrox zbee...@gmail.com wrote: Urm... Isn't the use of shared memory the more obvious way to transfer data between processes? Am I missing some nuance? I can't speak for Luigi's use-case, but the Binder APIs in BeOS and Android call for this kind of copy. The receiving process contains a ring buffer and the messages are pushed into it. You could implement this in shared memory, but only if you trusted the sender not to modify the data at incorrect times or write invalid values into the metadata (or, in the case of Binder, to forge the pid / uid of the sender, which it attached to each message). The kernel must act as an intermediary to enforce correct use of the buffer and also to allow the caller to block until space is available (perhaps by scheduling the receiver to run for a bit) without spinning and to allow multiple writers to be queued when there is no space, rather than have them racing. The buffers are in the receiver's memory space because it is designed for resource constrained environments and for malicious parties to communicate, so it avoids a potential DoS by filling up kmem with buffers - a process that c reate a load of receive ports will simply fill up its own address space and die. In the specific case of binder, you can avoid the overhead of extra VM lookups by mapping the buffer into the address space of every sender when you open the connection, but marking its access as privileged mode only. This means that you'll be doing a simple copy. You can also align the receive buffer in such a way that the consume counter is on a different page to the rest of the data structure, allowing you to get a page fault when the buffer transitions from full to non-full and there are messages waiting. David ___ 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: copyin+copyout in one step ?
On Tue, May 28, 2013 at 6:56 AM, Zaphod Beeblebrox zbee...@gmail.comwrote: On Mon, May 27, 2013 at 7:38 PM, Luigi Rizzo ri...@iet.unipi.it wrote: say a process P1 wants to use the kernel to copy the content of a buffer SRC (in its user address space) to a buffer DST (in the address space of another process P2), and assume that P1 issues the request to the kernel when P2 has already told the kernel where the data should go: Urm... Isn't the use of shared memory the more obvious way to transfer data between processes? Am I missing some nuance? see my other message about the use between VMs. I cannot simply share memory because otherwise the sender could alter the message while the receiver is playing with it, so at least one copy is needed (or page flipping, but that would be way more complex/wasteful/ expensive) . But also, in my case the source and destination buffers are chosen arbitrarily by the two VMs, and do not necessarily reside in the mmapped buffers that the kernel module provides. So at the moment I have three copies instead of one. cheers luigi ___ 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: make: /usr/ports/mail/postfix/Makefile line 92: warning: Couldn't read shell's output ...
On Sun, May 26, 2013 at 08:39:36PM -0400, Michael Butler wrote: What's up with this? imb@toshi:/home/imb sudo portupgrade -aR make: /usr/ports/mail/postfix/Makefile line 92: warning: Couldn't read shell's output for /usr/bin/grep -m 1 '^purgestat' /etc/mail/mailer.conf || true I've been seeing this in a few other places. It looks like bmake prints this warning when the shell command in a '!=' assignment doesn't print anything to stdout. For instance, the line below will trigger a warning with bmake: FOO!=/usr/bin/true -Mark ___ 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: mounting root from NFS via ROOTDEVNAME
Hi,
to conclude this thread, the patch below allows one to specify an nfs rootfs
via the ROOTDEVNAME kernel option, which will be mounted when BOOTP does not
return a root-path option.
Lars
diff --git a/sys/nfs/bootp_subr.c b/sys/nfs/bootp_subr.c
index 2c57a91..972fb12 100644
--- a/sys/nfs/bootp_subr.c
+++ b/sys/nfs/bootp_subr.c
@@ -45,6 +45,7 @@ __FBSDID($FreeBSD$);
#include opt_bootp.h
#include opt_nfs.h
+#include opt_rootdevname.h
#include sys/param.h
#include sys/systm.h
@@ -870,8 +871,20 @@ bootpc_call(struct bootpc_globalcontext *gctx, struct
thread *td)
rtimo = time_second +
BOOTP_SETTLE_DELAY;
printf( (got root path));
- } else
+ } else {
printf( (no root path));
+#ifdef ROOTDEVNAME
+ /*
+* If we'll mount rootfs from
+* ROOTDEVNAME, we can accept
+* offers without root paths.
+*/
+ gotrootpath = 1;
+ rtimo = time_second +
+ BOOTP_SETTLE_DELAY;
+ printf( (ROOTDEVNAME));
+#endif
+ }
printf(\n);
}
} /* while secs */
@@ -1440,6 +1453,16 @@ bootpc_decode_reply(struct nfsv3_diskless *nd, struct
bootpc_ifcontext *ifctx,
p = bootpc_tag(gctx-tag, ifctx-reply, ifctx-replylen,
TAG_ROOT);
+#ifdef ROOTDEVNAME
+ /*
+* If there was no root path in BOOTP, use the one in ROOTDEVNAME.
+*/
+ if (p == NULL) {
+ p = strdup(ROOTDEVNAME, M_TEMP);
+ if (strcmp(strsep(p, :), nfs) != 0)
+ panic(ROOTDEVNAME is not an NFS mount point);
+ }
+#endif
if (p != NULL) {
if (gctx-setrootfs != NULL) {
printf(rootfs %s (ignored) , p);
___
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: Supermicro 6027R-N3RF+head, usb trouble
On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: Hi, Can anybody explain why USB keyboard (and keyboard from integrated IPKVM) doesn't work when I boot with 'C606 chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? Also I can't boot that box from usb memstick and FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both loose(?) device and can't find root If I disable controller in bios system can't see any sata hdd connected to it:( booting with hw.usb.ehci.no_hs=1, kern.cam.boot_delay=1 and debug.acpi.disabled=hostres without success. I setup dhcpd, tftp, nfs on my laptop and finally I install fbsd on that box, but question with kbd is open - It doesn't work.. dmesg: http://svn.freebsd.by/files/dmesg_N3RF.txt pciconf -lv: http://svn.freebsd.by/files/pciconf_N3RF.txt I would appreciate any hints I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE (disc1) seems ok though. Did you get this figured out? My startup: uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM ugen1.2: Unknown at usbus1 (disconnected) uhub_reattach_port: could not allocate new device -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
[head tinderbox] failure on i386/i386
TB --- 2013-05-28 14:50:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-28 14:50:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-28 14:50:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-05-28 14:50:20 - cleaning the object tree TB --- 2013-05-28 14:50:20 - /usr/local/bin/svn stat /src TB --- 2013-05-28 14:50:25 - At svn revision 251061 TB --- 2013-05-28 14:50:26 - building world TB --- 2013-05-28 14:50:26 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 14:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 14:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 14:50:26 - SRCCONF=/dev/null TB --- 2013-05-28 14:50:26 - TARGET=i386 TB --- 2013-05-28 14:50:26 - TARGET_ARCH=i386 TB --- 2013-05-28 14:50:26 - TZ=UTC TB --- 2013-05-28 14:50:26 - __MAKE_CONF=/dev/null TB --- 2013-05-28 14:50:26 - cd /src TB --- 2013-05-28 14:50:26 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue May 28 14:50:33 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue May 28 17:56:45 UTC 2013 TB --- 2013-05-28 17:56:45 - generating LINT kernel config TB --- 2013-05-28 17:56:45 - cd /src/sys/i386/conf TB --- 2013-05-28 17:56:45 - /usr/bin/make -B LINT TB --- 2013-05-28 17:56:46 - cd /src/sys/i386/conf TB --- 2013-05-28 17:56:46 - /usr/sbin/config -m LINT TB --- 2013-05-28 17:56:46 - building LINT kernel TB --- 2013-05-28 17:56:46 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 17:56:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 17:56:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 17:56:46 - SRCCONF=/dev/null TB --- 2013-05-28 17:56:46 - TARGET=i386 TB --- 2013-05-28 17:56:46 - TARGET_ARCH=i386 TB --- 2013-05-28 17:56:46 - TZ=UTC TB --- 2013-05-28 17:56:46 - __MAKE_CONF=/dev/null TB --- 2013-05-28 17:56:46 - cd /src TB --- 2013-05-28 17:56:46 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue May 28 17:56:46 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules Kernel build for LINT completed on Tue May 28 18:30:25 UTC 2013 TB --- 2013-05-28 18:30:25 - cd /src/sys/i386/conf TB --- 2013-05-28 18:30:25 - /usr/sbin/config -m LINT-NOINET TB --- 2013-05-28 18:30:25 - building LINT-NOINET kernel TB --- 2013-05-28 18:30:25 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 18:30:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 18:30:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 18:30:25 - SRCCONF=/dev/null TB --- 2013-05-28 18:30:25 - TARGET=i386 TB --- 2013-05-28 18:30:25 - TARGET_ARCH=i386 TB --- 2013-05-28 18:30:25 - TZ=UTC TB --- 2013-05-28 18:30:25 - __MAKE_CONF=/dev/null TB --- 2013-05-28 18:30:25 - cd /src TB --- 2013-05-28 18:30:25 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue May 28 18:30:25 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules Kernel build for LINT-NOINET completed on Tue May 28 19:01:17 UTC 2013 TB --- 2013-05-28 19:01:17 - cd /src/sys/i386/conf TB --- 2013-05-28 19:01:17 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-05-28 19:01:17 - building LINT-NOINET6 kernel TB --- 2013-05-28 19:01:17 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 19:01:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 19:01:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 19:01:17 - SRCCONF=/dev/null TB --- 2013-05-28 19:01:17 - TARGET=i386 TB --- 2013-05-28 19:01:17 - TARGET_ARCH=i386 TB --- 2013-05-28 19:01:17 - TZ=UTC TB --- 2013-05-28 19:01:17 - __MAKE_CONF=/dev/null TB --- 2013-05-28 19:01:17 - cd /src TB --- 2013-05-28 19:01:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Tue May 28 19:01:17 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules Kernel build for LINT-NOINET6 completed on Tue May 28 19:32:56 UTC 2013 TB --- 2013-05-28 19:32:56 - cd /src/sys/i386/conf TB --- 2013-05-28 19:32:56 - /usr/sbin/config -m LINT-NOIP TB --- 2013-05-28 19:32:56 - building LINT-NOIP kernel TB
Re: Incorrect comparison of ticks in deadlkres
On Sun, 2013-05-26 at 02:53 +0200, Attilio Rao wrote:
On Sat, May 25, 2013 at 11:55 PM, Ryan Stone ryst...@gmail.com wrote:
Currently deadlkres performs the following comparison when trying to check
for threads that have been blocked on a mutex or sleeping on an sx lock:
if (TD_ON_LOCK(td) ticks td-td_blktick) {
/* check for deadlock...*/
Yes the check looks indeed inverted.
The test against ticks is incorrect. It results in deadlkres only
signaling a deadlock after ticks has rolled over; at 1000 hz this will take
up to 49 days. From looking at the history of the code this test appears
to be a attempt to deal with ticks rollover. However this is necessary;
later on the code calculates the amount of time that has passed with:
tticks = ticks - td-td_blktick;
ticks was designed to exploit integer underflow in the case of rollover to
guarantee that subtraction produces correct results in all cases (other
than a double rollover, of course). I am going to remove the two incorrect
tests unless somebody can point out a overflow/underflow case that I
haven't considered.
I'm not sure I follow what are you saying.
Assume that when thread td goes to sleep, ticks is very close to the
32 bits limit. Then thread td goes to sleep and td-td_blktick is set
to a value very close to 32 bits limits.
After a while deadlkres thread kicks in and in the while ticks
counter overflowed, rolling back to a very low value. How are you
supposed to compute a valid value from this situation?
I think that you need to still guard about overflow of ticks for such cases.
ticks is defined as a signed integer but conceptually it is unsigned --
it increments from 0 to UINT_MAX (not INT_MAX) then rolls over. If
td-td_blktick is captured while ticks = UINT_MAX and later ticks has
rolled over and counted back up to 15, then ticks - td-td_blktick gives
an elapsed time of 16, as it should be. Whether exploiting this
property of signed overflow is elegant or ugly is in the eye of the
beholder. :)
If the intent of the ticks td-td_blktick is to avoid the deadlock
check until after enough time has passed, then I guess it should
probably be something more like (ticks - td-blktick) SOME_THRESHOLD
so that it also uses the signed overflow trick.
-- Ian
___
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: Incorrect comparison of ticks in deadlkres
On Tue, May 28, 2013 at 5:29 PM, Ian Lepore i...@freebsd.org wrote: ticks is defined as a signed integer but conceptually it is unsigned -- it increments from 0 to UINT_MAX (not INT_MAX) then rolls over. If td-td_blktick is captured while ticks = UINT_MAX and later ticks has rolled over and counted back up to 15, then ticks - td-td_blktick gives an elapsed time of 16, as it should be. Whether exploiting this property of signed overflow is elegant or ugly is in the eye of the beholder. :) If the intent of the ticks td-td_blktick is to avoid the deadlock check until after enough time has passed, then I guess it should probably be something more like (ticks - td-blktick) SOME_THRESHOLD so that it also uses the signed overflow trick. -- Ian It already does this later on to actually detect the deadlock. The test is reversed but was intended to bail and not calculate the time elapsed at all if ticks had overflowed after td_blktick was captured, but as you say this is unnecessary. ___ 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: Incorrect comparison of ticks in deadlkres
On Wed, May 29, 2013 at 1:18 AM, Ryan Stone ryst...@gmail.com wrote: On Tue, May 28, 2013 at 5:29 PM, Ian Lepore i...@freebsd.org wrote: ticks is defined as a signed integer but conceptually it is unsigned -- it increments from 0 to UINT_MAX (not INT_MAX) then rolls over. If td-td_blktick is captured while ticks = UINT_MAX and later ticks has rolled over and counted back up to 15, then ticks - td-td_blktick gives an elapsed time of 16, as it should be. Whether exploiting this property of signed overflow is elegant or ugly is in the eye of the beholder. :) If the intent of the ticks td-td_blktick is to avoid the deadlock check until after enough time has passed, then I guess it should probably be something more like (ticks - td-blktick) SOME_THRESHOLD so that it also uses the signed overflow trick. -- Ian It already does this later on to actually detect the deadlock. The test is reversed but was intended to bail and not calculate the time elapsed at all if ticks had overflowed after td_blktick was captured, but as you say this is unnecessary. I'm not sure if there was a comparison between the 2 values (ticks, td_slpticks) somewhere, but if there is not and only add/sub to the relative values then it is good to be removed. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: files disappearing from ls on NFS
Hartmut Brandt wrote:
On Wed, 15 May 2013, Rick Macklem wrote:
RMWell, getdents() basically just calls kern_getdirentries() and it
calls
RMVOP_READDIR() { which is called nfs_readdir() in the NFS clients }.
RMnfs_readdir() calls ncl_bioread() to do the real work of finding
the
RMbuffer cache blocks and copying the data out of them.
RMOne thing you might check via printf()s is whether the buffer cache
RMhas the zero'd data in it before it copies it to userland.
I now dump the data just before the call to vn_io_fault_iomove in
ncl_bioread(). So what I do:
1. reboot
2. login
3. ls
- I see that it is moving 4 blocks 4k each to the user and they look
fine
4. wait half an hour
5. ls
- now there is only one block, which contains zeros starting from
0x200.
Note that I don't do anything else on that machine during that time.
RMSince you get valid data sometimes and partially zero'd out data
others,
RMI haven't a clue what is going on. One other person reported a
problem
RMwhen they used a small readdirsize, but it is hard to say they saw
the
RMsame thing and no one else seems to be seeing this, so I have no
idea
RMwhat it might be.
RM
RMI remember you started seeing this after an upgrade of current. Do
you
RMhappen to have dates (or rNN) for the old working verion vs the
one that broke this?
RM(All I can think to do is scan the commits that seem to somehow
relate
RM to the buffer cache or copying to userland or ???)
It looks like I had copied the old kernel before installing the new
one
and it is from february 5th. There is no SVN revision in it - looks
like
that feature was added only recently.
harti
Thanks to Hartmut's testing, a patch to fix this problem has just
been committed to head as r251079. The problem was caused by
vnode_pager_setsize() being called for directories (where the
size reported by the server can be smaller than the size of the
ufs-like directory created in the client from the RPCs XDR).
r251079 will be MFC'd to stable/9 in 1 week if things go smoothly.
You might see this problem for head kernels between r248567-r251078
and stable/9 kernels from r249078 (Apr. 4) until a week from now.
Sorry for any inconvenience and thanks go to Hartmut for his help
isolating this, rick
RM
RMrick
RM
RM harti
RM
RM -Original Message-
RM From: Rick Macklem [mailto:rmack...@uoguelph.ca]
RM Sent: Tuesday, May 14, 2013 2:50 PM
RM To: Brandt, Hartmut
RM Cc: curr...@freebsd.org
RM Subject: Re: files disappearing from ls on NFS
RM
RM Hartmut Brandt wrote:
RM On Mon, 13 May 2013, Rick Macklem wrote:
RM
RM RMHartmut Brandt wrote:
RM RM On Sun, 12 May 2013, Rick Macklem wrote:
RM RM
RM RM RMHartmut Brandt wrote:
RM RM RM Hi,
RM RM RM
RM RM RM I've updated one of my -current machines this week
RM (previous
RM RM update
RM RM RM was in
RM RM RM february). Now I see a strange effect (it seems only
on
RM NFS
RM RM mounts):
RM RM RM ls or
RM RM RM even echo * will list only some files (strange enough
the
RM first
RM RM files
RM RM RM from
RM RM RM the normal, alphabetically ordered list). If I change
RM something
RM RM in the
RM RM RM directory (delete a file or create a new one) for
some
RM time
RM the
RM RM RM complete
RM RM RM listing will appear but after sime time (seconds to a
RM minute
RM or
RM RM so)
RM RM RM again
RM RM RM only part of the files is listed.
RM RM RM
RM RM RM A ktrace on ls /usr/src/lib/libc/gen shows that
RM getdirentries is
RM RM RM called
RM RM RM only once (returning 4096). For a full listing
RM getdirentries
RM is
RM RM called
RM RM RM 5
RM RM RM times with the last returning 0.
RM RM RM
RM RM RM I can still open files that are not listed if I know
their
RM name,
RM RM RM though.
RM RM RM
RM RM RM The NFS server is a Windows 2008 server with an
OpenText
RM NFS
RM RM Server
RM RM RM which
RM RM RM works without problems to all the other FreeBSD
machines.
RM RM RM
RM RM RM So what could that be?
RM RM RM
RM RM RMI've attached a patch that might be worth trying. It is
a
RM shot in
RM RM the dark,
RM RM RMbut brings the new NFS client's readdir closer to the
old
RM one
RM RM (which you
RM RM RMmentioned still works ok).
RM RM RM
RM RM RMPlease let me know how it goes, if you have a chance to
test
RM it,
RM RM rick
RM RM
RM RM Hi Rick,
RM RM
RM RM the patch doesn't help.
RM RM
RM RM I wrote a small test program, which opens a directory,
calls
RM RM getdents(2)
RM RM in a loop and dumps that. I figured out, that the return
of the
RM system
RM RM call depends on the buffer size I pass to it. The
directory has
RM a
RM RM block size of 4k according to fstat(2). If I use that, I
get
RM some
RM RM 300
RM of the
RM RM almost 500 directory entries. If I use 8k, I get just
around
RM 200
RM and
RM RM if I
RM RM use 16k I get a handfull. If
Re: BSD sleep
On 5/28/2013 6:01 PM, Kenta Suzumoto wrote: Hi. Is there no built-in way of making sleep sleep in increments of minutes, hours, etc? The GNU sleep can be invoked like sleep 1h for an hour. The FreeBSD one's manpage leads me to believe we can only use seconds, which is kind of annoying. Is there an undocmented or missing feature here? Seems really trivial to implement. ~ $ sleep 1h usage: sleep seconds You think it's trivial until you read this: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time If you sleep one hour, do you sleep one hour from now or one hour from the system clock which may change in the next hour? If it's the system clock, you may sleep for ten minutes or ten hours. If you need to sleep for 3600 seconds, that's simple and understandable. ___ 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
BSD sleep
Hi. Is there no built-in way of making sleep sleep in increments of minutes, hours, etc? The GNU sleep can be invoked like sleep 1h for an hour. The FreeBSD one's manpage leads me to believe we can only use seconds, which is kind of annoying. Is there an undocmented or missing feature here? Seems really trivial to implement. ~ $ sleep 1h usage: sleep seconds ___ 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
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-05-28 22:21:37 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-28 22:21:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-28 22:21:37 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-05-28 22:21:37 - cleaning the object tree TB --- 2013-05-28 22:21:37 - /usr/local/bin/svn stat /src TB --- 2013-05-28 22:21:40 - At svn revision 251061 TB --- 2013-05-28 22:21:41 - building world TB --- 2013-05-28 22:21:41 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 22:21:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 22:21:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 22:21:41 - SRCCONF=/dev/null TB --- 2013-05-28 22:21:41 - TARGET=powerpc TB --- 2013-05-28 22:21:41 - TARGET_ARCH=powerpc TB --- 2013-05-28 22:21:41 - TZ=UTC TB --- 2013-05-28 22:21:41 - __MAKE_CONF=/dev/null TB --- 2013-05-28 22:21:41 - cd /src TB --- 2013-05-28 22:21:41 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue May 28 22:21:48 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed May 29 00:54:36 UTC 2013 TB --- 2013-05-29 00:54:36 - generating LINT kernel config TB --- 2013-05-29 00:54:36 - cd /src/sys/powerpc/conf TB --- 2013-05-29 00:54:36 - /usr/bin/make -B LINT TB --- 2013-05-29 00:54:36 - cd /src/sys/powerpc/conf TB --- 2013-05-29 00:54:36 - /usr/sbin/config -m LINT TB --- 2013-05-29 00:54:36 - building LINT kernel TB --- 2013-05-29 00:54:36 - CROSS_BUILD_TESTING=YES TB --- 2013-05-29 00:54:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-29 00:54:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-29 00:54:36 - SRCCONF=/dev/null TB --- 2013-05-29 00:54:36 - TARGET=powerpc TB --- 2013-05-29 00:54:36 - TARGET_ARCH=powerpc TB --- 2013-05-29 00:54:36 - TZ=UTC TB --- 2013-05-29 00:54:36 - __MAKE_CONF=/dev/null TB --- 2013-05-29 00:54:36 - cd /src TB --- 2013-05-29 00:54:36 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed May 29 00:54:36 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules Kernel build for LINT completed on Wed May 29 01:14:26 UTC 2013 TB --- 2013-05-29 01:14:26 - cd /src/sys/powerpc/conf TB --- 2013-05-29 01:14:26 - /usr/sbin/config -m GENERIC TB --- 2013-05-29 01:14:26 - building GENERIC kernel TB --- 2013-05-29 01:14:26 - CROSS_BUILD_TESTING=YES TB --- 2013-05-29 01:14:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-29 01:14:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-29 01:14:26 - SRCCONF=/dev/null TB --- 2013-05-29 01:14:26 - TARGET=powerpc TB --- 2013-05-29 01:14:26 - TARGET_ARCH=powerpc TB --- 2013-05-29 01:14:26 - TZ=UTC TB --- 2013-05-29 01:14:26 - __MAKE_CONF=/dev/null TB --- 2013-05-29 01:14:26 - cd /src TB --- 2013-05-29 01:14:26 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed May 29 01:14:26 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules Kernel build for GENERIC completed on Wed May 29 01:30:18 UTC 2013 TB --- 2013-05-29 01:30:18 - cd /src/sys/powerpc/conf TB --- 2013-05-29 01:30:18 - /usr/sbin/config -m GENERIC64 TB --- 2013-05-29 01:30:18 - skipping GENERIC64 kernel TB --- 2013-05-29 01:30:18 - cd /src/sys/powerpc/conf TB --- 2013-05-29 01:30:18 - /usr/sbin/config -m MPC85XX TB --- 2013-05-29 01:30:18 - building MPC85XX kernel TB --- 2013-05-29 01:30:18 - CROSS_BUILD_TESTING=YES TB --- 2013-05-29 01:30:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-29 01:30:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-29 01:30:18 - SRCCONF=/dev/null TB --- 2013-05-29 01:30:18 - TARGET=powerpc TB --- 2013-05-29 01:30:18 - TARGET_ARCH=powerpc TB --- 2013-05-29 01:30:18 - TZ=UTC TB --- 2013-05-29 01:30:18 - __MAKE_CONF=/dev/null TB --- 2013-05-29 01:30:18 - cd /src TB --- 2013-05-29 01:30:18 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX Kernel build for MPC85XX started on Wed May 29 01:30:18 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules -- cd
Re: [head tinderbox] failure on powerpc/powerpc
The suspect commit was already reverted. Glen On Wed, May 29, 2013 at 01:33:11AM +, FreeBSD Tinderbox wrote: stage 3.3: building the modules -- cd /obj/powerpc.powerpc/src/sys/MPC85XX; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc MACHINE_ARCH=powerpc MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc/src/tmp _LDSCRIPTROOT= VERSION=FreeBSD 8.3-PRERELEASE amd64 803500 INSTALL=sh /src/tools/install.sh PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc/src/tmp/legacy/usr/games:/obj/powerpc.powerpc/src/tmp/legacy/bin:/obj/powerpc.powerpc/src/tmp/usr/sbin:/obj/powerpc.powerpc/src/tmp/usr/bin:/obj/powerpc.powerpc/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC=cc CXX=c++ CPP=cpp AS=as AR=ar LD=ld NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=gcc /obj/src/make.amd64/make -B -m /src/share/mk KERNEL=kernel modules-all -DN! O_MODULES_OBJ make: don't know how to make modules-all. Stop make: stopped in /obj/powerpc.powerpc/src/sys/MPC85XX *** Error code 2 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-29 01:33:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-29 01:33:11 - ERROR: failed to build MPC85XX kernel TB --- 2013-05-29 01:33:11 - 9953.65 user 1229.51 system 11494.62 real pgp_Vm1ZjPNJ8.pgp Description: PGP signature
Re: Supermicro 6027R-N3RF+head, usb trouble
On Tue, 28 May 2013 13:20:53 -0500 Bryan Drewery bdrew...@freebsd.org wrote: On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: Hi, Can anybody explain why USB keyboard (and keyboard from integrated IPKVM) doesn't work when I boot with 'C606 chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? Also I can't boot that box from usb memstick and FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both loose(?) device and can't find root If I disable controller in bios system can't see any sata hdd connected to it:( booting with hw.usb.ehci.no_hs=1, kern.cam.boot_delay=1 and debug.acpi.disabled=hostres without success. I setup dhcpd, tftp, nfs on my laptop and finally I install fbsd on that box, but question with kbd is open - It doesn't work.. dmesg: http://svn.freebsd.by/files/dmesg_N3RF.txt pciconf -lv: http://svn.freebsd.by/files/pciconf_N3RF.txt I would appreciate any hints I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE (disc1) seems ok though. Did you get this figured out? I added to loader.conf kern.maxbcache=128M vfs.maxbufspace=134217728 also I create /boot.config with '-v' I don't know what exactly help, but now usb kbd (ipkvm) works fine for me. p.s. It is smbios.system.product=X9DRW My startup: uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM ugen1.2: Unknown at usbus1 (disconnected) uhub_reattach_port: could not allocate new device -- wbr, tiger ___ 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
