Re: howto determine network device unit number? device.hints?

[H.fazaeli]

   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
   ifconfig fastEthernet0 192.168.1.0/24
   Yony Yossef wrote:

 

  

-Original Message-
From: H.fazaeli [[1]mailto:faza...@sepehrs.com]
Sent: Wednesday, January 14, 2009 6:24 PM
To: Yony Yossef
Cc: [2]freebsd-...@freebsd.org; [3]freebsd-questi...@freebsd.org;
Eitan Shefi; Oleg Kats; Liran 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 ifconfig you suggested and the effect
it will cause.
Can you please explain it?
Yony



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 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=0x636815b3


rev=0xa0 hdr=0x00
mtn...@pci0:16:0:0: class=0x02 card=0x001715b3


chip=0x636815b3


rev=0xa0 hdr=0x00

So I've tried:

hint.mtnic.0.at="pci0:16"
hint.mtnic.1.at="pci0:19"

but it doesn't work. They keep switching arbitrarily.
I'm using FreeBSD 7.0.

Thanks
Yony
___
[4]freebsd-questi...@freebsd.org mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to


[6]"freebsd-questions-unsubscr...@freebsd.org"





--


Best regards.

Hooman Fazaeli [7]
Sepehr S. T. Co. Ltd.

Web: [8]http://www.sepehrs.com
Tel: (9821)88975701-2
Fax: (9821)88983352







___
[9]freebsd-...@freebsd.org mailing list
[10]http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [11]"freebsd-net-unsubscr...@freebsd.org"




--


Best regards.

Hooman Fazaeli [12]
Sepehr S. T. Co. Ltd.

Web: [13]http://www.sepehrs.com
Tel: (9821)88975701-2
Fax: (9821)88983352

References

   1. mailto:faza...@sepehrs.com
   2. mailto:freebsd-net@freebsd.org
   3. mailto:freebsd-questi...@freebsd.org
   4. mailto:freebsd-questi...@freebsd.org
   5. http://lists.freebsd.org/mailman/listinfo/freebsd-questions
   6. mailto:freebsd-questions-unsubscr...@freebsd.org
   7. mailto:h...@sepehrs.com
   8. http://www.sepehrs.com/
   9. mailto:freebsd-net@freebsd.org
  10. http://lists.freebsd.org/mailman/listinfo/freebsd-net
  11. mailto:freebsd-net-unsubscr...@freebsd.org
  12. mailto:h...@sepehrs.com
  13. http://www.sepehrs.com/
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: howto determine network device unit number? device.hints?

[Yony Yossef]

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 how come the unit number is given an arbitrary value? Is there a good
reason for that?
 
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 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 
ifconfig fastEthernet0 192.168.1.0/24


Yony Yossef wrote: 

 



  

-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 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 ifconfig you suggested and the effect

it will cause.

Can you please explain it?

Yony



  

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 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=0x636815b3



rev=0xa0 hdr=0x00

mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 

  

chip=0x636815b3



rev=0xa0 hdr=0x00



So I've tried:



hint.mtnic.0.at="pci0:16"

hint.mtnic.1.at="pci0:19"



but it doesn't work. They keep switching arbitrarily.

I'm using FreeBSD 7.0.



Thanks

Yony

___

freebsd-questi...@freebsd.org mailing list 

http://lists.freebsd.org/mailman/listinfo/freebsd-questions

To unsubscribe, send any mail to 

  

"freebsd-questions-unsubscr...@freebsd.org"
 



  

  

-- 





Best regards.



Hooman Fazaeli   

Sepehr S. T. Co. Ltd.



Web: http://www.sepehrs.com

Tel: (9821)88975701-2

Fax: (9821)88983352















___

freebsd-net@freebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-net

To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
 





  


-- 





Best regards.



Hooman Fazaeli   

Sepehr S. T. Co. Ltd.



Web: http://www.sepehrs.com

Tel: (9821)88975701-2

Fax: (9821)88983352







___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Julian Elischer]

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 flexible.


It seems quite wrong, don't you agree?
 
And how come the unit number is given an arbitrary value? Is there a good

reason for that?


device discovery depends on what slot you put the card into.
so if you move it, it's number may change.

