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

Dismiss

stable-digest V5 #778

2 views

Skip to first unread message

owner-freebsd...@freebsd.org

unread,

Jan 29, 2003, 3:05:39 PM1/29/03

stable-digest Wednesday, January 29 2003 Volume 05 : Number 778

In this issue:
Re: 4.7-R-p3: j.root-servers.net
Re: Power off
Re: Power off
Re: 4.7-R-p3: j.root-servers.net
Re: Problem with rcp -r
Re: Problem with rcp -r
strange data
This looks like a bug to me....
BIND 8.3.4 imported
Re: Power off
ipfw/natd problem with tonight's releng_4
TCP oddities in -STABLE
bizarre ep (3c509-Combo) behavior: one and a half init, minimal throughput
when make installkernel doesn't
Re: when make installkernel doesn't
disklabel not writeable
Re: TCP oddities in -STABLE
Re: when make installkernel doesn't
Re: bizarre ep (3c509-Combo) behavior: one and a half init, minimal throughput
Re: when make installkernel doesn't
Re: bizarre ep (3c509-Combo) behavior: one and a half init, minimal throughput
Compaq ES40 Alpha, FreeBSD 5.0-RELEASE - install issue.

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

Date: Tue, 28 Jan 2003 10:57:22 -0800 (PST)
From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: Re: 4.7-R-p3: j.root-servers.net

:
:That's good to know... I was kind of surprised that it was in the db at
:all.
:
:> BIND 9 will complain if there is additional data in the hints.
:
:Even better. :)
:
:--
:

Ok, I'm thinking then that it's better to load it as a real zone
file. Why do it that way instead of allowing updates via a root
server? Because in the last ten years I've had a number of problems
with individual root servers returning bad data. It doesn't happen
very often, but it does happen. I've have never had problems with
the downloaded root.zone, and if I ever do at least I'll know that
it's the likely cause since I only download it once a week on sunday,
and I can review the current and prior zone files without having to
dump named. From my point of view as an administrator that's the more
secure approach.

In anycase, there are obviously many ways to keep an up-to-date root
zone, my methodology is only one out of that list.

-Matt

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

Date: Tue, 28 Jan 2003 11:24:54 -0800
From: Andy Sparrow <spa...@best.com>
Subject: Re: Power off

- --==_Exmh_-1358795748P
Content-Type: text/plain; charset=us-ascii

>
> Is it possible running stable to power off x86 machines as can be done via
> ACPI on current? I like the poweroff ability (combined with wol) but I'm
> not ready to switch our servers over to 5 yet.

Try:

'shutdown -p'

Cheers,

- --==_Exmh_-1358795748P
Content-Type: application/pgp-signature

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
Comment: Exmh version 2.5 07/13/2001

iD8DBQE+NtkGPHh895bDXeQRArAnAJ4gYdBufS+GMb21KNhWoLfAqZU3UQCfR0qA
NWkA9SlY4bD0GruTA9rBs64=
=o25P
- -----END PGP SIGNATURE-----

- --==_Exmh_-1358795748P--

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

Date: Tue, 28 Jan 2003 20:37:57 +0100
From: Michael Nottebrock <michaeln...@gmx.net>
Subject: Re: Power off

Scott Sipe wrote:

> Is it possible running stable to power off x86 machines as can be done via
> ACPI on current? I like the poweroff ability (combined with wol) but I'm
> not ready to switch our servers over to 5 yet.

Yes, but you need working and enabled apm support. Check the december
2002 archives of this mailing list for a thread with the subject "Power
off problem" for further hints.

- --
Regards,
Michael Nottebrock

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

Date: Tue, 28 Jan 2003 22:13:47 +0100 (CET)
From: Marc Schneiders <ma...@schneiders.org>
Subject: Re: 4.7-R-p3: j.root-servers.net

On Tue, 28 Jan 2003, at 10:57 [=GMT-0800], Matthew Dillon wrote:

> Ok, I'm thinking then that it's better to load it as a real zone
> file. Why do it that way instead of allowing updates via a root
> server?

Because there is a feature in the DNS protocol called AXFR. It is
implemented by most if not all nameserver programs out there. It works
very well, with Bind in any case. It works automatically. It does not
cause much traffic if the zone is unchanged.

> Because in the last ten years I've had a number of problems
> with individual root servers returning bad data.

And did that cause any problems? Did your nameserver start to give out
weird answers? Or did it keep the old data?

> It doesn't happen
> very often, but it does happen.

I have never seen it, but that may not mean much. Sometimes a server
is unavailable for AXFR. Then Bind tries again a bit later. You may
the find files with weird extensions in your bind directory, like:

heist-centrum.be.db.6W6v6z
heist-centrum.be.db.vt3zUh
henkepak.com.db.2vq0pU
solidnetworks.org.db.FsG2hp
henkepak.com.db.HxO78P

All 0 bytes in size.

> I've have never had problems with
> the downloaded root.zone, and if I ever do at least I'll know that
> it's the likely cause since I only download it once a week on sunday,
> and I can review the current and prior zone files without having to
> dump named. From my point of view as an administrator that's the more
> secure approach.

Assuming:
1. That you don't forget it;
2. That you make no mistakes.

> In anycase, there are obviously many ways to keep an up-to-date root
> zone, my methodology is only one out of that list.

Naturally, but I prefer one that was invented for this purpose, AXFR,
and does the job without me wasting time. Once every few months I
clean up those empty temporary files of failed AXFRs. But that isn't
even necessary.

- --
[08] We appreciate positive feedback.
http://logoff.org/

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

Date: Tue, 28 Jan 2003 17:02:45 -0600
From: Bob Willcox <b...@immure.com>
Subject: Re: Problem with rcp -r

I am seeing this same problem (except for the protocol error) on my
4.7-stable systems. Is recursive rcp really broken in -stable, or am I
halucinating here?

Note that on my -current and old 3.5 systems rcp -r is working as
expected. Here's what I get:

bob@luke:pc /tmp> mkdir x
bob@luke:pc /tmp> touch x/{a,b,c,d}
bob@luke:pc /tmp> rcp -r x rancor:/tmp
rcp: /tmp/x/a/b: Not a directory
rcp: /tmp/x/a/b/c: Not a directory
rcp: /tmp/x/a/b/c/d: Not a directory

and on the target system we have just:

bob@rancor:p7 /tmp> ls -l x
total 0
- -rw-r--r-- 1 bob wheel 0 Jan 28 17:00 a

I have tried this same test on three of my relatively recent -stable
systems here with identical results.

Bob

On Sat, Nov 02, 2002 at 12:04:32PM -0500, Robert Ames wrote:
> In 4.7-RELEASE there seems to be a problem when using the -r option
> with rcp. For example, doing rcp between two 4.7-RELEASE machines:
>
> # rcp -rp /etc testbox:/tmp
> rcp: /tmp/etc/defaults/rc.conf/make.conf: Not a directory
> rcp: /tmp/etc/defaults/rc.conf/make.conf/pccard.conf: Not a directory
> rcp: /tmp/etc/defaults/rc.conf/make.conf/pccard.conf/periodic.conf: Not a
> directory
> rcp: /tmp/etc/defaults/rc.conf/make.conf/pccard.conf/periodic.conf: set
> times: Not a directory
> rcp:
> /tmp/etc/defaults/rc.conf/make.conf/pccard.conf/periodic.conf/services: Not
> a directory
> rcp: protocol error: expected control record
> rcp: lost connection
>
> Has this been fixed in -STABLE?
>
>
> _________________________________________________________________
> Get a speedy connection with MSN Broadband.? Join now!
> http://resourcecenter.msn.com/access/plans/freeactivation.asp
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message

