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)()
FXP_LOC
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
go
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 machin
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 13-Jan-2007 Oleg Bulyzhin wrote:
>> Could you please test attached patch? It should fix ierrs issue and should
>> not
>> break link events (would be fine to test it: unplug/plug cable, try to change
>> media with ifconfig, change media on other end of wire).
>>
>
> Oops, previous patch was in
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 er
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 r
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 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 t
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
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 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
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
> l
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 i
> 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 i
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
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 u
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 interfac
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: em
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
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
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 qu
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 platfor
On 17-Aug-2004 Harti Brandt wrote:
> On Mon, 16 Aug 2004, Bjoern A. Zeeb wrote:
>
> BAZ>Hi,
> BAZ>
> BAZ>It seems netgraph is only build on ia64 and i386.
> BAZ>Can someone please explain why ?
>
> Until around april I used all the ATM related Ng stuff regularily (this
> include ng_socket, all th
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] m
On 06-May-2004 Andre Oppermann wrote:
> Søren Schmidt wrote:
>>
>> Andre Oppermann wrote:
>> > What MIIPHY does the card have?
>>
>> No idea, builtin of sorts, there is no mention of it in the probe, and
>> no HW to see on the boards. I have two different boards with these on
>> them both show th
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
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: port
> 0xb000-0xb01f mem 0xfb10-0xfb11 irq 10 at device 1.0 on pci1
> em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xfb100
On 16-Mar-2004 Dag-Erling Smørgrav wrote:
> Ruslan Ermilov <[EMAIL PROTECTED]> writes:
>> I know this code quite well. Where do you suspect could be a bug
>> affecting -O2 compiles, or you just simply fixed -O2 and hope it
>> will auto-fix the (possible) bugs in -O2?
>
> Since there is no inline
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 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 t
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 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 22-Oct-2003 Greg Black wrote:
> On 2003-10-20, Tobias P. Santos wrote:
>
>> I am trying to boot a FreeBSD diskless client with no success.
>> Actually, I can boot the client, the kernel is downloaded and begins
>> to boot. Then it tries to reach the DHCP/BOOT server, but this never
>> occurs an
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
e design mandates a packet copy.
>
> It´s not a justification to make it slower but gigabit 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
the point where they matter. With 10 Gb ethernet on
> > the way, it will only get worse.
>
> You said there were calls to bpf_mtag and they would add noticeable
> overhead even when BPF was not in use. I said these are only made when BPF
> is in use. What doesn't follo
t the
extra calls to bpf_mtap to be present in the code only if enabled by
an option in the kernel config file.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Two buttocks cannot avoid friction." -- Malaw
inate
the problem. Even with gigabit ethernet those individual 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
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
If that is indeed the case, you're going
> 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 av
ut I think the problem would go away if you
changed WAIT_FOR_AUTO_NEG_DEFAULT to 0 in "if_em.h".
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Two buttocks cannot avoid friction." -- Malawi saying
ugs in the TCP implementation in
4.5-RELEASE. Try upgrading to the latest -stable.
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
-around for a chip bug. I can't think of
any other possible motivation for taking such a performance hit.
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
FreeBSD, and it only discourages them from
trying 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
"
> without the VPD stuff), but the other changes 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
70x chip, apparently. I noticed
that the Linux driver only applies this workaround for 5700 and 5701
chips. If you want better performance you may have to wait until
you can buy cards with the newer 5703 chips on them. Or, switch to
a non-Athlon system.
John
--
John Polstra
Jo
seeing the problem only on TCP packets.
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
load on the victim.
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
> touch it when I made that change several years ago.
>
> 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
--
J
I don't know the answer to that.
The majority of systems will be uniprocessor for a good long time, and
I would hate to see their performance sacrificed needlessly.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappo
counts laid out as they are
in -stable, i.e., one big contiguous block of counts. That way, the
counts are spread out through the entire 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
y* like the equivalent tigon-2 struct. This makes 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 i
r, probably) but the driver doesn't actually
use it. Without the docs 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 con
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.
>
&
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.
>
&
I'm pretty sure that most of
> them are capable of doing scatter DMA, but I 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.
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;
>
the only one that even attempts to do checksum offloading for
fragments. So the bug could easily be elsewhere in the system.
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
t
will flat-out break Alphas and most other architectures. The actual
fix would 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
they should load the
module. That should solve the problem for them. I 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.&
hwassist /sys/netgraph/ng_ether.c
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 U
r.c
revisions 1.22 (-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
are lost.
You can confirm this if you wish, by hacking up the xl driver to
disable hardware checksumming. Search for "CSUM" in sys/pci/if_xl.c
and #ifdef out the appropriate pieces of code.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle,
5.0 anyway. Placing dummy-fillers is just
> annoying.
OK, I can live 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
ent kettle of fish, but even there you
should add fillers 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ögya
from
consuming all of the mbufs and/or mbuf clusters.
You can change 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 intelligen
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.
ak compatibility with other
applications. They'd have to be enabled 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ö
., the Intel 8254x)
automatically pad these packets to the minimum Ethernet packet size
while transmitting them. If you run tcpdump on the sending system,
you'll see the short packets, before they are padded. If you run it
on the receiving system, you'll see the padded packets.
John
--
p on the receiving system instead,
you'll find that the checksums seen there are valid.
The same thing happens in the bge driver, because it also offloads
checksum generation to the NIC.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington US
rrupt context, and thus without any
> 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
rema
find any reason at all why 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 mai
ly don't have the resources to
tackle a dozen projects at once 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 Foun
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 PREINI
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 onl
27;s what I'd have to do. But this is
FreeBSD, and we can fix things 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
&qu
OK, it doesn't bother me to keep the fix in my local tree until
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
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 yo
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 fil
e packet was received.
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
g is FreeBSD 4.3-release.
In addition to the suggestion from Alex Rousskov, adding these lines
to "/boot/loader.conf" may help:
kern.ipc.maxsockets="8192"
kern.ipc.nmbclusters="32768"
John
--
John Polstra
John D. Polstra & Co., Inc.
as it was described upthread, and I
> experienced something similar when I was first setting up PPP dialups
> here.
Having looked back at my ppp.conf files, I'm sure you're right. The
way to keep your unencrypted passwords off the net is with "deny pap".
John
--
John Pols
ppy to have clients authenticate themselves.
Oh. I haven't actually sniffed it, so I'll assume you're right. I
apologize for the misinformation.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.
to CHAP-authenticate themselves (like my
> remote VPN servers, it seems).
The trouble with this is that your password will be sent unencrypted
across the Internet, very possibly hitting a sniffer or two along the
way. It's better to insist on chap and fix the broken peers.
John
--
J
In article <[EMAIL PROTECTED]>,
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> * John Polstra <[EMAIL PROTECTED]> [010831 15:03] wrote:
> > FreeBSD's "src/etc/amd.map" file still has "vers=2,proto=udp". Do
> > you think we should change i
t;src/etc/amd.map" file still has "vers=2,proto=udp". Do
you think we should change it?
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment
tBSD.
>
> Why? Is there any reason to believe that FreeBSD will (or even should)
> ever support ARCNET?
Yes, Max and others in Russia (at least) feel that it will be
worthwhile to support it. The core team approved his committership
fully aware that this was one of the project
88 matches
Mail list logo
