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

2009-01-15 Thread 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 mtnicunit
number, 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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


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

2009-01-15 Thread 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-...@freebsd.org; freebsd-questions@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-...@freebsd.org; freebsd-questions@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 
 your-name-here'
  
  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-questions@freebsd.org mailing list
  
  http://lists.freebsd.org/mailman/listinfo/freebsd-questions
  
  To unsubscribe, send any mail to
  

  
  freebsd-questions-unsubscr...@freebsd.org
  mailto:freebsd-questions-unsubscr...@freebsd.org
  
  
  

  

  
 
 

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


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

2009-01-15 Thread 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-...@freebsd.org; 
 Oleg Kats; 'H.fazaeli'; Eitan Shefi; freebsd-questions@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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


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

2009-01-15 Thread 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: pci11: driver added
Jan 15 19:28:04 sw247 kernel: pci12: driver added
Jan 15 19:28:04

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

2009-01-15 Thread Yony Yossef
 Eygene Ryabinkin wrote:
  ...
  I wanted to stress only one point: simple 'kldunload driver' and
  'kldload driver' 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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


howto determine network device unit number? device.hints?

2009-01-14 Thread Yony Yossef
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


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

2009-01-14 Thread Yony Yossef
 

 -Original Message-
 From: H.fazaeli [mailto:faza...@sepehrs.com] 
 Sent: Wednesday, January 14, 2009 6:24 PM
 To: Yony Yossef
 Cc: freebsd-...@freebsd.org; freebsd-questions@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 your-name-here'
 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-questions@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 h...@sepehrs.com
 Sepehr S. T. Co. Ltd.
 
 Web: http://www.sepehrs.com
 Tel: (9821)88975701-2
 Fax: (9821)88983352
 
 
 
 
 

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


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

2009-01-14 Thread Yony Yossef
 
 you may not change unit numbers as they are strictly 
 controlled by kernel.
 However, on freebsd 5.3+, you may use 'ifconfig name your-name-here'
 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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Using device.hints to determine network device unit number

2009-01-13 Thread Yony Yossef
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: class=0x02 card=0x001715b3 chip=0x636815b3
rev=0xa0 hdr=0x00
 
Is it done by /boot/device.hints?
if so, how? I've tried:
 
hint.mtnic.0.at=pci0:16
hint.mtnic.1.at=pci0:19
 
but it doesn't work. They keep switching upon reboot.
I'm using FreeBSD 7.0.
 
Thanks
Yony
 
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Detecting network memory leaks using netstat -m

2008-12-14 Thread Yony Yossef
Hi All,
 
I'm trying to find out whether my ethernet driver is leaking.
I just found out about netstat -m, but I don't understand some of it's
output.
 
Can somebody explain me what is mbuf+clusters out of packet secondary zone
in use ?
My output shows it raised significantly during equilibrium after several
stress runs:
 
BEFORE
 
16641/217734/234375 mbufs in use (current/cache/total)
16640/217766/234406/262144 mbuf clusters in use (current/cache/total/max)
256/1664 mbuf+clusters out of packet secondary zone in use (current/cache)
 
AFTER
 
625083/86562/711645 mbufs in use (current/cache/total)
180264/81880/262144/262144 mbuf clusters in use (current/cache/total/max)
160420/311 mbuf+clusters out of packet secondary zone in use (current/cache)
 
Thanks
Yony
 
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Timer driven tasks in FreeBSD 7

2008-12-07 Thread Yony Yossef
Hi All,

What mechanism should I use for making my netwrok driver call a
function every half a second, for instnace?

I am already using task queues but I haven't found a way to make it
work with a timer.

Thanks

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


cvsup first time - connection refused

2008-11-17 Thread Yony Yossef
Hi,

I'm running cvsup -g -L 2 cvs-supfile with all kinds of host names
from this list:

http://www.freebsd.org/doc/handbook/cvsup.html#HANDBOOK-MIRRORS-CHAPTER-SGML-MIRRORS-IL-CVSUP

I get a Connection refused error.

Help..

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


