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 22, 2017 at 05:09:40AM +1000, matthew green wrote: > please put it back on ERLITE. that system is *not* "stable enough now". > all it takes is some heavy work. > > i can't comment on other platforms platforms you changed. should we use 'options OCTEON_MEMSIZE="(256*1024*1024)"' in -8? it can't use the upper 256MB. ftp'ing a 300MB file did the trick to reproduce.
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 22, 2017 at 05:09:40AM +1000, matthew green wrote: > please put it back on ERLITE. that system is *not* "stable enough now". > all it takes is some heavy work. > > i can't comment on other platforms platforms you changed. I'll have a stab at fixing the glaring flaws again. But I wouldn't be surprised if it doesn't survive build.sh due to overheating - mine gets crazy hot when I leave it in u-boot.
re: CVS commit: src/sys/arch/evbmips/conf
"Maya Rashish" writes: > Module Name: src > Committed By: maya > Date: Sat Aug 19 09:10:24 UTC 2017 > > Modified Files: > src/sys/arch/evbmips/conf: ADM5120 ALCHEMY CPMBR1400 DB120 ERLITE MALTA > RB153 RB433UAH XLSATX ZYXELKX > > Log Message: > Comment out 'options DEBUG' on all evbmips kernels > > We aren't using DEBUG on other archs, mips is stable enough now, etc. please put it back on ERLITE. that system is *not* "stable enough now". all it takes is some heavy work. i can't comment on other platforms platforms you changed. .mrg.
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 08, 2017 at 05:48:47PM +, co...@sdf.org wrote: > Also not sure if it's necessary to do on user_return... After finding docs, I think I should probably use this opportunity to re-enable RAS (and not clear) :-)
Re: CVS commit: src/sys/arch/evbmips/conf
On Tue, Aug 08, 2017 at 05:48:47PM +, co...@sdf.org wrote: > 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. Never mind, it's right. Also docs in English: http://dev.lemote.com/files/resource/documents/Loongson/ls2f/Loongson2FUserGuide.pdf
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 Tue, Aug 01, 2017 at 04:12:33PM +, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date: Tue Aug 1 16:12:33 UTC 2017 > > Modified Files: > src/sys/arch/evbmips/conf: CPMBR1400 LINKITSMART7688 ZYXELKX > > Log Message: > Wrong architecture for IBCS2 compat! it's stringly an x86 thing. Strictly. :-)
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.
Re: CVS commit: src/sys/arch/evbmips/conf
Hi! From: Paul Goyette 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 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:
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.
