Re: config(8) putting (null) into config files
I am trying to get my laptop's config file as clean as possible
and one of the lines I experimented with is:
controller fdc0 at isa? disable port ? bio
(notice the lack of an irq and the wildcarding of at isa).
This results in a line in ioconf.c of:
{ 10, fdcdriver, (null), 0, -1, C 0x0, 0, 0, 0, 0x,
0,0, 0, 0, 0,0, 0 },
Notice the (null). I want the line in my config file to be like that
as I do not use the floppy drive very often, and I am quite content for
it to be kicked into action by pccardd when I plug it in. So my config
line above is just a device placeholder. The (null) causes a compile
failure, which is fixed by the kluge below. Is there a better way of
doing this, or is this OK to commit?
There is a better way. Copy the correct code for printing d_port and
d_portn from isa_devtab() to isa_biotab(), and while your're there,
check for other lossage in isa_biotab(). The current code also screws
up cases where the token following port is a number. Only the case
where it is a macro name works.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: locale errors
J Wunsch schrieb: As Andrey A. Chernov wrote: I suggest removing any multi character definition out of the collate files. It was Joerg initiative, I don't know DE enough to judge here. Please resolve this problem with him (CC'ed). Well, not completely. :) For testing, i've restored the file from before my change, and it missorts similarly. I'm probably too stupid to understand all of this collate stuff. So far, i haven't been able to come up with any locale definition that does the right thing for every input. To make matters worse, German doesn't even have a single collate defintion at all. There are at least two dissenting definitions: one is the phonebook sorting order, and the other one (certainly more widely accepted and thus should be the base of our collate definition) the `Duden' (German dictionary). According to my Duden, the following words Maße Maßeinheit Masse Massaua Massel should be sorted like: Massaua Maße Masse Maßeinheit Massel If anybody could come up with a set of collate definition files that does this, it probably would be the right thing. ;) Maybe it's simply impossible to express using the current collate stuff? It is impossible. The collate couldn't detect concatenated words, which sould sort the usual way: aussetzen austreiben (just a simple example) I noticed the difference while looking into the /R/dist/src directory during a make release. ssys.XX was sorted behind susrbin.XX in ls output. I suggest just backing out the stuff with multi character locale settings because it is bogus. We should just use the simple phonebook sorting, because it is easier to implement, and the people are more familiar with it. Duden isn't always right (very true since last year for some parts in northern Germany) Daniel P.S. Solaris does sorting the easy way (at least for LC_COLLATE=de.ISO8859-15 and LC_COLLATE=de) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: OBJLINK=yes breaks make buildworld
I don't have a fix. I never use OBJLINK. As far as I'm concerned, a suitable fix would be to eliminate that option altogether. As far as I'm concerned, and speaking as the author of that hack, I agree with you! :-) Kill it. Kill it dead. I use it a lot for working in individual directories. It shouldn't be killed until the separate object tree is killed. `make's search path should be set on the command line (default .) so that obj subdirectories, obj links, and /usr/obj/ can be ignored. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up: comitted optimization to vm_map_insert()
On Wed, 3 Feb 1999, Matthew Dillon wrote: : the test ). I think the seg fault may have revealed a new : bug and is not related to the optimization I comitted, so I : haven't backed out the commit. I am not 100% sure though, : and I am testing this now. : : What test? If we had this exact test, it could be exploiting the exact bug, :could it not? I'll let you know of any weird crashes in previously stable :programs. My do lots of things that force the machine to page up the wazoo and try to make it crash test :-) So do you run Netscape, or do you run StarOffice? ;) -Matt Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: locale errors
-Original Message- From: D. Rock [SMTP:r...@cs.uni-sb.de] Sent: Thursday, February 04, 1999 10:36 AM To: Joerg Wunsch Cc: Andrey A. Chernov; curr...@freebsd.org Subject: Re: locale errors It is impossible. The collate couldn't detect concatenated words, which sould sort the usual way: aussetzen austreiben (just a simple example) [ML] Shouldn't ß (scharfes-s, sz) be collated as SZ which it really is? /Marino I noticed the difference while looking into the /R/dist/src directory during a make release. ssys.XX was sorted behind susrbin.XX in ls output. I suggest just backing out the stuff with multi character locale settings because it is bogus. We should just use the simple phonebook sorting, because it is easier to implement, and the people are more familiar with it. Duden isn't always right (very true since last year for some parts in northern Germany) Daniel P.S. Solaris does sorting the easy way (at least for LC_COLLATE=de.ISO8859-15 and LC_COLLATE=de) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: locale errors
Ladavac Marino schrieb: -Original Message- From: D. Rock [SMTP:r...@cs.uni-sb.de] Sent: Thursday, February 04, 1999 10:36 AM To: Joerg Wunsch Cc: Andrey A. Chernov; curr...@freebsd.org Subject: Re: locale errors It is impossible. The collate couldn't detect concatenated words, which sould sort the usual way: aussetzen austreiben (just a simple example) [ML] Shouldn't ß (scharfes-s, sz) be collated as SZ which it really is? /Marino You will still get into the same problem (Auszeit) Also Duden explicitly states, sz should be only used as a last resort, to avoid misinterpretation. But the original example shows that Duden suggests treating ss and ß equal in sorting. Introducing sz just produces additional confusion. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Boot block problem
Mike Smith wrote: [Archie Cobbs wrote:] Just upgraded to 3.0-stable snapshot circa 2/1 and noticed that the new booteasy does not seem to remember the selection from the previous time. Eg., I need to press F5 to get to disk 2 but it always defaults to F2 (which is FreeBSD slice containing only a swap partition). This means my box won't reboot automatically anymore, e.g., if the power goes out. Is this a new bug or a new feature? :-) It's supposed to work, and it does for me here. Check you haven't got your BIOS 'boot virus protection' stuff enabled, then talk to Robert Nordier (in that order 8). No need to talk to me: I'll talk to you instead. :) The new boot manager remembers last slice selected rather than last menu option selected on each drive. I think I prefer this behavior myself, but I'll change it for compatibility with booteasy. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network Cards
Rod Taylor wrote: I've often wondered this, but why is it that every network card has a different 'name'. xl0, rl0, vr0, ed0, etc. etc. etc I tried simlinking them to a common name (I have xl0, rl0, and ed0 active in my current machine). linked to eth0, eth1, eth2 (didn't work). However, it would be nice if they all had a common name to the end user.. Primarily, me.. Especially when you rip out one card, install another, then the name changes on you... Suppose you have xl and vr in your computer. They are named eth0 and eth1, respectively. You then replace your vr by a ed. Mark with an X the correct option: ( ) the names for vr and ed will be eth0 and eth1, respectively. ( ) the names for vr and ed will be eth1 and eth0, respectively. ( ) none of the above Can you see what I'm getting at here? :-) The best solution would be hardwiring the names, but in that case it doesn't matter what are the default names. -- Daniel C. Sobral(8-DCS) d...@newsguy.com She just looked at him over the rotating pencil like, how slow can a mammal be and still have respiratory functions? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network Cards
But then if I added another say ed0, it wouldn't get eth2 :) But yeah, I understand where you're going... However, it would be nice if they all had a common name to the end user.. Primarily, me.. Especially when you rip out one card, install another, then the name changes on you... Suppose you have xl and vr in your computer. They are named eth0 and eth1, respectively. You then replace your vr by a ed. Mark with an X the correct option: ( ) the names for vr and ed will be eth0 and eth1, respectively. ( ) the names for vr and ed will be eth1 and eth0, respectively. ( ) none of the above Can you see what I'm getting at here? :-) The best solution would be hardwiring the names, but in that case it doesn't matter what are the default names. -- Daniel C. Sobral (8-DCS) d...@newsguy.com She just looked at him over the rotating pencil like, how slow can a mammal be and still have respiratory functions? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Rod Taylor Proud Member of Team OS/2 User of FreeBSD KDE To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network Cards
On Thu, 4 Feb 1999, Daniel C. Sobral wrote: Rod Taylor wrote: I've often wondered this, but why is it that every network card has a different 'name'. xl0, rl0, vr0, ed0, etc. etc. etc The best solution would be hardwiring the names, but in that case it doesn't matter what are the default names. Yes. Hardwiring is the only appropriate solution. It should be done as a part of the loader kernel configuration. Perhaps it should work somewhat like the SCSI disk partitions. Unspecified interfaces get the next available slot. However, and this is the important point, it is very useful to be able to assign an identifier to the logical interface and have that identifier appear in EVERY reference to the interface. I would like to hardwire 00:aa:bb:cc:dd:ee which uses the vr driver to eth23 and have ifconfig accept and report the device as 'eth23'. The actual driver is parenthetical. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
panic: vm_object_qcollapse(): object mismatch
Hardware: 486DX2/66 16Mb ram, aha1542CF, 2x1Gb SCSI disks
Software: 4.0-current 1-2 days old, softupdates
(vm_map.c is at rev 1.146, for example)
I was running 'make -j5 buildworld'. It swaps like crazy when I do this. :-)
Here's what gdb -k tells me:
...
#9 0xf01425e0 in panic (
fmt=0xf0225c1f vm_object_qcollapse(): object mismatch)
at ../../kern/kern_shutdown.c:446
#10 0xf01e0772 in vm_object_qcollapse (object=0xf2f001d0)
at ../../vm/vm_object.c:1011
#11 0xf01e08d6 in vm_object_collapse (object=0xf2f001d0)
at ../../vm/vm_object.c:1102
#12 0xf01ddae2 in vm_map_copy_entry (src_map=0xf2f4aa00, dst_map=0xf2f4ad00,
src_entry=0xf2ed0e10, dst_entry=0xf2f8edc0) at ../../vm/vm_map.c:2284
#13 0xf01ddd73 in vmspace_fork (vm1=0xf2f4aa00) at ../../vm/vm_map.c:2411
#14 0xf01da833 in vm_fork (p1=0xf2f7db20, p2=0xf2d751e0, flags=20)
at ../../vm/vm_glue.c:231
#15 0xf013d4f0 in fork1 (p1=0xf2f7db20, flags=20) at ../../kern/kern_fork.c:447
#16 0xf013ce65 in fork (p=0xf2f7db20, uap=0xf3021f94)
at ../../kern/kern_fork.c:99
#17 0xf01fe783 in syscall (frame={tf_es = 134807599, tf_ds = -272695249,
tf_edi = 134750909, tf_esi = 134935201, tf_ebp = -272643652,
tf_isp = -217964572, tf_ebx = 4, tf_edx = 672250004, tf_ecx = 19,
tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 671826564, tf_cs = 31,
tf_eflags = 662, tf_esp = -272651296, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#18 0xf01f4e9c in Xint0x80_syscall ()
...
(kgdb) p *p
$1 = {pageq = {tqe_next = 0xf02c5240, tqe_prev = 0xf02e4e00}, hnext = 0x0,
listq = {tqe_next = 0xf02e59d0, tqe_prev = 0xf2f69cc8}, object = 0xf2f69cb0,
pindex = 30, phys_addr = 15065088, queue = 4, flags = 1, pc = 0,
wire_count = 0, hold_count = 0, act_count = 27 '\e', busy = 0 '\000',
valid = 255 'ÿ', dirty = 255 'ÿ'}
(kgdb) p object
$2 = (struct vm_object *) 0xf2f001d0
(kgdb) p *object
$3 = {object_list = {tqe_next = 0xf2fdc2b8, tqe_prev = 0xf2f69c3c},
shadow_head = {tqh_first = 0x0, tqh_last = 0xf2f001d8}, shadow_list = {
tqe_next = 0x0, tqe_prev = 0xf2f69cb8}, memq = {tqh_first = 0xf02dbcb0,
tqh_last = 0xf02cc86c}, generation = 11690, type = OBJT_DEFAULT,
size = 32, ref_count = 2, shadow_count = 0, pg_color = 0,
hash_rand = -136756254, flags = 8576, paging_in_progress = 0, behavior = 0,
resident_page_count = 6, cache_count = 0, wire_count = 0,
backing_object = 0xf2f69cb0, backing_object_offset = 0x,
last_read = 0, pager_object_list = {tqe_next = 0xf2f69000,
tqe_prev = 0xf0252f10}, handle = 0x0, un_pager = {vnp = {
vnp_size = 0x}, devp = {devp_pglist = {tqh_first = 0x0,
tqh_last = 0x0}}, swp = {swp_bcount = 0}}}
(kgdb) p *(p-object)
$4 = {object_list = {tqe_next = 0xf2f915e4, tqe_prev = 0xf30fd0e8},
shadow_head = {tqh_first = 0xf2f001d0, tqh_last = 0xf2f001e0},
shadow_list = {tqe_next = 0x0, tqe_prev = 0xf30fef04}, memq = {
tqh_first = 0xf02e7170, tqh_last = 0xf02cff5c}, generation = 10219,
type = OBJT_SWAP, size = 32, ref_count = 3, shadow_count = 1, pg_color = 0,
hash_rand = -136000830, flags = 384, paging_in_progress = 0, behavior = 0,
resident_page_count = 4, cache_count = 1, wire_count = 0,
backing_object = 0x0, backing_object_offset = 0x,
last_read = 29, pager_object_list = {tqe_next = 0xf30fad24,
tqe_prev = 0xf30f0814}, handle = 0x0, un_pager = {vnp = {
vnp_size = 0x0001}, devp = {devp_pglist = {tqh_first = 0x1,
tqh_last = 0x0}}, swp = {swp_bcount = 1}}}
I'll keep this dump around. What other details do people want?
I'm not likely to even get to look at this let alone solve it. Bummer.
Stephen.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How do I query system temperature probes ?
In message 36b8ea32.d5105...@dsto.defence.gov.au, Matthew Thyer wrote: Thanks, Takanori, are you going to commit your example code in say /usr/src/share/examples/smbus ? If not can you send me a copy please ? I'll announce about it in current list also. I'm sorry if you see this twice. Message-Id: 199901251651.baa27...@shidahara1.planet.sci.kobe-u.ac.jp To: hack...@freebsd.org Subject: Some SMBus Stuffs. Date: Tue, 26 Jan 1999 01:51:13 +0900 From: Takanori Watanabe takaw...@shidahara1.planet.sci.kobe-u.ac.jp The driver for SMBus on Intel PIIX4 Power Management Controller has been commited. Now, I have some examples for SMBus application. It is available at http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ . (snip) Takanori Watanabe a href=http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html; Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
CALL FOR REVIEW: man page update
In order to reflect the recent changes regarding syscons, keyboard and video drivers, I wrote the following new man pages and update for a couple of existing ones. They are rudimentary, but better than nothing. http://www.freebsd.org/~yokota/man4update.tar.gz New pages: atkbd.4 atkbdc.4 splash.4 (screensaver.4) vga.4 Updated pages: pcvt.4 psm.4 (The tar.gz file includes doc-syms.diff, which should be applied to /usr/share/tmac/mdoc/doc-syms too.) Would you please, please review these man pages and correct my poor English. Please send me any suggestions and addition for them too. I would like to finish them in time for 3.1-RELEASE. I appreciate your help. Thank you. Kazu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Snapshots and Netscape
Just FYI, I don't know if anyone else has experienced this problem or if it was only with 3.0-19990128-SNAP. I found that if you use sysinstall to install a snapshot then you can't build Netscape 4..08 or 4.5 (Communicator or standalone). It dies in vreg (also when trying to start Netscape withoutt having run vreg) looking for ld.so. I cvsup'ed to 3.0-STABLE as of last night and everything worked. Kelly -- Kelly YanceyBill Gates is only a white Persian cat and ~kby...@freedomnet.com~ a monocle away from being the villain in a James Bond movie - comedian Dennis Miller To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ifq_maxlen problem...
After yesterdays 'make world' I am having such warnings: FreeBSD 4.0-CURRENT #0: Thu Feb 4 17:19:09 GMT 1999 jar...@ent.freebsd.org.pl:/usr/src/sys/compile/ENT [...] ep0 at 0x300-0x30f irq 10 on isa ep0: utp/bnc[*UTP*] address 00:60:08:65:d6:8d [...] ep0 XXX: driver didn't set ifq_maxlen lo0 XXX: driver didn't set ifq_maxlen ^ The system itself seems to work fine (for last 24 hrs). What do those messages mean??? Does anyone of you noticed similar messages??? The NIC is 3com 3c509B. Greetings -- Jaroslaw Bazydlo | mailto:jar...@freebsd.org.pl | http://www.freebsd.org.pl/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Boot block problem
The new boot manager remembers last slice selected rather than last menu option selected on each drive. I think I prefer this behavior myself, but I'll change it for compatibility with booteasy. In the case where the last action was to chain to another disk, that's definitely preferable... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network Cards
Rod Taylor wrote: I've often wondered this, but why is it that every network card has a different 'name'. xl0, rl0, vr0, ed0, etc. etc. etc I tried simlinking them to a common name (I have xl0, rl0, and ed0 active in my current machine). linked to eth0, eth1, eth2 (didn't work). However, it would be nice if they all had a common name to the end user.. Primarily, me.. Especially when you rip out one card, install another, then the name changes on you... Suppose you have xl and vr in your computer. They are named eth0 and eth1, respectively. You then replace your vr by a ed. Mark with an X the correct option: ( ) the names for vr and ed will be eth0 and eth1, respectively. ( ) the names for vr and ed will be eth1 and eth0, respectively. ( ) none of the above Can you see what I'm getting at here? :-) The best solution would be hardwiring the names, but in that case it doesn't matter what are the default names. Actually, this is just a pathalogical case of: You have de0 and de1 in your computer. You replace one with another 'de' card/rearrange cards/whatever. Mark with an X the correct option ( ) de0 remains de0, de1 remains de1 ( ) de0 becomes de1, de1 becomes de0 ( ) you discover a new device, de-1 Having a single linear namespace for interfaces would, actually, make life somewhat easier for the administrator. You can simulate it buy only buying one type of ethernet card. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ifq_maxlen problem...
On Thu, 4 Feb 1999, Jaroslaw Bazydlo wrote: After yesterdays 'make world' I am having such warnings: ep0 XXX: driver didn't set ifq_maxlen lo0 XXX: driver didn't set ifq_maxlen ^ The system itself seems to work fine (for last 24 hrs). What do those messages mean??? Does anyone of you noticed similar messages??? I get the same thing for my kingston DEC based 10/100 card and lo0. The card still works though so the chance of this being life threatening are low :-) I'm sure its pretty harmless. Chris -- Join Team-FreeBSD on cracking RC5-64! grab you client now and HELP OUT! http://www.distributed.net/cgi/select.cgi; ===| Open Systems FreeBSD Consulting. FreeBSD 2.2.8 is available now! | Phone: 402-573-9124 ---| 3335 N. 103 Plaza #14, Omaha, NE 68134 FreeBSD: The power to serve!| E-Mail: op...@open-systems.net http://www.freebsd.org | Consulting, Network Engineering, Security ===| http://open-systems.net -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.2 mQENAzPemUsAAAEH/06iF0BU8pMtdLJrxp/lLk3vg9QJCHajsd25gYtR8X1Px1Te gWU0C4EwMh4seDIgK9bzFmjjlZOEgS9zEgia28xDgeluQjuuMyUFJ58MzRlC2ONC foYIZsFyIqdjEOCBdfhH5bmgB5/+L5bjDK6lNdqD8OAhtC4Xnc1UxAKq3oUgVD/Z d5UJXU2xm+f08WwGZIUcbGcaonRC/6Z/5o8YpLVBpcFeLtKW5WwGhEMxl9WDZ3Kb NZH6bx15WiB2Q/gZQib3ZXhe1xEgRP+p6BnvF364I/To9kMduHpJKU97PH3dU7Mv CXk2NG3rtOgLTEwLyvtBPqLnbx35E0JnZc0k5YkABRO0JU9wZW4gU3lzdGVtcyA8 b3BzeXNAb3Blbi1zeXN0ZW1zLm5ldD4= =BBjp -END PGP PUBLIC KEY BLOCK- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network Cards
On Thu, 4 Feb 1999, Daniel C. Sobral wrote: Rod Taylor wrote: I've often wondered this, but why is it that every network card has a different 'name'. xl0, rl0, vr0, ed0, etc. etc. etc The best solution would be hardwiring the names, but in that case it doesn't matter what are the default names. Yes. Hardwiring is the only appropriate solution. Hardwiring is nonappropriate in a non-static environment. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How many people use VI? This is unbelievable..
John Birrell j...@cimlogic.com.au writes: FWIW, this message is being edited with vi on a 2.2.8-STABLE machine rlogged in from a dxterm running on an OSF/1 box. The keyboard is one of DEC's LK401 things with the funny Do keys etc from back when VAX was just a twinkle in PDP's eye. I have TERM=vt100 in my FreeBSD environment, dxterm configured with the Numeric Keypad option checked and vt100 emulation, so keypad keys are 0.123456789, just like you'd expect. It's not vi that's the problem, just your termcap setting doesn't match the keyboard. But why is it only vi ? I see the same behaviour here (-current, Eterm, TERM=xterm). The numeric keypad works for XEmacs forced to use term instead of X, pico, mcedit (midnight commanders builtin editor), shell - everywhere else, but not for vi. -- # /AS/ http://privat.schlund.de/entropy/ # # According to rumours, MS finally decided to delay the release of the # # long-awaited Windows 2000 until the first quarter of 1901. -unknown # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: wanton Atticizing is bad
Eric J. Schwertfeger wrote: There's two areas that IPFILTER seems to work better than IPFW, and both are NAT-related. I've been discussing this with various folks. What I see as the best solution to overcome the problem of a poorly maintained (and old) copy in the tree is to make a port out of it and remove the bulk of the code from the tree. Any chance of this happening (preferrably in 3.0-stable)? I need to run the newest version of IPFilter, and it's a bitch trying to hack out the old/hack in the new. Thanks, -- John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
boot0 does not remember F5
I have just installed the new boot0 boot manager on a machine which has two IDE disks attached to the same IDE bus. The first disk (wd0) is entirely dedicated to Windoze (ugh!) and the second one (wd1) to FreeBSD (aahhh...). Boot0 does its job, so I can choose between the two disks pressing F1 or F5. However, the default option is _always_ F1, despite of being F5 the last choice. Is this a bug or a feature :-) ? -- JMA --- José Mª Alcaide | mailto:j...@we.lc.ehu.es Universidad del País Vasco | mailto:j...@es.freebsd.org Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 --- Go ahead... make my day. - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
HEADS UP: loader has changed
I just committed patches to make include work with source code. Previously, it only processed builtins, greatly diminishing both ficl and include's usefulness. As a result of this change, the special behavior of the chacters @, # and - at the beginning of script lines is lost. They have been replaced as follow: @ Lines will *not* be echoed anymore by default. Thus, lines with @ can simply remove it. If one wants to echo a line, use the character $, with a space after it. # Use \ followed by a space. - Use % followed by a space. Examples: \ This is a comment load dont.echo $ load echo % load ignore.errors Since the new characters are forth words, they can be used anywhere in the line. So you can add comments *after* the command, for example. They can also be used together: % $ load /kernel.experimental I apologize for the inconvenience this may cause, but the previous way is highly incompatible with forth. -- Daniel C. Sobral (8-DCS) d...@gns.com.br The trouble with eating Italian food is that five or six days later you're hungry again. -- George Miller To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: vm_object_qcollapse(): object mismatch
Hmmm. This looks like an out-an-out bug to me. The assertion is wrong.
It's scanning the backing_object and asserting that the pages in the
backing object are associated with object rather then backing_object.
This section of code only runs when paging is in progress on a
collapseable object AND there are also idle pages in that object.
The collapse condition is probably due to an exiting process ( typical
in a buildworld ).
( from vm/vm_object.c )
/*
* busy the page and move it from the backing store to the
* parent object.
*/
vm_page_busy(p);
KASSERT(p-object == object, (vm_object_qcollapse(): object
mismatch));
^^
should be 'backing_object'
There is also an interrupt race. Since paging can be in progress,
pages in the object can be ripped out from under it so we have to
run at splbio() in the loop.
I will commit the fix.
-Matt
Matthew Dillon
dil...@backplane.com
:Hardware: 486DX2/66 16Mb ram, aha1542CF, 2x1Gb SCSI disks
:Software: 4.0-current 1-2 days old, softupdates
: (vm_map.c is at rev 1.146, for example)
:
:I was running 'make -j5 buildworld'. It swaps like crazy when I do this. :-)
:
:Here's what gdb -k tells me:
:
:...
:#9 0xf01425e0 in panic (
:fmt=0xf0225c1f vm_object_qcollapse(): object mismatch)
:at ../../kern/kern_shutdown.c:446
:#10 0xf01e0772 in vm_object_qcollapse (object=0xf2f001d0)
:at ../../vm/vm_object.c:1011
:#11 0xf01e08d6 in vm_object_collapse (object=0xf2f001d0)
:at ../../vm/vm_object.c:1102
:#12 0xf01ddae2 in vm_map_copy_entry (src_map=0xf2f4aa00, dst_map=0xf2f4ad00,
:src_entry=0xf2ed0e10, dst_entry=0xf2f8edc0) at ../../vm/vm_map.c:2284
:#13 0xf01ddd73 in vmspace_fork (vm1=0xf2f4aa00) at ../../vm/vm_map.c:2411
:#14 0xf01da833 in vm_fork (p1=0xf2f7db20, p2=0xf2d751e0, flags=20)
:at ../../vm/vm_glue.c:231
:#15 0xf013d4f0 in fork1 (p1=0xf2f7db20, flags=20) at ../../kern/kern_fork.c:447
:#16 0xf013ce65 in fork (p=0xf2f7db20, uap=0xf3021f94)
:at ../../kern/kern_fork.c:99
:#17 0xf01fe783 in syscall (frame={tf_es = 134807599, tf_ds = -272695249,
: tf_edi = 134750909, tf_esi = 134935201, tf_ebp = -272643652,
: tf_isp = -217964572, tf_ebx = 4, tf_edx = 672250004, tf_ecx = 19,
: tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 671826564, tf_cs = 31,
: tf_eflags = 662, tf_esp = -272651296, tf_ss = 47})
:at ../../i386/i386/trap.c:1100
:#18 0xf01f4e9c in Xint0x80_syscall ()
:...
:(kgdb) p *p
:$1 = {pageq = {tqe_next = 0xf02c5240, tqe_prev = 0xf02e4e00}, hnext = 0x0,
: listq = {tqe_next = 0xf02e59d0, tqe_prev = 0xf2f69cc8}, object = 0xf2f69cb0,
: pindex = 30, phys_addr = 15065088, queue = 4, flags = 1, pc = 0,
: wire_count = 0, hold_count = 0, act_count = 27 '\e', busy = 0 '\000',
: valid = 255 'ÿ', dirty = 255 'ÿ'}
:(kgdb) p object
:$2 = (struct vm_object *) 0xf2f001d0
:(kgdb) p *object
:$3 = {object_list = {tqe_next = 0xf2fdc2b8, tqe_prev = 0xf2f69c3c},
: shadow_head = {tqh_first = 0x0, tqh_last = 0xf2f001d8}, shadow_list = {
:tqe_next = 0x0, tqe_prev = 0xf2f69cb8}, memq = {tqh_first = 0xf02dbcb0,
:tqh_last = 0xf02cc86c}, generation = 11690, type = OBJT_DEFAULT,
: size = 32, ref_count = 2, shadow_count = 0, pg_color = 0,
: hash_rand = -136756254, flags = 8576, paging_in_progress = 0, behavior = 0,
: resident_page_count = 6, cache_count = 0, wire_count = 0,
: backing_object = 0xf2f69cb0, backing_object_offset = 0x,
: last_read = 0, pager_object_list = {tqe_next = 0xf2f69000,
:tqe_prev = 0xf0252f10}, handle = 0x0, un_pager = {vnp = {
: vnp_size = 0x}, devp = {devp_pglist = {tqh_first = 0x0,
:tqh_last = 0x0}}, swp = {swp_bcount = 0}}}
:(kgdb) p *(p-object)
:$4 = {object_list = {tqe_next = 0xf2f915e4, tqe_prev = 0xf30fd0e8},
: shadow_head = {tqh_first = 0xf2f001d0, tqh_last = 0xf2f001e0},
: shadow_list = {tqe_next = 0x0, tqe_prev = 0xf30fef04}, memq = {
:tqh_first = 0xf02e7170, tqh_last = 0xf02cff5c}, generation = 10219,
: type = OBJT_SWAP, size = 32, ref_count = 3, shadow_count = 1, pg_color = 0,
: hash_rand = -136000830, flags = 384, paging_in_progress = 0, behavior = 0,
: resident_page_count = 4, cache_count = 1, wire_count = 0,
: backing_object = 0x0, backing_object_offset = 0x,
: last_read = 29, pager_object_list = {tqe_next = 0xf30fad24,
:tqe_prev = 0xf30f0814}, handle = 0x0, un_pager = {vnp = {
: vnp_size = 0x0001}, devp = {devp_pglist = {tqh_first = 0x1,
:tqh_last = 0x0}}, swp = {swp_bcount = 1}}}
:
:I'll keep this dump around. What other details do people want?
:
:I'm not likely to even get to look at this let alone
Re: panic: vm_object_qcollapse(): object mismatch
I introduced this bug in 1.139 when I added the KASSERT(). Bleh. However, the code still needs to be protected at splbio(). And so I've committed. -Matt :Hmmm. This looks like an out-an-out bug to me. The assertion is wrong. :It's scanning the backing_object and asserting that the pages in the :backing object are associated with object rather then backing_object. : :This section of code only runs when paging is in progress on a :collapseable object AND there are also idle pages in that object. :The collapse condition is probably due to an exiting process ( typical :in a buildworld ). : :( from vm/vm_object.c ) :/* : * busy the page and move it from the backing store to the : * parent object. : */ : :vm_page_busy(p); : :KASSERT(p-object == object, (vm_object_qcollapse(): object mismatch)); : ^^ : should be 'backing_object' : :There is also an interrupt race. Since paging can be in progress, :pages in the object can be ripped out from under it so we have to :run at splbio() in the loop. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: loader has changed
Daniel C. Sobral wrote: I just committed patches to make include work with source code. ^^ That should have been _forth_ source code. Previously, it only processed builtins, greatly diminishing both ficl and include's usefulness. As a result of this change, the special behavior of the chacters @, # and - at the beginning of script lines is lost. They have been replaced as follow: @ Lines will *not* be echoed anymore by default. Thus, lines with @ can simply remove it. If one wants to echo a line, use the character $, with a space after it. # Use \ followed by a space. - Use % followed by a space. Examples: \ This is a comment load dont.echo $ load echo % load ignore.errors Since the new characters are forth words, they can be used anywhere in the line. So you can add comments *after* the command, for example. They can also be used together: % $ load /kernel.experimental I apologize for the inconvenience this may cause, but the previous way is highly incompatible with forth. -- Daniel C. Sobral (8-DCS) d...@gns.com.br The trouble with eating Italian food is that five or six days later you're hungry again. -- George Miller To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Daniel C. Sobral(8-DCS) d...@newsguy.com She just looked at him over the rotating pencil like, how slow can a mammal be and still have respiratory functions? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot0 does not remember F5
Jose M. Alcaide wrote: Boot0 does its job, so I can choose between the two disks pressing F1 or F5. However, the default option is _always_ F1, despite of being F5 the last choice. Is this a bug or a feature :-) ? This issue has already been discussed today (see the thread Boot block problem a few messages back). -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Boot block problem
Mike Smith writes: The new boot manager remembers last slice selected rather than last menu option selected on each drive. I think I prefer this behavior myself, but I'll change it for compatibility with booteasy. In the case where the last action was to chain to another disk, that's definitely preferable... Ah yes, that's what is happening to me, as I need to remember F5. Please let me know how I can get the necessary changes and whether you want me to test them. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
make release failure
I just tried a make release late last night eastern time, and it blew up in this stage. ===Verifying install for /usr/local/share/sgml/iso8879/catalog in /usr/ports/textproc/iso8879 make: argument list too long *** Error code 2 1 error -- Be careful of reading health books, you might die of a misprint. -- Mark Twain [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4.0-Current, netscape halts system
I finally got everything set up as far as having my vt220 being my console and being able to drop into DDB by hitting the break key. It turns out that as part of my setup I was using MFS for /tmp. When I did a CVSup and make world on the 29th, I decided to comment out the MFS mount point. I have not had a hang since then. So the question is are there known problems with MFS? -Reggie Alfred == Alfred Perlstein bri...@hotjobs.com writes: On Mon, 25 Jan 1999, Reginald S. Perry wrote: I have been having these X lockups with the linux netscape 4.5 running. I may have exacerbated it when I installed the linux realplayer and macromedia flash plugins. I would like to have a methodology to help debug this, but I have just this one system to use as the debug system. I do also have a vt220 which I could set up if that would help. The key here is that for me it locks the system up completely. I cannot telnet in remotely and the ctrl-alt-esc key sequence does not work so its unclear to me how to debug this. Tell me what I would need to help debug it, and I will try to be of some help. Ill attach my dmesg output. -Reggie options DDB options BREAK_TO_DEBUGGER #a BREAK on a comconsole goes to options INVARIANTS options INVARIANT_SUPPORT device sio0 at isa? port IO_COM1 tty irq 4 vector siointr device sio1 at isa? port IO_COM2 flags 0x30 tty irq 3 vector siointr my 'sio2' is setup with special flags to make it always be the consol. look in lint for more hints. when the machine locks: send a break: if on vt220: F5 using tip/cu: ~% take a look at 'ps' and copy it down to see what's up. you may also want to enable crash dumps, look in rc.conf and set your 'dumpdevice' to your swap partition. then you can type 'panic' and get a core image of the system to look at. on the next reboot you can 'kdb' the kernel and then type 'bt' to get a backtrace. i have a vt320 for vanity purposes :), but i suggest you use a serial line into an xterm on another box if you can, ddb isn't the nicest interface and being able to cut and paste in and out of ddb in an xterm is nice. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ifq_maxlen problem...
As Open Systems Inc. wrote... On Thu, 4 Feb 1999, Jaroslaw Bazydlo wrote: After yesterdays 'make world' I am having such warnings: ep0 XXX: driver didn't set ifq_maxlen lo0 XXX: driver didn't set ifq_maxlen ^ The system itself seems to work fine (for last 24 hrs). What do those messages mean??? Does anyone of you noticed similar messages??? I get the same thing for my kingston DEC based 10/100 card and lo0. The card still works though so the chance of this being life threatening are low :-) Interesting. I have the same Kingston 10/100 and I've never seen it. YMMV obviously. Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Overview of the FreeBSD boot process, 3.1 and later
#define quoting(Mike Smith) // I'm in the process of preparing a document describing the FreeBSD boot // process in the new age. At the moment, there's some emphasis on the // loader, and probably an uneven level of detail elsewhere. Commentary // is invited. // // http://www.freebsd.org/~msmith/FTL/bootstrap.txt Cool !!! We really needed such a documentation... My sugestions: 1) Explain a bit more how boot0 works, and which consequences could this behavior have on another operating systems installed. For example, say that it remembers the last booted slice by rewriting itself. BTW: Can this be disabled ? Sometimes this is not needed/wanted, and the only current solution is to use os-bs. 2) Update it for the last changes in /boot/loader by Daniel Sobral. IIRC: @, # and - are gone. BTW: If variables were identified by a $ sign, and the $ sign is now an echo on execute command, how will variables be identified now ? Or have I misunderstood something ? 3) Give more real examples in the load -t section. I'd include mfs_root and splash_image_data, for example. Or, at least, send the reader to some reference elsewhere. Jonny -- Joao Carlos Mendes LuisM.Sc. Student jo...@jonny.eng.br Universidade Federal do Rio de Janeiro This .sig is not meant to be politically correct. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up: comitted optimization to vm_map_insert()
Brian Feldman gr...@unixhelp.org writes: On Wed, 3 Feb 1999, Matthew Dillon wrote: My do lots of things that force the machine to page up the wazoo and try to make it crash test :-) So do you run Netscape, or do you run StarOffice? ;) Just trying to compile Applix should be enough. Ask Mike ;) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Bug in piperd
Ha. I've been slowly reducing MAXMEM on my test box to force it to
swap more heavily running buildworld and found a race in the
kern/sys_pipe.c module.
My buildworld froze up... i.e. just stopped running. Everything else
on the box was fine. ps showed an 'as' command stuck in 'piperd'.
The problem is simple (pseudo code fragment):
pipe read:
...
* check for EOF
* check for waiting writers
* lock the pipe
* check for waiting writers
* check for non-blocking I/O
* sleep in 'piperd'
The problem, of course, is that if 'lock the pipe' blocks, it is possible
for the writer side to close the pipe. Since EOF is not checked for
after the pipe has been locked, the reader enters a 'piperd' state
and never gets woken up again.
I am testing a fix now and will then commit it.
If anyone sees anything obviously wrong with this patch, please email me.
-Matt
Matthew Dillon
dil...@backplane.com
Index: sys_pipe.c
===
RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.49
diff -u -r1.49 sys_pipe.c
--- sys_pipe.c 1999/01/28 00:57:47 1.49
+++ sys_pipe.c 1999/02/04 22:14:58
@@ -381,12 +381,32 @@
#endif
} else {
/*
+* If there is no more to read in the pipe, reset
+* its pointers to the beginning. This improves
+* cache hit stats.
+*
+* We get this over with now because it may block
+* and cause the state to change out from under us,
+* rather then have to re-test the state both before
+* and after this fragment.
+*/
+
+ if ((error = pipelock(rpipe,1)) == 0) {
+ if (rpipe-pipe_buffer.cnt == 0) {
+ rpipe-pipe_buffer.in = 0;
+ rpipe-pipe_buffer.out = 0;
+ }
+ pipeunlock(rpipe);
+ }
+
+ /*
* detect EOF condition
*/
if (rpipe-pipe_state PIPE_EOF) {
/* XXX error = ? */
break;
}
+
/*
* If the write-side has been blocked, wake it up now.
*/
@@ -394,34 +414,26 @@
rpipe-pipe_state = ~PIPE_WANTW;
wakeup(rpipe);
}
- if (nread 0)
+
+ /*
+* break if error (signal via pipelock), or if some
+* data was read
+*/
+ if (error || nread 0)
break;
+ /*
+* Handle non-blocking mode operation
+*/
+
if (fp-f_flag FNONBLOCK) {
error = EAGAIN;
break;
}
/*
-* If there is no more to read in the pipe, reset
-* its pointers to the beginning. This improves
-* cache hit stats.
+* Wait for more data
*/
-
- if ((error = pipelock(rpipe,1)) == 0) {
- if (rpipe-pipe_buffer.cnt == 0) {
- rpipe-pipe_buffer.in = 0;
- rpipe-pipe_buffer.out = 0;
- }
- pipeunlock(rpipe);
- } else {
- break;
- }
-
- if (rpipe-pipe_state PIPE_WANTW) {
- rpipe-pipe_state = ~PIPE_WANTW;
- wakeup(rpipe);
- }
rpipe-pipe_state |= PIPE_WANTR;
if ((error = tsleep(rpipe, PRIBIO|PCATCH, piperd, 0))
!= 0) {
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Bug in piperd
Updated patch - one must also check to see if any new data has
entered the pipe after locking it in case the lock blocked.
( this patch FYI only, the problem occurs unoften enough that
you can afford to wait until I commit it ).
-Matt
Index: sys_pipe.c
===
RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.49
diff -u -r1.49 sys_pipe.c
--- sys_pipe.c 1999/01/28 00:57:47 1.49
+++ sys_pipe.c 1999/02/04 22:24:42
@@ -381,12 +381,39 @@
#endif
} else {
/*
+* If there is no more to read in the pipe, reset
+* its pointers to the beginning. This improves
+* cache hit stats.
+*
+* We get this over with now because it may block
+* and cause the state to change out from under us,
+* rather then have to re-test the state both before
+* and after this fragment.
+*/
+
+ if ((error = pipelock(rpipe,1)) == 0) {
+ if (rpipe-pipe_buffer.cnt == 0) {
+ rpipe-pipe_buffer.in = 0;
+ rpipe-pipe_buffer.out = 0;
+ }
+ pipeunlock(rpipe);
+
+ /*
+* If pipe filled up due to pipelock
+* blocking, loop back up.
+*/
+ if (rpipe-pipe_buffer.cnt 0)
+ continue;
+ }
+
+ /*
* detect EOF condition
*/
if (rpipe-pipe_state PIPE_EOF) {
/* XXX error = ? */
break;
}
+
/*
* If the write-side has been blocked, wake it up now.
*/
@@ -394,34 +421,26 @@
rpipe-pipe_state = ~PIPE_WANTW;
wakeup(rpipe);
}
- if (nread 0)
+
+ /*
+* break if error (signal via pipelock), or if some
+* data was read
+*/
+ if (error || nread 0)
break;
+ /*
+* Handle non-blocking mode operation
+*/
+
if (fp-f_flag FNONBLOCK) {
error = EAGAIN;
break;
}
/*
-* If there is no more to read in the pipe, reset
-* its pointers to the beginning. This improves
-* cache hit stats.
+* Wait for more data
*/
-
- if ((error = pipelock(rpipe,1)) == 0) {
- if (rpipe-pipe_buffer.cnt == 0) {
- rpipe-pipe_buffer.in = 0;
- rpipe-pipe_buffer.out = 0;
- }
- pipeunlock(rpipe);
- } else {
- break;
- }
-
- if (rpipe-pipe_state PIPE_WANTW) {
- rpipe-pipe_state = ~PIPE_WANTW;
- wakeup(rpipe);
- }
rpipe-pipe_state |= PIPE_WANTR;
if ((error = tsleep(rpipe, PRIBIO|PCATCH, piperd, 0))
!= 0) {
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Overview of the FreeBSD boot process, 3.1 and later
Joao Carlos Mendes Luis wrote: 1) Explain a bit more how boot0 works, and which consequences could this behavior have on another operating systems installed. For example, say that it remembers the last booted slice by rewriting itself. BTW: Can this be disabled ? Sometimes this is not needed/wanted, and the only current solution is to use os-bs. I think the best place to deal in detail with boot0 would be in a boot0(8) man page, similar in approach to the present boot(8). I'll try to get around to this in the next few days. It's useful that Mike's document touches on boot[012], but the loader is a big subject in it's own right -- and the one most people will want to read up on -- whereas boot0 is not even FreeBSD-specific, beyond being included in the distribution. To answer your question: yes, updates can be disabled. The easiest method at present is to define B0FLAGS (in the Makefile) as having bit 6 (0x40) set. Though a utility for installing and configuring the boot manager from the command line is in progress. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up: comitted optimization to vm_map_insert()
:Brian Feldman gr...@unixhelp.org writes: : On Wed, 3 Feb 1999, Matthew Dillon wrote: : My do lots of things that force the machine to page up the wazoo and : try to make it crash test :-) : So do you run Netscape, or do you run StarOffice? ;) : :Just trying to compile Applix should be enough. Ask Mike ;) : :DES :-- :Dag-Erling Smorgrav - d...@flood.ping.uio.no At the moment I'm doing -j16 buildworlds with MFS mounted /usr/obj, NFS swap, NFS mounted /usr/src, and artificially limited main memory (32MB). The machine goes totally nuts compiling the perl stuff, paging in and paging out simultaniously at 1 MByte/sec in each direction. But it slogs through it. Pretty soon I'm going to start experimenting with NFS-file-backed VN-mounted filesystems combo NFS and IDE swap to better test the swap and vnode pagers under extreme load conditions. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /dev/nrsa0 file mark handling
control open - Already on my list. mt_fileno/mt_blkno - I'm mulling that one. Yes, I think I will, but it'll take a lot of work because there are (now) a large number of conditions that invalidate and make completely unknown those relative positions (EOD, hard block locating). current state - Interesting notion. My motivation for wanting these things is that I have a program All three items are to be integrated today. There will be a control open device that allows you to open the device to retrieve stats (even if another application has the device open). You can (try) and set block size and density and compression via the control device open, but you'll pin (interruptibly) waiting for access to the device if another application has it open. There already is an Error Stats ioctl that is different from the regular MTIOCGET. The mt_fileno/mt_blkno will go in. Hopefully I'll have caught all the spots, but I will document in the man page that this information is not definitive. The only definitive information about tape position is BOT, End of Recorded Media and hardware block position (if supported by the drive). Current state will now be loaded int mt_dsreg. There will be some FreeBSD specific defines as to what the tape driver thinks that it is doing. mt(1) will be modified to print out the latter two items. After this point I plan to start development on using the HP TapeAlert initiative's rulesets for new tape behaviour. That should leverage FreeBSD into a number of markets. -matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up: comitted optimization to vm_map_insert()
On 4 Feb 1999, Dag-Erling Smorgrav wrote: Brian Feldman gr...@unixhelp.org writes: On Wed, 3 Feb 1999, Matthew Dillon wrote: My do lots of things that force the machine to page up the wazoo and try to make it crash test :-) So do you run Netscape, or do you run StarOffice? ;) Just trying to compile Applix should be enough. Ask Mike ;) Hah, I remember when I tried compiling (old-school) Mozilla, and ld was over 100mb ;) People need more RAM like in Jordan's home box, or wcarchive for that matter! This summer, hope I'll get my 512mb, and say goodbye to wd[03]s1b =) Let's ask Mr. VM if the fixes he did today were the culprits for his sig11, shall we? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Bug in piperd
I've been seeng lockups in 3.0 where as is in piperd,
but the stack trace has always looked as if the problem was in soft
updates or the syncer daemon..
Matthew Dillon wrote:
Ha. I've been slowly reducing MAXMEM on my test box to force it to
swap more heavily running buildworld and found a race in the
kern/sys_pipe.c module.
My buildworld froze up... i.e. just stopped running. Everything else
on the box was fine. ps showed an 'as' command stuck in 'piperd'.
The problem is simple (pseudo code fragment):
pipe read:
...
* check for EOF
* check for waiting writers
* lock the pipe
* check for waiting writers
* check for non-blocking I/O
* sleep in 'piperd'
The problem, of course, is that if 'lock the pipe' blocks, it is possible
for the writer side to close the pipe. Since EOF is not checked for
after the pipe has been locked, the reader enters a 'piperd' state
and never gets woken up again.
I am testing a fix now and will then commit it.
If anyone sees anything obviously wrong with this patch, please email me.
-Matt
Matthew Dillon
dil...@backplane.com
Index: sys_pipe.c
===
RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.49
diff -u -r1.49 sys_pipe.c
--- sys_pipe.c 1999/01/28 00:57:47 1.49
+++ sys_pipe.c 1999/02/04 22:14:58
@@ -381,12 +381,32 @@
#endif
} else {
/*
+* If there is no more to read in the pipe, reset
+* its pointers to the beginning. This improves
+* cache hit stats.
+*
+* We get this over with now because it may block
+* and cause the state to change out from under us,
+* rather then have to re-test the state both before
+* and after this fragment.
+*/
+
+ if ((error = pipelock(rpipe,1)) == 0) {
+ if (rpipe-pipe_buffer.cnt == 0) {
+ rpipe-pipe_buffer.in = 0;
+ rpipe-pipe_buffer.out = 0;
+ }
+ pipeunlock(rpipe);
+ }
+
+ /*
* detect EOF condition
*/
if (rpipe-pipe_state PIPE_EOF) {
/* XXX error = ? */
break;
}
+
/*
* If the write-side has been blocked, wake it up
now.
*/
@@ -394,34 +414,26 @@
rpipe-pipe_state = ~PIPE_WANTW;
wakeup(rpipe);
}
- if (nread 0)
+
+ /*
+* break if error (signal via pipelock), or if some
+* data was read
+*/
+ if (error || nread 0)
break;
+ /*
+* Handle non-blocking mode operation
+*/
+
if (fp-f_flag FNONBLOCK) {
error = EAGAIN;
break;
}
/*
-* If there is no more to read in the pipe, reset
-* its pointers to the beginning. This improves
-* cache hit stats.
+* Wait for more data
*/
-
- if ((error = pipelock(rpipe,1)) == 0) {
- if (rpipe-pipe_buffer.cnt == 0) {
- rpipe-pipe_buffer.in = 0;
- rpipe-pipe_buffer.out = 0;
- }
- pipeunlock(rpipe);
- } else {
- break;
- }
-
- if (rpipe-pipe_state PIPE_WANTW) {
- rpipe-pipe_state = ~PIPE_WANTW;
- wakeup(rpipe);
- }
rpipe-pipe_state |= PIPE_WANTR;
if ((error = tsleep(rpipe, PRIBIO|PCATCH, piperd,
0)) != 0) {
To
Re: Bug in piperd
: :I've been seeng lockups in 3.0 where as is in piperd, :but the stack trace has always looked as if the problem was in soft :updates or the syncer daemon.. : It's quite possible for as to be in 'piperd' when some other unassociated crash occurs, since it is typically waiting for input from cc1. What is not typical, however, is if as is stuck 'piperd' and the other end of the pipe has been closed. The particular piperd bug I found cannot crash the system - at worst it will block a process forever. And you can still kill the process. 3.0's lockups could be very well due to a number of low-memory interlock situations that typically occur when heavy paging is going on, if that is how you are running 3.0. I suspect it is too late to get my getpbuf() changes into 3.1, which might mitigate that somewhat. -Matt Matthew Dillon dil...@backplane.com : The problem is simple (pseudo code fragment): : : pipe read: : ... : * check for EOF : * check for waiting writers : * lock the pipe : * check for waiting writers : * check for non-blocking I/O : * sleep in 'piperd' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Bug in piperd
Matthew Dillon wrote: : :I've been seeng lockups in 3.0 where as is in piperd, :but the stack trace has always looked as if the problem was in soft :updates or the syncer daemon.. : It's quite possible for as to be in 'piperd' when some other unassociated crash occurs, since it is typically waiting for input from cc1. What is not typical, however, is if as is stuck 'piperd' and the other end of the pipe has been closed. The particular piperd bug I found cannot crash the system - at worst it will block a process forever. And you can still kill the process. 3.0's lockups could be very well due to a number of low-memory interlock situations that typically occur when heavy paging is going on, if that is how you are running 3.0. I suspect it is too late to get my getpbuf() changes into 3.1, which might mitigate that somewhat. the lockups are in a 2 day old SNAP of 3.x To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Bug in piperd
3.0's lockups could be very well due to a number of low-memory interlock situations that typically occur when heavy paging is going on, if that is how you are running 3.0. I suspect it is too late to get my getpbuf() changes into 3.1, which might mitigate that somewhat. If you can demonstrate that they work and have the desired effect, you could make a good case for this. If you have the time, a lot of people would appreciate the effort. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Reading a text file with BTX
On 04-Feb-99 Robert Nordier wrote about Re: Reading a text file with BTX: Right on the mark. BTW, my BIOS is set so the cd drive is searched before the hd on boot. Could that be the cause? Seems a reasonable assumption, but I don't know for sure. It is. Proof? I simply meant that it happened to me once on a 586 FX M/B: it disappeared when I selected C/CDROM/A as the drive to boot from in the BIOS. I cannot remember the version of the BootManager I tried, if that means anything. Robert Nordier Bye, UP To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ifq_maxlen problem...
On 04-Feb-99 Jaroslaw Bazydlo wrote: After yesterdays 'make world' I am having such warnings: FreeBSD 4.0-CURRENT #0: Thu Feb 4 17:19:09 GMT 1999 jar...@ent.freebsd.org.pl:/usr/src/sys/compile/ENT [...] ep0 at 0x300-0x30f irq 10 on isa ep0: utp/bnc[*UTP*] address 00:60:08:65:d6:8d [...] ep0 XXX: driver didn't set ifq_maxlen lo0 XXX: driver didn't set ifq_maxlen ^ The system itself seems to work fine (for last 24 hrs). What do those messages mean??? Does anyone of you noticed similar messages??? The NIC is 3com 3c509B. Just cvsup'ed, made world and kernel today (Thursday, 2/4), and am seeing the same thing at bootup (on lo0; I have no network interfaces installed). No idea what it means or what's causing it, but it seems pretty harmless. -- Conrad Sabatier conr...@neosoft.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
which star office 5.0 works with -current
Hello, I had checked ftp.stardiv.com and found that there are several star office 5.0 under the directory /pub/so5. I would like to know which one works with -current. 1. so50_01.tar Nov 5 2. so50_33.tar Dec18 3. so50_39.tar Dec18 4. so50_49.tar Nov 5 cheers.. Clarence To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR REVIEW: man page update
Kazutaka YOKOTA writes: In order to reflect the recent changes regarding syscons, keyboard and video drivers, I wrote the following new man pages and update for a couple of existing ones. They are rudimentary, but better than nothing. http://www.freebsd.org/~yokota/man4update.tar.gz I've added a couple of tweaks. For some reason the .Fx macro doesn't work on my terminal (using nroff -man foo.4), it just replaces the O/S version with nothing.. so I used .Tn instead which is what the pnpinfo(8) man page uses. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com diff -ur old/atkbd.4 new/atkbd.4 --- old/atkbd.4 Thu Feb 4 05:45:09 1999 +++ new/atkbd.4 Thu Feb 4 18:41:41 1999 @@ -69,7 +69,8 @@ The .Nm driver first appeared in -.Fx 3.1 . +.Tn FreeBSD +3.1. .Sh AUTHORS The .Nm diff -ur old/atkbdc.4 new/atkbdc.4 --- old/atkbdc.4Thu Feb 4 05:45:10 1999 +++ new/atkbdc.4Thu Feb 4 18:43:06 1999 @@ -77,9 +77,11 @@ The .Nm driver first appeared in -.Fx 3.1 . +.Tn FreeBSD +3.1. It is based on the kbdio module in -.Fx 2.2 . +.Tn FreeBSD +2.2. .Sh AUTHORS The kbdio module and the .Nm diff -ur old/splash.4 new/splash.4 --- old/splash.4Thu Feb 4 05:45:15 1999 +++ new/splash.4Thu Feb 4 18:48:38 1999 @@ -30,8 +30,8 @@ .Fl c or .Fl v -boot option when loading kernel, the splash image won't appear. -(But is still loaded and can be used as a screen saver later; see below.) +boot option when loading kernel, the splash image won't appear +(though it is still loaded and can be used as a screen saver later; see below). .Pp In order to display the bitmap, the bitmap file itself and matching splash image decoder must be loaded by the boot loader. @@ -41,7 +41,7 @@ .It splash_bmp.ko W*ndows BMP file decoder. While the BMP file format allows various depth of colors, this decoder -can handle 256 color bitmaps only. +can only handle 256 color bitmaps. Other color depth won't work. .El .Pp @@ -122,11 +122,11 @@ The screen saver won't run if the current screen is not in the text mode. .Sh SPLASH SCREEN AS A SCREEN SAVER -If you load splash image but don't load a screen saver, +If you load a splash image but don't load a screen saver, you can continue using the splash module as a screen saver. Specify the screen blanking interval as explained in the .Sx SCREEN SAVER -section above, then +section above, and the splash screen image will come back after the specified time. .\.Sh DRIVER CONFIGURATION .Sh FILES @@ -188,7 +188,7 @@ .Xr pcvt 4 . .Sh BUGS If you load a screen saver while another screen saver has already -been loaded, the first screen saver won't be automatically unloaed +been loaded, the first screen saver won't be automatically unloaded and remain in memory, wasting kernel memory space. .Sh SEE ALSO .Xr vidcontrol 1 , @@ -197,12 +197,13 @@ .Xr loader.rc 5 , .Xr rc.conf 5 , .Xr kldload 8 , -.Xr kldunload 8 , +.Xr kldunload 8 . .Sh HISTORY The .Nm driver first appeared in -.Fx 3.1 . +.Tn FreeBSD +3.1. .Sh AUTHORS The .Nm diff -ur old/vga.4 new/vga.4 --- old/vga.4 Thu Feb 4 05:45:18 1999 +++ new/vga.4 Thu Feb 4 18:52:40 1999 @@ -50,7 +50,7 @@ option is required in the kernel configuration file in this case too. .Sh DRIVER CONFIGURATION .Ss Kernel Configuration Options -There are following kernel configuration options to control the +The following kernel configuration options control the .Nm driver. They may be set in the kernel configuration file @@ -81,7 +81,7 @@ option. .It Em VESA_DEBUG=N Set the VESA support debug level to N. -The default value is zero and all debugging output is suppressed. +The default value is zero (all debugging output is suppressed). .El .Pp The following options will remove some features from the @@ -128,14 +128,18 @@ .Sh SEE ALSO .Xr syscons 4 , .Xr kldload 8 , -.Xr kldunload 8 +.Xr kldunload 8 . .Sh STANDARD -``VESA BIOS Extension (VBE)'', Video Electronics Standards Association. +.Rs +.%T VESA BIOS Extension (VBE) +.%A Video Electronics Standards Association +.Re .Sh HISTORY The .Nm driver first appeared in -.Fx 3.1 . +.Tn FreeBSD +3.1. .Sh AUTHORS The .Nm To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: aio_read panics SMP kernel
Brian Dean said: I'm using a dual 350MHz Dell Precision 410 with 4.0-19990130-SNAP (SMP enabled) to prototype a program that uses asynchronous read and write (aio_read() and aio_write()), and found that the following simple and not very useful program (it's for demonstration purposes only!) causes the system to do one of three things: The VM code needs to be upgraded to support proper threading and shared address space operations under SMP. That is a major missing feature, and probably something that should be higher priority than it currently is. I have experimental work to support it (and alot of other interesting things), but it will probably be quite a while before those who are currently working on the code will be able to add the capability. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: more about yield() versus sched_yield()
Richard Seaman, Jr. said: As I indicated to you several weeks ago, I think it is possible to have a priority inversion problem in spinlocks that spin on sched_yield. The yield call, as implemented, partly addresses the issue. However, as you commented to me, it does so poorly. If the consensus is to drop or modify SYS_yield, my vote would be to give consideration to changing the call to more correctly address the priority inversion issue. Possibly a yield (pid_t pid) where the pid passed in is the pid of the thread (process) holding a lock. The system could then check the credentials of the pid to see if there is permission (eg. its a kernel thread of the same process) and if so, raise the priority of pid to that of the calling process for one time slice so pid has a chance to execute and free the lock. I didn't add the system call to the library (yet), because wasn't sure if it was working the way that I wanted. I do suggest that there be only one (yield) type system call, and if special behavior is desired, then give an argument describing the special behavior. I suggest that the yield that is kept should be the one where there is a current maintainer for it :-). -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: swap_page_getswapspace failed (don't do stupid things with /dev/mem)
Matthew Dillon said: :Matt, : :Does datasize limit the number of backed pages, or the amount of address :space used by a process? I.e., can I grow myself a large chunk of address :space using mmap to the same region of a file, and then read into that :large chunk (presumably larger than the cache size if I want to be nasty)? :If datasize only affects backed pages, then we can still do nasty large :copies; if it affects address space, then nasty large copies are limited :to the size of the writable address space (if using readv) or the size of :the largest contiguous writable space (if using read). : : Robert N Watson : :rob...@fledge.watson.org http://www.watson.org/~robert/ :PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C The 'datasize' limit does not effect mmap(), only brk/sbrk. So, in fact, I believe you can bypass the datasize limit by allocating anonymous memory using mmap(). This is probably a bug. We should either limit the mmap()able space to about the same size as the data segment limit, or keep track of the amount of anonymous mapped memory and count that in the datasize limit. FYI, the information that provides the virtual space used by a map (process) is in the vm_map data structure (so you don't need to reinvent it.) It is now used by PS also. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
mmap() raw device
Is it possible somehow to mmap() a raw device such as /dev/rda0s2b? I am writing a program that needs very fast access to raw data, it almost creates its own filesystem in its own right. I'd much rather be able to mmap() the raw drive rather than having to go through the filesystem. -Matt --[ Matt Hamilton ] System Administrator System Administrator Badock Hall Clintondale Aviation Bristol University, UK Clifton Park, NY, USA http://www.bad.bris.ac.uk http://www.clintondale.com m...@bad.bris.ac.uk m...@clintondale.com --- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
swapper BIG problems
Okay, here's the situation:
I've got an old program from when I was first learning C lying around, and I
converted it to be a very rudimentary memory tester.
#include stdio.h
#include stdlib.h
#include string.h
#define SIZE 1024*1024
void
main(void) {
int count, yep = 0;
void *stfu[SIZE];
void *mem;
for (count = 0; count SIZE; count++) {
if ((mem = stfu[count] = malloc(1024))) {
int where;
printf(%p (%i) malloc'd\n, stfu[count], count);
for (where = 0; where (1024 / sizeof(unsigned)); where++)
((unsigned *)mem)[where] = 0xdeadbeef;
yep++;
}
else
break;
}
for (count = 0; count yep; count++) {
int where;
mem = stfu[count];
for (where = 0; where (1024 / sizeof(unsigned)); where++)
if (((unsigned *)mem)[where] != 0xdeadbeef) {
fprintf(stderr, memory check failed at %i of %i\n, count,
yep);
exit(2);
}
free(stfu[count]);
printf(%i free'd\n, count);
}
if (yep != SIZE) {
printf(mallocs failed at %i\n, yep);
exit (1);
}
else
exit (0);
}
It succeeds as per allocating the memory until the swap is full. But, when
it starts the reading/freeing, the swapins cause hundreds of
swap_pager_getswapspace: failed
This will put the system in a deadlock if, for instance, this program is run
in an xterm and an X server is running locally, and it's too swapped out to
be used, but the memory program displays things to the term (catch-22).
What I see this as is (but I'm just guessing, I'm not a real kernel hacker
yet):
The mallocations fail where the swap runs out. Fine, whatever. The printf's
in the free routines call malloc() after free()ing the kilobyte, but malloc
does not have the memory for it (or does but complains) and so complains a
LOT. The printfs work so it _SEEMS_ to be that the only thing bringing the
system to a halt is the printfs is the kernel itself, most likely the
printf's. Does this seem correct? If it's actually the kernel printf that's
hanging the system, what's the solution? What if it's not?
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: swapper BIG problems
If I do a little
--- swap_pager.c.orig Thu Feb 4 23:30:43 1999
+++ swap_pager.cThu Feb 4 23:31:22 1999
@@ -203,8 +203,10 @@
swp_sizecheck()
{
if (vm_swap_size nswap_lowat) {
+/*
if (swap_pager_full == 0)
printf(swap_pager: out of swap space\n);
+*/
swap_pager_full = 1;
} else if (vm_swap_size nswap_hiwat) {
swap_pager_full = 0;
@@ -442,9 +444,7 @@
{
daddr_t blk;
- if ((blk = blist_alloc(swapblist, npages)) == SWAPBLK_NONE) {
- printf(swap_pager_getswapspace: failed\n);
- } else {
+ if ((blk = blist_alloc(swapblist, npages)) != SWAPBLK_NONE) {
vm_swap_size -= npages;
swp_sizecheck();
}
My system survives through the run quite well. It does in fact seem I was
correct in my educated guess, but if anyone knows differently, (Matt, John
Dyson) please let me know! Right now it seems the printf()s can cause the
deadlock.
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: swapper BIG problems
In nlc.lists.freebsd-current you wrote: It succeeds as per allocating the memory until the swap is full. But, when Malloc's don't cause swap space allocation. Theoretically a process can malloc all of it's virtual address space so long as it doesn't touch the pages. it starts the reading/freeing, the swapins cause hundreds of swap_pager_getswapspace: failed Once you actually start touching the pages does swap space (or real memory) get allocated. However by now you have malloc'ed more data than exists in physical swap space, and the swapper can't do anything about it except throw away your dirty pages without saving them. This will put the system in a deadlock if, for instance, this program is run in an xterm and an X server is running locally, and it's too swapped out to be used, but the memory program displays things to the term (catch-22). This is a problem. Possibly the print commands should be rate limited. If they go to the console how do they end up in an xterm? Possibly your syslog.conf, or you run xconsole. Cheers. --++ . | John Saunders - mailto:j...@nlc.net.au(EMail) | ,--_|\|- http://www.nlc.net.au/ (WWW) | / Oz \ |- 02-9489-4932 or 041-822-3814 (Phone) | \_,--\_/ | NHJ NORTHLINK COMMUNICATIONS - Supplying a professional, | v| and above all friendly, internet connection service. | ++ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: locale errors
My locale is set do de_DE.ISO_8859-1, not de_DE.ASCII If I type 2 characters ss, I mean 2 characters ss. If I type ß I mean the single character ß. This sorting behaviour is just wrong. Not every apperence of ss even in pure ASCII does mean ß. I suggest you set LC_COLLATE to C, then it sorts in the good old fashioned way its meant to be. (like this on Solaris 7: Assel aSS asen ass asse assel assen aß aßen ) and so: Grüße Michael -- michael.schus...@germany.sun.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
