reproducible kernel panic on CURRENT, I/O related

[Johannes Dieterich]

Dear all,

since approximately three weeks I am seeing kernel panics on CURRENT
that are in so far reproducible as that they typically occur when I
run svn up on the ports tree. Hence, it seems I/O related to me. Sorry
that I only now got around to reporting it!

The system is a CURRENT amd64 running ZFS on root w/ GELI. It has the
aesni kernel module loaded. The world and kernel are on SVN r285764.

The kernel stack backtrace looks as follows (transcript):

db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe03d0394830
vpanic() at vpanic+0x189/frame 0xe03d03948b0
panic() at panic+0x43/frame 0xfe03d0394910
trash_ctor() at trash_ctor+0x48/frame 0xfe03d0394920
uma_zalloc_arg() at uma_zalloc_arg+0x573/frame 0xfe03d0394990
g_clone_bio() at g_clone_bio+0x1d/frame 0xfe03d03949b0
g_part_start() at g_part_start+0x8e/frame 0xfe03d0394a30
g_io_schedule_down() at g_io_schedule_down+0xe6/frame 0xfe03d0394a60
g_down_procbody() at g_down_procbody+0x7d/frame 0xfee03d0394a70
fork_exit() at fork_exit+0x84/frame 0xfe03d0394ab0
fork_trampoline at fork_trampoline+0xe/frame 0xfe03d0394ab0
--- trap 0, rip = 0, rsp =0xfe03d0394b90, rbp = 0---
KDB: enter: panic
[ thread pid 13 tid 100017 ]
Stopped at kdb_enter+0x3e: movq $0,kdb_why

Due to above setup, I cannot provide a core file, sorry.

Please let me know if there is any data you want me to obtain for
debugging. As I said above, it is fairly simple for me to hit the
panic.

Best

Johannes
___
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: "proper way" or "unworkable idea" ? > [SOLVED]

[Jeffrey Bouquet]

On Tue, 30 Jun 2015 20:54:07 +0200, Willem Jan Withagen  
wrote:

> On 30/06/2015 17:32, Simon J. Gerraty wrote:
> > Jeffrey Bouquet  wrote:
> > 
> >> If I've a spare /mnt/usr/src , it seems buildworld quite soon fails,
> >> where it otherwise may succeed in /usr/src. Any CLI parameters or> the
> >> build system is hardcoded enough so that there will always be
> >> problems?
> > 
> > The only thing hard coded is the default MAKEOBJDIRPREFIX (it isn't
> > called that but it works the same way), but even that should work for any
> > location. I always have MAKEOBJDIRPREFIX when doing buildworld etc,
> > and have never used /usr/src.
> > 
> > Is there perhaps something interesting about /mnt/usr/src (like
> > ancient?)
> 
> On some of the systems where I use different versions, I have
>   /usr/srcs
> mounted of the NFS-server. in which I have.
>   /usr/srcs/src8/src
>   /usr/srcs/src9/src
>   /usr/srcs/src10/src
>   /usr/srcs/head/src
> 
> Then also have /usr/objs mounted, with the same setup
> 
> And on the remote systems link /usr/src -> /usr/srcs/src??/src and same
> for obj
> 
> I have yet to run into trouble when I do the normal things. It gets
> messy if I'd like to build both i386 and amd64 in the same obj-tree.
> That does not always work, but adding a differentiating i386 and amd64
> to the hierarchy seemed to fix it. But I retired all but one i386, and
> that is soon to follow.
> 
> --WjW
> 
> 
> 
> 
> ___
> 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"


Using a r285418 (july 12), rsynced /usr/obj and /usr/src  ( precise howto
found in the motd where I store stuff... cp -Rp that is) 

# cp -Rp /mnt_usr/obj/usr/src /usr/obj/usr  # /usr as a seperate filesystem
  ... note 4 > 3
# cp -Rp /mnt_usr/src /usr # /usr as a seperate filesystem
 ... note  2 > 1 

