[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

Ed Maste  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2182
   ||70
 CC||ema...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

Kubilay Kocak  changed:

   What|Removed |Added

 Resolution|FIXED   |Not Enough Information

--- Comment #47 from Kubilay Kocak  ---
Use more appropriate resolution (FIXED is for those issues resolved by a
change/commit)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #46 from Robert Watson  ---
I've opened a new #218270 for the sbsndptr() crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #45 from Mike Andrews  ---
As the guy that filed the original bug report almost 7 years ago, I'd tend to
agree with Robert Watson here.  I'll see if Bugzilla will let me close it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

Mike Andrews  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|Open|Closed

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #44 from Robert Watson  ---
It's probably best to be clear: the bugs being described by various reporters
over the years are *different* (and likely entirely *independent*) bugs that
happen to have the same visible symptom as a result of being detected by the
same check.  Putting these differences problems in the same open bug report,
and keeping it open, is very much like putting all kernel panics in the same
bug report because they share the word "panic" and involve a crash (which is
pretty much what is happening here). As a result, there's a bug report that
describes many different problems fixed in many different ways at many
different times, and is never closed. Not only that, but prior debugging may
shed no light on more recent problems, and could in fact obscure understanding,
since it's not progress being made on one bug, but observations of several
likely independent problems.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #43 from Kubilay Kocak  ---
@All For issues where the 'described problem' and the 'thing(s) that need to be
changed' are not one and the same, to retain all history/contextual information
and not cause confusion (renaming titles, etc), the correct process is as
follows:

1) Leave the 'original description/report of symptoms' issues 'as is'.
2) Create a blocking (depends on) issue for each area/component within FreeBSD
that requires a change/fix (em, igb, etc). Alternatively, if multiple areas
require fixing/changes but these will be resolved by a single person or
maintainer (the assignee), then a single blocking issue is fine.

Notes:

The assignee of the blocked (parent) issue (ie 'the original report') can be
changed to the person(s) responsible (assignee) to the blocking (sub) issue. 

