Re: NCR/FXP and coredumps
> > 1) I managed to crash an intel N440BX mobo with an fxp card and the > > onboard ncr drivers. Lots of network traffic (ping floods) and disk IO > > (rawio in parallel on two disks) took it down in something like two > > hours. I know this is a known bug, I'm just offering core dumps and > > testing services in fixing it if anyone wants to take a stab at it. > > DG has looked at this extensively and the current feeling is that this is > a hardware bug. Using the sym driver instead of the ncr driver > apparently helps somewhat, but the problem still happens. The generally > recommended option is to buy an Adaptec SCSI controller and use that > instead of the on-board SCSI. That works flawlessly. I can confirm that the sym driver has cured all such problems for us. Not a single crash after switching to the sym driver. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Tiny GENERIC patch
I was doing some kernel debugging tonight and decided that I needed a backup plan. Since I already had built my test kernel I thought the attached would be a good idea. It has the added benefit of moving the existing kernel.GENERIC to kernel.GENERIC.old in the 'make install' step. Wording in the comment could probably be better... FWIW, Doug -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu." Index: GENERIC === RCS file: /usr/ncvs/src/sys/i386/conf/GENERIC,v retrieving revision 1.249 diff -u -r1.249 GENERIC --- GENERIC 2000/03/21 17:00:58 1.249 +++ GENERIC 2000/03/23 07:47:11 @@ -26,6 +26,7 @@ maxusers 32 #makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols +makeoptionsKERNEL=kernel.GENERIC #Remove for building a custom kernel optionsMATH_EMULATE#Support for x87 emulation optionsINET#InterNETworking
Is this a bug?
While making a slew of diskless machines I've tracked down a kernel panic.
FreeBSD 4.0-RELEASE, kernel with BOOTP* enabled.
Each machine has a private and public network attached. It netboots from
the private network. Because of that, I didn't set a gw address in
bootptab. The public network interface is brought up by the rc scripts.
After booting, since there was no gateway, the BOOTP code makes an
assumption and sets itself as the gateway and therefore starts proxy-arp.
The relevant bit of code in ./nfs/bootp_subr.c:
if (!gotgw) {
/* Use proxyarp */
gw.sin_addr.s_addr = myaddr.sin_addr.s_addr;
}
While the network table is in this state, if you ping anything outside of
the local network it causes a kernel panic (unaligned access fault) the
kernel in ip_input:310
ie. From the console after boot, ping locally and it's fine. Ping anything
off the local subnet and the kernel panics. Definately don't start sendmail
with a non-local resolver. Also don't telnet into the box, causing a
request to a non-local resolver.
This was on an Alpha box. It may not reproduce on Intel, since it's more
tolerant of off-alignment memory access.
What I really need to know is, is this a bug or a is the proxy-arp gateway
assumption a desired behavior? While the routing table is in this state,
you're an errant IP packet away from a panic (:
Since setting a gateway which was unreachable until the public interface
came up didn't seem like a great idea to me, my solution was to program out
the offending assumptions. If gw isn't received in the bootp reply, no
default route is set. Diffs against ./nfs/boop_subr.c are available if the
default behavior is wrong or considered obsolete.
- Matt
--
Matthew Zahorik Director of Systems and Networking - BiznessOnline.com
[EMAIL PROTECTED] President of AlbanyNet Inc. - a BiznessOnline subsidiary
[EMAIL PROTECTED]Voice: (518) 292-1001 Fax: (518) 626-0793
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: NCR/FXP and coredumps
On Wed, Mar 22, 2000 at 10:50:47PM -0500, David Miller wrote: > Two item: > > 1) I managed to crash an intel N440BX mobo with an fxp card and the > onboard ncr drivers. Lots of network traffic (ping floods) and disk IO > (rawio in parallel on two disks) took it down in something like two > hours. I know this is a known bug, I'm just offering core dumps and > testing services in fixing it if anyone wants to take a stab at it. DG has looked at this extensively and the current feeling is that this is a hardware bug. Using the sym driver instead of the ncr driver apparently helps somewhat, but the problem still happens. The generally recommended option is to buy an Adaptec SCSI controller and use that instead of the on-board SCSI. That works flawlessly. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: possible bug in kernel/if_ether.c
:SMP 2 cpus
:IdlePTD 3100672
:initial pcb at 281960
:panicstr: page fault
:panic messages:
:---
:Fatal trap 12: page fault while in kernel mode
:mp_lock = 0002; cpuid = 0; lapic.id =
:fault virtual address = 0x8
:fault code = supervisor read, page not present
:instruction pointer = 0x8:0xc01997c8
:stack pointer = 0x10:0xff806fa4
:frame pointer = 0x10:0xff806fac
: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 = Idle
:interrupt mask = <- SMP: XXX
:trap number = 12
:panic: page fault
:mp_lock = 0002; cpuid = 0; lapic.id =
:boot() called on cpu#0
:
:syncing disks... 11 11
:...
:#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
:304 dumppcb.pcb_cr3 = rcr3();
:(kgdb) bt
:#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
:#1 0xc01549fc in poweroff_wait (junk=0xc0259c2f, howto=0)
:at ../../kern/kern_shutdown.c:554
:#2 0xc022983b in trap_fatal (frame=0xff806f64, eva=8)
:at ../../i386/i386/trap.c:924
:#3 0xc02294d1 in trap_pfault (frame=0xff806f64, usermode=0, eva=8)
:at ../../i386/i386/trap.c:817
:#4 0xc02290a3 in trap (frame={tf_fs = 1107296280, tf_es = 16,
: tf_ds = -1056178160, tf_edi = -1, tf_esi = 0, tf_ebp = -8360020,
: tf_isp = -8360048, tf_ebx = 0, tf_edx = -1071016096, tf_ecx = 1,
: tf_eax = -1056143360, tf_trapno = 12, tf_err = 0, tf_eip = -1072064568,
: tf_cs = 8, tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
:at ../../i386/i386/trap.c:423
:#5 0xc01997c8 in arpintr () at ../../netinet/if_ether.c:447
:
:
:--2oS5YaxWCcQjTEyO
:Content-Type: text/plain; charset=us-ascii
:Content-Description: kgdb crash1
:Content-Disposition: attachment; filename=snuffy2
:
:
:SMP 2 cpus
Very, very weird. Can you disassemble the 'arpintr' function from your
kernel binary?
gdb -k /kernel (or kernel.debug if you have it)
disassemble arpintr
:Fatal trap 12: page fault while in kernel mode
:mp_lock = 0102; cpuid = 1; lapic.id = 0100
:fault virtual address = 0x8
:fault code = supervisor read, page not present
:instruction pointer = 0x8:0xc01997c8
:stack pointer = 0x10:0xff80dfa4
I can't pinpoint the fault point since my kernel is compiled up
differently, but I suspect it's at the line I've indicated below.
Unfortunately, it makes no sense whatsoever because %ebx would have to
be NULL and that case already checked. I suspect the actual fault
address is somewhere else if you do the dissassembly it should help.
splx(s);
if (m == 0 || (m->m_flags & M_PKTHDR) == 0)
panic("arpintr");
if (m->m_len < sizeof(struct arphdr) &&
(m = m_pullup(m, sizeof(struct arphdr)) == NULL)) {
log(LOG_ERR, "arp: runt packet -- m_pullup failed.");
continue;
0xc01aa6b5 :testl %ebx,%ebx
---Type to continue, or q to quit---
0xc01aa6b7 :je 0xc01aa6bf
0xc01aa6b9 :testb $0x2,0x12(%ebx)
0xc01aa6bd :jne0xc01aa6cc
0xc01aa6bf :pushl $0xc0281c0e
0xc01aa6c4 :call 0xc015f700
0xc01aa6c9 : leal 0x0(%esi),%esi
0xc01aa6cc : cmpl $0x7,0xc(%ebx)
0xc01aa6d0 : jbe0xc01aa71c
0xc01aa6d2 : movl 0x8(%ebx),%ecx <
0xc01aa6d5 : testl %ecx,%ecx
0xc01aa6d7 : je 0xc01aa71c
0xc01aa6d9 : movzwl (%ecx),%eax
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
possible bug in kernel/if_ether.c
i have a new system, dual pentium 550's, 512meg ram, dual adaptec 29160,
realtek ethernet. (dmesg.boot enclosed)
it has been having intermittent reboots, with no syslog output.
i thought maybe we were having heat issues, or power issues, but maybe it
is a kernel bug.
i enabled dumpdev and now i have dumps.
(arg, and it just crashed while i was snarfing the attached info)
both crashes occur in the same place in the kernel.
i think maybe that indicates a potential kernel/driver bug.
please find attached:
dmesg.boot
gdb -k info - crash 0
gdb -k info - crash 1
last second info:
nuffy# ifconfig rl0
rl0: flags=8843 mtu 1500
inet 209.167.108.145 netmask 0xff80 broadcast 209.167.108.255
inet 209.167.108.146 netmask 0x broadcast 209.167.108.146
ether 00:00:21:ef:1d:a4
media: autoselect (none) status: active
supported media: autoselect 100baseTX 100baseTX 10baseT/UTP
10baseT/UTP 100baseTX
is it possible that the bug is being triggered because the driver has not
selected a media type?
i did notice that the ethernet performance sucked, but i wasn't sure if that
was because the machine i was ftp'ing to sucked, or because this interface
was not specifically set to a media.
i elected not to set the media, because the machine is remote from me, and
didn't want to have it lose the connection.
i will physically visit the machine tomorrow.
--
[ Jim Mercer [EMAIL PROTECTED] +1 416 506-0654 ]
[ Reptilian Research -- Longer Life through Colder Blood ]
[ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
...
SMP 2 cpus
IdlePTD 3100672
initial pcb at 281960
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0002; cpuid = 0; lapic.id =
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01997c8
stack pointer = 0x10:0xff806fa4
frame pointer = 0x10:0xff806fac
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 = Idle
interrupt mask = <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0002; cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks... 11 11
...
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc01549fc in poweroff_wait (junk=0xc0259c2f, howto=0)
at ../../kern/kern_shutdown.c:554
#2 0xc022983b in trap_fatal (frame=0xff806f64, eva=8)
at ../../i386/i386/trap.c:924
#3 0xc02294d1 in trap_pfault (frame=0xff806f64, usermode=0, eva=8)
at ../../i386/i386/trap.c:817
#4 0xc02290a3 in trap (frame={tf_fs = 1107296280, tf_es = 16,
tf_ds = -1056178160, tf_edi = -1, tf_esi = 0, tf_ebp = -8360020,
tf_isp = -8360048, tf_ebx = 0, tf_edx = -1071016096, tf_ecx = 1,
tf_eax = -1056143360, tf_trapno = 12, tf_err = 0, tf_eip = -1072064568,
tf_cs = 8, tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc01997c8 in arpintr () at ../../netinet/if_ether.c:447
SMP 2 cpus
IdlePTD 3100672
initial pcb at 281960
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0100
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01997c8
stack pointer = 0x10:0xff80dfa4
frame pointer = 0x10:0xff80dfac
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 = Idle
interrupt mask = <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0102; cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... 48 47 21
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc01549fc in poweroff_wait (junk=0xc0259c2f, howto=0)
at ../../kern/kern_shutdown.c:554
#2 0xc022983b in trap_fatal (frame=0xff80df64, eva=8)
at ../../i386/i386/trap.c:924
#3 0xc02294d1 in trap_pfault (frame=0xff80df64, usermode=0, eva=8)
at ../../i386/i386/trap.c:817
#4 0xc02290a3 in trap (frame={tf_fs = 1107296280, tf_es = 16,
tf_ds = -1056178160, tf_edi = -1, tf_esi = 1, tf_ebp = -8331348,
tf_isp = -8331376, tf_ebx = 0, tf_edx = -1071016096, tf_ecx = 16777217,
tf_eax = -1056133376, tf_trapno = 12, tf_err = 0, tf_eip = -1072064568,
tf_cs = 8, tf_eflags = 66118, tf_esp = 0, tf_ss = 1})
at ../../i386/i386/trap.c:423
#5 0xc01997c8 in arpintr () at ../../netinet/if_ether.c:447
Copyright (c) 1992-2000 The
RE: Question about PCI vendor 0x127a
> Still funny that www.pcisig.com doesn't list 0x127a ... It costs $2500 per year to be a member of the PCI-SIG. If you stop paying, they delete you from their vendor list. A lot of companies join just to get assigned a vendor id, then they stop paying after the first year. So if you want to know the vendor id of a company that's no longer paying dues, you have to look at the unofficial list maintained by Jim Boemler at http://www.yourvote.com/pci/. Allen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NCR/FXP and coredumps
Two item: 1) I managed to crash an intel N440BX mobo with an fxp card and the onboard ncr drivers. Lots of network traffic (ping floods) and disk IO (rawio in parallel on two disks) took it down in something like two hours. I know this is a known bug, I'm just offering core dumps and testing services in fixing it if anyone wants to take a stab at it. 2) I have a production 3.2R system running on the same kind of hardware. I've done everything I did on the crashed system to try and pin down the problem but the core dumps are useless:( To review, I added 'makeoptions DEBUG="-g"' to the file, relinked the kernel, cp kernel to kernel.debug and ran "strip -g kernel". Booted on the new kernel. Added da0b to the rc.conf as the dumpdev, and added savecore -N /sys/compile/STAGING-1/kernel.debug /var/crash to /etc/ec. I get the coredumps fine: Mar 19 04:24:45 staging-1 savecore: reboot after panic: m_copym Mar 19 04:24:45 staging-1 savecore: writing core to /var/crash/vmcore.3 Mar 19 04:25:49 staging-1 savecore: writing kernel to /var/crash/kernel.3 But they don't seem to work:( staging-1:STAGING-1# gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.3 (kgdb) core-file /var/crash/vmcore.3 IdlePTD 2985984 kernel symbol `gd_curpcb' not found. (kgdb) where No stack. (kgdb) Any ideas? This is about the most important box I have, and it's crashing once or twice per week. The core dump I could examine for 1) was from a 3.4-stable system. The dirty details: FreeBSD 3.2R, as shipped on CD kernel config file pretty standard - single CPU, most unnecessary drivers commented out, available to anyone who wants to see it Hardware: TruSolutions 2U rack server with Intel N440BX mobo, onboard FXP and NCR, second Intel Pro 10/100B, two ibm fast wide scsi drives. Thanks, --- David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about PCI vendor 0x127a
On Wed, Mar 22, 2000 at 10:15:43PM -0500, Allen Pulsifer wrote: > >From http://www.yourvote.com/pci/ > > Rockwell Semiconductor Systems > 714-221-4600 > Vendor ID: 0x127A > Short Name: Rockwell Semi > Contact: [EMAIL PROTECTED] > Web Site: http://www.rockwell.com > > > Device ID: > 0x1002 > Chip Number: RC56HCFPCI > Description: Modem enumerator > > Device ID: > 0x1025 > Description: PCI modem > > Device ID: > 0x2005 > Chip Number: RS56/SP-PCI11P1 > Description: Single chip 56K V90 modem/spkrphone > > Device ID: > 0x2014 > Description: PCI modem Ahh, right, the modem, I forgot about it. Still funny that www.pcisig.com doesn't list 0x127a in their list sorted by hex. > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Ulf Zimmermann > > Sent: Wednesday, March 22, 2000 9:59 PM > > To: [EMAIL PROTECTED] > > Subject: Question about PCI vendor 0x127a > > > > > > I have this Sony Notebook Z505R, running 4.0-RC3 and works great. But I > > noticed there is still one unknown card: > > > > pci0: (vendor=0x127a, dev=0x2005) at 11.0 irq 9 > > > > Checking out www.pcisig.com, this vendor id is not listed. Anyone have > > an idea what part of the notebook it could be ? > > > > -- > > Regards, Ulf. > > > > - > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Question about PCI vendor 0x127a
>From http://www.yourvote.com/pci/ Rockwell Semiconductor Systems 714-221-4600 Vendor ID: 0x127A Short Name: Rockwell Semi Contact: [EMAIL PROTECTED] Web Site: http://www.rockwell.com Device ID: 0x1002 Chip Number: RC56HCFPCI Description: Modem enumerator Device ID: 0x1025 Description: PCI modem Device ID: 0x2005 Chip Number: RS56/SP-PCI11P1 Description: Single chip 56K V90 modem/spkrphone Device ID: 0x2014 Description: PCI modem > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ulf Zimmermann > Sent: Wednesday, March 22, 2000 9:59 PM > To: [EMAIL PROTECTED] > Subject: Question about PCI vendor 0x127a > > > I have this Sony Notebook Z505R, running 4.0-RC3 and works great. But I > noticed there is still one unknown card: > > pci0: (vendor=0x127a, dev=0x2005) at 11.0 irq 9 > > Checking out www.pcisig.com, this vendor id is not listed. Anyone have > an idea what part of the notebook it could be ? > > -- > Regards, Ulf. > > - > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > 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
Question about PCI vendor 0x127a
I have this Sony Notebook Z505R, running 4.0-RC3 and works great. But I noticed there is still one unknown card: pci0: (vendor=0x127a, dev=0x2005) at 11.0 irq 9 Checking out www.pcisig.com, this vendor id is not listed. Anyone have an idea what part of the notebook it could be ? -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
nm output
I'm looking through a nm listing for a static (unstripped) binary, and I keep seeing these things with the name ".Ltext0". Anyone ever see these things, or have any idea what they are? Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3,4
On Wed, 22 Mar 2000, sdf dsg wrote: > When are the 3.4 release comming, and i dont want some beta things? 3.4 has been out for 4 months now. Please don't post this kind of thing to FreeBSD-hackers - it's not on-topic. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
On Wed, 22 Mar 2000, Jim Bryant wrote: > well, there are other ways to make a system slow to a crawl > #!/bin/csh > /usr/games/primes 1 4294967295 >&/dev/null& > [...] /etc/security/limits.conf get the idea? :) -Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
:In reply: :> This is cross-posted to both linux-kernel and freebsd-hackers, please :> set your replies properly. :> :> > I found the following by accident playing with PVM. If you start the :> > 'gexample' from the examples directory with dimension=1 and no of :> > tasks=32 on one machine, it becomes almost immediately completely un- :> > usable and begins with heavy swapping. Considering how much memory :> > would be necessary for this computation before starting it would have :> > avoided the trouble. : :well, there are other ways to make a system slow to a crawl : :a good preventative measure is to never give shell accounts unless :everyone is accountable. : :#!/bin/csh :/usr/games/primes 1 4294967295 >&/dev/null& :/usr/games/primes 1 4294967295 >&/dev/null& :/usr/games/primes 1 4294967295 >&/dev/null& :... Generally speaking if a user wants to crash a machine, he can crash a machine. We've probably 'fixed' a dozen crashability holes in the last year but the count comes from a virtually unlimited supply. Short of being ridiculously draconian there will always be a way to twist the resource limits you are given to take a machine down or DOS it into unusability. And resource limits do not cover every conceivable facet. For example, just before the 4.0 release it was found that one can easily run the kernel out of vm_map_entry resources by mmap()ing hundreds of thousands of tiny files. We added a vm.max_proc_mmap sysctl to control that. And it still quite easy to bypass the datasize resource limit through the use of MAP_ANON mmap's. What resource limits are good at doing is preventing 'stupid user' mistakes. For example, at BEST we capped the CGI exec time at 10 cpu seconds (else our web servers would build up hundreds of broken CGI processes), but we set it as a soft limit so users who know what they are doing can unlimit it. I imposed a 40 process and 64 descriptor limit as being reasonable, but that's still 2560 descriptors to a user trying to mess things up on purpose. Quotas are useful for preventing a user from accidently filling up a disk partition. For example, I had a 100MB quota on /tmp, but quotas can be bypassed in a number of ways - for example, excessive syslogging (log files are owned by root). Resource limits are useful for protecting against a purposeful DOS attack insofar as it is generally the script kiddies who don't know their asses from their fingers who are trying to crash the machines. There is no way to protect against someone who knows what they are doing. So, in conclusion, resource limits are absolutely necessary in keeping a multi-user machine running smoothly, but the necessity has virtually nothing to do with preventing purposeful attacks. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 100Bit Fast Ethernet EISA card - anyone?
On Wed, 22 Mar 2000, Wilko Bulte wrote: > On Tue, Mar 21, 2000 at 10:20:14PM -0500, Matthew N. Dodd wrote: > > On Tue, 21 Mar 2000, Wilko Bulte wrote: > > > An FDDI ISA card would not be much fun (performance wise) > > > > But they exist, as do ISA 100baseTX cards. :) > > Duh.. Considering the premium price FDDI always had that is a surprise to > me to be honest. Like a V8 in a VW Beetle ;-) > Maybe, but that has been done too! :) > -- > Wilko Bulte Arnhem, The Netherlands > http://www.tcja.nlThe FreeBSD Project: http://www.freebsd.org > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Brian Beattie| This email was produced using professional quality, [EMAIL PROTECTED] | standards based software. Users of Microsoft [EMAIL PROTECTED] | products or other substandard software should www.aracnet.com/~beattie | contact the author about receiving a Free upgrade to | FreeBSD or Linux. "FreeBSD: The power to serve" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 100Bit Fast Ethernet EISA card - anyone?
On Tue, Mar 21, 2000 at 10:20:14PM -0500, Matthew N. Dodd wrote: > On Tue, 21 Mar 2000, Wilko Bulte wrote: > > An FDDI ISA card would not be much fun (performance wise) > > But they exist, as do ISA 100baseTX cards. :) Duh.. Considering the premium price FDDI always had that is a surprise to me to be honest. Like a V8 in a VW Beetle ;-) -- Wilko Bulte Arnhem, The Netherlands http://www.tcja.nl The FreeBSD Project: http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
* Jim Bryant <[EMAIL PROTECTED]> [000322 14:19] wrote: > In reply: > > This is cross-posted to both linux-kernel and freebsd-hackers, please > > set your replies properly. > > > > > I found the following by accident playing with PVM. If you start the > > > 'gexample' from the examples directory with dimension=1 and no of > > > tasks=32 on one machine, it becomes almost immediately completely un- > > > usable and begins with heavy swapping. Considering how much memory > > > would be necessary for this computation before starting it would have > > > avoided the trouble. > > well, there are other ways to make a system slow to a crawl > > a good preventative measure is to never give shell accounts unless > everyone is accountable. True. > > #!/bin/csh > /usr/games/primes 1 4294967295 >&/dev/null& > /usr/games/primes 1 4294967295 >&/dev/null& > # etc, ... > # > # [get the idea?] why are you 'scripting' in csh? eww. No i don't get the idea, login.conf in FreeBSD is able to limit a user to a maximum amount of processes, I think even cputime limitations work but I haven't tried them. Yes, and one shouldn't give accounts out to irresponcible/thoughtless people. 'rmuser' is your friend. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
In reply: > This is cross-posted to both linux-kernel and freebsd-hackers, please > set your replies properly. > > > I found the following by accident playing with PVM. If you start the > > 'gexample' from the examples directory with dimension=1 and no of > > tasks=32 on one machine, it becomes almost immediately completely un- > > usable and begins with heavy swapping. Considering how much memory > > would be necessary for this computation before starting it would have > > avoided the trouble. well, there are other ways to make a system slow to a crawl a good preventative measure is to never give shell accounts unless everyone is accountable. #!/bin/csh /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& /usr/games/primes 1 4294967295 >&/dev/null& # etc, ... # # [get the idea?] jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- [EMAIL PROTECTED] KC5VDJ - HF to 23cm KC5VDJ@NW0I.#NEKS.KS.USA.NOAM HF/VHF: IC-706MkII VHF/UHF/SHF: IC-T81AKPC3+ & PK-232MBXGrid: EM28px -- ET has one helluva sense of humor, always anal-probing right-wing schizos! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver
Dennis wrote: > > At 12:51 PM 3/21/00 -0700, you wrote: > >Dennis wrote: > >> > >> Shoot me for using an available resource. > > > >Shoot you for wasting a resource that could better spend their time > >developing FreeBSD instead of answering questions for people to lazy > >or stupid to look for themselves. > > Its very sad what's happened to this team. If asking a yes/no question is a > "waste of a resource" then there is no resource at all. Whatever, the linux > driver works. If you go back and read the list charter, something you seem to either be unaware of or completely ignore, this list is for discussing developing software on or for FreeBSD. Not for clueless newbie questions like "does FreeBSD work on my hardware?", that's what the -questions list is for. You seem to think the purpose of this list is for you to denigrate the work of the people who make FreeBSD, broadcast your own lovely little brand of FUD, and point out how much better Linux is for your customers. That's just fine, but this is NOT the appropriate channel for your opinions. If you want to present code that you think will fix the problem, fine. If you want to present diagnostics that think will fix the problem, fine. If you want user support questions, ask in -questions. If you want to opine that Linux is superior and FreeBSD a waste of time, as you have done so often lately, go do it somewhere else. This is not the appropriate venue. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
On Tuesday, 21 March 2000 at 7:46:57 +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Wes Peters writes: >> Poul-Henning Kamp wrote: >>> >>> In message <[EMAIL PROTECTED]>, Warner Losh writes: >>> I'd like to be able to do some simple spl locking in a driver that I'm writing. While I could go the splhigh() route, I'm concerned that spending lots of time at splhigh could cause problems, and some of my critical sections look to be very expensive. They only need protection against the card itself, not against the entire system. It just seems to be an overly large hammer. >>> >>> I miss this too. >> >> Semaphores? > > spl*() are semaphores. spl*() are interrupt lockouts. The difference is very evident in an SMP environment. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Odd TCP problem
Greetings, I've encounted somewhat of an odd problem that seemed to appear out of nowhere after my last -current upgrade a week or two ago. I rebuild last night and the problem is still around. Basically, near the end of the TCP transaction, consistant retransmission leads to the connection timing out. In the first example, my -current laptop is talking to a postgres database server running solaris7 on an ultra sparc. The program runs, and in the exact same spot each time (updating the last record) it stops. Here's a tcpdump: 14:20:01.894645 spirit.1100 > eclipse.5432: P 1176338:1176373(35) ack 136575 win 17520 (DF) 14:20:01.897467 eclipse.5432 > spirit.1100: P 136575:136624(49) ack 1176373 win 8760 (DF) 14:20:01.897951 spirit.1100 > eclipse.5432: P 1176373:1176756(383) ack 136624 win 17520 (DF) 14:20:01.908113 eclipse.5432 > spirit.1100: P 136624:136649(25) ack 1176756 win 8760 (DF) 14:20:01.910717 spirit.1100 > eclipse.5432: . 1176756:1178216(1460) ack 136649 win 17520 (DF) 14:20:01.911188 spirit.1100 > eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:01.978311 eclipse.5432 > spirit.1100: . ack 1178216 win 8760 (DF) 14:20:02.977968 spirit.1100 > eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:04.977986 spirit.1100 > eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:08.978058 spirit.1100 > eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:16.978187 spirit.1100 > eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:32.978432 spirit.1100 > eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:21:04.978917 spirit.1100 > eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) This continues until spirit gives up and resets the connection. As you can see, its like eclipse vanished. Now, running a tcpdump on eclipse shows that these packets are in fact reaching the machine, its just not responding to them. It's not a problem with postgres itself, as the same problem can also be observed sending mail. Everything goes fine until after the DATA stage, where we become stuck in the above retransmission loop. Ideas? -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: md_image compression?
If you're using the loader, don't bother. It'll do this for you as it loads the image. See eg. how the install floppies work. > I'm sort of thinking in my head about adding the ability for the > md driver to handle gziped images. md's drvinit() looks like > the perfect place to do this. if strcmp(type,"md_image_gzip") then > gunzip the image and so on. > > Obviously this trades RAM for disk space. The target implementation > is the i-opener -> X terminal transmogrification. I think I can cram > the whole thing into the 16M flash card, and with compression of that > image, I can cram a lot more. To implement it, I have some questions: > > 1. Is there a way to de-allocate or otherwise reuse the original > compressed image after the unzip is finished? > > 2. What is the best strategy for allocating the output image? > malloc(9)? > > 3. This would effectively add libz to the kernel. Does anyone > object, given the proviso that this whole mess would hide inside > of an option (MD_PRELOAD_GZIP springs to mind)? Perhaps instead > the md unzipper could be loaded as a module. The module could > be thrown away using the same mechanism as #1 once the > decompression is finished. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ 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: openssh + krb5 (followup)
On Wed, 22 Mar 2000, Sheldon Hearn wrote: > > Interoperability with MIT krb5 still seems to be an issue. > > Bleh, more FUD. The problem is in operability with non-FreeBSD openssh! > We use supported_authentication values for KRB5 that neither Datafellows > SSH nor OpenBSD SSH use. :-( Hmm..I thought OpenBSD's OpenSSH didn't support krb5, only krb4. Regardless, we should fix this to bring ourselves in line (preferably with both). Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Loopback device and 127.0.0.1address
Never cross-post to both -questions and -hackers, thanks. On Wed, 22 Mar 2000, Daniel Hilevich wrote: > Hi, > Does anyone have an idea why after creating 128 loopack devices and > configuring lo127 to 127.0.0.1 (instead of the default lo0) I am > experiencing many problems in interprocess communication using sockets? > Are lo0 and 127.0.0.1 (INADDR_LOOPBACK) tightly coupled? Errr... Haven't you just answered your own question? While we all wish it were otherwise I think you've already shown that there are places in the code that depend on lo0 == 127.0.0.1. Good luck, Doug -- "While the future's there for anyone to change, still you know it seems, it would be easier sometimes to change the past" - Jackson Browne, "Fountain of Sorrow" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
This is cross-posted to both linux-kernel and freebsd-hackers, please set your replies properly. > -- Forwarded message -- > Date: Wed, 22 Mar 2000 16:02:40 +0100 > From: Michael Lampe <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: How a normal user can crash any linux system > > I found the following by accident playing with PVM. If you start the > 'gexample' from the examples directory with dimension=1 and no of > tasks=32 on one machine, it becomes almost immediately completely un- > usable and begins with heavy swapping. Considering how much memory > would be necessary for this computation before starting it would have > avoided the trouble. > > So the processes go on allocating memory until physical memory and swap > is exhausted. At this point processes are killed and now things are > really > becoming interesting: One would expect that the misbehaving gexample > processes are killed or maybe other processes started by the same user. > > Actually random processes are killed: I've seen klogd, syslogd, cron, > gpm > and inetd disappear. In some cases the machine was unaccessible locally > as > well as remotely, but the kernel seemed to be still running -- ping > showed > the machine still up. > > Apart from the specific system processes that are killed, the problem > can be > reproduced under many different configurations. I have tried SuSE 6.0 > with > kernel 2.2.12, SuSE 6.2 with kernel 2.2.14, LinuxPPC R4/R5 (Red Hat 5.x > based) > with some recent 2.2.x kernels and finally the SuSE pre-release for PPC. > PVM > was 3.4.x. > > Any comments > * Ronald G. Minnich <[EMAIL PROTECTED]> [000322 09:57] wrote: > anybody want to try this on -current? No, a normal user shouldn't be able to crash any unix box with proper limits in place, this local DoS only works if there are no limitations. Please people, this is a 20 year old trick that I'm really tired of hearing come up every other month. It's called a forkbomb with a twist, it's old, boring and doesn't affect people with properly configured systems. Please consult your Operating System's documentation on how to setup limits. If you want to know why random processes are sometimes killed then you need to buy and read an OS book. thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ISO
p_a_r writes: > Where can i download the 3-4-stable as an iso image?? ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/3.4-install.iso -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How a normal user can crash any linux system (fwd)
anybody want to try this on -current? ron -- Forwarded message -- Date: Wed, 22 Mar 2000 16:02:40 +0100 From: Michael Lampe <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: How a normal user can crash any linux system I found the following by accident playing with PVM. If you start the 'gexample' from the examples directory with dimension=1 and no of tasks=32 on one machine, it becomes almost immediately completely un- usable and begins with heavy swapping. Considering how much memory would be necessary for this computation before starting it would have avoided the trouble. So the processes go on allocating memory until physical memory and swap is exhausted. At this point processes are killed and now things are really becoming interesting: One would expect that the misbehaving gexample processes are killed or maybe other processes started by the same user. Actually random processes are killed: I've seen klogd, syslogd, cron, gpm and inetd disappear. In some cases the machine was unaccessible locally as well as remotely, but the kernel seemed to be still running -- ping showed the machine still up. Apart from the specific system processes that are killed, the problem can be reproduced under many different configurations. I have tried SuSE 6.0 with kernel 2.2.12, SuSE 6.2 with kernel 2.2.14, LinuxPPC R4/R5 (Red Hat 5.x based) with some recent 2.2.x kernels and finally the SuSE pre-release for PPC. PVM was 3.4.x. Any comments - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver
At 12:51 PM 3/21/00 -0700, you wrote: >Dennis wrote: >> >> At 08:45 PM 3/20/00 -0800, David Greenman wrote: >> >>I hope your happy, but do you know the answer to my question? Has the >> >>driver been updated recently? >> > >> > Not to fix the problem that you are reporting. The solution might be as >> >simple as adding another PHY identifier to the list of supported ones. I need >> >to find some time to sit down with one of the not-working cards and fiddle >> >with it. I was going to do that this past weekend, but then got sick with a >> >virus. It's on my list. >> >> Ok. Thanks. Mr. Peters thinks that I should spend a half day searching for, >> installing and testing the "latest driver" (of course latest depends on >> where you happen to download it from), when it seems to me that asking the >> developers if a particuar issue has been corrected is a more reasonable >> approach. >> >> Shoot me for using an available resource. > >Shoot you for wasting a resource that could better spend their time >developing FreeBSD instead of answering questions for people to lazy >or stupid to look for themselves. Its very sad what's happened to this team. If asking a yes/no question is a "waste of a resource" then there is no resource at all. Whatever, the linux driver works. db To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP
Use the "alias" descriptor in ifconfig. You may wish to attach alias addresses to a loopback interface rather than a physical interface, too. -marc On Wed, 22 Mar 2000, Kasper Kristiansson wrote: > I wonder how i can add more than one ip number on the same network card. > > ./Kasper > > > 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
IP
I wonder how i can add more than one ip number on the same network card. ./Kasper To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
3,4
When are the 3.4 release comming, and i dont want some beta things? Mike Hammer Helsingborg, Bårslöv __ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: STABLE
On Wed, 22 Mar 2000, p_a_r wrote: > Hello were can i dównload freebsd3.4-stable as an iso image ?? This should be on FreeBSD-questions. ftp://ftp.freebsd.org/.0/FreeBSD/releases/i386/ISO-IMAGES/3.4-install.iso Or one of the MANY mirrors, as specified on www.freebsd.org -- Lloyd Rennie VBCnet GB Ltd [EMAIL PROTECTED] tel +44 (0) 117 929 1316http://www.vbc.netfax +44 (0) 117 927 2015 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ISO
Where can i download the 3-4-stable as an iso image?? +--+ | The coolest site for free home pages, email, chat, e-cards, movie info.. | | http://www.goplay.com - it's time to Go Play! | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: STABLE
> Hello were can i dównload freebsd3.4-stable as an iso image ?? do a "freebsd*.iso" search on http://ftpsearch.lycos.com -- Markus DoehrTel: +49 6503 917 152 IT AdminFax: +49 6503 917 190 SAP R/3 Basis e-Mail: [EMAIL PROTECTED] AUBI Baubeschläge GmbH http://www.aubi.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
STABLE
Hello were can i dównload freebsd3.4-stable as an iso image ?? +--+ | The coolest site for free home pages, email, chat, e-cards, movie info.. | | http://www.goplay.com - it's time to Go Play! | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: openssh + krb5 (followup)
On Wed, 22 Mar 2000 16:11:21 +0200, Sheldon Hearn wrote: > Interoperability with MIT krb5 still seems to be an issue. Bleh, more FUD. The problem is in operability with non-FreeBSD openssh! We use supported_authentication values for KRB5 that neither Datafellows SSH nor OpenBSD SSH use. :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Loopback device and 127.0.0.1address
Hi, Does anyone have an idea why after creating 128 loopack devices and configuring lo127 to 127.0.0.1 (instead of the default lo0) I am experiencing many problems in interprocess communication using sockets? Are lo0 and 127.0.0.1 (INADDR_LOOPBACK) tightly coupled? Thanks, --- Daniel Hilevich mailto:[EMAIL PROTECTED] Tel: +972-4-9592203 ext. 214 Charlotte's Web Networks LTD. http://www.cwnt.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: openssh + krb5 (followup)
On Sat, 18 Mar 2000 13:01:09 +0200, Sheldon Hearn wrote: > $ ssh -v -l root axl.ops > [...] > debug: Trying Kerberos V5 authentication. > ssh in free(): warning: chunk is already free. > [...] This was caused by a stale krb5.keytab on my box. It would have been nice if a more useful error message had been created, but the point is that kerberized ssh works. Interoperability with MIT krb5 still seems to be an issue. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
