Re: mmap mapped segment length
On Aug 21, 2:10am, Wes Peters wrote: } Subject: mmap mapped segment length } I discovered to my dismay today that the length field in the mmap call is } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file } and found I was only processing the first 4 MBytes of it. 50 MB should comfortably fit in a size_t. } Is this intentional, or just an artifact of the implementation? Is there any } reason NOT to change this to an off_t? The type of size_t is supposed to be large enough to express the length of any object that will fit in the virtual address space of a process. Since a size_t is 32 bits on an i386 and pointers are also 32 bits, there wouldn't be any advantage to changing mmap() to use a 64 bit wide length parameter, since you wouldn't be able to access all of such a large object. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device_add_child??
man 9 device_probe_and_attach Nick On Sat, 21 Aug 1999, Warner Losh wrote: In message [EMAIL PROTECTED] "David E. Cross" writes: : I have been writing a nasty kludge to treat a CardBus bridge as a standard : PCI bridge (with static config) you may start throwing rocks now. Ewe. Yuck. Wouldn't it be better to help the pccard/cardbus efforts :-) : I have : it to the point where I can (after the system is booted) 'pciconf -r : pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would : then just be a simple matter of 'device_add_child(dev, "pci", 5, 0);' to get : the bus to show up at PCI5: at bootup, but it seems to ignore it. following : from pcisupport.c I also tried to 'bus_generic_attach()' it after : device_add_child() finished. no go. Any suggestions? device_add_child just adds it to the tree. It doesn't probe or attach it. If you kludge adding it into the tree, you'll have to kludge attaching it. You might want to look at my pccard kludge-o-matic for examples. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
You can check the change by recompiling a few utils with the change:
(find . -name \*.c | xargs grep -l qsort)
./bin/ps/ps.c
./contrib/gcc/*.c
./contrib/top/commands.c
./games/fortune/strfile/strfile.c
./gnu/usr.bin/sort/sort.c
./sbin/fsck/pass2.c
The fsck one is a nice one. Just wack your /usr and reboot :-)
Nick
On Fri, 20 Aug 1999, Archie Cobbs wrote:
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
e-Mail: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
"Daniel C. Sobral" wrote: Terry Lambert wrote: That's kind of the point. No other VFS stacking system out there plays by FreeBSD's revamped rules. I look around and I see no standards. It is still time to be experimental. Since someone complained of my meekness, let me restate that... :-) 1) BS. That was not your point. Your point, in which you spent many paragraphs, was that the present way FreeBSD things does it stuff cannot support passing a method through an intermediate host/fs that does not know it. If your "point" was the above, you could just have said "no one else does it this way, so we won't be able to have non-FreeBSD intermediate/frontend/backend hosts". Only that does not prove that "our" way is not right. 2) There is *no* compatibility in the VFS out there. It's a jungle. If we implemented something compatible with anyone else, it would be a first. And given that everything out there have it's problems, it would be a huge mistake to adopt someone's standard just for the sake of being compatible. And if you disagree with point 2, feel free to argue against it. But in no way it will justify that absurd comment you made. Either that paragraph was trying to cover a flaw in your logic, or you just lost your train of thought. It certainly detracted from the content of the message. "You must assume that the intermediate host doesn't play by your rules". Bah. [not that I don't generally agree with you more often than it would be prudent to let it be publicly known :-) ] -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
:The problem that occurs on the FreeBSD server is simply that the :nfsrv_commit() procedure calls fsync() on the file... on the *ENTIRE* :file, for every commit rpc, rather then syncing just the offset/range :requested. I am looking into ways to fix this. : Ok, I've verified the problem. The nfsrv_commit() code running on the server is definitely the culprit. I was able to make a tentitive patch which increased NFSv3 write performance to 10 MBytes/sec -- the maximum my 100BaseTX network can do. CURRENT in tree:2.5 MBytes/sec CURRENT w/ asynchronized commit rpc:4.5 MBytes/sec CURRENT w/ asy commit and fixed nfsrv_commit: 10 MBytes/sec (1) note(1): network is maxed out. Running bonnie returned around 5.2 MBytes/sec using putc, 3.5 MBytes/sec doing rewrite (but also 3.5 MBytes/sec going the other way), and 10 MBytes/sec writing intelligently. Throughout the test the low level disk I/O on the server was able to do sustained clustering at 64KB/t. I have a backlog of patches so it may be a week or more before this one gets tested and committed into CURRENT. It's a little racey for putting into STABLE but maybe after a month of testing on CURRENT we will be able to do it. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap mapped segment length
Don Lewis said: On Aug 21, 2:10am, Wes Peters wrote: } Subject: mmap mapped segment length } I discovered to my dismay today that the length field in the mmap call is } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file } and found I was only processing the first 4 MBytes of it. 50 MB should comfortably fit in a size_t. It seems that 4MB and 4GB are being confused :-). John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
So are there any _objections_ to having the kernel match promiscuous "enabled" messages with "disabled" counterparts? I strongly _request_ such a log message. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel debugging questions
Zhihui Zhang [EMAIL PROTECTED] writes: Thanks for your response. I can not think of those points myself. However, on page 7 of the book "Panic! Unix system crash dump analysis", it says that a debugger named kadb in SunOS can load the real kernel during boot and treat the latter like a great, big, user program, stepping through its execution, examining and modifying values on the fly. It seems to me that FreeBSD does not have such a debugger. Maybe ddb can do so, but it works with assembly. kadb also works with assembly. That being said, I much prefer ddb to kadb, and of course remote gdb is *much* nicer. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: from number to power of two
G'day Nick, Nick Hibma [EMAIL PROTECTED] wrote: Does anyone know an inexpensive algorithm (O(1)) to go from an number to the next (lower or higher) power of two. 1 - 1 2,3 - 2 4,5,6,7 - 4 8,9,10,11,12,13,14,15 - 8 etc. So %1101 should become either %1 or %1000. a bitwise shift left (to higher) or right (to lower) before or after masking out all but the most significant bit in the number. You just need to know how many bits to mask based on where the most significant bit is ;] I was tempted to throw something together but its late, and the idea should be enough to go on ... Cheers Leigh -- | "By the time they had diminished | Leigh Hart, [EMAIL PROTECTED] | | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | | began to suspect 'Hungry' ..." | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, "The Far Side" | http://www.dotat.com/hart/ | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: from number to power of two
Does anyone know an inexpensive algorithm (O(1)) to go from an number to the next (lower or higher) power of two. 1 - 1 2,3 - 2 4,5,6,7 - 4 8,9,10,11,12,13,14,15 - 8 etc. So %1101 should become either %1 or %1000. The only solution I have so far is a table. That is a possibility as the the highest number will be 32 I think. The kernel uses a 'ffs()' function for that but i seem to remember that some processors have this one as a machine instruction. ffs() is declared in /sys/sys/libkern.h and implemented in /sys/libkern/ffs.c but maybe there is an assembly version somewherewhich i can't find. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: from number to power of two
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3 - 2
4,5,6,7 - 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
Nick,
Probably the best solution I can think of is a binary search on the
number. I'd estimate it as better than a table, as you save on memory
references (tables sound cool, but, from experience, they cause enough
extra data cache misses to kill any advantage, even in
a highly-optimized inner loop.
For 8-bit integets, a quick solution is:
int
round_up(int x)
{
if (x 0xf0) {
if (x 0xc0)
return (x 0x80) ? 0x80 : 0x40;
else {
return (x 0x20) ? 0x20 : 0x10;
}
}
else {
if (x 0xc)
return (x 0x8) ? 0x8 : 0x4;
else {
return (x 0x2) ? 0x2 : 0x1;
}
}
}
It's actually faster than the BSF/BSR operations on Pentium (and the
ffs() libc function), as Pentium does a sequential search of the bit
string and therefore is O(n) (eek!)
The innermost comparison could probably be avoided if it wasn't 00:37
or if I didn't have to get up early in the morning. You could also
combine that with a smaller lookup table to get the best of both
worlds.
Patryk.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ATX power supplies
At 12:29 PM 8/21/99 -0400, Chuck Robey wrote: Anyone know where the spec might be for how ATX power supplies work (especially the interface to the motherboard, and their on'off methods?) Thanks. ftp://download.intel.com/design/motherbd/atx_201.pdf See section 4.2 Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATX power supplies
On Sat, 21 Aug 1999, Kevin Day wrote: At 12:29 PM 8/21/99 -0400, Chuck Robey wrote: Anyone know where the spec might be for how ATX power supplies work (especially the interface to the motherboard, and their on'off methods?) Thanks. ftp://download.intel.com/design/motherbd/atx_201.pdf That's just what I wanted, thanks (also to Len, who sent something seconds later). I have to troubleshoot something. Time to get the trusty VOM out. +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Questions for vnconfig
I have successfully used vnconfig to add swap file and mount disk image files. However, I am still not sure about the following two things: (1) What does the count in "pseudo-device vn count" stand for? My guess is that if it is 2, then we can use /dev/vn0x and /dev/vn1x. If it is 1, then we can only use /dev/vn0x. The x stands for one of those eight partitions [a-h] in one slice. (2) For /dev/vn0[a-h], which one from a-h should I use for which purpose? Any help is appreciated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: from number to power of two
At Sat, 21 Aug 1999 12:54:32 +0200, Nick Hibma wrote:
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3- 2
4,5,6,7- 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
This small prog works at least on x86
=
#include sys/types.h
#include machine/cpufunc.h
int
main(int argc, char **argv){
int i, j, k;
sscanf(argv[1], "%d", i);
j = 1(fls(i)-1);
k = 1(fls(i-1));
printf("%d %d %d\n", j, i, k);
return 0;
}
=
/Johan K
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: pthread_set_concurrency()
According to Nate Williams: FreeBSD has no kernel 'thread' support, only user level. That's not strictly true. The fact is we have both kernel and user threads but no mapping between the two... The kernel already internally use some threads. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pthread_set_concurrency()
FreeBSD has no kernel 'thread' support, only user level. That's not strictly true. The fact is we have both kernel and user threads but no mapping between the two... The kernel already internally use some threads. Your definition of kernel threads and mine are obviously quite different. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SCSI vs IDE with vinum
I just setup vinum for the first time on a brand new server, nd I am getting what I think are strange results in performance tests with rawio. My SCSI drives seem to be much slower that my IDE drives? Here is a dmesg from the machine: ### Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Sat Aug 21 06:52:28 MDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GUILD1 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III (451.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,b25 real memory = 268435456 (262144K bytes) avail memory = 257900544 (251856K bytes) Preloaded elf kernel "kernel" at 0xc0332000. Probing for devices on PCI bus 0: chip0: Intel 82443BX host to PCI bridge rev 0x03 on pci0.0.0 chip1: Intel 82443BX host to AGP bridge rev 0x03 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.4.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.4.1 chip3: Intel 82371AB Power management controller rev 0x02 on pci0.4.3 ahc0: Adaptec 2940 Ultra SCSI adapter rev 0x01 int a irq 10 on pci0.11.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs xl0: 3Com 3c905B-TX Fast Etherlink XL rev 0x30 int a irq 11 on pci0.12.0 xl0: Ethernet address: 00:50:04:e1:3c:4d xl0: autoneg complete, link status good (half-duplex, 100Mbps) Probing for devices on PCI bus 1: vga0: ATI model 4742 graphics accelerator rev 0x5c int a irq 11 on pci1.0.0 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 plip0: PLIP network interface on ppbus 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa wdc0: unit 0 (wd0): IBM-DTTA-371440, LBA, DMA, 32-bit, multi-block-16 wd0: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): IBM-DTTA-371440, LBA, DMA, 32-bit, multi-block-16 wd1: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0xb0ffb0ff on isa wdc1: unit 0 (wd2): IBM-DTTA-371440, LBA, DMA, 32-bit, multi-block-16 wd2: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc1: unit 1 (wd3): IBM-DTTA-371440, LBA, DMA, 32-bit, multi-block-16 wd3: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 5 seconds for SCSI devices to settle changing root device to wd0s1a da0 at ahc0 bus 0 target 3 lun 0 da0: IBM DNES-318350W SA30 Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 6 lun 0 da1: IBM DNES-318350W SA30 Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) vinum: loaded vinum: reading configuration from /dev/wd3e vinum: updating configuration from /dev/da0e vinum: updating configuration from /dev/da1e vinum: updating configuration from /dev/wd2e ## As you can see there are four 14.4 Gig IBM IDE drives, and 2 18Gig IBM SCSI drives. My vinum config is: drive scsi1 device /dev/da0e drive scsi2 device /dev/da1e drive ide1 device /dev/wd2e drive ide2 device /dev/wd3e volume exporthome plex org concat sd length 0 drive scsi1 sd length 0 drive scsi2 volume backup plex org concat sd length 0 drive ide1 sd length 0 drive ide2 SCSI # rawio -a -v 1 /dev/vinum/rexporthome TestID K/sec /sec %User%Sys %Total RR anon 1774.1 110 0.1 0.7 0.7 16384 SR anon 14482.7884 0.1 5.3 5.4 16384 RW anon 1573.7 98 0.1 0.6 0.6 16384 SW anon 1981.8 121 0.0 0.7 0.8 16384 /dev/rda0 is one of the raw drives in exporthome.. # rawio -a -v 1 /dev/rda0 TestID K/sec /sec %User%Sys %Total RR
Re: mmap mapped segment length
On Sat, 21 Aug 1999 02:10:47 -0600 Wes Peters [EMAIL PROTECTED] wrote: I discovered to my dismay today that the length field in the mmap call is a size_t, not an off_t. I was attempting to process a large (~50 MByte) file and found I was only processing the first 4 MBytes of it. ...first of all, I assume you mean GByte, not MByte. The type of the "len" argument is specified by multiple standards. You could change size_t to a 64-bit quantity, but then you have: (1) A serious ABI incompatibility issue with the rest of the x86 world. (2) You'd have to go to 64-bit arithmetic everywhere in the VM code which could seriously impact performance. Is this intentional, or just an artifact of the implementation? Is there any reason NOT to change this to an off_t? -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: from number to power of two
In message [EMAIL PROTECTED] Nick Hibma writes: : Does anyone know an inexpensive algorithm (O(1)) to go from an number to : the next (lower or higher) power of two. 1 ffs(x) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pthread_set_concurrency()
In message [EMAIL PROTECTED] Nate Williams writes: : Your definition of kernel threads and mine are obviously quite : different. :) True. The kernel "threads" are just process context that a task can run in Lots of thread-like things are missing... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: from number to power of two
Nick Hibma scribbled this message on Aug 21:
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3 - 2
4,5,6,7 - 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
hmmm how about:
int
fls(int n)
{
/* courtesy of fortune, of course this is O(lgn) */
/* swap the bits around */
n = ((n 1) 0x) | ((n 1) 0x);
n = ((n 2) 0x) | ((n 2) 0x);
n = ((n 4) 0x0f0f0f0f) | ((n 4) 0xf0f0f0f0);
n = ((n 8) 0x00ff00ff) | ((n 8) 0xff00ff00);
n = ((n 16) 0x) | ((n 16) 0x);
/* mask all but the lowest bit off */
n = n -n;
/* swap them back to where they were originally */
n = ((n 1) 0x) | ((n 1) 0x);
n = ((n 2) 0x) | ((n 2) 0x);
n = ((n 4) 0x0f0f0f0f) | ((n 4) 0xf0f0f0f0);
n = ((n 8) 0x00ff00ff) | ((n 8) 0xff00ff00);
n = ((n 16) 0x) | ((n 16) 0x);
return n;
}
now this is O(lgn) (where n is number of bits in an int), but I'm not
sure how this will perform wrt the other posting.. it probably won't be
that fast because of all the arithmetic that happens, and a binary search
of the number would probably be faster (which I have implemented a few
times)...
--
John-Mark Gurney Voice: +1 541 684 8449
Cu Networking P.O. Box 5693, 97405
"The soul contains in itself the event that shall presently befall it.
The event is only the actualizing of its thought." -- Ralph Waldo Emerson
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
Archie Cobbs wrote...
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
I think your modification would avoid the degeneration indicated
by Christopher Seiwald, but degrade the advantage for the dataset
sorted completely or sorted in reversed order, down to nearly
equal for random dataset.
I added a routine before selecting pivot to test current partition
sorted already and if so, to bypass partitioning. It works well
for dataset sorted in order, but doesn't work for dataset in
reversed order. I believe a reversed dataset would be partitioned
into two subpartitions sorted in order at the 1'st pass of
the partitionings. Is this incorrect ?
--
for qsort.c,v 1.9 1998/06/30 11:05:11
@@ -102,2 +102,5 @@
swap_cnt = 0;
+ pl = (char *)a; pn = (char *)a + (n - 1) * es;
+ while (pl pn cmp(pl, pl + es) = 0) pl += es;
+ if (pl = pn) return;
if (n 7) {
--
-Akira Wada
*
$BOBED!!IK(B $B!?(B Akira Wada
$BEl5~ETJ!@8;TIpB"LnBf(B 1-27-5 $B%k%MJ!@8(B B609
(tel,fax) 042-552-1143
E-mail : [EMAIL PROTECTED]
*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap mapped segment length
Don Lewis wrote: On Aug 21, 2:10am, Wes Peters wrote: } Subject: mmap mapped segment length } I discovered to my dismay today that the length field in the mmap call is } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file } and found I was only processing the first 4 MBytes of it. 50 MB should comfortably fit in a size_t. Oh, duh. Notice the time on my message? Yeah, that's what I get for jumping into a mailing list when I've been up for way too long. } Is this intentional, or just an artifact of the implementation? Is there any } reason NOT to change this to an off_t? The type of size_t is supposed to be large enough to express the length of any object that will fit in the virtual address space of a process. Since a size_t is 32 bits on an i386 and pointers are also 32 bits, there wouldn't be any advantage to changing mmap() to use a 64 bit wide length parameter, since you wouldn't be able to access all of such a large object. Obviously. I'm not sure which memory space my HEAD was in last night, the moment I read your message I realized size_t spans 4 GB. Duh. Sorry to embarass myself in such a public manner. Now I've got to go figure out what *I've* screwed up. I fstat the file before mapping it and pass S.st_size as the map length. Is there any reason why mmap would return non-NULL but map less than the requested size? Scratching my head, -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD voice synthesis
On Wed, Aug 18, 1999 at 03:44:56PM -0700, Brian F. Feldman wrote:
On Wed, 18 Aug 1999, Nik Clayton wrote:
On Tue, Aug 03, 1999 at 12:37:39AM -0700, Julian Elischer wrote:
Just fetched and compiled the "festival" package.
http://www.cstr.ed.ac.uk/projects/festival
Likewise, based on your comments.
Has anyone had any problems with the volume being far too low?
I cannot get this far. Festival only coredumps when I try to start it
up. Could you send me a description of how I can reproduce your exact
build of Festival?
did you compile with SHARED=1 with speech tools? that doesn't work on
freebsd.
--
BLINK ;for (74,1970500640,1634627444,1751478816,1348825708,543711587,
1801810465){for($x=11^1;$x=11;$x--) {$q=hex ff,$r=oct($x=~s,\d,$*
10,e,$x),$x/=1/.1,$q=$r,$s.=chr (($_$q)$r),$t++}}while(-r$0-e$0)
{$o=$o?$?:$/;$|=1;print $o?$s:$"x$t if$;;print"\b"x$t;sleep 1} /BLINK
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap mapped segment length
:Wes Peters scribbled this message on Aug 21: : Now I've got to go figure out what *I've* screwed up. I fstat the file before : mapping it and pass S.st_size as the map length. Is there any reason why : mmap would return non-NULL but map less than the requested size? : :no, there is NO reason why it wouldn't map the entire 50meg file... :I have used ffsrecov w/ a 1.8gig file where I fstat it and map the entire :file w/o a problem... : :also, mmap doesn't return NULL, it returns MAP_FAILED... : :the code for ffsrecov might give you some hints to make sure you aren't :doing anything wrong... : :-- : John-Mark Gurney Voice: +1 541 684 8449 : Cu Networking P.O. Box 5693, 97405 I would compile the program -Wall -Wstrict-prototypes. If you get warnings maybe the problem is that you've missed some important #include files. Many system calls take off_t arguments, including mmap, and without the correct prototype the compiler will not generate a good argument stack. mmap'ing a 50MB file definitely works. I run several databases which use mmap() that are several hundred megabytes in size. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap mapped segment length
:Now I've got to go figure out what *I've* screwed up. I fstat the file before :mapping it and pass S.st_size as the map length. Is there any reason why :mmap would return non-NULL but map less than the requested size? : :Scratching my head, Note that mmap() returns (void *)-1 when an error occurs, *not* NULL. This is because it is legal to mmap at address 0. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
Following my previous post: I wrote .. I believe a reversed dataset would be partitioned into two subpartitions sorted in order at the 1'st pass of the partitionings. Is this incorrect ? Sorry, I'd confirmed BSD qsort's partitioning logic does not guarantee that "a reversed dataset would be partitioned into two subpartitions sorted in order at the 1'st pass of the partitionings". -Akira Wada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I2C/SMBus/LPBB
I had sent this message to -stable about a month ago, never heard anything -- so am trying it here. -- Forwarded message -- Date: Wed, 21 Jul 1999 03:24:38 -0400 (EDT) From: Mike Nowlin m...@argos.org To: freebsd-sta...@freebsd.org Subject: I2C/SMBus/LPBB OK -- I give up I'm trying to get the LPBB I2C driver working on my 3.2-stable machine, CVSUP'd earlier today... I have tried about a zillion and two different config file combinations, and can not get it to work. The relevant parts of the config file are: device ppc0at isa? port? tty irq 7 controller pcf0at isa? port? irq 5 controller iicbb0 controller smbus0 device smb0at smbus? controller ppbus0 #device lpt0at ppbus? #device ppi0at ppbus? device lpbb0 at ppbus? controller iicbus0 device iic0at iicbus? device iicsmb0 at iicbus? (.As you can see, I took out the printer driver and the geek port during this hair-pulling session -- those two devices vanish, but nothing else appears.) The dmesg chunks that show up about this are: ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ... pcf0 at irq 5 on isa ... pcf0: PCF8584 I2C bus controller iicbus0: Philips I2C bus on pcf0 addr 0xaa iicsmb0: I2C to SMB bridge on iicbus0 smbus0: System Management Bus on iicsmb0 smb0: SMBus general purpose I/O on smbus0 iic0: I2C general purpose I/O on iicbus0 It seems to see the PCF8584 just fine, but it refuses to put the parallel port I2C interface in... If I remove the controller pcf0 line, all of the I2C drivers disappear. Any ideas? --Mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: device_add_child??
In message 199908210557.baa22...@cs.rpi.edu David E. Cross writes: : I have been writing a nasty kludge to treat a CardBus bridge as a standard : PCI bridge (with static config) you may start throwing rocks now. Ewe. Yuck. Wouldn't it be better to help the pccard/cardbus efforts :-) : I have : it to the point where I can (after the system is booted) 'pciconf -r : pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would : then just be a simple matter of 'device_add_child(dev, pci, 5, 0);' to get : the bus to show up at PCI5: at bootup, but it seems to ignore it. following : from pcisupport.c I also tried to 'bus_generic_attach()' it after : device_add_child() finished. no go. Any suggestions? device_add_child just adds it to the tree. It doesn't probe or attach it. If you kludge adding it into the tree, you'll have to kludge attaching it. You might want to look at my pccard kludge-o-matic for examples. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
:The problem that occurs on the FreeBSD server is simply that the :nfsrv_commit() procedure calls fsync() on the file... on the *ENTIRE* :file, for every commit rpc, rather then syncing just the offset/range :requested. I am looking into ways to fix this. : Ok, I've verified the problem. The nfsrv_commit() code running on the server is definitely the culprit. I was able to make a tentitive patch which increased NFSv3 write performance to 10 MBytes/sec -- the maximum my 100BaseTX network can do. CURRENT in tree:2.5 MBytes/sec CURRENT w/ asynchronized commit rpc:4.5 MBytes/sec CURRENT w/ asy commit and fixed nfsrv_commit: 10 MBytes/sec (1) note(1): network is maxed out. Running bonnie returned around 5.2 MBytes/sec using putc, 3.5 MBytes/sec doing rewrite (but also 3.5 MBytes/sec going the other way), and 10 MBytes/sec writing intelligently. Throughout the test the low level disk I/O on the server was able to do sustained clustering at 64KB/t. I have a backlog of patches so it may be a week or more before this one gets tested and committed into CURRENT. It's a little racey for putting into STABLE but maybe after a month of testing on CURRENT we will be able to do it. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
mmap mapped segment length
I discovered to my dismay today that the length field in the mmap call is a size_t, not an off_t. I was attempting to process a large (~50 MByte) file and found I was only processing the first 4 MBytes of it. Is this intentional, or just an artifact of the implementation? Is there any reason NOT to change this to an off_t? Granted, I'm no VM hacker, but I'm willing to take a swing at it if there is any interest in putting it into the system. Otherwise, I have a workaround that works just fine for this application. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mmap mapped segment length
On Aug 21, 2:10am, Wes Peters wrote: } Subject: mmap mapped segment length } I discovered to my dismay today that the length field in the mmap call is } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file } and found I was only processing the first 4 MBytes of it. 50 MB should comfortably fit in a size_t. } Is this intentional, or just an artifact of the implementation? Is there any } reason NOT to change this to an off_t? The type of size_t is supposed to be large enough to express the length of any object that will fit in the virtual address space of a process. Since a size_t is 32 bits on an i386 and pointers are also 32 bits, there wouldn't be any advantage to changing mmap() to use a 64 bit wide length parameter, since you wouldn't be able to access all of such a large object. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: device_add_child??
man 9 device_probe_and_attach Nick On Sat, 21 Aug 1999, Warner Losh wrote: In message 199908210557.baa22...@cs.rpi.edu David E. Cross writes: : I have been writing a nasty kludge to treat a CardBus bridge as a standard : PCI bridge (with static config) you may start throwing rocks now. Ewe. Yuck. Wouldn't it be better to help the pccard/cardbus efforts :-) : I have : it to the point where I can (after the system is booted) 'pciconf -r : pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would : then just be a simple matter of 'device_add_child(dev, pci, 5, 0);' to get : the bus to show up at PCI5: at bootup, but it seems to ignore it. following : from pcisupport.c I also tried to 'bus_generic_attach()' it after : device_add_child() finished. no go. Any suggestions? device_add_child just adds it to the tree. It doesn't probe or attach it. If you kludge adding it into the tree, you'll have to kludge attaching it. You might want to look at my pccard kludge-o-matic for examples. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: anybody love qsort.c?
You can check the change by recompiling a few utils with the change:
(find . -name \*.c | xargs grep -l qsort)
./bin/ps/ps.c
./contrib/gcc/*.c
./contrib/top/commands.c
./games/fortune/strfile/strfile.c
./gnu/usr.bin/sort/sort.c
./sbin/fsck/pass2.c
The fsck one is a nice one. Just wack your /usr and reboot :-)
Nick
On Fri, 20 Aug 1999, Archie Cobbs wrote:
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
--
e-Mail: hi...@skylink.it
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
Daniel C. Sobral wrote: Terry Lambert wrote: That's kind of the point. No other VFS stacking system out there plays by FreeBSD's revamped rules. I look around and I see no standards. It is still time to be experimental. Since someone complained of my meekness, let me restate that... :-) 1) BS. That was not your point. Your point, in which you spent many paragraphs, was that the present way FreeBSD things does it stuff cannot support passing a method through an intermediate host/fs that does not know it. If your point was the above, you could just have said no one else does it this way, so we won't be able to have non-FreeBSD intermediate/frontend/backend hosts. Only that does not prove that our way is not right. 2) There is *no* compatibility in the VFS out there. It's a jungle. If we implemented something compatible with anyone else, it would be a first. And given that everything out there have it's problems, it would be a huge mistake to adopt someone's standard just for the sake of being compatible. And if you disagree with point 2, feel free to argue against it. But in no way it will justify that absurd comment you made. Either that paragraph was trying to cover a flaw in your logic, or you just lost your train of thought. It certainly detracted from the content of the message. You must assume that the intermediate host doesn't play by your rules. Bah. [not that I don't generally agree with you more often than it would be prudent to let it be publicly known :-) ] -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mmap mapped segment length
Don Lewis said: On Aug 21, 2:10am, Wes Peters wrote: } Subject: mmap mapped segment length } I discovered to my dismay today that the length field in the mmap call is } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file } and found I was only processing the first 4 MBytes of it. 50 MB should comfortably fit in a size_t. It seems that 4MB and 4GB are being confused :-). John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Package creation without installation
-hackers, I'm playing around with the pkg_create(1) command at the moment, trying to get the creation of pre-built versions (HTML, PS, etc) of the FDP documentation working. One of the things I'm trying to do is *not* require that the doc that's being packaged up be installed first. For example, if I'm building the PS version of the FAQ then I can # pwd /tmp/niks-package-build-area # cd doc/en_US.ISO_8859-1/books/faq # make FORMATS=ps What I'd like to do is then create a package from this file, such that when it is installed it does not default to installing in to /tmp/niks-package-build-area/docs/en_US.ISO_8859-1/books/faq but instead defaults to installing somewhere under /usr/doc/.
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
So are there any _objections_ to having the kernel match promiscuous enabled messages with disabled counterparts? I strongly _request_ such a log message. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Kernel debugging questions
Zhihui Zhang zzh...@cs.binghamton.edu writes: Thanks for your response. I can not think of those points myself. However, on page 7 of the book Panic! Unix system crash dump analysis, it says that a debugger named kadb in SunOS can load the real kernel during boot and treat the latter like a great, big, user program, stepping through its execution, examining and modifying values on the fly. It seems to me that FreeBSD does not have such a debugger. Maybe ddb can do so, but it works with assembly. kadb also works with assembly. That being said, I much prefer ddb to kadb, and of course remote gdb is *much* nicer. /assar To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
from number to power of two
Does anyone know an inexpensive algorithm (O(1)) to go from an number to the next (lower or higher) power of two. 1 - 1 2,3 - 2 4,5,6,7 - 4 8,9,10,11,12,13,14,15 - 8 etc. So %1101 should become either %1 or %1000. The only solution I have so far is a table. That is a possibility as the the highest number will be 32 I think. Nick -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
DMA-able memory
How do I allocate DMA-able memory? Or is all memory DMA-able? Like so: #include machine/pmap.h dma_addr = vtophys(addr); The UHCI (and OHCI) USB controllers use DMA to access the queues with the TransferDescriptors and QueueHeads. This is going to be loads of small (4 to 32 byte) memory blocks. Nick -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
G'day Nick, Nick Hibma n_hi...@skylink.it wrote: Does anyone know an inexpensive algorithm (O(1)) to go from an number to the next (lower or higher) power of two. 1 - 1 2,3 - 2 4,5,6,7 - 4 8,9,10,11,12,13,14,15 - 8 etc. So %1101 should become either %1 or %1000. a bitwise shift left (to higher) or right (to lower) before or after masking out all but the most significant bit in the number. You just need to know how many bits to mask based on where the most significant bit is ;] I was tempted to throw something together but its late, and the idea should be enough to go on ... Cheers Leigh -- | By the time they had diminished | Leigh Hart, h...@dotat.com | | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | | began to suspect 'Hungry' ... | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, The Far Side | http://www.dotat.com/hart/ | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
Does anyone know an inexpensive algorithm (O(1)) to go from an number to the next (lower or higher) power of two. 1 - 1 2,3 - 2 4,5,6,7 - 4 8,9,10,11,12,13,14,15 - 8 etc. So %1101 should become either %1 or %1000. The only solution I have so far is a table. That is a possibility as the the highest number will be 32 I think. The kernel uses a 'ffs()' function for that but i seem to remember that some processors have this one as a machine instruction. ffs() is declared in /sys/sys/libkern.h and implemented in /sys/libkern/ffs.c but maybe there is an assembly version somewherewhich i can't find. cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3 - 2
4,5,6,7 - 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
Nick,
Probably the best solution I can think of is a binary search on the
number. I'd estimate it as better than a table, as you save on memory
references (tables sound cool, but, from experience, they cause enough
extra data cache misses to kill any advantage, even in
a highly-optimized inner loop.
For 8-bit integets, a quick solution is:
int
round_up(int x)
{
if (x 0xf0) {
if (x 0xc0)
return (x 0x80) ? 0x80 : 0x40;
else {
return (x 0x20) ? 0x20 : 0x10;
}
}
else {
if (x 0xc)
return (x 0x8) ? 0x8 : 0x4;
else {
return (x 0x2) ? 0x2 : 0x1;
}
}
}
It's actually faster than the BSF/BSR operations on Pentium (and the
ffs() libc function), as Pentium does a sequential search of the bit
string and therefore is O(n) (eek!)
The innermost comparison could probably be avoided if it wasn't 00:37
or if I didn't have to get up early in the morning. You could also
combine that with a smaller lookup table to get the best of both
worlds.
Patryk.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
ATX power supplies
Anyone know where the spec might be for how ATX power supplies work (especially the interface to the motherboard, and their on'off methods?) Thanks. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ATX power supplies
At 12:29 PM 8/21/99 -0400, Chuck Robey wrote: Anyone know where the spec might be for how ATX power supplies work (especially the interface to the motherboard, and their on'off methods?) Thanks. ftp://download.intel.com/design/motherbd/atx_201.pdf See section 4.2 Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ATX power supplies
On Sat, 21 Aug 1999, Kevin Day wrote: At 12:29 PM 8/21/99 -0400, Chuck Robey wrote: Anyone know where the spec might be for how ATX power supplies work (especially the interface to the motherboard, and their on'off methods?) Thanks. ftp://download.intel.com/design/motherbd/atx_201.pdf That's just what I wanted, thanks (also to Len, who sent something seconds later). I have to troubleshoot something. Time to get the trusty VOM out. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Questions for vnconfig
I have successfully used vnconfig to add swap file and mount disk image files. However, I am still not sure about the following two things: (1) What does the count in pseudo-device vn count stand for? My guess is that if it is 2, then we can use /dev/vn0x and /dev/vn1x. If it is 1, then we can only use /dev/vn0x. The x stands for one of those eight partitions [a-h] in one slice. (2) For /dev/vn0[a-h], which one from a-h should I use for which purpose? Any help is appreciated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
At Sat, 21 Aug 1999 12:54:32 +0200, Nick Hibma wrote:
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3- 2
4,5,6,7- 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
This small prog works at least on x86
=
#include sys/types.h
#include machine/cpufunc.h
int
main(int argc, char **argv){
int i, j, k;
sscanf(argv[1], %d, i);
j = 1(fls(i)-1);
k = 1(fls(i-1));
printf(%d %d %d\n, j, i, k);
return 0;
}
=
/Johan K
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: pthread_set_concurrency()
According to Nate Williams: FreeBSD has no kernel 'thread' support, only user level. That's not strictly true. The fact is we have both kernel and user threads but no mapping between the two... The kernel already internally use some threads. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: pthread_set_concurrency()
FreeBSD has no kernel 'thread' support, only user level. That's not strictly true. The fact is we have both kernel and user threads but no mapping between the two... The kernel already internally use some threads. Your definition of kernel threads and mine are obviously quite different. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
SCSI vs IDE with vinum
I just setup vinum for the first time on a brand new server, nd I am getting what I think are strange results in performance tests with rawio. My SCSI drives seem to be much slower that my IDE drives? Here is a dmesg from the machine: ### Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Sat Aug 21 06:52:28 MDT 1999 r...@temple.guild.ab.ca:/usr/src/sys/compile/GUILD1 Timecounter i8254 frequency 1193182 Hz CPU: Pentium III (451.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,b25 real memory = 268435456 (262144K bytes) avail memory = 257900544 (251856K bytes) Preloaded elf kernel kernel at 0xc0332000. Probing for devices on PCI bus 0: chip0: Intel 82443BX host to PCI bridge rev 0x03 on pci0.0.0 chip1: Intel 82443BX host to AGP bridge rev 0x03 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.4.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.4.1 chip3: Intel 82371AB Power management controller rev 0x02 on pci0.4.3 ahc0: Adaptec 2940 Ultra SCSI adapter rev 0x01 int a irq 10 on pci0.11.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs xl0: 3Com 3c905B-TX Fast Etherlink XL rev 0x30 int a irq 11 on pci0.12.0 xl0: Ethernet address: 00:50:04:e1:3c:4d xl0: autoneg complete, link status good (half-duplex, 100Mbps) Probing for devices on PCI bus 1: vga0: ATI model 4742 graphics accelerator rev 0x5c int a irq 11 on pci1.0.0 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 plip0: PLIP network interface on ppbus 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa wdc0: unit 0 (wd0): IBM-DTTA-371440, LBA, DMA, 32-bit, multi-block-16 wd0: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): IBM-DTTA-371440, LBA, DMA, 32-bit, multi-block-16 wd1: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0xb0ffb0ff on isa wdc1: unit 0 (wd2): IBM-DTTA-371440, LBA, DMA, 32-bit, multi-block-16 wd2: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S wdc1: unit 1 (wd3): IBM-DTTA-371440, LBA, DMA, 32-bit, multi-block-16 wd3: 13783MB (28229040 sectors), 1757 cyls, 255 heads, 63 S/T, 512 B/S vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 5 seconds for SCSI devices to settle changing root device to wd0s1a da0 at ahc0 bus 0 target 3 lun 0 da0: IBM DNES-318350W SA30 Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 6 lun 0 da1: IBM DNES-318350W SA30 Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) vinum: loaded vinum: reading configuration from /dev/wd3e vinum: updating configuration from /dev/da0e vinum: updating configuration from /dev/da1e vinum: updating configuration from /dev/wd2e ## As you can see there are four 14.4 Gig IBM IDE drives, and 2 18Gig IBM SCSI drives. My vinum config is: drive scsi1 device /dev/da0e drive scsi2 device /dev/da1e drive ide1 device /dev/wd2e drive ide2 device /dev/wd3e volume exporthome plex org concat sd length 0 drive scsi1 sd length 0 drive scsi2 volume backup plex org concat sd length 0 drive ide1 sd length 0 drive ide2 SCSI # rawio -a -v 1 /dev/vinum/rexporthome TestID K/sec /sec %User%Sys %Total RR anon 1774.1 110 0.1 0.7 0.7 16384 SR anon 14482.7884 0.1 5.3 5.4 16384 RW anon 1573.7 98 0.1 0.6 0.6 16384 SW anon 1981.8 121 0.0 0.7 0.8 16384 /dev/rda0 is one of the raw drives in exporthome.. # rawio -a -v 1 /dev/rda0 TestID K/sec /sec %User%Sys %Total RR
Re: mmap mapped segment length
On Sat, 21 Aug 1999 02:10:47 -0600 Wes Peters w...@softweyr.com wrote: I discovered to my dismay today that the length field in the mmap call is a size_t, not an off_t. I was attempting to process a large (~50 MByte) file and found I was only processing the first 4 MBytes of it. ...first of all, I assume you mean GByte, not MByte. The type of the len argument is specified by multiple standards. You could change size_t to a 64-bit quantity, but then you have: (1) A serious ABI incompatibility issue with the rest of the x86 world. (2) You'd have to go to 64-bit arithmetic everywhere in the VM code which could seriously impact performance. Is this intentional, or just an artifact of the implementation? Is there any reason NOT to change this to an off_t? -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: from number to power of two
On 21-Aug-99 Nick Hibma wrote:
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3 - 2
4,5,6,7 - 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
a bit of fiddling around gives:
int pw2(register unsigned i) {
register unsigned cnt=1;
do {
i = 1;
cnt =1;
/* printf([%x %x],,i, cnt); */
} while (i);
/* return(cnt) /* higher */
return( cnt 1); /* in bound */
/* return(cnt 2); /* lower */
}
Prolly should do boundry check for case 0 : 0 - 0 ? 0 - 1.
Regards,
---
Don Read dr...@calcasieu.com
EDP Manager dr...@texas.net
Calcasieu Lumber Co. Austin TX
-- But I'm in good company, sendmail has kicked a great many
butts in the past
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
In message pine.bsf.4.10.9908211250310.7595-100...@heidi.plazza.it Nick Hibma writes: : Does anyone know an inexpensive algorithm (O(1)) to go from an number to : the next (lower or higher) power of two. 1 ffs(x) Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: pthread_set_concurrency()
In message 199908211739.laa20...@mt.sri.com Nate Williams writes: : Your definition of kernel threads and mine are obviously quite : different. :) True. The kernel threads are just process context that a task can run in Lots of thread-like things are missing... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mmap mapped segment length
Wes Peters scribbled this message on Aug 21: I discovered to my dismay today that the length field in the mmap call is a size_t, not an off_t. I was attempting to process a large (~50 MByte) file and found I was only processing the first 4 MBytes of it. as w/ others I'm assuming the file is 50gigs and you can only use map the first 4gigs... Is this intentional, or just an artifact of the implementation? Is there any reason NOT to change this to an off_t? Granted, I'm no VM hacker, but I'm willing to take a swing at it if there is any interest in putting it into the system. Otherwise, I have a workaround that works just fine for this application. I'm sure that you will find that if you try to map the first 4gigs of the file that it will not fit into memory, and the mapping will fail.. do what you are suppose to do, map 2gigs or so of it (I've mapped 1.8gigs w/o problems before on x86), work with it, then map the next 2gigs and so on... just use the offset to specify where in the file you want to map... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought. -- Ralph Waldo Emerson To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
Nick Hibma scribbled this message on Aug 21:
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3 - 2
4,5,6,7 - 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
hmmm how about:
int
fls(int n)
{
/* courtesy of fortune, of course this is O(lgn) */
/* swap the bits around */
n = ((n 1) 0x) | ((n 1) 0x);
n = ((n 2) 0x) | ((n 2) 0x);
n = ((n 4) 0x0f0f0f0f) | ((n 4) 0xf0f0f0f0);
n = ((n 8) 0x00ff00ff) | ((n 8) 0xff00ff00);
n = ((n 16) 0x) | ((n 16) 0x);
/* mask all but the lowest bit off */
n = n -n;
/* swap them back to where they were originally */
n = ((n 1) 0x) | ((n 1) 0x);
n = ((n 2) 0x) | ((n 2) 0x);
n = ((n 4) 0x0f0f0f0f) | ((n 4) 0xf0f0f0f0);
n = ((n 8) 0x00ff00ff) | ((n 8) 0xff00ff00);
n = ((n 16) 0x) | ((n 16) 0x);
return n;
}
now this is O(lgn) (where n is number of bits in an int), but I'm not
sure how this will perform wrt the other posting.. it probably won't be
that fast because of all the arithmetic that happens, and a binary search
of the number would probably be faster (which I have implemented a few
times)...
--
John-Mark Gurney Voice: +1 541 684 8449
Cu Networking P.O. Box 5693, 97405
The soul contains in itself the event that shall presently befall it.
The event is only the actualizing of its thought. -- Ralph Waldo Emerson
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: anybody love qsort.c?
Archie Cobbs wrote...
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
I think your modification would avoid the degeneration indicated
by Christopher Seiwald, but degrade the advantage for the dataset
sorted completely or sorted in reversed order, down to nearly
equal for random dataset.
I added a routine before selecting pivot to test current partition
sorted already and if so, to bypass partitioning. It works well
for dataset sorted in order, but doesn't work for dataset in
reversed order. I believe a reversed dataset would be partitioned
into two subpartitions sorted in order at the 1'st pass of
the partitionigs. Is this incorrect ?
--
for qsort.c,v 1.9 1998/06/30 11:05:11
@@ -102,2 +102,5 @@
swap_cnt = 0;
+ pl = (char *)a; pn = (char *)a + (n - 1) * es;
+ while (pl pn cmp(pl, pl + es) pl += es;
+ if (pl = pn) return;
if (n 7) {
--
-Akira Wada
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: anybody love qsort.c?
Archie Cobbs wrote...
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
I think your modification would avoid the degeneration indicated
by Christopher Seiwald, but degrade the advantage for the dataset
sorted completely or sorted in reversed order, down to nearly
equal for random dataset.
I added a routine before selecting pivot to test current partition
sorted already and if so, to bypass partitioning. It works well
for dataset sorted in order, but doesn't work for dataset in
reversed order. I believe a reversed dataset would be partitioned
into two subpartitions sorted in order at the 1'st pass of
the partitionings. Is this incorrect ?
--
for qsort.c,v 1.9 1998/06/30 11:05:11
@@ -102,2 +102,5 @@
swap_cnt = 0;
+ pl = (char *)a; pn = (char *)a + (n - 1) * es;
+ while (pl pn cmp(pl, pl + es) = 0) pl += es;
+ if (pl = pn) return;
if (n 7) {
--
-Akira Wada
*
和田 彬 ／ Akira Wada
東京都福生市武蔵野台 1-27-5 ルネ福生 B609
(tel,fax) 042-552-1143
E-mail : a-w...@mars.dti.ne.jp
*
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: mmap mapped segment length
Don Lewis wrote: On Aug 21, 2:10am, Wes Peters wrote: } Subject: mmap mapped segment length } I discovered to my dismay today that the length field in the mmap call is } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file } and found I was only processing the first 4 MBytes of it. 50 MB should comfortably fit in a size_t. Oh, duh. Notice the time on my message? Yeah, that's what I get for jumping into a mailing list when I've been up for way too long. } Is this intentional, or just an artifact of the implementation? Is there any } reason NOT to change this to an off_t? The type of size_t is supposed to be large enough to express the length of any object that will fit in the virtual address space of a process. Since a size_t is 32 bits on an i386 and pointers are also 32 bits, there wouldn't be any advantage to changing mmap() to use a 64 bit wide length parameter, since you wouldn't be able to access all of such a large object. Obviously. I'm not sure which memory space my HEAD was in last night, the moment I read your message I realized size_t spans 4 GB. Duh. Sorry to embarass myself in such a public manner. Now I've got to go figure out what *I've* screwed up. I fstat the file before mapping it and pass S.st_size as the map length. Is there any reason why mmap would return non-NULL but map less than the requested size? Scratching my head, -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mmap mapped segment length
Wes Peters scribbled this message on Aug 21: Now I've got to go figure out what *I've* screwed up. I fstat the file before mapping it and pass S.st_size as the map length. Is there any reason why mmap would return non-NULL but map less than the requested size? no, there is NO reason why it wouldn't map the entire 50meg file... I have used ffsrecov w/ a 1.8gig file where I fstat it and map the entire file w/o a problem... also, mmap doesn't return NULL, it returns MAP_FAILED... the code for ffsrecov might give you some hints to make sure you aren't doing anything wrong... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought. -- Ralph Waldo Emerson To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD voice synthesis
On Wed, Aug 18, 1999 at 03:44:56PM -0700, Brian F. Feldman wrote:
On Wed, 18 Aug 1999, Nik Clayton wrote:
On Tue, Aug 03, 1999 at 12:37:39AM -0700, Julian Elischer wrote:
Just fetched and compiled the festival package.
http://www.cstr.ed.ac.uk/projects/festival
Likewise, based on your comments.
Has anyone had any problems with the volume being far too low?
I cannot get this far. Festival only coredumps when I try to start it
up. Could you send me a description of how I can reproduce your exact
build of Festival?
did you compile with SHARED=1 with speech tools? that doesn't work on
freebsd.
--
BLINK ;for (74,1970500640,1634627444,1751478816,1348825708,543711587,
1801810465){for($x=11^1;$x=11;$x--) {$q=hex ff,$r=oct($x=~s,\d,$*
10,e,$x),$x/=1/.1,$q=$r,$s.=chr (($_$q)$r),$t++}}while(-r$0-e$0)
{$o=$o?$?:$/;$|=1;print $o?$s:$x$t if$;;print\bx$t;sleep 1} /BLINK
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: mmap mapped segment length
:Wes Peters scribbled this message on Aug 21: : Now I've got to go figure out what *I've* screwed up. I fstat the file before : mapping it and pass S.st_size as the map length. Is there any reason why : mmap would return non-NULL but map less than the requested size? : :no, there is NO reason why it wouldn't map the entire 50meg file... :I have used ffsrecov w/ a 1.8gig file where I fstat it and map the entire :file w/o a problem... : :also, mmap doesn't return NULL, it returns MAP_FAILED... : :the code for ffsrecov might give you some hints to make sure you aren't :doing anything wrong... : :-- : John-Mark Gurney Voice: +1 541 684 8449 : Cu Networking P.O. Box 5693, 97405 I would compile the program -Wall -Wstrict-prototypes. If you get warnings maybe the problem is that you've missed some important #include files. Many system calls take off_t arguments, including mmap, and without the correct prototype the compiler will not generate a good argument stack. mmap'ing a 50MB file definitely works. I run several databases which use mmap() that are several hundred megabytes in size. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mmap mapped segment length
:Now I've got to go figure out what *I've* screwed up. I fstat the file before :mapping it and pass S.st_size as the map length. Is there any reason why :mmap would return non-NULL but map less than the requested size? : :Scratching my head, Note that mmap() returns (void *)-1 when an error occurs, *not* NULL. This is because it is legal to mmap at address 0. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
