[patch] i386 pmap sysmaps_pcpu[] atomic access
Hi,
the access to sysmaps_pcpu[] should be atomic with respect to
thread migration. Otherwise, a sysmaps for one CPU can be stolen by
another CPU and the purpose of per CPU sysmaps is broken. A patch is
enclosed.
Svata
Index: sys/i386/i386/pmap.c
===
--- sys/i386/i386/pmap.c(revision 246831)
+++ sys/i386/i386/pmap.c(working copy)
@@ -4146,11 +4146,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4171,11 +4171,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page_area: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4220,13 +4220,13 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP1)
panic(pmap_copy_page: CMAP1 busy);
if (*sysmaps-CMAP2)
panic(pmap_copy_page: CMAP2 busy);
- sched_pin();
invlpg((u_int)sysmaps-CADDR1);
invlpg((u_int)sysmaps-CADDR2);
*sysmaps-CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A |
@@ -5072,11 +5072,11 @@
vm_offset_t sva, eva;
if ((cpu_feature CPUID_CLFSH) != 0) {
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_flush_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) |
PG_A | PG_M | pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: Assertion t-t_cursor.tp_row = t-t_winsize.tp_row failed at /usr/src/sys/teken/teken_subr.h:94
I got this panic when playing with the docking station for lenovo T61p. I tried to attach/detach it. I got a complete crash dump, but don't know what to do with it. root@zzz:/var/crash # cat info.1 Dump header from device /dev/ada0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 357797888B (341 MB) Blocksize: 512 Dumptime: Mon Feb 18 11:51:27 2013 Hostname: zzz Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #2 r246552: Fri Feb 15 20:41:10 GMT 2013 root@zzz:/usr/obj/usr/src/sys/MINKY Panic String: Assertion t-t_cursor.tp_row = t-t_winsize.tp_row failed at /u sr/src/sys/teken/teken_subr.h:94 Dump Parity: 3806418789 Bounds: 1 Dump Status: good root@zzz:/var/crash # The core.txt: http://eis.bris.ac.uk/~mexas/core.txt.1 Please advise Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote:
Hi,
the access to sysmaps_pcpu[] should be atomic with respect to
thread migration. Otherwise, a sysmaps for one CPU can be stolen by
another CPU and the purpose of per CPU sysmaps is broken. A patch is
enclosed.
And, what are the problem caused by the 'otherwise' ?
I do not see any.
Really, taking the mutex while bind to a CPU could be deadlock-prone
under some situations.
This was discussed at least one more time. Might be, a comment saying that
there is no issue should be added.
Svata
Index: sys/i386/i386/pmap.c
===
--- sys/i386/i386/pmap.c (revision 246831)
+++ sys/i386/i386/pmap.c (working copy)
@@ -4146,11 +4146,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4171,11 +4171,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page_area: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4220,13 +4220,13 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP1)
panic(pmap_copy_page: CMAP1 busy);
if (*sysmaps-CMAP2)
panic(pmap_copy_page: CMAP2 busy);
- sched_pin();
invlpg((u_int)sysmaps-CADDR1);
invlpg((u_int)sysmaps-CADDR2);
*sysmaps-CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A |
@@ -5072,11 +5072,11 @@
vm_offset_t sva, eva;
if ((cpu_feature CPUID_CLFSH) != 0) {
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_flush_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) |
PG_A | PG_M | pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
pgpJybqFrB7Kk.pgp
Description: PGP signature
Re: Possible bug in NFSv4 with krb5p security?
On 17 February 2013 22:58, Rick Macklem rmack...@uoguelph.ca wrote:
I think the Makefiles are in the kerberos5 directory.
Since the only function you care about is the one in
kerberos5/lib/libgssapi_krb5/pname_to_uid.c, I'd
just put a copy of that file in usr.sbin/gssd and
modify the Makefile there to compile it and link
its .o into gssd, avoiding rebuilding any libraries.
I'd put a couple of fprintf(stderr, ...) in it and
then run gssd -d and see what it says.
Just how I'd attack it, rick
Good news! The problem is solved!
You were right, the problem was in pname_to_uid.c. In it, the following
code can be found:
char lname[MAXLOGNAME + 1], buf[1024];
/* some code snipped for brevity... */
getpwnam_r(lname, pwd, buf, sizeof(buf), pw);
if (pw) {
*uidp = pw-pw_uid;
return (GSS_S_COMPLETE);
} else {
return (GSS_S_FAILURE);
}
As it turns out, the getpwnam_r() call fails with ERANGE (I had to check
the return value from getpwnam_r() in order to determine this, as pw is set
to NULL both if there was an error or if the user name can't be found).
Now, increasing the size of buf to 1024 solved the problem, and now the
lookup works correctly.
I wrote a small test program that issued the same call to getpwnam_r() and
it worked. Until I su'ed to root, and then it failed.
It seems as though the buffer needs to be bigger if you're root. I have no
idea why, but there you have it. Problem solved.
Should this be fixed in the main codebase?
Oh, and thanks so much to all of you for being patient with me while
solving this. I really appreciate it. Also, I'd like to say that the code
base was quite pleasant to work with. Thanks for that too. :-)
Regards,
Elias
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Possible bug in NFSv4 with krb5p security?
On 19 February 2013 00:06, Elias Mårtenson loke...@gmail.com wrote: char lname[MAXLOGNAME + 1], buf[1024]; Oops. Here I am, replying to myself. The above is a typo. That's by modified code. In the original source, buf is 128 bytes in size. Regards, Elias ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote:
On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov
kostik...@gmail.com wrote:
On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote:
Hi,
the access to sysmaps_pcpu[] should be atomic with respect to
thread migration. Otherwise, a sysmaps for one CPU can be stolen by
another CPU and the purpose of per CPU sysmaps is broken. A patch is
enclosed.
And, what are the problem caused by the 'otherwise' ?
I do not see any.
The 'otherwise' issue is the following:
1. A thread is running on CPU0.
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
2. A sysmaps variable contains a pointer to 'CPU0' sysmaps.
3. Now, the thread migrates into CPU1.
4. However, the sysmaps variable still contains a pointers to 'CPU0' sysmaps.
mtx_lock(sysmaps-lock);
4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the
thread uselessly can block another thread running on CPU0. Maybe, it's
not a problem. However, it definitely goes against the reason why the
submaps (one for each CPU) exist.
So what ?
Really, taking the mutex while bind to a CPU could be deadlock-prone
under some situations.
This was discussed at least one more time. Might be, a comment saying that
there is no issue should be added.
I missed the discussion. Can you point me to it, please? A deadlock is
not problem here, however, I can be wrong, as I can't imagine now how
a simple pinning could lead into a deadlock at all.
Because some other load on the bind cpu might prevent the thread from
being scheduled.
Svata
Index: sys/i386/i386/pmap.c
===
--- sys/i386/i386/pmap.c (revision 246831)
+++ sys/i386/i386/pmap.c (working copy)
@@ -4146,11 +4146,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4171,11 +4171,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page_area: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4220,13 +4220,13 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP1)
panic(pmap_copy_page: CMAP1 busy);
if (*sysmaps-CMAP2)
panic(pmap_copy_page: CMAP2 busy);
- sched_pin();
invlpg((u_int)sysmaps-CADDR1);
invlpg((u_int)sysmaps-CADDR2);
*sysmaps-CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A |
@@ -5072,11 +5072,11 @@
vm_offset_t sva, eva;
if ((cpu_feature CPUID_CLFSH) != 0) {
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_flush_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) |
PG_A | PG_M | pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
pgp9RnaKGdSYD.pgp
Description: PGP signature
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov
kostik...@gmail.com wrote:
On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote:
Hi,
the access to sysmaps_pcpu[] should be atomic with respect to
thread migration. Otherwise, a sysmaps for one CPU can be stolen by
another CPU and the purpose of per CPU sysmaps is broken. A patch is
enclosed.
And, what are the problem caused by the 'otherwise' ?
I do not see any.
The 'otherwise' issue is the following:
1. A thread is running on CPU0.
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
2. A sysmaps variable contains a pointer to 'CPU0' sysmaps.
3. Now, the thread migrates into CPU1.
4. However, the sysmaps variable still contains a pointers to 'CPU0' sysmaps.
mtx_lock(sysmaps-lock);
4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the
thread uselessly can block another thread running on CPU0. Maybe, it's
not a problem. However, it definitely goes against the reason why the
submaps (one for each CPU) exist.
Really, taking the mutex while bind to a CPU could be deadlock-prone
under some situations.
This was discussed at least one more time. Might be, a comment saying that
there is no issue should be added.
I missed the discussion. Can you point me to it, please? A deadlock is
not problem here, however, I can be wrong, as I can't imagine now how
a simple pinning could lead into a deadlock at all.
Svata
Index: sys/i386/i386/pmap.c
===
--- sys/i386/i386/pmap.c (revision 246831)
+++ sys/i386/i386/pmap.c (working copy)
@@ -4146,11 +4146,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4171,11 +4171,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page_area: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4220,13 +4220,13 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP1)
panic(pmap_copy_page: CMAP1 busy);
if (*sysmaps-CMAP2)
panic(pmap_copy_page: CMAP2 busy);
- sched_pin();
invlpg((u_int)sysmaps-CADDR1);
invlpg((u_int)sysmaps-CADDR2);
*sysmaps-CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A |
@@ -5072,11 +5072,11 @@
vm_offset_t sva, eva;
if ((cpu_feature CPUID_CLFSH) != 0) {
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_flush_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) |
PG_A | PG_M | pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is there an easy way to find out which port loads which library?
--- On Mon, 2/18/13, Chris Rees utis...@gmail.com wrote: From: Chris Rees utis...@gmail.com Subject: Re: Is there an easy way to find out which port loads which library? To: Jeffrey Bouquet jeffreybouq...@yahoo.com Cc: FreeBSD Mailing List freebsd-po...@freebsd.org Date: Monday, February 18, 2013, 1:01 AM On 18 Feb 2013 05:35, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote: Subject: Re: Is there an easy way to find out which port loads which library? Bernard Higonnet wrote: Is there a simple, direct, complete, and unequivocal way to find out which port(s) install which libraries? Something like this perhaps? # grep libfoobar.so /usr/ports/*/*/pkg-plist AvW None of these replies mention pkg which /usr/local/lib/libfoobar.so pkg_which /usr/local/lib/libfoobar.so ... I typically use one or both (still using /var/db/pkg after running pkg2ng once a long time ago...) Why??? Chris Unsure of the question. Why did I run pkg2ng? I was uncognizant of all the immediate consequences. Why did I revert? Not ready to make /var/db/pkg disappear until I've seen guides explaining the new usages which fit the present workflow here... Why do not I implement it at this time? I've still too much to do in the short term on a daily basis vs. implement anything new until I am one of the *last* to do so, so I would do it in the quickest and most expedient manner. pkg_delete -f /var/db/pkg/rubygem-mime-types-1.19 pkg_add rubygem-mime-types-1.21.tbz. I don't have to know the 1.19 (the shell does). I do not recall anyone mentioning how the equivalent would work in a pkg system. They may have, but if it was a reply, I archived it somewhere, as I would prefer to switch all the machines I use weekly all at once, and prefer to wait as long as expedient. That works on legacy laptops as well as modern 4-core CPU, aided by the shell doing expansion, and I can type it without thinking, aided by the shell. The subdirectory is directly available to grep, awk, less... without an .so. I've not yet had time to implement a /var/db/pkg/ on a machine running pkg (by script maybe) so that it could continue. I've posted several times why the progress of /pkg/ has not been shown to [1] not slow down the workflow to which I am accustomed to upgrade multiple machines has not been reliably demonstrated... and edge cases in which the legacy method is preferable. Unfortunately, I ran out of time a long time ago to respond more in depth; my views on the matter are scattered in the lists archives and forum archives [further content redacted so as to not waste anyone's time.] J. Bouquet [1] I am not asking for anyone's efforts, nor trying to sound negative; just trying to respond to the question with a wait-and-see viewpoint... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
No console, not even serial, does not work (init fails)
We run our NanoBSD images on Soekris and ALIX hardware. In some cases we need
all available serial ports for other hardware like GPS, and modems. The boards
have no video, so with all serial ports unavailable as a console no other
console is available.
The problem is that FreeBSD does not handle well the case where there is no
console at all:
1) http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/102515
fsck_ufs crashes (6.1-STABLE). Because of the unitialised console libc somehow
gets corrupted and crashes fsck_ufs. This problem can be circumvented by
replacing 'fsck -p' with 'fsck /dev/null /dev/null'.
2) In 8.3-RELEASE init exits prematurely because it cannot open /dev/console
for reading and writing in setctty(). Removing the calls to _exit(1) in that
function makes the boot complete. I haven't checked whether the fsck_ufs
problem still appears as our builds run with a patched rc.d script.
As far as I can see this is still a problem in CURRENT.
My attempt at resolving this was to create a null terminal in dev/null/null.c,
see the patch below, but that did not work as expected. After booting the
system with a modified init the response to 'echo /dev/console' was 'Device
not configured'. I've added another CN_* priority to make sure a null console
does not take precedence over for example gdb console.
Any pointers as to who/how to resolve this issue? Any reason why the null
console approach does not work?
Nick Hibma
n...@van-laarhoven.org
GTD: Time management for chaotic people.
Index: /usr/src/sys/sys/cons.h
===
--- /usr/src/sys/sys/cons.h (revision 242660)
+++ /usr/src/sys/sys/cons.h (working copy)
@@ -69,10 +69,11 @@
/* values for cn_pri - reflect our policy for console selection */
#defineCN_DEAD 0 /* device doesn't exist */
-#define CN_LOW 1 /* device is a last restort only */
-#define CN_NORMAL 2 /* device exists but is nothing special */
-#define CN_INTERNAL3 /* internal bit-mapped display */
-#define CN_REMOTE 4 /* serial interface with remote bit set */
+#define CN_NULL1 /* no console at all */
+#define CN_LOW 2 /* device is a last restort only */
+#define CN_NORMAL 3 /* device exists but is nothing special */
+#define CN_INTERNAL4 /* internal bit-mapped display */
+#define CN_REMOTE 5 /* serial interface with remote bit set */
/* Values for cn_flags. */
#defineCN_FLAG_NODEBUG 0x0001 /* Not supported with debugger.
*/
Index: /usr/src/sys/dev/null/null.c
===
--- /usr/src/sys/dev/null/null.c(revision 242660)
+++ /usr/src/sys/dev/null/null.c(working copy)
@@ -41,6 +41,9 @@
#include sys/bus.h
#include sys/filio.h
+#include sys/cons.h
+#include sys/consio.h
+
#include machine/bus.h
/* For use with destroy_dev(9). */
@@ -173,3 +176,45 @@
DEV_MODULE(null, null_modevent, NULL);
MODULE_VERSION(null, 1);
+
+static cn_probe_t null_cnprobe;
+static cn_init_t null_cninit;
+static cn_term_t null_cnterm;
+static cn_getc_t null_cngetc;
+static cn_putc_t null_cnputc;
+
+CONSOLE_DRIVER(null);
+
+static void
+null_cnprobe(struct consdev *cp)
+{
+sprintf(cp-cn_name, null);
+cp-cn_pri = CN_NULL;
+}
+
+static void
+null_cninit(struct consdev *cp)
+{
+}
+
+
+static void
+null_cnputc(struct consdev *cp, int c)
+{
+ (void) cp;
+
+ (void) c;
+}
+
+static int
+null_cngetc(struct consdev * cp)
+{
+ (void) cp;
+
+ return -1;
+}
+
+static void
+null_cnterm(struct consdev * cp)
+{
+}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is there an easy way to find out which port loads which library?
Not answering anyone in particular, but I feel compelled to point out that as far as I know pkg_info only works with packages/ports that are already installed (or at least created/downloaded), whereas the grep/find method also works for finding out which not-yet-installed package/port *will* install a certain file. But do of course correct me if I'm mistaken. AvW -- I'm not completely useless, I can be used as a bad example. pgp2Fpx5d4VfQ.pgp Description: PGP signature
Re: Is there an easy way to find out which port loads which library?
On 18 Feb 2013 18:42, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote: --- On Mon, 2/18/13, Chris Rees utis...@gmail.com wrote: From: Chris Rees utis...@gmail.com Subject: Re: Is there an easy way to find out which port loads which library? To: Jeffrey Bouquet jeffreybouq...@yahoo.com Cc: FreeBSD Mailing List freebsd-po...@freebsd.org Date: Monday, February 18, 2013, 1:01 AM On 18 Feb 2013 05:35, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote: Subject: Re: Is there an easy way to find out which port loads which library? Bernard Higonnet wrote: Is there a simple, direct, complete, and unequivocal way to find out which port(s) install which libraries? Something like this perhaps? # grep libfoobar.so /usr/ports/*/*/pkg-plist AvW None of these replies mention pkg which /usr/local/lib/libfoobar.so pkg_which /usr/local/lib/libfoobar.so ... I typically use one or both (still using /var/db/pkg after running pkg2ng once a long time ago...) Why??? Chris Unsure of the question. Why did I run pkg2ng? I was uncognizant of all the immediate consequences. Why did I revert? Not ready to make /var/db/pkg disappear until I've seen guides explaining the new usages which fit the present workflow here... Why do not I implement it at this time? I've still too much to do in the short term on a daily basis vs. implement anything new until I am one of the *last* to do so, so I would do it in the quickest and most expedient manner. pkg_delete -f /var/db/pkg/rubygem-mime-types-1.19 pkg_add rubygem-mime-types-1.21.tbz. I don't have to know the 1.19 (the shell does). I do not recall anyone mentioning how the equivalent would work in a pkg system. They may have, but if it was a reply, I archived it somewhere, as I would prefer to switch all the machines I use weekly all at once, and prefer to wait as long as expedient. You can use pkg delete -x rubygem-mime-types, or pkg update pkg upgrade is really what you need there. That works on legacy laptops as well as modern 4-core CPU, aided by the shell doing expansion, and I can type it without thinking, aided by the shell. The subdirectory is directly available to grep, awk, less... without an .so. I've not yet had time to implement a /var/db/pkg/ on a machine running pkg (by script maybe) so that it could continue. Man pkg-query, but see below. I've posted several times why the progress of /pkg/ has not been shown to [1] not slow down the workflow to which I am accustomed to upgrade multiple machines has not been reliably demonstrated... and edge cases in which the legacy method is preferable. Unfortunately, I ran out of time a long time ago to respond more in depth; my views on the matter are scattered in the lists archives and forum archives [further content redacted so as to not waste anyone's time.] Shell autocomplete should be pretty easy to implement should you choose, but given that many of the steps you describe are automated anyway, it's hard to see any real advantage to manually manipulating the data! Rather than describing your current methods, you may be better off (in a new thread) describing the *outcomes* that you would like, and we can help you achieve them. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Mon, Feb 18, 2013 at 6:09 PM, Konstantin Belousov
kostik...@gmail.com wrote:
On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote:
On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov
kostik...@gmail.com wrote:
On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote:
Hi,
the access to sysmaps_pcpu[] should be atomic with respect to
thread migration. Otherwise, a sysmaps for one CPU can be stolen by
another CPU and the purpose of per CPU sysmaps is broken. A patch is
enclosed.
And, what are the problem caused by the 'otherwise' ?
I do not see any.
The 'otherwise' issue is the following:
1. A thread is running on CPU0.
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
2. A sysmaps variable contains a pointer to 'CPU0' sysmaps.
3. Now, the thread migrates into CPU1.
4. However, the sysmaps variable still contains a pointers to 'CPU0' sysmaps.
mtx_lock(sysmaps-lock);
4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the
thread uselessly can block another thread running on CPU0. Maybe, it's
not a problem. However, it definitely goes against the reason why the
submaps (one for each CPU) exist.
So what ?
It depends. You don't understand it or you think it's ok? Tell me.
Really, taking the mutex while bind to a CPU could be deadlock-prone
under some situations.
This was discussed at least one more time. Might be, a comment saying that
there is no issue should be added.
I missed the discussion. Can you point me to it, please? A deadlock is
not problem here, however, I can be wrong, as I can't imagine now how
a simple pinning could lead into a deadlock at all.
Because some other load on the bind cpu might prevent the thread from
being scheduled.
I'm afraid I still have no idea. On single CPU, a binding has no
meaning. Thus, if any deadlock exists then exists without binding too.
Hmm, you are talking about a deadlock caused by heavy CPU load? Is it
a deadlock at all? Anyhow, mutex is a lock with priority propagation,
isn't it?
Svata
Index: sys/i386/i386/pmap.c
===
--- sys/i386/i386/pmap.c (revision 246831)
+++ sys/i386/i386/pmap.c (working copy)
@@ -4146,11 +4146,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4171,11 +4171,11 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_zero_page_area: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M |
pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
@@ -4220,13 +4220,13 @@
{
struct sysmaps *sysmaps;
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP1)
panic(pmap_copy_page: CMAP1 busy);
if (*sysmaps-CMAP2)
panic(pmap_copy_page: CMAP2 busy);
- sched_pin();
invlpg((u_int)sysmaps-CADDR1);
invlpg((u_int)sysmaps-CADDR2);
*sysmaps-CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A |
@@ -5072,11 +5072,11 @@
vm_offset_t sva, eva;
if ((cpu_feature CPUID_CLFSH) != 0) {
+ sched_pin();
sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)];
mtx_lock(sysmaps-lock);
if (*sysmaps-CMAP2)
panic(pmap_flush_page: CMAP2 busy);
- sched_pin();
*sysmaps-CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) |
PG_A | PG_M | pmap_cache_bits(m-md.pat_mode, 0);
invlcaddr(sysmaps-CADDR2);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Mon, Feb 18, 2013 at 09:27:40PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 6:09 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: Hi, the access to sysmaps_pcpu[] should be atomic with respect to thread migration. Otherwise, a sysmaps for one CPU can be stolen by another CPU and the purpose of per CPU sysmaps is broken. A patch is enclosed. And, what are the problem caused by the 'otherwise' ? I do not see any. The 'otherwise' issue is the following: 1. A thread is running on CPU0. sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)]; 2. A sysmaps variable contains a pointer to 'CPU0' sysmaps. 3. Now, the thread migrates into CPU1. 4. However, the sysmaps variable still contains a pointers to 'CPU0' sysmaps. mtx_lock(sysmaps-lock); 4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the thread uselessly can block another thread running on CPU0. Maybe, it's not a problem. However, it definitely goes against the reason why the submaps (one for each CPU) exist. So what ? It depends. You don't understand it or you think it's ok? Tell me. Both. I do not understand your concern, and I think that the code is fine. Both threads in your description make useful progress, and computation proceeds correctly. Really, taking the mutex while bind to a CPU could be deadlock-prone under some situations. This was discussed at least one more time. Might be, a comment saying that there is no issue should be added. I missed the discussion. Can you point me to it, please? A deadlock is not problem here, however, I can be wrong, as I can't imagine now how a simple pinning could lead into a deadlock at all. Because some other load on the bind cpu might prevent the thread from being scheduled. I'm afraid I still have no idea. On single CPU, a binding has no meaning. Thus, if any deadlock exists then exists without binding too. Hmm, you are talking about a deadlock caused by heavy CPU load? Is it a deadlock at all? Anyhow, mutex is a lock with priority propagation, isn't it? When executing on single cpu, kernel sometimes make different decisions. Yes, the deadlock can be more precisely described as livelock. It might not make any matter for exactly this case, but still is useful to remember. pgpRzTWR25fZB.pgp Description: PGP signature
Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 09:27:40PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 6:09 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: Hi, the access to sysmaps_pcpu[] should be atomic with respect to thread migration. Otherwise, a sysmaps for one CPU can be stolen by another CPU and the purpose of per CPU sysmaps is broken. A patch is enclosed. And, what are the problem caused by the 'otherwise' ? I do not see any. The 'otherwise' issue is the following: 1. A thread is running on CPU0. sysmaps = sysmaps_pcpu[PCPU_GET(cpuid)]; 2. A sysmaps variable contains a pointer to 'CPU0' sysmaps. 3. Now, the thread migrates into CPU1. 4. However, the sysmaps variable still contains a pointers to 'CPU0' sysmaps. mtx_lock(sysmaps-lock); 4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the thread uselessly can block another thread running on CPU0. Maybe, it's not a problem. However, it definitely goes against the reason why the submaps (one for each CPU) exist. So what ? It depends. You don't understand it or you think it's ok? Tell me. Both. I do not understand your concern, and I think that the code is fine. Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... After this, I took a look at how PCPU stuff is used in whole kernel and found out mentioned here i386 pmap issue. So, my concern is following: 1. to verify my newly gained ideas how per CPU data should be used, 2. to decide how to change my implementation of pmap on ARM11mpcore, as it's based on i386 pmap, 3. to make FreeBSD code better. In the meanwhile, it looks that using data dedicated to one CPU on another one is OK. However, I can't agree. At least, without comments, it is misleading for anyone new in FreeBSD and makes code misty. Both threads in your description make useful progress, and computation proceeds correctly. I thought, there is only one thread in my example. One thread running on CPU1, but holding sysmaps dedicated to CPU0 instead of holding sysmaps dedicated to CPU1. So, any thread running on CPU0 must wait because the thread running on CPU1 is a thief. Futhermore, the idea that a thread on CPU1 should hold data for CPU1 is not valid. So, either some comment is missing in the code that it's OK or the using of PCPU_GET(cpuid) is unneeded and some kind of free sysmaps list can be used and it will serve better. Really, taking the mutex while bind to a CPU could be deadlock-prone under some situations. This was discussed at least one more time. Might be, a comment saying that there is no issue should be added. I missed the discussion. Can you point me to it, please? A deadlock is not problem here, however, I can be wrong, as I can't imagine now how a simple pinning could lead into a deadlock at all. Because some other load on the bind cpu might prevent the thread from being scheduled. I'm afraid I still have no idea. On single CPU, a binding has no meaning. Thus, if any deadlock exists then exists without binding too. Hmm, you are talking about a deadlock caused by heavy CPU load? Is it a deadlock at all? Anyhow, mutex is a lock with priority propagation, isn't it? When executing on single cpu, kernel sometimes make different decisions. Yes, the deadlock can be more precisely described as livelock. It might not make any matter for exactly this case, but still is useful to remember. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Possible bug in NFSv4 with krb5p security?
Elias Martenson wrote:
On 17 February 2013 22:58, Rick Macklem rmack...@uoguelph.ca wrote:
I think the Makefiles are in the kerberos5 directory.
Since the only function you care about is the one in
kerberos5/lib/libgssapi_krb5/pname_to_uid.c, I'd
just put a copy of that file in usr.sbin/gssd and
modify the Makefile there to compile it and link
its .o into gssd, avoiding rebuilding any libraries.
I'd put a couple of fprintf(stderr, ...) in it and
then run gssd -d and see what it says.
Just how I'd attack it, rick
Good news! The problem is solved!
You were right, the problem was in pname_to_uid.c. In it, the
following
code can be found:
char lname[MAXLOGNAME + 1], buf[1024];
/* some code snipped for brevity... */
getpwnam_r(lname, pwd, buf, sizeof(buf), pw);
if (pw) {
*uidp = pw-pw_uid;
return (GSS_S_COMPLETE);
} else {
return (GSS_S_FAILURE);
}
As it turns out, the getpwnam_r() call fails with ERANGE (I had to
check
the return value from getpwnam_r() in order to determine this, as pw
is set
to NULL both if there was an error or if the user name can't be
found).
Now, increasing the size of buf to 1024 solved the problem, and now
the
lookup works correctly.
I wrote a small test program that issued the same call to getpwnam_r()
and
it worked. Until I su'ed to root, and then it failed.
It seems as though the buffer needs to be bigger if you're root. I
have no
idea why, but there you have it. Problem solved.
Should this be fixed in the main codebase?
Yes, I would definitely say so.
I won't be able to do a commit until April, but meybe someone else
can do a commit sooner?
Oh, and thanks so much to all of you for being patient with me while
solving this. I really appreciate it. Also, I'd like to say that the
code
base was quite pleasant to work with. Thanks for that too. :-)
And thanks for working through this, so we now have a fix, rick
Regards,
Elias
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
netmap error (Unable to get if info for eth1)
Hi all, I am giving netmap a try and have tested it on my Realtech and Intel 1G NICs (by using r8169 and e1000e kernel modules), and it is working fine. However, I am facing problem while running it on my intel 10G NIC (82598EB 10-Gigabit AF Dual Port Network Connection). Whenever, I run the pkt-gen example with 10G interface, it shows me following error === sudo ./pkt-gen -i eth1 -f tx -l 60 extract_ip_range [119] extract IP range from 10.0.0.1 extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 extract_ip_range [119] extract IP range from 10.1.0.1 extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 extract_mac_range [135] extract MAC range from 00:1b:21:ce:f3:6a extract_mac_range [150] 00:1b:21:ce:f3:6a starts at 0:1b:21:ce:f3:6a extract_mac_range [135] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1053] map size is 207712 Kb main [1059] Unable to get if info for eth1 main [1066] bad nthreads 1, have 0 queues main [1075] mmapping 207712 Kbytes main [1094] Unable to register interface eth1 Sending on eth1: 0 queues, 1 threads and 1 cpus. 10.0.0.1 - 10.1.0.1 (00:1b:21:ce:f3:6a - ff:ff:ff:ff:ff:ff) main [1128] Wait 2 secs for phy reset main [1130] Ready... main [1181] Unable to register eth1 main [1242] 0 pps Sent 0 packets, 60 bytes each, in 0.00 seconds. === Any idea that what's going wrong here? Regards Tahir Rauf (+92) 312-7767761 -- This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individuals or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to this email. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netmap error (Unable to get if info for eth1)
On Mon, Feb 18, 2013 at 9:51 PM, Tahir Rauf tahir.ra...@gmail.com wrote: Hi all, I am giving netmap a try and have tested it on my Realtech and Intel 1G NICs (by using r8169 and e1000e kernel modules), and it is working fine. However, I am facing problem while running it on my intel 10G NIC (82598EB 10-Gigabit AF Dual Port Network Connection). Whenever, I run the pkt-gen example with 10G interface, it shows me following error likely you are running an unpatched version of the ixgbe driver. Does dmesg say anything about netmap when loading the ixgbe driver ? (also which version of the code are you using ? it seems you are running linux...) cheers luigi === sudo ./pkt-gen -i eth1 -f tx -l 60 extract_ip_range [119] extract IP range from 10.0.0.1 extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 extract_ip_range [119] extract IP range from 10.1.0.1 extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 extract_mac_range [135] extract MAC range from 00:1b:21:ce:f3:6a extract_mac_range [150] 00:1b:21:ce:f3:6a starts at 0:1b:21:ce:f3:6a extract_mac_range [135] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1053] map size is 207712 Kb main [1059] Unable to get if info for eth1 main [1066] bad nthreads 1, have 0 queues main [1075] mmapping 207712 Kbytes main [1094] Unable to register interface eth1 Sending on eth1: 0 queues, 1 threads and 1 cpus. 10.0.0.1 - 10.1.0.1 (00:1b:21:ce:f3:6a - ff:ff:ff:ff:ff:ff) main [1128] Wait 2 secs for phy reset main [1130] Ready... main [1181] Unable to register eth1 main [1242] 0 pps Sent 0 packets, 60 bytes each, in 0.00 seconds. === Any idea that what's going wrong here? Regards Tahir Rauf (+92) 312-7767761 -- This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individuals or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to this email. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netmap error (Unable to get if info for eth1)
Dear Luigui, Thanks for your prompt answer. Below I try to give complete information so that it becomes easy for you to identify the problem. *netmap version used*: 20120813 new unified source code for Linux and FreeBSD *System credentials:* O/S: Ubuntu 12.04 LTS machine: x86_64 processor: x86_64 O/S kernel version: #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 O/S kernel release: 3.2.0-32-generic *10G NIC used* product: 82598EB 10-Gigabit AF Dual Port Network Connection vendor: Intel Corporation physical id: 0 bus info: pci@:01:00.0 logical name: eth1 version: 01 serial: 00:1b:21:c1:6d:e3 width: 32 bits capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical fibre configuration: autonegotiation=off broadcast=yes driver=ixgbe driverversion=3.6.7-k duplex=full firmware=0xc1b3 latency=0 link=yes multicast=yes resources: irq:16 memory:f7ba-f7bb memory:f7b4-f7b7 ioport:e020(size=32) memory:f7bc4000-f7bc7fff *Pkt-gen command* sudo ./pkt-gen -i eth1 tx -n 500111222 -l 60 -w 5 *Output of pkt-gen program* tahir@tahir-desktop:~/Desktop/netmap-old/examples$ sudo ./pkt-gen -i eth1 tx -n 500111222 -l 60 -w 5 extract_ip_range [119] extract IP range from 10.0.0.1 extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 extract_ip_range [119] extract IP range from 10.1.0.1 extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 extract_mac_range [135] extract MAC range from 00:1b:21:c1:6d:e3 extract_mac_range [150] 00:1b:21:c1:6d:e3 starts at 0:1b:21:c1:6d:e3 extract_mac_range [135] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1053] map size is 207712 Kb main [1059] Unable to get if info for eth1 main [1066] bad nthreads 1, have 0 queues main [1075] mmapping 207712 Kbytes main [1094] Unable to register interface eth1 Receiving from eth1: 0 queues, 1 threads and 1 cpus. main [1128] Wait 5 secs for phy reset main [1130] Ready... main [1181] Unable to register eth1 main [1242] 0 pps Received 0 packets, in 0.00 seconds. Speed: -nanpps. *Sequence of commands used* sudo insmod netmap_lin.ko sudo rmmod ixgbe sudo insmod ixgbe/ixgbe.ko sudo ./pkt-gen -i eth1 tx -n 500111222 -l 60 -w 5 *Dmesg output* [82904.219757] 549.080148 netmap_new_obj_allocator [426] objsize 1024 clustsize 4096 objects 4 [82904.219837] 549.080229 netmap_new_obj_allocator [504] Pre-allocated 128 clusters (4/512KB) for 'netmap_if' [82904.219841] 549.080233 netmap_new_obj_allocator [426] objsize 36864 clustsize 36864 objects 1 [82904.221431] 549.081825 netmap_new_obj_allocator [504] Pre-allocated 200 clusters (36/7200KB) for 'netmap_ring' [82904.221436] 549.081833 netmap_new_obj_allocator [426] objsize 2048 clustsize 4096 objects 2 [82904.251034] 549.111513 netmap_new_obj_allocator [504] Pre-allocated 5 clusters (4/20KB) for 'netmap_buf' [82904.251038] 549.111520 netmap_memory_init [554] Have 512 KB for interfaces, 7200 KB for rings and 195 MB for buffers [82904.251039] netmap: loaded module with 202 Mbytes [82918.659224] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.6.7-k [82918.659228] ixgbe: Copyright (c) 1999-2011 Intel Corporation. [82918.659260] ixgbe :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [82918.659276] ixgbe :01:00.0: setting latency timer to 64 [82920.223583] ixgbe :01:00.0: irq 53 for MSI/MSI-X [82920.223592] ixgbe :01:00.0: irq 54 for MSI/MSI-X [82920.223597] ixgbe :01:00.0: irq 55 for MSI/MSI-X [82920.223603] ixgbe :01:00.0: irq 56 for MSI/MSI-X [82920.223608] ixgbe :01:00.0: irq 57 for MSI/MSI-X [82920.223614] ixgbe :01:00.0: irq 58 for MSI/MSI-X [82920.223619] ixgbe :01:00.0: irq 59 for MSI/MSI-X [82920.223625] ixgbe :01:00.0: irq 60 for MSI/MSI-X [82920.223630] ixgbe :01:00.0: irq 61 for MSI/MSI-X [82920.223649] ixgbe :01:00.0: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8 [82920.223797] ixgbe :01:00.0: (PCI Express:2.5GT/s:Width x8) 00:1b:21:c1:6d:e3 [82920.223871] ixgbe :01:00.0: MAC: 1, PHY: 7, SFP+: 0, PBA No: E37002-011 [82920.224934] ixgbe :01:00.0: Intel(R) 10 Gigabit Network Connection [82920.224957] ixgbe :01:00.1: PCI INT B - GSI 17 (level, low) - IRQ 17 [82920.224971] ixgbe :01:00.1: setting latency timer to 64 [82920.305560] ADDRCONF(NETDEV_UP): eth1: link is not ready [82920.306249] ADDRCONF(NETDEV_UP): eth1: link is not ready [82921.727292] ixgbe :01:00.1: irq 62 for MSI/MSI-X [82921.727301] ixgbe :01:00.1: irq 63 for MSI/MSI-X [82921.727307] ixgbe :01:00.1: irq 64 for MSI/MSI-X [82921.727313] ixgbe :01:00.1: irq 65 for MSI/MSI-X [82921.727319] ixgbe :01:00.1: irq 66 for MSI/MSI-X [82921.727324] ixgbe :01:00.1: irq 67 for MSI/MSI-X [82921.727330] ixgbe :01:00.1: irq 68 for MSI/MSI-X [82921.727336] ixgbe :01:00.1: irq 69 for MSI/MSI-X [82921.727341] ixgbe :01:00.1: irq 70 for MSI/MSI-X [82921.727359] ixgbe :01:00.1: Multiqueue Enabled: Rx Queue count = 8, Tx Queue