Alternatively, the assignee of the parent issue can also be a person who wants
to/will 'see it through', coordinating and updating issue metadata until all
sub-tasks are closed, including any relevant MFC's and documentation tasks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #42 from Hiren Panchasara  ---
I've seen this happen on both em(4) which has only 1 queue and igb(4) which has
2.
It'd be interesting to see if new iflib'd em(4) (which has both em/igb) drivers
in -HEAD help in this regard.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #41 from e...@norma.perm.ru ---
May be it will be better just to change a subject, rather to lose all the
decent work here in comments ? Because closing such a bug will be really
discouraging, even if it's subject is misleading.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #40 from Ivan Klymenko  ---
(In reply to Robert Watson from comment #39)
I am afraid, that I can not add to new ticket tacking is nothing more, than has
been described in the above thread the mailing list.
In the same thread, I explained why I could not get more information about the
cause of panic.

Sorry.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #39 from Robert Watson  ---
FYI, I feel that this bug report ought to be closed, and a new and more
specific report opened on the IGB issue. The "sbdrop" panic is a generic
debugging invariant that catches a range of different bugs, and this report has
likely therefore encapsulated quite a few different bugs over the years, rather
than reflecting a single bug.

Can I recommend the creation of a new ticket tacking the presumed IGB
multi-queue issue specifically?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

Ivan Klymenko  changed:

   What|Removed |Added

 CC||fi...@ukr.net

--- Comment #38 from Ivan Klymenko  ---
I have the same problem:
http://docs.freebsd.org/cgi/mid.cgi?20170215093609.78a77ead
Head maillist: http://docs.freebsd.org/cgi/mid.cgi?20161021220413.1d130f5c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

Hiren Panchasara  changed:

   What|Removed |Added

 CC||s...@keff.org

--- Comment #37 from Hiren Panchasara  ---
*** Bug 147558 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

Greg Lund-Chaix  changed:

   What|Removed |Added

 CC||glundch...@gmail.com

--- Comment #36 from Greg Lund-Chaix  ---
(In reply to Daniel Bilik from comment #32)

I was seeing identical issues - panic/reboot every few hours when under network
load (rsync and zfs replication in this case) on 11.0-RELEASE.  Daniel's
suggested workaround setting "hw.igb.num_queues=1" in loader.conf has
stabilized the systems.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #35 from s...@zxy.spb.ru ---
(In reply to Hiren Panchasara from comment #34)
> which value of 'm' should I trust? is it null in frame #22 or not? it seems 
> like null in the frames above it also.

Зartially. ether_input call with m set to 0xf8014eee7600 (and this is first
m for next invocation of further functions), do one (or more, w/ different m,
need access to vmcore by kgdb and analyse 0xf8014eee7600 for answer)
iteration w/  and call netisr_dispatch with passed m as second argument (in
%rsi register). All next invocation can don't preserve %rsi (or %rdx in case of
m passed as 3'th argument) and backtrace can incorrectly decode arguments call.

Just realyty check: frame #19, ether_input_internal (ifp=,
m=0x0), line 483:

if (m->m_len < ETHER_HDR_LEN) {

MUST occur kernel panic if m realy NULL.

This is just incorrect decoding of arguments.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #34 from Hiren Panchasara  ---
(In reply to slw from comment #33)
Thanks but I am little confused.

which value of 'm' should I trust? is it null in frame #22 or not? it seems
like null in the frames above it also.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

s...@zxy.spb.ru changed:

   What|Removed |Added

 CC||s...@zxy.spb.ru

--- Comment #33 from s...@zxy.spb.ru ---
(In reply to Hiren Panchasara from comment #31)

> Most interesting frames are these 2:
> 
> #22 0x80a6c546 in ether_input (ifp=, m=0x0) at 
> /d2/hiren/freebsd/sys/net/if_ethersubr.c:759
> #23 0x804e2b3c in igb_rx_input (rxr=, 
> ifp=0xf80115614800, m=0xf8014eee7600, 
>ptype=) at /d2/hiren/freebsd/sys/dev/e1000/if_igb.c:4957
>
> #23 has an mbuf while #22 has it null.

> Does this point to your hunch of
> "device-driver bugs involving modifications to the mbuf chain after 
> submitting the mbuf to the network stack (e.g., due to concurrency bugs in 
> the device driver)" ?

This is just result of compiler optimisation and stack decoding.
Compiler use for m same register as passed at call time and do

while (m) {  
 mn = m->m_nextpkt;
[...]
 m = mn;
}

as result m (as decoded argument) will be incorectly displayed.
Actualy this is just last loop iteration with last mbuf in chain.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

Daniel Bilik  changed:

   What|Removed |Added

 CC||d...@neosystem.org

--- Comment #32 from Daniel Bilik  ---
(In reply to Robert Watson from comment #29)

> On the whole, my intuition is towards a device-driver bug based
> on past experience.

We've been also struggling this in past weeks, and I can confirm Robert's
intuition.

In our case, the bug affects two hosts running recent 10-STABLE, connected to
each other via igb(4) using a dedicated 100Mb switch. When trying to transfer
directory structure holding several gigabytes of data with rsync protocol,
either sender or receiver panics in less then a minute with:

Panic String: sbsndptr: sockbuf 0xf8000ccc76f8 and mbuf 0xf802a0145800
clashing

Interestingly, scp(1)ing data between the hosts doesn't seem to trigger this
panic such easily, but sometimes it does, mostly when copying larger (>1GB)
files.

We've fixed this just yesterday by limiting number of igb(4) txrx queues, ie.
adding this into loader.conf:

hw.igb.num_queues=1

Now the hosts run stable, periodically rsyncing data in both directions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #31 from Hiren Panchasara  ---
(In reply to Robert Watson from comment #29)

Robert,

Thanks for your response.

 On a slightly modified (nothing in driver space) stable/11, I am seeing
repeated panic in sbsndptr() with igb while box is pretty much idle or doing
very low traffic.

(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:221
#1  doadump (textdump=-2121667464) at
/d2/hiren/freebsd/sys/kern/kern_shutdown.c:298
#2  0x80389f86 in db_fncall_generic (nargs=0, addr=,
rv=, 
args=) at /d2/hiren/freebsd/sys/ddb/db_command.c:568
#3  db_fncall (dummy1=, dummy2=,
dummy3=, dummy4=)
at /d2/hiren/freebsd/sys/ddb/db_command.c:616
#4  0x80389a29 in db_command (last_cmdp=,
cmd_table=, 
dopager=) at /d2/hiren/freebsd/sys/ddb/db_command.c:440
#5  0x80389784 in db_command_loop () at
/d2/hiren/freebsd/sys/ddb/db_command.c:493
#6  0x8038c76b in db_trap (type=, code=)
at /d2/hiren/freebsd/sys/ddb/db_main.c:251
#7  0x809a6f33 in kdb_trap (type=, code=,
tf=)
at /d2/hiren/freebsd/sys/kern/subr_kdb.c:654
#8  0x80d93521 in trap_fatal (frame=0xfe1f2bb38210, eva=24)
at /d2/hiren/freebsd/sys/amd64/amd64/trap.c:836
#9  0x80d93753 in trap_pfault (frame=0xfe1f2bb38210, usermode=0)
at /d2/hiren/freebsd/sys/amd64/amd64/trap.c:691
#10 0x80d92cdc in trap (frame=0xfe1f2bb38210) at
/d2/hiren/freebsd/sys/amd64/amd64/trap.c:442
#11 
#12 sbsndptr (sb=0xf8060f8a5518, off=0, len=4294967287,
moff=0xfe1f2bb38420)
at /d2/hiren/freebsd/sys/kern/uipc_sockbuf.c:1191
#13 0x80ab9382 in tcp_output (tp=) at
/d2/hiren/freebsd/sys/netinet/tcp_output.c:1099
#14 0x80ab6105 in tcp_do_segment (m=, th=, so=0xf8060f8a5360, 
tp=, drop_hdrlen=60, tlen=, iptos=, 
ti_locked=)
at /d2/hiren/freebsd/sys/netinet/tcp_input.c:3182
#15 0x80ab2803 in tcp_input (mp=, offp=,
proto=)
at /d2/hiren/freebsd/sys/netinet/tcp_input.c:1444
#16 0x80aa6bc5 in ip_input (m=)
at /d2/hiren/freebsd/sys/netinet/ip_input.c:809
#17 0x80a82b35 in netisr_dispatch_src (proto=1, source=,
m=0x0)
at /d2/hiren/freebsd/sys/net/netisr.c:1120
#18 0x80a6c2ca in ether_demux (ifp=, m=0x0) at
/d2/hiren/freebsd/sys/net/if_ethersubr.c:850
#19 0x80a6cf22 in ether_input_internal (ifp=, m=0x0)
at /d2/hiren/freebsd/sys/net/if_ethersubr.c:639
#20 ether_nh_input (m=) at
/d2/hiren/freebsd/sys/net/if_ethersubr.c:669
#21 0x80a82b35 in netisr_dispatch_src (proto=5, source=,
m=0x0)
at /d2/hiren/freebsd/sys/net/netisr.c:1120
#22 0x80a6c546 in ether_input (ifp=, m=0x0) at
/d2/hiren/freebsd/sys/net/if_ethersubr.c:759
#23 0x804e2b3c in igb_rx_input (rxr=,
ifp=0xf80115614800, m=0xf8014eee7600, 
ptype=) at /d2/hiren/freebsd/sys/dev/e1000/if_igb.c:4957
#24 igb_rxeof (que=, count=358700136, done=)
at /d2/hiren/freebsd/sys/dev/e1000/if_igb.c:5185
#25 0x804e1daf in igb_msix_que (arg=) at
/d2/hiren/freebsd/sys/dev/e1000/if_igb.c:1612
#26 0x8091425f in intr_event_execute_handlers (p=,
ie=)
at /d2/hiren/freebsd/sys/kern/kern_intr.c:1262
#27 0x80914876 in ithread_execute_handlers (ie=,
p=)
at /d2/hiren/freebsd/sys/kern/kern_intr.c:1275
#28 ithread_loop (arg=) at
/d2/hiren/freebsd/sys/kern/kern_intr.c:1356
#29 0x80910ea5 in fork_exit (callout=0x809147b0 ,
arg=0xf8011561a0e0, 
frame=0xfe1f2bb38ac0) at /d2/hiren/freebsd/sys/kern/kern_fork.c:1040
#30 



