Re: 7.99.42/Nov 2 panic: kernel diagnostic assertion "l->l_md.md_gc_ptp == NULL" failed

[coypu]

49691

Re: ffs_newvnode: inode has non zero blocks

[Andreas Gustafsson]

Earlier, I wrote:
> Also, I have now narrowed down the appearance of the problem on the
> testbed to the following commit:
> 
>   2016.10.30.15.01.46 christos src/sys/ufs/ffs/ffs_alloc.c 1.154
> 
> The mystery remains because the commit message says there should be no
> functional change, and I also did a quick review of the diff and did
> not spot anything that could be a cause of the panic.

I have now also run a bisection of this on my own testbed, and it
identified a different commits than the TNF testbed did:

  2016.10.28.20.38.12 jdolecek src/sys/kern/vfs_wapbl.c 1.85
  2016.10.28.20.38.12 jdolecek src/sys/sys/wapbl.h 1.19
  2016.10.28.20.38.12 jdolecek src/sys/ufs/ffs/ffs_alloc.c 1.153
  2016.10.28.20.38.12 jdolecek src/sys/ufs/ffs/ffs_inode.c 1.118
  2016.10.28.20.38.12 jdolecek src/sys/ufs/ffs/ffs_snapshot.c 1.143
  2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_extern.h 1.83
  2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_inode.c 1.97
  2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_rename.c 1.13
  2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_vnops.c 1.233
  2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_wapbl.h 1.12

More data at:

  
http://releng.netbsd.org/b5reports/sparc/commits-2016.10.html#2016.10.30.15.01.46
  
http://www.gson.org/netbsd/bugs/build/sparc/commits-2016.10.html#2016.10.28.20.38.12

-- 
Andreas Gustafsson, g...@gson.org

Re: 7.99.42/Nov 2 panic: kernel diagnostic assertion "l->l_md.md_gc_ptp == NULL" failed

[Thomas Klausner]

On Mon, Nov 07, 2016 at 10:13:16PM +, co...@sdf.org wrote:
> 49691

Thanks.

So it's most visible with go programs, and there are two patches to
discuss.

https://mail-index.netbsd.org/port-amd64/2015/06/23/msg002276.html

by KAMADA Ken'ichi and

https://mail-index.netbsd.org/netbsd-bugs/2016/08/07/msg047862.html

by Mihai Chelaru.

Opinions on the patches or the underlying problems?
 Thomas

Re: ffs_newvnode: inode has non zero blocks

[Andreas Gustafsson]

Jaromír Doleček wrote:
> There was recenly change a change in FFS in the general area for
> WAPBL. Can you try attached patch and check if following KASSERT()
> triggers?

I'm afraid I took your request literally and tested a release build
with your patch and no other changes.  Since KASSERT does nothing
unless DIAGNOSTIC is also defined, and it is not defined by default,
your patch made no difference.

If you still need me to test a patch, please send one that includes
all necessary changes.
-- 
Andreas Gustafsson, g...@gson.org

TCP on IPv6 when IPV6_USE_MIN_MTU is set

[kato]

Folks,

This is not limited to NetBSD current but with all NetBSD releases
with IPv6, and other BSD based varients as well.

Applications which do not want to depend on Path MTU Discovery may set
IPV6_USE_MIN_MTU=1 to use IPv6_MMTU (1280) as defined in RFC3542. This
works well for UDP as long as fragmentation is allowed and no other
method to reduce message size is available.

But when the socket is set with this option, TCP doesn't see it and it
may send a larger segment especially when the peer notifies larger MSS
value. In this case, the segment is fragmented, and delivery
efficiency decreases. In some cases, if a middle box refuses fragments
(some of the boxes only pass the first fragment), the TCP session
breaks.

There was a short discussion on IETF 6man mailing list but no
conclusion was made:

https://www.ietf.org/mail-archive/web/ipv6/current/msg24977.html

I understood that it may not be the best to use IPV6_USE_MIN_MTU to
control this, however, there is no suitable knob defined at this
moment, and some TCP sessions currently fail in IPv6.

When IPV6_USE_MIN_MTU is defined to be 1 (IP6PO_MINMTU_ALL),
followings are necessary to avoid IPv6 fragmentation:
- it should advertise TCP MSS to be 1220 or less
- when TCP MSS is advertised from its peer, it should be clipped
  to be 1220 or less
- when it send a TCP segment, its segment size should be 1220 or less
Note: 1220 is IPV6_MMTU - IP6/TCP header size.

