https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287369
Mark Linimon changed:
What|Removed |Added
Keywords||crash
Assignee|b...@freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271366
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
Resoluti
from Ricardo Branco ---
Same here on QEMU VM:
Invoking IPv6 network device address event may sleep with the following
non-sleepable locks held:
exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r = 0 (0xf80002988600) locked
@ /usr/src/sys/dev/virtio/network/if_vtnet.c:2212
stack backtrace:
#0
Hi,
I think it's pretty common nowadays to have NICs with completion
rings/queues. It is definitely appropriate to implement such drivers with
iflib, and indeed iflib provides separate callbacks for updating the TX/RX
"submission" and "completion" queues:
- ift_txd_encap: submit a packet to a
I have a NIC (a SmartNIC actually) for which I have to implement a
driver, which in addition to RX and TX rings exposes also completion
CMPT rings. Due to this additional complication (the CMPT rings), I'm
not sure how appropriate it is to implement such a driver via the
IFLIB framework. Does anyon
ifconfig_DEFAULT="DHCP inet6 accept_rtadv"
$ dmesg
[...]
lo0: link state changed to UP
xn0: 2 link states coalesced
xn0: link state changed to UP
Invoking IPv6 network device address event may sleep with the following
non-sleepable locks held:
exclusive sleep mutex xnrx_2 (netfront receive l
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271366
Mina Galić changed:
What|Removed |Added
CC||free...@igalic.co
--- Comment #1 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271366
Piotr Kubaj changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receivi
On 25/3/18 12:21 am, Grzegorz Junka wrote:
Hi,
In my laptop I have both, wlan0 and ue0 (ethernet). When both are
connected, FreeBSD chooses to use wlan0 by default. Only when I
disable wlan0 it switches to use ue0. Since ue0 is ethernet it's
obviously much faster than wlan0.
It's decided by
Bezüglich Grzegorz Junka's Nachricht vom 24.03.2018 17:21 (localtime):
> Hi,
>
> In my laptop I have both, wlan0 and ue0 (ethernet). When both are
> connected, FreeBSD chooses to use wlan0 by default. Only when I
> disable wlan0 it switches to use ue0. Since ue0 is ethernet it's
> obviously much f
Hi,
In my laptop I have both, wlan0 and ue0 (ethernet). When both are
connected, FreeBSD chooses to use wlan0 by default. Only when I disable
wlan0 it switches to use ue0. Since ue0 is ethernet it's obviously much
faster than wlan0.
Why FreeBSD is selecting wlan rather than ue? How to config
On Sun, 20 Jan 2013 10:56:24 +1100
Peter Jeremy wrote:
> On 2013-Jan-17 14:38:06 -0500, "Stephen J. Kiernan"
> wrote:
> >The patch also includes moving zlib.[ch] and zlibutil.h out of net and
> >into sys/libkern (for the .c) and sys/sys (for the .h).
>
> Good.
>
> >It really doesn't make muc
On 2013-Jan-17 14:38:06 -0500, "Stephen J. Kiernan" wrote:
>The patch also includes moving zlib.[ch] and zlibutil.h out of net and
>into sys/libkern (for the .c) and sys/sys (for the .h).
Good.
>It really doesn't make much sense for that code to live in net,
>especially when so many things whi
On Fri, 18 Jan 2013 00:07:06 +0100
Damien Fleuriot wrote:
>
> On 17 Jan 2013, at 22:53, Steve Kiernan wrote:
>
> > On Thu, 17 Jan 2013 22:11:27 +0100
> > Andre Oppermann wrote:
> >
> >> On 17.01.2013 20:23, Stephen J. Kiernan wrote:
> >>> The network stack as a module patch has been separate
On 17 Jan 2013, at 22:53, Steve Kiernan wrote:
> On Thu, 17 Jan 2013 22:11:27 +0100
> Andre Oppermann wrote:
>
>> On 17.01.2013 20:23, Stephen J. Kiernan wrote:
>>> The network stack as a module patch has been separated out and can be found
>>> in the following location:
>>> http://people.fre
On Thu, 17 Jan 2013 22:11:27 +0100
Andre Oppermann wrote:
> On 17.01.2013 20:23, Stephen J. Kiernan wrote:
> > The network stack as a module patch has been separated out and can be found
> > in the following location:
> > http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff
>
> This is qu
On 17.01.2013 20:23, Stephen J. Kiernan wrote:
The network stack as a module patch has been separated out and can be found in
the following location:
http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff
This is quite some work and a lot of changes which will a moment to review.
Can you
On Jan 17, 2013 14:23, Stephen J. Kiernan wrote:
The network stack as a module patch has been separated out and can be
found in the following location:
http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff
Details about these changes:
I also forgot to mention in the previous e-mail.
The
The network stack as a module patch has been separated out and can be
found in the following location:
http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff
Details about these changes:
1. Network stack module support infrastructure
kern/{kern_netstack.c,netstack_if.m,netstack.h}
>
>
> I renamed the interface implementation from mumble_ddi.h to
> if_device.[ch] and put a diff here:
>http://people.freebsd.org/~marcel/Juniper/if_device.diff
Looks reasonable to me. Gives some protection from API change
But to really make use of this you could have driver specific meth
On Sep 5, 2012, at 1:16 PM, George Neville-Neil wrote:
> One more note. Can you break the patches down into more bite sized pieces?
> They're hard
> to review as is.
Following up finally. Let's focus on the device driver interface.
I renamed the interface implementation from mumble_ddi.h to
On Fri, Sep 07, 2012 at 01:28:16AM -0700, Anuranjan Shukla wrote:
> Hi George,
> Thanks for taking a look. Some answers/comments below.
>
> >
> >> Building FreeBSD without the network stack (network stack as a module)
> >> --
> >>
Hi George,
On 9/5/12 1:15 PM, "George Neville-Neil" wrote:
>
>> Building FreeBSD without the network stack (network stack as a module)
>> --
>> Today, not compiling networking stack related files in the kernel breaks
>> the kerne
On 9/7/12 8:48 AM, "Julian Elischer" wrote:
struct socket {
int so_fibnum; /* routing domain for this socket */
uint32_t so_user_cookie;
+ u_int so_oqueue; /* manage send prioritizing based on
application
needs */
+ u_short so_lrid;
At Fri, 7 Sep 2012 01:28:16 -0700,
Anuranjan Shukla wrote:
>
>
> >
> >> struct socket {
> >>
> >>int so_fibnum; /* routing domain for this socket */
> >>uint32_t so_user_cookie;
> >> + u_int so_oqueue; /* manage send prioritizing based on
> >>application
> >> needs */
> >
On 9/7/12 4:28 PM, Anuranjan Shukla wrote:
Hi George,
Thanks for taking a look. Some answers/comments below.
Building FreeBSD without the network stack (network stack as a module)
--
This would be interesting for many reasons
Hi George,
Thanks for taking a look. Some answers/comments below.
>
>> Building FreeBSD without the network stack (network stack as a module)
>> --
>>
>This would be interesting for many reasons, and I think it would be a good
>co
One more note. Can you break the patches down into more bite sized pieces?
They're hard
to review as is.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "fre
I think there is
already some agreement about these proposals, at least there was
in the room, now to get some on net@.
> The changes we propose are (the code/diffs etc are indicated
> at the end of this email):
>
> - Network Device Drivers
> - Building FreeBSD kernel without net
On Aug 28, 2012, at 10:24 AM, PseudoCylon wrote:
> Wouldn't using prepossessor macro or hooking be more flexible? (Could
> support multiple functionality.)
Macros make it impossible to treat ifnet as an opaque type.
As such, it won't be possible to havr a single pre-compiled
driver that can wor
> --
>
> Message: 2
> Date: Fri, 24 Aug 2012 21:11:45 -0700
> From: Anuranjan Shukla
> Subject: Proposal for changes to network device drivers and network
> stack (RFC)
> To: "freebsd-net@freebsd.org"
> Message-ID:
&g
ndicated that interested folks
are welcome to chat with him about this stuff during the summit.
The changes we propose are (the code/diffs etc are indicated
at the end of this email):
- Network Device Drivers
- Building FreeBSD kernel without network stack, network stack as a module
- Changes to mbu
On Thu, Jan 15, 2009 at 08:07:35PM +0200, Yony Yossef wrote:
> > Eygene Ryabinkin wrote:
> > > ...
> > > I wanted to stress only one point: simple 'kldunload ' and
> > > 'kldload ' makes devices to flip for Yony's case.
> > This means
> > > that unless some PCI hotplug stuff is here (which I don't
> Eygene Ryabinkin wrote:
> > ...
> > I wanted to stress only one point: simple 'kldunload ' and
> > 'kldload ' makes devices to flip for Yony's case.
> This means
> > that unless some PCI hotplug stuff is here (which I don't
> believe to
> > be present, because no physical cards are touched and th
Eygene Ryabinkin wrote:
...
I wanted to stress only one point: simple 'kldunload ' and
'kldload ' makes devices to flip for Yony's case. This means
that unless some PCI hotplug stuff is here (which I don't believe to be
present, because no physical cards are touched and there is actually a
small
> Thu, Jan 15, 2009 at 01:15:53PM +0200, Yony Yossef wrote:
> > > You're using your own driver, aren't you? If yes, could you show
> > > your device_method_t structure and the corresponding identify,
> > > probe, attach and detach routines? You're setting the
> unit numbers
> > > via 'if_initname
Bruce, good day.
Thu, Jan 15, 2009 at 03:01:37PM +, Bruce M. Simpson wrote:
> Bruce M. Simpson wrote:
> > In your case I'm not sure why your two cards would flip order. Could
> > it be how your BIOS and hardware set up the PCI IDSEL lines at boot?
>
> If this is the case on your system, then
Yony,
Bruce M. Simpson wrote:
And how come the unit number is given an arbitrary value? Is there a
good
reason for that?
...
In your case I'm not sure why your two cards would flip order. Could
it be how your BIOS and hardware set up the PCI IDSEL lines at boot?
If this is the case on
Yony Yossef wrote:
Thanks for the explanation.
So there's no way to determine this in advance..
I must build a script that contains my own mapping between MAC addresses and
the wanted interface names and run it after each driver load, rename the
interfaces if necessary.
It seems quite wrong,
Thu, Jan 15, 2009 at 01:15:53PM +0200, Yony Yossef wrote:
> > You're using your own driver, aren't you? If yes, could you
> > show your device_method_t structure and the corresponding
> > identify, probe, attach and detach routines? You're setting
> > the unit numbers via 'if_initname(ifp, dev
reebsd-questi...@freebsd.org
> Subject: Re: howto determine network device unit number? device.hints?
>
> Yony, good day.
>
> Thu, Jan 15, 2009 at 11:26:34AM +0200, Yony Yossef wrote:
> > All I'm doing is unloading and reloading the driver.
> > Unit numbers change an
H.fazaeli wrote:
>
>for example, say you have 2 interface em0 and em1 which
>you like to swap their minor numbers:
>ifconfig em0 name tmp
>ifconfig em1 name em0
>ifconfig em0 name em1
>or to assign cisco-like names to you interfaces:
>ifconfig xl0 name fastEthernet0
>
Hi,
Sorry to jump in but...
> Problem is, this unit number is not constant and changing arbitrarily every
> time I reload the driver (card A unit number=0 & card B un=1 or the other
> way around).
Since I have been using FreeBSD, the NIC had always been given the
same unit number (that is, unles
Yony, good day.
Thu, Jan 15, 2009 at 11:26:34AM +0200, Yony Yossef wrote:
> All I'm doing is unloading and reloading the driver.
> Unit numbers change and it makes my automatic subnet configuration
> (/etc/rc.conf) assign bad IPs.
You're using your own driver, aren't you? If yes, could you show
> Yony Yossef wrote:
> > Thanks for the explanation.
> >
> > So there's no way to determine this in advance..
> >
> What do you mean by 'in advance'? Assuming a fixed hardware
> configuration, when the kernel is loaded, you know all the
> interface names and can rename them, i.e., in rc.lo
ssef
Cc: freebsd-net@freebsd.org; freebsd-questi...@freebsd.org
Subject: Re: howto determine network device unit number? device.hints?
for example, say you have 2 interface em0 and em1 which
you like to swap their minor numbers:
ifconfig em0 name tmp
ifconfig em1 name em0
ifconfig em0 name em1
or to ass
me of the
interfaces.
Yony
>
> >
> > Yony
> >
> >
> >
> > _
> >
> > From: H.fazaeli [mailto:faza...@sepehrs.com]
> > Sent: Thursday, January 15, 2009 10:26 AM
> > To: Yony Yossef
> > Cc: freebsd-net@freebsd.o
hat's left.
Yony
_
From: H.fazaeli [mailto:faza...@sepehrs.com]
Sent: Thursday, January 15, 2009 10:26 AM
To: Yony Yossef
Cc: freebsd-net@freebsd.org; freebsd-questi...@freebsd.org
Subject: Re: howto determine network device unit number? device.hints?
for example, say you have 2 interf
Re: howto determine network device unit number? device.hints?
for example, say you have 2 interface em0 and em1 which
you like to swap their minor numbers:
ifconfig em0 name tmp
ifconfig em1 name em0
ifconfig em0 name em1
or to assign cisco-like names to you interfaces:
ifconfig xl0 name fastEthernet0
Liss
Subject: Re: howto determine network device unit number? device.hints?
you may not change unit numbers as they are strictly
controlled by kernel.
However, on freebsd 5.3+, you may use 'ifconfig name '
to achieve the same affect
Sorry, I don't understand the usage of ifconfi
> -Original Message-
> From: H.fazaeli [mailto:faza...@sepehrs.com]
> Sent: Wednesday, January 14, 2009 6:24 PM
> To: Yony Yossef
> Cc: freebsd-net@freebsd.org; freebsd-questi...@freebsd.org;
> Eitan Shefi; Oleg Kats; Liran Liss
> Subject: Re: howto determin
>
> you may not change unit numbers as they are strictly
> controlled by kernel.
> However, on freebsd 5.3+, you may use 'ifconfig name '
> to achieve the same affect
>
Sorry, I don't understand the usage of ifconfig you suggested and the effect
it will cause.
Can you please explain it?
Yony
>
you may not change unit numbers as they are strictly controlled by kernel.
However, on freebsd 5.3+, you may use 'ifconfig name '
to achieve the same affect
Yony Yossef wrote:
Hi,
I would like to determine the unit number of my network cards, e.g.
make the device on pci0:16 be assigned every
Hi,
I would like to determine the unit number of my network cards, e.g.
make the device on pci0:16 be assigned every time with unit number 0
and pci0:19 with unit number 1.
Is it done by /boot/device.hints?
if so, how?
My cards are:
mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x
Hi,
I would like to determine the unit number of my network cards, make the
device on pci0:16 appear always as mtnic0 and pci0:9 appear always as
mtnic1.
# pciconf -l | grep mtnic
mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00
mtn...@pci0:16:0:0: c
Hi,
I would like to determine the unit number of my network cards, make the
device on pci0:16 appear always as mtnic0 and pci0:9 appear always as
mtnic1.
# pciconf -l | grep mtnic
mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00
mtn...@pci0:16:0:0: c
On Sun, 17 Feb 2008, Kip Macy wrote:
Hi,
You might want to check out sys/modules/cxgb/tom/Makefile.
ha, so that file is not compiled at all. Thanks for pointing this out.
Is there a reason to keep it in cvs then? I guess there is but it's
not obvious to me;-)
So basically what does that mean
You might want to check out sys/modules/cxgb/tom/Makefile.
-Kip
On Feb 17, 2008 1:24 PM, Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008, Robert Watson wrote:
>
> Hi,
>
> [cutting a long mail short and randomly replying;-)]
>
> I came across dev/cxgb/ulp/tom/cxgb_tcp_subr.c vs. ne
On Sun, 6 Jan 2008, Robert Watson wrote:
Hi,
[cutting a long mail short and randomly replying;-)]
I came across dev/cxgb/ulp/tom/cxgb_tcp_subr.c vs. netinet/tcp_subr.c
and I am a bit worried with the way things are done atm. For those
functions copied over there are only changes like:
-
At Sun, 6 Jan 2008 13:47:24 + (GMT),
rwatson wrote:
>
>
> There's also the opportunity to think about whether it's possible to
> harden things in such a ways as to not give up our flexibility to
> keep maintaining and improving TCP (and other related subsystems),
> yet improving the quality o
On Jan 10, 2008 2:50 PM, <[EMAIL PROTECTED]> wrote:
> At Sun, 6 Jan 2008 13:47:24 + (GMT),
> rwatson wrote:
> >
> >
> > There's also the opportunity to think about whether it's possible to
> > harden things in such a ways as to not give up our flexibility to
> > keep maintaining and improving
On Jan 6, 2008 5:47 AM, Robert Watson <[EMAIL PROTECTED]> wrote:
...
> My proposal, and this is really a proposal to drive discussion as much as a
> proposal for a policy, is that the internal TCP data structures exported via
> the TOE interfaces and accessed by TOE device drivers *not* be conside
h are already precluded by the ABI/KPI policy, since knowledge of the
packet header layout is compiled into all network device drivers. What I'm
more concerned about is the new exposure of internal data structures and
algorithms, and a resulting freeze of those data structures and algorithms
Robert Watson wrote:
There's also the opportunity to think about whether it's possible to
harden things in such a ways as to not give up our flexibility to keep
maintaining and improving TCP (and other related subsystems), yet
improving the quality of life for a third party TOE driver maint
about how we want to treat
the TOE interface with respect to third party device driver support, and more
specifically to propose that we not consider the TOE interface to be part of
our stable network device driver KPI/ABI once it appears in a RELENG_X branch.
The background: in the last few Fr
Ivan Voras wrote:
I've noticed in ifconfig report for a gigabit NIC based on Realtek 8169S
chip that it has the SIMPLEX flag set. What does it mean in practice,
considering the media type is (correctly) autonegotiated for 1000baseTX
full-duplex?
Hello,
One of the first hits on google showed:
I've noticed in ifconfig report for a gigabit NIC based on Realtek 8169S
chip that it has the SIMPLEX flag set. What does it mean in practice,
considering the media type is (correctly) autonegotiated for 1000baseTX
full-duplex?
signature.asc
Description: OpenPGP digital signature
Dear all,
There is a way to install a 2 network device with fault
tolerance(active-standby) or with load-balancing( virtual ip address)?
thanks in advance
yqyq22
_
MSN Extra Storage: piena libertà di esprimersi e comunicare
http
Might FreeBSD suffer from this issue?
Do all our drivers pad packets with zero octets properly?
http://www.kb.cert.org/vuls/id/412115
http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf
Cheers,
--
Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/
NTT
< said:
> This is similar to the way most VxWorks network drivers operate:
Right -- in fact, as I recall, Mogul's paper mentions that his
solution is very similar to the way many RTOSes operate.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the
> it occurs to me that there is a potential infinite loop in
> most if not all ethernet drivers. Basically, on a
> receive interrupt, such drivers loop around the status word
> until the receive queue is drained.
>
> If the body of the loop takes approx the same as
> the packet interarrival time,
Garrett Wollman wrote:
>
> < said:
>
> > it occurs to me that there is a potential infinite loop in
> > most if not all ethernet drivers. Basically, on a
> > receive interrupt, such drivers loop around the status word
> > until the receive queue is drained.
>
> One possible right way to deal wi
Mark Peek wrote:
>
> At 9:09 PM -0500 2/8/01, Garrett Wollman wrote:
> >One possible right way to deal with this is to get rid of the
> >two-level interrupt scheme (for fast interfaces at least) and push the
> >packets all the way through the network stack. This will ensure that
> >if packets ar
At 9:09 PM -0500 2/8/01, Garrett Wollman wrote:
>One possible right way to deal with this is to get rid of the
>two-level interrupt scheme (for fast interfaces at least) and push the
>packets all the way through the network stack. This will ensure that
>if packets are arriving faster than we can
< said:
> it occurs to me that there is a potential infinite loop in
> most if not all ethernet drivers. Basically, on a
> receive interrupt, such drivers loop around the status word
> until the receive queue is drained.
One possible right way to deal with this is to get rid of the
two-level int
Hi,
it occurs to me that there is a potential infinite loop in
most if not all ethernet drivers. Basically, on a
receive interrupt, such drivers loop around the status word
until the receive queue is drained.
If the body of the loop takes approx the same as
the packet interarrival time, you migh
76 matches
Mail list logo