also, how do you identify the particular card you want to have a 
particular unit number? considering it may move (and for example

USB network interfaces WILL move if you add a keyboard or any
other device..

also to do as you want would take 2 passes.
first one to find the numbers needed and another to do what'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 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 
ifconfig fastEthernet0 192.168.1.0/24



Yony Yossef wrote: 

 




  


-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 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 ifconfig you suggested and the effect

it will cause.

Can you please explain it?

Yony



  


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 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=0x636815b3




rev=0xa0 hdr=0x00

mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 

  


chip=0x636815b3




rev=0xa0 hdr=0x00



So I've tried:



hint.mtnic.0.at="pci0:16"

hint.mtnic.1.at="pci0:19"



but it doesn't work. They keep switching arbitrarily.

I'm using FreeBSD 7.0.



Thanks

Yony

___

freebsd-questi...@freebsd.org mailing list 


http://lists.freebsd.org/mailman/listinfo/freebsd-questions

To unsubscribe, send any mail to 

  


"freebsd-questions-unsubscr...@freebsd.org"
 



  

  



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/89876: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx

[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 available for download anymore, so we're unable to
check that issue. Can you please give us the patch so a maintainer
can take a look?


Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: vwe
Responsible-Changed-When: Wed Jan 14 22:41:48 UTC 2009
Responsible-Changed-Why: 


Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=89876

  
Unfortunately it's been a while since I had the need to run those two 
txp cards I have, and eventually have abandoned the idea of using them 
at all. I do not keep the patch, but as long as i remember the main 
thing in it was copying the newest firmware available from the linux's 
txp (or whatever it was named) driver.


I do still keep those cards, and can test them under the latest FBSD and 
report back later today on the status of the problem.


Kind regards,
Doichin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: howto determine network device unit number? device.hints?

[Yony Yossef]

> 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 flexible.
> 
> > It seems quite wrong, don't you agree?
> >  
> > And how come the unit number is given an arbitrary value? 
> Is there a 
> > good reason for that?
> 
> device discovery depends on what slot you put the card into.
> so if you move it, it's number may change.
> 
> also, how do you identify the particular card you want to 
> have a particular unit number? considering it may move (and 
> for example USB network interfaces WILL move if you add a 
> keyboard or any other device..
> 
> also to do as you want would take 2 passes.
> first one to find the numbers needed and another to do what's left.
> 

Julian,
I'm not talking about the case where I'm physically switching card locations
on the PCI bus.
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.

I still don't get the reason for this arbitrarily assigned unit numbers and
what is the common solution for it. Except post load rename 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.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 assign cisco-like names to you interfaces:
> > 
> > ifconfig xl0 name fastEthernet0
> > ifconfig em0 name gigaEthernet0
> > ifconfig fastEthernet0 192.168.1.0/24
> > 
> > 
> > Yony Yossef wrote: 
> > 
> >  
> > 
> > 
> > 
> >   
> > 
> > -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 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 ifconfig you 
> suggested and the 
> > effect
> > 
> > it will cause.
> > 
> > Can you please explain it?
> > 
> > Yony
> > 
> > 
> > 
> >   
> > 
> > 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 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=0x636815b3
> > 
> > 
> > 
> > rev=0xa0 hdr=0x00
> > 
> > mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 
> > 
> >   
> > 
> > chip=0x636815b3
> > 
> > 
> > 
> > rev=0xa0 hdr=0x00
> > 
> > 
> > 
> > So I've tried:
> > 
> > 
> > 
> > hint.mtnic.0.at="pci0:16"
> > 
> > hint.mtnic.1.at="pci0:19"
> > 
> > 
> > 
> > but it doesn't work. They keep switching arbitrarily.
> > 
> > I'm using FreeBSD 7.0.
> > 
> > 
> > 
> > Thanks
> > 
> > Yony
> > 
> > ___
> > 
> > freebsd-questi...@freebsd.org mailing list
> > 
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > 
> > To unsubscribe, send any mail to
> > 
> >   
> > 
> > "freebsd-questions-unsubscr...@freebsd.org"
> > 
> > 
> > 
> > 
> >   
> > 
> >   
> > 
> 
> 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[H.fazaeli]

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 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.
  

I do not quite understand your requirement. Can you please explain?
Do you need a script that works on multiple machines with different 
hardwares?



It seems quite wrong, don't you agree?
 
And how come the unit number is given an arbitrary value? Is there a good

reason for that?
 
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 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 
ifconfig fastEthernet0 192.168.1.0/24



Yony Yossef wrote: 

 




  


-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 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 ifconfig you suggested and the effect

it will cause.

Can you please explain it?

Yony



  


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 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=0x636815b3




rev=0xa0 hdr=0x00

mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 

  


chip=0x636815b3




rev=0xa0 hdr=0x00



So I've tried:



hint.mtnic.0.at="pci0:16"

hint.mtnic.1.at="pci0:19"



but it doesn't work. They keep switching arbitrarily.

I'm using FreeBSD 7.0.



Thanks

Yony

___

freebsd-questi...@freebsd.org mailing list 


http://lists.freebsd.org/mailman/listinfo/freebsd-questions

To unsubscribe, send any mail to 

  


"freebsd-questions-unsubscr...@freebsd.org"
 



  

  

  


--


Best regards.

Hooman Fazaeli 
Sepehr S. T. Co. Ltd.

Web: http://www.sepehrs.com
Tel: (9821)88975701-2
Fax: (9821)88983352




___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: howto determine network device unit number? device.hints?

[Yony Yossef]

> 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.

>From the beginning:

I have a FreeBSD7 machine with two network cards, both carry the same device
name "mtnic".
My driver is a kernel module loaded manualy using kldload.
Upon load, the driver registers the net device by the name "mtnic", that is what you see in ifconfig.

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).
Therefore, IP assignment to mtnic0 by /etc/rc.conf may assign an interface
with an IP belongs to another subnet, since rc.conf is not changing.

Of course I can keep my own MAC-to-interface mapping and rename the
interfaces after I load the driver.
It doesn't sound like a reasonable solution though.

Plus, I still don't understand why the unit number should change at all,
instead of being determined according to the card PCI location or some other
constant.

Yony


> 
> > 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.
> >   
> I do not quite understand your requirement. Can you please explain?
> Do you need a script that works on multiple machines with 
> different hardwares?
> 
> > It seems quite wrong, don't you agree?
> >  
> > And how come the unit number is given an arbitrary value? 
> Is there a 
> > good reason for that?
> >  
> > Yony


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Eygene Ryabinkin]

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 your
device_method_t structure and the corresponding identify, probe, attach
and detach routines?  You're setting the unit numbers via
'if_initname(ifp, device_get_name(dev), device_get_unit(dev))' or alike?

> I still don't get the reason for this arbitrarily assigned unit numbers and
> what is the common solution for it. Except post load rename of the
> interfaces.

I was under impression that the unit number are coming from the parent
busses and they should be stable, at least for the case when the parent
bus driver isn't unloaded (and for PCI it should be the case).  So,
either the driver sets device unit names weirdly or you hit some bug.
-- 
Eygene
 ____   _.--.   #
 \`.|\.....-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' ` ,   __.--'  #  to read the on-line manual
 )/' _/ \   `-_,   /#  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
 _.-'_./   {_.'   ; /   #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Olivier Nicole]

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, unless I play and swap the hardware inside
the machine).

