Re: What is HIDE_POSIX HIDE_BSD?
On Tue, Jan 29, 2002 at 03:58:16PM -0500, Zhihui Zhang wrote: While adding a system call, I notice in file syscall-hide.h there are many instances of HIDE_POSIX() and HIDE_BSD(). What is the purpose of these macros? Maybe they are now obsolete? The syscalls-hide.h file was generated from sys/kern/makesyscalls.sh from the third field of sys/kern/syscalls.master - POSIX, BSD or NOHIDE. However, three months ago Poul Henning-Kamp removed the syscalls-hide.h file and the relevant parts of makesyscalls.sh. I think that this may be scheduled for MFC'ing some time in the future, but you might have to ask phk for specifics. Also, I would also like to know what was the original purpose of the POSIX/BSD/NOHIDE distinction. BTW, should that field be removed from syscalls.master, too? G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD-1.X public cvs?
On Tue, Jan 29, 2002 at 11:53:41PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Nate Williams write s: Caldera's License Agreement: http://www.tuhs.org/Archive/Caldera-license.pdf Thanks. However, this isn't as specific as I'd like it to be. It implies that Net1/Net2 are now 'legal', but it doesn't give explicit release of said source code. Well, I have never heard claims that BSD was tainted by any USL release besides 32V, so this is good enough for me to put my 1.X tree up without fearing ugly lawyers. Now, where did all those CD's go... If all else fails I have stored my FreeBSD 1.0 CD as a precious gem ;) Cannot find the 386BSD 0.1 + PK024 QIC tape though :( -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: multiple mounts of single device
man mount_nullfs. Remember to read the warning at the bottom of the man page. kt On Tue, Jan 29, 2002 at 09:14:35PM -0800, Gregory Neil Shapiro wrote: brent I've been searching for info regarding mounting the same device brent to multiple locations in the filesystem, i.e... brent # mount /dev/ad0s1e /usr brent # mount -r /dev/ad0s1e /var/jail//usr brent # mount -r /dev/ad0s1e /var/jail//usr I can't comment on this specifically but can tell you that I use localhost NFS mounts to accomplish this with jails under RELENG_4. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
HOW to debug memory corruption efficiently?
Hello everyone! I have a problem using some third party C++ library. After returning from a seemingly innocent function call my stack frame gets destroyed step by step --- and maybe other parts of memory as well. Unfortunately I'm neither proficient in C++ nor efficient in debugging, so I stumble around the problem rather blindfolded. Once I blamed the compiler, systemlibraries and operating system, I knew I needed some help. The problem appeared on a linux system, but I guess the techniques I might need will be the same under Linux, FreeBSD or any un*x. I checked the program execution using gdb and found that in the cleanup code after the function call (this is under Linux, so I will not present the assembler, as I guess clean up will be different under freebsd) something strange happens. When displaying the backtrace with gdb, the debugger suddenly complains: 6 card = new DAQ::SISO::Grabber(1); (gdb) bt #0 DAQ::SISO::Slave::Slave (this=0xb65b) at Slave.cc:6 #1 0x0804a352 in main () at test.cc:10 #2 0x400df65f in __libc_start_main () from /lib/libc.so.6 (gdb) n 10 card-LoadFramegrabberDesign( const_castchar *(name), 26, 52 ); (gdb) bt #0 DAQ::SISO::Slave::Slave (this=0xb65b) at Slave.cc:10 #1 0x0804a352 in main () at test.cc:10 #2 0x400df65f in __libc_start_main () from /lib/libc.so.6 Cannot access memory at address 0xbf080506 I stepped (s) and single stepped (si) over ther card = new ... command. The 'Cannot access memory' appears four single steps after finish returns from the Constructor. So not while within the Constructor or any function called from there. The assembler command after which the strange message appears seems to restore the basepointer (i386). Later during program execution (everytime after a method call using card-method(); my stack frame gets corrupted slowly or the message 'Cannot access memory' changes to complain about different adresses. I guess that somewhere within the Constructor or some function called therein my stack and registers stored there get corrupted due to a memory leak, freak pointer, etc. Is there an efficient way to find out which part of the program is responsible for the corruption. I.e. is there an efficient way to fix the blame either to my code or the third party libraries :)? Or is there another likely cause of this problem, which has nothing to do with freak pointers or the libraries, but with using C++ wrong. I compiled using -Wall and got no warnings. Sincerely, Ronbert S. -- Robert Suetterlin ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: SurfBoard SB1000 cable modem in FreeBSD?
If I recall correctly, doesn't the surfboard 1000-1100 service uni-directional cable? What kind of connection does your friend have? D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mario Sergio Fujikawa Ferreira Sent: Tuesday, January 29, 2002 10:51 PM To: [EMAIL PROTECTED] Cc: Marcelo Cunha; Jose Antonio Junior Subject: SurfBoard SB1000 cable modem in FreeBSD? Hi, I was trying to help a friend get a SurfBoard SB1000 cable modem working in a Linux box much to my pain. I mean trying because I failed horribly. :( At first, I tried looking for support under FreeBSD but found none. Then, I tried to get it working under Linux since it seems to be supported. I'll spare the details since this is not the place for non-FreeBSD stuff. HEheh However, Linux has been such a pain to kernel configure and system update (not to mention isapnp configure) that I am trying to ask here if there is a beta around or anything that would even remotely get a SurfBoard SB1000 working. I am sure that most of my pain with Linux comes from my inexperience with it since I've been mostly away for the past 4 years which I do not regret from the damned questionary when I try to compile a kernel. No flame wars please, I am sure people use it just fine. :) Anyone? Ideas on how to get the linux kernel module binary to work? Well, we were lucky with the aureal-kmod port. More information about it can be found at - Original driver written for Linux by Franco Venturi in 1998 http://www.jacksonville.net/~fventuri/ The driver can be found under any Linux kernel at drivers/net/sb1000.[ch] No flames please. I know the card is old but my friend has no choices. Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. Computer Science Undergraduate | FreeBSD Committer | CS Developer flames to beloved [EMAIL PROTECTED] feature, n: a documented bug | bug, n: an undocumented feature To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SurfBoard SB1000 cable modem in FreeBSD?
On Wed, Jan 30, 2002 at 08:42:22AM -0500, raymond hicks wrote: uni-directional cable? What kind of connection does your friend have? He lives in a area where both isdn and adsl do not work. Furthermore, much for his dismay, bi-directional cable (actually radio) does not work due to visibility issues. Therefore, he is stuck with uni-directional downstream. Upstream is handled by a 56K modem. -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. Computer Science Undergraduate | FreeBSD Committer | CS Developer flames to beloved [EMAIL PROTECTED] feature, n: a documented bug | bug, n: an undocumented feature To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
uiomove busted for the past 3 years
When the DEADLKTREAT flag was added, uiomove() was broken. :) The problem is that a return() inside of a switch nested inside of a while loop was converted to a break leading to the following rather silly code: if (error) break; break; What is supposed to happen is that if there is an error, we break out of the while loop, but all we do is break out of the switch ignoring the error and continuing to loop. Thus, in the best case, if copyin or copyout failed on the last iteration of the loop, we would return an error, but would bogusly update the counts in the iovec and uio structures. In the worst case, if we kept looping and later copyin's or copyout's succeeded, then we wouldn't return an error at all. A quick fix would be to add a goto to jump to the error return code at the end of the loop rather than the bogus break if (error). However, I can't test this at the moment. Someone please verify and fix this. I think it's broken in RELENG_3 as well if someone is adventurous enough to merge it that far. I guess copyin/copyout don't fail often. -- John Baldwin [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OS Textbook FreeBSD Appendix
On Tue, 29 Jan 2002 [EMAIL PROTECTED] wrote: As far as I remember from reading the Lyons' book, there were 16 mapping descriptors for text and data each. I think, 1/16 of the address space is not too big, and in absolute values it's the size of today's pages (4KB). well I had dropped this thread as I figured the list would not want to hear it, but yes you're right. The KT-11 MMU worked this way. I still have my manuals, as it was a pretty interesting piece of hardware. Unix was the first OS to actually use the split I/D capability, so while the various DEC OSes were stuck at 64K Unix programs could run at 64kI/64kD. Also user mode/super mode/kernel mode each got its own set. There was also a weird instruction called MFPU (move from previous user space) that allowed bcopy shared memory-type programming. Once again Unix actually used this, the DEC OSes did not, so Unix was the first to find the bugs in this hardware too. Once university as I recall actually added the wire to its machine to make MFPU work correctly ... The kinds of things you had to do in Unix on an 18-bit-physical address space machine with 16-bit addressing bear interesting similarities to what we have to do now on 36-bit mode Pentiums with 32-bit addresses. What goes around comes around ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: OS Textbook FreeBSD Appendix
Once again Unix actually used this, the DEC OSes did not, so Unix was the first to find the bugs in this hardware too. I think the first sentence is not true. The RT-11 XM monitor uses the MMU hardware intensively even before Unix came to utilize it. I'm not talking about RSX-11, RSTS-E and Sherrard's TSX-Plus which were native real multiuser's muliprocessors OS's for PDP-11. Igor. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
buildworld via ro mounted /usr/src
hello everybody! i am trying to accomplish this (should be fairly easy) task: cvsupping /usr/ports /usr/src on a central file server. and building world/kernel via nfs mounts. in order not to get things mixed up i share /usr/ports and /usr/src ro and /usr/ports/distfiles, /usr/obj rw. should work as desired: WRKDIRPREFIX set to a reasonable value (depending on arch and cpu) and MAKEOBJDIRPREFIX too. but *somehow* some tools appear to be built into /usr/src and not into /usr/obj (as it should be). might be that's just the bootstrapping tools, but why? and how do i change this behavior? i didn't find a good (any) guide to this on the net. reading makefiles also didn't give me any conclusion. thanks in advance, cheerz simon -- /\ http://corecode.ath.cx/ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News msg31253/pgp0.pgp Description: PGP signature
Re: FreeBSD-1.X public cvs?
Caldera's License Agreement: http://www.tuhs.org/Archive/Caldera-license.pdf Thanks. However, this isn't as specific as I'd like it to be. It implies that Net1/Net2 are now 'legal', but it doesn't give explicit release of said source code. Well, I have never heard claims that BSD was tainted by any USL release besides 32V, so this is good enough for me to put my 1.X tree up without fearing ugly lawyers. Now, where did all those CD's go... If all else fails I have stored my FreeBSD 1.0 CD as a precious gem ;) Cannot find the 386BSD 0.1 + PK024 QIC tape though :( A FreeBSD 1.X CVS tree has been found, which has it's first import as 386BSD 0.1 + PK 024. There are a couple minor points that need to be clarified from Caldera before it can be made public. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD-1.X public cvs?
On Wed, Jan 30, 2002 at 09:41:15AM -0700, Nate Williams wrote: A FreeBSD 1.X CVS tree has been found, which has it's first import as 386BSD 0.1 + PK 024. There are a couple minor points that need to be clarified from Caldera before it can be made public. Just curious, but will this be folded in the main CVS tree, or will it be available as a separate tree/cvsup dist? I'd imagine that the CVS hackery needed to implement the former takes a lot of time... --Stijn -- I'm not under the alkafluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get. msg31255/pgp0.pgp Description: PGP signature
Re: FreeBSD-1.X public cvs?
A FreeBSD 1.X CVS tree has been found, which has it's first import as 386BSD 0.1 + PK 024. There are a couple minor points that need to be clarified from Caldera before it can be made public. Just curious, but will this be folded in the main CVS tree, or will it be available as a separate tree/cvsup dist? I'd imagine that the CVS hackery needed to implement the former takes a lot of time... It would be *way* too much work to fold it into the release. You'd end up with a completely different CVS tree, and have little/no gain from doing it. I also don't see the FreeBSD project making it available as a CVSup dist either. *IF* it's made publically available, I could see it as a port or something like that. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD-1.X public cvs?
In message [EMAIL PROTECTED], Stijn Hoop writes: --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 30, 2002 at 09:41:15AM -0700, Nate Williams wrote: A FreeBSD 1.X CVS tree has been found, which has it's first import as 386BSD 0.1 + PK 024. There are a couple minor points that need to be clarified from Caldera before it can be made public. Just curious, but will this be folded in the main CVS tree, or will it be available as a separate tree/cvsup dist? I'd imagine that the CVS hackery needed to implement the former takes a lot of time... It will not be folded in. But if somebody were into a _real_ tour de force of history, they would try to slurp all of the true UNIX's into a joint tree now, CVS is probably not up to it, but perforce might be. now _THAT_ would be usable history online... :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD-1.X public cvs?
On Wed, Jan 30, 2002 at 06:57:37PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Stijn Hoop writes: On Wed, Jan 30, 2002 at 09:41:15AM -0700, Nate Williams wrote: A FreeBSD 1.X CVS tree has been found, which has it's first import as 386BSD 0.1 + PK 024. There are a couple minor points that need to be clarified from Caldera before it can be made public. Just curious, but will this be folded in the main CVS tree, or will it be available as a separate tree/cvsup dist? I'd imagine that the CVS hackery needed to implement the former takes a lot of time... It will not be folded in. But if somebody were into a _real_ tour de force of history, they would try to slurp all of the true UNIX's into a joint tree now, CVS is probably not up to it, but perforce might be. now _THAT_ would be usable history online... :-) Not to mention an incredably cool and insane job at the same time! (but I'm not applying :) Points noted, I'm anxious to see the code, whether as a port or something else. To Caldera, a compliment in advance: thanks for letting this piece of history get out! --Stijn -- Q: Why is Batman better than Bill Gates? A: Batman was able to beat the Penguin. msg31258/pgp0.pgp Description: PGP signature
Re: multiple mounts of single device
Brent Verner writes: Hi, I've been searching for info regarding mounting the same device to multiple locations in the filesystem, i.e... # mount /dev/ad0s1e /usr # mount -r /dev/ad0s1e /var/jail//usr # mount -r /dev/ad0s1e /var/jail//usr There was a time I mounted the same _file system_ to multiple locations. I made some part of disk with a lot of names and mount different devices with the same file system to different mount point. For example: 0garkin~(6)disklabel ad0s3 # /dev/ad0s3c: type: ESDI disk: auto label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16128 sectors/unit: 16257024 rpm: 7200 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 1625702404.2BSD 1024 819263 # (Cyl.0 - 16127) b: 1625702404.2BSD 1024 819263 # (Cyl.0 - 16127) c: 1625702404.2BSD 1024 819263 # (Cyl.0 - 16127) d: 1625702404.2BSD 1024 819263 # (Cyl.0 - 16127) e: 1625702404.2BSD 1024 819263 # (Cyl.0 - 16127) f: 1625702404.2BSD 1024 819263 # (Cyl.0 - 16127) g: 1625702404.2BSD 1024 819263 # (Cyl.0 - 16127) h: 1625702404.2BSD 1024 819263 # (Cyl.0 - 16127) Warning, partition c is not marked as unused! Warning, An incorrect partition c may cause problems for standard system utilities More of that, you can mark partition (ad0s3 in this case) with 0x05 type (extetded) and use 5 sets as the same fs: ad0s3a..h, ad0s5a..h to ad0s8a..h 0garkin~(9)fdisk ad0s3 *** Working on device /dev/ad0s3 *** parameters extracted from in-core disklabel are: cylinders=16128 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=16128 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 16257024 (7938 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 0; end: cyl 767/ sector 63/ head 15 The data for partition 2 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 16257024 (7938 Meg), flag 0 beg: cyl 0/ sector 1/ head 0; end: cyl 767/ sector 63/ head 15 The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 16257024 (7938 Meg), flag 0 beg: cyl 0/ sector 1/ head 0; end: cyl 767/ sector 63/ head 15 The data for partition 4 is: sysid 5,(Extended DOS) start 0, size 16257024 (7938 Meg), flag 0 beg: cyl 0/ sector 1/ head 0; end: cyl 767/ sector 63/ head 15 and more, you can mark one of s5..s8 partitions with 0x05 type and use loop until s30. But the last method is not safe for all kernels - some just drop the error at loop end and work as expected, some crush. The dark side is that the only file system used as different file systems - buffer cashe and vnodes are different - memory exhaust. Now I use null mount - it works now good enough in jails ro mounts and is not so memory expansive And one more trick: 0grimble~(7)l -o /jail/pop1/usr/libexec/ld-elf.so.1 73 -r-xr-xr-x 24 root wheel schg,sunlnk 74352 18 Á×Ç 2000 /jail/pop1/usr/libexec/ld-elf.so.1* ^^ multiple used files - lot of jails use the same fs with the only set of common files linked to different jails hierarchies. I cook now the helper package to set up light wait jails (jail per function) in that techics. Sorry, my English is bad. [Warning: I /know/ I know next-to-nothing about filesystems... but] I recall seeing some traffic (IIRC, from early 2001) about this ability being in -current, but looking at HEAD:/usr/sys/ufs/ffs/ffs_vfsops.c, I still see around line 571 that EBUSY is still being returned if the device is already mounted. Not being familiar with the fbsd code... Am I even in the correct ballpark? Or is this functionality already present in -current? If it is already in -current, where would I start digging around if I felt like (breaking a perfectly good 4.5 install and) trying to integrate the -current code into 4.5? I'd especially appreciate any two minute (or less) response to any of the following questions -- I'm perfectly comfortable being told go away and read, if I have some idea of what to read. 0) Is this multiple mount point functionality even necessary, or is there a better/existing mechanism to achieve the same goal (aside from local nfs mount). 1) What is the danger of not failing with EBUSY if the device is already mounted? 2) Would
Re: Broadcom 5701 (3com 3c996B-T) phy support in 4.5?
In article [EMAIL PROTECTED], Jonathan Stone [EMAIL PROTECTED] wrote: Apologies if this is the wrong place to ask this I just got a 3com 3c996B-T with a bcm5701 chip. It doesn't work with a kernel built from 4.5-RC source pulled Friday: the gigabit phy goes unrecognized, gets attached as a ukphy, which (obviously) doesn't support 1000baseTX. Is this expected to work? Its hard to tell from if_bge. I discovered a suitable value for lines for sys/dev/mii/miidevs in the Debian Linux driver: +model xxBROADCOM BCM5701 0x0011 BCM5701 10/100/1000baseTX PHY rebuilt the .h file, and added corresponding lines to the probe routine in bgrphy.c. That gets the builtin 5400-compatible gigabit PHY recognized -- it auto-negotiates with my gigabit switch, and gives the same ttcp same speed as a 5700-- but i still get another 30-odd ukphy devices attached on that miibus instance. Yep, I went through the same exercise. Apparently the 5701 doesn't bother to decode the phy address. The driver just has to know to use phy number 1. (Boo, hiss!) I worked around it by making bge_miibus_readreg and bge_miibus_writereg return 0 if the device is a 5701 and the phy number isn't 1. That way, the extra phys never get probed. With that change, it works except that I'm getting frequent bogus bge0: gigabit link up messages. I haven't been able to figure out why yet. They don't appear to affect packet flow at all. From investigating the Linux driver, I gather there are a few features in these chips which may need workarounds (e.g., the Debian driver includes a new firmware image for some 5701 revs'; and forces master mode in some revs, to avoid a CRC bug. Caveat emptor.) Yes, there are quite a few mysterious workarounds in that driver. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uiomove busted for the past 3 years
On Wed, 2002/01/30 at 07:02:25 -0800, User JHB wrote:
When the DEADLKTREAT flag was added, uiomove() was broken. :) The
problem is that a return() inside of a switch nested inside of a while
loop was converted to a break leading to the following rather silly code:
if (error)
break;
break;
What is supposed to happen is that if there is an error, we break out of
the while loop, but all we do is break out of the switch ignoring the
error and continuing to loop. Thus, in the best case, if copyin or
copyout failed on the last iteration of the loop, we would return an
error, but would bogusly update the counts in the iovec and uio
structures. In the worst case, if we kept looping and later copyin's or
copyout's succeeded, then we wouldn't return an error at all. A quick fix
would be to add a goto to jump to the error return code at the end of the
loop rather than the bogus break if (error). However, I can't test this
at the moment. Someone please verify and fix this.
The attached test program triggers this bug (if the test file is
located on a file system that does not split up the uiomove() in that
case, e.g. FFS with a block size = 2 * page size). When NIOV is changed
from 2 to 1, the writev() will result in EFAULT, however with two
iovecs the write returns the sum of the sizes of both iovecs although
the buffer supplied to the first is unaccessible.
The patch you proposed:
--- kern_subr.c~Fri Jan 25 02:14:45 2002
+++ kern_subr.c Wed Jan 30 20:39:07 2002
@@ -104,7 +104,7 @@
else
error = copyin(iov-iov_base, cp,
cnt);
if (error)
- break;
+ goto out;
break;
case UIO_SYSSPACE:
@@ -123,6 +123,7 @@
cp += cnt;
n -= cnt;
}
+out:
if (td != curthread) printf(uiomove: IT CHANGED!);
td = curthread; /* Might things have changed in
copyin/copyout? */
if (td) {
--
fixes it for me.
- thomas
#include sys/types.h
#include sys/fcntl.h
#include sys/mman.h
#include sys/stat.h
#include sys/uio.h
#include err.h
#include errno.h
#include stdio.h
#include string.h
#include unistd.h
#define NIOV2
int
main()
{
struct iovec iov[2];
size_t psz;
char *a, *b;
int fd, rv, en;
psz = getpagesize();
a = mmap(NULL, psz, PROT_NONE, MAP_ANON, -1, 0);
if (a == MAP_FAILED)
err(1, mmap 1);
b = mmap(a + psz, psz, PROT_READ, MAP_ANON | MAP_FIXED, -1, 0);
if (b == MAP_FAILED)
err(1, mmap 2);
fd = open(uiob.foo, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
if (fd == -1)
err(1, open);
iov[0].iov_base = a;
iov[0].iov_len = psz;
iov[1].iov_base = b;
iov[1].iov_len = psz;
rv = writev(fd, iov, NIOV);
en = errno;
printf(writev returned %d\n, rv);
if (rv == -1)
printf(error: %s\n, strerror(en));
close(fd);
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: What is HIDE_POSIX HIDE_BSD?
I can't guess what does it mean by hiding. Maybe any system call can be hidden from some configuration of the kernel. -Zhihui On Wed, 30 Jan 2002, Peter Pentchev wrote: On Tue, Jan 29, 2002 at 03:58:16PM -0500, Zhihui Zhang wrote: While adding a system call, I notice in file syscall-hide.h there are many instances of HIDE_POSIX() and HIDE_BSD(). What is the purpose of these macros? Maybe they are now obsolete? The syscalls-hide.h file was generated from sys/kern/makesyscalls.sh from the third field of sys/kern/syscalls.master - POSIX, BSD or NOHIDE. However, three months ago Poul Henning-Kamp removed the syscalls-hide.h file and the relevant parts of makesyscalls.sh. I think that this may be scheduled for MFC'ing some time in the future, but you might have to ask phk for specifics. Also, I would also like to know what was the original purpose of the POSIX/BSD/NOHIDE distinction. BTW, should that field be removed from syscalls.master, too? G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Broadcom 5701 (3com 3c996B-T) phy support in 4.5?
On Wed, Jan 30, 2002 at 11:41:05AM -0800, John Polstra wrote: From investigating the Linux driver, I gather there are a few features in these chips which may need workarounds (e.g., the Debian driver includes a new firmware image for some 5701 revs'; and forces master mode in some revs, to avoid a CRC bug. Caveat emptor.) Yes, there are quite a few mysterious workarounds in that driver. We've had alot of trouble with the builtin card in our Dell 2550s. I'm going to try swapping hardware to see if we've got a bad machine, but I suspect the chip is just plain broken. Where can you get the Linux driver from? I might try stealing some of the hacks in it to see if it fixes the problems we're seeing. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Broadcom 5701 (3com 3c996B-T) phy support in 4.5?
In article [EMAIL PROTECTED], David Malone [EMAIL PROTECTED] wrote: We've had alot of trouble with the builtin card in our Dell 2550s. I'm going to try swapping hardware to see if we've got a bad machine, but I suspect the chip is just plain broken. Well, it seems to work OK with the Linux driver. Where can you get the Linux driver from? I believe it's in the standard Linux kernel. Just grab the latest one from kernel.org. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD-1.X public cvs?
On Wednesday, 30 January 2002 at 9:41:15 -0700, Nate Williams wrote: Caldera's License Agreement: http://www.tuhs.org/Archive/Caldera-license.pdf Thanks. However, this isn't as specific as I'd like it to be. It implies that Net1/Net2 are now 'legal', but it doesn't give explicit release of said source code. Well, I have never heard claims that BSD was tainted by any USL release besides 32V, so this is good enough for me to put my 1.X tree up without fearing ugly lawyers. Now, where did all those CD's go... If all else fails I have stored my FreeBSD 1.0 CD as a precious gem ;) Cannot find the 386BSD 0.1 + PK024 QIC tape though :( A FreeBSD 1.X CVS tree has been found, which has it's first import as 386BSD 0.1 + PK 024. There are a couple minor points that need to be clarified from Caldera before it can be made public. There are? What are they? Who's doing it? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
kernel fork execve
Hi, I would like to add a new syscall in my kernel which execute an execve in a forked process. I call the fork1 function and hook inside it to execute my execve. Has anyone an example of calling execve from kernel ? I have some problem to pass the arguments ... Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: SurfBoard SB1000 cable modem in FreeBSD?
If that is the case... then the cable modem should have an address on the LAN side of it.. something like 192.168.100.1 which should be accessable via web browser. That is how the surfboard cable modems are managed. Once other thing is that the cable modem will fail to connect from Netscape as the submit tag of the button does not respond correctly. Mozilla is a better bet or if he has more then one box on the network such as a windows box then try from ie on that box to connect. The last of the irritating factors of using such device that I have found is that when trying to verify connectivity from behind the cable modem, forget using ping or any ping related utility such as traceroute; the cable modem will only pass response pings to the first address such as 192.168.100.2 if cable modem is 192.168.100.1. This is how I currently have mine set up and it is working fine for me.. Hope this helps D -Original Message- From: Mario Sergio Fujikawa Ferreira [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 8:57 AM To: raymond hicks Cc: [EMAIL PROTECTED]; 'Marcelo Cunha'; 'Jose Antonio Junior' Subject: Re: SurfBoard SB1000 cable modem in FreeBSD? On Wed, Jan 30, 2002 at 08:42:22AM -0500, raymond hicks wrote: uni-directional cable? What kind of connection does your friend have? He lives in a area where both isdn and adsl do not work. Furthermore, much for his dismay, bi-directional cable (actually radio) does not work due to visibility issues. Therefore, he is stuck with uni-directional downstream. Upstream is handled by a 56K modem. -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. Computer Science Undergraduate | FreeBSD Committer | CS Developer flames to beloved [EMAIL PROTECTED] feature, n: a documented bug | bug, n: an undocumented feature To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
if_rl.c autoneg fix
The problem I was having with the if_rl driver not working properly when
connected to a 10Mb hub (ie no link partner capabilities) can be fixed by
removing a line with a cryptic comment about broken autonegotiation.
in the file /sys/dev/mii/rlphy.c:
void
rlphy_reset(sc)
struct mii_softc *sc;
{
mii_phy_reset(sc);
/*
* XXX RealTek PHY doesn't set the BMCR properly after
* XXX reset, which breaks autonegotiation.
*/
/*
PHY_WRITE(sc, MII_BMCR, BMCR_S100|BMCR_AUTOEN|BMCR_FDX);
*/
}
taking out the PHY_WRITE repairs autonegotiation in all modes tested. The
line sets the BMCR_AUTOEN flag, which causes the phy_mediachg() call in
rl_reset to have no effect (in that the driver thinks its already doing
autoneg). Taking the line out causes mii_phy_auto() to be called correctly.
ifconfig still reports (none), but the port works properly without a manual
media setting.
Does anyone know the reasoning being the line being added originally? Perhaps
a conditional is required if it was required for older controllers for some
reason.
Dennis
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: kernel fork execve
check where init is called from.. On Thu, 31 Jan 2002, Jonathan BENSAMOUN wrote: Hi, I would like to add a new syscall in my kernel which execute an execve in a forked process. I call the fork1 function and hook inside it to execute my execve. Has anyone an example of calling execve from kernel ? I have some problem to pass the arguments ... Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel fork execve
* Julian Elischer [EMAIL PROTECTED] [020130 16:09] wrote: check where init is called from.. Y'know, exec call could be made into a do_exec, all that seems to matter is whether or not uap-fname is UIO_USERSPACE or UIO_SYSSPACE. On Thu, 31 Jan 2002, Jonathan BENSAMOUN wrote: Hi, I would like to add a new syscall in my kernel which execute an execve in a forked process. I call the fork1 function and hook inside it to execute my execve. Has anyone an example of calling execve from kernel ? I have some problem to pass the arguments ... Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: HOW to debug memory corruption efficiently?
Robert Suetterlin [EMAIL PROTECTED] wrote: Unfortunately I'm neither proficient in C++ nor efficient in debugging, so I stumble around the problem rather blindfolded. Once I blamed the compiler, systemlibraries and operating system, I knew I needed some help. The problem appeared on a linux system, but I guess the techniques I might need will be the same under Linux, FreeBSD or any un*x. Unfortunately, you'll probably have to debug this the hard way. Figure out what part of memory is being trashed, and then figure out what is trashing the memory. If the memory address/data is consistent, you might be able to use the i386 hardware breakpoint debug registers to help you. The best -- but horribly expensive -- way is to port the software to another Unix platform (like Solaris or HP-UX), and use Rational Software's Purify to locate the memory corruption. It's almost a no-brainer to use, and it works ungodly well. You don't even need source code to use purify -- object files are enough, as purify works at *link* time (you don't have to specially compile your code, unless you want to take advantage of special purify APIs). The downside is that your program does run 3-10X slower, and Purify is pretty expensive (but it's such a killer programming app). It's not available for either FreeBSD or Linux, though. Purify's nearest (commercial) competitor is ParaSoft's Insure++. Perhaps things have improved but, when we last evaluated it a year or two back, it was a LOT slower than purify (unusably slow for our applications). I seem to recall 5-10X slower than purify (maybe more). It can detect a few problems that purify does not, however (e.g., bad arguments to printf()). Insure++ needs access to source code for best results. I believe a Linux version is available. There is no open-source equivalent to purify (and probably won't be, due to patent issues). The closest thing is GNU checker, but that's a pale, feeble dust speck compared to purify (assuming that you even manage to get checker working). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
JKH - Jr. Kernel Hacker task
Right now one must hardcode compile the BPS rate into the kernel for serial consoles. This is just ridden with problems when machines move, or configurations shared. It would be really nice if the kernel would get the BPS rate from a loader environmental var instead of having it hard coded. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: HOW to debug memory corruption efficiently?
I would give Insure a try if you can't afford Purify. Either one is better than just about anything else you'll find in the open source world. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Broadcom 5701 (3com 3c996B-T) phy support in 4.5?
In article [EMAIL PROTECTED], Jonathan Stone [EMAIL PROTECTED] wrote: Thanks for the responses. Any chance the miidevs hack and phy workarounds will make it into -current or FreeBSD 4.5? I'm not going to commit anything unless/until I get the driver working properly with the 5701, including understanding and eliminating those gigabit link up messages. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: JKH - Jr. Kernel Hacker task
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : Right now one must hardcode compile the BPS rate into the kernel for : serial consoles. This is just ridden with problems when machines move, : or configurations shared. : : It would be really nice if the kernel would get the BPS rate from a : loader environmental var instead of having it hard coded. Does this patch work: Index: sio.c === RCS file: /cache/ncvs/src/sys/dev/sio/sio.c,v retrieving revision 1.362 diff -u -r1.362 sio.c --- sio.c 17 Jan 2002 20:05:47 - 1.362 +++ sio.c 31 Jan 2002 05:35:16 - @@ -431,6 +431,7 @@ SYSCTL_PROC(_machdep, OID_AUTO, conspeed, CTLTYPE_INT | CTLFLAG_RW, 0, 0, sysctl_machdep_comdefaultrate, I, ); +TUNABLE_INT(machdep.conspeed, comdefaultrate); #define SET_FLAG(dev, bit) device_set_flags(dev, device_get_flags(dev) | (bit)) #define CLR_FLAG(dev, bit) device_set_flags(dev, device_get_flags(dev) ~(bit)) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Again Softupdates on 4.5
On Wednesday 30 January 2002 02:31 pm, Kevin Oberman wrote: From: Brian T.Schellenberger [EMAIL PROTECTED] Date: Wed, 30 Jan 2002 14:17:27 -0500 On Wednesday 30 January 2002 12:53 pm, Kevin Oberman wrote: Date: Wed, 30 Jan 2002 20:09:14 +0300 (MSK) From: Varshavchick Alexander [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Then the difference lays only in the fact that on 4.5 the softupdates flag can be turned on in the sysinstall procedure? No. I means that sysinstall turns on softupdates for all non-root, non-swap partitions by default. Under 4.4 you had to tell sysinstall that you wanted softupdates (with the 'S' command). There is no change to the functionality in 4.5, only to the default operation. Does 4.5 also leave write-caching on by default? If so, I think that's a terrible mistake. Would I be correct in assuming it's way to late to get this reconsidered? Yes, write-cache is enabled by default on 4.5 (as it was on 4.4). The debate on this has been long and often mis-informed. There is a real risk of metadata corruption with write caching and softupdates, but it appears to be EXTREMELY small. So far no case of it has actually been confirmed. There is a significant chance of data loss in recently updated files with write-cache, but that is also true without softupdates. The only totally safe way to deal with this is to run fully synchronous with write-cache disabled. My experience is that combining the two of them greatly magnifies the risk of losing recent updates, and that in fact data can be lost even without any system crash or other problems when using them together. Indeed, I have a very reproducable case of this on my system-- If I enabled softupdates + write cache and then I do cd /some-big-directory rm -r * shutdown -p now then the file system will be corrupted on reboot. I find this as default behavior pretty ridiculous, and it it comes about *only* as result of having both enabled together. As I understand it the conclusion of the core team was that softupdates advantages more than justified the risks. 4.5 has been released. I already have burned CDs. I think it's too late. (And what list ought I have been reading to have known about these plans?) hackers and stable. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED]Phone: +1 510 486-8634 -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: JKH - Jr. Kernel Hacker task
On Wed, Jan 30, 2002 at 05:56:13PM -0800, David O'Brien wrote: Right now one must hardcode compile the BPS rate into the kernel for serial consoles. This is just ridden with problems when machines move, or configurations shared. It would be really nice if the kernel would get the BPS rate from a loader environmental var instead of having it hard coded. And on Alpha from the com1_speed SRM env var maybe. -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