- --
Bob Willcox We seem to have forgotten the simple truth that
b...@vieo.com reason is never perfect. Only non-sense attains
Austin, TX perfection. -- Poul Henningsen [1894-1967]

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

Date: Wed, 29 Jan 2003 10:17:21 +1100
From: Gregory Bond <g...@itga.com.au>
Subject: Re: Problem with rcp -r

> bob@luke:pc /tmp> rcp -r x rancor:/tmp
> rcp: /tmp/x/a/b: Not a directory
> rcp: /tmp/x/a/b/c: Not a directory
> rcp: /tmp/x/a/b/c/d: Not a directory

I see the same thing when rcp'ing from Solaris to FreeBSD, but the converse
(FreeBSD to Solaris) works as expected.

Solaris 2.6 (I know, but the bloody application vendor is slow) and FreeBSD
4-Stable as of about Nov 8.

Looks like a problem with the -Stable rcp server mode.

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

Date: Wed, 29 Jan 2003 03:25:34 +0100
From: "Ivan Voras" <ivo...@fer.hr>
Subject: strange data

For some time (6 months?), a FreeBSD-STABLE server outputs huge amounts of
data to the console & dmesg buffer. A random excerpt looks like:

100 jail RW Node
100 set_hostname_allowed RW *Handler Int
101 socket_unixiproute_only RW *Handler Int
102 sysvipc_allowed RW *Handler Int
101 compat RW Node
100 linux RW Node
100 osname RW *Handler String
101 osrelease RW *Handler String
102 oss_version RW *Handler Int
0 sysctl RW Node
0 debug R *Handler String
1 name R *Handler Node
2 next R *Handler Node
3 name2oid RW *Handler
4 oidfmt R *Handler Node
1 kern RW Node
1 ostype R *Handler String
2 osrelease R *Handler String
3 osrevision R *Handler Int
4 version R *Handler String
5 maxvnodes RW *Handler Int
6 maxproc R *Handler Int
7 maxfiles RW *Handler Int

To me, this looks like it may have some connection with sysctls.

Everything is fine, except for the ugly printout that effectively erases
everything else printed during boot, so I don't really know when or why it
is triggered. What is this and how can I disable it?

- --
ivoras

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

Date: Tue, 28 Jan 2003 23:58:17 -0500
From: "Andrew Lankford" <arla...@141.com>
Subject: This looks like a bug to me....

In the vicinity of line 405 of /usr/src/usr.bin/find/function.c
( in f_delete() ) we have the following:

/* Potentially unsafe - do not accept relative paths whatsoever */
if (strchr(entry->fts_accpath, '/') != NULL)
errx(1, "-delete: %s: relative path potentially not safe",
entry->fts_accpath);

Shouldn't the NULL really be entry->fts_accpath instead?

Andrew Lankford

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

Date: Tue, 28 Jan 2003 21:08:22 -0800 (PST)
From: Doug Barton <Do...@FreeBSD.org>
Subject: BIND 8.3.4 imported

Howdy. This is just an FYI. The actual code that's different is very small
(only one line), which is why I haven't rushed to do the update yet. It's
also the reason for the rapid MFC of this change; and the reason that at
this time I'm not planning to MFC it further down the tree. Those who
really need to see the number 8.3.4 in the logs can use the port.

Doug

- --

If it's moving, encrypt it. If it's not moving, encrypt
it till it moves, then encrypt it some more.

- ---------- Forwarded message ----------
From: Doug Barton <do...@FreeBSD.org>
To: cvs-com...@FreeBSD.org, cvs...@FreeBSD.org
Date: Tue, 28 Jan 2003 18:52:22 -0800 (PST)
Subject: cvs commit: src/contrib/bind CHANGES README Version
src/contrib/bind/bin/named db_defs.h db_sec.c ns_defs.h ns_ncache.c
ns_req.c ns_resp.c src/contrib/bind/doc/html logging.html
options.html src/contrib/bind/doc/man named.conf.5 ...

dougb 2003/01/28 18:52:22 PST

Modified files: (Branch: RELENG_4)
contrib/bind CHANGES README Version
contrib/bind/bin/named db_defs.h db_sec.c ns_defs.h
ns_ncache.c ns_req.c ns_resp.c
contrib/bind/doc/html logging.html options.html
contrib/bind/doc/man named.conf.5 resolver.3
contrib/bind/lib/nameser ns_name.c ns_samedomain.c
Log:
MFC of version 8.3.4 import

Revision Changes Path
1.1.1.7.2.9 +3 -3 src/contrib/bind/CHANGES
1.1.1.7.2.7 +3 -0 src/contrib/bind/README
1.1.1.3.2.8 +1 -1 src/contrib/bind/Version
1.1.1.2.2.7 +1 -1 src/contrib/bind/bin/named/db_defs.h
1.1.1.1.4.5 +1 -1 src/contrib/bind/bin/named/db_sec.c
1.1.1.3.2.8 +1 -1 src/contrib/bind/bin/named/ns_defs.h
1.1.1.2.2.4 +1 -1 src/contrib/bind/bin/named/ns_ncache.c
1.1.1.2.2.12 +1 -1 src/contrib/bind/bin/named/ns_req.c
1.1.1.2.2.9 +1 -1 src/contrib/bind/bin/named/ns_resp.c
1.1.1.3.2.2 +5 -1 src/contrib/bind/doc/html/logging.html
1.1.1.3.2.5 +4 -4 src/contrib/bind/doc/html/options.html
1.1.1.1.4.5 +10 -5 src/contrib/bind/doc/man/named.conf.5
1.1.1.2.2.5 +3 -1 src/contrib/bind/doc/man/resolver.3
1.1.1.2.2.5 +1 -1 src/contrib/bind/lib/nameser/ns_name.c
1.1.1.1.4.2 +2 -2 src/contrib/bind/lib/nameser/ns_samedomain.c

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

Date: Wed, 29 Jan 2003 13:11:10 +0700
From: Eugene Grosbein <eu...@kuzbass.ru>
Subject: Re: Power off

Scott Sipe wrote:
>
> Is it possible running stable to power off x86 machines as can be done via
> ACPI on current? I like the poweroff ability (combined with wol) but I'm
> not ready to switch our servers over to 5 yet.

Power down works on 4.x via APM. Make sure you have a line 'device apm0'
in your kernel config and there is no 'disable' in this line.
Make sure you have 'apm_enable="YES"' in /etc/rc.conf
Use shutdown -p now to turn power down.

Eugene Grosbein

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

Date: Wed, 29 Jan 2003 01:25:56 -0800 (PST)
From: Doug Barton <Do...@FreeBSD.org>
Subject: ipfw/natd problem with tonight's releng_4