And that is the normal behaviour. Of course at each boot the interface
em0 remains interface em0 and ithe interface em1 remains interface
em1, else it would be a headache.

> Plus, I still don't understand why the unit number should change at all,
> instead of being determined according to the card PCI location or some other
> constant.

Not only it should not change, but you are the first person I ever see
mentioning that it change at each boot.

Bests,

Olivier
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Mykola Dzham]

 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
>ifconfig em0 name gigaEthernet0
>ifconfig fastEthernet0 192.168.1.0/24
>Yony Yossef wrote:

Interface renaming is complex when you use ng_ether: if ng_ether loaded
before renaming, then ng_ether node name remain unchanged after
ifconfig ... name

-- 
Mykola Dzham, LEFT-(UANIC|RIPE)
JID: lev...@jabber.net.ua
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: howto determine network device unit number? device.hints?

[Yony Yossef]

 

> -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: 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 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 your device_method_t structure and the corresponding 
> identify, probe, attach and detach routines?  You're setting 
> the unit numbers via 'if_initname(ifp, device_get_name(dev), 
> device_get_unit(dev))' or alike?

My device has 2 ports, therefore my if_initname is that:

if_initname(dev, device_get_name(mdev->pdev), 
port + 2 * device_get_unit(mdev->pdev));


> > I still don't get the reason for this arbitrarily assigned unit 
> > numbers and what is the common solution for it. Except post load 
> > rename of the interfaces.
> 
> I was under impression that the unit number are coming from 
> the parent busses and they should be stable, at least for the 
> case when the parent bus driver isn't unloaded (and for PCI 
> it should be the case).  So, either the driver sets device 
> unit names weirdly or you hit some bug.
> --
> Eygene

This is what I captured the last time it happened. 

# pciconf -l | grep mtnic
mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00
mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00

# kldunload if_mtnic
# kldload if_mtnic

# pciconf -l | grep mtnic
mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00
mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: setfib+pf

[Dimitar Vasilev]

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 why ipfw has fib support :-)
>>
>>
>>possibly Max Lair may know both..
>>
>> Hi Julian,
>> Could you sched some light on the ipfw and setfib as an example. Seems the
>> person you're referring to is busy. The rest I will figure out on my own. If
>> there are results - I will share back.
>> Thanks,
>> Dimitar
>>
>
>
> well, you need to tell me a little more about what you want to do.

Thanks - here is the schema:

Lan1(browsing clients)
 |
-- 
|  WRT   |-|   ALIX |---Lan2 (DMZ stuff, splitted
into various networks, vlans,etc)
-- ---
| |
---
| Uplink|   | Uplink |
   


I will have two uplinks and would like to failover uplink of clients from
lan 1 and lan 2 depending on which link is up, keeping Lan2 accessible via
the both uplinks, using something like tunnel1.foobar and tunnel2.foobar, as
well as keeping LAN2 isolated from the clients via vlan and firewall rules
allowing ssh mostly. As will have various private networks,tunnels,etc and
no BGP, I would like to take advantage of setfib. Thanks.
Best regards,
Dimitar Vassilev
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Eygene Ryabinkin]

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, device_get_name(dev), 
> > device_get_unit(dev))' or alike?
> 
> My device has 2 ports, therefore my if_initname is that:
> 
> if_initname(dev, device_get_name(mdev->pdev), 
> port + 2 * device_get_unit(mdev->pdev));

So, you totally have four network interfaces -- two for each PCI
device?

> This is what I captured the last time it happened. 
> 
> # pciconf -l | grep mtnic
> mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
> rev=0xa0 hdr=0x00
> mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
> rev=0xa0 hdr=0x00
> 
> # kldunload if_mtnic
> # kldload if_mtnic
> 
> # pciconf -l | grep mtnic
> mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
> rev=0xa0 hdr=0x00
> mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
> rev=0xa0 hdr=0x00

Could you do the following:

1. Boot with verbose kernel mode (push '5' on the boot screen).
2. Kldload your module and provide the full list of kernel messages
   you will see after this action.
3. Kldunload and again, provide all messages kernel will print
   for this.
4. Kldload again and supply all messages for the last time.

This will show the PCI enumeration sequence and probe order for your
driver pci device units.  This might shed some light on the problem.

Thanks.
-- 
Eygene
 ____   _.--.   #
 \`.|\.....-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' ` ,   __.--'  #  to read the on-line manual
 )/' _/ \   `-_,   /#  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
 _.-'_./   {_.'   ; /   #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Bruce M. Simpson]

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, don't you agree?
 
And how come the unit number is given an arbitrary value? Is there a good

reason for that?
  


Normally the PCI probe runs in the opposite direction from that of 
Linux. It's largely to do with how the NEWBUS code walks the PCI bus. 
From a systems management point of view, yeah, it's irritating, however 
it would probably take more effort (i.e. kernel code) to try to patch it 
to work differently, and not everyone has free time to sit down and 
patch the kernel.