HW VLAN Filtering on FreeBSD 6.3 + 7.0

2008-11-16 Thread Yony Yossef
Hi All,

I would like to enable my NIC HW VLAN filtering, is there any way for my
driver to access the OS vlan table? (something like vlan_group_get_device on
linux)

I understood from previous investigation that on FreeBSD 6.3 and 7.0 there's
no ioctl informing the driver of vlan addition/removal. Is that correct?

Thanks,

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


Re: HW VLAN Filtering on FreeBSD 6.3 + 7.0

2008-11-16 Thread Yony Yossef

   I would like to enable my NIC HW VLAN filtering, is there any way for
 my
  driver to access the OS vlan table? (something like vlan_group_get_device
 on
  linux)
 
  I understood from previous investigation that on FreeBSD 6.3 and 7.0
 there's
  no ioctl informing the driver of vlan addition/removal. Is that correct?

 Man pages to check out: vlan(4) and ifconfig(8).  I'm pretty sure the
 vlan tagging feature is per-driver.


 Also, the vlan(4) list of supported drivers is out of date (for example,
 em(4) is missing), so be sure to check the man page of your NIC driver.


Sorry, i explained myself pretty bad. I'm working on an Ethernet driver for
FreeBSD.
The VLAN hw tagging is already working properly, but my nic is capable of
holding a vlan table on hw, filtering vlans on it's own.
I need to find a way to update that hw table.
one way is to recieve a ioctl from the OS of it's vlan table event (add,
remove). I can't find such ioctl.
second is to have a direct access from the driver to the OS vlan table. I'm
not familiar with the interface or if it's possible at all, and that is my
actual question.

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


Re: make doesn't know how to make KERNCONF

2008-11-16 Thread Yony Yossef
 make doesn't know how to make KERNCONF


 the command i run is:

 cd /usr/src
 make buildkernel KERNCONF=MIO

 where MIO is my kernel configuration file, living at /usr/src/sys/i386/conf

Are you sure your conf file shouldn't be in /usr/src/sys/amd64/conf ?

YY
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


VLAN filtering on FreeBSD 7.0 / 6.3

2008-10-28 Thread Yony Yossef
Hi,

I have two questions about VLANs on FreeBSD 6.3/7.0.

1.
I'm trying to understand whether HW VLAN filtering can be supported.
Looking at the code I can't find a proper ioctl that will inform the driver
about a vlan creation/destruction.
Is there a way of doing it?

2.
Second issue - is there way of enabling TSO on vlan interfaces?

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


Re: VLAN filtering on FreeBSD 7.0 / 6.3

2008-10-28 Thread Yony Yossef
 This change requires kernel changes that may not be compatible with 6.X, I
 am not sure,
 I am not the owner of that code.  Some reason you can't use 7.1 which will
 have everything
 you need?


I'm bound to 6.3 and 7.0 at the moment. Does the vlan ioctls exist only from
7.1 and fourth?
If so, are there any kernel patches to make 6.3 / 7.0 support it as well?



 TSO is a hardware feature, I have never tested this, but my suspicion is
 that if
 its enabled on the hardware that it will transparently happen in the
 outbound
 TX stream, but I am not sure.


My hardware works fine, I have TSO working on the regular interface. but
it seems like vlan interfaces does not inherit the parent device
capabilities.



 Jack



 On Tue, Oct 28, 2008 at 7:43 AM, Yony Yossef [EMAIL PROTECTED]wrote:

  Hi,

 I have two questions about VLANs on FreeBSD 6.3/7.0.

 1.
 I'm trying to understand whether HW VLAN filtering can be supported.
 Looking at the code I can't find a proper ioctl that will inform the
 driver about a vlan creation/destruction.
 Is there a way of doing it?

 2.
 Second issue - is there way of enabling TSO on vlan interfaces?

 Thanks
 Yony



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Freeing an mbuf cluster

2008-10-02 Thread Yony Yossef
Hi All,

I'm trying to manually build an mbuf chain with clusters in various sizes.
I'm doing it using the MGETHDR and MEXTADD macros, it works fine.
Now I'm looking for the simplest way to free an mbuf cluster, since I want
to free the clusters seperately. This function will be given as a parameter
to MEXTADD.

