Re: question about boot loaders
On Thu 1999-12-09 (02:46), Robert Watson wrote: Once we get into boot2 land, I recognize the FreeBSD-specific loading code, etc. What I don't know much about is those first three 512-byte chunks of code. Boot0 appears to be booteasy, but given some ignorance about the i386 boot process, I'm not sure whether it's loaded by mbr, or by the bios, and where it lives partition-wise. Similarly, how boot1 fits into it the whole scheme--I assume this is FreeBSD-specific as it knows about boot2, but don't know where it lives, etc. Preferably, afterwards, also drop the results into sys/boot/i386/README. :-) I wrote up some basic stuff, which doesn't seem quite to describe what you're after, but which may be of use, at http://rucus.ru.ac.za/~nbm/boot/ It's intended for the handbook, but I haven't had time since starting my new job to work on it much more. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: question about boot loaders
On Thu, 9 Dec 1999, Neil Blakey-Milner wrote: On Thu 1999-12-09 (02:46), Robert Watson wrote: Once we get into boot2 land, I recognize the FreeBSD-specific loading code, etc. What I don't know much about is those first three 512-byte chunks of code. Boot0 appears to be booteasy, but given some ignorance about the i386 boot process, I'm not sure whether it's loaded by mbr, or by the bios, and where it lives partition-wise. Similarly, how boot1 fits into it the whole scheme--I assume this is FreeBSD-specific as it knows about boot2, but don't know where it lives, etc. Preferably, afterwards, also drop the results into sys/boot/i386/README. :-) I wrote up some basic stuff, which doesn't seem quite to describe what you're after, but which may be of use, at http://rucus.ru.ac.za/~nbm/boot/ It's intended for the handbook, but I haven't had time since starting my new job to work on it much more. Looks interesting, but doesn't seem to mention the mbr/mbr.s code, and I'm not sure how this fit into the picture. There seem to be three 512-byte chunks of code: -r--r--r-- 1 root wheel 512 Sep 16 18:46 mbr -r--r--r-- 1 root wheel 512 Sep 16 18:46 boot0 -r--r--r-- 1 root wheel 512 Sep 16 18:46 boot1 -r--r--r-- 1 root wheel7680 Sep 16 18:46 boot2 -r-xr-xr-x 1 root wheel 131072 Sep 16 18:46 loader* When there were two of them, I understood pretty much what was going on. Now there are three, and I clearly haven't been keeping a close enough eye on what is going on, because now I'm confused whereas previously I wasn't :-). Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Possible libc changes to support LinuxThreads
I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2) running, but ran into a couple of minor problems integrating with our libc. LinuxThreads redefines a number of functions in order to make them either support thread cancellation or work correctly. The following functions need an alternative name, just as, for example, write() is actually _write(): lseek() pause() system() tcdrain() wait() waitpid() recv() send() This would allow implementing cancellation points for these functions. All in all, I won't lose much sleep over this, but if it's easy to do and doesn't violate some rule of symbol naming, it would be nice. The other issue has to do with longjmp() and siglongjmp(), and is of a similar nature, except that _longjmp() already exists as a separate interface. So, at least in the case of longjmp(), it needs to have a different alias, perhaps __longjmp(). Below is a *very* simplistic patch to libc that works, but it may make some people's skin crawl. Feedback is welcome. If there is no correct way to create aliases to function entry points, then we can do without them, but it will mean that the *jmp() functions cannot be used in conjunction with thread cleanup handlers when using LinuxThreads. Jason Index: i386/gen/setjmp.S === RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v retrieving revision 1.11 diff -u -r1.11 setjmp.S --- setjmp.S1999/10/10 08:38:33 1.11 +++ setjmp.S1999/12/09 02:07:45 @@ -54,6 +54,7 @@ #include "DEFS.h" #include "SYS.h" +ENTRY(__setjmp) ENTRY(setjmp) movl4(%esp),%ecx PIC_PROLOGUE @@ -80,6 +81,7 @@ xorl%eax,%eax ret +ENTRY(__longjmp) ENTRY(longjmp) movl4(%esp),%edx PIC_PROLOGUE Index: i386/gen/sigsetjmp.S === RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v retrieving revision 1.13 diff -u -r1.13 sigsetjmp.S --- sigsetjmp.S 1999/09/29 15:18:35 1.13 +++ sigsetjmp.S 1999/12/09 02:07:45 @@ -59,6 +59,7 @@ * use sigreturn() if sigreturn() works. */ +ENTRY(__sigsetjmp) ENTRY(sigsetjmp) movl8(%esp),%eax movl4(%esp),%ecx @@ -89,6 +90,7 @@ xorl%eax,%eax ret +ENTRY(__siglongjmp) ENTRY(siglongjmp) movl4(%esp),%edx cmpl$0,44(%edx) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: question about boot loaders
dcs suggests that the correct answer is: mbr is a replacement for boot0, without the OS choices. This seems to make sense, so I'll go with that unless someone has a better idea :-). We assume that you would never, therefore, use both mbr and boot0, explaining why there doesn't need to be an extra 512 bytes somewhere :-). Thanks, On Thu, 9 Dec 1999, Neil Blakey-Milner wrote: On Thu 1999-12-09 (02:46), Robert Watson wrote: Once we get into boot2 land, I recognize the FreeBSD-specific loading code, etc. What I don't know much about is those first three 512-byte chunks of code. Boot0 appears to be booteasy, but given some ignorance about the i386 boot process, I'm not sure whether it's loaded by mbr, or by the bios, and where it lives partition-wise. Similarly, how boot1 fits into it the whole scheme--I assume this is FreeBSD-specific as it knows about boot2, but don't know where it lives, etc. Preferably, afterwards, also drop the results into sys/boot/i386/README. :-) I wrote up some basic stuff, which doesn't seem quite to describe what you're after, but which may be of use, at http://rucus.ru.ac.za/~nbm/boot/ It's intended for the handbook, but I haven't had time since starting my new job to work on it much more. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
Jason Evans wrote: I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2) running, but ran into a couple of minor problems integrating with our libc. LinuxThreads redefines a number of functions in order to make them either support thread cancellation or work correctly. The following functions need an alternative name, just as, for example, write() is actually _write(): lseek() pause() system() tcdrain() wait() waitpid() recv() send() This would allow implementing cancellation points for these functions. All in all, I won't lose much sleep over this, but if it's easy to do and doesn't violate some rule of symbol naming, it would be nice. You know about weak symbol redirection, right? It basically allows runtime resolution of symbols instead of link time. So, you could have a weak pointer from lseek to _lseek and provide a _lseek function in libc. When programs link against "lseek" (including within libc itself), they hold a pointer to the non-redirected name. If you *also* provide a "lseek" in libpthreads from linuxthreads, then at runtime everything (including libc) will use the lseek() in the thread library and not _lseek(). Look for __weak_reference() etc, there are some examples in libc/net/* (but those are for different problems). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
firewall problem?
Hi I´m sitting behind a firewall consisting av FreeBsd and Squid. My mail program is Popper. I can mail to (and from) every adress I´ve tried - except freebsd.org. Here´s the error. The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET) from [192.168.1.2] - The following addresses had transient non-fatal errors - [EMAIL PROTECTED] - Transcript of session follows - .. while talking to hub.freebsd.org.: RCPT To:[EMAIL PROTECTED] 450 Client host rejected: cannot find your hostname, [62.20.54.54] [EMAIL PROTECTED]... Deferred: 450 Client host rejected: cannot find your hostname, [62.20.54.54] Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old Reporting-MTA: dns; hyndan.gbg.abf.se Arrival-Date: Wed, 8 Dec 1999 16:40:08 +0100 (CET) Final-Recipient: RFC822; [EMAIL PROTECTED] Action: delayed Status: 4.2.0 Remote-MTA: DNS; hub.freebsd.org Diagnostic-Code: SMTP; 450 Client host rejected: cannot find your hostname, [62.20.54.54] Last-Attempt-Date: Wed, 8 Dec 1999 20:52:11 +0100 (CET) Will-Retry-Until: Mon, 13 Dec 1999 16:40:08 +0100 (CET) Return-Path: [EMAIL PROTECTED] Received: from ralph ([192.168.1.2]) by hyndan.gbg.abf.se (8.9.3/8.9.3) with ESMTP id QAA63400; Wed, 8 Dec 1999 16:40:08 +0100 (CET) Message-Id: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Dec 1999 17:45:52 +0100 To: [EMAIL PROTECTED] From: Ralph Utbult [EMAIL PROTECTED] Subject: Test - ignore! Cc: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed What is the problem? Regards, Ralph Utbult Systems Operator ABF Göteborg Sweden Gratis epost med TJOHOOMAIL http://www.tjohoo.se To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: firewall problem?
Ralph Utbult wrote: Hi I´m sitting behind a firewall consisting av FreeBsd and Squid. My mail program is Popper. I can mail to (and from) every adress I´ve tried - except freebsd.org. Here´s the error. The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET) from [192.168.1.2] - The following addresses had transient non-fatal errors - [EMAIL PROTECTED] - Transcript of session follows - .. while talking to hub.freebsd.org.: RCPT To:[EMAIL PROTECTED] 450 Client host rejected: cannot find your hostname, [62.20.54.54] [EMAIL PROTECTED]... Deferred: 450 Client host rejected: cannot find your hostname, [62.20.54.54] Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old Reporting-MTA: dns; hyndan.gbg.abf.se [snip] No, name server problem. `hyndan.gbg.abf.se' resolves to `62.20.54.54'. But `62.20.54.54' resolves to `Non-existent host/domain' Check your name server's PTR records. Richard. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2) running, Great! but ran into a couple of minor problems integrating with our libc. LinuxThreads redefines a number of functions in order to make them either support thread cancellation or work correctly. The following functions need an alternative name, just as, for example, write() is actually _write(): lseek() pause() system() tcdrain() wait() waitpid() recv() send() This would allow implementing cancellation points for these functions. All in all, I won't lose much sleep over this, but if it's easy to do and doesn't violate some rule of symbol naming, it would be nice. It's my impression that glibc uses a three (four?) tiered naming convention. The "pure" syscall (in our case, eg. _write()). Then there is the version used internally in glibc (eg. _libc_write(). And finally, the version exported from glibc (eg. write()). The merit to the three tiered system is that you might need to rewrite the version used internally to libc for threads, but still have this be different from the version exported from the library (eg. to implement cancallation points without propagating them throughout libc). In this case, you'd want, for example, an _lseek(), _libc_lseek(), and _seek(). The problem with cancellation points, libc and linuxthreads has been that you need to wade through libc and replace instances of, for example, write() with either _write() or _libc_write() in order to avoid propagating cancellation points where they don't belong. The other issue has to do with longjmp() and siglongjmp(), and is of a similar nature, except that _longjmp() already exists as a separate interface. So, at least in the case of longjmp(), it needs to have a different alias, perhaps __longjmp(). Below is a *very* simplistic patch to libc that works, but it may make some people's skin crawl. Feedback is welcome. If there is no correct way to create aliases to function entry points, then we can do without them, but it will mean that the *jmp() functions cannot be used in conjunction with thread cleanup handlers when using LinuxThreads. __longjmp() and __siglongjmp() don't bother me at all. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Weird output from vmstat -m?
The recent discussion about route table leaks led me to check some of my systems. On one of them I got this: bash-2.03$ uname -srm FreeBSD 3.2-RELEASE i386 bash-2.03$ uptime 7:45AM up 28 days, 12:38, 3 users, load averages: 0.61, 0.50, 0.43 bash-2.03$ vmstat -m | grep routetbl | grep K routetbl60 8K 15K 40960K 18700 0 16,32,64,128,256 routetbl60 8K 15K 40960K 18700 0 16,32,64,128,256 routetbl60 8K 15K 40960K 18700 0 16,32,64,128,256 Eh... *Three* entries? In fact, lots of stuff is triplicated (or more): bash-2.03$ vmstat -m | sort | less [snip] kld1679K 84K 40960K 400 0 16,32,128,512,1K,4K,8K,64K kld1679K 84K 40960K 400 0 16,32,128,512,1K,4K,8K,64K kld1679K 84K 40960K 400 0 16,32,128,512,1K,4K,8K,64K kld1679K 84K 40960K 400 0 16,32,128,512,1K,4K,8K,64K [etc] And this: bash-2.03$ vmstat -m | less [snip] 64 file, lockf, namecache, devbuf, temp, session, shm, pcb, cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon, file, lockf, namecache, devbuf, temp, session, shm, pcb, cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon, file, lockf, namecache, devbuf, temp, session, shm, pcb, cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon, file This doesn't look healthy to me. I didn't see anything about this in the archives... -- Robert Withrow -- (+1 978 288 8256) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sequence of Events in Kernel source?
Greetings Seniors. I am interested in establishing the sequence of events from a source code perspective from when the PC is switched on, to the login prompt. I am specifically interested in the setting up of lower level stuff like the drivers. memory etc. Can anyone please take a moment and give me some pointers? Kind regards eT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: tty level buffer overflows
We're seeing it with our ppp link, which uses the kernel level ppp code. Since it doesn't happen for me often, it is hard to diagnose. You could set up a 486 (386?) and have it chew on a tonne of ipfw rules. If it is due to ipfw load, you should be able to force the problem to be reproduced by scaling down the hardware. Kees Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ifconfig panic using 3C574 card
I just upgraded my laptop to use a fresh current from this morning (fresh checkout with empty /usr/obj). The machine is an IBM ThinkPad 760XD with 88Mb RAM. Now when the ep driver attaches my 3COM 3C574 it reports the following mac address: ep0: 3Com 3C574 at port 0x240-0x25f irq 10 slot 0 on pccard0 ep0: Ethernet address 40:57:40:57:40:57 ep0: strange connector type in EEPROM: assuming AUI The error is mostly harmless as the card is functionning otherwise. (I'm not speaking about performances which are not very good right now). Now to the subject, when I run ifconfig on the machine, I instantly got the following panics. I guess that the second one is only an artefact of the first one and should not be considered. dmesg, pccardc dumpcis and config file follows. If you need anything else let me know. I'll try to look into this as soon as I get a few minutes (well, when I get the damn video console working on my 'winder). Steph Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xc71a6de8 frame pointer = 0x10:0xc71a6e0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 266 (ifconfig) interrupt mask = net kernel: type 12 trap, code=0 Stopped at 0: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01bc10c stack pointer = 0x10:0xc71a6c54 frame pointer = 0x10:0xc71a6c58 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resule, IOPL = 0 current process = 266 (ifconfig) interrupt mask = net kernel: type 12 trap, code=0 symbols near 0xc01bc10c: c01bc0f0 T db_read_bytes c01bc128 T db_write_bytes dmesg output: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Thu Dec 9 08:39:31 EST 1999 [EMAIL PROTECTED]:/mnt/.0/src/sys/compile/AZIMOV Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (165.79-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x544 Stepping = 4 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 92274688 (90112K bytes) avail memory = 86859776 (84824K bytes) Preloaded elf kernel "kernel" at 0xc0269000. Intel Pentium detected, installing workaround for F00F bug npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371FB PCI to ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pcic-pci0: TI PCI-1130 PCI-CardBus Bridge at device 2.0 on pci0 pcic-pci1: TI PCI-1130 PCI-CardBus Bridge at device 2.1 on pci0 vga-pci0: Trident model 9660 VGA-compatible display device irq 11 at device 3.0 on pci0 pci0: unknown card (vendor=0x1014, dev=0x0057) at 5.0 irq 11 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 ata0 at port 0x1f0 irq 14 on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold pcic: polling, can't alloc 0 pcic: polling, can't alloc 0 pcic0: Intel i82365 on isa0 pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A ppc0 at port 0x3bc-0x3c3 irq 7 on isa0 isa_compat: didn't get ports for ppc ppc0: PC87334 chipset (ECP/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ad0: IBM-DLGA-23080/A50D52 ATA-3 disk at ata0 as master ad0: 2937MB (6015744 sectors), 5968 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, PIO acd0: SANYO CRD-S58P/1.21 CDROM drive at ata0 as slave acd0: read 1377KB/s (1377KB/s), 256KB buffer, PIO acd0: supported read types: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted pccard: card inserted, slot 0 ep0: 3Com 3C574 at port 0x240-0x25f irq 10 slot 0 on pccard0 ep0: Ethernet address 40:57:40:57:40:57 ep0: strange connector type in EEPROM: assuming AUI 'pccardc dumpcis' output: Configuration data for card in
Veritas Software Now Shipping With Linux
http://news.excite.com/news/r/991209/09/tech-veritas-linux Veritas Software Now Shipping With Linux MOUNTAIN VIEW, Calif. (Reuters) Veritas Software Corp. (VRTS.O) said on Thursday its software used to backup data on computer systems is being shipped with Red Hat Inc.'s Linux 6.1 Delux product. "This is the first step as a result of the agreement we announced in early November to jointly develop enterprise storage management solutions for the Red Hat Linux marketplace," Paul McNamara, general manager of the enterprise business unit at Red Hat, said. Linux is a free version of the Unix operating system that was developed by Finnish programmer Linus Torvalds and a network of programmers. It is an alternative to Microsoft Corp.'s Windows NT for some applications. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Faster Malloc
Alfred Perlstein [EMAIL PROTECTED] wrote: (regarding Hoard: http://www.cs.utexas.edu/users/emery/hoard) This allocator is pretty much what the Dynix allocator is, it wouldn't be difficult to clean-room implement this with a BSD license. They should have given credit to Dynix or at least Uresh Vahalia (discussed on page 390 of his book Unix Internals section 12.9). Hi all, The DYNIX kernel allocator was by McKenney and Slingwine, and I'll be citing them in a revised version of the paper. While there are a number of differences between my allocator (Hoard) and theirs, the most important are locality related. I'll just bring up one here: false sharing. Using the McKenney Slingwine allocator (or the new Cilk allocator, discussed in my paper), a cache line can end up distributed across every CPU's free list and repeatedly re-used. This happens because freed blocks are placed back on a CPU's own freelist. This effect has been observed in practice and can dramatically worsen application performance. Hoard prevents this effect. Each superblock is owned by exactly one processor. When processor A free()'s a block from another CPU's superblock, it is put back in the superblock, and so will not be re-used by processor A's next malloc(). Regards, -- Emery -- Emery Berger | Parallel Programming [EMAIL PROTECTED]| Multiprogramming MP Groups http://www.cs.utexas.edu/users/emery | University of Texas at Austin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: firewall problem?
your ip address 62.20.54.54 is not in DNS, you must have your address in DNS. we do not accept email from machines that do not have entries in DNS. amny spammer use addresses that do not appear in DNS jmb Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Mailer: TjohooMAIL X-WebsiteUser-IP: 62.20.54.54 From: Ralph Utbult [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: Quoted-printable Date: Thu, 9 Dec 1999 03:35:26 -0800 (PST) Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk Hi I=B4m sitting behind a firewall consisting av FreeBsd and Squid. My mail pr= ogram is Popper. I can mail to (and from) every adress I=B4ve tried - excep= t freebsd.org. Here=B4s the error. The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET) from [192.168.1.2] - The following addresses had transient non-fatal errors - [EMAIL PROTECTED] - Transcript of session follows - .. while talking to hub.freebsd.org.: RCPT To:[EMAIL PROTECTED] 450 Client host rejected: cannot find your hostname, [62.20.54.54] [EMAIL PROTECTED]... Deferred: 450 Client host rejected: cannot= find your hostname, [62.20.54.54] Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old Reporting-MTA: dns; hyndan.gbg.abf.se Arrival-Date: Wed, 8 Dec 1999 16:40:08 +0100 (CET) Final-Recipient: RFC822; [EMAIL PROTECTED] Action: delayed Status: 4.2.0 Remote-MTA: DNS; hub.freebsd.org Diagnostic-Code: SMTP; 450 Client host rejected: cannot find your hostname,= [62.20.54.54] Last-Attempt-Date: Wed, 8 Dec 1999 20:52:11 +0100 (CET) Will-Retry-Until: Mon, 13 Dec 1999 16:40:08 +0100 (CET) Return-Path: [EMAIL PROTECTED] Received: from ralph ([192.168.1.2]) by hyndan.gbg.abf.se (8.9.3/8.9.3) with ESMTP id QAA63400; Wed, 8 Dec 1999 16:40:08 +0100 (CET) Message-Id: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Dec 1999 17:45:52 +0100 To: [EMAIL PROTECTED] From: Ralph Utbult [EMAIL PROTECTED] Subject: Test - ignore! Cc: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed What is the problem? Regards, Ralph Utbult Systems Operator ABF G=F6teborg Sweden Gratis epost med TJOHOOMAIL http://www.tjohoo.se To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: question about boot loaders
On Thu, 9 Dec 1999, Robert Watson wrote: loaderloadedbyfunction mbr BIOSwhatever, maybe a couple of lines /boot/mbr is a copy of the classic DOS MBR code. Used by fdisk. Simply loads the partition marked as 'active' (flag 0x80). Everything else was covered in Neil's handbook piece (which I should probably grab commit! :-) ) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: In this case, you'd want, for example, an _lseek(), _libc_lseek(), and _seek(). I meant "and lseek()", not _seek(). -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Veritas Software Now Shipping With Linux
Yes- this also concerned and annoyed the folks at Legato. It puts *me* in a bit of a bind because I have had business ties to both companies (I still do (at a very slow rate) Legato NetWorker client packages for *BSD and non-Intel Linux). On Thu, 9 Dec 1999, Charles Randall wrote: http://news.excite.com/news/r/991209/09/tech-veritas-linux Veritas Software Now Shipping With Linux MOUNTAIN VIEW, Calif. (Reuters) Veritas Software Corp. (VRTS.O) said on Thursday its software used to backup data on computer systems is being shipped with Red Hat Inc.'s Linux 6.1 Delux product. "This is the first step as a result of the agreement we announced in early November to jointly develop enterprise storage management solutions for the Red Hat Linux marketplace," Paul McNamara, general manager of the enterprise business unit at Red Hat, said. Linux is a free version of the Unix operating system that was developed by Finnish programmer Linus Torvalds and a network of programmers. It is an alternative to Microsoft Corp.'s Windows NT for some applications. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
printf() from KLD
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED] Be sure to reply to that address. Hello, I use printf() function from my KLD for debugging. Always, when the kernel call printf, I see two same line, like : Dec 9 15:40:10 techno /kernel: message Dec 9 15:40:10 techno /kernel: message How can I remvoe second line? Thank you. Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: The problem with cancellation points, libc and linuxthreads has been that you need to wade through libc and replace instances of, for example, write() with either _write() or _libc_write() in order to avoid propagating cancellation points where they don't belong. Now I understand why you claimed that making cancellation work is a lot of work. Since that isn't currently done, do you think it would be better to leave broken cancellation in the LinuxThreads port, or to take it out? As things stand right now, "broken" means: 1) Not all mandatory cancellation points are implemented. 2) Some functions may act as cancellation points, even though they shouldn't. We can fix 1) with some symbol munging, but 2) is much more difficult, as you point out. The other issue has to do with longjmp() and siglongjmp(), and is of a similar nature, except that _longjmp() already exists as a separate interface. So, at least in the case of longjmp(), it needs to have a different alias, perhaps __longjmp(). Below is a *very* simplistic patch to libc that works, but it may make some people's skin crawl. Feedback is welcome. If there is no correct way to create aliases to function entry points, then we can do without them, but it will mean that the *jmp() functions cannot be used in conjunction with thread cleanup handlers when using LinuxThreads. __longjmp() and __siglongjmp() don't bother me at all. Following is a slightly better patch that uses weak aliases. longjmp() must be an alias for __longjmp() since _longjmp() is a public interface. However, siglongjmp() could be an alias for either _siglongjmp() or __siglongjmp(). Is _siglongjmp() more consistent? Of course, this doesn't matter at all if we leave out cancellation entirely. Index: i386/gen/setjmp.S === RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v retrieving revision 1.11 diff -u -r1.11 setjmp.S --- setjmp.S1999/10/10 08:38:33 1.11 +++ setjmp.S1999/12/09 20:53:11 @@ -54,7 +54,9 @@ #include "DEFS.h" #include "SYS.h" -ENTRY(setjmp) +ENTRY(__setjmp) +.weak setjmp; +.set setjmp, __setjmp; movl4(%esp),%ecx PIC_PROLOGUE leal28(%ecx), %eax @@ -80,7 +82,9 @@ xorl%eax,%eax ret -ENTRY(longjmp) +ENTRY(__longjmp) +.weak longjmp; +.set longjmp, __longjmp; movl4(%esp),%edx PIC_PROLOGUE pushl $0 /* (sigset_t*)oset */ Index: i386/gen/sigsetjmp.S === RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v retrieving revision 1.13 diff -u -r1.13 sigsetjmp.S --- sigsetjmp.S 1999/09/29 15:18:35 1.13 +++ sigsetjmp.S 1999/12/09 20:53:11 @@ -59,7 +59,9 @@ * use sigreturn() if sigreturn() works. */ -ENTRY(sigsetjmp) +ENTRY(__sigsetjmp) +.weak sigsetjmp; +.set sigsetjmp, __sigsetjmp; movl8(%esp),%eax movl4(%esp),%ecx movl%eax,44(%ecx) @@ -89,7 +91,9 @@ xorl%eax,%eax ret -ENTRY(siglongjmp) +ENTRY(__siglongjmp) +.weak siglongjmp; +.set siglongjmp, __siglongjmp; movl4(%esp),%edx cmpl$0,44(%edx) jz 2f To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf() from KLD
Alex writes: This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED] Be sure to reply to that address. Hello, I use printf() function from my KLD for debugging. Always, when the kernel call printf, I see two same line, like : Dec 9 15:40:10 techno /kernel: message Dec 9 15:40:10 techno /kernel: message How can I remvoe second line? Thank you. man syslog.conf Your message is matching more than one rule (eg, "root" and "console"). -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
Re: Possible libc changes to support LinuxThreads
Jason Evans wrote: On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: The problem with cancellation points, libc and linuxthreads has been that you need to wade through libc and replace instances of, for example, write() with either _write() or _libc_write() in order to avoid propagating cancellation points where they don't belong. Now I understand why you claimed that making cancellation work is a lot of work. Since that isn't currently done, do you think it would be better to leave broken cancellation in the LinuxThreads port, or to take it out? As things stand right now, "broken" means: 1) Not all mandatory cancellation points are implemented. 2) Some functions may act as cancellation points, even though they shouldn't. We can fix 1) with some symbol munging, but 2) is much more difficult, as you point out. Have you looked at what NetBSD did with namespace? See: http://www.freebsd.org/cgi/cvsweb.cgi/basesrc/lib/libc/include/namespace.h?rev=1.42cvsroot=netbsd Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sequence of Events in Kernel source?
On Thu, 9 Dec 1999, Etienne De Bruin wrote: Greetings Seniors. I am interested in establishing the sequence of events from a source code perspective from when the PC is switched on, to the login prompt. I am specifically interested in the setting up of lower level stuff like the drivers. memory etc. Can anyone please take a moment and give me some pointers? Kind regards eT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message check the old bootblocks /usr/src/sys/i386/boot/biosboot for README.386BSD, README.MACH, README.serial for some background. then try find documentation (good luck) on the NEW bootblocks /usr/src/sys/boot/README is a start. The kernel starts in /sys/i386/i386/locore.s (at btext I think) then goes (from memory) to main() via mi_startup (I think). mi_startup is in init_main.c. mi_startup calls all teh initialisation modules linked into the kernel. (see kernel.h) eventually it starts up init.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
On Thu, Dec 09, 1999 at 12:57:45PM -0800, Jason Evans wrote: On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: The problem with cancellation points, libc and linuxthreads has been that you need to wade through libc and replace instances of, for example, write() with either _write() or _libc_write() in order to avoid propagating cancellation points where they don't belong. Now I understand why you claimed that making cancellation work is a lot of work. Since that isn't currently done, do you think it would be better to leave broken cancellation in the LinuxThreads port, or to take it out? As things stand right now, "broken" means: 1) Not all mandatory cancellation points are implemented. 2) Some functions may act as cancellation points, even though they shouldn't. We can fix 1) with some symbol munging, but 2) is much more difficult, as you point out. I think #2 above is very dangerous, since you can get a cancellation point unexpectedly while the thread holds resources (eg a lock). If you cancel while holding a lock, you could deadlock. This could even happen within libc, where (for example) fread puts a lock around the read syscall. If read is a cancellation point, the libc lock for the FILE pointer won't get released (at least I don't think it will). A user app could have the same problem if there are unexpected cancellation points. The original linuxthreads port left the cancellation functions in, but didn't do any syscall wrapping to implement libc cancellation points. A user app can create cancellation points with pthread_test_cancel(), which helps a little, but he doesn't get the POSIX libc cancellation points. Actually, I don't think all that many apps use pthread_cancel(). Its kind of messy to use. Most can get along without it, which is why there have only been a limited number of complaints about the lack of pthread_cancel() in libc_r (until recently). BTW, I haven't looked at libc_r's new cancellation functions. How do they avoid propagating cancellation points in libc without changing libc? Maybe they have an idea that can be used here? -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: question about boot loaders
The documentation in /usr/src/sys/boot/i386 seems a little scant, and that still hanging out in /usr/src/sys/i386/boot is clearly outdated. Was wondering if someone could point me at docs, and/or post a short summary something in the form of: http://www.freebsd.org/~msmith/FTL/tutorials/bootloader.txt It's incomplete and a little out of date, but I think it covers the questions you're asking. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf() from KLD
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED] Be sure to reply to that address. Hello, I use printf() function from my KLD for debugging. Always, when the kernel call printf, I see two same line, like : Dec 9 15:40:10 techno /kernel: message Dec 9 15:40:10 techno /kernel: message How can I remvoe second line? Read the manpages related to syslogd(8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
We are having a similar problem at the job I just started. A box meeting the exact specifications that Mike said caused the problem is essentially having the crap beat out of it as far as disk access and network activity (it might help to also say that this company is rather large in the scheme of things and would be a good example of how to use FreeBSD in a large enterprise environment). It is the only box out of alot of them having this problem, but its also the only one thats getting beat up as much as this one. it would be great if Peter could post his "patch" for the problem (how to migrate the -CURRENT driver into the 3.3 source) from what you say, Ed, it stands up a bit better than the current driver does, and can only probably get better. While this machine will probably be replaced with a different machine, FreeBSD is somewhat of a "Pride and Joy" here. -Pat -- Pat Lynch [EMAIL PROTECTED] [EMAIL PROTECTED] Systems Administrator Rush Networking To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
Richard Seaman, Jr. wrote: Actually, I don't think all that many apps use pthread_cancel(). Its kind of messy to use. Most can get along without it, which is why there have only been a limited number of complaints about the lack of pthread_cancel() in libc_r (until recently). BTW, I haven't looked at libc_r's new cancellation functions. How do they avoid propagating cancellation points in libc without changing libc? Maybe they have an idea that can be used here? Hi Richard, Libc_r doesn't avoid propagating cancellation points. A read() from within a libc(_r) function will still be a cancellation point. We had to weigh the lack of having pthread_cancel() versus having pthread_cancel() with non-standard cancellation points. In the end, only those applications that use pthread_cancel() are affected. I think the number of complaints saying "Hey, pthread_cancel support has non-standard cancellation points" will be less than the number of complaints because we don't have _any_ pthread_cancel support. Well, that's what I hope anyways ;-) Time will probably prove me wrong... Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote: Richard Seaman, Jr. wrote: Actually, I don't think all that many apps use pthread_cancel(). Its kind of messy to use. Most can get along without it, which is why there have only been a limited number of complaints about the lack of pthread_cancel() in libc_r (until recently). BTW, I haven't looked at libc_r's new cancellation functions. How do they avoid propagating cancellation points in libc without changing libc? Maybe they have an idea that can be used here? Hi Richard, Libc_r doesn't avoid propagating cancellation points. A read() from within a libc(_r) function will still be a cancellation point. Hmm.. What happens with (for example) fread() ? fread, in the thread safe version, can be: lock FILE pointer read unlock FILE pointer If fread is a cancellation point, don't you end up with the lock held still? Or, I guess since you keep track of lock owners you can unwind the locks if the thread cancels? -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
On Thu, 9 Dec 1999, Richard Seaman, Jr. wrote: On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote: Richard Seaman, Jr. wrote: Actually, I don't think all that many apps use pthread_cancel(). Its kind of messy to use. Most can get along without it, which is why there have only been a limited number of complaints about the lack of pthread_cancel() in libc_r (until recently). BTW, I haven't looked at libc_r's new cancellation functions. How do they avoid propagating cancellation points in libc without changing libc? Maybe they have an idea that can be used here? Hi Richard, Libc_r doesn't avoid propagating cancellation points. A read() from within a libc(_r) function will still be a cancellation point. Hmm.. What happens with (for example) fread() ? fread, in the thread safe version, can be: lock FILE pointer read unlock FILE pointer If fread is a cancellation point, don't you end up with the lock held still? Or, I guess since you keep track of lock owners you can unwind the locks if the thread cancels? Yes, we keep track of all internal locks and release them when the thread is cancelled. The only think not released just yet are standalone (not part of other locks, like file, mutex, condvar, etc) spinlocks. For instance the spinlock that protects malloc() wouldn't be released. It's easy enough to fix those with setting/clearing of lock wanted flags and/or held lock counts, but I'd thought I'd try to borrow a trick from the SA paper. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Crypto in the kernel: where how?
What is the plan (if any) for including crypto stuff in the kernel? As time goes on this will be more and more needed, eg. for IPSec and other VPN applications. It would be nice if we had a /usr/src/sys/crypt directory, plus whatever export-controlled firewalling silliness is necessary. Proposal.. (to get things started) - Add /usr/src/sys/crypt directory - Put exportable crypto stuff in it, eg, md5.c. - Put non-exportable crypto stuff in the international repository (which is where?) .. and possibly a separate US repository (?) (Or can the CVSup mirrors be configured not to mirror it?) My ulterior motive is to checkin netgrapph/ng_mppc.c which adds MPPE/MPPC support for PPTP. However it's useless without an [A]RC4 implementation. -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
Re: Crypto in the kernel: where how?
On Thu, 9 Dec 1999 17:01:38 -0800 (PST) Archie Cobbs [EMAIL PROTECTED] wrote: What is the plan (if any) for including crypto stuff in the kernel? As time goes on this will be more and more needed, eg. for IPSec and other VPN applications. At NetBSD, we already solved this problem with some simple changes to our config(8). Also, we put e.g. md5 and sha1 in libkern (the kernel's `libc'), since they're in libc for userland. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Upgrading rdist to v6.1.5 in -CURRENT?
On Tue, Dec 07, 1999 at 10:13:34PM -0500, C. Stephen Gunn wrote: I'll send-pr the recipe, and post a reference here when I document how I worked around some of the magnicomp guys's kludged makefiles/includes. I've send-pr'd my attempt at getting this ready for import. (bin/15390) You can fetch a tarball (relative to /usr/src) from: http://www.physics.purdue.edu/~csg/rdist-freebsd.tar.gz There's a readme file in what would become contrib/rdist/README-FreeBSD that documents my pruning of the distribution, and applied patches. I was a little disgusted with my soltion for building gram.h from the yacc grammar for rdistd to use. If someone with more make/import experience sees a better solution, let me know. - Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
What is the plan (if any) for including crypto stuff in the kernel? As time goes on this will be more and more needed, eg. for IPSec and other VPN applications. The KAME/IPv6 guys have already brought this up; the agreement was that... It would be nice if we had a /usr/src/sys/crypt directory, plus whatever export-controlled firewalling silliness is necessary. ...a sys/crypt/ directory should hold their DES code. :-) Proposal.. (to get things started) - Add /usr/src/sys/crypt directory The CTM things aleady know about this dir. My ulterior motive is to checkin netgrapph/ng_mppc.c which adds MPPE/MPPC support for PPTP. However it's useless without an [A]RC4 implementation. I'd like DES, arc4 and MD5/SHA for Yarrow. 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
