kill a process in kernel
Hello, what is the most proper and easy way to shutdown given process (not curproc) from kernel module ? Any advices regarding this are appreciated. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel level inet socket handling
John Polstra wrote: > > In article <[EMAIL PROTECTED]>, > Julian Elischer <[EMAIL PROTECTED]> wrote: > > [concerning my fixes for ng_ksocket nodes to handle TCP operations] > > > If you send me the files I can diff them and commit them. > > (of course you are welcome to do it yourself at your own pace if you wish) > > Hmm, I just might take you up on that. :-) The biggest obstacle is > that I have been working on the -stable branch, so the changes will > have to be made compatible with -current. I know you added some > locking in -current, but I had the impression that it's fairly well > hidden from most nodes. Is that right? basically, the iterface is pretty similar but it would be easier for me to port it.. > > John -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: secure Filesystem
That's cool! Maybe we can have a patch changing these cpp vars in the cfs port? Regards, Konstantin. Darryl Okahata wrote: > However, upon perusing the code again, cfsd appears to be using a > plain hash table with 1024 buckets and a linked list at each bucket. > The number of buckets is controlled by two simple #define's in cfs.h: > > #define HSIZE 1024 > #define HMASK 0x3ff /* change these together, please */ > > These are pretty easy to change (HSIZE must currently be a power of 2), > and you generally don't have to worry about hash function issues (the > file inode is used as the "hash function"). > > My test case has 20+ files, occupying ~1.4GB, and increasing > the hash table size (number of buckets) to 1M (1024*1024) greatly > improved swap performance (not surprising, as following the linked lists > is what unnecessarily dragged in lots of pages). On my laptop with > 128MB RAM, there was a significant change in resident memory footprint: > > VM used RES (max) > original 1024 bucket cfsd: ? ? > 128K bucket cfsd: 445MB 80-90MB > 1024K bucket cfsd: 458MB 30-35MB (<20MB typ) > > Of course, increasing the number of buckets increased the initial > cfsd size (to 14-16MB, in the case of the 1M buckets), but that's > acceptable. > > [ And the cfsd process doesn't shrink when you cdetach ;-( ] > > -- > 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 -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.netUnited Kingdom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kill a process in kernel
Fri, Aug 24, 2001 at 11:41:43, vel (Eugene L. Vorokov) wrote about "kill a process in kernel": > what is the most proper and easy way to shutdown given process > (not curproc) from kernel module ? Any advices regarding this > are appreciated. psignal(9); killproc() (for SIGKILL, in extremal situations) /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
> > It's kinda late in the process to be complaining about this, but I just noticed >this myself... Why not just symlink csh to tcsh then ? vel@bugz:/sys/modules/paudit # ls -l /bin/*csh -r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/csh -r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/tcsh Is this really reasonable ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Fri, 24 Aug 2001, Eugene L. Vorokov wrote: ELV>> > It's kinda late in the process to be complaining about this, but I just noticed this myself... ELV> ELV>Why not just symlink csh to tcsh then ? ELV> ELV>vel@bugz:/sys/modules/paudit # ls -l /bin/*csh ELV>-r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/csh ELV>-r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/tcsh ^ ELV> ELV>Is this really reasonable ? What's wrong with hard links? # ls -l /bin/csh /bin/tcsh 16112 -r-xr-xr-x 2 root wheel 740880 Aug 10 14:35 csh 16112 -r-xr-xr-x 2 root wheel 740880 Aug 10 14:35 tcsh harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: Why is csh tcsh? This can be a bad thing...
> On Fri, Aug 24, 2001 at 01:45:48PM +0400, Eugene L. Vorokov wrote: > > > > It's kinda late in the process to be complaining about this, but I just >noticed this myself... > > > > Why not just symlink csh to tcsh then ? > > Because csh is hardlinked to tcsh instead. Oh well, I missed that. But I think symlink would do just the same, but it would be more obvious for user that csh is now the same thing as tcsh. Is there any situation where symlink would not do the job but hardlink would ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: Why is csh tcsh? This can be a bad thing...
On Fri, 24 Aug 2001, Eugene L. Vorokov wrote: ELV>> On Fri, Aug 24, 2001 at 01:45:48PM +0400, Eugene L. Vorokov wrote: ELV>> > > > It's kinda late in the process to be complaining about this, but I just noticed this myself... ELV>> > ELV>> > Why not just symlink csh to tcsh then ? ELV>> ELV>> Because csh is hardlinked to tcsh instead. ELV> ELV>Oh well, I missed that. But I think symlink would do just the same, ELV>but it would be more obvious for user that csh is now the same thing ELV>as tcsh. Is there any situation where symlink would not do the job ELV>but hardlink would ? Probably not, but a hard link is faster (just for the case when invoking csh is the bottleneck in your application :-) And the symbolic link costs you an i-node. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Subject: Mail::Internet test subject This is a test message that was sent by the test suite of Mail::Internet. Testing. one >From foo four >From bar seven To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bug in net.link.generic handling
Hello, there seems to be a problem with the handling of the interfaces subtree. In if_mib.c I see: if (name[0] <= 0 || name[0] > if_index) return ENOENT; ifp = ifnet_addrs[name[0] - 1]->ifa_ifp; and after that 'ifp' is used to return information to the user. There are, however, circumstances, where ifnet_addrs[i] may be NULL: 1) in if_attach the allocation of the address may fail. In this case ifnet_addrs[i] remains NULL, but the interface is attached. 2) an interface may be detached from the 'middle' of the current interface index range. If, for example, I have three interfaces with indexes 1, 2 and 3 and I unload the driver for interface 2, ifnet_addrs[1] will be zero, but if_index will remain 3. If this happens the kernel will probably panic in sysctl_ifdata. The fix is obvious: Index: if_mib.c === RCS file: /usr/ncvs/src/sys/net/if_mib.c,v retrieving revision 1.10 diff -r1.10 if_mib.c 86c86,87 < ifp = ifnet_addrs[name[0] - 1]->ifa_ifp; --- > if ((ifp = ifnet_addrs[name[0] - 1]->ifa_ifp) == NULL) > return (ENOENT); A related problem is that net.link.generic.system.ifcount is not really to number of interfaces, but rather the current maximum interface index. These numbers may be different if there are holes in the index space. If this part of the sysctl names space were be documented, this should probably be mentioned :-) Is there any way to access net.link.generic with sysctl(8)? Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kernel configuration
I recently purchaced the freeBSD 3rd edition kit (book & 10 cd's) and have it installed and configured the best i need at this point, however i was having a hard time trying to make since of what the book had to say about configuring the kernel. I looked at the source code, but it didn't seem to be right. I have an AMD/K6-2/400, 64M, SB16, RadioReveal, PCI NIC (intel based), Adaptec 152x SCSI, SCSI cd, and 1 SCSI cd-r. I'm pretty familure with Slackware Linux, however similar they are still VERY different. Please help. __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
hi, there! On Fri, Aug 24, 2001 at 01:45:48PM +0400, Eugene L. Vorokov wrote: > > > It's kinda late in the process to be complaining about this, but I just noticed >this myself... > > Why not just symlink csh to tcsh then ? > > vel@bugz:/sys/modules/paudit # ls -l /bin/*csh > -r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/csh > -r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/tcsh > > Is this really reasonable ? fjoe@husky:/bin$ls -li *csh 633 -r-xr-xr-x 2 root wheel 635388 25 ÉÀÌ 20:27 csh* 633 -r-xr-xr-x 2 root wheel 635388 25 ÉÀÌ 20:27 tcsh* /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM statistics per process?
> Worse, pmap_pid_dump() is undocumented, and I don't
> understand what for(i=0;i<1024;i++) for(j=0;j<1024;j++) {} loop there is
> supposed to do... :-(
>
> I'd appreciate if someone would explain this to me.
the process' virtual memory is mapped into physical memory with page
directory table entries that point to a page table entry that points
to physical memory. there are 1024 (4096 character buffer with 4 bytes
per physical address) in both the PDE and PTEs. So 1 PDE is a pointer
to 1024 PTE which point to 1024 4KB of physical memory.
the outer for loop get a reference to the page table. the inner loop
gets the physical pages mapped to the virtual address.
the commentary for the pmap_pid_dump(int pid) routine:
for each process
if valid vmspace
get process physical memory mapping
for each physical memory page directory entry
if page directory entry exists and is currently valid
for each physical meory page table entry
if the virtual address is now into the kernel space
exit the routine
end of if the virtual address is now into the kernel space
if page table entry exists and is valid
get the vm_page associated with this physical page
print out the information about virtual and physical address
stats and pretting printing stuff
end of if page table entry exists and is valid
end of for each physical meory page table entry
end of for each physical memory page directory entry
end of if valid vmspace
end of for each process
return stats of number of physical pages used in user space for all processes
Note: most/many of the PDE and PTE entries will be not mapped or invalid.
:wq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: wireless nic recommendations
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Wes Peters writes: > : I've had no problems with this card, it is currently reaching about 6.5 > : miles without an amplifier, using a 24 dB "fruit basket" antenna on the > : roof of my house. > > What does the other end have? An omni antenna, Aironet commercial access point, and a 1w amp. Standard commercial fare, if rather expensive. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ata0-master: non aligned DMA transfer attempted
I write a program that writes into a raw device directly. Although the program runs OK, the system prints messages like: ata0-master: non aligned DMA transfer attempted What exactly happens here? Is there any problem in my program? Thanks. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What is the best mail virus scanner?
On Fri, Aug 24, 2001 at 03:33:47PM +0400, Andrey A. Chernov wrote: > Can anybody recommend some incoming mail virus scanner soft smoothly > integrated with sendmail or procmail, keep its virus database fresh and > eaten small amount of resources (not perl, please)? AVP (http://www.avp.ru) or Dr.Web (http://www.drweb.ru/) I use AVP at my corporate server. -- Rgdz,/"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
What is the best mail virus scanner?
Can anybody recommend some incoming mail virus scanner soft smoothly integrated with sendmail or procmail, keep its virus database fresh and eaten small amount of resources (not perl, please)? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
building 'release' and compiling doc ports
I get the impression that even if a machine has the necessary docproj buildtools ports installed a 'make release' builds them from scratch again? Is this true? And why? This takes bloody forever.. Observed with make release for RELENG_4 on Alpha. Like: chflags -R noschg /R/stage/trees touch release.2 Making docs... ===> Extracting for docproj-1.8 >> No MD5 checksum file. ===> Patching for docproj-1.8 ===> Configuring for docproj-1.8 ===> Installing for docproj-1.8 ===> docproj-1.8 depends on executable: instant - not found ===>Verifying install for instant in /usr/ports/textproc/sgmlformat ===> Extracting for sgmlformat-1.7 >> Checksum OK for sgmlformat-1.7.tar.gz. ===> Patching for sgmlformat-1.7 ===> Configuring for sgmlformat-1.7 ===> Building for sgmlformat-1.7 ===> instant Warning: Object directory not changed from original /usr/ports/textproc/sgmlform at/work/sgmlformat-1.7/instant cc -O -pipe -mcpu=ev4 -mcpu=ev4 -DTRANSPEC_DIR=\"/usr/local/share/sgml/transpec\ "-c browse.c cc -O -pipe -mcpu=ev4 -mcpu=ev4 -DTRANSPEC_DIR=\"/usr/local/share/sgml/transpec\ "-c info.c cc -O -pipe -mcpu=ev4 -mcpu=ev4 -DTRANSPEC_DIR=\"/usr/local/share/sgml/transpec\ "-c main.c [.etc...] Wilko [who wants to put a bootable .iso up for ftp ;-) ] -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: secure Filesystem
On Fri, Aug 24, 2001 at 09:34:51AM +0100, Konstantin Chuguev wrote: > That's cool! Maybe we can have a patch changing these cpp vars in the cfs > port? Don't forget to submit any work to [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
If memory serves me right, Wilko Bulte wrote:
> I get the impression that even if a machine has the necessary docproj
> buildtools ports installed a 'make release' builds them from scratch
> again? Is this true? And why?
Yes, it's true. We need to rebuild the docproj ports inside the chroot
area. There's one optimization made...anything in /usr/ports/distfiles
gets copied to the the chroot area's /usr/ports/distfiles. This can
save needing to fetch the distfiles for all of the docproj ports all
over again.
A little brainstorming...
I wonder if we could hand the release building process a list of
packages to install before building docs? Like we could try to do
pkg_add for each of the ports defined in ${MINIMALDOCPORTS} (insert
hand-waving here to convert directory names to package filenames). This
introduces two problems...the release builder needs to have a set of
packages that's consistent with the requirement of the doc/ and src/
release/doc trees (as well as the release being built). Second, it
introduces a Yet Another Knob To Tweak During Release Building (TM).
Another, truly ugly way would be an option to tar up /usr/local and drop
it into the chroot area (yeah, this doesn't work for people who don't
install ports to /usr/local).
> This takes bloody forever..
> Observed with make release for RELENG_4 on Alpha.
Now if I can crank out releases on my puny PII-400, surely an Alpha can
do it, right? :-)
/me ducks and covers.
Bruce.
PGP signature
Re: mmap MAP_INHERIT question.
:> :> MAP_INHERIT This is supposed to permit regions to be :> inherited across execve(2) system calls, :> but is currently broken. : : Support for the flag and reference to it in the manpage should just be :removed. : :-DG : :David Greenman Yah, I agree. Even if we implemented it it would be a massive security hole. a MAP_SHARED mmap() is easier. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
automating fsdb?
Is there an easy way to script interaction with fsdb? I'm trying to rebuild a disk that failed recently and I'm searching for the inode contains a directory that I need. However the entry in the root inode lists the inode for the directory I'm after as 0. I know it is there somewhere on the disk (or at least I hope it is) and I really don't want to have to type every number between 1 and 14,292,725 to find it. I thought if I could script fsdb I could do it much faster. In that vein I tossed together this silly little script but I'm missing something obvious because it doesn't work. Any suggestions besides don't do this? :) root@max(~)# cat foo.pl #!/usr/bin/perl -w open(FOO, "| fsdb /dev/vinum/mirror") or die "failed to start fsdb: $!"; print FOO "help\n"; close(FOO); root@max(~)# ./foo.pl ** /dev/vinum/mirror Editing file system `/dev/vinum/mirror' Last Mounted on /a current inode: directory I=2 MODE=40755 SIZE=512 MTIME=Aug 11 20:41:59 2001 [0 nsec] CTIME=Aug 11 20:41:59 2001 [0 nsec] ATIME=Aug 21 03:01:03 2001 [0 nsec] OWNER=root GRP=wheel LINKCNT=8 FLAGS=0 BLKCNT=2 GEN=54e262d0 fsdb (inum: 2)> * FILE SYSTEM STILL DIRTY * *** FILE SYSTEM MARKED DIRTY *** BE SURE TO RUN FSCK TO CLEAN UP ANY DAMAGE *** IF IT WAS MOUNTED, RE-MOUNT WITH -u -o reload To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Possible race in i386/i386/pmap.c:pmap_copy()
Alfred, DG, could you take a look at pmap_copy() in i386/i386/pmap.c
and tell me if what I think I'm seeing is what I'm seeing?
My read of this code is that a global, APTDpde, is being set, and
then that pointer is being used in a loop later on in the routine.
the problem is that the pmap_allocpte() call can block and, by my
read, that means some other process can go in and change APTDpde out
from under the loop.
This could also be related to problem Julian has been seeing with his
KSE patch set.
There is a comment:
/*
* We have to check after allocpte for the
* pte still being around... allocpte can
* block.
*/
dstmpte = pmap_allocpte(dst_pmap, addr);
if ((*dst_pte == 0) && (ptetemp = *src_pte)) {
/*
* Clear the modified and
...
But I do not believe this check is sufficient if APTDpde gets ripped
out from under the loop. Is this race real or am I blowing smoke?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
On Fri, Aug 24, 2001 at 09:05:16AM -0700, Bruce A. Mah wrote:
> If memory serves me right, Wilko Bulte wrote:
> > I get the impression that even if a machine has the necessary docproj
> > buildtools ports installed a 'make release' builds them from scratch
> > again? Is this true? And why?
>
> Yes, it's true. We need to rebuild the docproj ports inside the chroot
Why? Why can't the docs not be generated using the tools installed on the
system?
> area. There's one optimization made...anything in /usr/ports/distfiles
> gets copied to the the chroot area's /usr/ports/distfiles. This can
> save needing to fetch the distfiles for all of the docproj ports all
> over again.
And it appears to be broken too:
In file included from gdcache.h:43,
from gdft.c:35:
/usr/include/malloc.h:2: warning: #warning "this file includes
which is deprecated, use instead"
gdft.c:36: freetype/freetype.h: No such file or directory
gdft.c:37: freetype/ftglyph.h: No such file or directory
*** Error code 1
Stop in /usr/ports/graphics/gd/work/gd-1.8.4.
*** Error code 1
this is because 'gd' does not depend correctly on 'freetype2'
a plain 'make' on the docproj port on Alpha fails in an identical fashion.
> A little brainstorming...
>
> I wonder if we could hand the release building process a list of
> packages to install before building docs? Like we could try to do
> pkg_add for each of the ports defined in ${MINIMALDOCPORTS} (insert
> hand-waving here to convert directory names to package filenames). This
> introduces two problems...the release builder needs to have a set of
> packages that's consistent with the requirement of the doc/ and src/
> release/doc trees (as well as the release being built). Second, it
> introduces a Yet Another Knob To Tweak During Release Building (TM).
Why not depend the make release on 'docproj-v.foo' and be done with it?
And if it is lacking docproj and cannot build it either just continue the
make release and leave the docs out?
> Another, truly ugly way would be an option to tar up /usr/local and drop
> it into the chroot area (yeah, this doesn't work for people who don't
> install ports to /usr/local).
>
> > This takes bloody forever..
> > Observed with make release for RELENG_4 on Alpha.
>
> Now if I can crank out releases on my puny PII-400, surely an Alpha can
> do it, right? :-)
And this is not the puniest of Alphas, this is a 466MHz EV6 box. Most
FreeBSD folks have (much) slower machines.
> /me ducks and covers.
gcc sucks on Alpha and hence the performance of it all leaves a bit to
be desired. [understatement alert]
Wilko
--
| / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
If memory serves me right, Wilko Bulte wrote:
> On Fri, Aug 24, 2001 at 09:05:16AM -0700, Bruce A. Mah wrote:
> > If memory serves me right, Wilko Bulte wrote:
> > > I get the impression that even if a machine has the necessary docproj
> > > buildtools ports installed a 'make release' builds them from scratch
> > > again? Is this true? And why?
> >
> > Yes, it's true. We need to rebuild the docproj ports inside the chroot
>
> Why? Why can't the docs not be generated using the tools installed on the
> system?
Because at the time the docs get installed in the chroot area, the
chroot has already taken place, and the build processes can't access
that part of the filesystem anymore.
Skipping ahead in your message a bit, you don't *need* to go through
this pain. "NODOCS=YES" is your friend.
> > area. There's one optimization made...anything in /usr/ports/distfiles
> > gets copied to the the chroot area's /usr/ports/distfiles. This can
> > save needing to fetch the distfiles for all of the docproj ports all
> > over again.
>
> And it appears to be broken too:
>
> In file included from gdcache.h:43,
> from gdft.c:35:
> /usr/include/malloc.h:2: warning: #warning "this file includes
> which is deprecated, use instead"
> gdft.c:36: freetype/freetype.h: No such file or directory
> gdft.c:37: freetype/ftglyph.h: No such file or directory
> *** Error code 1
>
> Stop in /usr/ports/graphics/gd/work/gd-1.8.4.
> *** Error code 1
>
> this is because 'gd' does not depend correctly on 'freetype2'
>
> a plain 'make' on the docproj port on Alpha fails in an identical fashion.
G. Is it possible that mi's recent commit to ports/graphics/gd/Makefile
introduced a typo in LIB_DEPENDS ("freetype" instead of "freetype.7")?
Or is there some syntax here I am just missing? Either way this needs
to be fixed.
>
make NODOC=YES ?
I know that's not the "real" answer.
> Why not depend the make release on 'docproj-v.foo' and be done with it?
> And if it is lacking docproj and cannot build it either just continue the
> make release and leave the docs out?
You don't *have* to build with docs. Just set NODOC=YES, as described
in src/release/Makefile and you're ready to go. Really. If you're in
a hurry, you could also set NOPORTS=YES.
> gcc sucks on Alpha and hence the performance of it all leaves a bit to
> be desired. [understatement alert]
I'm not going there.
Hang in there
Bruce.
PGP signature
Re: building 'release' and compiling doc ports
On Fri, Aug 24, 2001 at 10:25:41AM -0700, Bruce A. Mah wrote: > > > > make NODOC=YES ? > > I know that's not the "real" answer. Nope. We need an RC to test -- this means as close to the real release as we can get. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
On Fri, Aug 24, 2001 at 10:25:41AM -0700, Bruce A. Mah wrote:
> If memory serves me right, Wilko Bulte wrote:
> > On Fri, Aug 24, 2001 at 09:05:16AM -0700, Bruce A. Mah wrote:
> > > If memory serves me right, Wilko Bulte wrote:
> > > > I get the impression that even if a machine has the necessary docproj
> > > > buildtools ports installed a 'make release' builds them from scratch
> > > > again? Is this true? And why?
> > >
> > > Yes, it's true. We need to rebuild the docproj ports inside the chroot
> >
> > Why? Why can't the docs not be generated using the tools installed on the
> > system?
>
> Because at the time the docs get installed in the chroot area, the
> chroot has already taken place, and the build processes can't access
> that part of the filesystem anymore.
Other idea:
do a 'make package' outside the chroot for all required doc ports and
move those into the chroot. Still not too elegant though..
Or build the docs outside the chroot and move 'm in after they are
generated :-P
Seriously: there is really a ton of ports required to generate all the
different incarnations of the docs. Quite horrible in a sense..
> Skipping ahead in your message a bit, you don't *need* to go through
> this pain. "NODOCS=YES" is your friend.
OK, I'll give that a try. I thought I had NODOCS in the buildscript
but apparantly not.
> > Stop in /usr/ports/graphics/gd/work/gd-1.8.4.
> > *** Error code 1
> >
> > this is because 'gd' does not depend correctly on 'freetype2'
> >
> > a plain 'make' on the docproj port on Alpha fails in an identical fashion.
>
> G. Is it possible that mi's recent commit to ports/graphics/gd/Makefile
> introduced a typo in LIB_DEPENDS ("freetype" instead of "freetype.7")?
> Or is there some syntax here I am just missing? Either way this needs
> to be fixed.
Can somebody please verify if it works on their Alpha (or x86 for
that matter) to build gd?
W/
--
| / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
On Fri, Aug 24, 2001 at 10:32:48AM -0700, David O'Brien wrote: > On Fri, Aug 24, 2001 at 10:25:41AM -0700, Bruce A. Mah wrote: > > > > > > > make NODOC=YES ? > > > > I know that's not the "real" answer. > > Nope. We need an RC to test -- this means as close to the real release > as we can get. For now I want an .iso With or without docs And believe me, I like docs (heck, I wrote quite a bit for the Alpha) W/ [and I want an airco too; 30+ degr C is not fun with these 'hot' alphas around me] -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ata0-master: non aligned DMA transfer attempted
It seems Zhihui Zhang wrote: > > I write a program that writes into a raw device directly. Although the > program runs OK, the system prints messages like: > > ata0-master: non aligned DMA transfer attempted > > What exactly happens here? Is there any problem in my program? You are probably trying to write an amount of data that is not a whole number of the device's blocksize, for harddisks that is 512bytes. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
On Fri, Aug 24, 2001 at 10:25:41AM -0700, Bruce A. Mah wrote:
> If memory serves me right, Wilko Bulte wrote:
> > On Fri, Aug 24, 2001 at 09:05:16AM -0700, Bruce A. Mah wrote:
> > which is deprecated, use instead"
> > gdft.c:36: freetype/freetype.h: No such file or directory
> > gdft.c:37: freetype/ftglyph.h: No such file or directory
> > *** Error code 1
> >
> > Stop in /usr/ports/graphics/gd/work/gd-1.8.4.
> > *** Error code 1
> >
> > this is because 'gd' does not depend correctly on 'freetype2'
> >
> > a plain 'make' on the docproj port on Alpha fails in an identical fashion.
>
> G. Is it possible that mi's recent commit to ports/graphics/gd/Makefile
> introduced a typo in LIB_DEPENDS ("freetype" instead of "freetype.7")?
> Or is there some syntax here I am just missing? Either way this needs
> to be fixed.
USE_FREETYPE2= yes
BUILD_DEPENDS= bzip2:${PORTSDIR}/archivers/bzip2
LIB_DEPENDS=png.4:${PORTSDIR}/graphics/png \
jpeg.9:${PORTSDIR}/graphics/jpeg \
Looks like freetype2 is missing from the depends?
# $FreeBSD: ports/graphics/gd/Makefile,v 1.39 2001/08/23 19:24:42 mi Exp $
This probably also explains why make release succeeded yesterday on another
alpha, it seems to be fixed now:
revision 1.40
date: 2001/08/24 12:17:08; author: mi; state: Exp; lines: +3 -2
LIB_DEPEND on freetype again (regardless of version, what comes with
XFree86-4 should work too). I could've sworn, I saw some other port
use the seemingly non-existent USE_FREETYPE2. As a bonus, add a
patch for malloc.h -> stdlib.h...
While I'm here (again), switch the default maintainership to ports@.
Submitted by: John Hay
--
| / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
If memory serves me right, Wilko Bulte wrote: > This probably also explains why make release succeeded yesterday on another > alpha, it seems to be fixed now: OK. I think I may have been slightly wrong on what ailed the graphics/ gd port (apologies to mi), but if it's fixed, this is a moot point. On the successful make release mentioned above, you *did* build docs right? Only reason I'm asking is that I've never personally seen an alpha release with RELNOTESng, so I'm just guessing that all of the alpha-dependent content built correctly for the release (as opposed to when I do RELNOTESng snapshots). Bruce. PGP signature
Re: function calls/rets in assembly
On Fri, Aug 24, 2001 at 01:01:39AM +0100, Steve Roome wrote:
> How exactly should functions work in assembly, afaict, the
> following C :
>
> void printasint(int p) { printf ("print this %d\n", (int)p);}
Why not just ask the compiler??
$ cc -S -O0 printasint.c
$ cat printasint.s
.file "foo.c"
.version"01.01"
gcc2_compiled.:
.section.rodata
.LC0:
.byte0x70,0x72,0x69,0x6e,0x74,0x20,0x74,0x68,0x69,0x73
.byte0x20,0x25,0x64,0xa,0x0
.text
.p2align 2,0x90
.globl printasint
.typeprintasint,@function
printasint:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
addl $-8,%esp
movl 8(%ebp),%eax
pushl %eax
pushl $.LC0
call printf
addl $16,%esp
.L2:
leave
ret
.Lfe1:
.sizeprintasint,.Lfe1-printasint
.ident "GCC: (c) 2.95.3 20010315 (release)"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Proposed Utility - detach(1)
I would appreciate comments on the usefulness of a utility which would allow one to detach a process from a TTY. I imagine the utility would be very small and just call daemon(3) and execlp(3). Would a utility like this be useful? Is this functionality already available in a system utility? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: function calls/rets in assembly
On 24-Aug-01 David O'Brien wrote:
> On Fri, Aug 24, 2001 at 01:01:39AM +0100, Steve Roome wrote:
>> How exactly should functions work in assembly, afaict, the
>> following C :
>>
>> void printasint(int p) { printf ("print this %d\n", (int)p);}
>
> Why not just ask the compiler??
>
> $ cc -S -O0 printasint.c
> $ cat printasint.s
>
>
> .file "foo.c"
> .version"01.01"
> gcc2_compiled.:
> .section.rodata
> .LC0:
> .byte0x70,0x72,0x69,0x6e,0x74,0x20,0x74,0x68,0x69,0x73
> .byte0x20,0x25,0x64,0xa,0x0
> .text
> .p2align 2,0x90
> .globl printasint
> .typeprintasint,@function
> printasint:
> pushl %ebp
> movl %esp,%ebp
> subl $8,%esp
> addl $-8,%esp
> movl 8(%ebp),%eax
> pushl %eax
> pushl $.LC0
> call printf
> addl $16,%esp
> .L2:
> leave
> ret
> .Lfe1:
Because this code is broken and obfuscated? :)
We save %esp in %ebp (the only thing that keeps it from breaking) then for some
reason allocate two quadwords on the stack unnecessarily, one using an add
instruction, one using a sub. Then we push the two dword args on the stack and
call the function. After the call, we adjust the stack by 16, even though
we only used 8 bytes of arguments! Thus, it seems to be reclaiming one of the
2 quadwords it allocated on the stack in addition to the arguments passed to
the function. At this point if we did a 'pop %ebp' instead of leave, things
would break since we have a misaligned stack, but the leave restores the %esp
from %ebp, before pop'ing %ebp thus working around the bogus stack handling.
A better version would be this:
printasint:
pushl %ebp
movl %ebp, %esp
pushl 8(%ebp)
pushl $.LC0
call printf
addl $8,%esp
leave
ret
Note that with hand optimizing, you could axe the addl after the call since
leave will clean up after that anyways. Also, you don't really need a frame
here anyways. In that case, you could just push 8(%esp) as your first
instruction and axe the leave (but leave the addl).
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: function calls/rets in assembly
On Fri, Aug 24, 2001 at 11:36:45AM -0700, John Baldwin wrote: > Because this code is broken and obfuscated? :) You're submitting patches to the GCC maintainer to make it produce better code, right? :-) :-) :-) :-) -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: function calls/rets in assembly
On 24-Aug-01 Leo Bicknell wrote: > On Fri, Aug 24, 2001 at 11:36:45AM -0700, John Baldwin wrote: >> Because this code is broken and obfuscated? :) > > You're submitting patches to the GCC maintainer to make it > produce better code, right? :-) :-) :-) :-) I think I can just about handle the kernel. The compiler is a bit big for my abilities. :) I must say that at least the ia64 code it generates doesn't seem to do as many silly things like the subl/addl's of %esp, it just doesn't reorder the intructions very well to pack them into the "packets" so you end up with nops, but at least the instructions it does use make sense. :) -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: function calls/rets in assembly
Someone suggested to me privately turning on optimization, for the record that doesn't help much: (with -O2) .file "printasint.c" .version"01.01" gcc2_compiled.: .section.rodata .LC0: .byte 0x70,0x72,0x69,0x6e,0x74,0x20,0x74,0x68,0x69,0x73 .byte 0x20,0x25,0x64,0xa,0x0 .text .p2align 2,0x90 .globl printasint .typeprintasint,@function printasint: pushl %ebp movl %esp,%ebp subl $8,%esp addl $-8,%esp pushl 8(%ebp) pushl $.LC0 call printf leave ret .Lfe1: .sizeprintasint,.Lfe1-printasint .ident "[ASM_FILE_END]GCC: (c) 2.95.2 19991024 (release)" -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: totally weirdass problem, Squid-2.3-4 and FreeBSD
Try recompiling squid *after* you have your local shell's ulimit's unlimited, so that the higher limits get set by configure. Steps: 1. fix up your /etc/rc.sysctl to up kern.maxfilesperproc and kern.maxfiles 2. ulimit -n 1 (or if in csh/tcsh, type unlimit) * you may have to force the hardlimits up as well 3. recompile squid (ie. rerun configure so it picks up the new values) 4. install squid this should address the problems you see.. good luck.. -mohan On Fri, Aug 24, 2001 at 01:18:39PM -0400, Jim Mercer wrote: > this is because we have: > > /etc/rc (with default limits) > /etc/rc.sysclt (ups some of the limits) > /usr/local/etc/rc.d/squid.sh (inherits /etc/rc limits) > /usr/local/bin/RunCache (squid wrapper, inherits rc.d/squid.sh limits) >/usr/local/sbin/squid (inherits RunCache limits) > > so, if i just kill squid, it re-ineherits the limits effectively from /etc/rc. > > if i kill RunCache and squid, then restart, it gets the sysctl.conf limits. > > is there a work-around for this, other than killing/restarting squid after > each reboot? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: totally weirdass problem, Squid-2.3-4 and FreeBSD
On Fri, Aug 24, 2001 at 10:44:00AM -0700, mki wrote: > Try recompiling squid *after* you have your local shell's ulimit's > unlimited, so that the higher limits get set by configure. > > Steps: > 1. fix up your /etc/rc.sysctl to up kern.maxfilesperproc and kern.maxfiles > 2. ulimit -n 1 (or if in csh/tcsh, type unlimit) >* you may have to force the hardlimits up as well > 3. recompile squid (ie. rerun configure so it picks up the new values) > 4. install squid > > this should address the problems you see.. good luck.. unfortunately not. > > is there a work-around for this, other than killing/restarting squid after > > each reboot? i'm thinking maybe i should stick a "ulimit -n 1" in the rc.d/squid.sh file. i'll have to wait for a quiet period to test (the squid is doing some 7000 hits per minute when in production). -- [ Jim Mercer[EMAIL PROTECTED] +1 416 410-5633 ] [ Now with more and longer words for your reading enjoyment. ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: totally weirdass problem, Squid-2.3-4 and FreeBSD
On Thu, Aug 23, 2001 at 05:47:19PM -0700, Julian Elischer wrote: > the paranoid answer is that someone is replacing your squid and rebooting > the system to cover their tracks... you might think that, however, i'm not that paranoid. in any case, i think i've nailed down the problem. the wierd bit was that if i did a "squid -k shutdown" and let the wrapper script fire it back up, it would not see the sysctl up'd values. this is because we have: /etc/rc (with default limits) /etc/rc.sysclt (ups some of the limits) /usr/local/etc/rc.d/squid.sh (inherits /etc/rc limits) /usr/local/bin/RunCache (squid wrapper, inherits rc.d/squid.sh limits) /usr/local/sbin/squid (inherits RunCache limits) so, if i just kill squid, it re-ineherits the limits effectively from /etc/rc. if i kill RunCache and squid, then restart, it gets the sysctl.conf limits. is there a work-around for this, other than killing/restarting squid after each reboot? -- [ Jim Mercer[EMAIL PROTECTED] +1 416 410-5633 ] [ Now with more and longer words for your reading enjoyment. ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: running diff on huge files
Rob wrote: > > I am trying to run diff on two huge files (220M) and I run out of swap > space. Is there another alternative? I have a Python script that does > something similar, but works on huge files, but it is much slower than > diff. Thanks, Rob. > When I tried something like this, I froze the whole computer. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
On Fri, Aug 24, 2001 at 10:32:48AM -0700, David O'Brien wrote: > On Fri, Aug 24, 2001 at 10:25:41AM -0700, Bruce A. Mah wrote: > > > > > > > make NODOC=YES ? > > > > I know that's not the "real" answer. > > Nope. We need an RC to test -- this means as close to the real release > as we can get. OK, the NODOC-iso was bootable alright on a Miata. :-) :-) I've just fired up a new make release without NODOC. That should result in a RC-like .iso Should be ready by tomorrow, eh, today (saturday). W/ -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
running diff on huge files
I am trying to run diff on two huge files (220M) and I run out of swap space. Is there another alternative? I have a Python script that does something similar, but works on huge files, but it is much slower than diff. Thanks, Rob. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed Utility - detach(1)
Here's the original PR I sent in, and my code: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=6320 The included shell archive has a man page and source code that works, and has been run successfuly on systems as disparate as Xenix-286 and Tru64. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: running diff on huge files
On Fri, 24 Aug 2001, Rob wrote: > Rob wrote: > > > > I am trying to run diff on two huge files (220M) and I run out of swap > > space. Is there another alternative? I have a Python script that does > > something similar, but works on huge files, but it is much slower than > > diff. Thanks, Rob. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > split -b 5k put the files into managable size. Rob. doesn't work for files that have diffs across the 50k boundary.. you need a streaming diff... Interestingly this is not impossible.. you may be able to make one read the sources to diff. :-) > > 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: Possible race in i386/i386/pmap.c:pmap_copy()
: :Thinking about this a bit more :doesn't each process ahve it's own PTD?, so a process could sleep and :another could run but it would have a differnt PTD :so they could change that PTDE with impunity :because when teh current process runs again it get's its own :ptd back again.. Hmm. Ok, I think you are right. APTDpde is what is being loaded and that points into the user page table directory page, which is per-process. So APTDpde should be per-process. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: running diff on huge files
Julian Elischer wrote: > > On Fri, 24 Aug 2001, Rob wrote: > > > Rob wrote: > > > > > > I am trying to run diff on two huge files (220M) and I run out of swap > > > space. Is there another alternative? I have a Python script that does > > > something similar, but works on huge files, but it is much slower than > > > diff. Thanks, Rob. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > split -b 5k put the files into managable size. Rob. > > doesn't work for files that have diffs across the 50k boundary.. > you need a streaming diff... > > Interestingly this is not impossible.. you may be able to make one > read the sources to diff. > :-) It worked out OK. But I'll have to take an extra look at the file boundaries in the future. Rob. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: running diff on huge files
Rob wrote: > > I am trying to run diff on two huge files (220M) and I run out of swap > space. Is there another alternative? I have a Python script that does > something similar, but works on huge files, but it is much slower than > diff. Thanks, Rob. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message split -b 5k put the files into managable size. Rob. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed Utility - detach(1)
I thought that nohup() did that? I guess it's abit different... On Fri, 24 Aug 2001, Ben Smithurst wrote: > Chris Costello wrote: > > > On Friday, August 24, 2001, Mike Barcroft wrote: > >> I would appreciate comments on the usefulness of a utility which would > >> allow one to detach a process from a TTY. I imagine the utility would > >> be very small and just call daemon(3) and execlp(3). > >> > >> Would a utility like this be useful? Is this functionality already > >> available in a system utility? > > > >All shells implement this: > > > > sh: > > $ sleep 5 & > > $ > > [1] 61049 Exit 0 sleep 5 > > Err... putting a process in the background is quite different to > detaching it from the terminal. Or did I miss your point? > > -- > Ben Smithurst / [EMAIL PROTECTED] FreeBSD: The Power To Serve > http://www.FreeBSD.org/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible race in i386/i386/pmap.c:pmap_copy()
wouldn't Giant be protecting this?
On Fri, 24 Aug 2001, Matt Dillon wrote:
> Alfred, DG, could you take a look at pmap_copy() in i386/i386/pmap.c
> and tell me if what I think I'm seeing is what I'm seeing?
>
> My read of this code is that a global, APTDpde, is being set, and
> then that pointer is being used in a loop later on in the routine.
> the problem is that the pmap_allocpte() call can block and, by my
> read, that means some other process can go in and change APTDpde out
> from under the loop.
>
> This could also be related to problem Julian has been seeing with his
> KSE patch set.
>
> There is a comment:
>
> /*
> * We have to check after allocpte for the
> * pte still being around... allocpte can
> * block.
> */
> dstmpte = pmap_allocpte(dst_pmap, addr);
> if ((*dst_pte == 0) && (ptetemp = *src_pte)) {
> /*
> * Clear the modified and
> ...
>
It seems real but it isn't causeing my problem as far as I can see.
I added code to compare the Alternate PTD entry to the value set into it
and it isn't changing..
> But I do not believe this check is sufficient if APTDpde gets ripped
> out from under the loop. Is this race real or am I blowing smoke?
>
I read it through and you are correct in that pmap_allocpte()
can block. (I followed it thropugh,, there are at least 2
tsleeps in the functions it calls.
Despite that I'm stil getting the same errors as yesterday..
(only the printf shows more info now)..
TPTE at 0xbfca0144 IS ZERO @ VA 28051000
TPTE at 0xbfca0188 IS ZERO @ VA 28062000
> -Matt
>
>
> 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: Possible race in i386/i386/pmap.c:pmap_copy()
On 25-Aug-01 Julian Elischer wrote: > > wouldn't Giant be protecting this? Not if the code blocks. Giant is released in tsleep(). -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: function calls/rets in assembly
On 24-Aug-01 Leo Bicknell wrote: > > Someone suggested to me privately turning on optimization, for > the record that doesn't help much: (with -O2) Actually, it's fairly close to what I proposed. It even axed the addl after the call. The only weirdness is the subl/addl dinking with gcc. I've no idea what that is about. Perhaps it is using that to align code to a certain boundary to optimize the ret inside printf? (Make it fetch at the start of a cache line or some such.) > .p2align 2,0x90 > .globl printasint > .typeprintasint,@function > printasint: > pushl %ebp > movl %esp,%ebp > subl $8,%esp > addl $-8,%esp > pushl 8(%ebp) > pushl $.LC0 > call printf > leave > ret > .Lfe1: > .sizeprintasint,.Lfe1-printasint > .ident "[ASM_FILE_END]GCC: (c) 2.95.2 19991024 (release)" -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible race in i386/i386/pmap.c:pmap_copy()
Thinking about this a bit more
doesn't each process ahve it's own PTD?, so a process could sleep and
another could run but it would have a differnt PTD
so they could change that PTDE with impunity
because when teh current process runs again it get's its own
ptd back again..
On Fri, 24 Aug 2001, Matt Dillon wrote:
> Alfred, DG, could you take a look at pmap_copy() in i386/i386/pmap.c
> and tell me if what I think I'm seeing is what I'm seeing?
>
> My read of this code is that a global, APTDpde, is being set, and
> then that pointer is being used in a loop later on in the routine.
> the problem is that the pmap_allocpte() call can block and, by my
> read, that means some other process can go in and change APTDpde out
> from under the loop.
>
> This could also be related to problem Julian has been seeing with his
> KSE patch set.
>
> There is a comment:
>
> /*
> * We have to check after allocpte for the
> * pte still being around... allocpte can
> * block.
> */
> dstmpte = pmap_allocpte(dst_pmap, addr);
> if ((*dst_pte == 0) && (ptetemp = *src_pte)) {
> /*
> * Clear the modified and
> ...
>
> But I do not believe this check is sufficient if APTDpde gets ripped
> out from under the loop. Is this race real or am I blowing smoke?
>
> -Matt
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed Utility - detach(1)
On Friday, August 24, 2001, Mike Barcroft wrote: > I would appreciate comments on the usefulness of a utility which would > allow one to detach a process from a TTY. I imagine the utility would > be very small and just call daemon(3) and execlp(3). > > Would a utility like this be useful? Is this functionality already > available in a system utility? All shells implement this: sh: $ sleep 5 & $ [1] 61049 Exit 0 sleep 5 ksh: $ sleep 5 & [1] 61052 $ [1] + Donesleep 5& csh: % sleep 5 & [1] 61058 % [1]Done sleep 5 etc. Why does this need to be implemented in a separate executable? -- +---++ | Chris Costello| God didn't create the world in 7 days. | | [EMAIL PROTECTED] | He pulled an all-nighter on the 6th. | +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
On Fri, Aug 24, 2001 at 10:52:50AM -0700, Bruce A. Mah wrote: > If memory serves me right, Wilko Bulte wrote: > > > This probably also explains why make release succeeded yesterday on another > > alpha, it seems to be fixed now: > > OK. I think I may have been slightly wrong on what ailed the graphics/ > gd port (apologies to mi), but if it's fixed, this is a moot point. > > On the successful make release mentioned above, you *did* build docs > right? Only reason I'm asking is that I've never personally seen an Eh, that was the other machine, yes, the build went OK and the ports necessary ports for doc building were also correctly built. > alpha release with RELNOTESng, so I'm just guessing that all of the > alpha-dependent content built correctly for the release (as opposed to > when I do RELNOTESng snapshots). I have not checked the generated docs, but I assume things went OK. The DS10 is now rolling tarballs (with NODOC=YES) so that make release appears to have run OK. I can try (overnight) a new make release without the NODOC and see what tomorrow morning gives me. If that proves OK I think I put the resulting .iso up for download. Wilko -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
If memory serves me right, Wilko Bulte wrote: > Eh, that was the other machine, yes, the build went OK and the > ports necessary ports for doc building were also correctly built. OK, cool. > The DS10 is now rolling tarballs (with NODOC=YES) so that make release > appears to have run OK. I can try (overnight) a new make release without > the NODOC and see what tomorrow morning gives me. > > If that proves OK I think I put the resulting .iso up for download. That'll be good to see. G'luck! Bruce. PGP signature
Re: function calls/rets in assembly
You guys are forgetting about the stack-boundry crap some idiot added to GCC to optimize floating point ops, which gets stuffed in there even if there are no floating point ops. I really wish someone would rip it out. It is SOOO fraggin annoying. -Matt cc -S -O -fomit-frame-pointer -mpreferred-stack-boundary=2 x.c printasint: pushl 4(%esp) pushl $.LC0 call printf addl $8,%esp ret cc -S -fomit-frame-pointer -mpreferred-stack-boundary=2 x.c printasint: movl 4(%esp),%eax pushl %eax pushl $.LC0 call printf addl $8,%esp .L2: ret To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed Utility - detach(1)
Chris Costello wrote: > On Friday, August 24, 2001, Mike Barcroft wrote: >> I would appreciate comments on the usefulness of a utility which would >> allow one to detach a process from a TTY. I imagine the utility would >> be very small and just call daemon(3) and execlp(3). >> >> Would a utility like this be useful? Is this functionality already >> available in a system utility? > >All shells implement this: > > sh: > $ sleep 5 & > $ > [1] 61049 Exit 0 sleep 5 Err... putting a process in the background is quite different to detaching it from the terminal. Or did I miss your point? -- Ben Smithurst / [EMAIL PROTECTED] FreeBSD: The Power To Serve http://www.FreeBSD.org/ PGP signature
Re: function calls/rets in assembly
In the last episode (Aug 24), John Baldwin said: > On 24-Aug-01 Leo Bicknell wrote: > > Someone suggested to me privately turning on optimization, for the > > record that doesn't help much: (with -O2) > > Actually, it's fairly close to what I proposed. It even axed the > addl after the call. The only weirdness is the subl/addl dinking > with gcc. I've no idea what that is about. Perhaps it is using that > to align code to a certain boundary to optimize the ret inside > printf? (Make it fetch at the start of a cache line or some such.) For what it's worth, gcc30 -O produces: .align 4 .globl printasint .type printasint,@function printasint: pushl %ebp movl%esp, %ebp subl$16, %esp pushl 8(%ebp) pushl $.LC0 callprintf leave ret -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What is the best mail virus scanner?
We've done a review of Kaspersky Anti-Virus [http://www.kaspersky.com/products.asp?tgroup=3&pgroup=9&id=52] at BSDatwork.com Its an excellent program that can be integrated seemlessly with sendmail. You can read the review here - http://www.bsdatwork.com/reviews.php? op=showcontent&id=1 - aaron - click46[wp] - AIM the click46 - ICQ 43450396 webpimps.net | bsdatwork.com | nerdserve.net moderator - o/c cooling forum @ hardforum.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible race in i386/i386/pmap.c:pmap_copy()
Matt Dillon wrote: > > : > :Thinking about this a bit more > :doesn't each process ahve it's own PTD?, so a process could sleep and > :another could run but it would have a differnt PTD > :so they could change that PTDE with impunity > :because when teh current process runs again it get's its own > :ptd back again.. > > Hmm. Ok, I think you are right. APTDpde is what is being loaded > and that points into the user page table directory page, which is > per-process. So APTDpde should be per-process. But it is! (sort-of) APTDpde was per-process but is now per-address-space with the advent of fork and RFMEM sharing (and KSE). When we context switch, PTD goes with the process^H^H^H^Haddress space, and APTD is merely mapped by the last entry in the per-process PTD (PTD[APTDPDTI] if memory serves correctly). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible race in i386/i386/pmap.c:pmap_copy()
:> Hmm. Ok, I think you are right. APTDpde is what is being loaded :> and that points into the user page table directory page, which is :> per-process. So APTDpde should be per-process. : :But it is! (sort-of) APTDpde was per-process but is now per-address-space :with the advent of fork and RFMEM sharing (and KSE). : :When we context switch, PTD goes with the process^H^H^H^Haddress space, and :APTD is merely mapped by the last entry in the per-process PTD :(PTD[APTDPDTI] if memory serves correctly). : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Oh !@#$#@$.. you're right! That means there *IS* a race, just that it is a race in the case where you use rfork. APTDpde can be ripped out from under one thread by another thread. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building 'release' and compiling doc ports
On Fri, Aug 24, 2001 at 04:11:18PM -0700, Bruce A. Mah wrote: > If memory serves me right, Wilko Bulte wrote: > > > Eh, that was the other machine, yes, the build went OK and the > > ports necessary ports for doc building were also correctly built. > > OK, cool. Apparantly not. > > The DS10 is now rolling tarballs (with NODOC=YES) so that make release > > appears to have run OK. I can try (overnight) a new make release without > > the NODOC and see what tomorrow morning gives me. > > > > If that proves OK I think I put the resulting .iso up for download. > > That'll be good to see. ===> Installing for sgmlformat-1.7 ===> sgmlformat-1.7 depends on executable: onsgmls - not found ===>Verifying install for onsgmls in /usr/ports/textproc/openjade >> No directory for onsgmls. Skipping.. ===> sgmlformat-1.7 depends on file: /usr/local/share/sgml/linuxdoc - not foun d ... * ===> Registering installation for sgmlformat-1.7 sgmlformat-1.7: "/usr/ports/textproc/openjade" non-existent -- dependency list i ncomplete ===> Returning to build of docproj-1.8 ... and of course in the end: ticle.sgml > article.html || (rm -f article.html && false) /usr/local/bin/openjade: not found *** Error code 1 Guess: some of the ports has changed(???). It is really not a lot of fun to be dependent on so much ports that are in flux when trying to build a release W/ -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: your mail
>From now on, please use the test@ email list for testing. None of us care if your Mail:: module works On Sat, 25 Aug 2001, Charlie Root wrote: > Subject: Mail::Internet test subject > > > This is a test message that was sent by the test suite of > Mail::Internet. > > Testing. > > one > > >From foo > four > > >From bar > seven > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Laurence Berland http://www.isp.northwestern.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible race in i386/i386/pmap.c:pmap_copy()
Peter Wemm wrote: > > Matt Dillon wrote: > > > > : > > :Thinking about this a bit more > > :doesn't each process ahve it's own PTD?, so a process could sleep and > > :another could run but it would have a differnt PTD > > :so they could change that PTDE with impunity > > :because when teh current process runs again it get's its own > > :ptd back again.. > > > > Hmm. Ok, I think you are right. APTDpde is what is being loaded > > and that points into the user page table directory page, which is > > per-process. So APTDpde should be per-process. > > But it is! (sort-of) APTDpde was per-process but is now per-address-space > with the advent of fork and RFMEM sharing (and KSE). AH yes, it's a race for KSe, but we are 1:1 still so it's not a problem (yet :-) ( at least, not the one that's hitteng me at the moment) For your info peter, What I'm seeing is that at exit (or maybe even before), occasionally PTES are found to have already been zero'd even though thevm thinks they should still be valid.. I can't imagine what I've screwed up but it's sure subtle... > > When we context switch, PTD goes with the process^H^H^H^Haddress space, and > APTD is merely mapped by the last entry in the per-process PTD > (PTD[APTDPDTI] if memory serves correctly). (second last) > > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