I'm not ready to push the big red button yet, but I definitely had a
problem with natd tonight on my -stable firewall box. I've had ipfw and
natd running on this box for years... so I'm sure it's not my
configuration. My last set of sources was from november 10. I did recently
change from having ipfw in the kernel config to loading it in a module
(since I'm currently experimenting with ipfilter too). However, the nov.
10 sources worked fine with ipfw loaded as a module. I had to twiddle
/sys/modules/ipfw/Makefile first to add the divert stuff, etc:

more /sys/modules/ipfw/Makefile
# $FreeBSD: src/sys/modules/ipfw/Makefile,v 1.11 1999/08/28 00:47:21 peter
Exp $

.PATH: ${.CURDIR}/../../netinet
KMOD= ipfw
SRCS= ip_fw.c
NOMAN=
CFLAGS+= -DIPFIREWALL
#
#If you want it verbose
CFLAGS+= -DIPFIREWALL_VERBOSE
CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=10000
#
#If you want it to pass all packets by default
CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT -DIPFIREWALL_FORWARD -DIPDIVERT
#

.include <bsd.kmod.mk>

I'm sure that this is ok, since when I kldload this module, I get the
following:

/kernel: IP packet filtering initialized, divert enabled, rule-based
forwarding enabled, default to accept, logging limited to 10000
packets/entry by default

All of my other rules work, and natd starts without errors. However, as
soon as I load the natd rule in ipfw, no packets can leave the box.

The good news is that ipnat works just fine, so at least I'm functional.
But I thought that the ipfw folks would want to know about this....
hopefully one of the recent updates to ipfw will suggest itself as a
candidate for this problem.

Doug

- --

If it's moving, encrypt it. If it's not moving, encrypt
it till it moves, then encrypt it some more.

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

Date: Wed, 29 Jan 2003 20:39:58 +1100
From: Peter Jeremy <peter...@optushome.com.au>
Subject: TCP oddities in -STABLE

I've been seeing occasional unexpected pauses in output across my home
LAN eg 'sh -x some_script' will pause for a second at apparently
random intervals. Looking at tcpdump output shows a couple of oddities
that I'm hoping someone can explain.

Background: The client is an old Pentium laptop running 4.6 from
mid-July, using a 3Com Etherlink III 3C589 NIC (10baseT). The server
is an Athlon XP running -stable from last Sunday, using a RealTek 8139
NIC (100baseTX FD). They are connected using a cheap-and-very-nasty
switch. 'netstat -m' on the client shows no problems and there are no
kernel messages suggesting a resource problem.

The following tcpdump primarily shows packets (and timing) on the
client (laptop), I've pruned the options information and cut the
timestamp down to seconds to try and minimise the size of this e-mail.
I've also merged in transmitted packets that never arrived (refer to
previous comments on the switch I'm using) - these have a blank
timestamp. Full dumps available on request.

My questions are:
1) Why doesn't the laptop write any ack packets back to the server
between 11.238341 and 11.243160, or between 11.244625 and
11.261048? The ack packets do get transmitted but much later than I
would expect. Is this a funny in the ep(4) driver?
2) Is it reasonable for the server to continue sending so many packets
in the absence of any acks? (On reflection, I presume this is ssh
disabling Nagle - the packets have tos 0x10).
3) The dump includes a packet 12880:12960(80) at 11.242797 but the
ack's include a large number of repeat acks for this packet
(11.278380 through 11.280344), implying this packet never arrived.
Since it did get to bpf, why didn't the TCP stack see it? (The
same thing seems to have happened to 15856:15904(48) at 11.249113).
4) Shouldn't the RTT calculations have triggered faster re-transmits
between 11.286337 and 13.684779? Either with the client realizing
it needs to quickly double-ack 17488 to force a re-transmit, or the
server working out that if it got the ack 17488 within 1msec of
re-sending 15856:17304(1448) [this time comes from the server
trace, it can't be seen below] then it can trust that this ack
represents missing data.
5) The pattern of non-received packets suggests that something is
over-running a network queue. Is it possible that the rl driver is
over-running the hardware? The switch claims 'total 128KB RAM per
device' for an 8-port switch. Even if I assume this means 'fixed
8KB ingress and egress FIFO per port', there doesn't seem to be
enough queued data (and the 802.3x flow control should have cut in).
Can anyone suggest how to track this down and eradicate it?

