I have a Dell SC1435 server running an i386 -current system from
around the end of December, with a few selected updates applied. It
had been running reliably until early this morning, when the
following sequence of events happened. First, this message was
logged:
Feb 15 07:14:29 rock kernel:
On 15-Feb-2007 Kip Macy wrote:
The discard frame w/o packet header message comes from ether_input()
if it gets an mbuf that doesn't have the M_PKTHDR flag set. That
can't happen unless something is very wrong with the system. I'd like
to make it a panic. At least then the machine would
On 15-Feb-2007 Kip Macy wrote:
I mean a bug in if_bge.c - there are a lot of ways that this could
happen - not calling M_GETHDR, mis-calling m_pullup etc.
There's no obvious bug in that part of the driver, but I'm going to
instrument it on the offending system to try to find out just what's
Aniruddha Bohra wrote:
Hi,
In two drivers, fxp and em, the assumptions about entering the
ether_input routine are different.
From em_rxeof:
#ifdef DEVICE_POLLING
EM_UNLOCK()
(*ifp-if_input)()
EM_UNLOCK()
#else
(*ifp-if_input)()
#endif
While in fxp:
FXP_UNLOCK()
(*ifp-if_input)()
to pursue.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED
. Do
you think we should change it?
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send
In article [EMAIL PROTECTED],
Garrett Wollman [EMAIL PROTECTED] wrote:
On Tue, 25 Sep 2001 11:09:27 -0700 (PDT), John Polstra [EMAIL PROTECTED] said:
The trouble with this is that your password will be sent unencrypted
across the Internet, very possibly hitting a sniffer or two along
In article [EMAIL PROTECTED],
Garrett Wollman [EMAIL PROTECTED] wrote:
On Tue, 25 Sep 2001 11:21:36 -0700 (PDT), John Polstra [EMAIL PROTECTED] said:
Oh. I haven't actually sniffed it, so I'll assume you're right. I
apologize for the misinformation.
Well, that's the situation
In article [EMAIL PROTECTED],
John Polstra [EMAIL PROTECTED] wrote:
I've been setting up a 4.4-RELEASE system for net booting and diskless
operation with pxeboot, and I've run into a minor but annoying
problem. It seems that if you boot with PXE you can't use dhclient.
pxeboot configures
then.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
that are broken.
What is the reason you think it would be better to put the solution
into dhclient-enter-hooks?
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send
In article [EMAIL PROTECTED],
Cyrille Lefevre [EMAIL PROTECTED] wrote:
John Polstra wrote:
What is the reason you think it would be better to put the solution
into dhclient-enter-hooks?
IMHO, for instance, because this hack is only needed at PXE level
not after, I am right
In article 002601c15cb4$064fb440$[EMAIL PROTECTED],
Cyrille Lefevre [EMAIL PROTECTED] wrote:
John Polstra [EMAIL PROTECTED] wrote:
Also, I don't feel that my patch is a hack. The entire purpose of
dhclient's PREINIT phase is to put the network interface into an
enabled state so that IP
I've been setting up a 4.4-RELEASE system for net booting and diskless
operation with pxeboot, and I've run into a minor but annoying
problem. It seems that if you boot with PXE you can't use dhclient.
pxeboot configures the relevant network interface (let's call it
fxp0), NFS-mounts the root
yet, so we are focusing our efforts.
You can rest assured that, with the support of the FreeBSD community,
we will be funding worthwhile development efforts in the future too.
John Polstra
Vice President
The FreeBSD Foundation
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
the NETISR and AF
constants have to be the same.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net
idea of a `current process'.
I have also used this in a project where I lifted the whole TCP/IP
stack from FreeBSD and used it in an embedded environment. It's a
very handy thing to be able to do, and I wouldn't like to see it
remain broken.
John
--
John Polstra
John D. Polstra Co., Inc
happens in the bge driver, because it also offloads
checksum generation to the NIC.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL
the short packets, before they are padded. If you run it
on the receiving system, you'll see the padded packets.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
specifically, by means of a
new ioctl.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body
In article [EMAIL PROTECTED],
Richard A Steenbergen [EMAIL PROTECTED] wrote:
On Fri, Feb 22, 2002 at 09:43:58AM -0800, John Polstra wrote:
Remember, bpf is used by many things besides tcpdump. Adding these
flags would require extending the bpf API. They couldn't be added for
the default
the limit via the sysctl variable kern.ipc.maxsockbuf.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
to replace any structure elements you remove, if
possible.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
with that for -current.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body
(-current) and 1.2.2.11 (-stable). Maybe the person
who started this thread is using an older kernel than that.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe
If it produces any output, then the file contains the fix already.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED
think the fixed
module should work fine with a 4.5 kernel.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
have to be more intelligent, but this is just an experiment.
Please report back after you have tried this change. I know two
people who have reported that it solved the problems they were having
with BCM5701 chips in PCI-X systems.
John
--
John Polstra
John D. Polstra Co., Inc
In article [EMAIL PROTECTED],
Andrew Gallatin [EMAIL PROTECTED] wrote:
John Polstra writes:
Something is wrong with the hardware checksum offloading for
..
+#if 0
ifp-if_hwassist = BGE_CSUM_FEATURES;
ifp-if_capabilities = IFCAP_HWCSUM;
ifp-if_capenable = ifp
don't have the
programming docs.
The BCM570x chips (bge driver) definitely need a single physically
contiguous buffer for each received packet.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence
In article [EMAIL PROTECTED],
Bosko Milekic [EMAIL PROTECTED] wrote:
On Fri, Jul 05, 2002 at 09:45:01AM -0700, John Polstra wrote:
The BCM570x chips (bge driver) definitely need a single physically
contiguous buffer for each received packet.
This is totally ridiculous for gigE
In article [EMAIL PROTECTED],
Bosko Milekic [EMAIL PROTECTED] wrote:
On Fri, Jul 05, 2002 at 09:45:01AM -0700, John Polstra wrote:
The BCM570x chips (bge driver) definitely need a single physically
contiguous buffer for each received packet.
This is totally ridiculous for gigE
it would take a lot of trial error to
figure out how to make it work.
In other words, I doubt that the bge driver could use a new buffer API
unless it provided a way to get physically contiguous buffers.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington
sense, as
its a descendant of the tigon-2.
Are the tigon-2 docs publicly available and free from NDA concerns?
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
cache and they don't compete
with each other nearly so much. That is the underlying principle of
slab allocators, by the way.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
.
I guess my question then is: I'd like to clean this up. Is the approach
I'm suggesting correct?
FWIW, your approach is what the ng_ksocket node does. I've used it
before and it worked fine for me.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
seemed
generally useful.
Please whittle the patch down to just the bug fix; 5.0 is in code freeze.
Don't worry, Sam. I'm planning to shepherd this stuff into the
tree, but I don't see it happening for 5.0.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle
to support our operating system. Let's just let the 4.x branch
live out the rest of its life span in a compatible way.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
to see a lot more support for IPv6 from vendors, etc.
Kind of like what happened with Ada, eh? ;-)
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Two buttocks cannot avoid friction. -- Malawi saying
In article [EMAIL PROTECTED],
Edwin Groothuis [EMAIL PROTECTED] wrote:
On Tue, Aug 05, 2003 at 11:17:07AM -0700, John Polstra wrote:
Tcpdump has always shown traffic _at_ the network interface. That's
why it has the -i option. I would not like to see that behavior
changed.
I totally
nanoseconds
add up quickly to the point where they matter. With 10 Gb ethernet on
the way, it will only get worse.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Two buttocks cannot avoid friction. -- Malawi saying
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
was not in use. I said these are only made when BPF
is in use. What doesn't follow?
What doesn't follow is, So any slow down should only happen when
BPF is active.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Two buttocks cannot avoid friction
performance out of bpf
is just not there until memory speeds increase a lot or the copying goes away.
My point is that the extra calls to bpf_mtap would harm performance
even when bpf wasn't being used.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
I'm trying for the first time to get routed(8) to do something useful,
and it's got me stumped. The man page says:
Static routes in the kernel table are preserved and included in RIP
responses if they have a valid RIP metric (see route(8)).
From reading the sources, valid RIP metric seems
On 14-Nov-2003 .@babolo.ru wrote:
I remember that VLAN tag has 12 bits :-)
I need in system with 5000 .. 1 VLAN
interfaces on 2 .. 6 physical ethernets.
Er, so what is your strategy for packing 5000-1 different values
into a 12-bit field?
Does anybody has such expienence?
On 14-Nov-2003 Brooks Davis wrote:
I think is should work, but performance may be poor. Currently,
vlan_input() finds the correct vlan by searching the list of all vlans
until it finds the correct one. For that many vlans, it might be
necessicary to modify the code to use some form of
On 19-Nov-2003 Crist J. Clark wrote:
OK, an easy one. I am trying to do some netgraph(3) coding in
userland. From how I read the documentation, this should work. Before
I go learn all of the netraph(4) kernel code to understand the error
message, could someone tell me how this is supposed to
On 23-Nov-2005 Kris Kennaway wrote:
I am seeing the em driver undergoing an interrupt storm whenever the
amr driver receives interrupts. In this case I was running newfs on
the amr array and em0 was not in use:
28 root1 -68 -187 0K 8K CPU1 1 0:32 53.98% irq16: em0
Can somebody explain why there is both an IF_HANDOFF macro and an
IFQ_HANDOFF macro? Except for a slight difference in parameters,
they both seem to do roughly the same thing using completely distinct
blocks of code. Is IF_HANDOFF supposed to be used only when the
target queue is not the
On 15-Jun-2006 Robert Watson wrote:
On Wed, 14 Jun 2006, John Polstra wrote:
Can somebody explain why there is both an IF_HANDOFF macro and an
IFQ_HANDOFF macro? Except for a slight difference in parameters, they both
seem to do roughly the same thing using completely distinct blocks
On 18-Jun-2006 John-Mark Gurney wrote:
John Polstra wrote this message on Thu, Jun 15, 2006 at 09:18 -0700:
in the HW but have not yet completed. When the completion interrupt
comes in, the driver is supposed to check the if_snd queue for more
mbufs and process them. Only when the transmit
Attached is a patch that maintains the current if_start, but adds
if_startmbuf. If a device driver implements if_startmbuf and the global
sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in the
driver will be used. Otherwise, if_start is used. I have modified the
On 31-Jul-2006 Petri Helenius wrote:
Robert Watson wrote:
I tend to agree, but implemented full queueing support for if_em to
make sure I understood to complexity implications of completely
removing queueing from the ifnet side dispatch. I guess an
interesting question for us is how we
On 26-Sep-2006 Danny Braniss wrote:
This keeps bitting me every other upgrade, IPMI on some
hosts, if enabled, will steal packets to port 623 or 664, so
the current solution is either set net.inet.ip.portrange.lowlast
to 664, (for some reason this does not seem to work if done via
On 19-Oct-2006 Scott Long wrote:
The performance measurements that Andre and I did early this year showed
that the INTR_FAST handler provided a very large benefit.
I'm trying to understand why that's the case. Is it because an
INTR_FAST interrupt doesn't have to be masked and unmasked in the
Folks, I'm using -current from 2006-11-16 05:00 UTC and find that my
em interfaces are unusable on two quite different platforms. I've
tried a lot of things to make sure it's not a local fubar here,
including doing a make release using a virgin source tree and
installing fresh from the resulting
On 18-Nov-2006 Mike Tancsa wrote:
Havent had too much experience with PCIe riser cards yet, but have
had some experience with bad PCI-X risers. Any way to test to see if
its a bad riser card? The behaviour almost looks to be a hardware issue ?
I agree. There's another slot (with its own
On 19-Nov-2006 John Polstra wrote:
On 18-Nov-2006 Mike Tancsa wrote:
Havent had too much experience with PCIe riser cards yet, but have
had some experience with bad PCI-X risers. Any way to test to see if
its a bad riser card? The behaviour almost looks to be a hardware issue ?
I agree
Well, this is embarrassing. It turns out there were two different
problems, neither one caused by the driver.
1. I had some ARP poisoning going on on my LAN, and that's why the two
em interfaces in the Dell box appeared to be behaving so strangely. I
fixed that, and the box is working just fine
On 30-Dec-2006 Bruce Evans wrote:
More debugging showed that almost any of the reads of the phy in mii
cause an input error,
The errors appear to be caused by the code in bge_miibus_{read,write}reg
that clears and then restores the BGE_MIMODE_AUTOPOLL bit of the
BGE_MI_MODE register. If you
On 09-Jan-2007 Oleg Bulyzhin wrote:
On Mon, Jan 08, 2007 at 04:33:29PM -0800, John Polstra wrote:
On 30-Dec-2006 Bruce Evans wrote:
More debugging showed that almost any of the reads of the phy in mii
cause an input error,
The errors appear to be caused by the code in bge_miibus_{read
On 16-Mar-2004 Mike Jakubik wrote:
Got it. In just curious though... realistically, how big of an impact on
performance is this on a modern CPU? Is it not simply the original 32bit
calculation x 2?
Please, just search the mailing list archives. We've already had this
discussion in depth.
On 13-May-2004 Ruslan Ermilov wrote:
I'm looking for a Broadcom BCM5704[S] technical datasheet. If anyone has
such a beast, or knows how one could obtain it, please let me know.
Broadcom only provides them under NDA.
John
___
[EMAIL PROTECTED]
On 05-May-2004 Søren Schmidt wrote:
For what its worth I have problems with one em based interface as well,
it locks the machine solid when used:
em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.25 port
0xb000-0xb01f mem 0xfb10-0xfb11 irq 10 at device 1.0 on pci1
em0:
On 05-May-2004 Søren Schmidt wrote:
John Polstra wrote:
Are either of the IRQs (10 and 19) shared with other devices?
Yes, the working one is shared with an (unused) USB port
I was hoping the failing IRQ would be shared. So much for that
idea. :-)
John
On 17-Aug-2004 Harti Brandt wrote:
On Mon, 16 Aug 2004, Bjoern A. Zeeb wrote:
BAZHi,
BAZ
BAZIt seems netgraph is only build on ia64 and i386.
BAZCan someone please explain why ?
Until around april I used all the ATM related Ng stuff regularily (this
include ng_socket, all the stuff
On 18-Aug-2004 Julian Elischer wrote:
John Polstra wrote:
There is one problem with netgraph on 64-bit platforms. The ng_msghdr
struct is 52 bytes / 4-byte aligned (see ng_message.h). That means
the message payload is not well-aligned for 64-bit platforms. It
would be nice to fix
I dropped scottl and re from the cc list, since they're busy and asked
us to work it out on our own.
On 20-Aug-2004 Julian Elischer wrote:
Ok so what is the next number that should be used?
it's currently #define __FreeBSD_version 60
61?
Yes, that would be the next number. I
On 31-Oct-2004 Sean Chittenden wrote:
This has long bugged me and tonight I finally snapped and had to do
something about it. Example output:
64 bytes from a.b.c.d: icmp_seq=935 ttl=126 time=33.824 ms
64 bytes from a.b.c.d: icmp_seq=936 ttl=126 time=29.138 ms
64 bytes from a.b.c.d:
On 17-May-2005 Ernest Smallis wrote:
Hi All, I am seeing this problem as well:
a. The kernel is in a tight loop via the fxp driver since there are
frames that need to be DMA'd but cannot be because 'b.'
b. The fxp driver calls m_getcl( ) which returns ENOBUFS since there
are no clusters to
72 matches
Mail list logo