That and (unlike Solaris) there is no *direct* mapping between the 
card's driver number on the bus and its network driver number.


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?



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/89876: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx

[NetOne - Doichin Dokov]

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 available for download anymore, so we're unable to
check that issue. Can you please give us the patch so a maintainer
can take a look?


Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: vwe
Responsible-Changed-When: Wed Jan 14 22:41:48 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=89876

  
Unfortunately it's been a while since I had the need to run those two 
txp cards I have, and eventually have abandoned the idea of using them 
at all. I do not keep the patch, but as long as i remember the main 
thing in it was copying the newest firmware available from the linux's 
txp (or whatever it was named) driver.


I do still keep those cards, and can test them under the latest FBSD 
and report back later today on the status of the problem.


Kind regards,
Doichin

I've now placed one of the cards I have in a FreeBSD 7.0 machine - it's 
still not recognized (booted) properly.

Here's the boot log:
...
Jan 15 15:08:41 test kernel: txp0: <3Com 3cR990B-TXM Etherlink with 3XP 
Processor> port 0x2080-0x20ff mem 0x4200-0x427f irq 11 at device 
14.0 on pci0

Jan 15 15:08:41 test kernel: txp0: not waiting for boot
Jan 15 15:08:41 test kernel: device_attach: txp0 attach returned -1
...

Here's the related pciconf:
t...@pci0:0:14:0:   class=0x02 card=0x100010b7 chip=0x990410b7 
rev=0x03 hdr=0x00

   vendor = '3COM Corp, Networking Division'
   device = '3CR990B-TM-X Etherlink 10/100 with 3XP Processor'
   class  = network
   subclass   = ethernet

If you're interested in fixing this problem, you might have a look at 
the driver included in the Linux kernel - it works fine with this card.
Unfortunately I no longer need to use those cards, and can afford to 
spend any time on this issue, what I could help is with testing. I could 
also provide an SSH access to a machine with this card installed, if 
this would be of any help resolving the issue.


Kind regards,
Doichin

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Bruce M. Simpson]

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 your system, then you really need to provide more 
data about your hardware, i.e. motherboard, BIOS, vendor information 
etc. as others point out.


Based on the data you've provided about the issue to date, my best guess 
is that something in the above is different on your system (which is why 
I mentioned IDSEL lines -- the mechanism PCI uses to actually assign bus 
numbers electrically).


Normally the behaviour of FreeBSD's bus probes is well known -- nexus is 
walked for child buses, then these buses are plumbed into NEWBUS, e.g. 
cpu0...cpuN on nexus itself, PCI buses, and PCI subordinate buses in 
that order.


* You mention you don't encounter the issue with Linux, but you may 
already be aware that udev can tie driver instance number(s) to specific 
MAC addresses, although this process isn't fully automatic and any given 
distro may or may not create the persistent udev rules on a first run -- 
so this is comparing apples with oranges.


* [PCI-Express is a special case though, and I've had to sit down and do 
some work with commercial clients to make sure their appliance was able 
to detect devices being in particular slot numbers. Again, though, it's 
just as subject to the PCI enumeration order further up on the bus 
hierarchy as non-PCI-Express drivers.]


So your issue may not be a simple matter of "this seems wrong, this 
doesn't work", though I am sorry to hear it isn't working for you right now.


There are a lot of dynamic factors in the overall picture of the system, 
and what seems to work as expected for many users, may not be working 
for you, and we really need basic hardware information, when folk see 
things like this happening, for any volunteer(s) out there to come up 
with the right solution, let alone the true picture of what's actually 
going on in your specific case.


thanks
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Eygene Ryabinkin]

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 you really need to provide more 
> data about your hardware, i.e. motherboard, BIOS, vendor information 
> etc. as others point out.

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 amount of PCI hotplug support in FreeBSD), no physical PCI devices
get added or removed from the PCI child tree.  It looks like that
something goes wrong during the PCI tree reprobe on the driver module
loading.

Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c will
invoke device_get_children() to get the list of the attached devices,
and for PCI case the list should be static.

Here is what I get for the 'kldload if_em' with verbose boot:
-
pci0: driver added
found-> vendor=0x8086, dev=0x283e, revid=0x02
domain=0, bus=0, slot=31, func=3
class=0c-05-00, hdrtype=0x00, mfdev=0
cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=c, irq=18
pci0:0:31:3: reprobing on driver added
pci1: driver added
pci2: driver added
pci3: driver added
pci4: driver added
pci5: driver added
found-> vendor=0x8086, dev=0x1010, revid=0x01
domain=0, bus=5, slot=3, func=0
class=02-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x0017, statreg=0x0230, cachelnsz=8 (dwords)
lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns)
intpin=a, irq=16
powerspec 2  supports D0 D3  current D0
MSI supports 1 message, 64 bit
pci0:5:3:0: reprobing on driver added
em0:  port 0xb880-0xb8bf mem 
0xff7c-0xff7d irq 16 at device 3.0 on pci5
pcib5: em0 requested memory range 0xff7c-0xff7d: good
pcib5: em0 requested I/O range 0xb880-0xb8bf: in range
em0: [FILTER]
em0: bpf attached
em0: Ethernet address: NN:NN:NN:NN:NN:NN
found-> vendor=0x8086, dev=0x1010, revid=0x01
domain=0, bus=5, slot=3, func=1
class=02-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x0017, statreg=0x0230, cachelnsz=8 (dwords)
lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns)
intpin=b, irq=17
powerspec 2  supports D0 D3  current D0
MSI supports 1 message, 64 bit
pci0:5:3:1: reprobing on driver added
em1:  port 0xbc00-0xbc3f mem 
0xff7e-0xff7f irq 17 at device 3.1 on pci5
pcib5: em1 requested memory range 0xff7e-0xff7f: good
pcib5: em1 requested I/O range 0xbc00-0xbc3f: in range
em1: [FILTER]
em1: bpf attached
em1: Ethernet address: NN:NN:NN:NN:NN:NN
-
And this message is stable across repeated kldunload/kldload.