09.520536 laptop.4357 > server.ssh: S 400775150:400775150(0) win 57344
09.520834 server.ssh > laptop.4357: S 1252883695:1252883695(0) ack 400775151 win 57344
09.521062 laptop.4357 > server.ssh: . ack 1 win 57920
[deleted]
11.238341 server.ssh > laptop.4357: P 10080:10160(80) ack 2456 win 57920
11.238423 server.ssh > laptop.4357: P 10160:10208(48) ack 2456 win 57920
11.238502 server.ssh > laptop.4357: P 10208:10256(48) ack 2456 win 57920
11.238580 server.ssh > laptop.4357: P 10256:10304(48) ack 2456 win 57920
11.238680 server.ssh > laptop.4357: P 10304:10384(80) ack 2456 win 57920
11.238759 server.ssh > laptop.4357: P 10384:10432(48) ack 2456 win 57920
11.238838 server.ssh > laptop.4357: P 10432:10480(48) ack 2456 win 57920
11.238921 server.ssh > laptop.4357: P 10480:10528(48) ack 2456 win 57920
11.239024 server.ssh > laptop.4357: P 10528:10608(80) ack 2456 win 57920
11.239107 server.ssh > laptop.4357: P 10608:10656(48) ack 2456 win 57920
11.239187 server.ssh > laptop.4357: P 10656:10704(48) ack 2456 win 57920
11.239267 server.ssh > laptop.4357: P 10704:10752(48) ack 2456 win 57920
11.239350 server.ssh > laptop.4357: P 10752:10800(48) ack 2456 win 57920
11.239430 server.ssh > laptop.4357: P 10800:10848(48) ack 2456 win 57920
11.239510 server.ssh > laptop.4357: P 10848:10896(48) ack 2456 win 57920
11.239613 server.ssh > laptop.4357: P 10896:10976(80) ack 2456 win 57920
11.239696 server.ssh > laptop.4357: P 10976:11024(48) ack 2456 win 57920
11.239784 server.ssh > laptop.4357: P 11024:11072(48) ack 2456 win 57920
11.239869 server.ssh > laptop.4357: P 11072:11120(48) ack 2456 win 57920
11.239982 server.ssh > laptop.4357: P 11120:11216(96) ack 2456 win 57920
11.240068 server.ssh > laptop.4357: P 11216:11264(48) ack 2456 win 57920
11.240152 server.ssh > laptop.4357: P 11264:11312(48) ack 2456 win 57920
11.240238 server.ssh > laptop.4357: P 11312:11360(48) ack 2456 win 57920
11.240350 server.ssh > laptop.4357: P 11360:11456(96) ack 2456 win 57920
11.240435 server.ssh > laptop.4357: P 11456:11504(48) ack 2456 win 57920
11.240520 server.ssh > laptop.4357: P 11504:11552(48) ack 2456 win 57920
11.240605 server.ssh > laptop.4357: P 11552:11600(48) ack 2456 win 57920
11.240718 server.ssh > laptop.4357: P 11600:11696(96) ack 2456 win 57920
11.240804 server.ssh > laptop.4357: P 11696:11744(48) ack 2456 win 57920
11.240890 server.ssh > laptop.4357: P 11744:11792(48) ack 2456 win 57920
11.240976 server.ssh > laptop.4357: P 11792:11840(48) ack 2456 win 57920
11.241101 server.ssh > laptop.4357: P 11840:11920(80) ack 2456 win 57920
11.241186 server.ssh > laptop.4357: P 11920:11968(48) ack 2456 win 57920
11.241272 server.ssh > laptop.4357: P 11968:12016(48) ack 2456 win 57920
11.241358 server.ssh > laptop.4357: P 12016:12064(48) ack 2456 win 57920
11.241442 server.ssh > laptop.4357: P 12064:12112(48) ack 2456 win 57920
11.241528 server.ssh > laptop.4357: P 12112:12160(48) ack 2456 win 57920
11.241614 server.ssh > laptop.4357: P 12160:12208(48) ack 2456 win 57920
11.241719 server.ssh > laptop.4357: P 12208:12288(80) ack 2456 win 57920
11.241803 server.ssh > laptop.4357: P 12288:12336(48) ack 2456 win 57920
11.241889 server.ssh > laptop.4357: P 12336:12384(48) ack 2456 win 57920
11.241974 server.ssh > laptop.4357: P 12384:12432(48) ack 2456 win 57920
11.242078 server.ssh > laptop.4357: P 12432:12512(80) ack 2456 win 57920
11.242164 server.ssh > laptop.4357: P 12512:12560(48) ack 2456 win 57920
11.242248 server.ssh > laptop.4357: P 12560:12608(48) ack 2456 win 57920
11.242334 server.ssh > laptop.4357: P 12608:12656(48) ack 2456 win 57920
11.242439 server.ssh > laptop.4357: P 12656:12736(80) ack 2456 win 57920
11.242524 server.ssh > laptop.4357: P 12736:12784(48) ack 2456 win 57920
11.242608 server.ssh > laptop.4357: P 12784:12832(48) ack 2456 win 57920
11.242693 server.ssh > laptop.4357: P 12832:12880(48) ack 2456 win 57920
11.242797 server.ssh > laptop.4357: P 12880:12960(80) ack 2456 win 57920
11.242879 server.ssh > laptop.4357: P 12960:13008(48) ack 2456 win 57920
11.242958 server.ssh > laptop.4357: P 13008:13056(48) ack 2456 win 57920
11.243037 server.ssh > laptop.4357: P 13056:13104(48) ack 2456 win 57920
11.243160 laptop.4357 > server.ssh: . ack 10160 win 52960
11.243263 laptop.4357 > server.ssh: . ack 10256 win 52864
11.243362 laptop.4357 > server.ssh: . ack 10384 win 52736
11.243464 laptop.4357 > server.ssh: . ack 10480 win 52640
11.244625 server.ssh > laptop.4357: P 13104:13184(80) ack 2456 win 57920
11.244710 server.ssh > laptop.4357: P 13184:13232(48) ack 2456 win 57920
11.244791 server.ssh > laptop.4357: P 13232:13280(48) ack 2456 win 57920
11.244876 server.ssh > laptop.4357: P 13280:13328(48) ack 2456 win 57920
11.244957 server.ssh > laptop.4357: P 13328:13376(48) ack 2456 win 57920
11.245037 server.ssh > laptop.4357: P 13376:13424(48) ack 2456 win 57920
11.245120 server.ssh > laptop.4357: P 13424:13472(48) ack 2456 win 57920
11.245223 server.ssh > laptop.4357: P 13472:13552(80) ack 2456 win 57920
11.245308 server.ssh > laptop.4357: P 13552:13600(48) ack 2456 win 57920
11.245393 server.ssh > laptop.4357: P 13600:13648(48) ack 2456 win 57920
11.245478 server.ssh > laptop.4357: P 13648:13696(48) ack 2456 win 57920
11.245582 server.ssh > laptop.4357: P 13696:13776(80) ack 2456 win 57920
11.245667 server.ssh > laptop.4357: P 13776:13824(48) ack 2456 win 57920
11.245752 server.ssh > laptop.4357: P 13824:13872(48) ack 2456 win 57920
11.245839 server.ssh > laptop.4357: P 13872:13920(48) ack 2456 win 57920
11.245943 server.ssh > laptop.4357: P 13920:14000(80) ack 2456 win 57920
11.246028 server.ssh > laptop.4357: P 14000:14048(48) ack 2456 win 57920
11.246114 server.ssh > laptop.4357: P 14048:14096(48) ack 2456 win 57920
11.246198 server.ssh > laptop.4357: P 14096:14144(48) ack 2456 win 57920
11.246304 server.ssh > laptop.4357: P 14144:14224(80) ack 2456 win 57920
11.246389 server.ssh > laptop.4357: P 14224:14272(48) ack 2456 win 57920
11.246475 server.ssh > laptop.4357: P 14272:14320(48) ack 2456 win 57920
11.246561 server.ssh > laptop.4357: P 14320:14368(48) ack 2456 win 57920
11.246665 server.ssh > laptop.4357: P 14368:14448(80) ack 2456 win 57920
11.246751 server.ssh > laptop.4357: P 14448:14496(48) ack 2456 win 57920
11.246836 server.ssh > laptop.4357: P 14496:14544(48) ack 2456 win 57920
11.246922 server.ssh > laptop.4357: P 14544:14592(48) ack 2456 win 57920
11.247031 server.ssh > laptop.4357: P 14592:14640(48) ack 2456 win 57920
11.247119 server.ssh > laptop.4357: P 14640:14688(48) ack 2456 win 57920
11.247205 server.ssh > laptop.4357: P 14688:14736(48) ack 2456 win 57920
11.247310 server.ssh > laptop.4357: P 14736:14816(80) ack 2456 win 57920
11.247395 server.ssh > laptop.4357: P 14816:14864(48) ack 2456 win 57920
11.247481 server.ssh > laptop.4357: P 14864:14912(48) ack 2456 win 57920
11.247567 server.ssh > laptop.4357: P 14912:14960(48) ack 2456 win 57920
11.247671 server.ssh > laptop.4357: P 14960:15040(80) ack 2456 win 57920
11.247756 server.ssh > laptop.4357: P 15040:15088(48) ack 2456 win 57920
11.247842 server.ssh > laptop.4357: P 15088:15136(48) ack 2456 win 57920
11.247926 server.ssh > laptop.4357: P 15136:15184(48) ack 2456 win 57920
11.248030 server.ssh > laptop.4357: P 15184:15264(80) ack 2456 win 57920
11.248116 server.ssh > laptop.4357: P 15264:15312(48) ack 2456 win 57920
11.248201 server.ssh > laptop.4357: P 15312:15360(48) ack 2456 win 57920
11.248287 server.ssh > laptop.4357: P 15360:15408(48) ack 2456 win 57920
11.248391 server.ssh > laptop.4357: P 15408:15488(80) ack 2456 win 57920
11.248476 server.ssh > laptop.4357: P 15488:15536(48) ack 2456 win 57920
11.248562 server.ssh > laptop.4357: P 15536:15584(48) ack 2456 win 57920
11.248646 server.ssh > laptop.4357: P 15584:15632(48) ack 2456 win 57920
11.248750 server.ssh > laptop.4357: P 15632:15712(80) ack 2456 win 57920
11.248836 server.ssh > laptop.4357: P 15712:15760(48) ack 2456 win 57920
11.248942 server.ssh > laptop.4357: P 15760:15808(48) ack 2456 win 57920
11.249028 server.ssh > laptop.4357: P 15808:15856(48) ack 2456 win 57920
11.249113 server.ssh > laptop.4357: P 15856:15904(48) ack 2456 win 57920
11.249194 server.ssh > laptop.4357: P 15904:15952(48) ack 2456 win 57920
11.249274 server.ssh > laptop.4357: P 15952:16000(48) ack 2456 win 57920
11.249371 server.ssh > laptop.4357: P 16000:16080(80) ack 2456 win 57920
11.249450 server.ssh > laptop.4357: P 16080:16128(48) ack 2456 win 57920
11.249530 server.ssh > laptop.4357: P 16128:16176(48) ack 2456 win 57920
11.251209 server.ssh > laptop.4357: P 16176:16224(48) ack 2456 win 57920
11.251316 server.ssh > laptop.4357: P 16224:16304(80) ack 2456 win 57920
11.251402 server.ssh > laptop.4357: P 16304:16352(48) ack 2456 win 57920
11.251487 server.ssh > laptop.4357: P 16352:16400(48) ack 2456 win 57920
11.251574 server.ssh > laptop.4357: P 16400:16448(48) ack 2456 win 57920
11.251678 server.ssh > laptop.4357: P 16448:16528(80) ack 2456 win 57920
11.251765 server.ssh > laptop.4357: P 16528:16576(48) ack 2456 win 57920
11.251850 server.ssh > laptop.4357: P 16576:16624(48) ack 2456 win 57920
11.251935 server.ssh > laptop.4357: P 16624:16672(48) ack 2456 win 57920
11.252038 server.ssh > laptop.4357: P 16672:16752(80) ack 2456 win 57920
11.252123 server.ssh > laptop.4357: P 16752:16800(48) ack 2456 win 57920
11.252209 server.ssh > laptop.4357: P 16800:16848(48) ack 2456 win 57920
11.252294 server.ssh > laptop.4357: P 16848:16896(48) ack 2456 win 57920
11.252399 server.ssh > laptop.4357: P 16896:16976(80) ack 2456 win 57920
11.252484 server.ssh > laptop.4357: P 16976:17024(48) ack 2456 win 57920
11.252569 server.ssh > laptop.4357: P 17024:17072(48) ack 2456 win 57920
11.252656 server.ssh > laptop.4357: P 17072:17120(48) ack 2456 win 57920
11.252741 server.ssh > laptop.4357: P 17120:17168(48) ack 2456 win 57920
11.252827 server.ssh > laptop.4357: P 17168:17216(48) ack 2456 win 57920
11.252911 server.ssh > laptop.4357: P 17216:17264(48) ack 2456 win 57920
11.253015 server.ssh > laptop.4357: P 17264:17344(80) ack 2456 win 57920
11.253102 server.ssh > laptop.4357: P 17344:17392(48) ack 2456 win 57920
11.253186 server.ssh > laptop.4357: P 17392:17440(48) ack 2456 win 57920
11.253272 server.ssh > laptop.4357: P 17440:17488(48) ack 2456 win 57920
server.ssh > laptop.4357: P 17488:17568(80) ack 2456 win 57920
11.253357 server.ssh > laptop.4357: P 17568:17616(48) ack 2456 win 57920
11.253443 server.ssh > laptop.4357: P 17616:17664(48) ack 2456 win 57920
11.253530 server.ssh > laptop.4357: P 17664:17712(48) ack 2456 win 57920
server.ssh > laptop.4357: P 17712:17792(80) ack 2456 win 57920
11.253615 server.ssh > laptop.4357: P 17792:17840(48) ack 2456 win 57920
11.253700 server.ssh > laptop.4357: P 17840:17888(48) ack 2456 win 57920
server.ssh > laptop.4357: P 17888:17936(48) ack 2456 win 57920
11.253803 server.ssh > laptop.4357: P 17936:18016(80) ack 2456 win 57920
server.ssh > laptop.4357: P 18016:18064(48) ack 2456 win 57920
11.253888 server.ssh > laptop.4357: P 18064:18112(48) ack 2456 win 57920
11.253974 server.ssh > laptop.4357: P 18112:18160(48) ack 2456 win 57920
server.ssh > laptop.4357: P 18160:18240(80) ack 2456 win 57920
11.254060 server.ssh > laptop.4357: P 18240:18288(48) ack 2456 win 57920
server.ssh > laptop.4357: P 18288:18336(48) ack 2456 win 57920
11.254146 server.ssh > laptop.4357: P 18336:18384(48) ack 2456 win 57920
11.254231 server.ssh > laptop.4357: P 18384:18432(48) ack 2456 win 57920
11.254317 server.ssh > laptop.4357: P 18432:18480(48) ack 2456 win 57920
11.254401 server.ssh > laptop.4357: P 18480:18528(48) ack 2456 win 57920
server.ssh > laptop.4357: P 18528:18608(80) ack 2456 win 57920
11.254488 server.ssh > laptop.4357: P 18608:18656(48) ack 2456 win 57920
11.254572 server.ssh > laptop.4357: P 18656:18704(48) ack 2456 win 57920
11.254658 server.ssh > laptop.4357: P 18704:18752(48) ack 2456 win 57920
server.ssh > laptop.4357: P 18752:18832(80) ack 2456 win 57920
11.254744 server.ssh > laptop.4357: P 18832:18880(48) ack 2456 win 57920
11.254829 server.ssh > laptop.4357: P 18880:18928(48) ack 2456 win 57920
11.254913 server.ssh > laptop.4357: P 18928:18976(48) ack 2456 win 57920
server.ssh > laptop.4357: P 18976:19056(80) ack 2456 win 57920
11.254998 server.ssh > laptop.4357: P 19056:19104(48) ack 2456 win 57920
11.255084 server.ssh > laptop.4357: P 19104:19152(48) ack 2456 win 57920
11.255177 server.ssh > laptop.4357: P 19152:19200(48) ack 2456 win 57920
server.ssh > laptop.4357: P 19200:19280(80) ack 2456 win 57920
11.255262 server.ssh > laptop.4357: P 19280:19328(48) ack 2456 win 57920
11.255348 server.ssh > laptop.4357: P 19328:19376(48) ack 2456 win 57920
server.ssh > laptop.4357: P 19376:19424(48) ack 2456 win 57920
server.ssh > laptop.4357: P 19424:19504(80) ack 2456 win 57920
11.255434 server.ssh > laptop.4357: P 19504:19552(48) ack 2456 win 57920
11.255519 server.ssh > laptop.4357: P 19552:19600(48) ack 2456 win 57920
11.255606 server.ssh > laptop.4357: P 19600:19648(48) ack 2456 win 57920
11.255687 server.ssh > laptop.4357: P 19648:19696(48) ack 2456 win 57920
11.255767 server.ssh > laptop.4357: P 19696:19744(48) ack 2456 win 57920
11.255846 server.ssh > laptop.4357: P 19744:19792(48) ack 2456 win 57920
server.ssh > laptop.4357: P 19792:19872(80) ack 2456 win 57920
11.255925 server.ssh > laptop.4357: P 19872:19920(48) ack 2456 win 57920
11.256005 server.ssh > laptop.4357: P 19920:19968(48) ack 2456 win 57920
server.ssh > laptop.4357: P 19968:20016(48) ack 2456 win 57920
11.256103 server.ssh > laptop.4357: P 20016:20096(80) ack 2456 win 57920
server.ssh > laptop.4357: P 20096:20144(48) ack 2456 win 57920
11.256181 server.ssh > laptop.4357: P 20144:20192(48) ack 2456 win 57920
server.ssh > laptop.4357: P 20192:20240(48) ack 2456 win 57920
server.ssh > laptop.4357: P 20240:20320(80) ack 2456 win 57920
11.256261 server.ssh > laptop.4357: P 20320:20368(48) ack 2456 win 57920
11.260188 server.ssh > laptop.4357: P 20368:21712(1344) ack 2456 win 57920
11.260953 server.ssh > laptop.4357: P 21712:22912(1200) ack 2456 win 57920
11.261048 server.ssh > laptop.4357: P 22912:22976(64) ack 2456 win 57920
11.276885 laptop.4357 > server.ssh: . ack 10608 win 52512
11.276969 laptop.4357 > server.ssh: . ack 10704 win 52416
11.277019 laptop.4357 > server.ssh: . ack 10800 win 52320
11.277070 laptop.4357 > server.ssh: . ack 10896 win 52224
11.277134 laptop.4357 > server.ssh: . ack 11024 win 52096
11.277219 laptop.4357 > server.ssh: . ack 11120 win 52000
11.277271 laptop.4357 > server.ssh: . ack 11264 win 51856
11.277371 laptop.4357 > server.ssh: . ack 11360 win 51760
11.277422 laptop.4357 > server.ssh: . ack 11504 win 51616
11.277517 laptop.4357 > server.ssh: . ack 11600 win 51520
11.277567 laptop.4357 > server.ssh: . ack 11744 win 51376
11.277654 laptop.4357 > server.ssh: . ack 11840 win 51280
11.277717 laptop.4357 > server.ssh: . ack 11968 win 51152
11.277799 laptop.4357 > server.ssh: . ack 12064 win 51056
11.277862 laptop.4357 > server.ssh: . ack 12160 win 50960
11.277944 laptop.4357 > server.ssh: . ack 12288 win 50832
11.278007 laptop.4357 > server.ssh: . ack 12384 win 50736
11.278096 laptop.4357 > server.ssh: . ack 12512 win 50608
11.278147 laptop.4357 > server.ssh: . ack 12608 win 50512
11.278244 laptop.4357 > server.ssh: . ack 12736 win 50384
11.278295 laptop.4357 > server.ssh: . ack 12832 win 50288
11.278380 laptop.4357 > server.ssh: . ack 12880 win 50240
11.278444 laptop.4357 > server.ssh: . ack 12880 win 50240
11.278526 laptop.4357 > server.ssh: . ack 12880 win 50240
11.278589 laptop.4357 > server.ssh: . ack 12880 win 50240
11.278671 laptop.4357 > server.ssh: . ack 12880 win 50240
11.278735 laptop.4357 > server.ssh: . ack 12880 win 50240
11.278818 laptop.4357 > server.ssh: . ack 12880 win 50240
11.278878 laptop.4357 > server.ssh: . ack 12880 win 50240
11.278962 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279026 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279108 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279171 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279253 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279316 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279404 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279454 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279597 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279649 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279699 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279750 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279834 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279898 laptop.4357 > server.ssh: . ack 12880 win 50240
11.279980 laptop.4357 > server.ssh: . ack 12880 win 50240
11.280041 laptop.4357 > server.ssh: . ack 12880 win 50240
11.280126 laptop.4357 > server.ssh: . ack 12880 win 50240
11.280197 laptop.4357 > server.ssh: . ack 12880 win 50240
11.280261 laptop.4357 > server.ssh: . ack 12880 win 50240
11.280344 laptop.4357 > server.ssh: . ack 12880 win 50240
11.283107 server.ssh > laptop.4357: . 12880:14328(1448) ack 2456 win 57920
11.283529 laptop.4357 > server.ssh: . ack 15856 win 54944
11.283872 laptop.4357 > server.ssh: . ack 15856 win 57920
11.286098 server.ssh > laptop.4357: . 15856:17304(1448) ack 2456 win 57920
11.286337 laptop.4357 > server.ssh: . ack 17488 win 56288
12.247106 laptop.4357 > server.ssh: . ack 17488 win 57920
12.484824 server.ssh > laptop.4357: . 17488:18936(1448) ack 2456 win 57920
12.485107 laptop.4357 > server.ssh: . ack 18976 win 56432
13.684779 server.ssh > laptop.4357: . 18976:20424(1448) ack 2456 win 57920
13.685086 laptop.4357 > server.ssh: . ack 22976 win 53920
13.685439 laptop.4357 > server.ssh: . ack 22976 win 57920
13.702095 laptop.4357 > server.ssh: P 2456:2504(48) ack 22976 win 57920
13.702625 server.ssh > laptop.4357: P 22976:23072(96) ack 2504 win 57920
13.716726 laptop.4357 > server.ssh: P 2504:2696(192) ack 23072 win 57920
13.717478 server.ssh > laptop.4357: P 23072:23184(112) ack 2696 win 57920
[deleted]

