Re: NUMA support; tweaking TCP for GPRS
On Fri, Dec 18, 2009 at 12:47:11PM +1100, Lawrence Stewart wrote: Sean Hamilton wrote: [...] Second, I am using a FreeBSD server to talk to equipment which has a GPRS internet connection. This is fairly high latency (approximately one second RTT) and is prone to bursts of packet loss, or bursts of extremely high latency -- perhaps up to a minute. These intervals cause many retransmissions, which I presume is a good strategy over the internet, but not so good for GPRS. For my application, latency is mostly irrelevant. However, data over GPRS is very expensive, so I would like to reduce as much as possible the number of TCP retransmissions made on the FreeBSD side, possibly at the expense of latency. So, I am looking for suggestions on how to achieve this, via sysctl, setsockopt, etc. There seems to be a lot of literature regarding TCP tuning, but usually the focus is on improving performance, not reducing network traffic. The rexmit_min and rexmit_sop sysctls mentioned in tcp(4) seem interesting, but it's not clear to me exactly how they might be adjusted for this purpose. Just back from 6 months of travel and a bit busy right now catching up on things, but ping me in a week or two about the TCP issue and I can provide some insights. At this point, the issue is mostly resolved -- we were seeing a huge number of TCP retransmissions, but this was due to braindead and undocumented behaviour on the GPRS device side, not FreeBSD's fault at all. Specifically, the TCP stack on the device (eCos-based, but possibly using the TCP stack in the GSM chipset -- not sure) was setting some of its parameters based on the requested GPRS service class. For instance, if the GPRS service class indicated a desired average RTT of 0.5s, then it would just retransmit every 0.5s, or something like that -- the exact behaviour is undocumented, but clearly laughably broken. Anyway, I am still really interested in what you might have to say about this. I have already increased the minimum retransmission interval to a few seconds, with some success. -- Sean Hamilton s...@bel.bc.ca ___ 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: something fails with svn
* jhell jh...@dataix.net wrote: With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp8fp9Jo6ghQ.pgp Description: PGP signature
linprocfs Input/output error
Hi all, I post here cause I didn't get any answers in freebsd-emulation. In 8.0-RELEASE-p1 if I try to execute this: cat /compat/linux/proc/cpuinfo ~/cpuinfo.txt I get cat: /compat/linux/proc/cpuinfo: Input/output error truss shows the read system call returns ERR#5. It is the same with other files from linprocfs. cat /compat/linux/proc/[any_file] works fine What am I missing? Thanks in advance ___ 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: linprocfs Input/output error
On Fri, Jan 01, 2010 at 06:45:33PM +0100, Fernando Apesteguía wrote: Hi all, I post here cause I didn't get any answers in freebsd-emulation. In 8.0-RELEASE-p1 if I try to execute this: cat /compat/linux/proc/cpuinfo ~/cpuinfo.txt I get cat: /compat/linux/proc/cpuinfo: Input/output error truss shows the read system call returns ERR#5. It is the same with other files from linprocfs. cat /compat/linux/proc/[any_file] works fine What am I missing? You are not missing anything, this is a bug. A while ago, cat(1) was changed to use larger buffers when writing to regular files on machines with sufficient RAM, usually a multiple of MAXPHYS. On the other hand, pseudofs (the general framework for filesystems such as procfs, linprocfs and linsysfs) in src/sys/fs/pseudofs/pseudofs_vnops.c pfs_read() fails any read over MAXPHYS + 1 with EIO. This limit probably has to do with the allocation of a buffer of that size using sbuf_new(9) (and so, malloc(9)). Some sort of limit seems appropriate, but MAXPHYS seems unrelated, and if the request is too long it should perhaps just truncate it. -- Jilles Tjoelker ___ 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: linprocfs Input/output error
2010/1/1 Jilles Tjoelker jil...@stack.nl: On Fri, Jan 01, 2010 at 06:45:33PM +0100, Fernando Apesteguía wrote: Hi all, I post here cause I didn't get any answers in freebsd-emulation. In 8.0-RELEASE-p1 if I try to execute this: cat /compat/linux/proc/cpuinfo ~/cpuinfo.txt I get cat: /compat/linux/proc/cpuinfo: Input/output error truss shows the read system call returns ERR#5. It is the same with other files from linprocfs. cat /compat/linux/proc/[any_file] works fine What am I missing? You are not missing anything, this is a bug. A while ago, cat(1) was changed to use larger buffers when writing to regular files on machines with sufficient RAM, usually a multiple of MAXPHYS. On the other hand, pseudofs (the general framework for filesystems such as procfs, linprocfs and linsysfs) in src/sys/fs/pseudofs/pseudofs_vnops.c pfs_read() fails any read over MAXPHYS + 1 with EIO. This limit probably has to do with the allocation of a buffer of that size using sbuf_new(9) (and so, malloc(9)). Some sort of limit seems appropriate, but MAXPHYS seems unrelated, and if the request is too long it should perhaps just truncate it. Thanks a lot for the explanation. -- Jilles Tjoelker ___ 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
TEMPer USB Thermometer
Various outfits including Brando are selling a cheap-ish USB thermometer named “TEMPer”. (I need one to monitor my home server closet.) I've put together a small command line utility that reads out the temperature from the LM75 sensor in the TEMPer: http://wiki.zs64.net/TEMPer_USB_Thermometer To run it, you will need to have the driver for WinChipHead USB-to-serial controller loaded (uchcom(8) on FreeBSD). It puts the LM75 into 12-bit resolution mode (about one measurement per second) and outputs temperature data once per second in degrees Celcius. The LM75 thermostat is connected to an LED, so you can use that as an indicator of temperature. Note that driving the LED dissipates enough power (probably through the current-limiting resistor) that the measured temperature rises by two degrees. usage: temper [-d device] [-h high] [-l low] [-n count] -d device USB serial port of the TEMPer -h high thermostat on temperature -l low thermostat off temperature -n countnumber of readings to take, 0 is infinite If the high temperature is below the low temperature, operation of the thermostat is reversed, and the output is turned on when the measured temperature is below the threshold. Enjoy! Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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
[PATCH] fts(3): allow FTS_LOGICAL without FTS_NOCHDIR
fts(3) currently automatically enables FTS_NOCHDIR if FTS_LOGICAL (-L in
various utilities) is used, according to a comment because symlinks are
too hard. However, the effect of fts_instr=FTS_FOLLOW seems quite
similar to FTS_LOGICAL in chdir mode. Using one more bit in fts_flags, I
made FTS_LOGICAL work with chdir.
This has several advantages:
* it runs faster
* it eliminates the PATH_MAX restriction on deep directory trees
* find -L ... -type l -delete can be made to work without ugliness
(although it is of course still insecure if run over directory trees
where untrusted users have write access)
Question: why are the values for fts_flags in the public header file
fts.h, even though they are supposedly private?
In case the mailing list eats the patch, it is also available here:
http://www.stack.nl/~jilles/unix/fts-logical-chdir.patch
--
Jilles Tjoelker
Index: include/fts.h
===
--- include/fts.h (revision 201269)
+++ include/fts.h (working copy)
@@ -106,6 +106,7 @@
#define FTS_DONTCHDIR 0x01 /* don't chdir .. to the parent */
#define FTS_SYMFOLLOW 0x02 /* followed a symlink to get here */
#define FTS_ISW 0x04 /* this is a whiteout object */
+#define FTS_DIRSYM 0x08 /* this is a symlink to a directory */
unsigned fts_flags; /* private flags for FTSENT structure */
#define FTS_AGAIN 1 /* read node again */
Index: lib/libc/gen/fts.c
===
--- lib/libc/gen/fts.c (revision 201269)
+++ lib/libc/gen/fts.c (working copy)
@@ -141,10 +141,6 @@
/* Shush, GCC. */
tmp = NULL;
- /* Logical walks turn on NOCHDIR; symbolic links are too hard. */
- if (ISSET(FTS_LOGICAL))
- SET(FTS_NOCHDIR);
-
/*
* Start out with 1K of path space, and enough, in any case,
* to hold the user's paths.
@@ -355,8 +351,10 @@
/* If skipped or crossed mount point, do post-order visit. */
if (instr == FTS_SKIP ||
(ISSET(FTS_XDEV) p-fts_dev != sp-fts_dev)) {
- if (p-fts_flags FTS_SYMFOLLOW)
+ if (p-fts_flags FTS_SYMFOLLOW) {
(void)_close(p-fts_symfd);
+p-fts_symfd = -1;
+ }
if (sp-fts_child) {
fts_lfree(sp-fts_child);
sp-fts_child = NULL;
@@ -385,6 +383,14 @@
* FTS_STOP or the fts_info field of the node.
*/
if (sp-fts_child != NULL) {
+ if (p-fts_flags FTS_DIRSYM
+ !(p-fts_flags FTS_SYMFOLLOW)) {
+if ((p-fts_symfd = _open(., O_RDONLY, 0)) 0) {
+ p-fts_errno = errno;
+ p-fts_info = FTS_ERR;
+} else
+ p-fts_flags |= FTS_SYMFOLLOW;
+ }
if (fts_safe_changedir(sp, p, -1, p-fts_accpath)) {
p-fts_errno = errno;
p-fts_flags |= FTS_DONTCHDIR;
@@ -674,8 +680,8 @@
nlinks = 0;
/* Be quiet about nostat, GCC. */
nostat = 0;
- } else if (ISSET(FTS_NOSTAT) ISSET(FTS_PHYSICAL)) {
- if (fts_ufslinks(sp, cur))
+ } else if (ISSET(FTS_NOSTAT)) {
+ if (ISSET(FTS_PHYSICAL) fts_ufslinks(sp, cur))
nlinks = cur-fts_nlink - (ISSET(FTS_SEEDOT) ? 0 : 2);
else
nlinks = -1;
@@ -707,7 +713,19 @@
*/
cderrno = 0;
if (nlinks || type == BREAD) {
- if (fts_safe_changedir(sp, cur, dirfd(dirp), NULL)) {
+ if (cur-fts_flags FTS_DIRSYM
+ !(cur-fts_flags FTS_SYMFOLLOW)) {
+ if ((cur-fts_symfd = _open(., O_RDONLY, 0)) 0) {
+if (nlinks type == BREAD)
+ cur-fts_errno = errno;
+cur-fts_flags |= FTS_DONTCHDIR;
+descend = 0;
+cderrno = errno;
+ } else
+cur-fts_flags |= FTS_SYMFOLLOW;
+ }
+ if (!(cur-fts_flags FTS_DONTCHDIR)
+ fts_safe_changedir(sp, cur, dirfd(dirp), NULL)) {
if (nlinks type == BREAD)
cur-fts_errno = errno;
cur-fts_flags |= FTS_DONTCHDIR;
@@ -796,7 +814,8 @@
} else if (nlinks == 0
#ifdef DT_DIR
|| (nostat
- dp-d_type != DT_DIR dp-d_type != DT_UNKNOWN)
+ dp-d_type != DT_DIR dp-d_type != DT_UNKNOWN
+ (dp-d_type != DT_LNK || ISSET(FTS_PHYSICAL)))
#endif
) {
p-fts_accpath =
@@ -883,7 +902,7 @@
FTSENT *t;
dev_t dev;
ino_t ino;
- struct stat *sbp, sb;
+ struct stat *sbp, sb, sb2;
int saved_errno;
/* If user needs stat info, stat buffer already allocated. */
@@ -923,6 +942,20 @@
if (S_ISDIR(sbp-st_mode)) {
/*
+ * Check if this is actually a symlink to a directory.
+ * If so, record this fact so we save a file descriptor
+ * to get back instead of using ...
+ */
+ if (ISSET(FTS_LOGICAL) !follow) {
+ if (lstat(p-fts_accpath, sb2)) {
+p-fts_errno = errno;
+goto err;
+ }
+ if (S_ISLNK(sb2.st_mode))
+p-fts_flags |= FTS_DIRSYM;
+ }
+
+ /*
* Set the device/inode. Used to find cycles and check for
* crossing mount points. Also remember the link count, used
* in fts_build to limit the number of stat calls. It is
___
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
[HEADSUP] Google SoC work on ext2fs to be committed
Hello, In a few days, I will commit the ext2fs improvements done by Aditya Sarawgi during and after Google Summer of Code to CURRENT. Some quick notes: - BSD licensed block and inode allocation policies for ext2fs. This involves the use FFS1 style block and inode allocation for ext2fs. Preallocation was removed since it was GPL'd. - Orlov Block Allocator for ext2fs. (Aditya can perhaps provide some details). - Some PR fixes and older bugs. - Make ext2fs MPSAFE by introducing locks to per-mount datastructures. More information along with nice shiny graphs can be found here: http://wiki.freebsd.org/SOC2009AdityaSarawgi and, of course, the code: http://gitorious.org/freebsd-ext2fs/freebsd-ext2fs As the work on support MP-safe operation may cause race conditions not discovered yet, it is important to report on these issues as they are encountered. Issues with the new implementation may be adressed to Aditya (CCed). http://wiki.freebsd.org/AdityaSarawgi -- Ulf Lilleengen ___ 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: something fails with svn
On 1/1/2010 6:24 AM, Ed Schouten wrote: * jhelljh...@dataix.net wrote: With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. You know really... I did not see anything that you have replied with to be constructive criticism At all. And personally if you really want to reply with remarks of Would you mind sharing your findings Sherlock Holmes You can then keep your comments to your self as I do not find them useful and my name is not Sherlock Holmes. Secondly I would expect a much more intelligent remark to come from someone with your background but I guess that comes with age. So my suggestion in constructiveness to you would be to think harder before you critique a post of the very same nature as the one you posted. As regards to the OP the email was meant as a confirmation to the author that the problem did lye on his end and that by paying closer attention to the paths that were displayed in the OP would have revealed the problem. -- jhell ___ 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: something fails with svn
the problem is at a standstill above always, only I did not see a sense so since I did not receive constructive feedback véáaszolni... otherwise i tested more things, but the situation did not change. // sorry for bad english, but I never learned it.. On 1/2/10, jhell jh...@dataix.net wrote: On 1/1/2010 6:24 AM, Ed Schouten wrote: * jhelljh...@dataix.net wrote: With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. You know really... I did not see anything that you have replied with to be constructive criticism At all. And personally if you really want to reply with remarks of Would you mind sharing your findings Sherlock Holmes You can then keep your comments to your self as I do not find them useful and my name is not Sherlock Holmes. Secondly I would expect a much more intelligent remark to come from someone with your background but I guess that comes with age. So my suggestion in constructiveness to you would be to think harder before you critique a post of the very same nature as the one you posted. As regards to the OP the email was meant as a confirmation to the author that the problem did lye on his end and that by paying closer attention to the paths that were displayed in the OP would have revealed the problem. -- jhell ___ 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: something fails with svn
and the newest log: M COPYRIGHT r201336 = a1f0e71ec85d326f0cb79b829129279961a36ed9 (refs/remotes/git-svn) M lib/libc/gen/time.3 M lib/libc/sys/clock_gettime.2 Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/lib/libc/stdtime Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc/stdtime Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/lib/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc r201363 = b04276d84884164bf0878eb7d11f3100bcdcd3a0 (refs/remotes/git-svn) Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/kmacy/releng_7_2_fcs/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys/contrib/pf r201365 = 4ad205e7e4ca78fc6ac8e5e9ea81b2199339917f (refs/remotes/git-svn) First, rewinding head to replay your work on top of it... Fast-forwarded master to refs/remotes/git-svn. From /usr/data/source/git/7-STABLE 00e48c1..4ad205e master - origin/master Merge made by recursive. COPYRIGHT|2 +- lib/libc/gen/time.3 |1 + lib/libc/sys/clock_gettime.2 | 55 + 3 files changed, 46 insertions(+), 12 deletions(-) the master local git repo don't touched, only synced with freebsd's svn repo, and the local commit are in second git tree commited, say it as: ~/src/, and the master is /usr/data/source/git/7-STABLE - this is a simple _git svn rebase_ based git tree. the command with synced the tree is: alias src_update '(cd /usr/data/source/git/7-STABLE.git; git svn rebase; cd ~/src; git pull) | less' so, the all process show as this: 1) cd /usr/data/source/git/7-STABLE.git # can't comment.. 2) git svn rebase # this fetched the source from svn://svn.freebsd.org/base/stable/7, and then updated the git repo 3) cd ~/src # can't comment.. 4) git pull # this fetched from the GIT repo the source, this runned without error So, the error is somewhere in process 2). And the errors in log is recently this files: svn://svn.freebsd.org/base/stable/7/head/lib/libc/stdtime svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc/stdtime svn://svn.freebsd.org/base/stable/7/head svn://svn.freebsd.org/base/stable/7/head/lib/libc svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris svn://svn.freebsd.org/base/stable/7/head/sys svn://svn.freebsd.org/base/stable/7/stable/8/sys svn://svn.freebsd.org/base/stable/7/user/kmacy/releng_7_2_fcs/sys svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf svn://svn.freebsd.org/base/stable/7/stable/8/sys/contrib/pf svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys/contrib/pf when you see the PATHs, then its showed as: 7-STABLE_base_path+do something else and at the end, i synced with this process my source code over one year, but it showed since ~1 week, as the first mail wroted.. On 1/2/10, Oliver Pinter oliver.p...@gmail.com wrote: the problem is at a standstill above always, only I did not see a sense so since I did not receive constructive feedback véáaszolni... otherwise i tested more things, but the situation did not change. // sorry for bad english, but I never learned it.. On 1/2/10, jhell jh...@dataix.net wrote: On 1/1/2010 6:24 AM, Ed Schouten wrote: * jhelljh...@dataix.net wrote: With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. You know really... I did not see anything that you have replied with to be constructive criticism At all. And personally if you really want to reply with remarks of Would you mind sharing your findings Sherlock Holmes You can then keep your comments to your self as I do not find them useful and my name is not Sherlock Holmes. Secondly I would expect a much more intelligent remark to come from someone with your background but I guess that comes with age. So my suggestion in constructiveness to you would be to think harder before
Re: something fails with svn
Date: Fri, 01 Jan 2010 19:20:54 -0500 From: jhell jh...@dataix.net Sender: owner-freebsd-sta...@freebsd.org On 1/1/2010 6:24 AM, Ed Schouten wrote: * jhelljh...@dataix.net wrote: With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. You know really... I did not see anything that you have replied with to be constructive criticism At all. And personally if you really want to reply with remarks of Would you mind sharing your findings Sherlock Holmes You can then keep your comments to your self as I do not find them useful and my name is not Sherlock Holmes. Secondly I would expect a much more intelligent remark to come from someone with your background but I guess that comes with age. So my suggestion in constructiveness to you would be to think harder before you critique a post of the very same nature as the one you posted. As regards to the OP the email was meant as a confirmation to the author that the problem did lye on his end and that by paying closer attention to the paths that were displayed in the OP would have revealed the problem. OK. I will try to say something constructive. You seem to think that clever, useless comments make you look good. As someone who has been working with FreeBSD and the FreeBSD community for a long time, all you really do is make yourself look juvenile, arrogant, and rude. You are a prime example of why many people approaching the FreeBSD community for help claim that we are an arrogant and rude bunch. The information content of your messages approaches zero. Maybe the problem is trivial and obvious to you. Maybe it would be to Ed, if he could spot it. Now, if you have never missed an obvious bug until you asked someone why the code would not work, you are either truly exceptional (along with the adjectives listed above) or have written little or no code of your own. Please either provide reasonable assistance when responding to questions or don't reply at all. No one likes a smart ass, plonk -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: something fails with svn
the git config is: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote svn] url = svn://svn.freebsd.org/base/stable/7 fetch = :refs/remotes/git-svn It looks like the error is on the line I've highlighted(note that it's trying to fetch files under svn://svn.freebsd.org/base/stable/7/head, which clearly won't work). I don't know anything about git so I can't give advice as to how to accomplish what you're trying to do. ___ 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: something fails with svn
yeah, but svn.freebsd.org/base/stable/7/head don't exist. git svn log -v some of broken infos find in this commit: r200570 | stas | 2009-12-15 11:34:05 +0100 (Tue, 15 Dec 2009) | 23 lines Changed paths: M share/man/man4/bge.4 M sys/dev/bge/if_bge.c M sys/dev/bge/if_bgereg.h - MFC r197832, r197834, r197837: - Add support for new BGE chips (5761, 5784 and 57780). These chips uses new BGE_PCI_PRODID_ASICREV register to store the chip identifier and its revisio n. - Add new grouping macro for 7575+ chips (BGE_IS_5755_PLUS). - Add IDs for Fujitsu-branded Broadcom adapters. PR:If a GNATS PR is affected by the change. Submitted by: If someone else sent in the change. Reviewed by: If someone else reviewed your modification. Approved by: If you needed approval for this commit. Obtained from: If the change is from a third party. MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email. Security: Vulnerability reference (one per line) or description. Empty fields above will be automatically removed. _M 7/share/man/man4 M7/share/man/man4/bge.4 _M 7/sys M7/sys/dev/bge/if_bgereg.h M7/sys/dev/bge/if_bge.c _M 7/sys/contrib/pf _M 7/sys/contrib/dev/acpica _M 7/sys/cddl/contrib/opensolaris On 1/2/10, Ryan Stone ryst...@gmail.com wrote: the git config is: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote svn] url = svn://svn.freebsd.org/base/stable/7 fetch = :refs/remotes/git-svn It looks like the error is on the line I've highlighted(note that it's trying to fetch files under svn://svn.freebsd.org/base/stable/7/head, which clearly won't work). I don't know anything about git so I can't give advice as to how to accomplish what you're trying to do. ___ 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: something fails with svn
hmmm, it's look like this: http://lists-archives.org/git/707921-git-svn-memoize-conversion-of-svn-merge-ticket-info-to-git-commit-ranges.html git releated change is the source of the warnings.. and the git is updated at Dec 28 20:39 ll /usr/local/bin/git -rwxr-xr-x 95 root wheel 1066766 Dec 28 20:39 /usr/local/bin/git so i have this workaround: --8-- alias src_update '(cd /usr/data/source/git/7-STABLE.git; '\ 'git svn rebase' \ '| grep -E -v ^Couldn.t find revmap for svn://svn\.freebsd\.org/base/stable/7;' \ 'cd ~/src;' \ 'git pull)' \ '| less' --8-- and sorry for noise.. ps.: added the git patch author to cc On 1/2/10, Oliver Pinter oliver.p...@gmail.com wrote: yeah, but svn.freebsd.org/base/stable/7/head don't exist. git svn log -v some of broken infos find in this commit: r200570 | stas | 2009-12-15 11:34:05 +0100 (Tue, 15 Dec 2009) | 23 lines Changed paths: M share/man/man4/bge.4 M sys/dev/bge/if_bge.c M sys/dev/bge/if_bgereg.h - MFC r197832, r197834, r197837: - Add support for new BGE chips (5761, 5784 and 57780). These chips uses new BGE_PCI_PRODID_ASICREV register to store the chip identifier and its revisio n. - Add new grouping macro for 7575+ chips (BGE_IS_5755_PLUS). - Add IDs for Fujitsu-branded Broadcom adapters. PR:If a GNATS PR is affected by the change. Submitted by: If someone else sent in the change. Reviewed by: If someone else reviewed your modification. Approved by: If you needed approval for this commit. Obtained from: If the change is from a third party. MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email. Security: Vulnerability reference (one per line) or description. Empty fields above will be automatically removed. _M 7/share/man/man4 M7/share/man/man4/bge.4 _M 7/sys M7/sys/dev/bge/if_bgereg.h M7/sys/dev/bge/if_bge.c _M 7/sys/contrib/pf _M 7/sys/contrib/dev/acpica _M 7/sys/cddl/contrib/opensolaris On 1/2/10, Ryan Stone ryst...@gmail.com wrote: the git config is: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote svn] url = svn://svn.freebsd.org/base/stable/7 fetch = :refs/remotes/git-svn It looks like the error is on the line I've highlighted(note that it's trying to fetch files under svn://svn.freebsd.org/base/stable/7/head, which clearly won't work). I don't know anything about git so I can't give advice as to how to accomplish what you're trying to do. ___ 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: something fails with svn
On 1/1/2010 8:21 PM, Kevin Oberman wrote: Date: Fri, 01 Jan 2010 19:20:54 -0500 From: jhelljh...@dataix.net Sender: owner-freebsd-sta...@freebsd.org On 1/1/2010 6:24 AM, Ed Schouten wrote: * jhelljh...@dataix.net wrote: With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. You know really... I did not see anything that you have replied with to be constructive criticism At all. And personally if you really want to reply with remarks of Would you mind sharing your findings Sherlock Holmes You can then keep your comments to your self as I do not find them useful and my name is not Sherlock Holmes. Secondly I would expect a much more intelligent remark to come from someone with your background but I guess that comes with age. So my suggestion in constructiveness to you would be to think harder before you critique a post of the very same nature as the one you posted. As regards to the OP the email was meant as a confirmation to the author that the problem did lye on his end and that by paying closer attention to the paths that were displayed in the OP would have revealed the problem. OK. I will try to say something constructive. You seem to think that clever, useless comments make you look good. As someone who has been working with FreeBSD and the FreeBSD community for a long time, all you really do is make yourself look juvenile, arrogant, and rude. You are a prime example of why many people approaching the FreeBSD community for help claim that we are an arrogant and rude bunch. That's great and all but have you read the reply that I had originally made to the OP. It does not seem like it from your comments. The information content of your messages approaches zero. Maybe the problem is trivial and obvious to you. Maybe it would be to Ed, if he could spot it. Now, if you have never missed an obvious bug until you asked someone why the code would not work, you are either truly exceptional (along with the adjectives listed above) or have written little or no code of your own. Please either provide reasonable assistance when responding to questions or don't reply at all. No one likes a smart ass, Reasonable assistance I think that was pretty reasonable, I do not recall anyone paying something for anything I have said and it seemed to me that he was asking for more of a confirmation. plonk I do not like smart asses either, which in turn is why I am still replying to comments about the followup and why I don't know that I feel I should have to defend my self on this matter. For one: The followup that I had made as I already stated was confirming the problem was on his end and in no way that I see was offending, maybe I could have choose different words but that does not relieve the response I had received after from Ed. For two: If you want to call someone something call them by the respective name or email address that they have spoken with. I do not ever recall naming Ed anything other than his own name nor anyone else. As spoken do on to others as you would do onto your self. I repeat my name is not Sherlock Holmes. Thirdly: Constructive ? there was nothing non-constructive about the followup I had made. I have missed plenty of things in the past and would never claim otherwise and the information that I offered certainly was not complete but was meant not to be, and not in a critiquing manner. -- jhell ___ 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
