Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

stable-digest V5 #790

0 views
Skip to first unread message

owner-freebsd...@freebsd.org

unread,
Feb 10, 2003, 7:16:39 PM2/10/03
to

stable-digest Monday, February 10 2003 Volume 05 : Number 790

In this issue:
[none]
Re: Invalid ps start time values for kernel processes ?
CepNews Şubat 2003
Moxa Smartio C104H/PCI and pucdata.c
Re: IPSEC problems after upgrade
ipfw traffic shaping
RE: HEADS UP: Broken if_dc NICs with MACs like 08:08[...] or 00:00[...]
Re: Moxa Smartio C104H/PCI and pucdata.c
Re: Odd "hanging" behavior with -STABLE ...
Re: sshd_config man page typo
Re: sshd_config man page typo
PCI oddity
Re: PCI oddity
Re: PCI oddity
Re: PCI oddity
ipsec & ipfw: 4.7-release vs -stable
Re: PCI oddity
ng_fec && pseudo-device vlan

----------------------------------------------------------------------

Date: Sun, 9 Feb 2003 23:32:53 +0100 (CET)
From: "mike...@infected.bounceme.net" <mike...@infected.bounceme.net>
Subject: [none]

subscribe freebsd-stable

------------------------------

Date: Sun, 9 Feb 2003 23:56:40 +0100
From: Thomas Seck <tmseck...@netcologne.de>
Subject: Re: Invalid ps start time values for kernel processes ?

* Wes Peters (w...@softweyr.com):

> On Saturday 08 February 2003 18:47, Thomas Seck wrote:
> >
> > NetBSD allows you (when I last looked at it, it was 1.5.something) to
> > set a kernel variable for the difference between CMOS time and UTC at
> > compile time. You would then need two kernels to reflect DST.
>
> Or a hint with the offset, and an operator or program smart enough
> to change the hint on DST changes.

Yes; now I remember reading a snippet of documentation about changing
the offset at runtime; my bad. I wonder whether the NetBSD approach is a
solution to this problem?

--Thomas

------------------------------

Date: Mon, 10 Feb 2003 06:10:37 +0200
From: Cep...@CepNews.com
Subject: CepNews Şubat 2003

<html>
<head>
<title>CepNews</title>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-9">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1254">
</head>

<body bgcolor="#FFFFFF" text="#000000">
<table width="500" border="0" height="77" align="center" cellpadding="0" cellspacing="0">
<tr>
<td height="77" width="16"></td>
<td height="77" width="62"><a href="http://217.31.235.140/cgi-bin/to.cgi?dta=T200302_3.dta&l=baslik"><img src="http://www.telsim.com.tr/mails/tlsm_lg.gif" width="62" height="77" border="0"></a></td>
<td height="77" width="93" background="http://www.telsim.com.tr/mails/bg_ln.gif"></td>
<td height="77" width="147"><a href="http://217.31.235.140/cgi-bin/to.cgi?dta=T200302_3.dta&l=baslik"><img src="http://www.telsim.com.tr/mails/hdr.gif" width="147" height="77" border="0"></a></td>
<td height="77" width="67" background="http://www.telsim.com.tr/mails/bg_ln.gif"></td>
<td height="77" width="99"><img src="http://www.telsim.com.tr/mails/trh_subat.gif" width="99" height="77"></td>
<td height="77" width="16"></td>
</tr>
</table>
<table width="500" border="0" align="center" height="30" cellpadding="0" cellspacing="0">
<tr>
<td width="500" height="30"><img src="http://217.31.235.157/cimage/cepnews_200302_3.gif" width="1" height="1" border="0"></td>
</tr>
</table>
<table width="500" border="0" cellspacing="0" cellpadding="0" align="center" height="200">
<tr>
<td width="16"></td>
<td bgcolor="#efefef" colspan="2" rowspan="7">