Peter

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

Date: 29 Jan 2003 15:42:33 +0100
From: pe...@bgnett.no (Peter N. M. Hansteen)
Subject: bizarre ep (3c509-Combo) behavior: one and a half init, minimal throughput

After a confusing sequence of events concerning power spikes which killed
my home gateway, some shuffling of network cards was needed.

An underused machine which for the usual reasons (SWMBO and daughter
insistence) dual boots FreeBSD 5.0-RELEASE and Win98se ended up with a
3c509-Combo card (ISA) which *almost* works. That is, after booting
into win98's 'dos mode' I was able to run the config program and set
the card to not grab IRQ11 for itself, and after a few attempts the
card at least works somewhat in win98.

However, the card does some strange things when I boot FreeBSD.
dmesg follows:

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Thu Jan 16 22:16:53 GMT 2003
ro...@hollin.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0673000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06730a8.
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 499034803 Hz
CPU: AMD-K7(tm) Processor (499.03-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x612 Stepping = 2
Features=0x81f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX>
AMD Features=0xffffffffc0400000<AMIE,DSP,3DNow!>
real memory = 134152192 (127 MB)
avail memory = 123383808 (117 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
npx0: <math processor> on motherboard
npx0: INT 16 interface
acpi0: <AWARD AWRDACPI> on motherboard
ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
acpi0: power button is handled as a fixed feature programming model.
acpi0: sleep button is handled as a fixed feature programming model.
Timecounter "ACPI-fast" frequency 3579545 Hz
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0
acpi_cpu0: <CPU> on acpi0
acpi_tz0: <thermal zone> on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0x5080-0x50ff,0x5000-0x507f,0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <AMD 751 host to AGP bridge> port 0xe000-0xe003 mem 0xe0000000-0xe0000fff,0xd8000000-0xdbffffff at device 0.0 on pci0
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci1: <display, VGA> at device 5.0 (no driver attached)
isab0: <PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <AMD 756 ATA66 controller> port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: <bridge, PCI-unknown> at device 7.3 (no driver attached)
ohci0: <AMD-756 USB Controller> mem 0xe0001000-0xe0001fff irq 3 at device 7.4 on pci0
usb0: OHCI version 1.0, legacy support
usb0: <AMD-756 USB Controller> on ohci0
usb0: USB revision 1.0
uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 4 ports with 4 removable, self powered
pci0: <network> at device 9.0 (no driver attached)
pci0: <multimedia, audio> at device 10.0 (no driver attached)
fdc0: <Enhanced floppy controller (i82077, NE72065 or clone)> port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0 port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
atkbdc0: <Keyboard controller (i8042)> port 0x64,0x60 irq 1 on acpi0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
orm0: <Option ROM> at iomem 0xc0000-0xcffff on isa0
pmtimer0 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ep0: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0
ep0: Ethernet address 00:a0:24:ca:7c:b0
Timecounters tick every 10.000 msec
acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0%
ad0: 25941MB <WDC WD272AA> [52707/16/63] at ata0-master UDMA66
ad1: 38166MB <WDC WD400BB-00DEA0> [77545/16/63] at ata0-slave UDMA66
ata1-master: timeout waiting for cmd=ef s=00 e=00
acd0: CDROM <CREATIVE CD-RW RW4424E> at ata1-master BIOSPIO
acd1: DVD-ROM <LG DVD-ROM DRD-8160B> at ata1-slave PIO4
Mounting root from ufs:/dev/ad1s1a
module_register: module pccard/ep already exists!
Module pccard/ep failed to register: 17
module_register: module isa/ep already exists!
Module isa/ep failed to register: 17
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
ep1: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0
ep1: No I/O space?!
ep1: ep_alloc() failed! (6)
device_probe_and_attach: ep1 attach returned 6
acpi_tz0: WARNING - current temperature (39.0C) exceeds system limits

Note that the card is recognized first as

ep0: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0
ep0: Ethernet address 00:a0:24:ca:7c:b0

then once more as

ep1: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0
ep1: No I/O space?!
ep1: ep_alloc() failed! (6)

There is only one network card in the machine, I promise!

The network card at ep0 is then initialized normally, but the network
response is extremely slow, taking literally minutes to scp a small file
like the dmesg above to another machine across a 10Mbit ethernet.

The card performed reasonably as the inner interface on the (now
deceased) gateway running Debian, and the machine and cables in
question performed just fine with another 3com card (the xl
persuation) which was needed more urgently elsewhere and various
FreeBSD releases plus win98 when necessary.

I'm unsure if the real problem is that this card needs some not very
widely known special pampering or if it is more likely that the card
was actually damaged by the power irregularity even if the diagnostic
programs from 3com do not turn up anything.

Any advice on how to proceed would be much appreciated, although
swapping the card for another one (preferably some PCI card or other)
would perhaps be a saner option than fighting with ISA cards these
days.

- - P
- --
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/

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

Date: Wed, 29 Jan 2003 09:15:04 -0600 (CST)
From: "J.F. Noonan" <j...@msc.com>
Subject: when make installkernel doesn't

Hi,

Yesterday I cvsup'd to -stable on an machine that had been running
4.5-stable (with 247 days of uptime). I started a make buildworld
and a make buildkernel KERNCONF=MYKERNELNAME and went home.

This morning, I dropped to single-user and did a make installworld
followed by a make installkernel KERNCONF=MYKERNELNAME. I did a
mergemaster, sync,sync,reboot. When the system came back up, I
did a netstat -a to be sure that my network services were all
running before leaving the machine room to go to my desk.

Huh, that's weird, nothing running but syslog. tail -f
/var/log/maillog and see mail is going out and in. uh, ok. ps
ax|grep sendmail. ps: proc size mismatch (41184 total, 1060
chunks). OK, that means libkvm is out of sync so I go make that
and remake ps. Same thing happens.

Hrrm, uname -a: 4.5-STABLE FreeBSD 4.5-STABLE #1: Fri Mar 22
17:55:41 CSt 2002. Well that's not the kernel I installed and
that isn't yesterday's date. date: Wed Jan 29 09:09:38 CST 2003
- -- Clock's OK (better be or ntp is broken).

Alright, surely something must have gone wrong with that
installkernel let's just do another buildkernel and installkernel.
Build goes w/o incident, drop to single and install. Reboot, same
kernel.

I have done this 100 times if I have done this once and I have
never seen a kernel refuse to install. Can anybody point out what
is wrong?

Thanks,

- --

Joseph F. Noonan
Rigaku/MSC Inc.
j...@msc.com

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

Date: Wed, 29 Jan 2003 11:07:06 -0500
From: Chris BeHanna <ch...@pennasoft.com>
Subject: Re: when make installkernel doesn't

On Wednesday 29 January 2003 10:15, J.F. Noonan wrote:
> Hi,
>
> Yesterday I cvsup'd to -stable on an machine that had been running
> 4.5-stable (with 247 days of uptime). I started a make buildworld
> and a make buildkernel KERNCONF=3DMYKERNELNAME and went home.
>
> This morning, I dropped to single-user and did a make installworld
> followed by a make installkernel KERNCONF=3DMYKERNELNAME. I did a
> mergemaster, sync,sync,reboot. When the system came back up, I
> did a netstat -a to be sure that my network services were all
> running before leaving the machine room to go to my desk.
>
> Huh, that's weird, nothing running but syslog. tail -f
> /var/log/maillog and see mail is going out and in. uh, ok. ps
> ax|grep sendmail. ps: proc size mismatch (41184 total, 1060
> chunks). OK, that means libkvm is out of sync so I go make that
> and remake ps. Same thing happens.
>
> Hrrm, uname -a: 4.5-STABLE FreeBSD 4.5-STABLE #1: Fri Mar 22
> 17:55:41 CSt 2002. Well that's not the kernel I installed and
> that isn't yesterday's date. date: Wed Jan 29 09:09:38 CST 2003
> -- Clock's OK (better be or ntp is broken).
>
> Alright, surely something must have gone wrong with that
> installkernel let's just do another buildkernel and installkernel.
> Build goes w/o incident, drop to single and install. Reboot, same
> kernel.
>
> I have done this 100 times if I have done this once and I have
> never seen a kernel refuse to install. Can anybody point out what
> is wrong?

This is one thing:

> This morning, I dropped to single-user and did a make installworld
> followed by a make installkernel KERNCONF=3DMYKERNELNAME. I did a

You do a make installkernel *first*, *then* reboot and make sure
it at least comes back to single user.

Then and only then do you do an installworld.

You might get yourself to goodness by copying your new kernel and
new modules by hand from /usr/obj to their appropriate places.

- --=20
Chris BeHanna http://www.pennasoft.com=20
Principal Consultant =20
PennaSoft Corporation =20
ch...@pennasoft.com =20

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

Date: Wed, 29 Jan 2003 11:23:12 -0500
From: Dave Kingsley <king...@enc.edu>
Subject: disklabel not writeable

I am trying to set up vinum on a FreeBSD 5.0 system. To do so I need to
write the disk
label to set vinum as the file type for the partition I want to use.
The response to disklabel -e -r /dev/da0s3 is "disklabel: /dev/da0s3:
Operation not permitted"
The man page states that "disklabel -W /dev/da0s3" should make the
label writable, but I
get the same error message.
If I look at the label I get:

luke# disklabel -r /dev/da0s3
# /dev/da0s3:
type: SCSI
disk: da0s3
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 4462
sectors/unit: 71686144
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0

8 partitions:
# size offset fstype [fsize bsize bps/cpg]
b: 8388608 12562830 swap # (Cyl. 782 -
1304*)
c: 59119200 12562830 unused 0 0 # (Cyl. 782 - 4461)
d: 50730592 20951438 4.2BSD 2048 16384 28512 # (Cyl. 1304*-
4461*)
Warning, partition c doesn't start at 0!
Warning, partition c doesn't cover the whole unit!
Warning, An incorrect partition c may cause problems for standard system
utilities

