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
RE: OS throws away large packets
-Original Message- From: Tom Judge [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 8:21 PM To: Mr Y Cc: freebsd-questions@freebsd.org; [EMAIL PROTECTED] Subject: Re: OS throws away large packets Mr Y wrote: Hi all, I'm trying to implement Large Recieve Offload for an Ethernet driver on FreeBSD 6.3, but all my MTU packets are being thrown by the OS. I'm using mbuf chains in this imlpementation, each mbuf is a cluster of MCLBYTES bytes. They are linked by the m_next pointer. The first packet being thrown away is 2945 bytes long. Wireshark shows the packet that is being passed to the OS is correct. Do I need to set some OS parameter to make it recieve mbuf chains? Please help. Hi Yony, I seem to remember some discussion about this list last year see the following threads: http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm l http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm l From my limited reading of these threads just now and possibly bad memory. It would seem that the MRU to MTU relationship is defined in the nic driver rather than enforced further up the stack or at least that seamed to be the case with the bce driver. Hope this is helpful, Tom Hi Tom, From what I understand these threads are referring to the bce hardware configuration (bus configuration) and driver mbuf allocation size. Am I correct? In my case I'm not trying to receive packets MTU from the HW, but to chain mbuf clusters, each is MCLBYTES long, and pass the mbuf chain to the OS. Since tcpdump (analyzed by wireshark) catches the packets above the driver and reports a good packet (and 2945 bytes long), I assume my driver functionality is ok. From what I know tcpdump is supposed to immitate the way the stack sees the packet, yet it is discarded. My logic says there is an OS parameter handled by the driver (at net device init time for example) that will set the OS to receive large mbuf chains, or a kernel tcp parameter. Is the tcp stack submitted to the mtu somehow? Yony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: OS throws away large packets
Hi all,
I'm trying to implement Large Recieve Offload for an
Ethernet driver
on FreeBSD 6.3, but all my MTU packets are being thrown
by the OS.
I'm using mbuf chains in this imlpementation, each mbuf is
a cluster
of MCLBYTES bytes. They are linked by the m_next pointer.
The first packet being thrown away is 2945 bytes long.
Wireshark shows
the packet that is being passed to the OS is correct.
Do I need to set some OS parameter to make it recieve mbuf chains?
Please help.
Hi Yony,
I seem to remember some discussion about this list last
year see the
following threads:
http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm
l
http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm
l
From my limited reading of these threads just now and possibly bad
memory. It would seem that the MRU to MTU relationship is
defined in
the nic driver rather than
enforced further up the stack or at least that seamed to
be the case
with the bce driver.
Hope this is helpful,
Tom
Hi Tom,
From what I understand these threads are referring to the bce
hardware
configuration (bus configuration) and driver mbuf
allocation size. Am
I correct?
In my case I'm not trying to receive packets MTU from the
HW, but to
chain mbuf clusters, each is MCLBYTES long, and pass the
mbuf chain to
the OS.
Since tcpdump (analyzed by wireshark) catches the packets above the
driver and reports a good packet (and 2945 bytes long), I assume my
driver functionality is ok. From what I know tcpdump is supposed to
immitate the way the stack sees the packet, yet it is discarded.
My logic says there is an OS parameter handled by the
driver (at net
device init time for example) that will set the OS to receive large
mbuf chains, or a kernel tcp parameter. Is the tcp stack
submitted to
the mtu somehow?
I don't see where you've identified what version of the os you're
working with. There's a check in the 802.3 input path on earlier
systems to discard frames mtu. This was removed not too long ago
with LRO in mind; check the history of sys/net/if_ethersubr.c.
Sam
Hi Sam, I have mentioned working on 6.3.
FreeBSD 6.2 had this check in if_ethersubr.c / ether_input:
539 if (m-m_pkthdr.len
540 ETHER_MAX_FRAME(ifp, etype, m-m_flags M_HASFCS)) {
541 if_printf(ifp, discard oversize frame
542 (ether type %x flags %x len %u
max %lu)\n,
543 etype, m-m_flags, m-m_pkthdr.len,
544 ETHER_MAX_FRAME(ifp, etype,
545 m-m_flags
M_HASFCS));
546 ifp-if_ierrors++;
547 m_freem(m);
548 return;
549 }
Patching it was explained by neterion in
http://trac.neterion.com/cgi-bin/trac.cgi/wiki/FreeBSD.
This check no longer exists in 6.3, nor any other oversize packet
handling (I couldn't find any so far).
I also get no error prints from the OS.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
kldload: unexpected relocation type 10
I'm getting tons of this message when loading my module: kldload: unexpected relocation type 10 I'm using a simple Makefile including a slightly modified bsd.kmod.mk (I've removed the -strip-debug flag) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Makefile execution on 6.3
Hi, I was happily using the following Makefile: ### MAKEOBJDIR=objs KMOD= if_mtnic SRCS= mtnic_cmd.c mtnic_event.c mtnic_main.c mtnic_params.c mtnic_netdev.c mtnic_lro.c SRCS+= mtnic_ver.h device_if.h bus_if.h pci_if.h CFLAGS+= -DMTNIC_SW_COUNTERS -DMTNIC_DEBUG_VERBOSE CFLAGS+= -g -DCONFIG_MTNIC_DEBUG mtnic_ver.h: echo #define DRV_RELDATE \`cat BUILD_ID | tail -1 | cut -d' ' -f4-8`\ $@ CLEANFILES+= mtnic_ver.h .include bsd.kmod.mk ### Until suddenly it stopped compiling and since then I only get: `mtnic_ver.h' is up to date. Is there any configuration I accidently changed for 'make' to make it create $KMOD? Thanks Yehonatan Yossef Mellanox Technologies Office: +972-4-9097200 ext. 301 Cell: +972-54-2345031 ([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: Capturing dmesg upon system crash on 6.3
I'm facing a system reboot upon loading of the driver, and I could use a tool for capturing dmesg upon system crash (such as netconsole on Linux). Your kernel isn't setup for driver development: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-ha ndbook/kerneldebug.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kern elconfig.html Basically, your system is rebooting cause the kernel panics and you're not setup for crash dumps, or anything that could help you diagnose the panic. -- Mel I've setup the dumpdev/dumpdir and I get a vmcore image upon a crash. I don't really understand how to use kgdb in order to read it but more than that - I don't need that much of data. I only want the dmesg report at the moment, see at what point my driver went crazy. Is it possible? Uhm, no. Fundamental logic flaw: when a kernel is stopped, you can't issue userland commands. All you have when you use ddb, is the contents of the registers, ram and backtrace. You really want ddb in the kernel: when a kernel panics, it'll drop to ddb and you can examine registers and do a backtrace, instead of dumping core and rebooting. It should point exactly to where your driver went crazy. -- Mel I meant making the dmesg log sent over the network/serial console to a linux machine. I just found out about syslogd, I'm trying to figure out how to use it. DDB sounds like a great option for deeper debugging, I'll use it. Ooh, sorry, totally got your question wrong. Serial should really be the way to go. But it depends when you load your driver. If your driver panics the kernel before it gets to loading syslogd, there may not be much sent. You could help this by not loading the network interface on bootup, but via cron instead, so that you're sure syslogd is up and running when you load the driver. Of course this assumes a working main network interface and that the driver isn't loaded automatically by /boot/loader.conf. -- Mel Thanks Mel, DDB is a great help. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Capturing dmesg upon system crash on 6.3
Hello, I'm a freebsd newbee, trying to port an ethernet driver from Linux to FreeBSD 6.3. I'm facing a system reboot upon loading of the driver, and I could use a tool for capturing dmesg upon system crash (such as netconsole on Linux). Can anyone link me to an appropriate tool? Sorry for sending this to three mailing lists, but I don't really know which one is active and relevant to this question. Cheers, Yehonatan Yossef Mellanox Technologies INC Office: +972-4-9097200 ext. 301 Cell: +972-54-2345031 ([EMAIL PROTECTED] callto:yonyossef ) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Capturing dmesg upon system crash on 6.3
I'm facing a system reboot upon loading of the driver, and I could use a tool for capturing dmesg upon system crash (such as netconsole on Linux). Your kernel isn't setup for driver development: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-ha ndbook/kerneldebug.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kern elconfig.html Basically, your system is rebooting cause the kernel panics and you're not setup for crash dumps, or anything that could help you diagnose the panic. -- Mel I've setup the dumpdev/dumpdir and I get a vmcore image upon a crash. I don't really understand how to use kgdb in order to read it but more than that - I don't need that much of data. I only want the dmesg report at the moment, see at what point my driver went crazy. Is it possible? Yony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Capturing dmesg upon system crash on 6.3
I'm looking into the syslogd capabilities at the moment, it might be enough. I've tried following the serial console setup you've pointed, but when I added the 'console=comconsole' to loader.conf the OS hanged during boot time, had to re-install the system. I'm currently porting Mellanox ethernet driver, InfiniBand will be probably next. Mail me outside this list if you're interested in InfiniBand. Yehonatan Yossef Mellanox Technologies INC Office: +972-4-9097200 ext. 301 Cell: +972-54-2345031 ([EMAIL PROTECTED]) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, February 25, 2008 3:29 PM To: Yehonatan Yossef Cc: freebsd-questions@freebsd.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Capturing dmesg upon system crash on 6.3 Yehonatan, good day. Mon, Feb 25, 2008 at 11:28:12AM +0200, Yehonatan Yossef wrote: I'm a freebsd newbee, trying to port an ethernet driver from Linux to FreeBSD 6.3. I'm facing a system reboot upon loading of the driver, and I could use a tool for capturing dmesg upon system crash (such as netconsole on Linux). May be serial console will help you? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/seri alconsole-setup.html Out of curiosity: are you porting some InfiniBand drivers to FreeBSD? -- Eygene ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Capturing dmesg upon system crash on 6.3
On Monday 25 February 2008 13:32:01 Yehonatan Yossef wrote: I'm facing a system reboot upon loading of the driver, and I could use a tool for capturing dmesg upon system crash (such as netconsole on Linux). Your kernel isn't setup for driver development: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-ha ndbook/kerneldebug.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kern elconfig.html Basically, your system is rebooting cause the kernel panics and you're not setup for crash dumps, or anything that could help you diagnose the panic. -- Mel I've setup the dumpdev/dumpdir and I get a vmcore image upon a crash. I don't really understand how to use kgdb in order to read it but more than that - I don't need that much of data. I only want the dmesg report at the moment, see at what point my driver went crazy. Is it possible? Uhm, no. Fundamental logic flaw: when a kernel is stopped, you can't issue userland commands. All you have when you use ddb, is the contents of the registers, ram and backtrace. You really want ddb in the kernel: when a kernel panics, it'll drop to ddb and you can examine registers and do a backtrace, instead of dumping core and rebooting. It should point exactly to where your driver went crazy. -- Mel I meant making the dmesg log sent over the network/serial console to a linux machine. I just found out about syslogd, I'm trying to figure out how to use it. DDB sounds like a great option for deeper debugging, I'll use it. Yony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