<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="yazi" height="15" bgcolor="#FFFFFF"></td>
</tr>
<td align="center" height="5" bgcolor="#FFFFFF"></td>
</tr>
<tr>
<td align="center" bgcolor="#FFFFFF"> <font size="2" face="Verdana, Arial, Helvetica, sans-serif"><b><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><b></b></font></b></font>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<!-- fwtable fwsrc="Untitled" fwbase="ilan_birilk.jpg" fwstyle="Dreamweaver" fwdocid = "742308039" fwnested="0" -->
<tr bgcolor="#FFFFFF">
<td width="140"><img src="http://www.telsim.com.tr/kampanyalar/globals/sol_ust.gif" width="135" height="101" hspace="5"></td>
<td></td>
<td></td>
<td align="center"><img src="http://www.telsim.com.tr/kampanyalar/globals/sim.gif" width="135" height="101"></td>
<td align="center"><img src="http://www.telsim.com.tr/kampanyalar/globals/sticker.gif" width="101" height="179"></td>
</tr>
<tr bgcolor="#FFFFFF">
<td width="140"></td>
<td></td>
<td colspan="2"></td>
<td height="15"></td>
</tr>
<tr bgcolor="#FFFFFF">
<td colspan="3"><img src="http://www.telsim.com.tr/kampanyalar/globals/yazi.gif" width="135" height="88" hspace="5"></td>
<td colspan="2"><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><b>TELSİM'DEN
TÜRKİYE'YE BİR İLK.<br>
<br>
</b></font><font face="Verdana, Arial, Helvetica, sans-serif" size="1">Telsim,
dünyanın en büyük uydu telekomünikasyon operatörü Globalstar
ile yaptığı işbirliği sonucunda, Türkiye'nin uydu destekli hizmet
veren ilk GSM operatörü olmuştur. Kısaca, Telsim-Globalstar
birlikteliği, dünyanın her noktasındaki dağ, açık deniz, ova,
orman gibi yerleşim merkezlerinden uzak olan ve GSM, yani hücresel
telekomünikasyon sistemlerinin kapsama alanı dışında kalan bölgelerde
dahi mobil iletişim olanağı sunmaktadır.</font></td>
</tr>
<tr bgcolor="#FFFFFF">
<td colspan="3">&nbsp;</td>
<td colspan="2"><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><font color="#FF0000"><a href="http://217.31.235.140/cgi-bin/to.cgi?dta=T200302_3.dta&l=kampanya"><br>
Ayrıntılı bilgi için tıklayın...</a></font></font></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="yazi" height="15" bgcolor="#FFFFFF"></td>
</tr>
<tr>
<td height="1" bgcolor="#FFFFFF"></td>
</tr>

<td align="center" height="1" bgcolor="#000000"></td>
</tr>
<tr>
<td align="center" bgcolor="#FFFFFF">
<table width="100%" border="0" cellspacing="0" cellpadding="0"
height="1">
<tr>
<td width="94%" valign="top" height="1">&nbsp;</td>
</tr>
<tr>
<td width="94%" valign="top" height="1"><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><b><font size="2"><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><img src="http://www.telsim.com.tr/mails/nokia7650_new.gif" width="100" height="201" align="left" hspace="1"></font><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><b><font size="2"><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><b><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><img src="http://www.telsim.com.tr/mails/nokia3650_new.gif" width="100" height="225" align="right" hspace="1"></font></b></font></font></b></font><font size="3">Cep
telefonunu cep televizyonu </font><font size="3">yaptık! </font></font></b></font>
<p><font face="Verdana, Arial, Helvetica, sans-serif" size="1">Türkiye'de
artık cep telefonundan televizyon yayınlarını izleyebileceksiniz.
Dünyada, Mobile Video Streaming (MVS) adı verilen &quot;cepte
televizyon yayını&quot; izleme imkânını veren bu teknolojiyi,
Türkiye'de, Türk bilgisayar mühendisleri yarattı. Telsim Teknolojisi'nin
arkasındaki, 150 bilgisayar mühendisi. Telsim'in Türkiye ve
dünya üzerindeki rekabet gücünün ekonomik ve teknolojik boyutlarını
önemli ölçülerde artıran bu beyin gücü, Telsim'in üstünlüklerinden
biri. Bu üstünlüğü sayesinde Telsim, dilediği zaman, dilediği
teknolojik yenilikleri kendi yaratabiliyor. Kimseye bağımlı
olmadan devreye sokabiliyor. İşte bu ayrıcalık, Telsim'le
diğerleri arasındaki farkı yaratıyor. Telsim Teknolojisi,
şimdi Türkiye'ye MVS, yani &quot;cepte televizyon yayını&quot;nı
sunuyor. MVS'ten yaralanarak, cep televizyonunuzdan pardon
cep telefonunuzdan, 24 saat Star televizyonunu, haftanın TOP
10 video kliplerini, futbolla ilgili haberleri, maç görüntülerini,
Türkiye'den ve dünyadan önemli politik ve ekonomik haberleri,
son dakika gelişmelerini, magazin haberlerini 1 Nisan 2003
tarihine kadar ücretsiz izleyebilirsiniz. Telsim'i diğerlerinden
farklı kılan mühendisler ordusunun, yani beyin gücünün Telsim'e
ve Türkiye'ye getirdiği teknolojik yenilikler devam edecek.
Bekleyin.<br>
<br>
<b></b><b></b></font><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><font color="#FF0000"><a href="http://217.31.235.140/cgi-bin/to.cgi?dta=T200302_3.dta&l=mvs">Ayrıntılı
bilgi için tıklayın...</a></font></font></p>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="yazi" height="15" bgcolor="#FFFFFF">
<p>&nbsp;</p>
</td>
</tr>
<tr>
<td height="1" bgcolor="#000000"></td>
</tr>
<tr>
<td height="1" bgcolor="#FFFFFF"></td>
</tr>
<tr>
<td class="yazi" height="15" bgcolor="#FFFFFF"></td>
</tr>
<tr>
<td align="left" bgcolor="#FFFFFF"><font face="Verdana, Arial, Helvetica, sans-serif" size="1">Bu
mesaj size Telsim Mobil Telekomünikasyon Hizmetleri A.Ş. tarafından<br>
gönderilmiştir. Bu tür mesajları almak istemiyorsanız lütfen <a href="http://217.31.235.140/cgi-bin/to.cgi?dta=T200302_3.dta&l=uyelik">tıklayınız</a>
</font>
<p><font face="Verdana, Arial, Helvetica, sans-serif" size="1">This
message was sent to you by Telsim Mobile Telecommunications. To
unsubscribe<br>
from this service, please <a href="http://217.31.235.140/cgi-bin/to.cgi?dta=T200302_3.dta&l=uyelik_en">click here</a></font></p></td>
</tr>
<tr>
<td class="yazi" height="15" bgcolor="#FFFFFF"></td>
</tr>
<tr>
<td height="1" bgcolor="#FFFFFF"></td>
</tr>
<tr>
<td height="1" bgcolor="#FFFFFF"></td>
</tr>
</table>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
</tr>
</table>