I guess that when Yony will enable verbose boot and will show us kernel
messages from two successive kldunload/kldload sequences, we will get
some additional information about what's going on.
-- 
Eygene
 ____   _.--.   #
 \`.|\.....-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' ` ,   __.--'  #  to read the on-line manual
 )/' _/ \   `-_,   /#  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
 _.-'_./   {_.'   ; /   #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Yony Yossef]

> 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, device_get_name(dev),
> device_get_unit(dev))'
> > > or alike?
> >
> > My device has 2 ports, therefore my if_initname is that:
> >
> > if_initname(dev, device_get_name(mdev->pdev),
> > port + 2 * device_get_unit(mdev->pdev));
>
> So, you totally have four network interfaces -- two for each
> PCI device?
>
> > This is what I captured the last time it happened.
> >
> > # pciconf -l | grep mtnic
> > mtn...@pci0:19:0:0: class=0x02 card=0x001715b3
> chip=0x636815b3
> > rev=0xa0 hdr=0x00
> > mtn...@pci0:16:0:0: class=0x02 card=0x001715b3
> chip=0x636815b3
> > rev=0xa0 hdr=0x00
> >
> > # kldunload if_mtnic
> > # kldload if_mtnic
> >
> > # pciconf -l | grep mtnic
> > mtn...@pci0:19:0:0: class=0x02 card=0x001715b3
> chip=0x636815b3
> > rev=0xa0 hdr=0x00
> > mtn...@pci0:16:0:0: class=0x02 card=0x001715b3
> chip=0x636815b3
> > rev=0xa0 hdr=0x00
>
> Could you do the following:
>
> 1. Boot with verbose kernel mode (push '5' on the boot screen).
> 2. Kldload your module and provide the full list of kernel messages
>you will see after this action.
> 3. Kldunload and again, provide all messages kernel will print
>for this.
> 4. Kldload again and supply all messages for the last time.
>
> This will show the PCI enumeration sequence and probe order
> for your driver pci device units.  This might shed some light
> on the problem.
>

This is the flow I've done, you can see the swapping happened again:

[r...@sw247 ~]# pciconf -l | grep mtnic
mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00
mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00
[r...@sw247 ~]# kldunload if_mtnic
[r...@sw247 ~]# kldload if_mtnic
[r...@sw247 ~]# pciconf -l | grep mtnic
mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00
mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00

/var/log/messages during this flow (the brackets are my addition ofcourse):

[kldunload if_mtnic]

Jan 15 19:27:46 sw247 kernel: mtnic0: Destroying netdev on port:0
Jan 15 19:27:46 sw247 kernel: mtnic0: Destroying netdev on port:1
Jan 15 19:27:46 sw247 kernel: mtnic0: Reseting device...
Jan 15 19:27:46 sw247 kernel: mtnic0: Reset complete.
Jan 15 19:27:46 sw247 kernel: mtnic0: detached
Jan 15 19:27:46 sw247 kernel: mtnic1: Destroying netdev on port:0
Jan 15 19:27:46 sw247 kernel: mtnic1: Destroying netdev on port:1
Jan 15 19:27:47 sw247 kernel: mtnic1: Reseting device...
Jan 15 19:27:47 sw247 kernel: mtnic1: Reset complete.
Jan 15 19:27:47 sw247 kernel: mtnic1: detached

[kldload if_mtnic]

Jan 15 19:28:04 sw247 kernel: pci0: driver added
Jan 15 19:28:04 sw247 kernel: found->   vendor=0x0e11, dev=0xb203, revid=0x03
Jan 15 19:28:04 sw247 kernel: domain=0, bus=0, slot=4, func=0
Jan 15 19:28:04 sw247 kernel: class=08-80-00, hdrtype=0x00, mfdev=1
Jan 15 19:28:04 sw247 kernel: cmdreg=0x0103, statreg=0x0290,
cachelnsz=0 (dwords)
Jan 15 19:28:04 sw247 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0
ns), maxlat=0x00 (0 ns)
Jan 15 19:28:04 sw247 kernel: intpin=a, irq=25
Jan 15 19:28:04 sw247 kernel: powerspec 3  supports D0 D3  current D0
Jan 15 19:28:04 sw247 kernel: pci0:0:4:0: reprobing on driver added
Jan 15 19:28:04 sw247 kernel: found->   vendor=0x0e11, dev=0xb204, revid=0x03
Jan 15 19:28:04 sw247 kernel: domain=0, bus=0, slot=4, func=2
Jan 15 19:28:04 sw247 kernel: class=08-80-00, hdrtype=0x00, mfdev=1
Jan 15 19:28:04 sw247 kernel: cmdreg=0x0117, statreg=0x0290,
cachelnsz=16 (dwords)
Jan 15 19:28:04 sw247 kernel: lattimer=0x40 (1920 ns), mingnt=0x00 (0
ns), maxlat=0x00 (0 ns)
Jan 15 19:28:04 sw247 kernel: intpin=b, irq=26
Jan 15 19:28:04 sw247 kernel: powerspec 3  supports D0 D3  current D0
Jan 15 19:28:04 sw247 kernel: pci0:0:4:2: reprobing on driver added
Jan 15 19:28:04 sw247 kernel: found->   vendor=0x103c, dev=0x3302, revid=0x00
Jan 15 19:28:04 sw247 kernel: domain=0, bus=0, slot=4, func=6
Jan 15 19:28:04 sw247 kernel: class=0c-07-01, hdrtype=0x00, mfdev=1
Jan 15 19:28:04 sw247 kernel: cmdreg=0x0002, statreg=0x0290,
cachelnsz=0 (dwords)
Jan 15 19:28:04 sw247 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0
ns), maxlat=0x00 (0 ns)
Jan 15 19:28:04 sw247 kernel: intpin=a, irq=25
Jan 15 19:28:04 sw247 kernel: powerspec 3  supports D0 D3  current D0
Jan 15 19:28:04 sw247 kernel: pci0:0:4:6: reprobing on driver added
Jan 15 19:28:04 sw247 kernel: pci1: driver added
Jan 15 19:28:04 sw247 kernel: pci2: driver added
Jan 15 19:28:04 sw247 kernel: pci8: driver added
Jan 15 19:28:04 sw247 kernel: pci9: driver added
Jan 15 19:28:04 sw247 kernel: pci10: driver added
Jan 15 19:28:04 sw247 kernel:

