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
ifconfig em0 name gigaEthernet0
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, don't you agree?
And
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.
you must agree it's
v...@freebsd.org написа:
Synopsis: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx
State-Changed-From-To: open->feedback
State-Changed-By: vwe
State-Changed-When: Wed Jan 14 22:41:48 UTC 2009
State-Changed-Why:
Doichin,
the patch isn't available for download anymore, so w
> 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 nece
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.local.
I must build a s
> 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
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
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
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
>
> -Original Message-
> From: rea-f...@codelabs.ru [mailto:rea-f...@codelabs.ru]
> Sent: Thursday, January 15, 2009 12:01 PM
> To: Yony Yossef
> Cc: 'Julian Elischer'; Liran Liss; freebsd-net@freebsd.org;
> Oleg Kats; 'H.fazaeli'; Eitan Shefi; freebsd-questi...@freebsd.org
> Subject: Re
2009/1/15 Julian Elischer
> Dimitar Vasilev wrote:
>
>>
>>
>>I'd much appreciate if someone thinks with me for the best
>>options of using
>>the setfib features along with pf.
>>
>>
>>I know setfib but I don't know pf unfortunately.. I use ipfw
>>(which is
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
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,
NetOne - Doichin Dokov написа:
v...@freebsd.org написа:
Synopsis: [txp] [patch] txp driver doesn't work with latest firmware
03.xxx.xxx
State-Changed-From-To: open->feedback
State-Changed-By: vwe
State-Changed-When: Wed Jan 14 22:41:48 UTC 2009
State-Changed-Why: Doichin,
the patch isn't avail
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
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
> 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
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
> 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
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
Manolis Kiagias wrote:
> yong...@freebsd.org wrote:
>
>> Synopsis: [bfe] Kernel Panic acquiring IP address from DHCP server on newly
>> enabled netcard
>>
>> State-Changed-From-To: open->feedback
>> State-Changed-By: yongari
>> State-Changed-When: Thu Jan 15 02:06:33 UTC 2009
>> State-Changed-W
Old Synopsis: if_re doesn't always attach to Realtek 8111C
New Synopsis: [re] if_re doesn't always attach to Realtek 8111C
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Jan 15 21:38:20 UTC 2009
Responsible-Changed-Why:
Over to
Hi,
from my point of view this issue can be closed.
TCP write/write/read sequences are bad on any operating system, it's just that
other OS are a little bit smarter. -- I think Jon Nagle has had a proposal to
fix/remove this unconditional delay, but I don't know if it has been
implemented.
F
This is a known issue and it's easily reproducible using the
netperf tool.
I am working on a permanent solution.
In the meantime you can use the following workaround, as suggested
by Kip:
route add -host (if-ip) -iface lo0
-- Qing
> -Original Message-
> From: owner-freebsd-cu
Synopsis: [re] if_re doesn't always attach to Realtek 8111C
State-Changed-From-To: open->feedback
State-Changed-By: yongari
State-Changed-When: Fri Jan 16 02:14:46 UTC 2009
State-Changed-Why:
I believe HEAD has fix for the issue. Would you try re(4) in HEAD?
To get the re(4) of HEAD you may have
Jost Boekemeier wrote:
Hi,
from my point of view this issue can be closed.
TCP write/write/read sequences are bad on any operating system, it's just that
other OS are a little bit smarter. -- I think Jon Nagle has had a proposal to
fix/remove this unconditional delay, but I don't know if it
On Thu, January 15, 2009 6:46 pm, Li, Qing wrote:
> This is a known issue and it's easily reproducible using the
> netperf tool.
>
> I am working on a permanent solution.
>
> In the meantime you can use the following workaround, as suggested
> by Kip:
>
> route add -host (if-ip) -iface lo0
>
Hi Larry,
This empty arp output issue appears to be a recent breakage
on amd64. The world+kernel built on Jan. 12 out of my last
commit for i386 (r187094) appears to be fine. The problem
is being investigated ...
-- Qing
-Original Message-
From: Larry Rosenman [mailto:l...@lerctr.org]
29 matches
Mail list logo