The warnings are the same no matter what slice I look at.

Help!

- -- Dave

- --
Dave Kingsley Voice: 617-745-3806
Systems Administrator FAX: 617-745-3907
Eastern Nazarene College
23 E. Elm Avenue E-mail: king...@enc.edu
Quincy, MA 02170
***************************************************************
There are 10 types of people . . . . Those who understand binary,
And those who don't!

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

Date: Wed, 29 Jan 2003 11:21:50 -0500
From: Chuck Swiger <csw...@mac.com>
Subject: Re: TCP oddities in -STABLE

On Wednesday, January 29, 2003, at 04:39 AM, Peter Jeremy wrote:
> Background: The client is an old Pentium laptop running 4.6 from
> mid-July, using a 3Com Etherlink III 3C589 NIC (10baseT). The server
> is an Athlon XP running -stable from last Sunday, using a RealTek 8139
> NIC (100baseTX FD). They are connected using a cheap-and-very-nasty
> switch. 'netstat -m' on the client shows no problems and there are no
> kernel messages suggesting a resource problem.

Try switching the Althon box to running a 10Mbs/HD; your switch may not be
handling the different speeds very well. (Although your NICs are also
somewhat dubious in terms of quality hardware, too.)

- -Chuck

Chuck Swiger | ch...@codefab.com | All your packets are belong to
us.