Re: howto determine network device unit number? device.hints?

[Bruce M. Simpson]

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 amount of PCI hotplug support in FreeBSD), no physical PCI devices
get added or removed from the PCI child tree.  It looks like that
something goes wrong during the PCI tree reprobe on the driver module
loading.
  


BTW: Thanks for looking further at the software layer first.

VIM is a wee bit easier to use than a bus analyzer.

Most motherboards don't support PCI geographical addressing, so... I 
wager it's the network driver code which may be the source of the 
problem, based on your analysis!


If this code just doing a blind bump of an instance count and using that 
as a "unit number"... well, that's OK and expected for software virtual 
devices, but is counter-intuitive for something like hardware.


But I don't have any mtnic source, so this is pure speculation on my part.


Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c will
invoke device_get_children() to get the list of the attached devices,
and for PCI case the list should be static.
  


Yup, that's right.


I guess that when Yony will enable verbose boot and will show us kernel
messages from two successive kldunload/kldload sequences, we will get
some additional information about what's going on.
  


Hopefully he will chime in...

[bms does some google searching *before* he thinks about throwing his 
toys out of the pram at the Orignal.Poster.]


ding :-) [a light bulb above bms' head]

So... Yony. you're writing a driver.
Maybe there's a bug in it?
That's cool, dude.
Hope it's a nice card and you plan on sharing the sweets with the rest 
of the class. ;-)


But seriously, please mention that you are writing a driver in general 
questions you might ask about the whole system, otherwise, FreeBSD 
volunteers will run around going "Is core code broken?" and that's not 
so good for community stress levels as a whole.


with lemonade,
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Yony Yossef]

> 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 amount of PCI hotplug support in FreeBSD), no
> > physical PCI devices get added or removed from the PCI
> child tree.  It
> > looks like that something goes wrong during the PCI tree reprobe on
> > the driver module loading.
> >
>
> BTW: Thanks for looking further at the software layer first.
>
> VIM is a wee bit easier to use than a bus analyzer.
>
> Most motherboards don't support PCI geographical addressing,
> so... I wager it's the network driver code which may be the
> source of the problem, based on your analysis!
>
> If this code just doing a blind bump of an instance count and
> using that as a "unit number"... well, that's OK and expected
> for software virtual devices, but is counter-intuitive for
> something like hardware.
>
> But I don't have any mtnic source, so this is pure
> speculation on my part.
>
> > Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c
> > will invoke device_get_children() to get the list of the attached
> > devices, and for PCI case the list should be static.
> >
>
> Yup, that's right.
>
> > I guess that when Yony will enable verbose boot and will show us
> > kernel messages from two successive kldunload/kldload sequences, we
> > will get some additional information about what's going on.
> >
>
> Hopefully he will chime in...
>
> [bms does some google searching *before* he thinks about
> throwing his toys out of the pram at the Orignal.Poster.]
>
> ding :-) [a light bulb above bms' head]
>
> So... Yony. you're writing a driver.
> Maybe there's a bug in it?
> That's cool, dude.
> Hope it's a nice card and you plan on sharing the sweets with
> the rest of the class. ;-)
>
> But seriously, please mention that you are writing a driver
> in general questions you might ask about the whole system,
> otherwise, FreeBSD volunteers will run around going "Is core
> code broken?" and that's not so good for community stress
> levels as a whole.
>
> with lemonade,
> BMS

Sorry for risking the whole community with a massive heart attack Bruce :)
Yes, I am writing a driver and yes, it still has a bug or two I guess..
About sharing it with the rest of the class, that's something I wanted
to ask you guys:  what's the procedure for a 10GigE driver to apply
for the FreeBSD kernel?

Mellanox has started porting it's products to FreeBSD about a year
ago, hoping to see our 10GigE and InfiniBand drivers inbox next year.

Yony
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: howto determine network device unit number? device.hints?

