Re: howto determine network device unit number? device.hints?
> 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-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?
> 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:
RE: howto determine network device unit number? device.hints?
> -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?
> 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 > ' > > > > 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?
> 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-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?
> > 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-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?
> -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 ' > 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 > 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"
howto determine network device unit number? device.hints?
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
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
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
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
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]"
Re: make doesn't know how to make KERNCONF
> 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]"
Re: HW VLAN Filtering on FreeBSD 6.3 + 7.0
> > > 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]"
HW VLAN Filtering on FreeBSD 6.3 + 7.0
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: VLAN filtering on FreeBSD 7.0 / 6.3
> 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]"
VLAN filtering on FreeBSD 7.0 / 6.3
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
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
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]"
kernel process memory overrun debugging
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]"
Valgrind compilation failure on FreeBSD7.0 for i386
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: p
FreeBSD7.0 shell failure on boot, amd 64
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
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]"
Re: options WITNESS and locks
> > > 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
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]"
options WITNESS and locks
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
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]"
