5.0-RUSH: -current install testers wanted!
I built a make release overnight and I managed to install from it by copying the boot.flp image to a ZIP disk, selecting Minimum and FTP passive. So far so good. But we all know that sysintall has a few more bells and whistles than that, so NOW is the TIME of all good men to come to the aid of their favourite installer! I want as many people as possible to beat up on sysinstall as much as they can. And I want them to do it RSN: 5.0-R is only 9 days away. Please try to be creative in the choices you make in sysinstall, we don't need 20 people all testing ftp-passive, we need to get all the media options tested, IPv4 and IPv6, all the different distributions, scripted installs, on different hardware configs and so. If you find problems, please try to see if you reproduce them, if you can, try to see if you can isolate them to some particular menu choice or set of circumstances. Please report your findings with send-pr. If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. I can't promise to fix all the issues which come up, but I will do my very best... -- 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: Scheduling a recurring task in a device driver
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Luigi Rizzo [EMAIL PROTECTED] writes: : a timeout() call will do (at most once per tick). grep for timeout( : in most of device drivers to see how to use it. Also, A software interrupt would be good too, depending on the nature of the recurring event. I considered suggesting this, but you are right about needing to know more about the frequency and other requirements of the hardware bug they are working around, before a useful suggestion is possible. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Poul-Henning Kamp wrote: I want as many people as possible to beat up on sysinstall as much as they can. And I want them to do it RSN: 5.0-R is only 9 days away. Please try to be creative in the choices you make in sysinstall, we don't need 20 people all testing ftp-passive, we need to get all the media options tested, IPv4 and IPv6, all the different distributions, scripted installs, on different hardware configs and so. If you find problems, please try to see if you reproduce them, if you can, try to see if you can isolate them to some particular menu choice or set of circumstances. Please report your findings with send-pr. Ad-Hoc testing is unlikely to find problems; if you are expecting a certain class of problems, it's best to treat them, up front. There are a number of systems right now with broken INT 0x12 implementations which will not boot at all right now (they panic almost immediately). I think you are going to end up with a lot of bug reports not related to the problems you are trying to prevent/address. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
What a lame program... If this program is indicative of your real-world work-load, you can optimize a lot by getting better programmers. If it is not indicative, then forget about it. i wish i could :-) danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Danny Braniss wrote: What a lame program... If this program is indicative of your real-world work-load, you can optimize a lot by getting better programmers. If it is not indicative, then forget about it. i wish i could :-) This is a memory overcommit architecture. If you want to avoid the problem, set process limits, such that the programs you run will not hit hard system limits, and will hit administrative limitations instead. This will prevnt the core dumps you were seeing. I implied this in my last post; I'm being very explicit now. If you want GNU malloc behaviour, then you should install the port for the GNU allocator, and use it instead of the system allocator, and you will end up with the same behaviour that your application has on Linux. As far as the speed of your FP programs, I suggest looking at man fpsetmask, and realize that the Linux defaults fail to comply with IEEE floating point standards. Specifically, there was a recent discussion on the -current list about FP compliance testing, which demonstrated Linux non-compliance. I believe the code in that thread was downloadable from NIST and from UC Berkeley. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2002-10-21 ] [ Subjecte: 5.0-RUSH: -current install testers wanted! ] I want as many people as possible to beat up on sysinstall as much as they can. I've been fighting to find a way to install -CURRENT pure on my workstation using the 4.7 CD I just got in the mail, to no avail, because of the bin-base thing. But with the 4.7 installer, bouncing around in the FTP and networking screens, having done the restart sysinstall thing once, I managed to get a SIG11, though I couldn't reproduce it with debugging on. Anyone with a good idea on how to bootstrap a _clean_ 5.0 install to a box with only a CDROM drive, and 4.7 CD, with broken PXE firmware, and an IDE disk which can be thrashed, by all means tell me... I'd imagine that I could just use the mfsroot and kernel, but there's no way for me to disable atkbd/atkbdc that _I_ know of, in the post-userconfig world, and my keyboard is broken at the mountroot prompt, as the atkbdc detected based on my usb keyboard makes neither interface work, as both are exposed to the kernel. I've never had to install CURRENT on here without the ability to burn a bootable CD, and use userconfig... Yes, it was that long ago that I did my initial install. Thoughts? Yes, I could build my own kernel and fake it, but I can't do that in a real, user environment, and I'd love to have some idea of what might be possible... Damned Korean legacy-free box :/ Thanks, juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Juli Mallett wrote: Anyone with a good idea on how to bootstrap a _clean_ 5.0 install to a box with only a CDROM drive, and 4.7 CD, with broken PXE firmware, and an IDE disk which can be thrashed, by all means tell me... I'd imagine that I could just use the mfsroot and kernel, but there's no way for me to disable atkbd/atkbdc that _I_ know of, in the post-userconfig world, and my keyboard is broken at the mountroot prompt, as the atkbdc detected based on my usb keyboard makes neither interface work, as both are exposed to the kernel. I've never had to install CURRENT on here without the ability to burn a bootable CD, and use userconfig... Yes, it was that long ago that I did my initial install. Thoughts? Find another box where it has already been successfully installed, and an ISO image has been built from sources. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] Juli Mallett wrote: Anyone with a good idea on how to bootstrap a _clean_ 5.0 install to a box with only a CDROM drive, and 4.7 CD, with broken PXE firmware, and an IDE disk which can be thrashed, by all means tell me... I'd imagine that I could just use the mfsroot and kernel, but there's no way for me to disable atkbd/atkbdc that _I_ know of, in the post-userconfig world, and my keyboard is broken at the mountroot prompt, as the atkbdc detected based on my usb keyboard makes neither interface work, as both are exposed to the kernel. I've never had to install CURRENT on here without the ability to burn a bootable CD, and use userconfig... Yes, it was that long ago that I did my initial install. Thoughts? Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: Soeren Schmidt [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] It seems Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. Where do you live ? I'm sure we can find someone with a CD burner near you willing to make a copy and snailmail it to you... (Consider this a beg for anyone close enough for it to be cost effective to send me a 5.0-CURRENT snapshot CD, on which I can somehow disable the atkbdc/atkbd stuff at bootup, or which has them out of the kernel...) Juli Mallett 11145 W 76th Terrace Shawnee, KS 66214 United States Thanks for the idea :) juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Your code is not efficient; try this instead: He, the code is not mine, and the programmer is being invited for some coffee and indocrination. The program showed at least two things, 1- the linux emulation ignores the datasize limit, 2- is faster for this particular case of bad programing. btw, the host has 4gb of main memory, so i don't think it swapped. actually i just rebooted the machine with no swap to make sure. I'm not passing judgement as to what is better - though im biased to *BSD - but the fact is that i have some 1500 users, and some 600 computers, and (i hope none of my users are reading this) the users are getting less sophisticated - and when i get complains that it works on Linux, but not under FreeBSD i try very hard to prove them wrong, but im loosing. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
[...] If you want GNU malloc behaviour, then you should install the port for the GNU allocator, and use it instead of the system allocator, and you will end up with the same behaviour that your application has on Linux. what ticked my curiosity was that the linux binary did work, while the fbsd binary did the right thing with respect to the admin limits and coredumped when the datasize limit was exeeded. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. You don't burn a CD from the other box, you install from it. Though FreeBSD doesn't technically support it, because they do not make the sysinstall image easily available, you can upgrade via a CDROM FS image via NFS, without even needing a local CDROM installed on the machine being upgraded. To do this, copy over /stand/sysinstall to /tmp/sysinstall (it is crunched, therefore av[0] needs to be sysinstall), mount the image via NFS, run the sysinstall in /tmp, and select local file system for the media from which you will be upgrading. You must manullay run disklabel to change the boot code, after the upgrade, and prior to the reboot (the upgrade code in sysinstall makes assumptions about the boot media when it comes to the boot code installation, and those assumptions are often invalis, as in this case). If you are using SSH, you will potentially need to add the ssh line to the pam.conf file, or you will need physical console access to get back into the machine after you reboot with the new OS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. You don't burn a CD from the other box, you install from it. Though FreeBSD doesn't technically support it, because they do not make the sysinstall image easily available, you can upgrade via a CDROM FS image via NFS, without even needing a local CDROM installed on the machine being upgraded. To do this, copy over /stand/sysinstall to /tmp/sysinstall (it is crunched, therefore av[0] needs to be sysinstall), mount the image via NFS, run the sysinstall in /tmp, and select local file system for the media from which you will be upgrading. You must manullay run disklabel to change the boot code, after the upgrade, and prior to the reboot (the upgrade code in sysinstall makes assumptions about the boot media when it comes to the boot code installation, and those assumptions are often invalis, as in this case). If you are using SSH, you will potentially need to add the ssh line to the pam.conf file, or you will need physical console access to get back into the machine after you reboot with the new OS. If I wanted to do this, I could, but it would not give me a clean 5.0 install, and it is also not that simple at this time, as (afaict) kern.disks is required by sysinstall, which 4.x doesn't support... And even then, I'd have to blow away everything except /tmp first, which is a hell of a lot of fun, especially when it (often) doesn't work... -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Danny Braniss wrote: If you want GNU malloc behaviour, then you should install the port for the GNU allocator, and use it instead of the system allocator, and you will end up with the same behaviour that your application has on Linux. what ticked my curiosity was that the linux binary did work, while the fbsd binary did the right thing with respect to the admin limits and coredumped when the datasize limit was exeeded. The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero. The Linux malloc uses pages added to the process address space via a call to sbrk. The FreeBSD malloc guarantees that the pages are zeroed before being obtained from the system; this is probably the majority of the cost. It is a security measure, so that you do not leak data from one process to another through anonymous pages. The Linux malloc does not. The FreeBSD malloc does not impose a size limit based on the (potential) collision of the stack with the heap. The Linux Malloc must impose a memory limit based on the possibility of such a collision. The FreeBSD malloc allocates untouched pages: the pages are faulted in when they are accessed. The Linux malloc pays the penalty up front, and so doesn't run into a usage shortage, if you use a thrashing access pattern, like your example application used, to intentionally thrash memory (twice; once on allocation, once again on checking of the reference, after). The FreeBSD malloc references an environment variable and a readlink() of a potentially non-existant symbolic link containing configuration data for the malloc. The Linux malloc does not have this overhead. The FreeBSD malloc would be lower performance than the Linux malloc, if you allocate space in teeny, tiny chunks; it has much higher performance for large allocations. Good programmers allocate their resources up front, once, instead of doing the allocations in time critical internal loops. The FreeBSD allocation is an overcommit allocation; this means that the malloc could succeed, obtain a memory mapping for the pages, but run out of pages to use as backing store for the address space so mapped. This *only* happens if the administrative limits on the applications are larger than the available physical resources: don't do that: man login.conf, man limit. If you want to have the Linux malloc behaviour on FreeBSD, then link your application with the Linux malloc library. It is available as a port for you to install on your FreeBSD system: cd /usr/ports/devel/libmalloc make all install ...and them link your applications with the malloc library, instead of using the system malloc. Can't really make it any more clear than that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Danny Braniss wrote: Your code is not efficient; try this instead: He, the code is not mine, and the programmer is being invited for some coffee and indocrination. Good. The program showed at least two things, 1- the linux emulation ignores the datasize limit, Possibly. One would expect it to core, then, when you ran out of memory; you said (in your original posting) that it was the FreeBSD version of the code that cored?!? 2- is faster for this particular case of bad programing. Don't expect FreeBSD to ever optimize system code to make bad programmers look like good programmers. It's not going to happen. btw, the host has 4gb of main memory, so i don't think it swapped. actually i just rebooted the machine with no swap to make sure. Then you aren't getting the core dump you said you were. 8-). I'm not passing judgement as to what is better - though im biased to *BSD - but the fact is that i have some 1500 users, and some 600 computers, and (i hope none of my users are reading this) the users are getting less sophisticated - and when i get complains that it works on Linux, but not under FreeBSD i try very hard to prove them wrong, but im loosing. If you are fighting that fight, you might as well switch to Windows, and be done with it, because people can make the same argument with Windows vs. Linux instead of Linux vs. FreeBSD, since the issues are exactly analogous: the Windows environment does a much better job than Linux of allowing bad programmers to write code that runs. And Linux does this better than FreeBSD (there are even Linux libraries that will treat NULL pointers as if they were pointers to strings with a value of -- and don't think there isn't runtime overhead associated with the extra compares again NULL for each and every strcpy(), strlen(), etc.. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. snapshots.jp.freebsd.org hasn't completed a make release since September 17th by the looks of things. Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel + mfsroot article review
On Fri, Oct 18, 2002 at 04:42:01PM -0700, David Yeske wrote: MD_ROOT_SIZE is only needed for write_mfs_in_kernel. When write_mfs_in_kernel was removed the code that used it was not though. I don't think it is still being used though. A couple of files still reference it: src/sys/dev/md/md.c has ifdefs for it, src/release/Makefile still compiles it on stable, src/sys/conf/options still defines it in opt_md.h, src/sys/i386/conf/LINT still has an example... MFS_ROOT_SIZE seems to be even more stale. phk probably knows for sure though... I, for one, still use it to do remote net installs via dhcp/tftp. Works like a charm, together with write_mfs_in_kernel... Zlo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
smbfs install option
I got a smbfs install option working a while ago before drivers.flp came around, but there was no space on the floppies. Since drivers.flp came out I have not had time to get it going again. This patch is NOT up to date though. I was wondering how I should go about making this usable, and which files should be on boot.flp, mfsroot.flp, drivers.flp, or somewhere else. Should this go into 5.0R, or make it into HEAD after RELENG_5 branches, or should this be applied to something other than sysinstall? Or should we not have a smbfs install option? The diff to GENERIC is NOT implying I think GENERIC should be modifed. I did that just to have those things added to GENERIC so they would make it onto BOOTMFS. http://pigseye.kennesaw.edu/~dyeske/freebsd/smbfs_current.patch http://pigseye.kennesaw.edu/~dyeske/freebsd/smbfs.c Also I modified nfs.c to make smbfs.c Regards, David Yeske __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
cdrom.1 build option
Most of the time I don't need cdrom images when I make release. This patch should make it an option. It does not change the default. If this looks ok than I can open a pr and submit it... http://pigseye.kennesaw.edu/~dyeske/freebsd/patch-src_release_Makefile Regards, David Yeske __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
[...] Possibly. One would expect it to core, then, when you ran out of memory; you said (in your original posting) that it was the FreeBSD version of the code that cored?!? true, but i also mentioned how i fixed it, by increasing the MAXDSIZ option. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Terry Lambert [EMAIL PROTECTED] wrote: The FreeBSD malloc guarantees that the pages are zeroed before being obtained from the system; this is probably the majority of the cost. It is a security measure, so that you do not leak data from one process to another through anonymous pages. The Linux malloc does not. Utter bollocks. FreeBSD malloc can be configured to re-initialize memory on every allocation, but this is designed to assist with buggy programs, it is *not* a security measure. Memory obtained from the kernel on *all* unices (including Linux) is zeroed; that is when security matters, not in malloc. This will not affect the relative performance of phk and gnu malloc. The FreeBSD malloc references an environment variable and a readlink() of a potentially non-existant symbolic link containing configuration data for the malloc. Once at program startup. This is not a significant cost. The FreeBSD allocation is an overcommit allocation True for Linux too, by default. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ NORTH UTSIRE: EAST 4 OR 5 INCREASING 6 TO GALE 8. RAIN. MODERATE. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PThreads problem
On Tue, Oct 22, 2002 at 12:31:32PM +0100, Bruce M Simpson wrote: On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote: It is more correct to say that libcurl makes an assumption about signal delivery which is not guaranteed by POSIX, and therefore libcurl will not work with *any* POSIX compliant threads implementation which does not *happen* to work this way. Would a more correct approach, when dealing with POSIX threads and signals, be to make sure signals are delivered to a single thread *expressly for that purpose*, and then use POSIX thread primitives (such as mutexes and condvars) to communicate the signal conditions to the other threads? ..and when you start writing programs which depend on this functionality, they will not work on any system that does not do it. Part of the problem is that the linuxthreads approach of different threads as different processes would require that you deliver each and every signal destined for a 'worker' thread/process to the designated 'signal handler' thread/process; I am practically certain that no one in the Linux kernel crowd would like the idea of redirecting all signals from one process to another :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. msg37527/pgp0.pgp Description: PGP signature
Re: Ati Rage 128: Dpms suspend failes
Eric Anholt writes: On Mon, 2002-10-21 at 08:16, Hanspeter Roth wrote: Hello, I have two hosts connected to one monitor. My idea is attach the display to the other host by issuing `xset dpms force suspend'. This works on one host with a Matrox Millenium. On the host with an Ati Rage 128 Pro TF it works with Netbsd, but it doesn't work with FreeBSD 4.7-Release. The screen only turns blank but the LED remains green. This is the same when issuing `xset s activate'. What could be the reason on FreeBSD 4.7 that dpms force suspend doesn't work? Installed are XFree86-Server-4.2.1_3 and XFree86-libraries-4.2.1_1.) You need XFree86-Server-4.2.1_4 or later (it's at _5 now). I've now upgraded to XFree86-Server-4.2.1_5. dpms still does not work for me: % xset dpms force off ; xset q | tail -5 Standby: 300Suspend: 600Off: 660 DPMS is Enabled Monitor is Off Font cache: hi-mark (KB): 1024 low-mark (KB): 768 balance (%): 70 (and I'm looking at the monitor and it is on) My video card is an ATI Rage 128: none1@pci1:0:0: class=0x03 card=0x7106174b chip=0x54461002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage 128 Pro AGP 4x' class= display subclass = VGA Do I need something special in my /etc/X11/XF86Config to make this work? I never had problems on my old system (an alpha with a 3dlabs Permedia-2 based AGP card). Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ati Rage 128: Dpms suspend failes
On Oct 22 at 10:37, Andrew Gallatin spoke: I've now upgraded to XFree86-Server-4.2.1_5. dpms still does not work for me: % xset dpms force off ; xset q | tail -5 I didn't care about off. My monitor seems to behave the similar when set to `off' as when set to suspend or standby. The status LED turns yellow and the screen turns blank and recovery takes a few seconds. My application is to switch the display to the alternate host. This is working now. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ati Rage 128: Dpms suspend failes
Hanspeter Roth writes: On Oct 22 at 10:37, Andrew Gallatin spoke: I've now upgraded to XFree86-Server-4.2.1_5. dpms still does not work for me: % xset dpms force off ; xset q | tail -5 I didn't care about off. My monitor seems to behave the similar when set to `off' as when set to suspend or standby. The status LED turns yellow and the screen turns blank and recovery takes a few seconds. As does mine (based on experiance from when I had a video card that worked in my old machine :-( ) My application is to switch the display to the alternate host. This is working now. Lucky you! What does pciconf -lv say about your card? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Last week I replace a broken mainboard with a dual-Athlon one (Tyan
Tiger s2466n-4m) and decided to upgrade that box from 4-stable to
-current by installing the 0917-jpsnap via the floppies and passive
ftp. I hit several sysinstall-problems some of which my already be
fixed:
- The hd I install -current onto previously had 4-stable on it, I
deleted slice one (was the only one) and created a new one and
selected the standard MBR. I decided to give UFS2 a try and created
the filesystems with '-O 2 -U' (there was some problem toggling
Softupdates und just adding '-O 2' to the newfs-options). But after
rebooting the 4-stable (!) bootloader came claiming it wasn't able
to load /kernel, a `ls` at the bootloader-prompt showed the contents
of the former root-fs, even the former contents of some of the sub-
direcroties , e.g. /etc could be displayed.
- After a `dd if=/dev/zero of=/dev/da0 count=16` (booted with another
hd containing 4-stable) I repeated the above procedure and ended up
with the -current bootloader yelling No UFS several times. For now
I ended up having the root-fs UFS1 and var, usr and tmp UFS2.
This problem seems to be on the todo-list.
- During the 6-7 sysinstall-runs (it hung and crashed unreproduceable
4-5 times) I always had the problem that after configuring the nic
with a ipv4-adress it took some random time between ~15 seconds up
to several minutes to look up the hostname of the jpsnap-server.
This definitely wasn't a network- or dns-problem, another box
connected via the same line and using the same nameserver didn't
have problems looking up the hostname. I ran tcpdump on the other
box and the reason for this seems to be sysinstall doing ipv6
neigbhourhood-detection and ping6 the ipv6-address of the jpsnap-
server also the interface wasn't configured for ipv6. I also saw
some stuff that I don't know of what it is:
fe80::2e0:81ff:fe22:d7cf ff02::2:f8c7:7880: HBH icmp6: multicast listener report
max resp delay: 0 addr: ff02::2:f8c7:7880 [hlim 1]
- The 3 or 4 times I got to the point to set the root password the
prompt to enter it popped up in ttyv1 and not in tty0 like the
rest of sysinstall. I wasn't actually able to set one but sysinstall
returned to the post-install-configuration-menue when hitting
ctrl-c in ttyv0.
Some problems I have with the installed -current:
- The bios of the board offers ACPI-support and as I thought FreeBSD's
support of this is advanced enough I decided to turn it but it turned
out to not be SMP-safe. I can't remeber a panic while running an
UP-kernel for the short time to update to latest -current and build
a SMP-kernel. When both ACPI- (via kld) and SMP-support are enabled
the box is fscking unstable, I get about 3 lock-order-reversal- and
locking-against-myself-panics per hour and occasionally spontaneous
reboots. After turing of ACPI-support in the bios the ACPI-kld no
longer gets loaded and the box runs stable for 3 days (no more
panics or spontaneous reboots), still with the same kernel built
of sources as of Oct 17.
The mainboard has 2 pci-bridges, they and all devices behind them
successfully get probed when running with ACPI enabled so this
doesn't sound like the problem described in the todo-list.
acpiconf doesn't work except for `acpiconf -s 1` (after an
`acpiconf -e`), `acpiconf -s 1` turns off the output of the gfx-
card for the fraction of second (once also the hd sounded as it
would spin-down) and as soon it returns 2 resume-messages get
displayed. Doing this causes a panic (pagefaults iirc) in about
1 of 5 times.
- After the tons of panics I got the background fsck always cleaned
up an alarming number of files and directories on the UFS2-
filesystems, much more than I've ever seen after a panic of a
4-stable box. As I got most panics while extracting tarballs or
building ports this could be ok but once also file I successfully
downloaded some 30-60 seconds before a panic got deleted during
the fsck-run, imho this shouldn't happen.
Last but not least it would be fine if sysinstall would also support
ATAPI-floppies (/dev/afd0) for mounting the fixit-floppy. I didn't
check recently but I think support for mounting the live-cdrom in
SCSI-cdroms is also broken, last time I tried it also wasn't
possible to install from a SCSI-cdrom as sysinstall didn't detect
/dev/cd0c. Hrm, the minor looks wrong in devices.c, could this be the
reason ?
static struct _devname {
DeviceType type;
char *name;
char *description;
int major, minor, delta, max;
} device_names[] = {
{ DEVICE_TYPE_CDROM,cd%dc,SCSI CDROM drive, 15, 2, 8, 4
but:
ls -la /dev/cd0c
crw-r- 1 root operator 15, 0 Oct 22 19:02 /dev/cd0c
At least the minor matches for acd0c.
Marius
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: malloc
On Tue, Oct 22, 2002 at 01:20:42AM -0700, Terry Lambert wrote: The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero. The Linux malloc uses pages added to the process address space via a call to sbrk. There is no Linux malloc, neither does Linux have a sbrk syscall :) But glibc malloc indeed uses both brk and mmap. The FreeBSD malloc guarantees that the pages are zeroed before being obtained from the system; this is probably the majority of the cost. It is a security measure, so that you do not leak data from one process to another through anonymous pages. The Linux malloc does not. glibc malloc doesn not guarantee you zeroed memory if you reuse memory that was freed in your process. Otherwise it's of course zeroed. once on allocation, once again on checking of the reference, after). The FreeBSD malloc references an environment variable and a readlink() of a potentially non-existant symbolic link containing configuration data for the malloc. The Linux malloc does not have this overhead. glibc malloc reads a bunch of enviroment variables, though to allow stuff like memleak debuging and such The FreeBSD malloc would be lower performance than the Linux malloc, if you allocate space in teeny, tiny chunks; it has much higher performance for large allocations. Good programmers allocate their resources up front, once, instead of doing the allocations in time critical internal loops. It's certainly debatable wehther the whole point of a userlevel memory allocator like malloc() isn't avoiding the reimlementation of a better allocator in each an every program :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PThreads problem
Bruce M Simpson wrote: On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote: It is more correct to say that libcurl makes an assumption about signal delivery which is not guaranteed by POSIX, and therefore libcurl will not work with *any* POSIX compliant threads implementation which does not *happen* to work this way. Would a more correct approach, when dealing with POSIX threads and signals, be to make sure signals are delivered to a single thread *expressly for that purpose*, and then use POSIX thread primitives (such as mutexes and condvars) to communicate the signal conditions to the other threads? There is very little in the way of signals which are guaranteed to work, when you are using threads. The best approach is to not use signals and threads together. If you have to use signals for something (in this case, you are building a simple timer mechanism using alarm/SIGALRM), then it is best to trap the signal to a handler, and have the hander do no work whatsoever, other than (1) noting the signal occurred in a volatile marker, and, possibly, (2) triggering a worker thread to act on the signal having occurred, and do the processing which you normally would have done in the signal handler in that thread, instead. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
--On mardi 22 octobre 2002 10:08 +0100 Ceri Davies [EMAIL PROTECTED] wrote: On Tue, Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. snapshots.jp.freebsd.org hasn't completed a make release since September 17th by the looks of things. I was willing to install a fresh -current, I'm trying to make release from a -stable box, but I don't believe it will end well. Could someone make release from a recent -current so that many of us could install it ? -- Mathieu Arnold To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
On Tue, Oct 22, 2002 at 01:52:34PM -0500, Stephen Montgomery-Smith wrote: Brooks Davis wrote: The user may also see a performance gain on Linux if they use a less stupid allocation scheme. I ran into some code once that read strings one character at a time via getc() and did a realloc for each read. Needless to say, performance was truly awful since a typical run required parsing over 600MB of text. I saw a better then 50% speedup on Alpha Linux when I fixed that mess. As an amateur programmer, I wrote a program something like this. But it allocates memory 1000 bytes at a time in order to save some of this overhead. I would be interested in getting feedback about this little function I wrote as to whether it could be greatly improved. (It works great for me, but probably I haven't really pushed it very hard.) If it performs well enough for your application, there's nothing wrong with it. If you want to speed it up, I'd suggest using the profiler (gprof) to see where you are spending the most time. What makes sense, depends on the layout of the file and how you want to process it. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg37540/pgp0.pgp Description: PGP signature
Re: Kernel Panic Problems
John Baldwin wrote: Panic #1: --- Is this a full backtrace? I don't see any way that the stack could have started with trap_pfault... it had to be running something to cause a page fault. It's a fault from userland perhaps. Panic #3 was a fault in userland, and it showed the process in the stack backtrace. This one also isn't, because the 'usermode' argument to trap_pfault is 0. Panic #2: --- #9 0xc02607aa in generic_bcopy () #10 0xc0247c30 in scstart (tp=0xc0879b00) at ../../dev/syscons/syscons.c:1285 [ ... ] generic_bcopy() is an asm function which may not have a full frame. Thus, when gdb walks back over the stacktrace, it may skip the frame that called generic_bcopy() and go to the previous frame. ddb sometimes does a better job with backtraces for some reason. This is a good point. He should take a backtrace from ddb, at the time of the panic. There is still the little problem of the line numbers not matching the FreeBSD source code. If he can't provide at least a CVS timestamp to use to check out a source tree identical to his, I'm feeling pretty strongly that he's running with local modifications that he's not telling us about, and that these modifications are likely the source of his problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ati Rage 128: Dpms suspend failes
On Oct 22 at 13:08, Andrew Gallatin spoke: Lucky you! What does pciconf -lv say about your card? none0@pci1:0:0: class=0x03 card=0x7106174b chip=0x54461002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage 128 Pro AGP 4x' class= display subclass = VGA -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
On Tue, Oct 22, 2002 at 12:01:19PM -0700, Terry Lambert wrote: Tony Finch wrote: Terry Lambert [EMAIL PROTECTED] wrote: The FreeBSD malloc guarantees that the pages are zeroed before being obtained from the system; this is probably the majority of the cost. It is a security measure, so that you do not leak data from one process to another through anonymous pages. The Linux malloc does not. Utter bollocks. FreeBSD malloc can be configured to re-initialize memory on every allocation, but this is designed to assist with buggy programs, it is *not* a security measure. Memory obtained from the kernel on *all* unices (including Linux) is zeroed; that is when security matters, not in malloc. This will not affect the relative performance of phk and gnu malloc. *before being obtained from the system*. Linux does that too, and you appeared to be saying that it doesn't which is clearly wrong for the security reasons that you stated. It therefore won't affect the relative performance. And I didn't say that. I only said that the pages were zeroed *before being obtained from the system*. This is what you would expect, with anonymous memory accessed off /dev/zero. PHK malloc uses MAP_ANON on FreeBSD, not /dev/zero -- it uses the latter only if compiled for Solaris. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FAIR ISLE: NORTHEAST BACKING NORTH 5 TO 7 INCREASING 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 IN EAST. RAIN. MODERATE OR POOR. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Dan Nelson wrote: The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero. The Linux malloc uses pages added to the process address space via a call to sbrk. Actually, on FreeBSD only the page directory is mmap'ed. Data returned to the user is allocated via sbrk. Please see: /usr/src/lib/libc/stdlib/malloc.c The only calls to sbrk have a 0 argument. This is only used to find the segment end, so that the mmap's do not occur over top of anything important. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Brooks Davis wrote: On Tue, Oct 22, 2002 at 01:20:42AM -0700, Terry Lambert wrote: The FreeBSD malloc would be lower performance than the Linux malloc, if you allocate space in teeny, tiny chunks; it has much higher performance for large allocations. Good programmers allocate their resources up front, once, instead of doing the allocations in time critical internal loops. The user may also see a performance gain on Linux if they use a less stupid allocation scheme. I ran into some code once that read strings one character at a time via getc() and did a realloc for each read. Needless to say, performance was truly awful since a typical run required parsing over 600MB of text. I saw a better then 50% speedup on Alpha Linux when I fixed that mess. This goes without saying. It's the difference between programmers and software engineers. Nevertheless, there will continue to be a performance differential between FreeBSD and Linux. I personally don't think it's a problem; optimizing that area is optimizing noise. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Tony Finch wrote: The FreeBSD malloc guarantees that the pages are zeroed before being obtained from the system; this is probably the majority of the cost. It is a security measure, so that you do not leak data from one process to another through anonymous pages. The Linux malloc does not. [ ... ] *before being obtained from the system*. Linux does that too, and you appeared to be saying that it doesn't which is clearly wrong for the security reasons that you stated. It therefore won't affect the relative performance. Yes, it will. It has to do with the use of anonymous memory being different between the systems. You are arguing that there is nothing that can account for the performance difference, when in fact there is a measured performance difference. And I didn't say that. I only said that the pages were zeroed *before being obtained from the system*. This is what you would expect, with anonymous memory accessed off /dev/zero. PHK malloc uses MAP_ANON on FreeBSD, not /dev/zero -- it uses the latter only if compiled for Solaris. And tell me, what does the Linux malloc use? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: [...] And I want them to do it RSN: 5.0-R is only 9 days away. [...] 9 days??? There won't be another DP? A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
If memory serves me right, The Anarcat wrote: On Tue Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: [...] And I want them to do it RSN: 5.0-R is only 9 days away. [...] 9 days??? There won't be another DP? Um, not exactly. The current release date isn't until 20 November (subject to change, but that's the official word until RE says otherwise). That being said, the more testing we can get with sysinstall and fresh installations, the better. Urk. We really need to update some of the dates on the 5.0 release schedule. I'll push this during the RE telecon this week, if we don't get to it sooner. Bruce. PS. We're still trying to do DP2. Any other snapshots we release after DP2 are more likely to be release-candidate-style snapshots. msg37548/pgp0.pgp Description: PGP signature
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 01:07:50PM -0700, Bruce A. Mah wrote: If memory serves me right, The Anarcat wrote: On Tue Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: And I want them to do it RSN: 5.0-R is only 9 days away. 9 days??? There won't be another DP? Um, not exactly. The current release date isn't until 20 November (subject to change, but that's the official word until RE says otherwise). That being said, the more testing we can get with sysinstall and fresh installations, the better. Urk. We really need to update some of the dates on the 5.0 release schedule. I'll push this during the RE telecon this week, if we don't get to it sooner. I've noticed many commits on cvs-all include an Approved by: re line, but I haven't seen an official code slush/freeze announcement. Is RE going to request a code freeze around 10 Nov.? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Dan Nelson wrote: The only calls to sbrk have a 0 argument. This is only used to find the segment end, so that the mmap's do not occur over top of anything important. Ah, but take a look at the calls to brk, especially in map_pages() and free_pages(). How the anonymous pages (which I have already made reference to) are explcitly obtained is irrelevent to the current discussion. If you want me to be exact in terms of implementation details, on both Linux and FreeBSD, I can do so. That isn't the real purpose of the current discussion. The real purpose of this discussion is to defend the choice of FreeBSD, rather than Linux, to users who are strong advocates of Linux. Any answers that don't provide *only* general details on the differences between the systems which lead to the differences in performance behaviour aren't really useful... in fact, they are counter-productive. Yes, this is really nothing more than a Linux shortage discussion, where someone has written some bogus code to demonstrate how terrible the world is, without Linux everywhere. ... I have a bad idea insert Bad Idea Dance here. Why don't you explain how malloc works in excruciating implementation detail, instead of why his program is failing on FreeBSD and not on Linux, so that he gets no real useful comparative information out of the resulting discussion, and everyone reading the archives thinks we bury valid Linux vs. FreeBSD questions in technobabble, thus affirming the validity of the original complaint to any third parties who are later referred to the thread as an example of Why FreeBSD sucks. Then he can throw up his hands in surrender, because no one is willing to speak in the abstract, instead of in terms of implementation details, and switch over to Linux, as his users are demanding he do, since they appear to spend their entire lives looking for degenerate cases that they can use to advocate the the use of Linux in place of whatever other software their administration happens to be using, because they are NOT in fact users being prevented from doing their jobs, they are Linux advocates *pretending* to be users being prevented from doing their jobs by a severe lack of Linux, God's One True Blessed OS. ... Yes, technically, this discussion should be taking place on -advocacy, but that's not where the question was asked, and it's not where the discussion will be read, and it's not where the results will be archived. And it's not the archive that will be referred to by future advocates who want to make FreeBSD look bad. Moving it will only serve the purpose of placing a question about FreeBSD for which there is apparently no good answer, for lack of an answer in the archives of the forum (-hackers) in which the question was asked. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ctwm port and XFree86 4.2 port incompatible?
Nothing I have tried has been successful in getting the ctwm window manager to run successfully with the newest X ports. It can't find any fonts. twm seems to work fine. All my old configs failed when I upgraded to teh new XFree86 ports. Anyone able to get it going? julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
If memory serves me right, Steve Kargl wrote: I've noticed many commits on cvs-all include an Approved by: re line, but I haven't seen an official code slush/freeze announcement. Feature freeze started 16 October. New feature commits (as opposed to bugfix or doc commits) should have RE approval. Is RE going to request a code freeze around 10 Nov.? Clearly we're not adhering to the last published code-freeze date; according to that, we would have been in code-freeze for two days already. The more src-oriented members of RE are probably in a better position than I am to say when code-freeze is going to start. Bruce. msg37552/pgp0.pgp Description: PGP signature
Re: ctwm port and XFree86 4.2 port incompatible?
Julian Elischer wrote: Nothing I have tried has been successful in getting the ctwm window manager to run successfully with the newest X ports. It can't find any fonts. twm seems to work fine. All my old configs failed when I upgraded to teh new XFree86 ports. Anyone able to get it going? I think you meant to post this to -current... Weren't the Type 1 fonts removed from indices in order to get X to quit core dumping all over the place? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Is sysinstall still supposed to copy the contents of the mfsroot- image to /stand ? This at least results in two copies of sysinstall, one in /stand and the other one in /usr/sbin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
On Tue, Oct 22, 2002 at 12:48:03PM -0700, Terry Lambert wrote: Tony Finch wrote: Linux [clears memory in the kernel before handing it over to userland], and you appeared to be saying that it doesn't which is clearly wrong for the security reasons that you stated. It therefore won't affect the relative performance. Yes, it will. It has to do with the use of anonymous memory being different between the systems. The only significant difference I can see is that large callocs are mmapped by gnu malloc which doesn't then re-clear them, whereas phk malloc only mmaps its page table (not memory returned to the user) so calloc always clears memory, which happens to be redundant if the pages have just come from brk (which isn't always the case). However calloc isn't relevant to this benchmark. [If you are talking about a different difference, perhaps you should say what it is so that this thread doesn't get even more unnecessarily long.] You are arguing that there is nothing that can account for the performance difference, when in fact there is a measured performance difference. No, I'm saying that some of what you said is either wrong or misleading, and the comment about security was especially stupid. PHK malloc uses MAP_ANON on FreeBSD, not /dev/zero -- it uses the latter only if compiled for Solaris. And tell me, what does the Linux malloc use? Exactly the same, and it uses MAP_ANONYMOUS on Linux. It uses mmap for large allocations whereas phk malloc does not. Since both mmap and sbrk get zero-filled pages from the kernel this shoudld make little difference, except in the calloc case explained above. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FORTIES CROMARTY: EAST BECOMING CYCLONIC 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 LATER. RAIN. MODERATE OR POOR. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
In message [EMAIL PROTECTED], [EMAIL PROTECTED] .de writes: Is sysinstall still supposed to copy the contents of the mfsroot- image to /stand ? This at least results in two copies of sysinstall, one in /stand and the other one in /usr/sbin. That is intentional -- 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: 5.0-RUSH: -current install testers wanted!
For what it's worth; I'm also using a dual-Athlon that gets spontaneous reboots once in a while and seems like it could possibly have to do with ACPI activating while the system is trying to cool itself down. Do you have any more hints here on where the problem may lie so I can attempt to track it down? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 10:39:32PM +0200, Poul-Henning Kamp wrote: That is intentional Is it ok then that the sysinstall in /stand of the 0917-JPSNAP immediately dumps core with signal 10 when run on a 1017 -current ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Tony Finch wrote: You are arguing that there is nothing that can account for the performance difference, when in fact there is a measured performance difference. No, I'm saying that some of what you said is either wrong or misleading, and the comment about security was especially stupid. Yes, it was misleading, in that I didn't provide full implementation details, so a naieve reader looking to reimplement malloc() as it was implemented on FreeBSD, would get it wrong. The security comment had to do with the fact that zeroing occurs in the kernel in the idle loop, and can account for a large latency in the case of a big demand in user space. It's a philosophy issue that led to the implementation, and it has a performance impact that's higher in FreeBSD than in Linux, under some usage patterns. I don't think it's necessary to discuss the implementation details to the level of documenting them for people wanting to reimplement the code. The context of the current discussion is a FreeBSD admin with Linux users bitching at him about core dumps in an overcommit case, where he's hitting an administrative limit, and then trying to dereference a pointer to a page that has an established mapping, but for which there is no page available to act as backing store. Saying this, though, really doesn't help, when you have a user that's pretending to not understand your explanations, and wants an explanation in layman's terms, which is what the original poster is facing. If it weren't for the fact that we were dealing with a programmer that was pretending to be dumb enough to put allocations into an interior loop in order to give FreeBSD a bad performance number relative to Linux, this wouldn't have ever been an issue in the first place: for the perfectly correct, we would just refer the person to the malloc() source code. Instead, we have to deal with a fictional microbenchmark, and discuss why decisions were made. There's perfectly correct, and then there's speaking to the level of your audience. PHK malloc uses MAP_ANON on FreeBSD, not /dev/zero -- it uses the latter only if compiled for Solaris. And tell me, what does the Linux malloc use? Exactly the same, and it uses MAP_ANONYMOUS on Linux. It uses mmap for large allocations whereas phk malloc does not. Since both mmap and sbrk get zero-filled pages from the kernel this shoudld make little difference, except in the calloc case explained above. The allocations in this case are lots of very small allocations; it makes no real difference, unless there is a preallocation of space by the malloc() subsystem in order to refill a free pool, to deal with expected future malloc() requests. FreeBSD's overallocation pool size is one 4K page, which is relatively small for modern systems with 4G of memory. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
In message [EMAIL PROTECTED], [EMAIL PROTECTED] .de writes: On Tue, Oct 22, 2002 at 10:39:32PM +0200, Poul-Henning Kamp wrote: That is intentional Is it ok then that the sysinstall in /stand of the 0917-JPSNAP immediately dumps core with signal 10 when run on a 1017 -current ? Current developments considered: that's probably to be expected. -- 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: 5.0-RUSH: -current install testers wanted!
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], [EMAIL PROTECTED] .de writes: Is sysinstall still supposed to copy the contents of the mfsroot- image to /stand ? This at least results in two copies of sysinstall, one in /stand and the other one in /usr/sbin. That is intentional Yes. It would be a good idea to make the sysinstall available as a binary image on the CDROM, as well, to permit it to be used for network mounted upgrades of things like lots of CDROM-less boxes in racks, too, which would make it 3 places. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 04:40:12PM -0400, Brian F. Feldman wrote: For what it's worth; I'm also using a dual-Athlon that gets spontaneous reboots once in a while and seems like it could possibly have to do with ACPI activating while the system is trying to cool itself down. Do you have any more hints here on where the problem may lie so I can attempt to track it down? Nope, sorry, just happens... Thinking a bit about it I think so far they only happened when the box was fairly idle so maybe it occures when ACPI is trying to throttle down the system. Like I wrote I disabled ACPI for now as it seems to cause the frequent locking-related panics I saw. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] On Tue, Oct 22, 2002 at 10:39:32PM +0200, Poul-Henning Kamp wrote: That is intentional Is it ok then that the sysinstall in /stand of the 0917-JPSNAP immediately dumps core with signal 10 when run on a 1017 -current ? You're really supposed to run /usr/sbin/sysinstall. This breaks my finger memory, but is the new world order. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel Panic Problems
Panic #2: --- #9 0xc02607aa in generic_bcopy () #10 0xc0247c30 in scstart (tp=0xc0879b00) at ../../dev/syscons/syscons.c:1285 [ ... ] generic_bcopy() is an asm function which may not have a full frame. Thus, when gdb walks back over the stacktrace, it may skip the frame that called generic_bcopy() and go to the previous frame. ddb sometimes does a better job with backtraces for some reason. This is a good point. He should take a backtrace from ddb, at the time of the panic. There is still the little problem of the line numbers not matching the FreeBSD source code. If he can't provide at least a CVS timestamp to use to check out a source tree identical to his, I'm feeling pretty strongly that he's running with local modifications that he's not telling us about, and that these modifications are likely the source of his problem. -- Terry No Terry there are no modifications from me to local files. I realy don't know why the information is incomplete but I didn't make any modifications. Its possible that a memory problem cause this errors? Again, last night the computer stop running 3 times without an apparent cause. This afternoon the first time a turnned on the computer it panics again with a fatal trap 12. I'll try to change this memory just to eliminate the possibility of hardware problem then if it continues i'll do a hard study on gdb and try to find some info. Could you provide some good source of information to gdb? Thanks Diego To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel Panic Problems
Diego Wentz Antunes wrote: No Terry there are no modifications from me to local files. I realy don't know why the information is incomplete but I didn't make any modifications. The incompleteness is because you didn't do a backtrace in ddb at the time of the crash, and only did it in gdb on the system dump image; as John explained, gdb sometimes messes up stack frames for assembly functions, and leaves information out. The reason I suggested that there would be modifications is totally different. The reason is that the line numbers of the source files for the backtrace do not match the correct function names in 4.4, 4.6, and -current source code. This doesn't necessarily mean your code has local modifications. But it does mean that you aren't giving us enough information to be able to properly anayze the backtrace, because you haven't given us enough information so that the source code we can look at is the same as your source code. We don't know if you are running a -RELEASE version, and, if you are, *which* version you are running. You never told us. Its possible that a memory problem cause this errors? It's possible, but unlikely, if the errors didn't happen before, and they are happening now. Have you had a lightning storm, are you overclocking, or has an atomic weapon gone off nearby? 8-). If the answer is no, then the MTBF for solid state devices that have survived burn-in is pretty much longer than man has been on the planet. Again, last night the computer stop running 3 times without an apparent cause. This afternoon the first time a turnned on the computer it panics again with a fatal trap 12. I'll try to change this memory just to eliminate the possibility of hardware problem then if it continues i'll do a hard study on gdb and try to find some info. Could you provide some good source of information to gdb? There's an O'Reilly book; most gdb references aren't very useful (IMO). In practice, it's better to know how the problem *could* happen, then to try to back track from when it *did* happen. This means that the most important thing you can do is get the problem to be repeatable. It would also help if you were to look at the source code where the problem starts happening; without your source code, we can only give you an educated guess as to the problem, based on what we think the source code should be. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Terry Lambert [EMAIL PROTECTED] wrote: The security comment had to do with the fact that zeroing occurs in the kernel in the idle loop, and can account for a large latency in the case of a big demand in user space. It's a philosophy issue that led to the implementation, and it has a performance impact that's higher in FreeBSD than in Linux, under some usage patterns. You said that Linux doesn't guarantee to zero pages handed from the system to userland, which is wrong. You've also mentioned the in- kernel page-zeroing strategy which is irrelevant when comparing different userland malloc implementations on the same OS. Hand-waving about the peanut gallery when I am trying to get you to be more specific about your vague assertions is not helpful. The context of the current discussion is a FreeBSD admin with Linux users bitching at him about core dumps in an overcommit case, where he's hitting an administrative limit, and then trying to dereference a pointer to a page that has an established mapping, but for which there is no page available to act as backing store. I'm slightly perplexed about this: his program shouldn't have dumped core when hitting an administrative limit because it was correctly checking the return value from malloc(), and he's unlikely to be in an overcommit situation on a machine with 4GB of RAM when allocating only 800MB especially when it works with the administrative limit removed. Perhaps the core came from a different version of the program what didn't check for errors properly. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: NORTHWEST BACKING WEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. SQUALLY SHOWERS. GOOD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Wow, spooky, I used to live at: 8716 W 70th Terr Shawnee Mission, KS 66204 Of course, that was back in the early 70's ;). Anyway, I might be able to get you a copy if you want 1. I have a spare 5.0-DP somewhere at one of my customers in Lenexa, or I could make a newer version. Unfortunately, I cannot get to my broadband connection until Thursday because I am staying with my wife at the hospital. If noone else sends you one, I will try to make one for you and mail it then. - brian On Tue, 22 Oct 2002, Juli Mallett wrote: * De: Soeren Schmidt [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] It seems Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. Where do you live ? I'm sure we can find someone with a CD burner near you willing to make a copy and snailmail it to you... (Consider this a beg for anyone close enough for it to be cost effective to send me a 5.0-CURRENT snapshot CD, on which I can somehow disable the atkbdc/atkbd stuff at bootup, or which has them out of the kernel...) Juli Mallett 11145 W 76th Terrace Shawnee, KS 66214 United States Thanks for the idea :) juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message +---+--+ He rides a cycle of mighty days, and \ Wm Brian and Lori McCane represents the last great schizm among\ McCane Consulting the gods. Evil though he obviously is, \ [EMAIL PROTECTED] he is a mighty figure, this father of \ http://freenews.maxbaud.net/ my spirit, and I respect him as the sons \ http://www.sellit-here.com/ of old did the fathers of their bodies. \ http://recall.maxbaud.net/ Roger Zelazny - Lord of Light\ http://www.mccons.net/ +---+--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: Wm Brian McCane [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] Wow, spooky, I used to live at: 8716 W 70th Terr Shawnee Mission, KS 66204 Of course, that was back in the early 70's ;). Anyway, I might be able to get you a copy if you want 1. I have a spare 5.0-DP somewhere at one of my customers in Lenexa, or I could make a newer version. Unfortunately, I cannot get to my broadband connection until Thursday because I am staying with my wife at the hospital. If noone else sends you one, I will try to make one for you and mail it then. Someone's already offered to burn me one (petef@) CD of any ISO, so I'm working to get a 'make release' done locally with the appropriate conf options. Thanks much though, any BSD Users Groups in this area? :) juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Well, I'll send it to you or anyone else if you can provide me with the link of what you want. Only thing I ask is that an official Mesa 4.0.4 FSBD port makes it into the 5.0 release as well as the next 4.x release. ;o) All I ask! -K _ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
Tony Finch wrote: You said that Linux doesn't guarantee to zero pages handed from the system to userland, which is wrong. You've also mentioned the in- kernel page-zeroing strategy which is irrelevant when comparing different userland malloc implementations on the same OS. No. I said: | The FreeBSD malloc guarantees that the pages are zeroed before being | obtained from the system; this is probably the majority of the cost. | It is a security measure, so that you do not leak data from one process | to another through anonymous pages. | | The Linux malloc does not. It has to do with *when the pages are zeroed... *before* being obtained from the system or *at the time they are obtained from the system*. Hand-waving about the peanut gallery when I am trying to get you to be more specific about your vague assertions is not helpful. Specificity is counterproductive in the current context. The person was not asking how does FreeBSD malloc work?. He was asking about relative performance of FreeBSD and Linux. See the original post: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=73677+0+current/freebsd-hackers ...it was Yet Another Bogus MicroBenchmark. The context of the current discussion is a FreeBSD admin with Linux users bitching at him about core dumps in an overcommit case, where he's hitting an administrative limit, and then trying to dereference a pointer to a page that has an established mapping, but for which there is no page available to act as backing store. I'm slightly perplexed about this: his program shouldn't have dumped core when hitting an administrative limit because it was correctly checking the return value from malloc(), and he's unlikely to be in an overcommit situation on a machine with 4GB of RAM when allocating only 800MB especially when it works with the administrative limit removed. Perhaps the core came from a different version of the program what didn't check for errors properly. The alloc succeeded because there was page mapping space available. The pages to back the pages in that space were not allocated until they were referenced. The core dump may have occurred as a result of any demand for memory at all (including a copy on write of a dirty data page or a stack grow). Running the bad program from the original posting on my local machine, however, indicates, that it happened when there was an attempt to dereference it in the compare in the second for. On a system with different limits, where the limits were enforced, the mapping could be established, with no room left over to obtain backing pages for the region mapped. If this happened, then it would occur in the array pointer dereference for the first element on a new page boundary in the initial for loop. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
In the last episode (Oct 22), Terry Lambert said: Danny Braniss wrote: If you want GNU malloc behaviour, then you should install the port for the GNU allocator, and use it instead of the system allocator, and you will end up with the same behaviour that your application has on Linux. what ticked my curiosity was that the linux binary did work, while the fbsd binary did the right thing with respect to the admin limits and coredumped when the datasize limit was exeeded. The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero. The Linux malloc uses pages added to the process address space via a call to sbrk. Actually, on FreeBSD only the page directory is mmap'ed. Data returned to the user is allocated via sbrk. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: malloc
In the last episode (Oct 22), Terry Lambert said: Dan Nelson wrote: The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero. The Linux malloc uses pages added to the process address space via a call to sbrk. Actually, on FreeBSD only the page directory is mmap'ed. Data returned to the user is allocated via sbrk. Please see: /usr/src/lib/libc/stdlib/malloc.c The only calls to sbrk have a 0 argument. This is only used to find the segment end, so that the mmap's do not occur over top of anything important. Ah, but take a look at the calls to brk, especially in map_pages() and free_pages(). -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
