Re: CVS commit: src/sys/arch/evbmips/conf
> On Dec 30, 2018, at 4:34 PM, Sevan Janiyan wrote: > > On 30/12/2018 16:16, Jason Thorpe wrote: >> Maybe create a std.evmips that the various std. files can >> include to get options that you want for everything? > > Noted, I was thinking about the pull up to the 8 branch and making that > as easy as possible. I don't have anything else further at the moment, > should I go ahead any way? I would say pull this up to -8, and then make another cleanup pass. > > > Sevan -- thorpej
Re: CVS commit: src/sys/arch/evbmips/conf
On 30/12/2018 16:16, Jason Thorpe wrote: > Maybe create a std.evmips that the various std. files can > include to get options that you want for everything? Noted, I was thinking about the pull up to the 8 branch and making that as easy as possible. I don't have anything else further at the moment, should I go ahead any way? Sevan
Re: CVS commit: src/sys/arch/evbmips/conf
> On Dec 30, 2018, at 6:51 AM, Sevan Janiyan wrote: > > Modified Files: > src/sys/arch/evbmips/conf: ADM5120 ADM5120-NB ADM5120-USB ALCHEMY AP30 > CI20 CPMBR1400 DB120 ERLITE GDIUM LINKITSMART7688 LOONGSON MALTA > MERAKI RB153 RB433UAH SBMIPS WGT624V3 XLSATX ZYXELKX Maybe create a std.evmips that the various std. files can include to get options that you want for everything? -- thorpej
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 08, 2017 at 12:22:21PM +, Maya Rashish wrote: > This only need to be performed on kernel code, because only there we can have > accesses not translated/limited by TLB. For user code, it is impossible to > generate accesses to unwanted physical address. So it is safe. > > Also, to prevent addresses generated by user mode code to be used by the > kernel, we add a few empty jumps to flush the BTB upon entrance to kernel." Currently we do not do the empty jumps. the code claims it is flushing the BTB but it's hard to tell as the docs are in Chinese. Linux does this: /* * Clear BTB (branch target buffer), forbid RAS (return address * stack) to workaround the Out-of-order Issue in Loongson2F * via its diagnostic register. */ movek0, ra jal 1f nop 1: jal 1f nop 1: jal 1f nop 1: jal 1f nop 1: movera, k0 li k0, 3 mtc0k0, $22 I've changed the code be effectively: li k0, 3 mtc0 k0 $22 Also not sure if it's necessary to do on user_return...
Re: CVS commit: src/sys/arch/evbmips/conf
On Jul 30, 2012, at 6:50 AM, KIYOHARA Takashi wrote: Module Name: src Committed By: kiyohara Date: Mon Jul 30 13:50:06 UTC 2012 Modified Files: src/sys/arch/evbmips/conf: ALCHEMY MALTA Log Message: Enable INET6. Avoid build failed when enable ipf and disable INET6. The problem is in IPF. Please on't add hacks to fix it.
Re: CVS commit: src/sys/arch/evbmips/conf
On Mon, 30 Jul 2012, KIYOHARA Takashi wrote:
Module Name:src
Committed By: kiyohara
Date: Mon Jul 30 13:50:06 UTC 2012
Modified Files:
src/sys/arch/evbmips/conf: ALCHEMY MALTA
Log Message:
Enable INET6. Avoid build failed when enable ipf and disable INET6.
While this might be a stop-gap measure to get the build working, the
right action is to fix ipf so it builds without INET6.
I have previously provided patches (attached again here) to fix this,
and those fixes have been sent upstream (to darrenr@). As was already
pointed out, my patches should not be committed as-is due to my use of
variable initialization in the declaration... :)
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-Index: ip_ftp_pxy.c
===
RCS file: /cvsroot/src/sys/external/bsd/ipf/netinet/ip_ftp_pxy.c,v
retrieving revision 1.3
diff -u -p -r1.3 ip_ftp_pxy.c
--- ip_ftp_pxy.c22 Jul 2012 14:27:51 - 1.3
+++ ip_ftp_pxy.c25 Jul 2012 02:40:57 -
@@ -834,7 +834,7 @@ ipf_p_ftp_pasvreply(ipf_ftp_softc_t *sof
ipnat_t *ipn;
fr_info_t fi;
ftpside_t *f;
- nat_t *nat2;
+ nat_t *nat2 = NULL;
mb_t *m;
softc = fin-fin_main_soft;
@@ -1669,8 +1669,10 @@ ipf_p_ftp_eprt(ipf_ftp_softc_t *softf, f
if (f-ftps_rptr[5] == f-ftps_rptr[7]) {
if (f-ftps_rptr[6] == '1' nat-nat_v[0] == 4)
return ipf_p_ftp_eprt4(softf, fin, ip, nat, ftp, dlen);
+#ifdef USE_INET6
if (f-ftps_rptr[6] == '2' nat-nat_v[0] == 6)
return ipf_p_ftp_eprt6(softf, fin, ip, nat, ftp, dlen);
+#endif
}
return 0;
}
@@ -1902,7 +1904,7 @@ ipf_p_ftp_epsv(ipf_ftp_softc_t *softf, f
newbuf, s);
}
-
+#ifdef USE_INET6
int
ipf_p_ftp_eprt6(ipf_ftp_softc_t *softf, fr_info_t *fin, ip_t *ip,
nat_t *nat, ftpinfo_t *ftp, int dlen)
@@ -2107,3 +2109,4 @@ ipf_p_ftp_eprt6(ipf_ftp_softc_t *softf,
f-ftps_cmd = FTPXY_C_EPRT;
return ipf_p_ftp_addport(softf, fin, ip, nat, ftp, dlen, port, inc);
}
+#endif /* USE_INET6 */
Index: ip_nat.c
===
RCS file: /cvsroot/src/sys/external/bsd/ipf/netinet/ip_nat.c,v
retrieving revision 1.5
diff -u -p -r1.5 ip_nat.c
--- ip_nat.c22 Jul 2012 16:40:40 - 1.5
+++ ip_nat.c25 Jul 2012 02:40:57 -
@@ -2531,9 +2531,11 @@ ipf_nat_delrule(ipf_main_softc_t *softc,
case 4 :
ipf_nat_delrdr(softn, np);
break;
+#ifdef USE_INET6
case 6 :
ipf_nat6_delrdr(softn, np);
break;
+#endif
}
}
if (np-in_redir (NAT_MAPBLK|NAT_MAP)) {
@@ -2542,9 +2544,11 @@ ipf_nat_delrule(ipf_main_softc_t *softc,
case 4 :
ipf_nat_delmap(softn, np);
break;
+#ifdef USE_INET6
case 6 :
ipf_nat6_delmap(softn, np);
break;
+#endif
}
}
}
@@ -7969,18 +7973,6 @@ ipf_nat_rehash(ipf_main_softc_t *softc,
}
softn-ipf_nat_stats.ns_side[1].ns_bucketlen = bucketlens[1];
- if (softn-ipf_nat_stats.ns_side6[0].ns_bucketlen != NULL) {
- KFREES(softn-ipf_nat_stats.ns_side6[0].ns_bucketlen,
- softn-ipf_nat_table_sz * sizeof(u_int));
- }
- softn-ipf_nat_stats.ns_side6[0].ns_bucketlen = bucketlens[0];
-
- if (softn-ipf_nat_stats.ns_side6[1].ns_bucketlen != NULL) {
- KFREES(softn-ipf_nat_stats.ns_side6[1].ns_bucketlen,
- softn-ipf_nat_table_sz * sizeof(u_int));
- }
- softn-ipf_nat_stats.ns_side6[1].ns_bucketlen = bucketlens[1];
-
softn-ipf_nat_maxbucket = maxbucket;
softn-ipf_nat_table_sz = newsize;
/*
@@ -7990,8 +7982,6 @@ ipf_nat_rehash(ipf_main_softc_t *softc,
*/
softn-ipf_nat_stats.ns_side[0].ns_inuse = 0;
softn-ipf_nat_stats.ns_side[1].ns_inuse = 0;
- softn-ipf_nat_stats.ns_side6[0].ns_inuse = 0;
- softn-ipf_nat_stats.ns_side6[1].ns_inuse = 0;
for (nat = softn-ipf_nat_instances; nat != NULL; nat = nat-nat_next) {
nat-nat_hnext[0] = NULL;
Index: ip_rcmd_pxy.c
Re: CVS commit: src/sys/arch/evbmips/conf
Hi! From: Paul Goyette p...@whooppee.com Date: Mon, 30 Jul 2012 07:01:10 -0700 (PDT) On Mon, 30 Jul 2012, KIYOHARA Takashi wrote: Module Name:src Committed By: kiyohara Date: Mon Jul 30 13:50:06 UTC 2012 Modified Files: src/sys/arch/evbmips/conf: ALCHEMY MALTA Log Message: Enable INET6. Avoid build failed when enable ipf and disable INET6. While this might be a stop-gap measure to get the build working, the right action is to fix ipf so it builds without INET6. I have previously provided patches (attached again here) to fix this, and those fixes have been sent upstream (to darrenr@). As was already pointed out, my patches should not be committed as-is due to my use of variable initialization in the declaration... :) I am waiting for a fix of darrenr@, backout my add-hoc fix. What is OK? # Also please fix evbarm... Thanks, -- kiyohara OPENBLOCKS_A6 comming soon. :) And Psion series 5mx(EPOC32).
Re: CVS commit: src/sys/arch/evbmips/conf
On Jul 30, 2012, at 7:01 AM, Paul Goyette wrote: On Mon, 30 Jul 2012, KIYOHARA Takashi wrote: Module Name: src Committed By:kiyohara Date:Mon Jul 30 13:50:06 UTC 2012 Modified Files: src/sys/arch/evbmips/conf: ALCHEMY MALTA Log Message: Enable INET6. Avoid build failed when enable ipf and disable INET6. While this might be a stop-gap measure to get the build working, the right action is to fix ipf so it builds without INET6. I have previously provided patches (attached again here) to fix this, and those fixes have been sent upstream (to darrenr@). As was already pointed out, my patches should not be committed as-is due to my use of variable initialization in the declaration... :) Uh, that's perfectly acceptable these days.
