Hi: I have the idea to transform my Qube (already working as File, Web, FTP server) into a router/firewall using PF and the 2 Nic's the Qube have build in but I'am in the need for some guideness, where I can find some information about a project like this??. Any help is welcome, Thanks Claudio http://4x4.no-ip.com (Powered By NetBSD for Cobalt)
Claudio Leiva S wrote: > Hi: > > I have the idea to transform my Qube (already working as File, Web, FTP > server) into a router/firewall using PF and the 2 Nic's the Qube have build > in but I'am in the need for some guideness, where I can find some > information about a project like this??. > > Any help is welcome, Thanks > > > > Claudio > http://4x4.no-ip.com > (Powered By NetBSD for Cobalt) > > Claudio, There is detailed howto here "http://www.muine.org/~hoang/netnat.html" on the net. Also IP filter has very detailed documentation. I used to do this with my qube but found that at the end it is not worth the trouble, IMHO. You have to actively maintain it, upgrade OS, edit rules and such. Takes too much time. If this is for your home you may be better off with some simple firewall/router that you can buy for $30 or so. Regards, Alex(Continue reading)
Hello all,
I'm porting a VR4120A based micro to netbsd.
I've got the initial setup done, console, cache etc
But the 64bit divide isn't working right.
This is most noticable in printf("%d\n",345);
prints
005
The remainder is OK, but not the quotient.
I've based this port on hpcmips which has the right
family of processors but is running big endian, which
none of those ports are for.
The div_d routine is in arch/mips/mips though so I would
not have thought endian had anything to do with it.
Anyone got any experience with this function, point me as
were it could be going wrong?
JP
jpfoster <at> exterity.co.uk wrote: > I'm porting a VR4120A based micro to netbsd. > I've got the initial setup done, console, cache etc : > The div_d routine is in arch/mips/mips though so I would > not have thought endian had anything to do with it. I'm afraid there are few people who tried mips SOFTFLOAT code on big endian environment. (anyone tried it on alchemy?) I guess you would have to add some #if _BYTE_ORDER like locore_mips3.S to swap high/low words in some 64bit functions. BTW, do NEC VR41xx processors work properly on big endian? I heard a rumour that some embedded peripherals didn't work on big endian since they were designed for WindowsCE. --- Izumi Tsutsui
so... how exactly do I add "options SOSEND_NO_LOAN"? and... if you added it successfully, instead of me (im guessing) recompiling the kernel, is there a way you can send it to me your fixed kernel and I can host it or something like that? I don't think i had this problem with -current from ages and ages ago, while my Qube2 isnt my fastest machine, I would like for it to be stable -justin On 6/15/06, Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp> wrote: > I wrote: > > After a bunch of tests with various attempts in ~six months, > > adding "options SOSEND_NO_LOAN" seems to fix this problem. > > Note this option also improves xfer rate on the ftp get command > (i.e. wd0->tlp0 xfer) from ~1.9MB/s to ~2.3MB/s. Umm. > --- > Izumi Tsutsui >
justin <at> tinfoilsoldier.com wrote: > how exactly do I add "options SOSEND_NO_LOAN"? The NetBSD Guide might help? http://www.NetBSD.org/guide/en/chap-kernel.html > and... if you added it > successfully, instead of me (im guessing) recompiling the kernel, is > there a way you can send it to me your fixed kernel and I can host it > or something like that? Here it is: http://www.ceres.dti.ne.jp/~tsutsui/netbsd/netbsd-cobalt-NOLOAN-20060709.gz but I doubt it's worth unless you currently have any stability problem. (note it isn't a real fix but just a workaround) --- Izumi Tsutsui
Izumi Tsutsui wrote: > jpfoster <at> exterity.co.uk wrote: > > >> I'm porting a VR4120A based micro to netbsd. >> I've got the initial setup done, console, cache etc >> > : > >> The div_d routine is in arch/mips/mips though so I would >> not have thought endian had anything to do with it. >> > > I'm afraid there are few people who tried mips SOFTFLOAT code > on big endian environment. (anyone tried it on alchemy?) > I run alchemy little endian, because there are some ugly PCI quirks when it runs big endian. I'll try to take a look at this on AR5312, which also runs big endian. > I guess you would have to add some #if _BYTE_ORDER > like locore_mips3.S to swap high/low words in some > 64bit functions. > > BTW, do NEC VR41xx processors work properly on big endian? > I heard a rumour that some embedded peripherals didn't work > on big endian since they were designed for WindowsCE. >(Continue reading)
============================================================== INFORMATIZE SUA EMPRESA COM SOFTWARES INTEGRADOS AO SITE ============================================================== BAIXE AGORA MESMO UMA DEMONSTRAO PARA: SALO DE BELEZA ACADEMIA PIZZARIA DISK ENTREGA LOJA DE CONFECO REVENDA DE VECULO IMOBILIRIA REPRESENTANTE OFICINA MERCADO INFORMTICA PETSHOP PORTARIA CELULAR COMRCIO E SERVIO CLINICA CURSOS E MUITO MAIS... LIGUE PARA NOSSO TELE-VENDAS: (11)4063-3059 So Paulo (61)4063-8149 Braslia (31)4062-7169 Belo Horizonte(Continue reading)
Hello all, I've begun looking into fixing some long-standing problems with revision 2.2 R4000 CPUs on SGI systems and would like any input whatsoever from those more experienced with MIPS. The most prominent bug in this revision occurs when a branch or jump exists as the last instruction in a page, the following page (containing the delay slot instruction) is not mapped, and a few other conditions (including a data cache miss) are met by the two prior instructions. The errata sheet doesn't seem terribly clear as to what all of the conditions are, but identifying a jump or branch in the last slot suffices in finding a potentially vulnerable instruction sequence. I would start here and attempt to make the test more specific afterwards so as not to work around unproblematic pages unnecessarily. The seemingly obvious fix is to guarantee that the following page is always mapped in the TLB when the troublesome page also exists there. In looking at the code, this appears fairly intrusive and also rather complicated. We'd need to go to pains to swap in the next page when servicing a lookup on a bad page, remove wired mappings when switching contexts, remove the wired mapping when replacing a problematic mapped page, deal with consecutive pages that may be problematic, etc, etc. And even then, theoretically a program could have N consecutive bad pages and require N wired entries in the TLB. The best solution is to ensure that a jump never occurs on an end of page boundary thus requiring no kernel workarounds to be enabled, but the gnu toolchain doesn't appear to support this, though other, less serious workarounds are now in gcc4. In trying to consider an alternative solution, I thought of dynamically altering the troublesome sequence when it is placed into the pmap via pmap_enter() under the assumption that changing the sequence would avoid the problem entirely. The instruction immediately preceding the branch or jump could be changed into a(Continue reading)
>>>>> "Stephen" == Stephen M Rumble <stephen.rumble <at> utoronto.ca> writes:
Stephen> Hello all, I've begun looking into fixing some long-standing
Stephen> problems with revision 2.2 R4000 CPUs on SGI systems and
Stephen> would like any input whatsoever from those more experienced
Stephen> with MIPS. The most prominent bug in this revision occurs
Stephen> when a branch or jump exists as the last instruction in a
Stephen> page, the following page (containing the delay slot
Stephen> instruction) is not mapped, and a few other conditions
Stephen> (including a data cache miss) are met by the two prior
Stephen> instructions. ...
Sounds like the old SB1 rev 1 bug. The best answer is to use the same
solution they used, which is to tweak the GCC code generator to align
all branches to modulo 8 boundaries. That's simple, reliable, and has
very little performance impact.
paul
RSS Feed2 | |
|---|---|
2 | |
3 | |
4 | |
2 | |
3 | |
6 | |
4 | |
13 | |
2 | |
8 | |
1 | |
2 | |
1 | |
3 | |
2 | |
30 | |
1 | |
7 | |
9 | |
11 | |
11 | |
14 | |
10 | |
5 | |
8 | |
3 | |
1 | |
42 | |
13 | |
4 | |
7 | |
4 | |
17 | |
17 | |
7 | |
1 | |
6 | |
16 | |
22 | |
9 | |
5 | |
6 | |
32 | |
2 | |
2 | |
9 | |
3 | |
5 | |
2 | |
3 | |
1 | |
9 | |
5 | |
2 | |
3 | |
23 | |
5 | |
1 | |
10 | |
23 | |
10 | |
31 | |
39 | |
6 | |
5 | |
9 | |
7 | |
7 | |
1 | |
41 | |
36 | |
10 | |
24 | |
12 | |
4 | |
23 | |
8 | |
28 | |
24 | |
66 | |
48 | |
24 | |
4 | |
2 | |
3 | |
3 | |
7 | |
79 | |
36 | |
5 | |
6 | |
23 | |
2 | |
20 | |
15 | |
8 | |
16 | |
37 | |
22 | |
44 | |
18 | |
5 | |
39 | |
13 | |
70 | |
26 | |
7 | |
1 | |
10 | |
15 | |
25 | |
2 | |
8 | |
10 | |
5 |