the MAKEOBJDIRPREFIX seems to be working for the first time ever.  Cntl-c'd it 
since
the installkernel/installworld did the upgrade...  so something was fixed.  
Could probably
comtinue with the MAKEOBJDIRPREFIX  buildworld if I was sure (doubly sure) 
how to install from
the "different" location to the "usual" one...  without a hitch.  So that may 
come later this
year... unless something else breaks the specific build environment which 
caused this
thread, which appears SOLVED...
___
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: null pointer dereference panic in cap_rights_contains() on 11.0-CURRENT r285785 amd64

[Mateusz Guzik]

On Fri, Jul 24, 2015 at 02:07:17AM +0300, Sergey Kandaurov wrote:
> On 24 July 2015 at 01:24, Don Lewis  wrote:
> > I just got this panic while using poudriere to build packages for
> > FreeBSD 8.4 i386.
> [..]
> > db> bt
> > Tracing pid 78211 tid 101405 td 0xf80139td29a0
> > cap_rights_contains() at cap_rights_contains+0x24/frame
> > 0xfe005acc772d0
> > cap_check() at cap_check+0x15/frame 0xfe005acc7800
> > fget_unlocked() at fget_unlocked+0xca/frame 0xfe005acc7870
> > fget() at fget+0x2b/frame 0xfe005acc78a0
> > ksem_get at ksem_get+0x1e/frame 0xfe05acc78e0
> > sys_ksem_close() at sys_ksem_close+0x23/frame 0xfe005acc7920
> > ia32_syscall() at ia32_syscall+0x2a5/frame 0xfe005acc7a30
> > Xint0x00_syscall() at Xint0x00_syscall+0x95/frame 0xfe00acc7a30
> > --- syscall (400, FreeBSD ELF32, sys_ksem_close), rip = 0x2828676b, rsp
> > = 0xc60c, rbp = 0xc628 ---
> >
> >
> 
> Looks like this was missed after r284442.
> 
> Index: kern/uipc_sem.c
> ===
> --- kern/uipc_sem.c(revision 285723)
> +++ kern/uipc_sem.c(working copy)
> @@ -651,12 +651,13 @@
>  int
>  sys_ksem_close(struct thread *td, struct ksem_close_args *uap)
>  {
> +cap_rights_t rights;
>  struct ksem *ks;
>  struct file *fp;
>  int error;
> 
>  /* No capability rights required to close a semaphore. */
> -error = ksem_get(td, uap->id, 0, &fp);
> +error = ksem_get(td, uap->id, cap_rights_init(&rights), &fp);
>  if (error)
>  return (error);
>  ks = fp->f_data;
> @@ -872,12 +873,13 @@
>  int
>  sys_ksem_destroy(struct thread *td, struct ksem_destroy_args *uap)
>  {
> +cap_rights_t rights;
>  struct file *fp;
>  struct ksem *ks;
>  int error;
> 
>  /* No capability rights required to close a semaphore. */
> -error = ksem_get(td, uap->id, 0, &fp);
> +error = ksem_get(td, uap->id, cap_rights_init(&rights), &fp);
>  if (error)
>  return (error);
>  ks = fp->f_data;
> 
> 

Correct, please commit.

-- 
Mateusz Guzik 
___
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: null pointer dereference panic in cap_rights_contains() on 11.0-CURRENT r285785 amd64

[Sergey Kandaurov]

On 24 July 2015 at 01:24, Don Lewis  wrote:
> I just got this panic while using poudriere to build packages for
> FreeBSD 8.4 i386.
[..]
> db> bt
> Tracing pid 78211 tid 101405 td 0xf80139td29a0
> cap_rights_contains() at cap_rights_contains+0x24/frame
> 0xfe005acc772d0
> cap_check() at cap_check+0x15/frame 0xfe005acc7800
> fget_unlocked() at fget_unlocked+0xca/frame 0xfe005acc7870
> fget() at fget+0x2b/frame 0xfe005acc78a0
> ksem_get at ksem_get+0x1e/frame 0xfe05acc78e0
> sys_ksem_close() at sys_ksem_close+0x23/frame 0xfe005acc7920
> ia32_syscall() at ia32_syscall+0x2a5/frame 0xfe005acc7a30
> Xint0x00_syscall() at Xint0x00_syscall+0x95/frame 0xfe00acc7a30
> --- syscall (400, FreeBSD ELF32, sys_ksem_close), rip = 0x2828676b, rsp
> = 0xc60c, rbp = 0xc628 ---
>
>

Looks like this was missed after r284442.

Index: kern/uipc_sem.c
===
--- kern/uipc_sem.c(revision 285723)
+++ kern/uipc_sem.c(working copy)
@@ -651,12 +651,13 @@
 int
 sys_ksem_close(struct thread *td, struct ksem_close_args *uap)
 {
+cap_rights_t rights;
 struct ksem *ks;
 struct file *fp;
 int error;

 /* No capability rights required to close a semaphore. */
-error = ksem_get(td, uap->id, 0, &fp);
+error = ksem_get(td, uap->id, cap_rights_init(&rights), &fp);
 if (error)
 return (error);
 ks = fp->f_data;
@@ -872,12 +873,13 @@
 int
 sys_ksem_destroy(struct thread *td, struct ksem_destroy_args *uap)
 {
+cap_rights_t rights;
 struct file *fp;
 struct ksem *ks;
 int error;

 /* No capability rights required to close a semaphore. */
-error = ksem_get(td, uap->id, 0, &fp);
+error = ksem_get(td, uap->id, cap_rights_init(&rights), &fp);
 if (error)
 return (error);
 ks = fp->f_data;


-- 
wbr,
pluknet
___
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"

null pointer dereference panic in cap_rights_contains() on 11.0-CURRENT r285785 amd64

[Don Lewis]

I just got this panic while using poudriere to build packages for
FreeBSD 8.4 i386.  This is hand transcribed because I was not able to
get a core file.

Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 16
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80a51e14
stack pointer   = 0x20:0xfe005acc77a0
frame pointer   = 0x20:0xfe005acc77d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 78211 (initial thread)
[ thread pid 78211 tid 101405 ]
Stopped at  cap_rights_contains+0x24:   movq(%r14),%rcx)
db> bt
Tracing pid 78211 tid 101405 td 0xf80139td29a0
cap_rights_contains() at cap_rights_contains+0x24/frame
0xfe005acc772d0
cap_check() at cap_check+0x15/frame 0xfe005acc7800
fget_unlocked() at fget_unlocked+0xca/frame 0xfe005acc7870
fget() at fget+0x2b/frame 0xfe005acc78a0
ksem_get at ksem_get+0x1e/frame 0xfe05acc78e0
sys_ksem_close() at sys_ksem_close+0x23/frame 0xfe005acc7920
ia32_syscall() at ia32_syscall+0x2a5/frame 0xfe005acc7a30
Xint0x00_syscall() at Xint0x00_syscall+0x95/frame 0xfe00acc7a30
--- syscall (400, FreeBSD ELF32, sys_ksem_close), rip = 0x2828676b, rsp
= 0xc60c, rbp = 0xc628 ---


# kgdb /boot/kernel/kernel /dev/kmem
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"...
Failed to open vmcore: cannot mmap corefile
(kgdb) list cap_rights_contains+0x24
Junk at end of line specification.
(kgdb) list *cap_rights_contains+0x24
0x80a51e14 is in cap_rights_contains 
(/usr/src/sys/kern/subr_capability.c:294).
289 cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little)
290 {
291 unsigned int i, n;
292 
293 assert(CAPVER(big) == CAP_RIGHTS_VERSION_00);
294 assert(CAPVER(little) == CAP_RIGHTS_VERSION_00);
295 assert(CAPVER(big) == CAPVER(little));
296 
297 n = CAPARSIZE(big);
298 assert(n >= CAPARSIZE_MIN && n <= CAPARSIZE_MAX);
(kgdb) 


This machine has mirrored swap and dumpdev=AUTO.  Calling doadump in ddb
seemed to dump memory contents somewhere, but savecore wasn't able to
find it.

___
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: Kernel Application Binary Interface (kABI) support in FreeBSD

[Julian Elischer]

On 7/23/15 6:06 PM, Venkat Duvvuru wrote:

I will debug this crash.
At this point, my concern is not about debugging this particular 
issue but whether to commit to our customers or not about the binary 
compatibility of FreeBSD X.0 drivers with all FreeBSD X.Y OS versions.
I would like to stay safe and tell the customers to build the 
drivers on their respective revisions unless you folks think that 
the binary compatibility is maintained very strictly and this is one 
of those rare bugs.
this is supposed to be possible but whether it actually is depends to 
some extent on whether the code in  question is considered likely to 
be directly callable by a third party module. Most interfaces that are 
likely to be called from network and storage drivers willb e very 
stable, as will scheduler interfaces and things like task queues and 
thread creation. the more esoteric the more likely that an 
incompatibility can be committed and not caught.




Please let me know.


well, what are you doing?



Thanks,
Venkat.

On Wed, Jul 22, 2015 at 8:33 PM, Julian Elischer > wrote:


On 7/22/15 2:56 PM, Venkat Duvvuru wrote:

I have this setup where FreeBSD 9.0 OCE driver is loaded on
FreeBSD 9.3. The OCE module loads just fine but when the
interface is brought up, the system crashes. This happens
everytime I bring the interface up.
The backtraces are attached with this email.
However, if I build the same driver on 9.3, everything works
just fine.


then that is a bug.
Unfortunately I'm not your man for helping you find it at the
moment.
Do you now how to run a kernel under GDB?
(either in a VM or with serial console (or firewire if you have
it))
There is a handbook section on doing this.
You might look at trying to see what actually goes wrong with
the help of GDB.




___
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: MS DNS doesn't answer to CURRENT under Hyper-V

[Wei Hu]

The TCP offloading is still working on these platforms. There is no flag to 
distinguish UDP and TCP offloading, so the RXCSUM and TXCSUM are still set. Let 
me know if there is any other way to show it properly.

Thanks,
Wei


-Original Message-
From: Pavel Timofeev [mailto:tim...@gmail.com] 
Sent: Wednesday, July 22, 2015 9:04 PM
To: Wei Hu 
Cc: Slawa Olhovchenkov ; freebsd-current@freebsd.org; 
freebsd-virtualizat...@freebsd.org
Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V

Hi! I see you have done the code for disabling UDP checksum offloading when 
running on the Hyper-V on Windows Server 2012 and earlier hosts

https://svnweb.freebsd.org/base?view=revision&revision=285785

I tried new CURRENT and it works. Thank you!

A small note here: while it disables and works it still shows RXCSUM and TSCSUM 
in iface's options:

root@proxy:/usr/src # ifconfig hn0
hn0: flags=8843 metric 0 mtu 1500
options=31b
ether 00:15:5d:02:9c:09
inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63
nd6 options=29

Is it possible to hide it automatically if it's disabled by new code?


2015-07-13 11:06 GMT+03:00 Wei Hu :
> We have root caused the problem. This issue happens on the Hyper-Vs on 
> Windows Server 2012 (Win 8.0) and earlier releases. On these releases, the 
> UPD checksum offloading on host side does not work properly. The workaround 
> is to disable UPD checksum offloading in the FreeBSD guest through 
> 'ifconfig'. We are also working on a patch to turn off UPD checksum 
> offloading in the netvsc driver when detecting the Hyper-V releases.
>
> The UDP checksum offloading works fine on Windows Server 2012R2 and Win 8.1 
> hosts.
>
> Thanks Pavel and Slawa for the support.
>
> Wei
>
>
>> -Original Message-
>> From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd- 
>> virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
>> Sent: Wednesday, July 8, 2015 4:06 PM
>> To: Slawa Olhovchenkov
>> Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
>> Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V
>>
>> Ok, r284746 is the root of the problem. MS DNS works under r284745 
>> and doesn't work under r284746.
>> Slawa, what should I look at in wireshark output?
>>
>>
>> 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov :
>> > On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote:
>> >
>> >> Well, turning off checksum offloading by `ifconfig hn0 -txcsum 
>> >> -rxcsum` definitely helps.
>> >>
>> >> As for tcpdump I'm not completely sure if I did it right, but I 
>> >> see "bad udp cksum" phrase:
>> >>
>> >> # tcpdump -i hn0 -vvv -nn udp dst port 53
>> >> tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture 
>> >> size
>> >> 262144 bytes
>> >> 18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags 
>> >> [none], proto UDP (17), length 51)
>> >> 192.168.25.26.45683 > 192.168.25.3.53: [bad udp cksum 0xb39e 
>> >> -> 0xf210!] 52886+ A? ya.ru. (23)
>> >> 18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags 
>> >> [none], proto UDP (17), length 51)
>> >> 192.168.25.26.12575 > 192.168.25.3.53: [bad udp cksum 0xb39e 
>> >> -> 0x7365!] 52886+ A? ya.ru. (23)
>> >
>> > tcpdump "bad udp cksum" is normal on FreeBSD host in case checksum 
>> > offload (and may be need only for help finding issuse in code). 
>> > Need wireshark capturing from MS DNS host (or from mirroring port).
>> ___
>> freebsd-virtualizat...@freebsd.org mailing list 
>> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
>> To unsubscribe, send any mail to "freebsd-virtualization- 
>> 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: Kernel Application Binary Interface (kABI) support in FreeBSD

[Venkat Duvvuru]

I will debug this crash.
At this point, my concern is not about debugging this particular issue but
whether to commit to our customers or not about the binary compatibility of
FreeBSD X.0 drivers with all FreeBSD X.Y OS versions.
I would like to stay safe and tell the customers to build the drivers on
their respective revisions unless you folks think that the binary
compatibility is maintained very strictly and this is one of those rare
bugs.

Please let me know.

Thanks,
Venkat.

On Wed, Jul 22, 2015 at 8:33 PM, Julian Elischer  wrote:

>  On 7/22/15 2:56 PM, Venkat Duvvuru wrote:
>
> I have this setup where FreeBSD 9.0 OCE driver is loaded on FreeBSD 9.3.
> The OCE module loads just fine but when the interface is brought up, the
> system crashes. This happens everytime I bring the interface up.
> The backtraces are attached with this email.
> However, if I build the same driver on 9.3, everything works just fine.
>
>  then that is a bug.
> Unfortunately I'm not your man for helping you find it at the moment.
> Do you now how to run a kernel under GDB?
> (either in a VM or with serial console (or firewire if you have it))
> There is a handbook section on doing this.
> You might look at trying to see what actually goes wrong with the help of
> GDB.
>
>
>
>___
>>> 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"

IPSEC stop works after r285336

[Alexandr Krivulya]

I have IPSEC tunnel inside l2tp tunnel via mpd. After r285536 I see only
outgoing esp packets on ng interface:

root@thinkpad:/usr/src # tcpdump -i ng0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng0, link-type NULL (BSD loopback), capture size 262144 bytes
10:35:27.331886 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9a5), length 140
10:35:28.371707 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9a6), length 140
10:35:29.443536 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9a7), length 140
10:35:30.457370 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9a8), length 140
10:35:31.475606 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9a9), length 140
10:35:31.622315 IP 10.10.10.1.isakmp > 10.10.10.2.isakmp: isakmp: phase
2/others ? inf[E]
10:35:31.622544 IP 10.10.10.2.isakmp > 10.10.10.1.isakmp: isakmp: phase
2/others ? inf[E]
10:35:31.622658 IP 10.10.10.2.isakmp > 10.10.10.1.isakmp: isakmp: phase
2/others ? inf[E]
10:35:31.623933 IP 10.10.10.1.isakmp > 10.10.10.2.isakmp: isakmp: phase
2/others ? inf[E]
10:35:32.492349 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9aa), length 140
10:35:33.509346 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9ab), length 140
10:35:34.527187 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9ac), length 140
10:35:35.539600 IP 10.10.10.2 > 10.10.10.1:
ESP(spi=0x03081e58,seq=0x9ad), length 140