- -------------+-------------------+-----------------------------------
"The human race's favorite method for being in control of the facts
is to ignore them." -Celia Green

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

Date: Wed, 29 Jan 2003 10:44:11 -0600 (CST)
From: "J.F. Noonan" <j...@msc.com>
Subject: Re: when make installkernel doesn't

> On Wednesday 29 January 2003 10:15, J.F. Noonan wrote:
> >

Hi Chris, thanks for the reply,

> This is one thing:
>
> > This morning, I dropped to single-user and did a make installworld
> > followed by a make installkernel KERNCONF=MYKERNELNAME. I did a
>
> You do a make installkernel *first*, *then* reboot and make sure
> it at least comes back to single user.

Yes, you are of course right about that, I think I made this
mistake once before a long time ago and caused a great mess. BUT,
even though I've done this stupid thing, why does "make
installworld" apparently run to completion (w/o a single peep or
complaint), but not actually DO anything? The binaries associated
with the "make kernel" are all newer than the stuff from "make
world", so this should look like I'm starting out on a new kernel
build, no?

Confusedly,

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

Date: Wed, 29 Jan 2003 17:49:24 +0100
From: Chris Pockele <chr...@belgacom.net>
Subject: Re: bizarre ep (3c509-Combo) behavior: one and a half init, minimal throughput