[Brooks Davis]

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
> > believe to
> > > be present, because no physical cards are touched and there is
> > > actually a small amount of PCI hotplug support in FreeBSD), no
> > > physical PCI devices get added or removed from the PCI
> > child tree.  It
> > > looks like that something goes wrong during the PCI tree reprobe on
> > > the driver module loading.
> > >
> >
> > BTW: Thanks for looking further at the software layer first.
> >
> > VIM is a wee bit easier to use than a bus analyzer.
> >
> > Most motherboards don't support PCI geographical addressing,
> > so... I wager it's the network driver code which may be the
> > source of the problem, based on your analysis!
> >
> > If this code just doing a blind bump of an instance count and
> > using that as a "unit number"... well, that's OK and expected
> > for software virtual devices, but is counter-intuitive for
> > something like hardware.
> >
> > But I don't have any mtnic source, so this is pure
> > speculation on my part.
> >
> > > Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c
> > > will invoke device_get_children() to get the list of the attached
> > > devices, and for PCI case the list should be static.
> > >
> >
> > Yup, that's right.
> >
> > > I guess that when Yony will enable verbose boot and will show us
> > > kernel messages from two successive kldunload/kldload sequences, we
> > > will get some additional information about what's going on.
> > >
> >
> > Hopefully he will chime in...
> >
> > [bms does some google searching *before* he thinks about
> > throwing his toys out of the pram at the Orignal.Poster.]
> >
> > ding :-) [a light bulb above bms' head]
> >
> > So... Yony. you're writing a driver.
> > Maybe there's a bug in it?
> > That's cool, dude.
> > Hope it's a nice card and you plan on sharing the sweets with
> > the rest of the class. ;-)
> >
> > But seriously, please mention that you are writing a driver
> > in general questions you might ask about the whole system,
> > otherwise, FreeBSD volunteers will run around going "Is core
> > code broken?" and that's not so good for community stress
> > levels as a whole.
> >
> > with lemonade,
> > BMS
> 
> Sorry for risking the whole community with a massive heart attack Bruce :)
> Yes, I am writing a driver and yes, it still has a bug or two I guess..
> About sharing it with the rest of the class, that's something I wanted
> to ask you guys:  what's the procedure for a 10GigE driver to apply
> for the FreeBSD kernel?

Pretty much just get it working, make sure it's licensed under a BSD,
MIT, or ISC license (ideally, others are possible, but require more
approval), and then find someone to review and commit it or sponsor the
maintainer for a commit bit.  

> Mellanox has started porting it's products to FreeBSD about a year
> ago, hoping to see our 10GigE and InfiniBand drivers inbox next year.

Excellent.

-- Brooks

> 
> Yony
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 


pgpoQADbsZs9S.pgp
Description: PGP signature

Re: kern/118897: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard

[Manolis Kiagias]

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-Why: 
>> I think all known bugs in bfe(4) were fixed.
>> Can you still reproduce the issue on 6.4-RELEASE or 7.1-RELEASE?
>>
>>
>> Responsible-Changed-From-To: freebsd-net->yongari
>> Responsible-Changed-By: yongari
>> Responsible-Changed-When: Thu Jan 15 02:06:33 UTC 2009
>> Responsible-Changed-Why: 
>> Grab.
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=118897
>>
>>
>>   
>> 
> I'll give it a try this afternoon and let you know.
>
>   
Continuing with this, I just realized that the machine that replaced the
one exhibiting this, does not have a bfe(4) but a bge(4).
I no longer have access to any machine with bfe.  FWIW, bge(4) works
fine performing the same steps.
Please feel free to close this report.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: misc/130586: [re] if_re doesn't always attach to Realtek 8111C

[linimon]

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 maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=130586
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte

[Jost Boekemeier]

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.

Furthermore this problem has been fixed on application level. And I think 
Patrick van Staveren maintains a FreeBSD port which uses unix domain- instead 
of TCP socket communication.


Regards,
Jost Bökemeier




___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: Bacula: VERY SLOW on SAME host

[Li, Qing]

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-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Kip Macy
> Sent: Wednesday, January 14, 2009 8:47 PM
> To: Larry Rosenman
> Cc: freebsd-curr...@freebsd.org
> Subject: Re: Bacula: VERY SLOW on SAME host
> 
> arpv2 - add an localhost interface route as a workaround
> 
> -Kip
> 
> On Wed, Jan 14, 2009 at 8:35 PM, Larry Rosenman 
wrote:
> > Greetings,
> >Somethings changed (Around the 1st of the year?) where my bacula
> jobs
> > take FOREVER to backup on the same host
> > with the StorageDaemon and Director.  If I change it to use
127.0.0.1
> > instead of the address on the em card, it's fine.
> >
> > If I use the address on the em nics, it's like 4kb/sec as opposed to
> > multi-megabytes/sec.
> >
> > I'm looking for how to find what broke.
> >
> > Other networking to the host is fine, but this is TCP within the
same
> host,
> > but using the IP address on the em interface.
> >
> > I see the TCP Send-Q fill up, and it's extremely slow.
> >
> > What data do you need to help debug this?
> >
> >
> >
> > --
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
> > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
> > ___
> > freebsd-curr...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-
> unsubscr...@freebsd.org"
> >
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-
> unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/130586: [re] if_re doesn't always attach to Realtek 8111C

[yongari]

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 to get following files
from HEAD and rebuild kernel.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c


Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Fri Jan 16 02:14:46 UTC 2009
Responsible-Changed-Why: 
Grab.

http://www.freebsd.org/cgi/query-pr.cgi?pr=130586
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte

[Tom Judge]

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 has been 
implemented.

Furthermore this problem has been fixed on application level. And I think 
Patrick van Staveren maintains a FreeBSD port which uses unix domain- instead 
of TCP socket communication.