Is there a simple command like 'free(buf)' to free an mbuf cluster?

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


Long mbuf chains

2008-08-06 Thread Yony Yossef
Hi All

I'm working on an Ethernet driver for FreeBSD 7.0.
Taking network performance numbers I encountered very long mbuf chains on
the sender side.

The symptom is constant, always during iperf/netperf TCP stream tests with
message sizes of 128 bytes (200 mbufs per chain),
1024 bytes (30-60 mbufs per chain) and 2048 bytes.

My problem is that long chains require some kind of defragmentation/cutting
before it can be properly DMAd.
This is pretty a expansive operation.

1.
Is there a way of tuning the OS for sending limited length mbuf chains? I
thought setting net.inet.ip.maxfragsperpacket would do it but it doesn't.

2.
Is there a better way of handling this issue?


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


Valgrind compilation failure on FreeBSD7.0 for i386

2008-07-22 Thread Yony Yossef
Hi,

I would really like to use valgrind on my FreeBSD machine, but.. :-)

-Yony


make
===  Building for valgrind-352_7
gmake  all-recursive
gmake[1]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-352'
Making all in include
gmake[2]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-352/include'
gmake  all-am
gmake[3]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-352/include'
gmake[3]: Nothing to be done for `all-am'.
gmake[3]: Leaving directory
`/usr/ports/devel/valgrind/work/valgrind-stable-352/include'
gmake[2]: Leaving directory
`/usr/ports/devel/valgrind/work/valgrind-stable-352/include'
Making all in coregrind
gmake[2]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind'
gmake  all-recursive
gmake[3]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind'
Making all in x86
gmake[4]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind/x86'
gmake  all-am
gmake[5]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind/x86'
gmake[5]: Nothing to be done for `all-am'.
gmake[5]: Leaving directory `/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind/x86'
gmake[4]: Leaving directory `/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind/x86'
Making all in demangle
gmake[4]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind/demangle'
gmake[4]: Nothing to be done for `all'.
gmake[4]: Leaving directory `/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind/demangle'
Making all in .
gmake[4]: Entering directory
`/usr/ports/devel/valgrind/work/valgrind-stable-

352/coregrind'
if cc -DHAVE_CONFIG_H -I. -I. -I..  -I./demangle -I../include -I./x86 -

DVG_LIBDIR=\/usr/local/lib/valgrind\-Winline -Wall -Wshadow -O
-fno-omit-frame-pointer

-mpreferred-stack-boundary=2 -g -DELFSZ=32  -MT vg_mylibc.o -MD -MP -MF

.deps/vg_mylibc.Tpo -c -o vg_mylibc.o vg_mylibc.c; \
then mv -f .deps/vg_mylibc.Tpo .deps/vg_mylibc.Po; else rm -f

.deps/vg_mylibc.Tpo; exit 1; fi
In file included from vg_include.h:49,
 from vg_mylibc.c:33:
../include/vg_skin.h:1230: warning: type qualifiers ignored on function
return type
vg_mylibc.c: In function 'vgPlain_kisemptysigset':
vg_mylibc.c:65: warning: pointer targets in passing argument 1 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:65: warning: pointer targets in passing argument 2 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:65: warning: pointer targets in passing argument 4 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c: In function 'vgPlain_kisfullsigset':
vg_mylibc.c:74: warning: pointer targets in passing argument 1 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:74: warning: pointer targets in passing argument 2 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:74: warning: pointer targets in passing argument 4 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c: In function 'vgPlain_ksigaddset_from_set':
vg_mylibc.c:121: warning: pointer targets in passing argument 1 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:121: warning: pointer targets in passing argument 2 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:121: warning: pointer targets in passing argument 4 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c: In function 'vgPlain_ksigdelset_from_set':
vg_mylibc.c:130: warning: pointer targets in passing argument 1 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:130: warning: pointer targets in passing argument 2 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:130: warning: pointer targets in passing argument 4 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c: In function 'vgPlain_ksignal':
vg_mylibc.c:212: warning: pointer targets in passing argument 1 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:212: warning: pointer targets in passing argument 2 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:212: warning: pointer targets in passing argument 4 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c: In function 'vgPlain_exit':
vg_mylibc.c:390: warning: pointer targets in passing argument 1 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:390: warning: pointer targets in passing argument 2 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c:390: warning: pointer targets in passing argument 4 of

'vgPlain_core_assert_fail' differ in signedness
vg_mylibc.c: In function 'vgPlain_brk':
vg_mylibc.c:445: warning: implicit declaration of function 'brk'
vg_mylibc.c:446: warning: implicit declaration of function 'sbrk'
vg_mylibc.c:446: warning: return makes pointer from integer without a cast
vg_mylibc.c: In function 'myvprintf_int64':
vg_mylibc.c:528: warning: pointer 

kernel process memory overrun debugging

2008-07-22 Thread Yony Yossef
Hi all,

I'm looking for methods to debug a kernel process memory overrun.
I'm working on an Ethernet driver for FreeBSD 7.0 and I'm facing a crash
after several (kldload + kldunload)s.
The exception is being thrown by the shell process after the last kldunload
successfully ends so I'm guessing it's a memory overrun.

Is there any tool/kernel option that helps?
Thanks,

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


FreeBSD7.0 shell failure on boot, amd 64

2008-07-16 Thread Yony Yossef
Hi,

After a successful installation, first boot of FreeBSD7 fails upon shell
loading:

ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/amd64/reloc.c:341
pid 78 (sh), uid 0: exited on signal 6

I get a prompt asking to provide a shell path. the same error occurs for all
existing shells (sh, csh, tcsh).

Here's the command pointed by the crash:
/usr/src/libexec/rtld-elf/amd64/reloc.c:341:
assert(ELF_R_TYPE(rela-r_info) == R_X86_64_JMP_SLOT);

Machine info:

Serie=PowerEdge SC1435
CpuNum   =4
CpuVendor=AuthenticAMD
CpuModel =Dual-Core AMD Opteron(tm) Processor 2216
CpuMhz   =2400.330
MemSizeKb=8247676
MachType =x86_64
KernelRev=2.6.18-8.el5
ChipSet  =Broadcom HT1000 Legacy South Bridge

Is this arch supported by FreeBSD 7.0 ?

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


Re: options WITNESS and locks

2008-07-15 Thread Yony Yossef
 Hi Kris,

Please see below


  Hi all.

 I'm trying to debug a spinlock held too long error.
 Therefore I thought compiling my kernel with options WITNESS would be a
 good idea.

 Using the WITNESS kernel I cannot load my driver with any MTX_SPIN mutex.
 I had to change it all to MTX_DEF since every MTX_SPIN got me this error:

 panic: lock (network driver) spin mutex does not match earlier (sleep
 mutex)
 lock


 It means that somewhere you are treating a mutex with that name as a sleep
 mutex and in other places as a spin mutex.  WITNESS works on the lock name
 so this may or may not be a bug.

 However, default mutexes should be used in most cases anyway (bear in mind
 that default mutexes will also spin when it makes sense for them to do so).

 So I changed it all to MTX_DEF, just to see if things will work.
 Now I can load my driver, but calling ifconfig shows a new crash:

 mtnic0: Activating port:1
 mtnic0: Ethernet address: 00:00:00:00:08:88
 mtnic0: Activating port:2
 mtnic1: Ethernet address: 00:00:00:00:08:89
 lock order reversal: (sleepable after non-sleepable)
  1st 0x81379010 MTNIC state semaphore (MTNIC state semaphore) @
 mtnic_netdev.c:1855
  2nd 0x809eee00 ACPI root bus (ACPI root bus) @
 /usr/src/sys/dev/acpica/acpi.c:1022


 You are acquiring a lock that is sleepable (i.e. legal for consumers to
 sleep while holding it), after first acquiring another lock that is not
 sleepable.  The danger is that if some code sleeps while holding both the
 first and second lock, then other code that tries to acquire the first lock
 will deadlock indefinitely.

 This is often due to a programming or design error.

 Kris


Something is still unclear. All my locks are MTX_DEF type, which means
sleepable, including the one specified in the crash report (MTNIC state
semaphore).
This crash happens when I try to call bus_resource_alloc_any for a SYS_REQ
which is trying to obtain the second lock (ACPI root bus). How come my
MTX_DEF lock is being treated as as non-sleepable?





   KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 witness_checkorder() at witness_checkorder+0x559
 _sx_xlock() at _sx_xlock+0x32
 acpi_alloc_resource() at acpi_alloc_resource+0x9a
 pci_alloc_resource() at pci_alloc_resource+0x81
 resource_list_alloc() at resource_list_alloc+0x17a
 pci_alloc_resource() at pci_alloc_resource+0x81
 bus_alloc_resource() at bus_alloc_resource+0x89
 mtnic_start_port() at mtnic_start_port+0x4f1
 mtnic_open() at mtnic_open+0xb2
 ether_ioctl() at ether_ioctl+0xb5
 mtnic_ioctl() at mtnic_ioctl+0x3e
 in_ifinit() at in_ifinit+0x8d
 in_control() at in_control+0xc66
 ifioctl() at ifioctl+0xea
 kern_ioctl() at kern_ioctl+0xa3
 ioctl() at ioctl+0xf9
 syscall() at syscall+0x1b5
 Xfast_syscall() at Xfast_syscall+0xab
 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800824cfc, rsp =
 0x7fffe3b8, rbp = 0x7fffee10 ---
 KDB: enter: witness_checkorder
 [thread pid 1051 tid 100069 ]
 Stopped at  kdb_enter+0x31: leave
 db


 Can anybody please tell me what is going on here?

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




___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: options WITNESS and locks

2008-07-15 Thread Yony Yossef


 Something is still unclear. All my locks are MTX_DEF type, which means
 sleepable, including the one specified in the crash report (MTNIC state
 semaphore).
 This crash happens when I try to call bus_resource_alloc_any for a SYS_REQ
 which is trying to obtain the second lock (ACPI root bus). How come my
 MTX_DEF lock is being treated as as non-sleepable?


 MTX_DEF locks *are* non-sleepable :-)

 Kris



Good news :-)
Yet the documentation is confusing me:

man pages say:
MTX_DEFDefault mutexes will always allow the current thread to be
suspended to avoid deadlock conditions against interrupt
threads.  The implementation of this lock type may spin
for a while before suspending the current thread.
and in mutex.h:
/*
 * Mutex types and options passed to mtx_init().  MTX_QUIET and MTX_DUPOK
 * can also be passed in.
 */
#define MTX_DEF  0x /* DEFAULT (sleep) lock */
#define MTX_SPIN 0x0001 /* Spin lock (disables interrupts) */
#define MTX_RECURSE 0x0004 /* Option: lock allowed to recurse */
#define MTX_NOWITNESS 0x0008 /* Don't do any witness checking. */
#define MTX_NOPROFILE   0x0020 /* Don't profile this lock */


What does the DEFAULT (sleep) lock comment near MTX_DEF means?
And which ones are sleepable?..  I guess I'm missing something here.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: options WITNESS and locks

2008-07-15 Thread Yony Yossef
Problem solved :-)
Thank you very much for your patience Kris..

On Tue, Jul 15, 2008 at 5:14 PM, Kris Kennaway [EMAIL PROTECTED] wrote:

  Yony Yossef wrote:


Something is still unclear. All my locks are MTX_DEF type, which
means
sleepable, including the one specified in the crash report
(MTNIC state
semaphore).
This crash happens when I try to call bus_resource_alloc_any for
a SYS_REQ
which is trying to obtain the second lock (ACPI root bus). How
come my
MTX_DEF lock is being treated as as non-sleepable?


MTX_DEF locks *are* non-sleepable :-)

Kris

   Good news :-)
 Yet the documentation is confusing me:
  man pages say:
 MTX_DEFDefault mutexes will always allow the current thread to be
suspended to avoid deadlock conditions against
 interrupt
threads.  The implementation of this lock type may spin
for a while before suspending the current thread.
 and in mutex.h:
 /*
  * Mutex types and options passed to mtx_init().  MTX_QUIET and MTX_DUPOK
  * can also be passed in.
  */
 #define MTX_DEF  0x /* DEFAULT (sleep) lock */
 #define MTX_SPIN 0x0001 /* Spin lock (disables interrupts) */
 #define MTX_RECURSE 0x0004 /* Option: lock allowed to recurse */
 #define MTX_NOWITNESS 0x0008 /* Don't do any witness checking. */
 #define MTX_NOPROFILE   0x0020 /* Don't profile this lock */
   What does the DEFAULT (sleep) lock comment near MTX_DEF means?
 And which ones are sleepable?..  I guess I'm missing something here.


 sleep mutex means that the mutex holder may be put to sleep by the kernel
 while the mutex is held by another process (if the lock holder is running
 then it will spin, though).  It is in contrast to spin mutexes that always
 spin forever while the lock is held, even when it might be inefficient for
 them to do so because the lock holder is no longer running after the CPU
 context switched to another process before it released the lock.

 This describes the behaviour of the mutex while it is waiting to acquire a
 lock.

 sleepable vs non-sleepable locks means what it is legal for your code
 to do while holding a mutex and doesn't relate to the internal
 implementation of the lock.

 This describes what it is legal for your code to do once it has acquired
 the lock.

 Kris


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


options WITNESS and locks

2008-07-14 Thread Yony Yossef
Hi all.

I'm trying to debug a spinlock held too long error.
Therefore I thought compiling my kernel with options WITNESS would be a
good idea.

Using the WITNESS kernel I cannot load my driver with any MTX_SPIN mutex.
I had to change it all to MTX_DEF since every MTX_SPIN got me this error:

panic: lock (network driver) spin mutex does not match earlier (sleep mutex)
lock
So I changed it all to MTX_DEF, just to see if things will work.
Now I can load my driver, but calling ifconfig shows a new crash:

mtnic0: Activating port:1
mtnic0: Ethernet address: 00:00:00:00:08:88
mtnic0: Activating port:2
mtnic1: Ethernet address: 00:00:00:00:08:89
lock order reversal: (sleepable after non-sleepable)
 1st 0x81379010 MTNIC state semaphore (MTNIC state semaphore) @
mtnic_netdev.c:1855
 2nd 0x809eee00 ACPI root bus (ACPI root bus) @
/usr/src/sys/dev/acpica/acpi.c:1022
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
witness_checkorder() at witness_checkorder+0x559
_sx_xlock() at _sx_xlock+0x32
acpi_alloc_resource() at acpi_alloc_resource+0x9a
pci_alloc_resource() at pci_alloc_resource+0x81
resource_list_alloc() at resource_list_alloc+0x17a
pci_alloc_resource() at pci_alloc_resource+0x81
bus_alloc_resource() at bus_alloc_resource+0x89
mtnic_start_port() at mtnic_start_port+0x4f1
mtnic_open() at mtnic_open+0xb2
ether_ioctl() at ether_ioctl+0xb5
mtnic_ioctl() at mtnic_ioctl+0x3e
in_ifinit() at in_ifinit+0x8d
in_control() at in_control+0xc66
ifioctl() at ifioctl+0xea
kern_ioctl() at kern_ioctl+0xa3
ioctl() at ioctl+0xf9
syscall() at syscall+0x1b5
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800824cfc, rsp =
0x7fffe3b8, rbp = 0x7fffee10 ---
KDB: enter: witness_checkorder
[thread pid 1051 tid 100069 ]
Stopped at  kdb_enter+0x31: leave
db


Can anybody please tell me what is going on here?

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


Process management in FreeBSD 7

2008-06-19 Thread Yony Yossef
Hi All,

I'm trying to find the equivilents for Linux's schedule() and
set_task_state(TASK_RUNNING).

Does anybody have a tip?

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