Re: em network issues
On Wed, 18 Oct 2006, Kris Kennaway wrote:
I have been working with someone's system that has em shared with fxp,
and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is
enough to produce watchdog timeouts after a few seconds.
As previously mentioned, changing the INTR_FAST to INTR_MPSAFE in the
driver avoids this problem. However, others are seeing sporadic
watchdog timeouts at higher system load on non-shared em systems too.
em_intr_fast() has no locking whatsoever. I would be very surprised
if it even seemed to work for SMP. For UP, masking of CPU interrupts
(as is automatic in fast interrupt handlers) might provide sufficient
locking, but for many drivers fast wth interrupt handlers, whatever
locking is used by the fast interrupt handler must be used all over
the driver to protect data strutures that are or might be accessed by
the fast interrupt handler. That means lots of intr_disable/enable()s
if the UP case is micro-optimized and lots of mtx_lock/unlock_spin()s
for the general case. But em has no references to spinlocks or CPU
interrupt disabling.
em_intr() starts with EM_LOCK(), so it isn't obviously broken near its
first statement.
Very few operations are valid in fast interrupt handlers. Locking
and fastness must be considered for every operation, not only in
the interrupt handler but in all data structures shared by the
interrupt handler. For just the interrupt handler in em:
% static void
% em_intr_fast(void *arg)
% {
% struct adapter *adapter = arg;
This is safe because it has no side effects and doesn't take long.
% struct ifnet*ifp;
% uint32_treg_icr;
%
% ifp = adapter->ifp;
%
This is safe provided other parts of the driver ensure that the interrupt
handler is not reached after adapter->ifp goes away. Similarly for other
long-lived almost-const parts of *adapter.
% reg_icr = E1000_READ_REG(&adapter->hw, ICR);
%
This is safe provided reading the register doesn't change it.
% /* Hot eject? */
% if (reg_icr == 0x)
% return;
%
% /* Definitely not our interrupt. */
% if (reg_icr == 0x0)
% return;
%
These are safe since we don't do anything with the result.
% /*
%* Starting with the 82571 chip, bit 31 should be used to
%* determine whether the interrupt belongs to us.
%*/
% if (adapter->hw.mac_type >= em_82571 &&
% (reg_icr & E1000_ICR_INT_ASSERTED) == 0)
% return;
%
This is safe, as above.
% /*
%* Mask interrupts until the taskqueue is finished running. This is
%* cheap, just assume that it is needed. This also works around the
%* MSI message reordering errata on certain systems.
%*/
% em_disable_intr(adapter);
Now that we start doing things, we have various races.
The above races to disable interrupts with other entries to this interrupt
handler, and may race with other parts of the driver.
After we disable driver interrupts. There should be no more races with
other entries to this handler. However, reg_icr may be stale at this
point even if we handled the race correctly. The other entries may have
partly or completely handled the interrupt when we get back here (we
should have locked just before here, and then if the lock blocked waiting
for the other entries (which can only happen in the SMP case), we should
reread the status register to see if we still have anything to do, or
more importantly to see what we have to do now (extrascheduling of the
SWI handler would just wake time, but missing scheduling would break
things).
% taskqueue_enqueue(adapter->tq, &adapter->rxtx_task);
%
Safe provided the API is correctly implemented. (AFAIK, the API only
has huge design errors.)
% /* Link status change */
% if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC))
% taskqueue_enqueue(taskqueue_fast, &adapter->link_task);
%
As above, plus might miss this call if the status changed underneath us.
% if (reg_icr & E1000_ICR_RXO)
% adapter->rx_overruns++;
Race updating the counter.
Generally, fast interrupt handlers should avoid book-keeping like this,
since correct locking for it would poison large parts of the driver
with the locking required for the fast interrupt handler. Perhaps
similarly for important things. It's safe to read the status register
provided reading it doesn't change it. Then it is safe to schedule
tasks based on the contents of the register provided we don't do
anything else and schedule enough tasks. But don't disable interrupts
-- leave that to the task and make the task do nothing if it handled
everything for a previous scheduling. This would result in the task
usually being scheduled when the interrupt is for us but not if it is
for another device. The above doesn't try to do much more than this.
However, a fast interrupt handler needs to handle the usual case to
be worth having ex
Re: tz ME
# tzsetup tzsetup: /usr/share/zoneinfo/zone.tab:250: country code `ME' unknown Already fixed today. so bmah said. rebuilding now randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tz ME
Randy Bush wrote: releng6 as of yesterday # tzsetup tzsetup: /usr/share/zoneinfo/zone.tab:250: country code `ME' unknown Already fixed today. cvsup and # cd /usr/src/share/misc/ && make all install clean Thanks -- Marcus Alves Grando marcus(at)corp.grupos.com.br | Grupos Internet S/A mnag(at)FreeBSD.org | FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 4.x EoL
On Wed, 18 Oct 2006 12:13:11 +0100 (BST) Jan Grant <[EMAIL PROTECTED]> wrote: > > If you're setting up machines that you're going to be upgrading like > this in the future, I think it's _really_ worthwhile hacking out a > couple of "root slices" - that is, space for a second / and /usr - to > facilitate this. You can run mergemaster on a secondary copy of your > /etc (this, of course, requries that the contents of /etc are relatively > quiescent for this step) and tidy up by hand. You can perform a dump & > restore followed by a source upgrade, a fresh source install or a binary > upgrade ad lib; just reboot (with nextboot) when done. > > This also means you can keep the previous OS around for a while in case > there are problems with the new one. > > For setups that aren't amenable to automated deployments this works > pretty well and gives you a safety-net for upgrades. Good advice. I have a few additions. In fact, you don't need *a* partitions to boot such as ad0s1a. You simply need to spare a FreeBSD partition. At boot loader, you could type: ad(0,2,e) to boot "e" partition of the "2nd" slice on the first drive which is denoted by "0." ad(2,2,f) to boot from "f" partition of the 2nd slice on the 3rd drive. If you have lots of physical memory and swap space, you may be able to spare swap space for this porpuse for a moment. In another word, you can disable swap device for a while and use it as a root parition. Regards, Hiro ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em network issues
On Wed, 18 Oct 2006, Jack Vogel wrote: > On 10/18/06, Kip Macy <[EMAIL PROTECTED]> wrote: > > I have a Sun T2000 that I generally run with the em driver from as of > > July in order to avoid watchdog timeouts. One trivial scenario that > > reproduces the problem with 100% consistency is running the ghc > > configure script (a 20kloc shell script) over NFS. As the T2000 > > doesn't exactly represent "typical" PC hardware it may not be the most > > desirable test platform. Nonetheless, let me know if you're > > interested. > > Thanks for looking into this issue. > > > > -Kip > > I'm a bit confused from the way you worded this, do you have watchdogs > with em, or you use em to avoid them? I have watchdogs with the current (post vendor update) em driver, but not with an older (pre vendor update) version of it. > > If you have problems when running NFS then thats a clue, is it TCP or > UDP based NFS? I am interested, give me details about the setup please. Its UDP: 192.168.1.100:/usr/flatstor/freebsd/7.x/sparc64 / nfs bg,intr,rw 0 0 192.168.1.100:/usr/flatstor/shared /shared nfs bg,intr,rw,nfsv3 0 0 Running ./configure --help in /shared/ghc-6.4.2/ triggers it 100% consistently. > > I have one of the engineers in our test organization trying to repro symptoms > on a system installed with BETA2, it has shared interrupts between em and > usb. Any additional stuff he could run would be helpful. > Let me know what else you need. %ifconfig -a em0: flags=8843 mtu 1500 options=18b inet 192.168.1.5 netmask 0xff00 broadcast 192.168.1.255 ether 00:03:ba:d9:20:ae media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8802 mtu 1500 options=18b ether 00:03:ba:d9:20:af media: Ethernet autoselect status: no carrier em2: flags=8802 mtu 1500 options=18b ether 00:03:ba:d9:20:b0 media: Ethernet autoselect status: no carrier em3: flags=8802 mtu 1500 options=18b ether 00:03:ba:d9:20:b1 media: Ethernet autoselect status: no carrier lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 %pciconf -l [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:2:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:8:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:9:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x02 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:2:0:class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:8:0:class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:9:0:class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03408086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:0:2:class=0x060400 card=0x0044 chip=0x03418086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:2:0: class=0x060100 card=0x153310b9 chip=0x153310b9 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:6:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x0101ff card=0x chip=0x522910b9 rev=0xc4 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x0c0400 card=0x01001077 chip=0x23121077 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x01 card=0x30f01000 chip=0x00501000 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x02 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 %vmstat -i interrupt total rate vec1941: em0 18533 91 Total 18533 91 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em network issues
Awesome, this is the kind of data that will help. I'll see what I can do to get something repro'd. Jack On 10/18/06, Albert Shih <[EMAIL PROTECTED]> wrote: Le 19/10/2006 01:03:40+0200, Albert Shih a écrit > Le 18/10/2006 10:46:30-0700, Jack Vogel a écrit > > I think there may be a few different problems going on with the em driver > > on 6.2 that are being lumped under the general description of network > > hangs. In order to solve these I need a reproducible failure, either on a > > system here at Intel, or someone who is willing to be a remote guinea > > pig :) > > > > I need detailed reports, meaning EXACT system data, if its an OEM > > box, what model, what addons, a pciconf list, description of the > > network, and anything special that is connected with the problem > > occurence. OH, and if you have a 'before and after' situation, then > > please give driver deltas that worked, and which failed. > > Well > > BOX : HP Proliant ML350 G4 > All addons is HP > > Here the network config > > em0: flags=8843 mtu 1500 > options=b > media: Ethernet autoselect (1000baseTX ) > status: active > em1: flags=8843 mtu 1500 > options=b > media: Ethernet autoselect (1000baseTX ) > status: active > fxp0: flags=8843 mtu 1500 > options=8 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=8843 mtu 1500 > options=8 > media: Ethernet autoselect (100baseTX ) > status: active > bge0: flags=8843 mtu 1500 > options=1b > media: Ethernet autoselect (100baseTX ) > status: active > > The pciconf -l > > [EMAIL PROTECTED] ~]# pciconf -l > [EMAIL PROTECTED]:0:0:class=0x06 card=0x32000e11 chip=0x35908086 rev=0x0c hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x060400 card=0x0050 chip=0x35958086 rev=0x0c hdr=0x01 > [EMAIL PROTECTED]:4:0: class=0x060400 card=0x0050 chip=0x35978086 rev=0x0c hdr=0x01 > [EMAIL PROTECTED]:6:0: class=0x060400 card=0x0050 chip=0x35998086 rev=0x0c hdr=0x01 > [EMAIL PROTECTED]:28:0:class=0x060400 card=0x0050 chip=0x25ae8086 rev=0x02 hdr=0x01 > [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x32010e11 chip=0x25a98086 rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x32010e11 chip=0x25aa8086 rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:29:4:class=0x088000 card=0x32010e11 chip=0x25ab8086 rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:29:5:class=0x080020 card=0x32010e11 chip=0x25ac8086 rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x32010e11 chip=0x25ad8086 rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 rev=0x0a hdr=0x01 > [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x25a18086 rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:31:1: class=0x01018a card=0x32010e11 chip=0x25a28086 rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03298086 rev=0x09 hdr=0x01 > [EMAIL PROTECTED]:0:2: class=0x060400 card=0x0044 chip=0x032a8086 rev=0x09 hdr=0x01 > [EMAIL PROTECTED]:1:0: class=0x0c0400 card=0x01000e11 chip=0x23121077 rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:1:0: class=0x02 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 > [EMAIL PROTECTED]:1:1: class=0x02 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x010400 card=0x409a0e11 chip=0x00460e11 rev=0x01 hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x060400 card=0x00dc chip=0xb1548086 rev=0x00 hdr=0x01 > [EMAIL PROTECTED]:3:0: class=0x01 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 > [EMAIL PROTECTED]:3:1: class=0x01 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 > [EMAIL PROTECTED]:4:0: class=0x02 card=0xb1630e11 chip=0x12298086 rev=0x08 hdr=0x00 > [EMAIL PROTECTED]:5:0: class=0x02 card=0xb1630e11 chip=0x12298086 rev=0x08 hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x02 card=0x00e30e11 chip=0x165414e4 rev=0x03 hdr=0x00 > [EMAIL PROTECTED]:3:0: class=0x03 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 > [EMAIL PROTECTED]:4:0: class=0x088000 card=0x00d70e11 chip=0x00d70e11 rev=0x01 hdr=0x00 > [EMAIL PROTECTED] ~]# > I forgot : [EMAIL PROTECTED] ~]# vmstat -i interrupt total rate irq1: atkbd0 717 0 irq4: sio0 92430 2 irq6: fdc087 0 irq15: ata1 47 0 irq17: bge0 5812600139 irq24: mpt0 29 0 irq25: mpt1 17 0 irq26: fxp0 fxp1 2663253 64 irq48: isp0 3898376 93 irq72: ciss0 164341 3 irq76: em0 50269177 1209 irq77: em1 5608732134 cpu0: timer
Re: em network issues
On 10/18/06, Albert Shih <[EMAIL PROTECTED]> wrote: > > There is also a hardware eeprom issue on systems with an 82573 > type NIC on SOME systems. There is a utility to fix that, if you and on HP ? your system does not have 573 NICs, (what you show are 546) do you have others that are? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange with rpc
Le 18/10/2006 23:27:55+0200, Albert Shih a ?crit > Hi all > > I've strange (little) problem > > I've got many message like > > rpc.statd: Failed to contact host one_my_host_name > > but one_my_host_name is poweroff (off course he cannot contact). But why my > nfs server trying to contact a server is poweroff. > > I've try to find the name of one_my_host_name in /etc with (find ...) in > /var in /tmp nothing... (same thing with IP number). > > I don't event known why my server found the name (or IP number). > > I've event do reboot of my server. > > Any one have a idea ? > I found... it's in the man of rpc.statd Sorry for asking this quesiton. Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 i?me ?tage, plateau D, bureau 10 Heure local/Local time: Thu Oct 19 01:49:15 CEST 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em network issues
Le 19/10/2006 01:03:40+0200, Albert Shih a ?crit > Le 18/10/2006 10:46:30-0700, Jack Vogel a ?crit > > I think there may be a few different problems going on with the em driver > > on 6.2 that are being lumped under the general description of network > > hangs. In order to solve these I need a reproducible failure, either on a > > system here at Intel, or someone who is willing to be a remote guinea > > pig :) > > > > I need detailed reports, meaning EXACT system data, if its an OEM > > box, what model, what addons, a pciconf list, description of the > > network, and anything special that is connected with the problem > > occurence. OH, and if you have a 'before and after' situation, then > > please give driver deltas that worked, and which failed. > > Well > > BOX : HP Proliant ML350 G4 > All addons is HP > > Here the network config > > em0: flags=8843 mtu 1500 > options=b > media: Ethernet autoselect (1000baseTX ) > status: active > em1: flags=8843 mtu 1500 > options=b > media: Ethernet autoselect (1000baseTX ) > status: active > fxp0: flags=8843 mtu 1500 > options=8 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=8843 mtu 1500 > options=8 > media: Ethernet autoselect (100baseTX ) > status: active > bge0: flags=8843 mtu 1500 > options=1b > media: Ethernet autoselect (100baseTX ) > status: active > > The pciconf -l > > [EMAIL PROTECTED] ~]# pciconf -l > [EMAIL PROTECTED]:0:0:class=0x06 card=0x32000e11 chip=0x35908086 > rev=0x0c hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x060400 card=0x0050 chip=0x35958086 > rev=0x0c hdr=0x01 > [EMAIL PROTECTED]:4:0: class=0x060400 card=0x0050 chip=0x35978086 > rev=0x0c hdr=0x01 > [EMAIL PROTECTED]:6:0: class=0x060400 card=0x0050 chip=0x35998086 > rev=0x0c hdr=0x01 > [EMAIL PROTECTED]:28:0:class=0x060400 card=0x0050 chip=0x25ae8086 > rev=0x02 hdr=0x01 > [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x32010e11 chip=0x25a98086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x32010e11 chip=0x25aa8086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:29:4:class=0x088000 card=0x32010e11 chip=0x25ab8086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:29:5:class=0x080020 card=0x32010e11 chip=0x25ac8086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x32010e11 chip=0x25ad8086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 > rev=0x0a hdr=0x01 > [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x25a18086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:31:1: class=0x01018a card=0x32010e11 chip=0x25a28086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03298086 > rev=0x09 hdr=0x01 > [EMAIL PROTECTED]:0:2: class=0x060400 card=0x0044 chip=0x032a8086 > rev=0x09 hdr=0x01 > [EMAIL PROTECTED]:1:0: class=0x0c0400 card=0x01000e11 chip=0x23121077 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:1:0: class=0x02 card=0x00db0e11 chip=0x10108086 > rev=0x01 hdr=0x00 > [EMAIL PROTECTED]:1:1: class=0x02 card=0x00db0e11 chip=0x10108086 > rev=0x01 hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x010400 card=0x409a0e11 chip=0x00460e11 > rev=0x01 hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x060400 card=0x00dc chip=0xb1548086 > rev=0x00 hdr=0x01 > [EMAIL PROTECTED]:3:0: class=0x01 card=0x00da0e11 chip=0x00301000 > rev=0x08 hdr=0x00 > [EMAIL PROTECTED]:3:1: class=0x01 card=0x00da0e11 chip=0x00301000 > rev=0x08 hdr=0x00 > [EMAIL PROTECTED]:4:0: class=0x02 card=0xb1630e11 chip=0x12298086 > rev=0x08 hdr=0x00 > [EMAIL PROTECTED]:5:0: class=0x02 card=0xb1630e11 chip=0x12298086 > rev=0x08 hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x02 card=0x00e30e11 chip=0x165414e4 > rev=0x03 hdr=0x00 > [EMAIL PROTECTED]:3:0: class=0x03 card=0x001e0e11 chip=0x47521002 > rev=0x27 hdr=0x00 > [EMAIL PROTECTED]:4:0: class=0x088000 card=0x00d70e11 chip=0x00d70e11 > rev=0x01 hdr=0x00 > [EMAIL PROTECTED] ~]# > I forgot : [EMAIL PROTECTED] ~]# vmstat -i interrupt total rate irq1: atkbd0 717 0 irq4: sio0 92430 2 irq6: fdc087 0 irq15: ata1 47 0 irq17: bge0 5812600139 irq24: mpt0 29 0 irq25: mpt1 17 0 irq26: fxp0 fxp1 2663253 64 irq48: isp0 3898376 93 irq72: ciss0 164341 3 irq76: em0 50269177 1209 irq77: em1 5608732134 cpu0: timer 83015825 1997 Total 151525631 3646 [EMAIL PROT
Re: em network issues
Le 18/10/2006 10:46:30-0700, Jack Vogel a ?crit > I think there may be a few different problems going on with the em driver > on 6.2 that are being lumped under the general description of network > hangs. In order to solve these I need a reproducible failure, either on a > system here at Intel, or someone who is willing to be a remote guinea > pig :) > > I need detailed reports, meaning EXACT system data, if its an OEM > box, what model, what addons, a pciconf list, description of the > network, and anything special that is connected with the problem > occurence. OH, and if you have a 'before and after' situation, then > please give driver deltas that worked, and which failed. Well BOX : HP Proliant ML350 G4 All addons is HP Here the network config em0: flags=8843 mtu 1500 options=b media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 mtu 1500 options=b media: Ethernet autoselect (1000baseTX ) status: active fxp0: flags=8843 mtu 1500 options=8 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8843 mtu 1500 options=8 media: Ethernet autoselect (100baseTX ) status: active bge0: flags=8843 mtu 1500 options=1b media: Ethernet autoselect (100baseTX ) status: active The pciconf -l [EMAIL PROTECTED] ~]# pciconf -l [EMAIL PROTECTED]:0:0:class=0x06 card=0x32000e11 chip=0x35908086 rev=0x0c hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x060400 card=0x0050 chip=0x35958086 rev=0x0c hdr=0x01 [EMAIL PROTECTED]:4:0: class=0x060400 card=0x0050 chip=0x35978086 rev=0x0c hdr=0x01 [EMAIL PROTECTED]:6:0: class=0x060400 card=0x0050 chip=0x35998086 rev=0x0c hdr=0x01 [EMAIL PROTECTED]:28:0:class=0x060400 card=0x0050 chip=0x25ae8086 rev=0x02 hdr=0x01 [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x32010e11 chip=0x25a98086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x32010e11 chip=0x25aa8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:29:4:class=0x088000 card=0x32010e11 chip=0x25ab8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:29:5:class=0x080020 card=0x32010e11 chip=0x25ac8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x32010e11 chip=0x25ad8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 rev=0x0a hdr=0x01 [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x25a18086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:31:1: class=0x01018a card=0x32010e11 chip=0x25a28086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03298086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:0:2: class=0x060400 card=0x0044 chip=0x032a8086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:1:0: class=0x0c0400 card=0x01000e11 chip=0x23121077 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x02 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:1:1: class=0x02 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x010400 card=0x409a0e11 chip=0x00460e11 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x060400 card=0x00dc chip=0xb1548086 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:3:0: class=0x01 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 [EMAIL PROTECTED]:3:1: class=0x01 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 [EMAIL PROTECTED]:4:0: class=0x02 card=0xb1630e11 chip=0x12298086 rev=0x08 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0x02 card=0xb1630e11 chip=0x12298086 rev=0x08 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x02 card=0x00e30e11 chip=0x165414e4 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:3:0: class=0x03 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 [EMAIL PROTECTED]:4:0: class=0x088000 card=0x00d70e11 chip=0x00d70e11 rev=0x01 hdr=0x00 [EMAIL PROTECTED] ~]# This server has only one purpose : nfsd. There are a MSA1000 (disk array) connected in FC with Qlogic FC card. History of my problem : The server is buy on january 2006 (in replacement of old HP) only the server is news, the MSA1000 is the old one. I've install FreeBSD 6.x on this server. Because I've 0 problem with the old server, I directly put my server in production (I known bad idea...) After some weeks the problem begin with lost em interface (watchdog), sometime it's fxp (but very rarely). When this append nothing can fix (without reboot). I make many cvs, to swapp on 6-Stable, but nothing change. After some weeks the server just hang-on or the network em is on watchdog status. In ~march 2006 someone on this mailing list tel me I can put the interface on polling mode with no SMP. This thing work very fine until september 2006. Without any change on my server (no cvs, no buildkernel, no reboot), no change on the nfs clients (linux/FreebSD) the problem come again. The first crash is the server hang-on. I've make cvsup/buildworld/buildkernel. After some
Re: em network issues
On Wed, Oct 18, 2006 at 03:31:53PM -0700, Jack Vogel wrote: > On 10/18/06, Kip Macy <[EMAIL PROTECTED]> wrote: > >I have a Sun T2000 that I generally run with the em driver from as of > >July in order to avoid watchdog timeouts. One trivial scenario that > >reproduces the problem with 100% consistency is running the ghc > >configure script (a 20kloc shell script) over NFS. As the T2000 > >doesn't exactly represent "typical" PC hardware it may not be the most > >desirable test platform. Nonetheless, let me know if you're > >interested. > >Thanks for looking into this issue. > > > >-Kip > > I'm a bit confused from the way you worded this, do you have watchdogs > with em, or you use em to avoid them? > > If you have problems when running NFS then thats a clue, is it TCP or > UDP based NFS? I am interested, give me details about the setup please. > > I have one of the engineers in our test organization trying to repro > symptoms > on a system installed with BETA2, it has shared interrupts between em and > usb. Any additional stuff he could run would be helpful. I have been working with someone's system that has em shared with fxp, and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is enough to produce watchdog timeouts after a few seconds. As previously mentioned, changing the INTR_FAST to INTR_MPSAFE in the driver avoids this problem. However, others are seeing sporadic watchdog timeouts at higher system load on non-shared em systems too. This is in addition to the hardware instances you already know about where the em driver has not worked going back to 5.x. Kris pgpD0sIWlaYUK.pgp Description: PGP signature
Re: em network issues
On 10/18/06, Kip Macy <[EMAIL PROTECTED]> wrote: I have a Sun T2000 that I generally run with the em driver from as of July in order to avoid watchdog timeouts. One trivial scenario that reproduces the problem with 100% consistency is running the ghc configure script (a 20kloc shell script) over NFS. As the T2000 doesn't exactly represent "typical" PC hardware it may not be the most desirable test platform. Nonetheless, let me know if you're interested. Thanks for looking into this issue. -Kip I'm a bit confused from the way you worded this, do you have watchdogs with em, or you use em to avoid them? If you have problems when running NFS then thats a clue, is it TCP or UDP based NFS? I am interested, give me details about the setup please. I have one of the engineers in our test organization trying to repro symptoms on a system installed with BETA2, it has shared interrupts between em and usb. Any additional stuff he could run would be helpful. Thanks, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tz ME
If memory serves me right, Randy Bush wrote: > releng6 as of yesterday > > # tzsetup > tzsetup: /usr/share/zoneinfo/zone.tab:250: country code `ME' unknown I think this was fixed in rev. 1.13.8.2 of src/share/misc/iso3166. Bruce. signature.asc Description: OpenPGP digital signature
Re: 6.2-PRE /boot/loader
Am 18.10.2006 um 17:29 schrieb Norbert Augenstein: after updating my pc (RELENG_6) last night and everything went fine i updated my laptop as well. Unfortunately my laptop ran into this constantly rebooting problem caused by the new /boot/loader. And again, /boot/loader.old works fine on my laptop. One possible (probable?) cause is non-default CFLAGS, or using certain values for CPUTYPE. Not sure what the underlying problem is, but anything but the defaults seems to trip loader up. HTH, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em network issues
I have a Sun T2000 that I generally run with the em driver from as of July in order to avoid watchdog timeouts. One trivial scenario that reproduces the problem with 100% consistency is running the ghc configure script (a 20kloc shell script) over NFS. As the T2000 doesn't exactly represent "typical" PC hardware it may not be the most desirable test platform. Nonetheless, let me know if you're interested. Thanks for looking into this issue. -Kip On 10/18/06, Jack Vogel <[EMAIL PROTECTED]> wrote: I think there may be a few different problems going on with the em driver on 6.2 that are being lumped under the general description of network hangs. In order to solve these I need a reproducible failure, either on a system here at Intel, or someone who is willing to be a remote guinea pig :) I need detailed reports, meaning EXACT system data, if its an OEM box, what model, what addons, a pciconf list, description of the network, and anything special that is connected with the problem occurence. OH, and if you have a 'before and after' situation, then please give driver deltas that worked, and which failed. I know that there are systems out there that have management hardware that can interfere on the network, it grabs certain packets as being 'management' and doesnt pass them on to the OS. Specifically packets for port 623 and 664 get 'eaten' by this hardware. There is a fix for this, you tell the portmapper to not use ports below 665, in particular: sysctl net.inet.ip.portrange.lowlast 665 (default is 600) So, if you have IPMI or AMT hardware, you should try this change and see if it fixes hangs. There is also a hardware eeprom issue on systems with an 82573 type NIC on SOME systems. There is a utility to fix that, if you have a problem, and have that NIC email me and I can send that out to you. Lastly, our Linux crew have long believed that there are lurking issues on some AMD based systems, we have problems with these because we dont have easy access to this hardware (as you can imagine :). But we now have evidence that SOMETIMES completion on transmit descriptors is not being written back, and this causes hangs. They (the linux team) have a modified transmit cleanup algorithm that does not use the DONE bit, instead it just using the head and tail pointers. If I can get a case where someone has this kind of hardware and has hangs AND is willing to test then perhaps I can try coding something similar up. Also, remember to let everyone know if something gets fixed :) Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tz ME
releng6 as of yesterday # tzsetup tzsetup: /usr/share/zoneinfo/zone.tab:250: country code `ME' unknown ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Tom Judge wrote: Kris Kennaway wrote: On Wed, Oct 18, 2006 at 06:15:14PM +0100, Jason Thomson wrote: Using the driver from HEAD* in the latest RELENG_6 didn't fix our problems. We could still trigger the Watchdog timeout when copying a local file to an NFS mounted filesystem (UDP mount, GigE speeds). It was also possible to trigger this bug with multiple simultaneous TCP streams, but that took a little longer. Copying a local file to an NFS/UDP filesystem would trigger the bug in a few seconds. If there's anything we can do to help debug this, please let us know. Per my previous mails, the (known) bce watchdogs are symptoms of driver bugs which can be usefully converted into panics by enabling INVARIANTS and INVARIANT_SUPPORT. Please do so, then report what happens. Kris Hi Kris, I am a colleague of Jason's, when we were testing this patch the kernel used had both options set: option INVARIANTS option INVARIANT_SUPPORT Although on several boxes we have failed to cause a kernel panic, only watchdog timeouts. However the last crash that we reproduced did trigger several: bce: need to defrag Messages on the console before the watchdob timeout occured. Tom This is a debugging message that I accidentally left in. It may relate to the problem, I'll take a look. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfsmb survey
1. find out pci handle of your SMB controller: # pciconf -lv | fgrep 0x0c0500 -A 4 [EMAIL PROTECTED]:1:1: class=0x0c0500 card=0x5348108e chip=0x005210de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 SMBus' class= serial bus subclass = SMBus 2. read values in BARs 4 and 5 and also registers 0x50 and 0x54 like follows: # pciconf -r pci0:1:1 0x20 1c01 # pciconf -r pci0:1:1 0x24 1c41 # pciconf -r pci0:1:1 0x50 1c01 # pciconf -r pci0:1:1 0x54 1c41 FreeBSD 6.2-BETA2 FreeBSD 6.2-BETA2 #0: Mon Oct 2 03:22:01 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Strange with rpc
Hi all I've strange (little) problem I've got many message like rpc.statd: Failed to contact host one_my_host_name but one_my_host_name is poweroff (off course he cannot contact). But why my nfs server trying to contact a server is poweroff. I've try to find the name of one_my_host_name in /etc with (find ...) in /var in /tmp nothing... (same thing with IP number). I don't event known why my server found the name (or IP number). I've event do reboot of my server. Any one have a idea ? Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 i?me ?tage, plateau D, bureau 10 Heure local/Local time: Wed Oct 18 23:24:17 CEST 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Runaway kernel? Or an attack?
On Wed, Oct 18, 2006 at 04:07:14PM -0400, Andresen, Jason R. wrote:
> Ok, I have a recurring problem with my webserver. Once a day or so it
> gets locked into a loop with some random server usually somewhere in my
> ISP. When it does this, it spends all of its time spitting out packets
> and getting FIN, ACKs back.
>
> Shutting down the HTTP server doesn't stop the traffic. I have to
> create firewall rules to block the outgoing traffic to stop it. Wiping
> the disk and reinstalling from the CD didn't help either. This host is
> behind a NAT (A D-Link DI-604 router). Is this a bad packet injection
> attack, a bug, or has my box been compromised?
And let me guess: your DI-604 is set to port forward TCP 80 to
192.168.42.2 (rather than make 192.168.42.2 the DMZ host).
I recommend removing the DI-604 from the topology and see if the
problem continues. Gut feeling (based on past experience with
D-Link's residential products) is the problem will disappear.
You'll have to trust me on this -- no matter how reliable you think
the DI-series units are ("It works fine for me!"), they aren't.
There are major IP stack implementation issues with these units
(same with the DI-614+).
Thoroughly scan the D-Link forum on www.broadbandreports.com for
details of these problems. The IP stack on those units is awful.
Consider picking up a WRT54GL (which runs Linux; sure, I'd prefer
they run BSD, but I'll trust Linux's IP stack over some third-party
out-of-country IP stack any day of the week). Do not go with a
WRT54G (because you won't know what version you get; Linux-based
or VxWorks-based (which has other IP stack problems), nor a WRT54GS
(same risk (Linux vs. VxWorks)).
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-PRE /boot/loader
On Wed, Oct 18, 2006 at 11:20:37PM +0300, Dmitry Pryanishnikov wrote:
> No, it isn't. It's new and shiny (yet harmless) bug, which made it's way
> into the RELENG_6 with the following commit:
>
> ume 2006-10-16 15:09:24 UTC
>
> FreeBSD src repository
>
> Modified files:(Branch: RELENG_6)
> etc/rc.d auto_linklocal
> sys/netinet6 in6_ifattach.c
> Log:
> MFC: Revert the default value of net.inet6.ip6.auto_linklocal to 1.
> If ipv6_enable is not set to "YES", net.inet6.ip6.auto_linklocal
> is turned to 0 at boot.
>
> and this is the result of the /etc/rc.d/auto_linklocal execution on
> IPv6-less kernel.
The rc.d/auto_linklocal script does this:
auto_linklocal_start()
{
if ! checkyesno ipv6_enable; then
${SYSCTL_W} net.inet6.ip6.auto_linklocal=0
fi
}
The condition for this code getting called is weird. It would
require ipv6_enable="no" (which is default)... yet it goes and
tinkers with ipv6 sysctls anyways. I assume that the idea behind
ipv6_enable is that it's ONLY set to "yes" by administrators who
want to do IPv6-related things. (My point: It's bad to try and
set IPv6 sysctl when an administrator doesn't have ipv6_enable="yes")
This feature probably needs its own rc.conf option. Maybe this
is what the author had intended?
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Runaway kernel? Or an attack?
On Oct 18, 2006, at 1:07 PM, Andresen, Jason R. wrote: Ok, I have a recurring problem with my webserver. Once a day or so it gets locked into a loop with some random server usually somewhere in my ISP. When it does this, it spends all of its time spitting out packets and getting FIN, ACKs back. Shutting down the HTTP server doesn't stop the traffic. I have to create firewall rules to block the outgoing traffic to stop it. Frankly, this sounds more like the random remote host has been compromised, rather than your machine, and it is scanning the network for other hosts to attack. What URLs are being requested (check the http logs)? Here's a short tcpdump of the traffic when it happens, these packets are going out at a rate of thousands per second. The 192.168.42.2 is the local host and 192.76.86.83 is the apparently random victim: I'd talk to verizon.com and ask them what is going on from their side with that host... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-PRE /boot/loader
Hello! On Wed, 18 Oct 2006, [LoN]Kamikaze wrote: sysctl: unknown oid 'net.inet6.ip6.auto_linklocal' due to missing inet6 support in my kernel. This looks like a stale entry in your /etc/sysctl.conf or /boot/loader.conf to me. Just remove it (the entry, not the file). No, it isn't. It's new and shiny (yet harmless) bug, which made it's way into the RELENG_6 with the following commit: ume 2006-10-16 15:09:24 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) etc/rc.d auto_linklocal sys/netinet6 in6_ifattach.c Log: MFC: Revert the default value of net.inet6.ip6.auto_linklocal to 1. If ipv6_enable is not set to "YES", net.inet6.ip6.auto_linklocal is turned to 0 at boot. and this is the result of the /etc/rc.d/auto_linklocal execution on IPv6-less kernel. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Runaway kernel? Or an attack?
Ok, I have a recurring problem with my webserver. Once a day or so it gets locked into a loop with some random server usually somewhere in my ISP. When it does this, it spends all of its time spitting out packets and getting FIN, ACKs back. Shutting down the HTTP server doesn't stop the traffic. I have to create firewall rules to block the outgoing traffic to stop it. Wiping the disk and reinstalling from the CD didn't help either. This host is behind a NAT (A D-Link DI-604 router). Is this a bad packet injection attack, a bug, or has my box been compromised? This problem has persisted from when the box was 5.4 all the way to it's current 6.0 life. Sadly, I cannot upgrade it beyond 6.0 Release at the moment because it has a proprietary vendor binary kernel module for the RAID array, and the newest version they have is for 6.0. Here's a short tcpdump of the traffic when it happens, these packets are going out at a rate of thousands per second. The 192.168.42.2 is the local host and 192.76.86.83 is the apparently random victim: 09:36:51.056914 IP (tos 0x0, ttl 64, id 57273, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.42.2.80 > 192.76.86.83.22929: ., cksum 0xd1b3 (correct), 0:0(0) ack 0 win 33120 09:36:51.059404 IP (tos 0x0, ttl 51, id 61707, offset 0, flags [none], proto: TCP (6), length: 52) 192.76.86.83.22929 > 192.168.42.2.80: F, cksum 0x5331 (correct), 0:0(0) ack 1 win 65535 09:36:51.059469 IP (tos 0x0, ttl 64, id 57274, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.42.2.80 > 192.76.86.83.22929: ., cksum 0xd1b0 (correct), 0:0(0) ack 0 win 33120 09:36:51.060004 IP (tos 0x0, ttl 51, id 61709, offset 0, flags [none], proto: TCP (6), length: 52) 192.76.86.83.22929 > 192.168.42.2.80: F, cksum 0x5331 (correct), 0:0(0) ack 1 win 65535 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
In response to Bill Moran <[EMAIL PROTECTED]>: > In response to Scott Long <[EMAIL PROTECTED]>: > > > Conrad Burger wrote: > > > Hi > > > > > > It looks like there is a "new" version of the bce driver in HEAD. > > > When will it be incorporated into Releng_6? > > > > It will be merged when someone, preferably 2-3 people, tell me that > > the changes in HEAD work for them. So far, no one has. > > I'm working on that now. I wasn't aware that improvements had been > committed or I'd have started on it 2 days ago ... Well, I tried to backport the driver in -CURRENT to 6-STABLE and failed. Then I tried upgrading the system to -CURRENT, and that's left me with an unbootable system. Just not having a good day ... -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Installing 6.1-R on Dell Powervault 745N
Jeremy Chadwick wrote: On Wed, Oct 18, 2006 at 10:46:21PM +0800, Lin Jui-Nan Eric wrote: We have a Dell Powervault 745N and want to install FreeBSD 6.1-R. But the installer complains that it can not find out any hard disk. Since the dmesg contains ata2~5, I think the controller is recognized by FreeBSD, but it cannot get the SATA drive. The dmesg and result of running pciconf -lv is in this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/103624 The controller (which you label in your PR as "some funny RAID controller") is an Intel 31244: atapci0: mem 0xfe1ff000-0xfe1f irq 25 at device 2.0 on pci2 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 Some history: this controller was discussed back in 2005: http://lists.freebsd.org/pipermail/freebsd-current/2005-June/050827.html The appropriate code appears to have been committed to FreeBSD as of June 2005: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.h#rev1.49 There was a DMA-related fix for this controller committed in February 2006: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.h#rev1.49.2.7 Soren, do you have any ideas? Nothing else that that it should work. I dont own any HW that uses this chip so I cannot test it out. The current support was done for the ARM port IIRC so things might be different on other systems. At any rate you definitly should try out 6.2-beta-something as 6.1 is getting old -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Kris Kennaway wrote: On Wed, Oct 18, 2006 at 06:15:14PM +0100, Jason Thomson wrote: Using the driver from HEAD* in the latest RELENG_6 didn't fix our problems. We could still trigger the Watchdog timeout when copying a local file to an NFS mounted filesystem (UDP mount, GigE speeds). It was also possible to trigger this bug with multiple simultaneous TCP streams, but that took a little longer. Copying a local file to an NFS/UDP filesystem would trigger the bug in a few seconds. If there's anything we can do to help debug this, please let us know. Per my previous mails, the (known) bce watchdogs are symptoms of driver bugs which can be usefully converted into panics by enabling INVARIANTS and INVARIANT_SUPPORT. Please do so, then report what happens. Kris Hi Kris, I am a colleague of Jason's, when we were testing this patch the kernel used had both options set: option INVARIANTS option INVARIANT_SUPPORT Although on several boxes we have failed to cause a kernel panic, only watchdog timeouts. However the last crash that we reproduced did trigger several: bce: need to defrag Messages on the console before the watchdob timeout occured. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
On Wed, Oct 18, 2006 at 06:15:14PM +0100, Jason Thomson wrote: > Scott Long wrote: > > Conrad Burger wrote: > > > >> Hi > >> > >> It looks like there is a "new" version of the bce driver in HEAD. > >> When will it be incorporated into Releng_6? > > > > > > It will be merged when someone, preferably 2-3 people, tell me that > > the changes in HEAD work for them. So far, no one has. > > > > Scott > > ___ > > Using the driver from HEAD* in the latest RELENG_6 didn't fix our > problems. > > We could still trigger the Watchdog timeout when copying a local file to > an NFS mounted filesystem (UDP mount, GigE speeds). > > It was also possible to trigger this bug with multiple simultaneous TCP > streams, but that took a little longer. > > Copying a local file to an NFS/UDP filesystem would trigger the bug in a > few seconds. > > If there's anything we can do to help debug this, please let us know. Per my previous mails, the (known) bce watchdogs are symptoms of driver bugs which can be usefully converted into panics by enabling INVARIANTS and INVARIANT_SUPPORT. Please do so, then report what happens. Kris pgpGWtgwBEgVf.pgp Description: PGP signature
em network issues
I think there may be a few different problems going on with the em driver on 6.2 that are being lumped under the general description of network hangs. In order to solve these I need a reproducible failure, either on a system here at Intel, or someone who is willing to be a remote guinea pig :) I need detailed reports, meaning EXACT system data, if its an OEM box, what model, what addons, a pciconf list, description of the network, and anything special that is connected with the problem occurence. OH, and if you have a 'before and after' situation, then please give driver deltas that worked, and which failed. I know that there are systems out there that have management hardware that can interfere on the network, it grabs certain packets as being 'management' and doesnt pass them on to the OS. Specifically packets for port 623 and 664 get 'eaten' by this hardware. There is a fix for this, you tell the portmapper to not use ports below 665, in particular: sysctl net.inet.ip.portrange.lowlast 665 (default is 600) So, if you have IPMI or AMT hardware, you should try this change and see if it fixes hangs. There is also a hardware eeprom issue on systems with an 82573 type NIC on SOME systems. There is a utility to fix that, if you have a problem, and have that NIC email me and I can send that out to you. Lastly, our Linux crew have long believed that there are lurking issues on some AMD based systems, we have problems with these because we dont have easy access to this hardware (as you can imagine :). But we now have evidence that SOMETIMES completion on transmit descriptors is not being written back, and this causes hangs. They (the linux team) have a modified transmit cleanup algorithm that does not use the DONE bit, instead it just using the head and tail pointers. If I can get a case where someone has this kind of hardware and has hangs AND is willing to test then perhaps I can try coding something similar up. Also, remember to let everyone know if something gets fixed :) Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Scott Long wrote: > Conrad Burger wrote: > >> Hi >> >> It looks like there is a "new" version of the bce driver in HEAD. >> When will it be incorporated into Releng_6? > > > It will be merged when someone, preferably 2-3 people, tell me that > the changes in HEAD work for them. So far, no one has. > > Scott > ___ Using the driver from HEAD* in the latest RELENG_6 didn't fix our problems. We could still trigger the Watchdog timeout when copying a local file to an NFS mounted filesystem (UDP mount, GigE speeds). It was also possible to trigger this bug with multiple simultaneous TCP streams, but that took a little longer. Copying a local file to an NFS/UDP filesystem would trigger the bug in a few seconds. If there's anything we can do to help debug this, please let us know. * With the following patch applied: --- /usr/src/sys/dev/bce/if_bce.c.orig Wed Oct 18 17:19:02 2006 +++ /usr/src/sys/dev/bce/if_bce.c Wed Oct 18 17:39:11 2006 @@ -4521,6 +4521,7 @@ bus_dmamap_t map; struct tx_bd *txbd = NULL; struct mbuf *m0; +struct m_tag *mtag; u32 vlan_tag_flags = 0; u32 prod_bseq; u16 chain_prod, prod; @@ -4540,9 +4541,10 @@ } /* Transfer any VLAN tags to the bd. */ - if (m0->m_flags & M_VLANTAG) +mtag = VLAN_OUTPUT_TAG(sc->bce_ifp, m0); +if (mtag != NULL) vlan_tag_flags |= (TX_BD_FLAGS_VLAN_TAG | - (m0->m_pkthdr.ether_vtag << 16)); + (VLAN_TAG_VALUE(mtag) << 16)); /* Map the mbuf into DMAable memory. */ prod = sc->tx_prod; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-PRE /boot/loader
Norbert Augenstein wrote: > Moreover, while booting i get the following message: > > sysctl: unknown oid 'net.inet6.ip6.auto_linklocal' > > due to missing inet6 support in my kernel. This looks like a stale entry in your /etc/sysctl.conf or /boot/loader.conf to me. Just remove it (the entry, not the file). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
The 5754 is more than likely supported by the bge driver. The PCI id's probably have to be added. Kevin Kramer wrote: Sorry, I thought that you and others were working on numerous Broadcom issues including incorrect recognition of the chipsets for the Poweredge 1950's and Precision 390. You had been responding to most of the threads regarding Broadcom issues. -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Scott Long wrote the following on 10/18/06 10:26: Kevin Kramer wrote: and will it support the BCM5754 in the Precision 390? No idea, ask the vendor. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Sorry, I thought that you and others were working on numerous Broadcom issues including incorrect recognition of the chipsets for the Poweredge 1950's and Precision 390. You had been responding to most of the threads regarding Broadcom issues. -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Scott Long wrote the following on 10/18/06 10:26: Kevin Kramer wrote: and will it support the BCM5754 in the Precision 390? No idea, ask the vendor. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
locked vnode / nfs... requires kill -9 in ddb
6.2-PRERELEASE from 20061016 RELENG_6 sources. SMP with CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2127.97-MHz 686-class CPU) GENERIC minus some devices plus: options IPSEC options IPSEC_ESP device tap device vlan device hwpmc options HWPMC_HOOKS options KDB options DDB This also happened a couple times with 6.2-PRERELEASE from 20061004 RELENG_6 sources before I updated a couple days ago. In userland from a csh session, I used Ctrl-Z to suspend a Bourne shell script writing to a file through an amd host NFS (tcp v3) mount back to my own machine. Sometimes (maybe 5 times out of 20? in the last week) when I do this, I get a locked vnode problem (see ddb session below) and can't do anything with the filesystems at all (local or nfs). Shells hang when I execute any command (until the suspended 'sh' is killed from ddb). Interrupts still work, Ctrl-Alt-F# allows switching from X to ttyv* consoles. Dropping into ddb allows me to kill the 'sh' with -9 and then continuing from ddb let's me continue working and things are back to normal. KDB: enter: manual escape to debugger [thread pid 19 tid 100025 ] Stopped at 0xc05d5bcf = kdb_enter+0x2b:nop db> show lockedvnods Locked vnodes 0xc6b7bdd0: tag nfs, type VDIR usecount 2, writecount 0, refcount 8 mountedhere 0 flags (VV_ROOT) v_object 0xc9d84108 ref 0 pages 0 lock type nfs: EXCL (count 1) by thread 0xc8adac00 (pid 50746) with 5 pending fileid 8 fsid 0x300ff06 db> ps pid ppid pgrp uid state wmesg wchancmd 50761 1699 50761 0 S+ nfs 0xc6b7be28 ls 50760 1699 50760 0 S+ nfs 0xc6b7be28 lsof 50759 48969 48935 600 S+ nanslp 0xc088efcc seamonkey-bin 50758 48969 48935 600 S+ nanslp 0xc088efcc seamonkey-bin 50757 50756 50757 0 Ss nfs 0xc6b7be28 procmail 50756 1 809 0 S select 0xc0895ba4 sendmail 50751 50750 50751 0 Ss nfs 0xc6b7be28 procmail 50750 1 809 0 S select 0xc0895ba4 sendmail 50748 50747 1418 600 SV+ nfs 0xc6b7be28 csh 50747 1418 1418 600 S+ ppwait 0xc8573430 csh 50746 5 4 600 T+ sh 5 1418 4 600 T+ formail 4 1418 4 600 T+ pipewr 0xc910f000 cat . . db>db> trace 50746 Tracing pid 50746 tid 100231 td 0xc8adac00 sched_switch(c8adac00,0,2) at 0xc05ce0cb = sched_switch+0x173 mi_switch(2,0) at 0xc05c2b0a = mi_switch+0x1ba thread_suspend_check(1,c079e04c,c8adac00,c9206b80,1,...) at 0xc05c722d = thread_suspend_check+0x191 sleepq_catch_signals(c9206b80) at 0xc05db93f = sleepq_catch_signals+0x103 sleepq_wait_sig(c9206b80) at 0xc05dbd96 = sleepq_wait_sig+0xe msleep(c9206b80,c08a6a40,153,c0813379,0) at 0xc05c2652 = msleep+0x25a nfs_reply(c9206b80,0,c8adac00,4,c7ea7100,...) at 0xc06c33ac = nfs_reply+0x244 nfs_request(c6b7bdd0,c6ae2d00,1,c8adac00,c7815280,e8f3488c,e8f34890,e8f34894,c8adac00,e8f348a0) at 0xc06c40a5 = nfs_request+0x3c1 nfs_getattr(e8f348dc) at 0xc06c912b = nfs_getattr+0x11f VOP_GETATTR_APV(c086c700,e8f348dc) at 0xc07b260c = VOP_GETATTR_APV+0x38 nfsspec_access(e8f34a8c,c6bf7c94,0,e8f349a4,c060ca26,...) at 0xc06cebf1 = nfsspec_access+0x85 nfs_access(e8f34a8c) at 0xc06c8b7a = nfs_access+0x122 VOP_ACCESS_APV(c086c700,e8f34a8c) at 0xc07b25b0 = VOP_ACCESS_APV+0x38 nfs_lookup(e8f34b18) at 0xc06c96ff = nfs_lookup+0xd3 VOP_LOOKUP_APV(c086c700,e8f34b18) at 0xc07b22f7 = VOP_LOOKUP_APV+0x43 lookup(e8f34c00) at 0xc060ee79 = lookup+0x4c1 namei(e8f34c00) at 0xc060e71a = namei+0x39a kern_stat(c8adac00,806712c,0,e8f34c74) at 0xc061d3cd = kern_stat+0x35 stat(c8adac00,e8f34d04) at 0xc061d37b = stat+0x1b syscall(3b,3b,3b,1,80670ec,...) at 0xc07a9363 = syscall+0x2bf Xint0x80_syscall() at 0xc079456f = Xint0x80_syscall+0x1f --- syscall (188, FreeBSD ELF32, stat), eip = 0x28196477, esp = 0xbfbfdc1c, ebp = 0xbfbfdcb8 --- db> kill 9 50746 db> c ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
In response to Scott Long <[EMAIL PROTECTED]>: > Conrad Burger wrote: > > Hi > > > > It looks like there is a "new" version of the bce driver in HEAD. > > When will it be incorporated into Releng_6? > > It will be merged when someone, preferably 2-3 people, tell me that > the changes in HEAD work for them. So far, no one has. I'm working on that now. I wasn't aware that improvements had been committed or I'd have started on it 2 days ago ... -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-PRE /boot/loader
On Tue, Oct 03, 2006 at 06:55:39PM +0200, Norbert Augenstein wrote: > Hi list, > i have just updated to 6.2-PRERELEASE and GRUB is unable to use > the new /boot/loader. Ending in an endless loop rebooting after > selecting FreeBSD. > As a workaround it was possible to chainload FreeBSD. > Further investigation shows that /boot/loader.old is woking. > > So what can cause the new loader to fail? > I have not set CFLAGS / CPUTYPE in /etc/make.conf > > No other problems , em device is working fine here:) > Hi list, me again after updating my pc (RELENG_6) last night and everything went fine i updated my laptop as well. Unfortunately my laptop ran into this constantly rebooting problem caused by the new /boot/loader. And again, /boot/loader.old works fine on my laptop. Moreover, while booting i get the following message: sysctl: unknown oid 'net.inet6.ip6.auto_linklocal' due to missing inet6 support in my kernel. regards, --> auge -- 5:00PM up 72 days, 17:04, 0 users, load averages: 0.00, 0.00, 0.00 No yak too dirty; no dumpster too hollow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Kevin Kramer wrote: and will it support the BCM5754 in the Precision 390? No idea, ask the vendor. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Conrad Burger wrote: Hi It looks like there is a "new" version of the bce driver in HEAD. When will it be incorporated into Releng_6? It will be merged when someone, preferably 2-3 people, tell me that the changes in HEAD work for them. So far, no one has. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfsmb survey
On Monday 16 October 2006 18:15, Andriy Gapon wrote: > In STABLE and upcoming 6.2 (and in CURRENT, of course) there is a new > SMB driver for NForce2/3/4 chipsets, nfsmb, developed by Ruslan Ermilov. > However, the driver doesn't currently work on all hardware that it is to > support. The problem is with choosing proper BAR registers, which, as it > seems, might be different for different chipsets/SMB controllers. > > If you have a system based on NForce2/3/4, could you please share the > following information: > > 1. find out pci handle of your SMB controller: > $ pciconf -l | fgrep 0x0c0500 > and also note chip field value, it should match 00(64|84|d4|e4|52)10de. > E.g.: > [EMAIL PROTECTED]:1:1:class=0x0c0500 card=0x1c02147b chip=0x006410de > rev=0xa2 hdr=0x00 > > 2. read values in BARs 4 and 5 and also registers 0x50 and 0x54 like > follows: > $ pciconf -r pci0:1:1 0x20 > $ pciconf -r pci0:1:1 0x24 > $ pciconf -r pci0:1:1 0x50 > $ pciconf -r pci0:1:1 0x54 > using your pci handle instead of pci0:1:1, e.g.: > $ pciconf -r pci0:1:1 0x20 > > $ pciconf -r pci0:1:1 0x24 > > $ pciconf -r pci0:1:1 0x50 > 1001 > $ pciconf -r pci0:1:1 0x54 > 1041 > > 3. send chip id and register values here. > > Thank you very much in advance. Tyan Thunder K8WE (S2895) data# pciconf -lv | fgrep 0x0c0500 [EMAIL PROTECTED]:1:1:class=0x0c0500 card=0x289510f1 chip=0x005210de rev=0xa2 hdr=0x00 data# pciconf -r pci0:1:1 0x20 a001 data# pciconf -r pci0:1:1 0x24 a041 data# pciconf -r pci0:1:1 0x50 a001 data# pciconf -r pci0:1:1 0x54 a041 -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Installing 6.1-R on Dell Powervault 745N
On Wed, Oct 18, 2006 at 10:46:21PM +0800, Lin Jui-Nan Eric wrote: > We have a Dell Powervault 745N and want to install FreeBSD 6.1-R. > But the installer complains that it can not find out any hard disk. > Since the dmesg contains ata2~5, I think the controller is recognized > by FreeBSD, but it cannot get the SATA drive. > > The dmesg and result of running pciconf -lv is in this PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/103624 The controller (which you label in your PR as "some funny RAID controller") is an Intel 31244: atapci0: mem 0xfe1ff000-0xfe1f irq 25 at device 2.0 on pci2 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 Some history: this controller was discussed back in 2005: http://lists.freebsd.org/pipermail/freebsd-current/2005-June/050827.html The appropriate code appears to have been committed to FreeBSD as of June 2005: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.h#rev1.49 There was a DMA-related fix for this controller committed in February 2006: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.h#rev1.49.2.7 Soren, do you have any ideas? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Installing 6.1-R on Dell Powervault 745N
Dear All, We have a Dell Powervault 745N and want to install FreeBSD 6.1-R. But the installer complains that it can not find out any hard disk. Since the dmesg contains ata2~5, I think the controller is recognized by FreeBSD, but it cannot get the SATA drive. The dmesg and result of running pciconf -lv is in this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/103624 Any suggestions? With Best Regards, Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux-flashplugin dependency on linux-base ( was: flash7/firefox plugin no longer registers)
Hi On Wednesday 18 October 2006 17:01, Oliver Fromme wrote: > If you use linux-flashlugin with www/linuxpluginwrapper, > then you don't need the linux emulation at all (neither > linux-base nor the kernel module). > > However, if you use linux-flashplugin natively (with a > linux browser), then both are required. Yes, but the linux-flashplugin does NOT require linux-base, if you use it with a linux browser then the linux browser will require linux-base and the kernel module. So, keeping in mind that linux-base is no small port, i would suggest removing the dependency on linux-base from linux-flashplugin . Iulian M. http://www.erata.net -- I like your game but we have to change the rules. pgpMygj8SqqjA.pgp Description: PGP signature
Re: flash7/firefox plugin no longer registers
Iulian M wrote: > The plugin works fine now, but i still have one more question > regarding flash player. Does the linux-flashplugin7 port > really require linux-base ? I don't relay like the idea of > installing linux-base and the linux kernel module, If you use linux-flashlugin with www/linuxpluginwrapper, then you don't need the linux emulation at all (neither linux-base nor the kernel module). However, if you use linux-flashplugin natively (with a linux browser), then both are required. In fact, I think you also need x11/linux-xorg-libs (because the plugin is linked against libs from that port), even though it is not listed as a dependency. Maybe that's a bug, or maybe I haven't looked closely enough. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
and will it support the BCM5754 in the Precision 390? -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Conrad Burger wrote the following on 10/18/06 04:58: Hi It looks like there is a "new" version of the bce driver in HEAD. When will it be incorporated into Releng_6? We are currently having some performance problems with a java application on our Dell 1950s. And it looks like it has something to do with the speed with which network I/Os are performed. We have Dell 2850s running FreeBSD 5.4/i386 SMP. With Intel nics (em) and they are performing quite well. With 34000 tcp sockets open the maximum time it takes to perform a single network I/O is about 100ms. The Dell 1950s running FreeBSD 6.2-Prerelease/i386 SMP with Broadcom nics (bce), the same application and 34000 tcp connections open. The maximum time it takes to perform a single network I/O is about 7000ms. Most of the packets the systems send/receive are rather small. We are not quite sure what could cause this behavior. If anyone has any ideas of what we could do to decrease the time it takes to perform network I/O it would be much appreciated. Regards Conrad Some information: dev.bce.0.%desc: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 dev.bce.0.%driver: bce dev.bce.0.%location: slot=0 function=0 dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x164c subvendor=0x1028 subdevice=0x01b3 class=0x02 dev.bce.0.%parent: pci9 dev.bce.0.driver_version: v0.9.6 dev.bce.0.stat_IfHcInOctets: 2346165 dev.bce.0.stat_IfHCInBadOctets: 1877825702 dev.bce.0.stat_IfHCOutOctets: 2751390538 dev.bce.0.stat_IfHCOutBadOctets: 0 dev.bce.0.stat_IfHCInUcastPkts: 360078711 dev.bce.0.stat_IfHCInMulticastPkts: 18339 dev.bce.0.stat_IfHCInBroadcastPkts: 270544 dev.bce.0.stat_IfHCOutUcastPkts: 323261730 dev.bce.0.stat_IfHCOutMulticastPkts: 147410 dev.bce.0.stat_IfHCOutBroadcastPkts: 985 dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.0.stat_Dot3StatsFCSErrors: 0 dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 dev.bce.0.stat_Dot3StatsSingleCollisionFraes: 0 dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.0.stat_Dot3StatsLateCollisions: 0 dev.bce.0.stat_EtherStatsCollisions: 0 dev.bce.0.stat_EtherStatsFragments: 0 dev.bce.0.stat_EtherStatsJabbers: 0 dev.bce.0.stat_EtherStatsUndersizePkts: 0 dev.bce.0.stat_EtherStatsOverrsizePkts: 0 dev.bce.0.stat_EtherStatsPktsRx64Octets: 44671171 dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 166377250 dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 125306581 dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 11502851 dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 3372657 dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 9137084 dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 dev.bce.0.stat_EtherStatsPktsTx64Octets: 12605056 dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 208798776 dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 82452517 dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 8532515 dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 3204492 dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 7816769 dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 dev.bce.0.stat_XonPauseFramesReceived: 0 dev.bce.0.stat_XoffPauseFramesReceived: 0 dev.bce.0.stat_OutXonSent: 0 dev.bce.0.stat_OutXoffSent: 0 dev.bce.0.stat_FlowControlDone: 0 dev.bce.0.stat_MacControlFramesReceived: 0 dev.bce.0.stat_XoffStateEntered: 0 dev.bce.0.stat_IfInFramesL2FilterDiscards: 4933702 dev.bce.0.stat_IfInRuleCheckerDiscards: 0 dev.bce.0.stat_IfInFTQDiscards: 0 dev.bce.0.stat_IfInMBUFDiscards: 0 dev.bce.0.stat_IfInRuleCheckerP4Hit: 0 dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.0.stat_CatchupInFTQDiscards: 0 dev.bce.0.stat_CatchupInMBUFDiscards: 0 dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 # vmstat -i interrupt total rate irq14: ata0 47 0 irq16: bce0 bce1548968755 1086 irq21: uhci0 uhci+ 5 0 irq78: mfi0343548 0 cpu0: timer 998576924 1976 cpu1: timer1008301350 1995 cpu3: timer1008469139 1995 cpu2: timer 995126109 1969 Total 4559785877 9023 # uname -a FreeBSD niobium.mxit.co.za 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Oct 10 13:28:54 SAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MXIT-SMP-I386 i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mai
Re: nfsmb survey
On Monday, 16 October 2006 at 20:15:26 +0300, Andriy Gapon wrote: > > In STABLE and upcoming 6.2 (and in CURRENT, of course) there is a new > SMB driver for NForce2/3/4 chipsets, nfsmb, developed by Ruslan Ermilov. > However, the driver doesn't currently work on all hardware that it is to > support. The problem is with choosing proper BAR registers, which, as it > seems, might be different for different chipsets/SMB controllers. > > If you have a system based on NForce2/3/4, could you please share the > following information: > > 1. find out pci handle of your SMB controller: > $ pciconf -l | fgrep 0x0c0500 > and also note chip field value, it should match 00(64|84|d4|e4|52)10de. > E.g.: > [EMAIL PROTECTED]:1:1:class=0x0c0500 card=0x1c02147b chip=0x006410de > rev=0xa2 hdr=0x00 > > 2. read values in BARs 4 and 5 and also registers 0x50 and 0x54 like > follows: > $ pciconf -r pci0:1:1 0x20 > $ pciconf -r pci0:1:1 0x24 > $ pciconf -r pci0:1:1 0x50 > $ pciconf -r pci0:1:1 0x54 > using your pci handle instead of pci0:1:1, e.g.: > $ pciconf -r pci0:1:1 0x20 > > $ pciconf -r pci0:1:1 0x24 > > $ pciconf -r pci0:1:1 0x50 > 1001 > $ pciconf -r pci0:1:1 0x54 > 1041 > > 3. send chip id and register values here. > > Thank you very much in advance. > > -- > Andriy Gapon > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" [EMAIL PROTECTED]:~# pciconf -l | fgrep 0x0c0500 [EMAIL PROTECTED]:1:1: class=0x0c0500 card=0x813f1043 chip=0x00e410de rev=0xa1 hdr=0x00 [EMAIL PROTECTED]:~# pciconf -r pci0:1:1 0x20 5001 [EMAIL PROTECTED]:~# pciconf -r pci0:1:1 0x24 5041 [EMAIL PROTECTED]:~# pciconf -r pci0:1:1 0x50 5001 [EMAIL PROTECTED]:~# pciconf -r pci0:1:1 0x54 5041 -- == - Best regards, Nikolay Pavlov. <<<--- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 4.x EoL
On Tue, 17 Oct 2006, Michael W. Oliver wrote: > 1. Be prepared to spend a lot of time in single-user mode, especially > for the 4->5 step, because there is a LOT for mergemaster to do. The > step from 5->6 is not nearly as painful. I didn't try to do the > installworld and mergemaster in multiuser, and if you do then have a > bigger set than I do. If you're setting up machines that you're going to be upgrading like this in the future, I think it's _really_ worthwhile hacking out a couple of "root slices" - that is, space for a second / and /usr - to facilitate this. You can run mergemaster on a secondary copy of your /etc (this, of course, requries that the contents of /etc are relatively quiescent for this step) and tidy up by hand. You can perform a dump & restore followed by a source upgrade, a fresh source install or a binary upgrade ad lib; just reboot (with nextboot) when done. This also means you can keep the previous OS around for a while in case there are problems with the new one. For setups that aren't amenable to automated deployments this works pretty well and gives you a safety-net for upgrades. Cheers, jan -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ We thought time travel was impossible. But that was now and this is then. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
When will the new BCE driver in HEAD be incorporated into RELENG_6?
Hi It looks like there is a "new" version of the bce driver in HEAD. When will it be incorporated into Releng_6? We are currently having some performance problems with a java application on our Dell 1950s. And it looks like it has something to do with the speed with which network I/Os are performed. We have Dell 2850s running FreeBSD 5.4/i386 SMP. With Intel nics (em) and they are performing quite well. With 34000 tcp sockets open the maximum time it takes to perform a single network I/O is about 100ms. The Dell 1950s running FreeBSD 6.2-Prerelease/i386 SMP with Broadcom nics (bce), the same application and 34000 tcp connections open. The maximum time it takes to perform a single network I/O is about 7000ms. Most of the packets the systems send/receive are rather small. We are not quite sure what could cause this behavior. If anyone has any ideas of what we could do to decrease the time it takes to perform network I/O it would be much appreciated. Regards Conrad Some information: dev.bce.0.%desc: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 dev.bce.0.%driver: bce dev.bce.0.%location: slot=0 function=0 dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x164c subvendor=0x1028 subdevice=0x01b3 class=0x02 dev.bce.0.%parent: pci9 dev.bce.0.driver_version: v0.9.6 dev.bce.0.stat_IfHcInOctets: 2346165 dev.bce.0.stat_IfHCInBadOctets: 1877825702 dev.bce.0.stat_IfHCOutOctets: 2751390538 dev.bce.0.stat_IfHCOutBadOctets: 0 dev.bce.0.stat_IfHCInUcastPkts: 360078711 dev.bce.0.stat_IfHCInMulticastPkts: 18339 dev.bce.0.stat_IfHCInBroadcastPkts: 270544 dev.bce.0.stat_IfHCOutUcastPkts: 323261730 dev.bce.0.stat_IfHCOutMulticastPkts: 147410 dev.bce.0.stat_IfHCOutBroadcastPkts: 985 dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.0.stat_Dot3StatsFCSErrors: 0 dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 dev.bce.0.stat_Dot3StatsSingleCollisionFraes: 0 dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.0.stat_Dot3StatsLateCollisions: 0 dev.bce.0.stat_EtherStatsCollisions: 0 dev.bce.0.stat_EtherStatsFragments: 0 dev.bce.0.stat_EtherStatsJabbers: 0 dev.bce.0.stat_EtherStatsUndersizePkts: 0 dev.bce.0.stat_EtherStatsOverrsizePkts: 0 dev.bce.0.stat_EtherStatsPktsRx64Octets: 44671171 dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 166377250 dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 125306581 dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 11502851 dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 3372657 dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 9137084 dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 dev.bce.0.stat_EtherStatsPktsTx64Octets: 12605056 dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 208798776 dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 82452517 dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 8532515 dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 3204492 dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 7816769 dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 dev.bce.0.stat_XonPauseFramesReceived: 0 dev.bce.0.stat_XoffPauseFramesReceived: 0 dev.bce.0.stat_OutXonSent: 0 dev.bce.0.stat_OutXoffSent: 0 dev.bce.0.stat_FlowControlDone: 0 dev.bce.0.stat_MacControlFramesReceived: 0 dev.bce.0.stat_XoffStateEntered: 0 dev.bce.0.stat_IfInFramesL2FilterDiscards: 4933702 dev.bce.0.stat_IfInRuleCheckerDiscards: 0 dev.bce.0.stat_IfInFTQDiscards: 0 dev.bce.0.stat_IfInMBUFDiscards: 0 dev.bce.0.stat_IfInRuleCheckerP4Hit: 0 dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.0.stat_CatchupInFTQDiscards: 0 dev.bce.0.stat_CatchupInMBUFDiscards: 0 dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 # vmstat -i interrupt total rate irq14: ata0 47 0 irq16: bce0 bce1548968755 1086 irq21: uhci0 uhci+ 5 0 irq78: mfi0343548 0 cpu0: timer 998576924 1976 cpu1: timer1008301350 1995 cpu3: timer1008469139 1995 cpu2: timer 995126109 1969 Total 4559785877 9023 # uname -a FreeBSD niobium.mxit.co.za 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Oct 10 13:28:54 SAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MXIT-SMP-I386 i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ENABLE_SUID_SSH in make.conf
On Wed, Oct 18, 2006 at 09:25:28AM +0200, Oliver Fromme wrote: > That name exists for historical reasons. Some time ago it > was ssh(1) itself which got the suid bit in order to be > able to read the private host key (which is readable by > root only). Access to that key is required for host-based > authentication (disabled by default). Hence the variable > named ENABLE_SSH_SUID. There is another reason for wanting this. If you still use the ssh1 RSARhosts authentication mechanism, then it needs ssh to be suid root because using a priveleged port is part of the authentication mechanism (combined with signing using the host key). This has been more or less replaced by the ssh-keysign stuff, but I guess some people may still be depending on it. David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ENABLE_SUID_SSH in make.conf
Oliver Fromme <[EMAIL PROTECTED]> writes: > For the reasons outlined above, I recommend not to change > anything at all, except correcting the documentation [...] I concur. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hald and strange error messages
Hi!
After updating my system, and enabling hald (no config, only the default
settings), I've got so many strange SCSI errors. With some limited
tests, I've found, that's because of hald. If I start it, got SCSI (and
NTP?) errors. After stopping it, errors go away. Here is a snippet from
messages (I've generated "Starting/stopping hald" messages with logger):
===
Oct 18 09:44:41 Picasso root: Starting hald
Oct 18 09:45:06 Picasso kernel: ahc0:A:2: Missed busfree. Lastphase =
0xe0, Curphase = 0x0
Oct 18 09:45:11 Picasso kernel: ahc0:A:2: Missed busfree. Lastphase =
0xe0, Curphase = 0xe4
Oct 18 09:45:44 Picasso last message repeated 5 times
Oct 18 09:46:05 Picasso last message repeated 3 times
Oct 18 09:46:06 Picasso root: Stopping hald
Oct 18 09:46:12 Picasso kernel: ahc0:A:2: Missed busfree. Lastphase =
0xe0, Curphase = 0xe4
Oct 18 09:46:47 Picasso ntpd[660]: kernel time sync disabled 2041
Oct 18 09:49:27 Picasso root: Starting hald
Oct 18 09:49:41 Picasso kernel: ahc0:A:2: Missed busfree. Lastphase =
0xe0, Curphase = 0xe4
Oct 18 09:50:05 Picasso last message repeated 4 times
Oct 18 09:50:05 Picasso login: ROOT LOGIN (root) ON ttyv2
Oct 18 09:50:12 Picasso kernel: ahc0:A:2: Missed busfree. Lastphase =
0xe0, Curphase = 0xe4
Oct 18 09:50:47 Picasso last message repeated 5 times
Oct 18 09:52:40 Picasso last message repeated 16 times
Oct 18 09:52:43 Picasso root: Stopped hald
Oct 18 09:52:47 Picasso kernel: ahc0:A:2: Missed busfree. Lastphase =
0xe0, Curphase = 0xe4
Oct 18 09:55:22 Picasso ntpd[660]: kernel time sync enabled 2001
Oct 18 10:02:19 Picasso root: Starting hald
Oct 18 10:02:28 Picasso kernel: ahc0:A:2: Missed busfree. Lastphase =
0xe0, Curphase = 0xe4
Oct 18 10:02:59 Picasso last message repeated 5 times
Oct 18 10:04:10 Picasso last message repeated 10 times
Oct 18 10:04:15 Picasso root: Stopped hald
Oct 18 10:04:17 Picasso kernel: ahc0:A:2: Missed busfree. Lastphase =
0xe0, Curphase = 0xe4
Bye, Zahy < Gabor at Zahemszky dot HU >
--
#!/bin/ksh
Z='21N16I25C25E30, 40M30E33E25T15U!';IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ
';set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break;[[ $i = ???
]]&&j=$i&&i=${i%?};typeset -i40 i=8#$i;print -n ${i#???};[[ "$j" = ???
]]&&print -n "${j#??} "&&j=;typeset +i i;};IFS=' 0123456789 ';set --
$Z;for i;{ [[ $i = , ]]&&i=2;[[ $i = ?? ]]||typeset -l i;j="$j
$i";typeset +l i;};print "$j"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic mounting /tmp - 6.2-PRERELEASE
Brooks Davis wrote: > It's known that an appropriately corrupt file system can do > this, but the causes (there are probably several) are not yet > known. There is some speculation that the only solution is > to add checksums to all key data sections. Which means that ZFS will solve the problem, as soon as PJD has finished the port to FreeBSD. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ENABLE_SUID_SSH in make.conf
Ruslan Ermilov wrote: > Albert Chin wrote: > > According to make.conf(5): > > ENABLE_SUID_SSH > >(bool) Set this to install ssh(1) with the > >set-user-ID bit turned on. > > > > However, I think ENABLE_SUID_SSH only sets the suid bit for > > /usr/libexec/ssh-keysign. That name exists for historical reasons. Some time ago it was ssh(1) itself which got the suid bit in order to be able to read the private host key (which is readable by root only). Access to that key is required for host-based authentication (disabled by default). Hence the variable named ENABLE_SSH_SUID. But then the OpenSSH folks decided that it is preferable not to make ssh(1) suid root. They created a small tool to access the private host key, and made only that tool setuid root. That's ssh-keysign(8). However, the name of the variable wasn't changed, so hostbased authentication didn't break for those people who enabled it. > > Why isn't /usr/libexec/ssh-keysign suid by default anyway? It's > > pointless without it. > > Good question. Let's see what our maintainer has to say about it. > My feeling as well is that the option should just be removed. Personally I have never used ssh-keysign, because I think that host-based authentication (which is the only thing that requires ssh-keysign to be suid-root) is too insecure. I guess most people don't even know that it exists. :-) Since I prefer not to have any superfluous suid binaries on my system, I'm quite happy with the default of ssh-keysign not being suid-root. Note that host-based authentication is disabled by default anyway (for good reason), so it doesn't really make sense to make ssh-keysign suid-root by default. For the reasons outlined above, I recommend not to change anything at all, except correcting the documentation in make.conf(5) and in /usr/share/examples/etc/make.conf, like this: ENABLE_SUID_SSH (bool) Set this to install ssh-keysign(8) with the set-user-ID bit turned on. This is only required for hostbased authentication which is disabled by default. See the description of the ~/.rhosts and /etc/hosts.equiv files in sshd(8) for details. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