With r285535 all works fine.
___
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: MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

Ok, sorry!

2015-07-23 7:51 GMT+03:00 Wei Hu :
> The TCP offloading is still working on these platforms. There is no flag to 
> distinguish UDP and TCP offloading, so the RXCSUM and TXCSUM are still set. 
> Let me know if there is any other way to show it properly.
>
> Thanks,
> Wei
>
>
> -Original Message-
> From: Pavel Timofeev [mailto:tim...@gmail.com]
> Sent: Wednesday, July 22, 2015 9:04 PM
> To: Wei Hu 
> Cc: Slawa Olhovchenkov ; freebsd-current@freebsd.org; 
> freebsd-virtualizat...@freebsd.org
> Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V
>
> Hi! I see you have done the code for disabling UDP checksum offloading when 
> running on the Hyper-V on Windows Server 2012 and earlier hosts
>
> https://svnweb.freebsd.org/base?view=revision&revision=285785
>
> I tried new CURRENT and it works. Thank you!
>
> A small note here: while it disables and works it still shows RXCSUM and 
> TSCSUM in iface's options:
>
> root@proxy:/usr/src # ifconfig hn0
> hn0: flags=8843 metric 0 mtu 1500
> options=31b
> ether 00:15:5d:02:9c:09
> inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63
> nd6 options=29
>
> Is it possible to hide it automatically if it's disabled by new code?
>
>
> 2015-07-13 11:06 GMT+03:00 Wei Hu :
>> We have root caused the problem. This issue happens on the Hyper-Vs on 
>> Windows Server 2012 (Win 8.0) and earlier releases. On these releases, the 
>> UPD checksum offloading on host side does not work properly. The workaround 
>> is to disable UPD checksum offloading in the FreeBSD guest through 
>> 'ifconfig'. We are also working on a patch to turn off UPD checksum 
>> offloading in the netvsc driver when detecting the Hyper-V releases.
>>
>> The UDP checksum offloading works fine on Windows Server 2012R2 and Win 8.1 
>> hosts.
>>
>> Thanks Pavel and Slawa for the support.
>>
>> Wei
>>
>>
>>> -Original Message-
>>> From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd-
>>> virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
>>> Sent: Wednesday, July 8, 2015 4:06 PM
>>> To: Slawa Olhovchenkov
>>> Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
>>> Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V
>>>
>>> Ok, r284746 is the root of the problem. MS DNS works under r284745
>>> and doesn't work under r284746.
>>> Slawa, what should I look at in wireshark output?
>>>
>>>
>>> 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov :
>>> > On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote:
>>> >
>>> >> Well, turning off checksum offloading by `ifconfig hn0 -txcsum
>>> >> -rxcsum` definitely helps.
>>> >>
>>> >> As for tcpdump I'm not completely sure if I did it right, but I
>>> >> see "bad udp cksum" phrase:
>>> >>
>>> >> # tcpdump -i hn0 -vvv -nn udp dst port 53
>>> >> tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture
>>> >> size
>>> >> 262144 bytes
>>> >> 18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags
>>> >> [none], proto UDP (17), length 51)
>>> >> 192.168.25.26.45683 > 192.168.25.3.53: [bad udp cksum 0xb39e
>>> >> -> 0xf210!] 52886+ A? ya.ru. (23)
>>> >> 18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags
>>> >> [none], proto UDP (17), length 51)
>>> >> 192.168.25.26.12575 > 192.168.25.3.53: [bad udp cksum 0xb39e
>>> >> -> 0x7365!] 52886+ A? ya.ru. (23)
>>> >
>>> > tcpdump "bad udp cksum" is normal on FreeBSD host in case checksum
>>> > offload (and may be need only for help finding issuse in code).
>>> > Need wireshark capturing from MS DNS host (or from mirroring port).
>>> ___
>>> freebsd-virtualizat...@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
>>> To unsubscribe, send any mail to "freebsd-virtualization-
>>> 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"