Most interesting frames are these 2:

#22 0x80a6c546 in ether_input (ifp=, m=0x0) at
/d2/hiren/freebsd/sys/net/if_ethersubr.c:759
#23 0x804e2b3c in igb_rx_input (rxr=,
ifp=0xf80115614800, m=0xf8014eee7600, 
ptype=) at /d2/hiren/freebsd/sys/dev/e1000/if_igb.c:4957

#23 has an mbuf while #22 has it null.

Does this point to your hunch of
"device-driver bugs involving modifications to the mbuf chain after submitting
the mbuf to the network stack (e.g., due to concurrency bugs in the device
driver)" ?

OR something else is going on?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #30 from e...@norma.perm.ru ---
Follow-up: RC3 was installed incorrectly (i.e. not installed at all). After
proper RC3 downgrade (r305786) seems like server is at least more stable - it
runs for more than an hour. On 11.0-PRE (306739) panics were happening in like
3 to 5 minutes.

I have a handful of cores, in case someone needs them.

As about the driver. This was a HP DL160 g6 I guess and the driver was igb(4).
Now it's the Supermicro board (tech team switched the drives to a new chassis
to exclude possible hardware problems) and the ifconfig/dmesg.boot are as
folows (the driver is still an igb(4)), and the dmesg is from 11-RC3:

igb0: flags=8843 metric 0 mtu 1500
   
options=6403bb
ether 00:25:90:06:b7:9e
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
igb1: flags=8c02 metric 0 mtu 1500
   
options=6403bb
ether 00:25:90:06:b7:9f
nd6 options=29
media: Ethernet autoselect
status: no carrier
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
nd6 options=21
groups: lo
vlan1: flags=8843 metric 0 mtu 1500
options=303
ether 00:25:90:06:b7:9e
inet 192.168.0.248 netmask 0xff00 broadcast 192.168.0.255
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
vlan: 1 vlanpcp: 0 parent interface: igb0
groups: vlan
vlan2: flags=8843 metric 0 mtu 1500
options=303
ether 00:25:90:06:b7:9e
inet 91.206.242.1 netmask 0xfff0 broadcast 91.206.242.15
inet 91.206.242.5 netmask 0xfff0 broadcast 91.206.242.15
inet 91.206.242.8 netmask 0xfff0 broadcast 91.206.242.15
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
vlan: 2 vlanpcp: 0 parent interface: igb0
groups: vlan
vlan3: flags=8843 metric 0 mtu 1500
options=303
ether 00:25:90:06:b7:9e
inet 10.64.0.250 netmask 0xff00 broadcast 10.64.0.255
inet 10.64.0.252 netmask 0xff00 broadcast 10.64.0.255
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
vlan: 3 vlanpcp: 0 parent interface: igb0
groups: vlan
vlan4: flags=8843 metric 0 mtu 1500
options=303
ether 00:25:90:06:b7:9e
inet 89.250.210.6 netmask 0xfffc broadcast 89.250.210.7
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
vlan: 4 vlanpcp: 0 parent interface: igb0
groups: vlan
vlan5: flags=8843 metric 0 mtu 1500
options=303
ether 00:25:90:06:b7:9e
inet 77.43.142.201 netmask 0xfffc broadcast 77.43.142.203
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
vlan: 5 vlanpcp: 0 parent interface: igb0
groups: vlan
vlan6: flags=8843 metric 0 mtu 1500
options=303
ether 00:25:90:06:b7:9e
inet 172.20.142.250 netmask 0xff00 broadcast 172.20.142.255
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
vlan: 6 vlanpcp: 0 parent interface: igb0
groups: vlan
vlan7: flags=8843 metric 0 mtu 1500
options=303
ether 00:25:90:06:b7:9e
inet 172.16.240.2 netmask 0xff00 broadcast 172.16.240.255
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
vlan: 7 vlanpcp: 0 parent interface: igb0
groups: vlan
vlan8: flags=8843 

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #29 from Robert Watson  ---
Just a quick comment in light of recent notes on this PR: the panic being seen
is as a result of a kernel self-check that occurs on socket close, and likely
reports on a bug that triggered some substantial time earlier (milliseconds,
seconds, minutes, hours, days, or even weeks earlier), and reports on a class
of problems rather than detecting a specific bug. It's entirely likely that the
problem reported more recently is not the same bug as those reported previously
with the same panic message -- rather, a similar bug with the same kernel
self-check detecting it.