</td>
<td width="16"></td>
</tr>
</table>
</body>
</html>

------------------------------

Date: Mon, 10 Feb 2003 10:28:00 +0300 (MSK)
From: solo...@stroimontazh.spb.ru
Subject: Moxa Smartio C104H/PCI and pucdata.c

Hello!

I have Moxa Smartio C104H/PCI card and FreeBSD 4.7-STABLE. This card not listed in sys/dev/puc/pucdata.c and it doesn't work by default.
I added the following to pucdata.c (diff -uw):

linas# diff -uw sys/dev/puc/pucdata_orig.c sys/dev/puc/pucdata.c
- --- sys/dev/puc/pucdata_orig.c Fri Jan 17 16:08:05 2003
+++ sys/dev/puc/pucdata.c Sun Jan 26 22:39:05 2003
@@ -861,6 +861,18 @@
},
},
+ /* Moxa Technologies Co., Ltd. PCI I/O Card 4S RS232/422/485 */
+ { "Moxa Technologies, Smartio C104H/PCI",
+ { 0x1393, 0x1040, 0, 0 },
+ { 0xffff, 0xffff, 0, 0, },
+ {
+ { PUC_PORT_TYPE_COM, 0x18, 0x00, COM_FREQ * 8 },
+ { PUC_PORT_TYPE_COM, 0x18, 0x08, COM_FREQ * 8 },
+ { PUC_PORT_TYPE_COM, 0x18, 0x10, COM_FREQ * 8 },
+ { PUC_PORT_TYPE_COM, 0x18, 0x18, COM_FREQ * 8 },
+ },
+ },
+
/* Moxa Technologies Co., Ltd. PCI I/O Card 8S RS232 */
{ "Moxa Technologies, C168H/PCI",
{ 0x1393, 0x1680, 0, 0 },

and now it works.
Here is my Moxa related dmesg output:

puc0: <Moxa Technologies, Smartio C104H/PCI> port
0xa000-0xa00f,0x9c00-0x9c3f,0x9800-0x987f irq 11 at device 4.0 on pci2
sio2: type 16550A
sio3: type 16550A
sio4: type 16550A
sio5: type 16550A

Maybe this will be interesting for someone.

------------------------------

Date: Mon, 10 Feb 2003 09:30:00 +0100
From: Borja Marcos <borj...@sarenet.es>
Subject: Re: IPSEC problems after upgrade

On Saturday 08 February 2003 10:22, Peter Haight wrote:
> I figured out what the problem was, so I thought I'd post the solution
> because I never found it when I was searching the archives. Basically,
> there was a change to the way IPSEC worked and the end result is that
> the packets get run through the firewall after they get decrypted and s=
o
> they look like they are coming from an internal network on an external
> interface and so they get rejected by a firewall rule that was rejectin=
g
> private network ip addresses.

=09Hello,

=09I am using IPSec to secure the traffic in a wireless network, and I ha=
d=20
the firewall rules for the wireless interface (wi0) configured so that it=
=20
would *only* accept IKE and ESP traffic.

=09After upgrading to -STABLE my setup stopped working due to the behavio=
r=20
change in ipfw; decrypted packets were passed again to IPFW.

=09After a suggestion I read in this list, I tried IPFW2 using "layer2"=20
rules. It works, but I found some quirks.=20

=09My new setup is:

# This rule *permits* ARP.
add 190 allow ip from any to any layer2 mac-type 0x0806 via wi0

# 1: IKE
add 200 allow udp from 192.168.2.0/24 500 to me 500 recv wi0 layer2
add 210 allow udp from me 500 to 192.168.2.0/24 500 xmit wi0 layer2

# 2: ESP
add 300 allow esp from 192.168.2.0/24 to me recv wi0 layer2
add 310 allow esp from me to 192.168.2.0/24 xmit wi0 layer2

# After this, I had a problem: traffic *coming* from wi0 could not be sen=
t=20
# via fxp0 because it seems that it was passed to ipfw2 gain before being
# sent. Adding this rule fixed the problem.

add 340 allow all from any to any via fxp0 layer2

# Now we deny unwanted traffic (remember, "layer2" through wi0)
# This had an unwanetd side-effect; traffic received from the tunnel coul=
d=20
# not be sent because it was apparently "labelled" as "coming from wi0" b=
y=20
# ipfw, and it was checked again when sending the packets via fxp0, despi=
te=20
# the fact that the rule specified "wi0". After I added rule 340 it=20
# worked.

add 400 deny log all from any to 192.168.2.2 xmit wi0 layer2
add 410 deny log all from 192.168.2.2 to any recv wi0 layer2

# These two rules permit traffic from/through the encrypted tunnel.
add 400 deny log all from any to 192.168.2.2 xmit wi0 layer2
add 410 deny log all from 192.168.2.2 to any recv wi0 layer2

=09Summarizing:

=09I think ipfw2 is much superior to ipfw. The ability to work with layer=
2=20
rules is really great. However, I think configuration is tricky. And I am=
=20
puzzled by the apparent confusion with the interfaces (see rules 340, 400=
=20
and 410). Is this a bug?

=09Regards,


=09Borja.

------------------------------

Date: Mon, 10 Feb 2003 10:29:31 +0100
From: Martin Hudec <cor...@corwin.sk>
Subject: ipfw traffic shaping

Hello,

I have question regarding ipfw traffic shaping:

This were default settings:
00004: 2.000 Mbit/s 0 ms 30 sl. 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/By=
te
Drp
0 tcp 192.168.x.x/1037 y.y.y.y/80 299073 117448216 0 0 =
1

New settings are the same but with 50 sl. instead of former 30.
Is this number of slots in queue?
How can I change it to former settings?
Can anyone help me please?

- --
Martin Hudec
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

:m: +421 907 303 393
:@: cor...@corwin.sk
:w: http://www.corwin.sk

"In google non est, ergo non est."
- - unknown IRC operator

------------------------------

Date: Mon, 10 Feb 2003 12:49:34 +0200
From: "Tony Russell" <To...@clarotech.co.za>
Subject: RE: HEADS UP: Broken if_dc NICs with MACs like 08:08[...] or 00:00[...]

I have a whole bunch of "SMC EZ Card 10/100 Mbps Fast Ethernet PCI card"
(SMC1255 series) that we use as a log profile PCI card that suffer with
00:08:00:08:00:08 MAC addresses.

Your patch resolves the problem.

_________________________________________________
Antony Russell
Technical Director
Clarotech Consulting (Pty) Ltd
EMail: To...@Clarotech.co.za
Phone: 021.671.5350


- -----Original Message-----
From: Martin Blapp [mailto:m...@imp.ch]=20
Sent: 08 February 2003 00:48
To: freebsd...@FreeBSD.ORG
Cc: hac...@FreeBSD.ORG
Subject: HEADS UP: Broken if_dc NICs with MACs like 08:08[...] or
00:00[...]


Hi all,

Many if_dc cards are still broken in RELENG_4. Can you please
try this diff if you own such a broken card ?

If you have a Conexant LANfinity MiniPCI 10/100BaseTX card, I'd like
to have feedback if full duplex mode works now too.

Thank you very much for your tests. I'd like to see all these
DEC/Intel 21143 clone cards fixed for 4.8R.

Martin

------------------------------

Date: Mon, 10 Feb 2003 14:29:52 +0300
From: "Sergey A. Osokin" <o...@freebsd.org.ru>
Subject: Re: Moxa Smartio C104H/PCI and pucdata.c

On Mon, Feb 10, 2003 at 10:28:00AM +0300, solo...@stroimontazh.spb.ru wrote:
> Hello!
>
> I have Moxa Smartio C104H/PCI card and FreeBSD 4.7-STABLE. This card not listed in sys/dev/puc/pucdata.c and it doesn't work by default.
> I added the following to pucdata.c (diff -uw):
>
> linas# diff -uw sys/dev/puc/pucdata_orig.c sys/dev/puc/pucdata.c
> --- sys/dev/puc/pucdata_orig.c Fri Jan 17 16:08:05 2003
> +++ sys/dev/puc/pucdata.c Sun Jan 26 22:39:05 2003
> @@ -861,6 +861,18 @@
> },
> },
> + /* Moxa Technologies Co., Ltd. PCI I/O Card 4S RS232/422/485 */
> + { "Moxa Technologies, Smartio C104H/PCI",
> + { 0x1393, 0x1040, 0, 0 },
> + { 0xffff, 0xffff, 0, 0, },
> + {
> + { PUC_PORT_TYPE_COM, 0x18, 0x00, COM_FREQ * 8 },
> + { PUC_PORT_TYPE_COM, 0x18, 0x08, COM_FREQ * 8 },
> + { PUC_PORT_TYPE_COM, 0x18, 0x10, COM_FREQ * 8 },
> + { PUC_PORT_TYPE_COM, 0x18, 0x18, COM_FREQ * 8 },
> + },
> + },
> +
> /* Moxa Technologies Co., Ltd. PCI I/O Card 8S RS232 */
> { "Moxa Technologies, C168H/PCI",
> { 0x1393, 0x1680, 0, 0 },
>
> and now it works.
> Here is my Moxa related dmesg output:
>
> puc0: <Moxa Technologies, Smartio C104H/PCI> port
> 0xa000-0xa00f,0x9c00-0x9c3f,0x9800-0x987f irq 11 at device 4.0 on pci2
> sio2: type 16550A
> sio3: type 16550A
> sio4: type 16550A
> sio5: type 16550A
>
> Maybe this will be interesting for someone.

Please, if it possible, make a patch against -CURRENT and send PR.
Thanks.

- --

Rgdz, /"\ ASCII RIBBON CAMPAIGN
Sergey Osokin aka oZZ, \ / AGAINST HTML MAIL
http://ozz.pp.ru/ X AND NEWS
/ \

------------------------------

Date: Mon, 10 Feb 2003 03:54:17 -0800
From: David Schultz <dsch...@uclink.Berkeley.EDU>
Subject: Re: Odd "hanging" behavior with -STABLE ...

Thus spake Marc G. Fournier <scr...@hub.org>:
> At first I'd thought it might be hardware related, but if it is, its a
> behaviour I haven't seen before ...
>
> I have two machines .. one -STABLE as of Feb 1st, the other of Feb 6th ...
> the one on Feb 6th itermediantly "hangs" ... but doesn't stay hung ...
>
> For instance, I woke up this morning to checked on the one that has been
> giving problems, and, once more, it was 'hung' ... checked ruptime on the
> other server, and it reported that it was down 9hrs ... type 'uptime' on
> an option console I have on the 'hung' server, and after a couple of
> minutes, it comes back with the answer, and I can proceed to enter a few
> more commands ... come back a bit later, and its 'hung' again, with pretty
> much the same routine ...
>
> I'm trying to CVSup back to the sources from the 1st, to see if that helps
> correct the problem, but does anyone have any ideas on what might be
> causing this? There is nothing in /var/log/messages to indicate a problem

Does it seem to be basically responsive (e.g. you can switch
virtual consoles), but processes hang when they try to do I/O? If
you can run top while you see this problem, it should tell you
what state processes are getting stuck in. You can get the same
information by breaking into the debugger and typing 'ps'. I had
a problem like this that involved the SCSI controller randomly
timing out. Decreasing the tag queue length solved the problem.

------------------------------

Date: Mon, 10 Feb 2003 15:11:24 +0100
From: "Karl M. Joch" <k.j...@kmjeuro.com>
Subject: Re: sshd_config man page typo

DES, this is the copy of the man pag on the system:


UsePrivilegeSeparation
Specifies whether sshd separates privileges by creating an
unprivileged child process to deal with incoming network
traffic.
After successful authentication, another process will be
created
that has the privilege of the authenticated user. The goal of
privilege separation is to prevent privilege escalation by
con-
taining any corruption within the unprivileged processes. The
default is ``no''.

- --
Best regards / Mit freundlichen Gruessen,

Karl M. Joch

------------------------------

Date: Mon, 10 Feb 2003 15:13:09 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: sshd_config man page typo

"Karl M. Joch" <k.j...@kmjeuro.com> writes:
> DES, this is the copy of the man pag on the system:
> [...]

Your system is out of date.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Mon, 10 Feb 2003 09:54:41 -0500
From: Jason Andresen <jand...@mitre.org>
Subject: PCI oddity

Hello,
I have an Abit BX6-II motherboard with 5 PCI slots. Whenever
I try to populate both of the bottom two slots, FreeBSD crash dumps
on boot. I have tried this with a variety of cards over the years,
but I always have the same results.

Is this a FreeBSD problem, a motherboard problem, or a problem with the
PCI cards?

Recently I realized that I really need 6 PCI cards in the box (5 ATA
controllers and 1 NIC). Right now it's semi-crippled with just the 4
cards (3 ATA controllers with some drives on slaves and 1 NIC), and I
was thinking about upgrading to a Tyan Trinity 400. Will I not be able
to populate this board beyond 4 cards?

- --
\ |_ _|__ __|_ \ __| Jason Andresen jand...@mitre.org
|\/ | | | / _| Network and Distributed Systems Engineer
_| _|___| _| _|_\___| Office: 703-883-7755

------------------------------

Date: Mon, 10 Feb 2003 10:20:35 -0500
From: Jason Andresen <jand...@mitre.org>
Subject: Re: PCI oddity

David Wolfskill wrote:
> Check your dmesg (might want to do a "boot -v" first). Those (physical)
> 2 PCI slots may be sharing a resource in some way.
>
> Might also check any docs for the board & BIOS.
>
> Hmmm... during the boot, does the BIOS see the different cards OK?

Yeah, the cards always probe in the bios just fine. FreeBSD probes
the cards too (they show up in the dmesg).

The problem comes when the ATA drive list has to be displayed. FreeBSD
crash dumps right as it tries to print that list.

I'll post the relevant bits from the current dmesg to illustrate:

FreeBSD 4.7-RELEASE #1: Tue Jan 14 10:04:01 EST 2003
ro...@jubei.ceyah.org:/usr/src/sys/compile/JUBEI
...
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
...
atapci0: <Intel PIIX4 ATA33 controller> port 0xf000-0xf00f at device 7.1
on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
...
atapci1: <Sil 0680 ATA133 controller> port
0xb400-0xb40f,0xb000-0xb003,0xac00-0xac07,0xa800-0xa803,0xa400-0xa407
mem 0xdf004000-0xdf0040ff irq 5 at device 9.0 on pci0
ata2: at 0xa400 on atapci1
ata3: at 0xac00 on atapci1
atapci2: <CMD 649 ATA100 controller> port
0xc800-0xc80f,0xc400-0xc403,0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb807
irq 12 at device 11.0 on pci0
ata4: at 0xb800 on atapci2
ata5: at 0xc000 on atapci2
atapci3: <Promise TX2 ATA100 controller> port
0xdc00-0xdc0f,0xd800-0xd803,0xd400-0xd407,0xd000-0xd003,0xcc00-0xcc07
mem 0xdf000000-0xdf003fff irq 10 at device 13.0 on pci0
ata6: at 0xcc00 on atapci3
ata7: at 0xd400 on atapci3
dc0: <ADMtek AN985 10/100BaseTX> port 0xe000-0xe0ff mem
0xdf005000-0xdf0053ff irq 11 at device 15.0 on pci0
dc0: Ethernet address: 00:03:6d:20:1e:8a
miibus0: <MII bus> on dc0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
...
ad0: 38166MB <WDC WD400BB-00CCB0> [77545/16/63] at ata0-master UDMA33
[ This is where it crashes with the 5th card installed]
ad4: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata2-master UDMA100
ad5: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata2-slave UDMA100
ad6: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata3-master UDMA100
ad7: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata3-slave UDMA100
ad8: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata4-master UDMA100
ad9: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata4-slave UDMA100
ad10: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata5-master UDMA100
ad11: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata5-slave UDMA100
ad12: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata6-master UDMA100
ad14: 76319MB <MAXTOR 4K080H4> [155061/16/63] at ata7-master UDMA100
acd0: CDROM <FX400> at ata1-master PIO3


This machine is a hodge-podge of hardware because it was made from spare
parts (except for the 80GB HDDs). It's design goal was to make a cheap,
large, cheap, reasonable performance, cheap fileserver. The $100 mobo
hurts goals 1, 3, and 5, but if it helps goal 4 I'm willing to bite the
bullet.

This is actually the second life of this box. The first configuration
had 2 filesystem. A big 6 disk and a smaller 4 disk one. The 6 disk
was made from all of the disks acting as masters, while the smaller one
consisted of the slaves. It worked ok, but the larger one needed more
room and we got a secondary fileserver to take over the job of the
smaller one (backups).

- --
\ |_ _|__ __|_ \ __| Jason Andresen jand...@mitre.org
|\/ | | | / _| Network and Distributed Systems Engineer
_| _|___| _| _|_\___| Office: 703-883-7755

------------------------------

Date: Mon, 10 Feb 2003 10:23:01 -0500
From: Jason Andresen <jand...@mitre.org>
Subject: Re: PCI oddity

Phil Reynolds wrote:
> On Mon, Feb 10, 2003 at 09:54:41AM -0500, Jason Andresen wrote:
>
>>Hello,
>> I have an Abit BX6-II motherboard with 5 PCI slots. Whenever
>>I try to populate both of the bottom two slots, FreeBSD crash dumps
>>on boot. I have tried this with a variety of cards over the years,
>>but I always have the same results.
>>
>>Is this a FreeBSD problem, a motherboard problem, or a problem with the
>>PCI cards?
>
>
> A motherboard issue. It is normal for some slots to share bus mastering or
> IRQs. RTFM, it tells you which ones do, and also which ones share with on-board
> kit.

My manual doesn't tell me squat about the interrupts on the board. My
guess what that the two slots share an IRQ, because PCI only has IIRC 4
IRQ lines to go around. That's why I was worried it might be an issue
with FreeBSD being unable to support shared cards.

It is the bottom two PCI slots that give me problems though (one of
which is the shared PCI/ISA slot, but that doesn't seem to matter).

>>Recently I realized that I really need 6 PCI cards in the box (5 ATA
>>controllers and 1 NIC). Right now it's semi-crippled with just the 4
>>cards (3 ATA controllers with some drives on slaves and 1 NIC), and I
>>was thinking about upgrading to a Tyan Trinity 400. Will I not be able
>>to populate this board beyond 4 cards?
>
>
> It all depends on what is happy to share interrupts etc.

Are there certain cards that are known to be good about sharing interrupts?

- --
\ |_ _|__ __|_ \ __| Jason Andresen jand...@mitre.org
|\/ | | | / _| Network and Distributed Systems Engineer
_| _|___| _| _|_\___| Office: 703-883-7755

------------------------------

Date: Mon, 10 Feb 2003 10:48:02 -0500
From: Bill Moran <wmo...@potentialtech.com>
Subject: Re: PCI oddity

Jason Andresen wrote:
> Phil Reynolds wrote:
>
>> On Mon, Feb 10, 2003 at 09:54:41AM -0500, Jason Andresen wrote:
>>
>>> Hello,
>>> I have an Abit BX6-II motherboard with 5 PCI slots. Whenever
>>> I try to populate both of the bottom two slots, FreeBSD crash dumps
>>> on boot. I have tried this with a variety of cards over the years,
>>> but I always have the same results.
>>>
>>> Is this a FreeBSD problem, a motherboard problem, or a problem with the
>>> PCI cards?
>>
>> A motherboard issue. It is normal for some slots to share bus
>> mastering or
>> IRQs. RTFM, it tells you which ones do, and also which ones share with
>> on-board
>> kit.
>
> My manual doesn't tell me squat about the interrupts on the board. My
> guess what that the two slots share an IRQ, because PCI only has IIRC 4
> IRQ lines to go around. That's why I was worried it might be an issue
> with FreeBSD being unable to support shared cards.

In my experience, that's how it's set up. Can guarantee it with your board,
but that's typical.

> It is the bottom two PCI slots that give me problems though (one of
> which is the shared PCI/ISA slot, but that doesn't seem to matter).

No, but usually those last two slots share an interrupt.

>>> Recently I realized that I really need 6 PCI cards in the box (5 ATA
>>> controllers and 1 NIC). Right now it's semi-crippled with just the 4
>>> cards (3 ATA controllers with some drives on slaves and 1 NIC), and I
>>> was thinking about upgrading to a Tyan Trinity 400. Will I not be
>>> able to populate this board beyond 4 cards?
>>
>> It all depends on what is happy to share interrupts etc.
>
> Are there certain cards that are known to be good about sharing interrupts?

Oh yeah. Make sure the card is designed to share interrupts or it won't
work worth a hoot. Can't give you a list of what does and doesn't work
off the top of my head ... I know most Intel NICs share interrupts OK.

- --
Bill Moran
Potential Technologies
http://www.potentialtech.com

------------------------------

Date: Mon, 10 Feb 2003 11:42:06 -0500 (EST)
From: Andriy Gapon <aga...@cv-nj.com>
Subject: ipsec & ipfw: 4.7-release vs -stable

Is there any remedy expected before 4.8 release for the situation with
ipsec & ipfw interaction that was created after 'ip_input.c 1.130.2.40,
MFC: 1.214' ?

The reason I am asking this question with such a big crosspost is that it
seems that all previous discussions on this topic resulted in nothing. And
this change definetely breaks things for those who use ipsec without extra
stuff like gif tunnels. It definetely doesn't look like a kind of change
welcomed in -stable branch, not mentioning a potential security
vulnaribity for those who can not use gif.

I apologize in the case I have missed any latest developments in this
area.

- --
Andriy Gapon

------------------------------

Date: Mon, 10 Feb 2003 21:51:20 +0100
From: Thierry Herbelot <thi...@herbelot.com>
Subject: Re: PCI oddity

Hello,

I don't know if it's relevant or not, but I've got here an ASUS A7V333, with
all 5 PCI slots used, including a NIC (which could be included on-board), an
IDE board, and an SCSI board (also with a bktr and a PCI grfx board)

TfH

------------------------------

Date: Mon, 10 Feb 2003 16:15:09 -0800
From: Mike Hogsett <hog...@csl.sri.com>
Subject: ng_fec && pseudo-device vlan

Why don't ng_fec (Cisco FastEtherChannel netgraph module) and
`pseudo-device vlan' (802.1q trunking) work together?

I can get each of them to work independently.

If it makes any difference I cvsup'd to (and built/installed) RELENG_4
this morning

The following is my goal :

Cisco Switch FreeBSD

/Port 4/1--------------fxp0\ /vlan0
dot1q Trunk - EtherChannel< >--fec0---<
\Port 4/2--------------fxp1/ \vlan1
\vlan2
\vlanN

I set this up as follows :

kldload ng_fec
/usr/sbin/ngctl mkpeer fec dummy fec
/usr/sbin/ngctl msg fec0: add_iface '"fxp0"'
/usr/sbin/ngctl msg fec0: add_iface '"fxp1"'
ifconfig fxp0 up
ifconfig fxp1 up
ifconfig fec0 up
ifconfig vlan0 inet 10.107.1.83 netmask 255.255.255.0 vlan 1 vlandev fec0 up

If I `tcpdump' fxp0 I see dot1q tagged packets
If I `tcpdump' fxp1 I see dot1q tagged packets
If I `tcpdump' fec0 I see dot1q tagged packets
If I `tcpdump' vlan0 I see nothing...

I am not skilled enough to diagnose the kernel internals to discern why
this doesn't work. I am willing to test any patches that may turn up.

Thanks

- Mike Hogsett

------------------------------

End of stable-digest V5 #790
****************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-stable-digest in the body of the message

0 new messages