Enclosed is a quick ugly patch for NetBSD-7 to mitigate this
situation, which may not be complete.

-- Akira Kato, WIDE Project
*** tcp_input.c.ORG Sun Aug  2 15:08:15 2015
--- tcp_input.c Mon Nov  7 17:12:05 2016
***
*** 4443,4448 
--- 4443,4461 
sc->sc_ourmaxseg = tcp_mss_to_advertise(m->m_flags & M_PKTHDR ?
m->m_pkthdr.rcvif : NULL,
sc->sc_src.sa.sa_family);
+ #ifdefINET6
+   if (tp && tp->t_in6pcb && tp->t_in6pcb->in6p_outputopts) {
+   if (tp->t_in6pcb->in6p_outputopts->ip6po_minmtu ==
+   IP6PO_MINMTU_ALL) {
+   sc->sc_ourmaxseg = min(sc->sc_ourmaxseg,
+   IPV6_MMTU - sizeof(struct ip6_hdr)
+   - sizeof(struct tcphdr));
+   sc->sc_peermaxseg = min(sc->sc_peermaxseg,
+   IPV6_MMTU - sizeof(struct ip6_hdr)
+   - sizeof(struct tcphdr));
+   }
+   }
+ #endif
sc->sc_win = win;
sc->sc_timebase = tcp_now - 1;  /* see tcp_newtcpcb() */
sc->sc_timestamp = tb.ts_recent;
*** tcp_output.c.ORGSun Aug  2 15:08:15 2015
--- tcp_output.cTue Nov  1 08:29:38 2016
***
*** 1124,1129 
--- 1124,1138 
tp->snd_nxt = tp->iss;
tp->t_ourmss = tcp_mss_to_advertise(synrt != NULL ?
synrt->rt_ifp : NULL, af);
+ #ifdef INET6
+   if (tp->t_in6pcb && tp->t_in6pcb->in6p_outputopts) {
+   if (tp->t_in6pcb->in6p_outputopts->ip6po_minmtu ==
+   IP6PO_MINMTU_ALL)
+   tp->t_ourmss = min(tp->t_ourmss, 
+   IPV6_MMTU - sizeof(struct ip6_hdr)
+   - sizeof(struct tcphdr));
+   }
+ #endif
if ((tp->t_flags & TF_NOOPT) == 0 && OPT_FITS(4)) {
opt[0] = TCPOPT_MAXSEG;
opt[1] = 4;
*** tcp_subr.c.ORG  Thu Feb 26 12:44:13 2015
--- tcp_subr.c  Thu Nov  3 09:25:45 2016
***
*** 2001,2006 
--- 2001,2014 
mss = tcp_mssdflt;
if (offer)
mss = offer;
+ #ifdef INET6
+   if (tp->t_in6pcb && tp->t_in6pcb->in6p_outputopts) {
+   if (tp->t_in6pcb->in6p_outputopts->ip6po_minmtu ==
+   IP6PO_MINMTU_ALL)
+   mss = min(mss, IPV6_MMTU - sizeof(struct ip6_hdr)
+   - sizeof(struct tcphdr));
+   }
+ #endif
mss = max(mss, 256);/* sanity */
tp->t_peermss = mss;
mss -= tcp_optlen(tp);

Re: Automated report: NetBSD-current/i386 build success

[Christos Zoulas]

In article ,
seeman doy   wrote:
>-=-=-=-=-=-
>
>hi im installing a netbsd_7.0 in a computer with 1.3ghz amd duron k7
>cpu,ram is 256mb,my computer wont boot,i used the i386iso,should I use the
>amd64iso,,,pls help me thanks,,,

Either should work. What happens?

christos

Re: Automated report: NetBSD-current/i386 build success

[seeman doy]

hi im installing a netbsd_7.0 in a computer with 1.3ghz amd duron k7
cpu,ram is 256mb,my computer wont boot,i used the i386iso,should I use the
amd64iso,,,pls help me thanks,,,

On Tue, Nov 1, 2016 at 1:45 PM, NetBSD Test Fixture 
wrote:

> The NetBSD-current/i386 build is working again.
>
> The following commits were made between the last failed build and the
> successful build:
>
> 2016.11.01.15.58.41 christos 
> src/external/gpl3/binutils/lib/libiberty/Makefile,v
> 1.9
>
> Log files can be found at:
>
> http://releng.NetBSD.org/b5reports/i386/commits-2016.
> 11.html#2016.11.01.15.58.41
>