Regards,
Jost Bökemeier
  

Hi Jost,

I'm not sure if Patrick (I work with him) has a port using unix domain sockets 
in production.  I do know however that patches to PHP (That add the no delay 
socket option to the sockets API) where submitted after we found the work 
around for this issue and they where accepted.

And that we have a patched php java bridge client running in production.

My response was just to say that I have also seen this bug on a more recent 
release.

Regards

Tom 



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: Bacula: VERY SLOW on SAME host

[Larry Rosenman]

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
>

Thanks, Qing!

If you have code you'd like me to test, feel free.

On a related note, is the arp table supposed to be empty now?

$ arp -an
$ ping 192.168.200.5
PING 192.168.200.5 (192.168.200.5): 56 data bytes
64 bytes from 192.168.200.5: icmp_seq=0 ttl=255 time=0.810 ms
64 bytes from 192.168.200.5: icmp_seq=1 ttl=255 time=0.292 ms
^C
--- 192.168.200.5 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.292/0.551/0.810/0.259 ms
$ arp -an
$ uname -a
FreeBSD borg.lerctr.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Jan 14
17:16:03 CST 2009 r...@borg.lerctr.org:/usr/obj/usr/src/sys/BORG 
amd64
$

> -- Qing
>
>
>> -Original Message-
>> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
>> curr...@freebsd.org] On Behalf Of Kip Macy
>> Sent: Wednesday, January 14, 2009 8:47 PM
>> To: Larry Rosenman
>> Cc: freebsd-curr...@freebsd.org
>> Subject: Re: Bacula: VERY SLOW on SAME host
>>
>> arpv2 - add an localhost interface route as a workaround
>>
>> -Kip
>>
>> On Wed, Jan 14, 2009 at 8:35 PM, Larry Rosenman 
> wrote:
>> > Greetings,
>> >Somethings changed (Around the 1st of the year?) where my bacula
>> jobs
>> > take FOREVER to backup on the same host
>> > with the StorageDaemon and Director.  If I change it to use
> 127.0.0.1
>> > instead of the address on the em card, it's fine.
>> >
>> > If I use the address on the em nics, it's like 4kb/sec as opposed to
>> > multi-megabytes/sec.
>> >
>> > I'm looking for how to find what broke.
>> >
>> > Other networking to the host is fine, but this is TCP within the
> same
>> host,
>> > but using the IP address on the em interface.
>> >
>> > I see the TCP Send-Q fill up, and it's extremely slow.
>> >
>> > What data do you need to help debug this?
>> >
>> >
>> >
>> > --
>> > Larry Rosenman http://www.lerctr.org/~ler
>> > Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
>> > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
>> > ___
>> > freebsd-curr...@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-
>> unsubscr...@freebsd.org"
>> >
>> ___
>> freebsd-curr...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-
>> unsubscr...@freebsd.org"
>


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: Bacula: VERY SLOW on SAME host

[Li, Qing]

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]
Sent: Thu 1/15/2009 8:07 PM
To: Li, Qing
Cc: freebsd-curr...@freebsd.org; freebsd-net@freebsd.org
Subject: RE: Bacula: VERY SLOW on SAME host
 

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
>

Thanks, Qing!

If you have code you'd like me to test, feel free.

On a related note, is the arp table supposed to be empty now?

$ arp -an
$ ping 192.168.200.5
PING 192.168.200.5 (192.168.200.5): 56 data bytes
64 bytes from 192.168.200.5: icmp_seq=0 ttl=255 time=0.810 ms
64 bytes from 192.168.200.5: icmp_seq=1 ttl=255 time=0.292 ms
^C
--- 192.168.200.5 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.292/0.551/0.810/0.259 ms
$ arp -an
$ uname -a
FreeBSD borg.lerctr.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Jan 14
17:16:03 CST 2009 r...@borg.lerctr.org:/usr/obj/usr/src/sys/BORG 
amd64
$

> -- Qing
>
>
>> -Original Message-
>> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
>> curr...@freebsd.org] On Behalf Of Kip Macy
>> Sent: Wednesday, January 14, 2009 8:47 PM
>> To: Larry Rosenman
>> Cc: freebsd-curr...@freebsd.org
>> Subject: Re: Bacula: VERY SLOW on SAME host
>>
>> arpv2 - add an localhost interface route as a workaround
>>
>> -Kip
>>
>> On Wed, Jan 14, 2009 at 8:35 PM, Larry Rosenman 
> wrote:
>> > Greetings,
>> >Somethings changed (Around the 1st of the year?) where my bacula
>> jobs
>> > take FOREVER to backup on the same host
>> > with the StorageDaemon and Director.  If I change it to use
> 127.0.0.1
>> > instead of the address on the em card, it's fine.
>> >
>> > If I use the address on the em nics, it's like 4kb/sec as opposed to
>> > multi-megabytes/sec.
>> >
>> > I'm looking for how to find what broke.
>> >
>> > Other networking to the host is fine, but this is TCP within the
> same
>> host,
>> > but using the IP address on the em interface.
>> >
>> > I see the TCP Send-Q fill up, and it's extremely slow.
>> >
>> > What data do you need to help debug this?
>> >
>> >
>> >
>> > --
>> > Larry Rosenman http://www.lerctr.org/~ler
>> > Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
>> > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
>> > ___
>> > freebsd-curr...@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-
>> unsubscr...@freebsd.org"
>> >
>> ___
>> freebsd-curr...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-
>> unsubscr...@freebsd.org"
>


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"