In the past, this self-check has most frequently fired as a result of either
bugs in the socket-buffer code (although I think none recently), or
device-driver bugs involving modifications to the mbuf chain after submitting
the mbuf to the network stack (e.g., due to concurrency bugs in the device
driver). It can also occur in use-after-free scenarios, as a result of protocol
bugs, etc.

On the whole, my intuition is towards a device-driver bug based on past
experience. Could you paste in the output of "dmesg" and "ifconfig -a" from the
host to give a bit more information on its configuration?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

e...@norma.perm.ru changed:

   What|Removed |Added

 CC||e...@norma.perm.ru

--- Comment #28 from e...@norma.perm.ru ---
Got this right now on an update from 10.2-STABLE to 11.0-PRERELEASE. Persistent
in 11.0-RC3. Repeatable in like 5-12 minutes. 25 minutes is an absolute record.

panic: sbsndptr: sockbuf 0xf8003eea31b8 and mbuf 0xf80020a6e700
clashing

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: sbsndptr: sockbuf 0xf8003eea31b8 and mbuf 0xf80020a6e700
clashing
cpuid = 1
KDB: stack backtrace:
#0 0x80b1d0c7 at kdb_backtrace+0x67
#1 0x80ad1f62 at vpanic+0x182
#2 0x80ad1dd3 at panic+0x43
#3 0x80b6a15a at sbsndptr+0xda
#4 0x80cfcbb4 at tcp_output+0xf34
#5 0x80cf9a81 at tcp_do_segment+0x2ce1
#6 0x80cf60cc at tcp_input+0xd1c
#7 0x80c66dbf at ip_input+0x15f
#8 0x80bfc295 at netisr_dispatch_src+0xa5
#9 0x80be4cea at ether_demux+0x12a
#10 0x80be5942 at ether_nh_input+0x322
#11 0x80bfc295 at netisr_dispatch_src+0xa5
#12 0x80be4f66 at ether_input+0x26
#13 0x80bed9db at vlan_input+0x1cb
#14 0x80be4c55 at ether_demux+0x95
#15 0x80be5942 at ether_nh_input+0x322
#16 0x80bfc295 at netisr_dispatch_src+0xa5
#17 0x80be4f66 at ether_input+0x26

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

--- Comment #27 from Mike Andrews  ---
For what it's worth, the original problem I reported in this PR from 6 years
ago is (for me anyway) long-ago solved... but then we're on 10.3 these days and
are slowly rolling 11-beta out.  Haven't seen a panic in quite a while.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||mfc-stable9?, mfc-stable11?
Summary|[panic] |[panic] "panic: sbdrop" and
   |8.1-RELEASE/10.1-STABLE |"panic: sbsndptr: sockbuf _
   |"panic: sbdrop" and "panic: |and mbuf _ clashing"
   |sbsndptr: sockbuf _ and |(8.1-RELEASE/10.1-STABLE/11
   |mbuf _ clashing"|-CURRENT)

--- Comment #26 from Kubilay Kocak  ---
Update mfc flags and summary to reflect latest information.

@Hiren, is this likely to affect 11.0-R ? If so, please cc re@ so they're aware
and can track

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"