Re: Shell games
On Tue, 18 Apr 2000 22:53:22 +0100, Brian Somers wrote: > I'm not sure why sanity won here though. I guess it'll be done the > next time it comes up Reason won in the Bourne shell case because ours is actively maintained. Until ours is no longer actively maintained by a responsive, cluefull and FreeBSD-friendly person or group of people, someone's going to have to come up with _new_ arguments for any other shell. Thus far, nothing compelling has emerged, though not for want of noise. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: floating point exceptions
On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote: > > Is FreeBSD's behavior correct? Why or why not? You can use the included > > code snippet to verify that this occurs. > > FreeBSD has traditionaly violated the IEEE FP standard in this regard. > This is fixed in 5.0 and I think in 4.0-STABLE (though I can't remember > what file this is in so I can't check.) Huh? I'm pretty sure you've got this backwards. FreeBSD has traditionally upheld the standard and we only recently decided to go with the flow in 5.0. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Large mbufs?
Is there support for large mbufs in v4.0? (that is, allocations of any size?) Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Large mbufs?
Dennis writes: > Is there support for large mbufs in v4.0? (that is, allocations of any size?) > There are 2 ways to use large mbufs: o options MCLSHIFT= in your kernel config file. Where XXX is 1 << XXX bytes. Eg, MCLSHIFT=12 is 4K mbuf clusters, MCLSHIFT=13 is 8k clusters, etc. config will complain, but it will work. There are several drawbacks to this method. The most glaring is that you'll probably be wasting an awfully large amount of space. o allocate & manage them yourself, using m_ext mbufs, within the subsystem you feel needs them. See the Tigon (sys/pci/if_ti.c) driver's management of jumbo frame receive buffers for an example of how this is done. Hope this helps, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
On Sat, 22 Apr 2000, Matthew Dillon wrote: [snip] > disk itself is probably the bottleneck. Disk writes tend to be > somewhat slower then disk reads and the seeking alone (between source > file and destination file), even when using a large block size, > will reduce performance drastically verses simply reading or writing > a single file linearly. Double buffering may help a disk-to-disk > file copy, but I doubt it will help a disk-to-same-disk file copy. > Wouldn't coping the file to another disk and then back to the original one than just a simple copy in some cases be faster then? After all, you are saving a lot of head seeks. > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Using the boot loader to set maximum memory size?
Is there any chance of extending the loader so that it can set the memory size, rather than hard coding it into the kernel config file? This would be quite useful for testing things which like a large amount of memory set aside exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for G400 cards here). Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPv4->IPv6 conversion suite?
I have just set up IPv6 on my network at home, and there was much rejoicing. :-) Now the problem is that legacy apps don't have v6 support. One idea I have floating around in my head is the idea of a socks-like combination of libc support and faith to allow IPv6-only networks to participate in ipv4 using faith as a proxy. Such a library would merely need a single input -- an IPV4PREFIX. It would take the socket(), connect(), etc calls for the AF_INET domain and turn them into AF_INET6 calls with the address being made out of the IPv4 input address and the IPV4PREFIX. With this in place, entire IPv6 networks could "hide" behind a single IPv4 address with which they could conduct IPv4 business, while using IPv6 natively. IMHO common deployment would speed the retirement of IPv4. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using the boot loader to set maximum memory size?
* Stephen Hocking <[EMAIL PROTECTED]> [000426 09:23] wrote: > Is there any chance of extending the loader so that it can set the memory > size, rather than hard coding it into the kernel config file? This would be > quite useful for testing things which like a large amount of memory set aside > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > G400 cards here). Use the undocumented hw.physmem variable in the loader. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: floating point exceptions
In the last episode (Apr 26), Sheldon Hearn said: > On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote: > > > Is FreeBSD's behavior correct? Why or why not? You can use the > > > included code snippet to verify that this occurs. > > > > FreeBSD has traditionaly violated the IEEE FP standard in this > > regard. This is fixed in 5.0 and I think in 4.0-STABLE (though I > > can't remember what file this is in so I can't check.) > > Huh? I'm pretty sure you've got this backwards. FreeBSD has > traditionally upheld the standard and we only recently decided to go > with the flow in 5.0. No; we held our moral ground against IEEE, until 5.0 when we gave in. The IEEE standard says "trap nothing". For most programs, this is the wrong thing to do, since they are not signal-processing apps or numerical analysis programs and a divide by zero is a coding error. I'd rather have my program die on an unexpected divide by zero than continue with invalid data. Why should we treat (1.0/0.0) any differently from (1/0)? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using the boot loader to set maximum memory size?
Alfred Perlstein wrote: > > * Stephen Hocking <[EMAIL PROTECTED]> [000426 09:23] wrote: > > Is there any chance of extending the loader so that it can set the memory > > size, rather than hard coding it into the kernel config file? This would be > > quite useful for testing things which like a large amount of memory set aside > > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > > G400 cards here). > > Use the undocumented hw.physmem variable in the loader. Patches for both /boot/help and loader.8 are accepted, of course. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] GPL certainly doesn't meet Janis Joplin's definition of freedom: "Freedom is just another word for nothing left to lose." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: floating point exceptions
On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote: > Why should we treat (1.0/0.0) any differently from (1/0)? Because Linux has the uncanny ability to both divide by zero and produce the shittiest coders the world has ever seen. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
Narvi wrote: > > On Sat, 22 Apr 2000, Matthew Dillon wrote: > > [snip] > > > disk itself is probably the bottleneck. Disk writes tend to be > > somewhat slower then disk reads and the seeking alone (between source > > file and destination file), even when using a large block size, > > will reduce performance drastically verses simply reading or writing > > a single file linearly. Double buffering may help a disk-to-disk > > file copy, but I doubt it will help a disk-to-same-disk file copy. > > > > Wouldn't coping the file to another disk and then back to the original one > than just a simple copy in some cases be faster then? > > After all, you are saving a lot of head seeks. The problem is that if they are on the same data channel then you have conflicts for access to the data bus. Some products like SCSI are better suited for that environment but data still only flows one direction at a time. On the old ISA bus, you could just about watch data flow with an analyzer plugged on to a new interface card. We had one interface card that the data ready went true before the data was stored into the on_card memory. The cpu was fast enough that I could watch the bits in the memory change. I couldn't get good data until memory had stablized. Cray's were really good at handling data in 1988 because they had 100MB/s + 1000MB/s data channels. I'm not sure how wide the data channels were. It seems like the 100MB/s was 16 bytes wide and the 1000 MB/s was 32 bytes wide. Their high speed disks were striped to provide 20MB/s continuous transfers. Getting data off of the disk was far more important to throughput than writing the data. The queued read/write ability of the scsi drives made life better but the disk was still the bottle neck to high speed data. The PCI bus probably shares that honor on the modern PC. It is only 4 bytes wide and relatively slow. The new 64bit PCI bus will help but that is a long way from the 256 bit or 512 bit wide Cray data channels that Cray was using in 1988. A while back I was given some parameters that could change the time required for a 4.0-Stable buildworld. The only option that improved my buildworld time was "CFLAGS= -pipe". It saved about 140u seconds. The option "-Os" made a buildworld take 1/3 longer. I also did an installworld (and kernel) of a -Os system and that really didn't change the times. The jump for version 4.0 on a Celeron 433a was 3560u + 800s to 4950u + 800s. There are still some options to try but "softupdates" didn't help. The buildworld using an UW scsi for /usr/obj was actually a little bit longer than using a UDMA66 ATA HD. The scsi was flat out at 8MB/s where as the UDMA HD was capable of 12-14MB/s. The Maxtor UDMA drive had a 2MB cache and the IBM uw was much smaller. Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: commit MAKE_SHELL?
On Tue, Apr 25, 2000 at 11:00:07PM -0700, Doug Barton wrote: > Anatoly Vorobey wrote: > > > Well, *should* we have a built-in "test"? I gather the original ash didn't > > have it due to the KIS principle. But if it speeds things up considerably, > > it's not much of a bloat, is it? I'd volunteer to write it. > > Unfortunately, the only way to tell for sure would be to do a couple > make worlds with the current sh, then do some with super-sh with the > built in 'test'. You are right. I will do it, and report the results. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using the boot loader to set maximum memory size?
> Is there any chance of extending the loader so that it can set the memory > size, rather than hard coding it into the kernel config file? This would be > quite useful for testing things which like a large amount of memory set aside > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > G400 cards here). There are better ways to achieve that, but you can use: set hw.physmem= MAXMEM (i386 only) Limits the amount of physical memory space available to the system to bytes. may have a k, M or G suffix to indicate kilobytes, megabytes and gigabytes respectively. Note that the current i386 architecture limits this value to 4GB. On systems where memory cannot be accurately probed, this option provides a hint as to the actual size of system memory (which will be tested before use). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using the boot loader to set maximum memory size?
> * Stephen Hocking <[EMAIL PROTECTED]> [000426 09:23] wrote: > > Is there any chance of extending the loader so that it can set the memory > > size, rather than hard coding it into the kernel config file? This would be > > quite useful for testing things which like a large amount of memory set aside > > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > > G400 cards here). > > Use the undocumented hw.physmem variable in the loader. There isn't an "undocumented hw.physmem" variable, there's only a "documented hw.physmem" variable. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using the boot loader to set maximum memory size?
* Mike Smith <[EMAIL PROTECTED]> [000426 10:46] wrote: > > * Stephen Hocking <[EMAIL PROTECTED]> [000426 09:23] wrote: > > > Is there any chance of extending the loader so that it can set the memory > > > size, rather than hard coding it into the kernel config file? This would be > > > quite useful for testing things which like a large amount of memory set aside > > > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > > > G400 cards here). > > > > Use the undocumented hw.physmem variable in the loader. > > There isn't an "undocumented hw.physmem" variable, there's only a > "documented hw.physmem" variable. Ah, it's in loader.help, but not the manpage, I'll patch it asap. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: floating point exceptions
On Wed, Apr 26, 2000 at 12:16:51PM -0400, Bill Fumerola wrote: > On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote: > > > Why should we treat (1.0/0.0) any differently from (1/0)? > > Because Linux has the uncanny ability to both divide by zero and produce > the shittiest coders the world has ever seen. Which brings me to the inevitable question: 'can NT divide by zero' ? ;-) -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
The standard PCI bus can do 130 MBytes/sec. Even with overhead issues (setup for a DMA burst) it can still do 100 MBytes/sec. A standard SCSI controller can do 40, 80, and now even 160 MBytes/sec over the wire - standard copper cabling w/ LVD connectors (example below). A modern hard disk can do 10-30 MBytes/sec to/from the platter, assuming no seeks. But the moment it needs to seek the performance drops drastically ... generally down to 1-5 MBytes/sec. So in the case of a file copy over a SCSI bus, the physical disk is almost always going to be the limiting factor. -Matt da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4340MB (924 512 byte sectors: 255H 63S/T 553C) da1 at ahc2 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da2 at ahc2 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) Mounting root from ufs:/dev/da0s1a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
Matthew Dillon wrote: > > The standard PCI bus can do 130 MBytes/sec. Even with overhead issues > (setup for a DMA burst) it can still do 100 MBytes/sec. But that depends on what is also going on at the same time. There are three other cards in my PCI bus. You can eliminate one because I wasn't using the sound card :). > > A standard SCSI controller can do 40, 80, and now even 160 MBytes/sec > over the wire - standard copper cabling w/ LVD connectors (example > below). This is where the cache size on the HD becomes important. It also acts like a hardware double buffering. > > A modern hard disk can do 10-30 MBytes/sec to/from the platter, assuming > no seeks. But the moment it needs to seek the performance drops > drastically ... generally down to 1-5 MBytes/sec. I haven't seen any 30MB/s. The 10K LVD IBM's were just about the fastest at 20MB/s continuous. The drop for UDMA drives is to even lower rates. > > So in the case of a file copy over a SCSI bus, the physical disk is > almost always going to be the limiting factor. I just noticed that mine isn't showing "Tagged Queueing Enabled" is that something I can set? The adapter is an Adaptec 2940uw. da0 at ahc0 bus 0 target 4 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
In the last episode (Apr 26), Kent Stewart said: > I just noticed that mine isn't showing "Tagged Queueing Enabled" is > that something I can set? The adapter is an Adaptec 2940uw. > > da0 at ahc0 bus 0 target 4 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) The CAM code has a quirk entry for IBM DCAS drives that turns it off; check out /sys/cam/cam_xpt.c, line 320. I suggest benchmarking with and without the quirk entry, and if it's faster with tagged queueing, update PR kern/10398. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
:In the last episode (Apr 26), Kent Stewart said: :> I just noticed that mine isn't showing "Tagged Queueing Enabled" is :> that something I can set? The adapter is an Adaptec 2940uw. :> :> da0 at ahc0 bus 0 target 4 lun 0 :> da0: Fixed Direct Access SCSI-2 device :> da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) :> da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) : :The CAM code has a quirk entry for IBM DCAS drives that turns it off; :check out /sys/cam/cam_xpt.c, line 320. I suggest benchmarking with :and without the quirk entry, and if it's faster with tagged queueing, :update PR kern/10398. : :-- : Dan Nelson : [EMAIL PROTECTED] I seem to remember a discussion last year about tagged commands being a lot slower on IBM drives being the reason why tagged queueing was turned off. I wonder if IBM has fixed the problem in their later drives? Note that tagging is different from disconnection. Tagging allows you to queue multiple commands (e.g. multiple reads & writes) to the drive. Disconnection is a bus-level protocol which allows the SCSI bus to be freed up after sending a command (e.g. like a read) so other SCSI devices can use the bus while the drive is seeking. Disconnection is more important. Tagging is nice in that it can absorb command queueing overheads and allows the drive to prioritize the transactions based on the characteristics of the media, but tagging is not going to make much of a difference when you only have one or two processes banging on the drive. Tagging shows its suds on more heavily loaded systems, when dozens of processes are banging on the disks. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
> > A modern hard disk can do 10-30 MBytes/sec to/from the platter, assuming > > no seeks. But the moment it needs to seek the performance drops > > drastically ... generally down to 1-5 MBytes/sec. > > I haven't seen any 30MB/s. The 10K LVD IBM's were just about the > fastest at 20MB/s continuous. The drop for UDMA drives is to even > lower rates. The IBM DPTA-372730 will do 23 MB/s continuous - this is a 7200 RPM IDE drive with very high bit density. There are IDE drives that do more, and I certainly expect the new 36 GB 1" 10K drives to do more. > I just noticed that mine isn't showing "Tagged Queueing Enabled" is > that something I can set? The adapter is an Adaptec 2940uw. > > da0 at ahc0 bus 0 target 4 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) The DCAS-34330 is quirked out - which may not always be sensible. See /sys/cam/cam_xpt.c. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Removing synchronizing instruction from MP unlock
I had added a synchronizing instruction to the MP unlock code in November after the issue was brought up in the lists and linux folks thought there might be a synchronization issue. It turns out that there is no issue. This was refered to me by Mike Silbersack: http://kernelnotes.org/lnxlists/linux-kernel/lk_0004_04/msg00332.html I have decided to remove the synchronizing instruction from the MP unlock code. There are three cases: * single cpu using the MP lock. - 200 nS faster with the synchronizing instruction removed. * two cpu's using the MP lock, in contention (one holds it while the other is trying to get it) - 700 nS SLOWER with the synchronizing instruction removed. * two cpu's using the MP lock, NOT in contention (one holds it and releases it, then sometime later the other holds it and releases it). - 400 ns FASTER. Since our goal is to reduce lock contention in the first place by removing the MP lock, and since the most common instance of MP use eats some user time and does not result in billions of short-term MP locks being simultaniously contended for by more then one cpu (this is different from long-term contention, where 700 nS doesn't matter anyway), I have decided to remove the synchronizing instruction from the unlock code for FreeBSD. Linus has indicated (if you follow the thread in the above URL), that he will be doing the same thing for the Linux MP unlock code as well. This is just a head's up. No review is necessary. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Safe sourcing of rc files
On Wed 2000-04-19 (16:51), Neil Blakey-Milner wrote:
> I have another idea: We make a sh script named "rcsource" or whatever,
> which we source when we want to have the rc environment, stealing your
> code maliciously:
>
> /--
> sourcercs_sourced_files=
> sourcercs ( ) {
> local rc_conf_files
> for i in $*; do
> case "${sourcercs_sourced_files}" in
> *:$i:*)
> ;;
> *)
> sourcercs_sourced_files="${sourcercs_sourced_files}:$i:"
> echo $i
> if [ -r $i ]; then
> . $i
> sourcercs ${rc_conf_files}
> fi
> ;;
> esac
> done
> }
> sourcercs /etc/defaults/rc.conf
> \--
Unless someone comes back with negative feedback, I'll be pushing for a
commit for this (and all that depend on this change) on the weekend.
Consider this a request for review and comment.
Neil
--
Neil Blakey-Milner
Hacker In Chief, Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
Dan Nelson wrote: > > In the last episode (Apr 26), Kent Stewart said: > > I just noticed that mine isn't showing "Tagged Queueing Enabled" is > > that something I can set? The adapter is an Adaptec 2940uw. > > > > da0 at ahc0 bus 0 target 4 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > > The CAM code has a quirk entry for IBM DCAS drives that turns it off; > check out /sys/cam/cam_xpt.c, line 320. I suggest benchmarking with > and without the quirk entry, and if it's faster with tagged queueing, > update PR kern/10398. What would you suggest. Do you remove the entry or just change the tags field? It has mintags=0 and maxtags=0. The other entries have mintags=24 and maxtags=32. I 've have about 6 hours of buildworlds on it right now. Plus some other benchmarking. Kent > > -- > Dan Nelson > [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: commit MAKE_SHELL?
On Wed, Apr 26, 2000 at 07:55:19PM +, Anatoly Vorobey wrote:
> > Unfortunately, the only way to tell for sure would be to do a couple
> > make worlds with the current sh, then do some with super-sh with the
> > built in 'test'.
>
> You are right. I will do it, and report the results.
Reporting back ;) Adding built-in "test" turns out to be frightfully easy,
by compiling into the shell the real test(1) code (builtin printf works
this way, too). I have broken world right now so I can't test it, but on
running several configure scripts from ports I generally save from 9% to
18% of time. Maybe someone would like to test/review/comment on this?
Patches below. In test(1), errx() calls had to be changed into warnx()
calls because the latter are #define'd to be something else when compiling
within the shell, in order to capture the output when necessary.
To test, 'sh /usr/src/bin/test/TEST.sh', run configures, build worlds, etc. ;)
Index: test.c
===
RCS file: /freebsd/cvs/src/bin/test/test.c,v
retrieving revision 1.29
diff -u -r1.29 test.c
--- test.c 1999/12/28 09:34:57 1.29
+++ test.c 2000/04/26 22:30:13
@@ -10,10 +10,12 @@
* This program is in the Public Domain.
*/
+#if !defined(SHELL)
#ifndef lint
static const char rcsid[] =
"$FreeBSD: src/bin/test/test.c,v 1.29 1999/12/28 09:34:57 sheldonh Exp $";
#endif /* not lint */
+#endif /* not a sh builtin */
#include
#include
@@ -26,6 +28,11 @@
#include
#include
+#ifdef SHELL
+#define main testcmd
+#include "bltin/bltin.h"
+#endif
+
/* test(1) accepts the following grammar:
oexpr ::= aexpr | aexpr "-o" oexpr ;
aexpr ::= nexpr | nexpr "-a" aexpr ;
@@ -171,7 +178,7 @@
p++;
if (strcmp(p, "[") == 0) {
if (strcmp(argv[--argc], "]"))
- errx(2, "missing ]");
+ return( (warnx("missing ]") , 2) );
argv[argc] = NULL;
}
@@ -195,9 +202,9 @@
{
if (op && *op)
- errx(2, "%s: %s", op, msg);
+ exit( (warnx("%s: %s", op, msg), 2) );
else
- errx(2, "%s", msg);
+ exit( (warnx("%s", msg), 2) );
}
static int
Index: Makefile
===
RCS file: /freebsd/cvs/src/bin/sh/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- Makefile1999/09/08 15:40:43 1.30
+++ Makefile2000/04/27 00:24:55
@@ -5,7 +5,7 @@
SHSRCS=alias.c arith.y arith_lex.l cd.c echo.c error.c eval.c exec.c expand.c
\
histedit.c input.c jobs.c mail.c main.c memalloc.c miscbltin.c \
mystring.c options.c output.c parser.c printf.c redir.c show.c \
- trap.c var.c
+ test.c trap.c var.c
GENSRCS= builtins.c init.c nodes.c syntax.c
GENHDRS= builtins.h nodes.h syntax.h token.h y.tab.h
SRCS= ${SHSRCS} ${GENSRCS} ${GENHDRS} y.tab.h
@@ -22,7 +22,7 @@
# for debug:
# CFLAGS+= -g -DDEBUG=2
-.PATH: ${.CURDIR}/bltin ${.CURDIR}/../../usr.bin/printf
+.PATH: ${.CURDIR}/bltin ${.CURDIR}/../../usr.bin/printf ${.CURDIR}/../test
CLEANFILES+= mkinit mkinit.o mknodes mknodes.o \
mksyntax mksyntax.o
Index: builtins.def
===
RCS file: /freebsd/cvs/src/bin/sh/builtins.def,v
retrieving revision 1.7
diff -u -r1.7 builtins.def
--- builtins.def1999/08/27 23:15:08 1.7
+++ builtins.def2000/04/27 00:25:08
@@ -80,6 +80,7 @@
setcmd set
setvarcmd setvar
shiftcmd shift
+testcmdtest [
trapcmdtrap
truecmd: true
typecmdtype
--
Anatoly Vorobey,
[EMAIL PROTECTED] http://pobox.com/~mellon/
"Angels can fly because they take themselves lightly" - G.K.Chesterton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
xe driver
FYI I tried the xe driver in 4.0-Stable and could not get it to work.
I have a 16bit Xircomn RE-10 ethernet adaptor.
here is what I tried
/etc/pccard.conf
# Xircom CreditCard Ethernet 10/100 + modem (Ethernet part)
card "Xircom" "Ethernet Adapter"
config auto "xe1" 9
insert logger -t pccard:$device -s Xircom CreditCard Modem inserted
insert /etc/pccard_ether $device
remove logger -t pccard:$device -s Xircom CreditCard Modem removed
remove /sbin/ifconfig $device delete
also tried config 0x1, 0x27 ,0x15 and "xe0"
cruft from insert...
Apr 27 06:24:33 ricoh /kernel: pccard: card inserted, slot 1
Apr 27 06:24:38 ricoh pccardd[409]: Card "Xircom"("Ethernet Adapter") matched "Xircom"
("Ethernet Adapter")
Apr 27 06:24:38 ricoh pccardd[409]: Card "Xircom"("Ethernet Adapter") matched "Xircom"
("Ethernet Adapter")
Apr 27 06:24:44 ricoh /kernel: xe1: xe: Probing
Apr 27 06:24:44 ricoh /kernel: xe1: xe: Probing
Apr 27 06:24:44 ricoh /kernel: xe1: Can't map in cis
Apr 27 06:24:44 ricoh /kernel: xe1: Can't map in cis
Apr 27 06:24:44 ricoh pccardd[409]: driver allocation failed for Xircom(Ethernet
Adapter): Device not configured
Apr 27 06:24:44 ricoh pccardd[409]: driver allocation failed for Xircom(Ethernet
Adapter): Device not configured
Ill keep trying as soon as I hear about updates...
RP
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: No route for 127/8 to lo0 (?)
On Mon, Apr 24, 2000 at 07:28:32PM -0400, Joseph Jacobson wrote:
> See RFC1122, section 3.2.1.3, available at
> http://www.cis.ohio-state.edu/htbin/rfc/rfc1122.html
> http://www.faqs.org/rfcs/rfc1122.html
Right. Assuming we're looking at the same section, it says:
[...]
(g) { 127, }
Internal host loopback address. Addresses of this form
MUST NOT appear outside a host.
[...]
which is the only discussion of 127/8 I see in that document.
The behaviour I'm seeing is that packets to 127.255.255.255 (i.e.,
broadcasts on the 127/8 net) are being sent out the default route,
because on FreeBSD (at least, FreeBSD 3-stable), there's only a host
route for 127.0.0.1, not a network route. Per the RFC, that's
incorrect behaviour, right?
The RFC also says:
For most purposes, a datagram addressed to a broadcast or
multicast destination is processed as if it had been
addressed to one of the host's IP addresses;
Is there some special-case for 127/8 that's covered by the "For most
purposes" line?
Cheers,
N
--
Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95.
Telephone line, $24.95 a month. Software, free. USENET transmission,
hundreds if not thousands of dollars. Thinking before posting, priceless.
Somethings in life you can't buy. For everything else, there's MasterCard.
-- Graham Reed, in the Scary Devil Monastery
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: floating point exceptions
In the last episode (Apr 27), Andrew Reilly said: > > Because 0.0 might be the closest approximation to whatever > number you were really trying to divide by that the hardware can > manage. 0 is never an approximation to 1 or -1. Aaah, but that assumes you're not also trapping on underflow :) -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How about building modules along with the kernel?
[cc'ing to hackers, to get this archived] George Cox wrote: > > On 26/04 19:29, Daniel C. Sobral wrote: > > > BTW, loader reads FAT just fine too, thank you. > > I have a related question :-) > > Is there any way I can put a FreeBSD kernel on a DOS partition, and load > it, specifying the root device (different from the DOS partition device) > that I want it to use? Sure. There are many variations that you can try. For example, you can put something like kernel="disk1s1:/kernel" in /boot/loader.conf, which will cause the loader to get the kernel from said disk/slice. Now, assume FreeBSD is on disk2 or disk1s2, for example, and you tell booteasy (boot0) to boot from said disk. The root device will be the one you asked booteasy to boot FreeBSD from (and where loader will be loaded from), while the kernel will be coming from the other disk. Alternatively, there is the variable rootdev you can use to specify an alternate root device. See loader(8) for more information, as well as "help" from the loader prompt. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] GPL certainly doesn't meet Janis Joplin's definition of freedom: "Freedom is just another word for nothing left to lose." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
lock-ups due to the scheduler
I dropped hints that there may be issues about 3 weeks ago, as my machine
had locked up for apparently no reason, and I had no idea why until
recently. It seems that it has everything to do with running things that
use lots of CPU at a very high priority (I use -20).
I've been struggling for a few days with this... and what happens is that
the kernel never executes any user processes (or does so so very rarely
that I really can't detect it at all, in any application, the execution).
I'm not really sure what's happening, but it definitely is with the
scheduler: if I cap the scheduler's priority computation on the lower
end to keep user processes from not executing with a p_priority < PUSER,
the system can get slightly unresponsive, but it does not lock up.
The modifications I made to allow prevention of this follow my signature.
This is a deadlock-type situation, and I can reproduce it at will, so I'll
try to explain the steps I can reproduce it with.
1. start XMMS at -20 priority, and play something
2. XMMS is decoding audio and other random things, nothing huge, but at
about 15-20% CPU. XMMS sends decoded mp3 (archives of CDs I own) to
the EsounD daemon (esd), which takes 2-3% cpu or so, and XFree86
itself takes a good 5-10% cpu.
3. Start a "Visualization" plugin, which basically takes XMMS to full
CPU usage (as much as it can get), and things lock up. XMMS is the
curproc for every single time I've polled it (using DDB, for example),
and I stop hearing audio. XFree86 would be doing the X11 servering,
and esd would mostly be writing to the audio device or reading from its
socket, so usually in PRIBIO or PSOCK.
At this point, the system is really locked up, and there's nothing I can
do. I can, however, get a coredump and have the entire system state at
this point. I'm certain that that other people here will be able to try
the same tests, of course on 5.0-CURRENT, and possibly reproduce them
exactly the same as it happens for me. I can grovel in a coredump to
get information about the system as it was running at the time, so if
anyone can provide hints as to where to check for what happened that
makes things lock up nowadays, I'll be grateful, and I'll be able to
try almost anything to get this fixed.
If you're familiar with the scheduler area of the system, please help.
I have noone's arm to twist or anything of the sort, so I'm really
going out on a limb hoping someone will be able to try to help me fix
this. Note that I've taken my HZ=1000 line out of my kernel config,
so I'm running at a standard hz = 100 and a kern.quantum of 2.
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
Index: kern_synch.c
===
RCS file: /usr2/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.89
diff -u -u -r1.89 kern_synch.c
--- kern_synch.c2000/03/28 18:06:42 1.89
+++ kern_synch.c2000/04/27 00:55:21
@@ -903,6 +903,10 @@
maybe_resched(p);
}
+static int priority_lower_cap = 0;
+SYSCTL_INT(_debug, OID_AUTO, enable_priority_lower_cap, CTLFLAG_RW,
+ &priority_lower_cap, 0, "");
+
/*
* Compute the priority of a process when running in user mode.
* Arrange to reschedule if the resulting priority is better
@@ -917,6 +921,12 @@
if (p->p_rtprio.type == RTP_PRIO_NORMAL) {
newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
NICE_WEIGHT * p->p_nice;
+ if (priority_lower_cap && newpriority < PUSER) {
+ if (p == curproc)
+ uprintf("kernel: tried to use priority %d\n",
+ newpriority);
+ newpriority = PUSER;
+ }
newpriority = min(newpriority, MAXPRI);
p->p_usrpri = newpriority;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: commit MAKE_SHELL?
On Tue, 25 Apr 2000 23:00:07 -0700, Doug Barton <[EMAIL PROTECTED]> wrote: >Anatoly Vorobey wrote: > >> Well, *should* we have a built-in "test"? I gather the original ash didn't >> have it due to the KIS principle. But if it speeds things up considerably, >> it's not much of a bloat, is it? I'd volunteer to write it. > > Unfortunately, the only way to tell for sure would be to do a couple >make worlds with the current sh, then do some with super-sh with the >built in 'test'. A somewhat quicker (though not quite as accurate) check is to do a make buildworld with accounting on. Based on this, the most-executed (>1000) commands (after merging aliases) are: 23743 cpp 23912 sh sh* 17060 cc 15583 as 13689 cc1 17934 test [ 12544 ld 11725 mv 7366 make 4904 rm 2999 ln 2160 sed 2102 gzip 1454 mkdir (There was some other system activity, but I don't think it would affect the results). This suggests that making test/[ a builtin would probably help, but probably not nearly as much as reducing the number of shells exec'd (ie making make(1) a bit smarter). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lock-ups due to the scheduler
This is quite interesting. I'm no scheduler expert, but my understanding
is priority < PUSER won't degrade and is only set in kernel mode after
waking up from a sleep. In user mode, processes should always have priority
p_usrpri >= PUSER, it is obviously not true for a negative nice value:
> newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> NICE_WEIGHT * p->p_nice;
We should probably offset p->p_nice by PRIO_MIN,
> newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> NICE_WEIGHT * (p->p_nice - PRIO_MIN);
To fully utilize the 20 out of 32 run queues for user priorities, we might
want to change NICE_WEIGHT from 2 to 1, and upper limit of p_estcpu to
#define ESTCPULIM(e) \
min((e),
INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN) - PPQ) + \
INVERSE_ESTCPU_WEIGHT - 1)
so that a cpu hog at nice 0 would have about the same priority as a low
cpu usage nice +20 process.
-lq
> I dropped hints that there may be issues about 3 weeks ago, as my machine
> had locked up for apparently no reason, and I had no idea why until
> recently. It seems that it has everything to do with running things that
> use lots of CPU at a very high priority (I use -20).
>
> I've been struggling for a few days with this... and what happens is that
> the kernel never executes any user processes (or does so so very rarely
> that I really can't detect it at all, in any application, the execution).
>
> I'm not really sure what's happening, but it definitely is with the
> scheduler: if I cap the scheduler's priority computation on the lower
> end to keep user processes from not executing with a p_priority < PUSER,
> the system can get slightly unresponsive, but it does not lock up.
> The modifications I made to allow prevention of this follow my signature.
>
> This is a deadlock-type situation, and I can reproduce it at will, so I'll
> try to explain the steps I can reproduce it with.
>
> 1. start XMMS at -20 priority, and play something
> 2. XMMS is decoding audio and other random things, nothing huge, but at
>about 15-20% CPU. XMMS sends decoded mp3 (archives of CDs I own) to
>the EsounD daemon (esd), which takes 2-3% cpu or so, and XFree86
>itself takes a good 5-10% cpu.
> 3. Start a "Visualization" plugin, which basically takes XMMS to full
>CPU usage (as much as it can get), and things lock up. XMMS is the
>curproc for every single time I've polled it (using DDB, for example),
>and I stop hearing audio. XFree86 would be doing the X11 servering,
>and esd would mostly be writing to the audio device or reading from its
>socket, so usually in PRIBIO or PSOCK.
>
> At this point, the system is really locked up, and there's nothing I can
> do. I can, however, get a coredump and have the entire system state at
> this point. I'm certain that that other people here will be able to try
> the same tests, of course on 5.0-CURRENT, and possibly reproduce them
> exactly the same as it happens for me. I can grovel in a coredump to
> get information about the system as it was running at the time, so if
> anyone can provide hints as to where to check for what happened that
> makes things lock up nowadays, I'll be grateful, and I'll be able to
> try almost anything to get this fixed.
>
> If you're familiar with the scheduler area of the system, please help.
> I have noone's arm to twist or anything of the sort, so I'm really
> going out on a limb hoping someone will be able to try to help me fix
> this. Note that I've taken my HZ=1000 line out of my kernel config,
> so I'm running at a standard hz = 100 and a kern.quantum of 2.
>
> --
> Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
> [EMAIL PROTECTED]`--'
>
> Index: kern_synch.c
> ===
> RCS file: /usr2/ncvs/src/sys/kern/kern_synch.c,v
> retrieving revision 1.89
> diff -u -u -r1.89 kern_synch.c
> --- kern_synch.c 2000/03/28 18:06:42 1.89
> +++ kern_synch.c 2000/04/27 00:55:21
> @@ -903,6 +903,10 @@
> maybe_resched(p);
> }
>
> +static int priority_lower_cap = 0;
> +SYSCTL_INT(_debug, OID_AUTO, enable_priority_lower_cap, CTLFLAG_RW,
> + &priority_lower_cap, 0, "");
> +
> /*
> * Compute the priority of a process when running in user mode.
> * Arrange to reschedule if the resulting priority is better
> @@ -917,6 +921,12 @@
> if (p->p_rtprio.type == RTP_PRIO_NORMAL) {
> newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> NICE_WEIGHT * p->p_nice;
> + if (priority_lower_cap && newpriority < PUSER) {
> + if (p == curproc)
> + uprintf("kernel: tried to use priority %d\n",
> + newpriority);
> + newpriority = PUSER;
> +
