Re: have live system with NFS client cache problems what do i do?
? Alfred Perlstein wrote: > On Mon, 12 Apr 1999, Maxim Sobolev wrote: > > > Alfred Perlstein wrote: > > > > > Hey, i was just doing a kernel compile over NFS and i have a weird > > > situtation.? After compiling everything the linker barfs on linking. > > > > > > gensetdefs: cd9660_bmap.o: not an ELF file > > > > > > for about 12 files... > > > > > > the compile is being done on a laptop that has my desktop's src dir > > > NFS mounted. > > > > > Hey I have pretty the same problems on my 4.0 cvsup'ed and builded few > > days ago! > > > > As NFS server I have 3.1-stable box. > ? > Let's try to figure out some other commonalities to assist debugging this. > can you please fill this in: > ? ?? Me? You Server version 4.0-apr6th? 3.1- apr6th ?Netcard?? pn0?? ed0 (Realtek 8029) ?local disk??? da? wd0 ?options?? softupdates??? noatime ?nfsd? yes yes ?ram?? 32meg??? 24meg Client version 4.0-apr9th?? 4.0- apr6th ?Netcard?? ep0 3comIII pcmcia?? ed0 (AR-P500 pcmcia) ?local disk??? wd?? ad0 ?options?? softupdates?? noatime ?nfsiod??? don't think so??? don't think so ?ram?? 48meg??? 32meg > ? > Mount type:??? mount server:/usr/src > ??? /usr/src > > how bug??? build kernel in > happened:? NFS mounted /usr/src > ?? make depend && make -j6 all > > bug:?? client sees files are filled > ?? with zeros, but server has > ?? non-corrupted files > > ?? will not link on client > ?? links fine on server > ?? if the files are copied from > ?? the NFS mount to local disk > ?? they "un-corrupt" themselves. > > well?? I'm tempted to blame the 3com, but that doesn't make sense > as when you copy to local disk the files seem to become normal again... > ? Mount type:??? mount -o noatime server:/usr/src ? mount -o noatime server:/usr/ports how bug??? build ports and kernel happened:? NFS mounted /usr/ports cd /usr/ports/textproc/docproj make all install NFS mounted /usr/src make depend && make -j4 bug:?? client sees files are filled with zeros, but server has non-corrupted files will not link on client ?? links fine on server ?? if the files are copied from ?? the NFS mount to local disk ?? they "un-corrupt" themselves. ?? very good chance to link correctly is to try run make on client once more (cache flushes??) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: sys/pci pci.c
On Mon, 12 Apr 1999, Alfred Perlstein wrote: > On Mon, 12 Apr 1999, Doug Rabson wrote: > > > On Mon, 12 Apr 1999, Alfred Perlstein wrote: > > > > > The problem that i faced was that the console stuff must be done even > > > before the SYSINITs are done it's generally setup from machdep.c this > > > is before a lot of stuff is really setup. > > > > > > How early can i expect this framework to be in place so i can attach > > > a console bus/device or does it seem i have to hack this somehow? > > > > > > What i'm planning on is a way to modularize the console code enough > > > so that during runtime the console can be moved from device to device > > > and even support a forked console (i/o on both sio and sc) revoking > > > a console and a split console (input serial, output syscons). > > > > That sounds very worthwhile. While you are at it, can you try to factor > > out the common code from the i386 and alpha ports so that both can use the > > new mechanism. > > I will try to, something i also wonder, why is there seperate sio.c > for each port? it seems like a lot of the isa stuff is duplicated > across each port making it hard to actually do this correctly. > > hopefull the new stuff going into the bus code will help this, i know > drowning the code in #ifdef __alpha__/__i386__/etc is pretty nasty > but trying to keep 3 sio.c and i presume more if the other arch ports > in the works have the same isa device as even more difficult. The one in sys/isa is the new-bus style one. It has diverged slightly from the i386 one but I intend to fix that. If/when the i386 new-bus implementation goes into current, there will be only one version of sio.c. > > the seperate i386/cons.c and such will be put into an arch independant > form and i will impelement a spec to follow to be a console device. > > I will bring sio and syscons on i386 into this model and i hope developers > with pc98 and alpha equip can move to it as well. Sounds good to me. I'm sure I can spend some time on adapting the alpha to the new model when it appears. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
newconfig/new-bus
ftp://ftp.nop.or.jp/users/uch/PCMCIA/FreeBSD/sys4c990410-newconfig990413.patch.gz This is newest newconfig patch against to 4.0-CURRENT(990410). FreeBSD/newconfig provides NetBSD compatible frame work ,bus_space(9) (bus_memio.h,bus_pio.h are no longer required.) and `bus name`_intr_establish. and also provides resource management. This feature makes easy to implement and feedback drivers among *BSD. As a sample, dev/pcmcia/ directory was imported from NetBSD. The amounts of #ifdef __FreeBSD__ is little. I'm working CardBus (dev/cardbus/) driver with NetBSD people. (originary written for NetBSD) Newconfig may not to be seem exciting, but this is powerful and flexible implementation in fact. please see this patch. Following table is guide map for comparison. newconfig new-bus framework: kern/subr_autoconf.c kern/subr_bus.c sys/device.h sys/bus.h resource management: kern/subr_rman.c kern/subr_rman.c i386/i386/resource.c i386/i386/nexus.c mainbus: i386/i386/mainbus.ci386/i386/nexus.c ISA bus: i386/isa/isa_machdep.c i386/i386/nisa.c PCI bus: i386/pci/pci_machdep.c pci/pci.c --- UCHIYAMA Yasushi u...@nop.or.jp To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
FreeBSD won't boot
Hi! I have Win95 and FreeBSD 4.0-Current on my system. Today I had to reinstall Win95, which overwrites the master boot record. After that I used fdisk to switch to FreeBSD and used /stand/sysinstall to install the FreeBSD selector boot record (I set the FreeBSD and the Win95 partition to bootable first). Now the boot selector will be displayed, but I cannot run FreeBSD from it anymore. It will just show the boot prompt in the boot loader and won't accept to boot from my SCSI drive, where the FreeBSD and Win95 partition are located (using "0:da(0,a)kernel", which should work). The boot loader just says "Invalid format!". Then I used the Fixit-Floppy and tried to boot FreeBSD from my harddrive, again using "0:da(0,a)kernel", which works perfectly. Am I missing something? Why doesn't the harddrive-installed bootloader accept my kernel, whereas the floppy bootloader does? Thanks for your help! Ciao, Thomas. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
UPDATING need to be updated
It seems that as of today (13 Apr) make -j N world works fine. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD won't boot
Thomas Schuerger wrote: > > I have Win95 and FreeBSD 4.0-Current on my system. What version of FreeBSD you originally had in your system? > Today I had to reinstall Win95, which overwrites the master boot record. > After that I used fdisk to switch to FreeBSD and used /stand/sysinstall > to install the FreeBSD selector boot record (I set the FreeBSD and the > Win95 partition to bootable first). This /stand/sysinstall is the one on the hard drive, correct? I assume you never, ever, did cd /usr/src/release/sysinstall; make all install, correct? Thus, this sysinstall corresponds to the originally installed FreeBSD version. One needs the latest loader to boot current -current kernels. I don't recall the exact dates for the latest loader, but the specific patch that is needed was committed sometime in march, I think. > Now the boot selector will be displayed, but I cannot run FreeBSD from > it anymore. It will just show the boot prompt in the boot loader and > won't accept to boot from my SCSI drive, where the FreeBSD and Win95 > partition are located (using "0:da(0,a)kernel", which should work). 0:da(0,a)kernel will certainly not work for loader, only boot2. Is loader being loaded at all? If not, you *definitely* don't have a latest version installed. In this case, try "0:da(0,a)/boot/loader". If that proceeds to boot your kernel correctly, do a "disklabel -B da0", and everything will be back to normal. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "nothing better than the ability to perform cunning linguistics" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
Chris Costello wrote: > > > If one can't control one's users, one has no business managing them. > > The > > last thing FreeBSD needs is some overly complex, sophisticated scheduler > > designed to help bozo sysops stay on their feet. > >I agree with you very much here. Public shell systems are a > bad idea. In my opinion, you should trust someone before you > allow them to have an account on your system. What you really mean is that "FreeBSD is not a solution for public shell systems", correct? Public shell systems is not a bad idea, it's a business opportunity and a public service. If the OS is not up to the task, don't blame the task. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "nothing better than the ability to perform cunning linguistics" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
> What you really mean is that "FreeBSD is not a solution for public > shell systems", correct? Public shell systems is not a bad idea, > it's a business opportunity and a public service. If the OS is not > up to the task, don't blame the task. Any Unix OS is going to give you more or less the same out-of-box experience for shell users, the real difference being in the administrators who manage the machine(s). For shell machines especially, the admin simply has to have a reasonably high level of clue or they can count on a world of grief from their own users, and I don't care if the box in question is running Linux, FreeBSD or Solaris. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
On Tue, Apr 13, 1999, Daniel C. Sobral wrote: > What you really mean is that "FreeBSD is not a solution for public > shell systems", correct? Public shell systems is not a bad idea, > it's a business opportunity and a public service. If the OS is not > up to the task, don't blame the task. If you close your eyes and run towards a brick wall with the goal being to destroy it, and instead you injure yourself, it's not your forehead's fault or the wall's fault (no matter how much you cuss out the wall), but the person behind it. If you were strong and determined enough, perhaps you could solve the problem, but your forehead wasn't meant to crash through walls by default, and the brick wall wasn't meant to have a forehead plow through it. Make any sense? The admin shouldn't expect a public shell service to be secure out of the box with anything. BSD/OS, Linux, FreeBSD, NetBSD, OpenBSD - are any of these born shell service OS? I doubt it. It takes a hefty bit of 'tweaking', I'd imagine, to make a system fit to run a public shell. In "theory", no OS I've heard of is a "solution" for shell systems, at least out of the box and with an unexperienced administrator. Does this clear it up? > > -- > Daniel C. Sobral (8-DCS) > d...@newsguy.com > d...@freebsd.org > > "nothing better than the ability to perform cunning linguistics" -- Chris Costello Be careful when a loop exits to the same place from side and bottom. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
:What you really mean is that "FreeBSD is not a solution for public :shell systems", correct? Public shell systems is not a bad idea, :it's a business opportunity and a public service. If the OS is not :up to the task, don't blame the task. : :-- :Daniel C. Sobral (8-DCS) I would note that BEST.COM has been running, effectively, public shell systems for 5 years. The last couple of years have been using FreeBSD. It works just dandy. We put 2000 users on each box. Just because people aren't willing to spend thousands of hours making the kernel handle every conceivable user abuse doesn't make the machine a bad solution for a particular problem. With that sort of attitude, no operating system ever made could live up to your standards. FreeBSD does the things most easily handled in a kernel. You, the sysop, are supposed to do the things that are most easily handled by a sysop. That is inclusive of writing monitoring and kill scripts. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
Matthew Dillon wrote: > > I would note that BEST.COM has been running, effectively, public shell > systems for 5 years. The last couple of years have been using FreeBSD. > It works just dandy. We put 2000 users on each box. > > Just because people aren't willing to spend thousands of hours making > the kernel handle every conceivable user abuse doesn't make the machine > a bad solution for a particular problem. With that sort of attitude, > no operating system ever made could live up to your standards. FreeBSD > does the things most easily handled in a kernel. You, the sysop, are > supposed to do the things that are most easily handled by a sysop. That > is inclusive of writing monitoring and kill scripts. Ok, disclaimer in the vain attempt to prevent further replies. I took an issue with blaming public shell accounts for perceived problems with the way FreeBSD manages them. I do think FreeBSD, and Unix, generally speaking, is one of the best deals available. It could be improved, and it does require non-clueless sysadmins. Saying "public shell accounts are a bad idea" is dismissing the real issues, and blaming the messenger for the bad news. What you, Dillon, were saying in the message quoted in the message I originally replied to, is to the point. FreeBSD can handle it, as long as the sysadmin knows what s/he is doing. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "nothing better than the ability to perform cunning linguistics" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
Chris Costello once stated: =On Sat, Apr 10, 1999, Matthew Dillon wrote: => :Sun has a product for this, Solaris Resource Manager. = You don't need to tune user accounts, you need only put the =users in a separate login class (if that hasn't already been =done) and modify the resource limitation for that login =restriction. Speaking of which. Can we have the login class database distributed over NIS? => If one can't control one's users, one has no business managing => them. The last thing FreeBSD needs is some overly complex, => sophisticated scheduler designed to help bozo sysops stay on => their feet. = I agree with you very much here. Public shell systems are a =bad idea. In my opinion, you should trust someone before you =allow them to have an account on your system. Can we, perhaps, have a configurable maximum load level for each class? The users of the class will not be allowed to start new processes if the current load is above that number? -mi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: newconfig/new-bus
Hi: I just wanted to say that I see this as very important work. BSD and Linux interoperability is the best way to insure the BSDs survive (and maybe better) the Linux mania. Rick Whitesel NBase-Xyplex "If it is easy it probably sucks." - Original Message - From: UCHIYAMA Yasushi To: Sent: Tuesday, April 13, 1999 3:58 AM Subject: newconfig/new-bus ftp://ftp.nop.or.jp/users/uch/PCMCIA/FreeBSD/sys4c990410-newconfig990413.pat ch.gz This is newest newconfig patch against to 4.0-CURRENT(990410). FreeBSD/newconfig provides NetBSD compatible frame work ,bus_space(9) (bus_memio.h,bus_pio.h are no longer required.) and `bus name`_intr_establish. and also provides resource management. This feature makes easy to implement and feedback drivers among *BSD. As a sample, dev/pcmcia/ directory was imported from NetBSD. The amounts of #ifdef __FreeBSD__ is little. I'm working CardBus (dev/cardbus/) driver with NetBSD people. (originary written for NetBSD) Newconfig may not to be seem exciting, but this is powerful and flexible implementation in fact. please see this patch. Following table is guide map for comparison. newconfig new-bus framework: kern/subr_autoconf.c kern/subr_bus.c sys/device.h sys/bus.h resource management: kern/subr_rman.c kern/subr_rman.c i386/i386/resource.c i386/i386/nexus.c mainbus: i386/i386/mainbus.ci386/i386/nexus.c ISA bus: i386/isa/isa_machdep.c i386/i386/nisa.c PCI bus: i386/pci/pci_machdep.c pci/pci.c --- UCHIYAMA Yasushi u...@nop.or.jp To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
Just review the thread: >. Look, here is a little script, which allows any user to perform a DoS attack! <. Khmm, yes indeed, but you can remove any user who does this. >. But shouldn't the system be able to sustain/detect this sort of attack? [... Nice theoretical discussion is skipped. ...] <. No, it is your responsibility as a sysop, do not give accounts to those you don't trust. >. Oh, well, but what about public-shell systems? <. Public shell systems are a bad idea! >. Just because FreeBSD can not handle it, does not mean the task itself is a bad idea... <. [Now we are all upset, flames start to light the sky]: . FreeBSD handles this here and here! . No OS will handle it quite right... . You just need to be a better sysop. >. Sorry, no offense meant... Why don't we admit this possibility exists (as well as many others, perhaps) for a local user to cause a DoS and may be someday someone will address it? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
In message <199904131256.iaa08...@kot.ne.mediaone.net>, Mikhail Teterin writes: >Why don't we admit this possibility exists (as well as many others, >perhaps) for a local user to cause a DoS and may be someday someone >will address it? Because we have (counts for a moment, but as he flips to the third page of notes sighs deeply and gives up) more than plenty of things we need to do before that becomes the top priority problem... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Kevin Day wrote: > On the shell servers I run, we've got 200-300 users running tasks. > Occasionally, through intent or misconfiguration, a user either forkbombs, > or gets a large number of processes running sucking lots of cpu. > > I'd like to see an option that makes all the processes run by one uid have > the same weight as one process another uid is running. > > i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid > 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's > 40 processes get 50% cpu shared between them. > > This way, one errant user can't have as significant of an impact. > > Is this plausable? A while ago on -current, I posted a reference to a paper on lottery scheduling in FreeBSD. It allows you to provide scheduling weightings that (on average) share the CPU as described. Do a search of the -current or -hackers archive and it should show up. If not, let me know and I can dig up the reference. I believe it was a section of a CMU Tech Report. I don't know what the source code availability of that is, but it presumably was a month-long project for two grad students or something, so should be quite feasible. However, because processes in kernel mode are non-preemptible, it is impossible to deal with some of the connotations of a hog process. But because these processes are billed for some of the resources they consume in kernel mode (i.e., the CPU spent by their kernel thread), at least that can be taken into account. Matt makes the excellent point in another email that once you have this facility, you need to make sure that your CPU policy actually reflects what you want: do you want some process to displace some other process for "fairness" when fairness impedes throughput in such a way that you might be denying something else service because that something else cannot be represented in the scheduling policy? A combination of priorities and lottery tickets might be the best solution. Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
Poul-Henning Kamp once stated: =>Why don't we admit this possibility exists (as well as many others, =>perhaps) for a local user to cause a DoS and may be someday someone =>will address it? =Because we have (counts for a moment, but as he flips to the third =page of notes sighs deeply and gives up) more than plenty of things =we need to do before that becomes the top priority problem... Ok. So, make this the (n+1)th on the list... Why is somebody saying "FreeBSD can not do this" gets flamed with "other OSes can not either" or "OS is not supposed to do this"? -mi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
In message <199904131325.jaa08...@kot.ne.mediaone.net>, Mikhail Teterin writes: >Poul-Henning Kamp once stated: > >=>Why don't we admit this possibility exists (as well as many others, >=>perhaps) for a local user to cause a DoS and may be someday someone >=>will address it? > >=Because we have (counts for a moment, but as he flips to the third >=page of notes sighs deeply and gives up) more than plenty of things >=we need to do before that becomes the top priority problem... > >Ok. So, make this the (n+1)th on the list... Why is somebody saying >"FreeBSD can not do this" gets flamed with "other OSes can not >either" or "OS is not supposed to do this"? Because people would rather be hacking code than arguing fine points of irrellevant theoretical issues ? Please let this thread die now. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
Matthew D. Fuller wrote: > > As a data point, CVSup runs nicely, but if I iconify it and deiconify it, > it takes about forEVER (maybe 10, 15 seconds on a PPro 180) to redisplay > itself completely. Yes, that's when the problem is most obvious. Here's the bottom line from my point of view. CVSup is slow to update the GUI because it is busy doing more important things, i.e., updating your files as quickly as it can. I agree that it can be annoying. But would you really want me to slow down file updates just so the GUI could look better? John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Bad attitudes (was Re: DoS from local users)
Wow, this is getting deep. Mikhail, give it a break. You _cannot_ prevent a determined attacker from cauing a system a lot of heartache. For every subsystem that you harden, you introduce new weaknesses and more performance hits which can themselves be used as vulnerabilities. I'd bet my reputation on being able to DoS any box you can present to me, given sufficient technical knowledge of the box and what measures you have implemented. Now, PHK, Matt Dillon, Jordan, and all these other fine hackers are hammering out code for this fine OS, and each has their own area of interest and specialty. (I don't mean to leave anyone out BTW). Each is doing their own bit to make the OS better. Sometimes you will be able to get one of them interested in a particularly good idea, sometimes you won't. There have often been things I've wanted to see in FreeBSD, and sometimes you just have to go hammer out the code yourself and submit it. I've done my own bits... anyone who looks at getty or some of the SLIP code will find my fingerprints on them. Sometimes I've talked people into doing useful things... John Dyson, thanks for madvise(), just for example. Is FreeBSD ideal for a public shell system? No. Yet it is a hell of a lot better than Solaris, which many ISP's use. It's a hell of a lot better than SunOS, which _I'VE_ used for a decade to provide public shell access. If you want to run a public shell system, you have to do so with your eyes wide open. You have to be an experienced admin, willing to take some time to make it work right, or you have to be a clueless newbie admin who is willing to live on the box 24/7. Once you establish this, then any help the OS provides merely falls into the "wonderful fantastic safety net" category. Now, if you'd LIKE the OS to provide a wonderful fantastic safety net, then by all means, STFU and go write one. I'm continually amazed at the fantastic improvements being introduced into FreeBSD on a regular basis... ... Joe --- Joe Greco - Systems Administrator jgr...@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ftp hangs on -current
Hello Gianmarco, Thursday, April 08, 1999, 7:49:52 AM, you wrote: GG> "ftp" on 4.0-very-current (post egcs make world) randomly hangs during GG> sessions... GG> I never succeded in finishing a session lately. GG> To transfer some files from my home to my isp server I had to do an "ftp" GG> from the server and a "get" to them... GG> The ftp server works normally and fetch is ok ... GG> Probably it is a fault of my system, if no other experiences it. you're not alone with this problem here - i have the same one. and it seems that it is somehow related to natd, because ftp works quite well when i disable this daemon. any ideas? by the way, i have a question to natd gurus. i have faced with a strange trouble - natd alters _all_ packets passing through the interface (and it is clearly visible when i start natd with -v option) completely ignoring -u option. but i would like to alter packets for unregistered source addresses (192.168.0.0/16) only. what should i do? i run natd with "-u -n ed1" options and firewall rule for natd is: 00100 divert 8668 ip from any to any via ed1 Best regards, Ilyamailto:ca...@avias.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
John Polstra wrote: >Matthew D. Fuller wrote: >> >> As a data point, CVSup runs nicely, but if I iconify it and deiconify it, >> it takes about forEVER (maybe 10, 15 seconds on a PPro 180) to redisplay >> itself completely. > >Yes, that's when the problem is most obvious. > >Here's the bottom line from my point of view. CVSup is slow to update >the GUI because it is busy doing more important things, i.e., updating >your files as quickly as it can. I agree that it can be annoying. >But would you really want me to slow down file updates just so the GUI >could look better? In my view, the non-GUI mode provides excellent feedback (depending on the level of verbosity), so I'd certainly prefer to see the focus remain speed, as opposed to the GUI. I seem to recall that a certain OS, which will remain nameless, used to spend more file-copy time calculating and updating progress bars than actually moving data (all controlled I/O, IIRC). It looked nice, was very responsive and the progress bars were smooth and accurate to the pixel, but it isn't the route I'd choose! (To be fair, this was probably a relic of the floppy-drive days.) Thomas Stephens t...@stephens.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: newconfig/new-bus
On Tue, 13 Apr 1999, Rick Whitesel wrote: > Hi: > I just wanted to say that I see this as very important work. BSD and > Linux interoperability is the best way to insure the BSDs survive (and maybe > better) the Linux mania. I think the work is important too but it won't improve interoperability with Linux driver code... -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
"newbus" CVSup collection
Since some interested parties don't have CVSup access to freefall, I have made the "newbus" collection that Peter announced available on one public mirror site: cvsup2.freebsd.org. Use collection "newbus", release=cvs. Don't forget to specify a dedicated directory for the "prefix". This collection is entirely separate from the others, and you wouldn't want it to be blatted on top of your existing files. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
John Polstra once wrote: > > As a data point, CVSup runs nicely, but if I iconify it and > > deiconify it, it takes about forEVER (maybe 10, 15 seconds on a PPro > > 180) to redisplay itself completely. > Yes, that's when the problem is most obvious. > > Here's the bottom line from my point of view. CVSup is slow to update > the GUI because it is busy doing more important things, i.e., updating > your files as quickly as it can. I agree that it can be annoying. But > would you really want me to slow down file updates just so the GUI > could look better? No-no :-), please, don't... However, the CPU is not 100% busy, and the cvsup is still slow to update sometimes... Updating it does not need anything but the CPU, does it (on the local display)? -mi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: newconfig/new-bus
Hi: I should have been more clear. BSD driver interoperability is a seperate issue from Linux application interoperability but I think both are important. Rick Whitesel Scientist NBase-Xyplex rwhite...@nbase-xyplex.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 - Original Message - From: Doug Rabson To: Rick Whitesel Cc: ; UCHIYAMA Yasushi Sent: Tuesday, April 13, 1999 3:11 PM Subject: Re: newconfig/new-bus On Tue, 13 Apr 1999, Rick Whitesel wrote: > Hi: > I just wanted to say that I see this as very important work. BSD and > Linux interoperability is the best way to insure the BSDs survive (and maybe > better) the Linux mania. I think the work is important too but it won't improve interoperability with Linux driver code... -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
> > Here's the bottom line from my point of view. CVSup is slow to update > > the GUI because it is busy doing more important things, i.e., updating > > your files as quickly as it can. I agree that it can be annoying. But > > would you really want me to slow down file updates just so the GUI > > could look better? > > No-no :-), please, don't... However, the CPU is not 100% busy, and > the cvsup is still slow to update sometimes... Updating it does > not need anything but the CPU, does it (on the local display)? cvsup is mostly based on disk (and network) I/O, so there shouldn't be a problem with properly updating the GUI. Someone said it is done in a separate process, so I still wonder why the GUI is updated so slowly on my PII/450. Ciao, Thomas. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: newconfig/new-bus
> Hi: > I should have been more clear. BSD driver interoperability is a seperate > issue from Linux application interoperability but I think both are > important. For an example of Linux/*BSD driver interoperability and the grief and difficulties therein, you might want to look at the Qlogic SCSI/FibreChannel driver I've done. It exists for FreeBSD,OpenBSD,NetBSD and Linux. It's a dicey business trying to straddle this broad of a set of fences. The take home lesson here is that in order to make a dirver work without overloading a platform specific areas is that the core driver has to be single threaded, not do locking and not do too much porpoising in and out of the platform layers. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: newconfig/new-bus
"Rick Whitesel" wrote: > Hi: > I should have been more clear. BSD driver interoperability is a seperate > issue from Linux application interoperability but I think both are > important. I don't want to get hopes up prematurely, but we think we might be able to emulate enough of the newconfig-style interface via the same sort of wrapper shims that we use for the old isa and pci drivers. If that works out, then it should make porting/using a NetBSD/OpenBSD/BSDI driver a lot easier. There's bound to be #ifdefs required no matter what, but it shouldn't require two totally different config interfaces. Of course, this is still a "might" case since it hasn't been written. However, it would be quite hard to get this to work seamlessly for sub-busses and devices, eg: PCIC->PCCARD->CARDBUS->etc. Simple devices shouldn't be too hard though, but even then there are seriously non-trivial differences in the tty, block/character devices, VM, networking, etc. Even if the config interface was compatable it wouldn't ever be a 'drop in' option, even with 'newconfig'. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: newconfig/new-bus
So I've been lookin gat this patch set.. it seems to duplicate a lot of code already in FreeBSD, by just replacing it with the equivalent code from NetBSD. (or rather, jsut adding the NetBSD code and not using the FreeBSD version. This is acceptable in a test scenario). What is not so clear is what the chances are of us getting something that takes the best features from NetBSD and the best features from the new-bus code. There are similarities, but the differences are less obvious. The framework may be totally different, but how different do the DRIVERS have to be? julian (still reading the new-config stuff) On Tue, 13 Apr 1999, UCHIYAMA Yasushi wrote: > ftp://ftp.nop.or.jp/users/uch/PCMCIA/FreeBSD/sys4c990410-newconfig990413.patch.gz > This is newest newconfig patch against to 4.0-CURRENT(990410). > > FreeBSD/newconfig provides NetBSD compatible frame work ,bus_space(9) > (bus_memio.h,bus_pio.h are no longer required.) and `bus name`_intr_establish. > and also provides resource management. > This feature makes easy to implement and feedback drivers among *BSD. > As a sample, dev/pcmcia/ directory was imported from NetBSD. The > amounts of #ifdef __FreeBSD__ is little. > I'm working CardBus (dev/cardbus/) driver with NetBSD people. > (originary written for NetBSD) > > Newconfig may not to be seem exciting, but this is powerful and > flexible implementation in fact. please see this patch. > > Following table is guide map for comparison. > > newconfig new-bus > framework: > kern/subr_autoconf.c kern/subr_bus.c > sys/device.h sys/bus.h > resource management: > kern/subr_rman.c kern/subr_rman.c > i386/i386/resource.c i386/i386/nexus.c > > mainbus: > i386/i386/mainbus.ci386/i386/nexus.c > ISA bus: > i386/isa/isa_machdep.c i386/i386/nisa.c > PCI bus: > i386/pci/pci_machdep.c pci/pci.c > --- > UCHIYAMA Yasushi > u...@nop.or.jp > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
ATA disks can do command queueing?
Hello ! Recently installed March 12 -current snapshot and compiled kernel with new IDE subsystem. I see interesting lines in dmesg: npx0: INT 16 interface ata0: master: settting up UDMA2 mode on PIIX4 chip OK ad0: ATA-4 disk at ata0 as master ad0: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 0 depth queue, DMA mode ata0: slave: settting up UDMA2 mode on PIIX4 chip OK ad1: ATA-4 disk at ata0 as slave ad1: 6197MB (12692736 sectors), 12592 cyls, 16 heads, 63 S/T, 512 B/S ad1: piomode=4, dmamode=2, udmamode=2 ad1: 16 secs/int, 31 depth queue, DMA mode ata1: master: settting up UDMA2 mode on PIIX4 chip OK ad2: ATA-4 disk at ata1 as master ad2: 6197MB (12692736 sectors), 12592 cyls, 16 heads, 63 S/T, 512 B/S ad2: piomode=4, dmamode=2, udmamode=2 ad2: 16 secs/int, 31 depth queue, DMA mode changing root device to wd0s1a vinum: loaded vinum: reading configuration from /dev/wd2e vinum: updating configuration from /dev/wd1e ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates Does it mean that new ATA disks can queue up commands (something similar to SCSI disks?)? I feel like I heard something in the -current list lately but I'm not sure... -- Vallo Kallaste va...@matti.ee To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: swap-related problems
In message <199904121505.laa70...@misha.cisco.com>, Mikhail Teterin writes: >Matthew Dillon once wrote: > >> If you unset the datasize limit and the program does not exceed >> the maximum system-supported datasize limit, malloc() should not >> return NULL even if the system is out of swap. > >Can you explain why? Our malloc(3) is a little fuzzy as to the >circumstances under which malloc will fail, but on Solaris, it is >more explicit: > > RETURN VALUES > If there is no available memory, malloc(), realloc(), > memalign(), valloc(), and calloc() return a null pointer. > >I consider being out-of-swap as having "no available memory". Wouldn't you? The trouble is, there is no such thing as "no available memory". What we have instead is "not enough memory available for this specific request". For phkmalloc I can say in particular that there is a pool for each size of chunk (16,32,64...2048 bytes and for pages. If you run out of one of these there may still be stuff in the other pools. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATA disks can do command queueing?
It seems Vallo Kallaste wrote: > Hello ! > > Recently installed March 12 -current snapshot and compiled kernel > with new IDE subsystem. I see interesting lines in dmesg: > ad1: 16 secs/int, 31 depth queue, DMA mode > Does it mean that new ATA disks can queue up commands (something > similar to SCSI disks?)? I feel like I heard something in the > -current list lately but I'm not sure... Yep that is exactly what it means, however the driver in -current doesn't take advantage of it yet, but its on my TODO list. The reason why I put in this verbosity, is so I can get a hint to which drives support it, and it seems IBM are on of the few that does. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
Mikhail Teterin wrote: > However, the CPU is not 100% busy, and the cvsup is still slow to > update sometimes... Updating it does not need anything but the CPU, > does it (on the local display)? Correct. I have not tried to analyze where the delays come from. But I do have a guess. CVSup uses user-level threads. If a thread gets blocked waiting for network I/O, the thread scheduler can run a different thread while it is waiting. A subsequent call to select() will inform the scheduler when the I/O can be resumed. But that isn't possible for disk I/O. If you call read() or write() on a disk file, it never returns EAGAIN. It always blocks in the kernel, non-interruptible by signals. When that happens, the process is blocked and it can't run any other threads or do anything else at all until the read/write call has completed. Since CVSup is so disk-intensive, I suspect it is wasting a lot of time blocked in those calls. An interested person could probably confirm or deny that using ktrace. If we had kernel threads and Modula-3 supported them, this wouldn't be a problem. But those are two very big ifs. :-( John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
On Tue, 13 Apr 1999, Thomas Schuerger wrote: > > > Here's the bottom line from my point of view. CVSup is slow to update > > > the GUI because it is busy doing more important things, i.e., updating > > > your files as quickly as it can. I agree that it can be annoying. But > > > would you really want me to slow down file updates just so the GUI > > > could look better? > > > > No-no :-), please, don't... However, the CPU is not 100% busy, and > > the cvsup is still slow to update sometimes... Updating it does > > not need anything but the CPU, does it (on the local display)? > > cvsup is mostly based on disk (and network) I/O, so there shouldn't > be a problem with properly updating the GUI. Someone said it is > done in a separate process, so I still wonder why the GUI is updated > so slowly on my PII/450. My lame assumption is that modula3 uses userland threads that may be io blocking but intrupted with signals or some such if the io is blocked too long. generally i: a) use options -g -L 2 and use 'tee' to dump to a file and review that later, or b) i wait till the run is done before messing with the GUI. oh, and of course subscribe to freebsd-cvs list. :) -Alfred To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
Thomas Schuerger wrote: > cvsup is mostly based on disk (and network) I/O, so there shouldn't > be a problem with properly updating the GUI. Someone said it is > done in a separate process, so I still wonder why the GUI is updated > so slowly on my PII/450. Not a separate process -- a separate thread. It uses user-level threads. If the process blocks in a disk I/O call, all threads stop until the call completes. That's just the way Unix works. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: newconfig/new-bus
| it seems to duplicate a lot of code already in FreeBSD, by just replacing | it with the equivalent code from NetBSD. | | (or rather, jsut adding the NetBSD code and not using the FreeBSD | version. This is acceptable in a test scenario). ep at isa/pcmcia/cardbus ... I fully rewrote code to use newconfig/bus_space(9). (newconfig goal sample) sn ... not in FreeBSD (PAO has this) fe ... Originally same code. ne at pci ... My NetBSD compatiblity test sample. OK to remove. ne at pcmcia ... NetBSD drivers already bus-specific frontend code was separated from bus-independent(backend) code. So easy to adapt another buses. I've tested its separation for FreeBSD's ep code, but it was already done by NetBSD. ed case, I determined to use NetBSD driver.(rewriting was difficult...)But if you love FreeBSD origine, you can replace it. --- UCHIYAMA Yasushi u...@nop.or.jp To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
John Polstra wrote: > Correct. I have not tried to analyze where the delays come from. > But I do have a guess. > > CVSup uses user-level threads. If a thread gets blocked waiting for > network I/O, the thread scheduler can run a different thread while it > is waiting. A subsequent call to select() will inform the scheduler > when the I/O can be resumed. > > But that isn't possible for disk I/O. If you call read() or write() > on a disk file, it never returns EAGAIN. It always blocks in the > kernel, non-interruptible by signals. When that happens, the process > is blocked and it can't run any other threads or do anything else > at all until the read/write call has completed. Since CVSup is so > disk-intensive, I suspect it is wasting a lot of time blocked in those > calls. An interested person could probably confirm or deny that using > ktrace. > Does Modula-3 use libc_r, or does it have it's own user thread support? The recent set of commits to libc_r changed the thread scheduling mechanism to use ITIMER_PROF instead of ITIMER_VIRTUAL. This was to allow for fairer scheduling with I/O bound threads. Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: newconfig/new-bus
On Wed, 14 Apr 1999, UCHIYAMA Yasushi wrote: > NetBSD drivers already bus-specific frontend code was separated from > bus-independent(backend) code. So easy to adapt another buses. > I've tested its separation for FreeBSD's ep code, but it was already > done by NetBSD. ed case, I determined to use NetBSD driver.(rewriting > was difficult...)But if you love FreeBSD origine, you can replace it. No, I was just curious. julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
On Tue, Apr 13, 1999 at 08:29:30AM -0700, a little birdie told me that John Polstra remarked > Matthew D. Fuller wrote: > > > > As a data point, CVSup runs nicely, but if I iconify it and deiconify it, > > it takes about forEVER (maybe 10, 15 seconds on a PPro 180) to redisplay > > itself completely. > > Yes, that's when the problem is most obvious. > > Here's the bottom line from my point of view. CVSup is slow to update > the GUI because it is busy doing more important things, i.e., updating > your files as quickly as it can. I agree that it can be annoying. > But would you really want me to slow down file updates just so the GUI > could look better? Oh god no; by all means, make the file updates faster!! After about 4 days without cvsup'ing (including lots of fun gcc/egcs) updates it took 6:16 to update my CVS repo including: *default release=cvs src-all src-eBones src-secure ports-all www doc-all --- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Matthew Fuller http://www.over-yonder.net/ | * fulle...@futuresouth.com fulle...@over-yonder.net * | UNIX Systems Administrator Specializing in FreeBSD | * FutureSouth Communications ISPHelp ISP Consulting * | "The only reason I'm burning my candle at both ends, | *is because I haven't figured out how to light the* | middle yet" | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATA disks can do command queueing?
On Tue, Apr 13, 1999 at 10:58:45PM +0200, Soren Schmidt wrote: > Yep that is exactly what it means, however the driver in -current > doesn't take advantage of it yet, but its on my TODO list. > The reason why I put in this verbosity, is so I can get a hint to > which drives support it, and it seems IBM are on of the few that > does. Nice. As you say you need hints I can try 14gig 7200rpm IBM also, one is on my table. I think it can behave similarly. -- Vallo Kallaste va...@matti.ee To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
compiler specs for -pthread/-kthread
To facilate auto detection of the local threading environment, it would be nice if the -?thread options set all the necessary compiler/linker flags. It is a common practace for such options to specify both compilation and link options. I suggest the EGCS specs be adjusted to: -pthread => -D_THREAD_SAFE -D_UTHREADS -lc_r -kthread => -D_THREAD_SAFE -D_KTHREADS -lpthread If the LinuxThread "port" is targetted to be -kthread: -kthread => -D_REENRANT -D_LINUXTHREADS -lpthread If the LinuxThread "port" is NOT targetted to be -kthread, I suggest another -?thread option be added and the library specified as -llthread. -?thread => -D_REENTRANT -D_LINUXTHREADS -llthread After modify the specification, the headers/libraries would be adjusted as needed. I can easily submit diffs if desirable. Kurt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ftp hangs on -current
On Tue, 13 Apr 1999 18:34:25 Ilya Naumov wrote: > Hello Gianmarco, > > Thursday, April 08, 1999, 7:49:52 AM, you wrote: > > GG> "ftp" on 4.0-very-current (post egcs make world) randomly hangs during > GG> sessions... > GG> I never succeded in finishing a session lately. > GG> To transfer some files from my home to my isp server I had to do an "ftp" > GG> from the server and a "get" to them... > > GG> The ftp server works normally and fetch is ok ... > GG> Probably it is a fault of my system, if no other experiences it. > > you're not alone with this problem here - i have the same one. and it > seems that it is somehow related to natd, because ftp works quite > well when i disable this daemon. any ideas? Well I am also experiencing something like this with ports and sendmail connections - intermittently, unfortunatly I am not running natd ! > > by the way, i have a question to natd gurus. i have faced with a > strange trouble - natd alters _all_ packets passing through the > interface (and it is clearly visible when i start natd with -v option) > completely ignoring -u option. but i would like to alter packets > for unregistered source addresses (192.168.0.0/16) only. what should i do? > > i run natd with "-u -n ed1" options and firewall rule for natd is: > 00100 divert 8668 ip from any to any via ed1 > > > Best regards, > Ilyamailto:ca...@avias.com > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message Tim. I'd rather boot Bill Gates than Windoze any day. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
Daniel Eischen wrote: > Does Modula-3 use libc_r, or does it have it's own user thread support? It has its own. It can be ported to use native threads, but it's a non-negligible amount of work. It hardly seems worth it for the GUI alone. > The recent set of commits to libc_r changed the thread scheduling > mechanism to use ITIMER_PROF instead of ITIMER_VIRTUAL. This was > to allow for fairer scheduling with I/O bound threads. My hunch is that it's not a fairness issue. It's just the fact that when you block in disk I/O, the whole process (all threads) blocks. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
Matthew D. Fuller wrote: > After about 4 days without cvsup'ing (including lots of fun gcc/egcs) > updates it took 6:16 to update my CVS repo including: When CVSup is fetching entirely new files, it can't do anything much smarter than compress them. It can't avoid moving the bits from point A to point B. In the case of egcs, that's a lot of bits. But six hours and sixteen minutes? That's awfully slow. You must have had a really bad link that day. I'd try a few different mirror sites if I were you. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: swap-related problems
Poul-Henning Kamp once wrote: > >> If you unset the datasize limit and the program does not exceed > >> the maximum system-supported datasize limit, malloc() should > >> not return NULL even if the system is out of swap. > >Can you explain why? Our malloc(3) is a little fuzzy as to the > >circumstances under which malloc will fail, but on Solaris, it is > >more explicit: > > RETURN VALUES > > If there is no available memory, malloc(), realloc(), > > memalign(), valloc(), and calloc() return a null pointer. > > > >I consider being out-of-swap as having "no available memory". Wouldn't you? > The trouble is, there is no such thing as "no available memory". Well, this is just an implementation detail, is not it? I don't mean to critisize, or anything, but such thing as "no available memory" is a fairly intuitive... Coming down, again, the malloc should return a usable memory if available and NULL if it's not. Is not this a "natural" semantics? Why can a program die because _another_ program ate up all the rest of the memory? > What we have instead is "not enough memory available for this specific > request". > For phkmalloc I can say in particular that there is a pool for each > size of chunk (16,32,64...2048 bytes and for pages. If you run out of > one of these there may still be stuff in the other pools. Then the malloc may need to take its time rearranging the pools, or whatever... It gets it right if there is a datasize limit, right? But the current behaviour under low-memory conditions seems wrong to me, and is certainly different from what the Solaris' malloc(3C) states. -mi DISCLAIMER: a) this message was not meant to offend; b) I realize, the Solaris' malloc() may also be broken in many ways; c) FreeBSD is rightfully the OS of choice for many (including myself); d) I realize, that FreeBSD is wonderfull and I myself use it _all_ i386 machines under my control and on most i386 machines outside of my control. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: compiler specs for -pthread/-kthread
On Tue, Apr 13, 1999 at 03:16:01PM -0700, Kurt D. Zeilenga wrote: > To facilate auto detection of the local threading environment, > it would be nice if the -?thread options set all the necessary > compiler/linker flags. It is a common practace for such > options to specify both compilation and link options. > > I suggest the EGCS specs be adjusted to: > > -pthread => -D_THREAD_SAFE -D_UTHREADS -lc_r > -kthread => -D_THREAD_SAFE -D_KTHREADS -lpthread A little known and not well documented fact is that FreeBSD also uses _REENTRANT in its header files. Ever wondered why you couldn't find declarations for gamma_r, lgamma_r, gammaf_r, or lgammaf_r? Check math.h. :) Personally I think conditional declarations should just be eliminated from math.h, rather than tell people they might have to add -D_REENTRANT. :) > > If the LinuxThread "port" is targetted to be -kthread: > > -kthread => -D_REENRANT -D_LINUXTHREADS -lpthread In FreeBSD, you should define -D_THREAD_SAFE for linuxthreads if you want the thread safe behaviour in stdio.h. Its a libc thing, not a linuxthreads thing. Adding -D_REENTRANT to linuxthreads doesn't get you anything except the added headers in math.h (same as libc_r). > After modify the specification, the headers/libraries would > be adjusted as needed. I can easily submit diffs if desirable. Nobody has offered to commit the changes to the header files I have requested, and the PR I submitted on Jan 29 has not been acted upon. As a result, I anticipate dropping the -DLINUXTHREADS solution to the header conflict problem in favor of stuffing all the linux threads specific headers into /usr/local/include/pthread/linuxthreads where they go now, and instead of -DLINUXTHREADS, people will have to add -I/usr/local/include/pthread/linuxthreads to their compile options. (This works now too). -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
John Polstra wrote: > > Does Modula-3 use libc_r, or does it have it's own user thread support? > > It has its own. It can be ported to use native threads, but it's a > non-negligible amount of work. It hardly seems worth it for the GUI > alone. No argmuent here. It's just that if it was using native threads, I would have been curious to see how CVSup worked before and after the recent changes to libc_r. But I guess I could have tested that myself :-) > My hunch is that it's not a fairness issue. It's just the fact that > when you block in disk I/O, the whole process (all threads) blocks. That statement made me think that Modula-3 had it's own threading support because our native threads using non-blocking file I/O. Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: compiler specs for -pthread/-kthread
%On Tue, Apr 13, 1999 at 03:16:01PM -0700, Kurt D. Zeilenga wrote: %> To facilate auto detection of the local threading environment, %> it would be nice if the -?thread options set all the necessary %> compiler/linker flags. It is a common practace for such %> options to specify both compilation and link options. %> %> I suggest the EGCS specs be adjusted to: %> %> -pthread => -D_THREAD_SAFE -D_UTHREADS -lc_r %> -kthread => -D_THREAD_SAFE -D_KTHREADS -lpthread % %A little known and not well documented fact is that FreeBSD also %uses _REENTRANT in its header files. Ever wondered why you %couldn't find declarations for gamma_r, lgamma_r, gammaf_r, %or lgammaf_r? Check math.h. :) % %Personally I think conditional declarations should just be %eliminated from math.h, rather than tell people they might %have to add -D_REENTRANT. :) % %> %> If the LinuxThread "port" is targetted to be -kthread: %> %> -kthread => -D_REENRANT -D_LINUXTHREADS -lpthread and don't forget -lgcc_r... Russell [...] %-- %Richard Seaman, Jr. email: d...@tar.com %5182 N. Maple Lanephone: 414-367-5450 %Chenequa WI 53058 fax: 414-367-5852 % % %To Unsubscribe: send mail to majord...@freebsd.org %with "unsubscribe freebsd-current" in the body of the message % To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
On Tue, Apr 13, 1999 at 03:41:46PM -0700, a little birdie told me that John Polstra remarked > Matthew D. Fuller wrote: > > > After about 4 days without cvsup'ing (including lots of fun gcc/egcs) > > updates it took 6:16 to update my CVS repo including: > > When CVSup is fetching entirely new files, it can't do anything much > smarter than compress them. It can't avoid moving the bits from point > A to point B. In the case of egcs, that's a lot of bits. > > But six hours and sixteen minutes? That's awfully slow. You must > have had a really bad link that day. I'd try a few different mirror > sites if I were you. Nono, 6 minutes and 16 seconds :P *lovin it* --- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Matthew Fuller http://www.over-yonder.net/ | * fulle...@futuresouth.com fulle...@over-yonder.net * | UNIX Systems Administrator Specializing in FreeBSD | * FutureSouth Communications ISPHelp ISP Consulting * | "The only reason I'm burning my candle at both ends, | *is because I haven't figured out how to light the* | middle yet" | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
Daniel Eischen wrote: > John Polstra wrote: > >> My hunch is that it's not a fairness issue. It's just the fact that >> when you block in disk I/O, the whole process (all threads) blocks. > > That statement made me think that Modula-3 had it's own threading > support because our native threads using non-blocking file I/O. For disk I/O? Are you sure? If so then it must use the aio/lio calls or something similar. Disk I/O calls _always_ block, even if you've set O_NONBLOCK on the file descriptor. John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
Matthew D. Fuller wrote: >> But six hours and sixteen minutes? That's awfully slow. You must >> have had a really bad link that day. I'd try a few different mirror >> sites if I were you. > > Nono, 6 minutes and 16 seconds :P > *lovin it* Ohhh! Heh, you had me worried for a minute there. :-) John --- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
John Polstra wrote: > > That statement made me think that Modula-3 had it's own threading > > support because our native threads using non-blocking file I/O. > > For disk I/O? Are you sure? If so then it must use the aio/lio calls > or something similar. Disk I/O calls _always_ block, even if you've > set O_NONBLOCK on the file descriptor. No it doesn't use aio/lio (although I was recently thinking about trying it). It uses select for I/O readiness, then read/write on O_NONBLOCK files. Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ftp hangs on -current
> > > On Tue, 13 Apr 1999 18:34:25 Ilya Naumov wrote: > > Hello Gianmarco, > > > > Thursday, April 08, 1999, 7:49:52 AM, you wrote: > > > > GG> "ftp" on 4.0-very-current (post egcs make world) randomly hangs during > > GG> sessions... > > GG> I never succeded in finishing a session lately. > > GG> To transfer some files from my home to my isp server I had to do an > > "ftp" > > GG> from the server and a "get" to them... > > > > GG> The ftp server works normally and fetch is ok ... > > GG> Probably it is a fault of my system, if no other experiences it. > > > > you're not alone with this problem here - i have the same one. and it > > seems that it is somehow related to natd, because ftp works quite > > well when i disable this daemon. any ideas? > > Well I am also experiencing something like this with ports and sendmail > connections - intermittently, unfortunatly I am not running natd ! > I am getting problems similar to those outlined above. I don't run natd, either, but I do have a firewall enabled. (open rule) I've had to 'put' files rather than 'get' them, since my last build/installworld. (Yesterday's -current source) Bret Ford To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvsup
John Polstra wrote: > > If we had kernel threads and Modula-3 supported them, this wouldn't be > a problem. But those are two very big ifs. :-( Alternatively, if you could use aio.h in Module-3, this wouldn't be a problem either. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "nothing better than the ability to perform cunning linguistics" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATA disks can do command queueing?
It seems Vallo Kallaste wrote: > On Tue, Apr 13, 1999 at 10:58:45PM +0200, Soren Schmidt > wrote: > > > Yep that is exactly what it means, however the driver in -current > > doesn't take advantage of it yet, but its on my TODO list. > > The reason why I put in this verbosity, is so I can get a hint to > > which drives support it, and it seems IBM are on of the few that > > does. > > Nice. As you say you need hints I can try 14gig 7200rpm IBM also, one > is on my table. I think it can behave similarly. It does, I have the 10G version it does have support. Nice drives BTW.. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