On Wed, Jan 29, 2003 at 03:42:33PM +0100, Peter N. M. Hansteen wrote:
>
8< 8< snip

> Note that the card is recognized first as
>
> ep0: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0
> ep0: Ethernet address 00:a0:24:ca:7c:b0
>
> then once more as
>
> ep1: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0
> ep1: No I/O space?!
> ep1: ep_alloc() failed! (6)
>
> There is only one network card in the machine, I promise!
>
It's a common issue. Run it's config program again, turn off the PnP mode
of the card and set it to known free resource values (e.g. port 0x300 irq 5).
You will probably need to do some configuring in Windows then, but FreeBSD
should now recognize and use the card well.

> The network card at ep0 is then initialized normally, but the network
> response is extremely slow, taking literally minutes to scp a small file
> like the dmesg above to another machine across a 10Mbit ethernet.
>
> The card performed reasonably as the inner interface on the (now
> deceased) gateway running Debian, and the machine and cables in
> question performed just fine with another 3com card (the xl
> persuation) which was needed more urgently elsewhere and various
> FreeBSD releases plus win98 when necessary.
>
> I'm unsure if the real problem is that this card needs some not very
> widely known special pampering or if it is more likely that the card
> was actually damaged by the power irregularity even if the diagnostic
> programs from 3com do not turn up anything.
>
> Any advice on how to proceed would be much appreciated, although
> swapping the card for another one (preferably some PCI card or other)
> would perhaps be a saner option than fighting with ISA cards these
> days.
>
> - P
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://www.blug.linux.no/rfc1149/ http://www.datadok.no/
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message

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

Date: Wed, 29 Jan 2003 11:53:22 -0600 (CST)
From: "J.F. Noonan" <j...@msc.com>
Subject: Re: when make installkernel doesn't

On Wed, 29 Jan 2003 at 10:44am J.F. Noonan wrote:

> > On Wednesday 29 January 2003 10:15, J.F. Noonan wrote:
> > >
>
> Yes, you are of course right about that, I think I made this
> mistake once before a long time ago and caused a great mess. BUT,
> even though I've done this stupid thing, why does "make
> installworld" apparently run to completion (w/o a single peep or
> complaint), but not actually DO anything? The binaries associated
> with the "make kernel" are all newer than the stuff from "make
> world", so this should look like I'm starting out on a new kernel
> build, no?

Alright, with some clever use of the 'ls' command
(ls -al /kernel* :-) I found that the installed kernel
is the one I built this AM. And strings /kernel | grep Free
yields: @(#)FreeBSD 4.7-STABLE #3: Wed Jan 29 08:39:31 CST 2003. Cool.

So my libkvm is presumably stil whacked. So I do a make clean;
make;make install in /usr/src/lib/libkvm. Then I go to
/usr/src/bin/ps and do the same series of makes. Still no go.

I am really stuck now.

Thanks,

- --

Joseph F. Noonan
Rigaku/MSC Inc.
j...@msc.com

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

Date: Wed, 29 Jan 2003 18:54:25 +0100 (CET)
From: Robert Joosten <rob...@wirehub.nl>
Subject: Re: bizarre ep (3c509-Combo) behavior: one and a half init, minimal throughput

Hi,

> ep0: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0
> ep0: Ethernet address 00:a0:24:ca:7c:b0
> then once more as
> ep1: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0
> ep1: No I/O space?!
> ep1: ep_alloc() failed! (6)
> There is only one network card in the machine, I promise!

I know these ep's, they're supported but only work so-so.

I found out you must keep the order your kernel-config lists them intact
(that's ed0, then ex, and then ep, followed by fe0) and also man keep that
fe0 following the ep device. I experimented with this (read: wasted a lot
of time) to figure out what and how.

I'm running a old '486 running 4.7R with two ep's:

Jan 29 13:01:42 t2ja /kernel: ep0: <3Com 3C509-TPO EtherLink III> at port
0x300-0x30f irq 10 on isa0
Jan 29 13:01:42 t2ja /kernel: ep0: Ethernet address 00:20:af:b8:96:8c
Jan 29 13:01:42 t2ja /kernel: ep1: <3Com 3C509-TPO EtherLink III> at port
0x310-0x31f irq 11 on isa0
Jan 29 13:01:42 t2ja /kernel: ep1: Ethernet address 00:60:08:c6:a2:77

with only some minor issues: blasting a lot of traffiq through it causes
some mbuff trouble which degardes performace to nearly zero, I always shut
the interface down, wait a few seconds and the throw it up again. As long
as the interface's not threated, performance keeps suffering lasting for
hours and maybe days...! A precursor is the appearance of OACTIVE in the
ifconfig output regarding that interface.

One sysadmin I know told me 3com released various series of these cards.
The most recent models suppose to run flawlessly under *nix. The earliest
models should be avoided. Windows doesn't care at all.

And yes: I know from 1st hand experience Linux supports these cards
very well (They did a wonderfull job on my 386xs/25 running Slackware 3.9
(kernel 2.0.37).

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

Date: Wed, 29 Jan 2003 12:03:59 -0800
From: Mahlon <mahlon-dated-10...@martini.nu>
Subject: Compaq ES40 Alpha, FreeBSD 5.0-RELEASE - install issue.

- --0vzXIDBeUiKkjNJl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I'm having some installation problems here that I'm hoping someone has
seen before. It's my first attempt to install on an Alpha, so it's
entirely possible that I am missing something rather basic - or simply
don't know where to delve for diagnostic info.

On my initial attempt, sysinstall would sig11 when trying to write the
disklabel. I've since gone through and updated the abios and srm to the
newest revisions - no more sig11, hooray. Now I see this instead, *after*
the disklabel, during newfs:

- ---------------------------------------------
/dev/da0a: 128.0 (262144 sectors) block size 16384, fragment size 2048
using 4 cylinder group of 32.02MB, 2049 blks, 4224 inodes.
super-block backups (for fsck -b #) at:
32, 65600, 131168, 196736
write error: 0
newfs: wtfs: Operation not permitted
- ---------------------------------------------

And voila, I'm stuck.=20

Any help offered is appreciated, I'm eager to get this beast running.

On a side note - no fdisk option in sysinstall? Is that normal on alpha
installs, or is that new to 5.0?

- -Mahlon

Mahlon E. Smith jabber id: mah...@chat.martini.nu
http://www.martini.nu/ get pgp key: mahlo...@martini.nu
=2E.......................................................................
I don't think I'm alone when I say I'd like to see more and more
planets fall under the ruthless domination of our solar system. --
Jack Handey

- --0vzXIDBeUiKkjNJl
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----

iD8DBQE+ODOvwL5r+zYGsmcRAvsQAKCkGS4R1MPSN9wwC/5rp3jG+dP6ZwCaAvv5
CXxcP8ik0MgqwE+oEv4rU30=
=vXco
- -----END PGP SIGNATURE-----

- --0vzXIDBeUiKkjNJl--

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

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

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

0 new messages