* RE: [parisc-linux] CONFIG_IP_ADVANCE_ROUTER?
From: jsoe0708 @ 2003-01-09 7:40 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <3E0085D000001FAA@ocpmta5.freegates.net>
Hi all,
>
>Does somebody have already tested a pa kernel 2.4.20 configured as 'adva=
nce
>router'.
>Does it have some chance that it works?
>
>Thanks in advance,
> Joel
>
>PS: This is to configure a b180 as a small gateway-proxy :) and this is
>requested in GIpTable?
>
Just test and seems to works fine :-))
Joel
********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be
^ permalink raw reply
* Re: Gauntlet Set NOW!
From: Andre Hedrick @ 2003-01-09 7:41 UTC (permalink / raw)
To: Richard Stallman; +Cc: linux-kernel
In-Reply-To: <E18WX7P-0001cV-00@fencepost.gnu.org>
Richard,
My Lawyers instructed me not to talk to anyone about this issue any more.
However, I will forward your note to them.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 9 Jan 2003, Richard Stallman wrote:
> I'm not sure what your project is designed to do, so I don't have an
> opinion about how it stands regarding the GPL. However, I've talked
> with our lawyer about one specific issue that you raised: that of
> using simple material from header files.
>
> Someone recently made the claim that including a header file always
> makes a derivative work.
>
> That's not the FSF's view. Our view is that just using structure
> definitions, typedefs, enumeration constants, macros with simple
> bodies, etc., is NOT enough to make a derivative work. It would take
> a substantial amount of code (coming from inline functions or macros
> with substantial bodies) to do that.
>
^ permalink raw reply
* Re: 2.4.21-pre3 fails compile of ehci-hcd.c
From: Greg KH @ 2003-01-09 7:38 UTC (permalink / raw)
To: Kristofer T. Karas; +Cc: Linux Kernel
In-Reply-To: <1042096276.8219.126.camel@madmax>
On Thu, Jan 09, 2003 at 02:11:15AM -0500, Kristofer T. Karas wrote:
> Hello All,
>
> Noticed that I could not get patch-2.4.21-pre3 to compile:
>
> make[3]: Entering directory `/usr/src/kernels/linux-2.4.20/drivers/usb'
> ld -m elf_i386 -r -o usbcore.o usb.o usb-debug.o hub.o devio.o inode.o drivers.o devices.o hcd.o
> gcc -D__KERNEL__ -I/usr/src/kernels/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -nostdinc -iwithprefix include -DKBUILD_BASENAME=ehci_hcd -c -o hcd/ehci-hcd.o hcd/ehci-hcd.chcd/ehci-hcd.c: In function `ehci_start':
> hcd/ehci-hcd.c:343: parse error before `;'
> hcd/ehci-hcd.c:416: parse error before `;'
> hcd/ehci-hcd.c: In function `ehci_stop':
> hcd/ehci-hcd.c:501: parse error before `;'
> hcd/ehci-hcd.c: In function `ehci_irq':
> hcd/ehci-hcd.c:685: parse error before `;'
Does this patch solve it for you?
thanks,
greg k-h
--- 1.5/drivers/usb/hcd/ehci-dbg.c Mon Jan 6 16:43:05 2003
+++ edited/ehci-dbg.c Wed Jan 8 23:45:02 2003
@@ -18,37 +18,23 @@
/* this file is part of ehci-hcd.c */
-#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,50)
-
-#define ehci_dbg(ehci, fmt, args...) \
- dev_dbg (*(ehci)->hcd.controller, fmt, ## args )
-#define ehci_err(ehci, fmt, args...) \
- dev_err (*(ehci)->hcd.controller, fmt, ## args )
-#define ehci_info(ehci, fmt, args...) \
- dev_info (*(ehci)->hcd.controller, fmt, ## args )
-#define ehci_warn(ehci, fmt, args...) \
- dev_warn (*(ehci)->hcd.controller, fmt, ## args )
-
-#else
-
#ifdef DEBUG
#define ehci_dbg(ehci, fmt, args...) \
- printk(KERN_DEBUG "%s %s: " fmt, hcd_name, \
- (ehci)->hcd.pdev->slot_name, ## args )
+ printk(KERN_DEBUG "%s %s: " fmt , hcd_name , \
+ (ehci)->hcd.pdev->slot_name , ## args )
#else
#define ehci_dbg(ehci, fmt, args...) do { } while (0)
#endif
#define ehci_err(ehci, fmt, args...) \
- printk(KERN_ERR "%s %s: " fmt, hcd_name, \
- (ehci)->hcd.pdev->slot_name, ## args )
+ printk(KERN_ERR "%s %s: " fmt , hcd_name , \
+ (ehci)->hcd.pdev->slot_name , ## args )
#define ehci_info(ehci, fmt, args...) \
- printk(KERN_INFO "%s %s: " fmt, hcd_name, \
- (ehci)->hcd.pdev->slot_name, ## args )
+ printk(KERN_INFO "%s %s: " fmt , hcd_name , \
+ (ehci)->hcd.pdev->slot_name , ## args )
#define ehci_warn(ehci, fmt, args...) \
- printk(KERN_WARNING "%s %s: " fmt, hcd_name, \
- (ehci)->hcd.pdev->slot_name, ## args )
-#endif
+ printk(KERN_WARNING "%s %s: " fmt , hcd_name , \
+ (ehci)->hcd.pdev->slot_name , ## args )
#ifdef EHCI_VERBOSE_DEBUG
^ permalink raw reply
* kgdb & mips-linux
From: Gilad Benjamini @ 2003-01-09 7:09 UTC (permalink / raw)
To: linux-mips
After many efforts I was able to start a succesfull kgdb session.
However, each time I tell gdb to "continue", it receives a SIGTRAP
in process.c.
I was told that this is probably a yet un-resolved mips SMP issue.
Is this a known issue ?
Any workarounds or solutions ?
TIA
^ permalink raw reply
* [Linux-ia64] Re: strace improvement patch
From: David Mosberger @ 2003-01-09 7:24 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805650@msgid-missing>
>>>>> On Wed, 8 Jan 2003 23:05:55 -0800, Roland McGrath <roland@redhat.com> said:
Roland> Are you sure this really works on IA64?
Yes, it works very well on 2.5.52. I tested it on decidedly
non-trivial, heavily multithreaded programs.
Roland> I've committed the changes (along with some more fixes and
Roland> new support for the new threads features in Linux 2.5). Can
Roland> you get the current sources from sourceforge and try them on
Roland> IA64? After getting a cvs checkout, you'll need to run
Roland> "autoreconf -i" with automake-1.7.2 and autoconf-2.57.
I tried it and it works fine with 2.5.52. Then I also tried on a
2.4.20 machine and sure enough, there it dies with a SIGSEGV. I can
look into it, but not tonight, so you may want to go ahead with the
test-release.
Thanks,
--david
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Fabio Massimo Di Nitto @ 2003-01-09 7:29 UTC (permalink / raw)
To: Wichert Akkerman; +Cc: Andrew McGregor, netdev, linux-kernel
In-Reply-To: <20030108224339.GO22951@wiggy.net>
On Wed, 8 Jan 2003, Wichert Akkerman wrote:
> Previously Andrew McGregor wrote:
> > Probably on the server's side it got an ICMP Host Unreachable or two as
> > some router updated its tables, and decided to close the connection.
>
> The fact that this problem does not seem to occur when using a window
> XP client seems to contradict the suggestions that it may be a router
> problem.
>
> Wichert.
>
>
Is the WinXP client located in the same place where you are?
>From my side the ISP that is giving me problems is xs26.net
at 2 different points. One is flapping and one is the link between them
and another ISP (i can't even reach it now) where pkts get seriously
delayed (from 100ms to more than 350ms) probably due to a slow link.
But what is seriously annoying is that xs26.net keeps announcing a network
that it can't reach, fscking the entire routing.
Fabio
^ permalink raw reply
* Re: Gauntlet Set NOW!
From: Richard Stallman @ 2003-01-09 7:28 UTC (permalink / raw)
To: andre; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.10.10301031425590.421-100000@master.linux-ide.org>
I'm not sure what your project is designed to do, so I don't have an
opinion about how it stands regarding the GPL. However, I've talked
with our lawyer about one specific issue that you raised: that of
using simple material from header files.
Someone recently made the claim that including a header file always
makes a derivative work.
That's not the FSF's view. Our view is that just using structure
definitions, typedefs, enumeration constants, macros with simple
bodies, etc., is NOT enough to make a derivative work. It would take
a substantial amount of code (coming from inline functions or macros
with substantial bodies) to do that.
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Richard Stallman @ 2003-01-09 7:28 UTC (permalink / raw)
To: dpaun; +Cc: lm, acahalan, linux-kernel
In-Reply-To: <200301071118.41059.dpaun@rogers.com>
You are a smart guy. I think you'd agree with me that this particular
battle (GNU/Linux) is lost.
It's not a battle, and the outcome isn't binary.
(See http://www.gnu.org/gnu/gnu-linux-faq.html.)
The GNU/Linux campaign is partly successful
and that's better than not at all.
Bottom line is, the are only so many hours in a day. You have so many
battles to fight, that would serve the community.
All other work that we do is made less effective than it could have
been because the public doesn't know what we've already done. The
partial success of the GNU/Linux campaign partly reverses this.
Calling the system "GNU/Linux" is very easy, and takes just seconds a
day; that and using the term "free software" are the most efficient
ways you can use your time to help us.
situation, it must be clear even to you that things can't possibly go
back, and all your doing is creating bad blood. Think about it.
When we call the system "GNU/Linux" we are not insulting anyone. The
bad blood is created by others, by the people who resent our saying
this.
There are two ways to look at this question: in terms of principle
and in terms of practical effects.
First, principle. When a majority assaults a minority for stating a
truth that the majority wants forgotten, who is morally responsible?
If you say that the unpopular minority "creates bad blood", you're
blaming the victims of the intimidation campaign for resisting it;
taking a stand that deliberately disregards the concept of justice.
Second, practicalities. The people who are so attached to the idea of
the "Linux" system that they would attack us for disagreeing with it
are never going to help us much. They mostly don't share our values
anyway. So we have nothing to lose.
These discussions will never convince those people, but they do win
support from others who read both sides and find that we have right on
our side. So we have something to gain.
All in all, what we are doing is both right and effective. We will
continue.
^ permalink raw reply
* Re: Linux v2.5.55
From: Chris Wedgwood @ 2003-01-09 7:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0301082033410.1438-100000@penguin.transmeta.com>
On Wed, Jan 08, 2003 at 08:35:45PM -0800, Linus Torvalds wrote:
> <joe@fib011235813.fsnet.co.uk>:
> o dm: Don't let the ioctl interface drop a suspended device
> o dm: Correct clone info initialisation
> o dm: Correct target_type reference counting
> o dm: rwlock_t -> rw_semaphore (fluff)
> o dm: Call dm_put_target_type() *after* calling the destructor
> o dm: Remove explicit returns from void fns (fluff)
> o dm: printk tgt->error if dm_table_add_target() fails
> o dm: Simplify error->map
> o dm: Export dm_table_get_mode()
> o dm: Remove redundant error checking
FWIW, I *really* like it when people are able to prefix these
summaries as they send patches... I make reading the log more
pleasant.
--cw
^ permalink raw reply
* "Mother" == "computer-illiterate"
From: Val Henson @ 2003-01-09 7:20 UTC (permalink / raw)
To: Miles Bader; +Cc: dpaun, rms, lm, acahalan, linux-kernel
In-Reply-To: <buofzs474ro.fsf@mcspd15.ucom.lsi.nec.co.jp>
On Wed, Jan 08, 2003 at 11:29:47AM +0900, Miles Bader wrote:
>
> If someone's mom (having heard the gossip) asks their computer-literate
> child, `What is this XXX thing, anyway?', the answer is likely to be
> very different when XXX is "GNU" as opposed to when XXX is "Linux".
How come no one ever talks about a Linux distribution so easy that
your grandfather could install it? Or a kernel configuration tool so
simple that even Uncle Timmy can use it?
Can we quit with the "clueless mother" examples already? My own
mother has installed more distributions of Linux than I've even logged
into. I know quite a few mothers who have PhDs in CS, own several
CS-related patents, and/or made important fundamental discoveries in
CS. Hint: Find out who invented the spanning tree algorithm for
ethernet bridges, $10 ThinkGeek gift certificate to the first person
who emails me the correct answer.
-VAL
^ permalink raw reply
* [Linux-ia64] Re: strace improvement patch
From: Roland McGrath @ 2003-01-09 7:05 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805650@msgid-missing>
> * util.c (arg_setup) [IA64]: Make it work for syscall-stubs that have
> a non-empty local register partition.
> (set_arg0) [IA64]: Fix it so it actually works.
> (set_arg1) [IA64]: Ditto.
> (setbpt): Treat SYS_clone2 like SYS_clone.
Are you sure this really works on IA64? I've merged the changes, and
though I fixed some other problems with my original code, the IA64 code in
util.c is exactly what's in your patch. It doesn't work for me on IA64.
The failure mode suggests the argument munging code is munging the wrong
thing. I don't know IA64 halfway well enough to figure out how it might be
wrong, and it looks to me like it matches the code that fetches those
values in syscall_enter. When I do "strace -f /usr/bin/time /bin/true",
both parent and child die with SIGSEGV upon continuing the clone syscall
whose arguments should have been munged to set the CLONE_PTRACE flag.
(It executes fine without -f.)
I've committed the changes (along with some more fixes and new support for
the new threads features in Linux 2.5). Can you get the current sources
from sourceforge and try them on IA64? After getting a cvs checkout,
you'll need to run "autoreconf -i" with automake-1.7.2 and autoconf-2.57.
Unless someone can help me fix this right away, we'll probably go ahead
with a 4.4.90 test release with this bug still biting IA64.
Thanks,
Roland
^ permalink raw reply
* RE: opening a port..
From: mdew @ 2003-01-09 7:04 UTC (permalink / raw)
To: Dharmendra.T; +Cc: netfilter
In-Reply-To: <1042095224.810.19.camel@india>
On Thu, 2003-01-09 at 19:53, Dharmendra.T wrote:
> > >
> > > # nc -l -p 4662
> > >
> > > And then run nmap. You should get listed this port!
> > >
> > > --
> > > Dharmendra.T
> > > Linux Enthu
> >
> > mdew:~# nc -l -p 4662
> > ãP<H¹ogÝT'b´\Y6▒http://emule-project.net<6Ñ~ÖEmdew:~#
> >
> > (some strange characters, then it quits)
> >
> > mdew:~# netstat -an|grep 4662
> > mdew:~#
> >
> > nirvana:/home/mdew# nmap 10.0.0.6
> >
> > Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
> > Interesting ports on debian (10.0.0.6):
> > (The 1591 ports scanned but not shown below are in state: closed)
> > Port State Service
> > 22/tcp open ssh
> > 25/tcp open smtp
> > 110/tcp open pop-3
> > 111/tcp filtered sunrpc
> > 113/tcp open auth
> > 135/tcp filtered loc-srv
> > 136/tcp filtered profile
> > 137/tcp filtered netbios-ns
> > 138/tcp filtered netbios-dgm
> > 139/tcp filtered netbios-ssn
> > 199/tcp filtered smux
> > 826/tcp filtered unknown
> > 953/tcp filtered rndc
> > 8080/tcp open http-proxy
> >
> >
> >
> >
>
> nc, I mean to say netcat.?
it was netcat
apt-get install netcat
^ permalink raw reply
* 2.4.21-pre3 fails compile of ehci-hcd.c
From: Kristofer T. Karas @ 2003-01-09 7:11 UTC (permalink / raw)
To: Linux Kernel
Hello All,
Noticed that I could not get patch-2.4.21-pre3 to compile:
make[3]: Entering directory `/usr/src/kernels/linux-2.4.20/drivers/usb'
ld -m elf_i386 -r -o usbcore.o usb.o usb-debug.o hub.o devio.o inode.o drivers.o devices.o hcd.o
gcc -D__KERNEL__ -I/usr/src/kernels/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -nostdinc -iwithprefix include -DKBUILD_BASENAME=ehci_hcd -c -o hcd/ehci-hcd.o hcd/ehci-hcd.chcd/ehci-hcd.c: In function `ehci_start':
hcd/ehci-hcd.c:343: parse error before `;'
hcd/ehci-hcd.c:416: parse error before `;'
hcd/ehci-hcd.c: In function `ehci_stop':
hcd/ehci-hcd.c:501: parse error before `;'
hcd/ehci-hcd.c: In function `ehci_irq':
hcd/ehci-hcd.c:685: parse error before `;'
I'm not sure why gcc 2.95.3 is failing on the macro expansion, but it is
turning:
ehci_warn (ehci, "illegal capability!\n");
into:
printk("<4>" "%s %s: " "illegal capability!\n" , hcd_name, ( ehci ) ;
which is missing the ->... structure reference. The macros in
ehci-dbg.c work just fine if you give them one or more arguments
following the format string definition.
Compiler is gcc 2.95.3, binutils 2.12.90.0.9 20020526, glibc 2.2.5 on a
Slackware 8.0 distribution.
Kris
^ permalink raw reply
* Re: small fix for nforce ide chipset driver in 2.5.54
From: James Curbo @ 2003-01-09 6:56 UTC (permalink / raw)
To: Alan Cox; +Cc: Andre Hedrick, Linux Kernel Mailing List
In-Reply-To: <1042034033.24099.2.camel@irongate.swansea.linux.org.uk>
On Jan 08, Alan Cox wrote:
> On Wed, 2003-01-08 at 07:55, James Curbo wrote:
> > so I added a #define for PCI_DEVICE_ID_NVIDIA_NFORCE_IDE as 0x0065. It
> > compiled fine and I am in fact running that kernel now. I would have
> > just sent a patch but I am new to kernel hacking, this is just a one
> > liner and I'm sure you know where it goes better than I do.
>
> Someone deleted it about 2.5.50, and though I sent in the fix twice Linus
> still hasn't applied it 8(
Well, I thought this deal was over but apparently not. My 2.5.54 kernel
is still working fine, but when I compiled 2.4.20-ac2, it didn't pick up
my Nforce2 IDE. On a whim I checked include/linux/pci_ids.h and it has a
different PCI ID for PCI_DEVICE_ID_NVIDIA_NFORCE_IDE, namely 0x01bc.
(lspci -v reports 0x0065 here). Perhaps 0x01bc is the nforce1 ide
chipset and 0x0065 is the nforce2 ide chipset?
--
James Curbo <hannibal@adtrw.org> <phoenix@sandwich.net>
GPG public key available at http://sandwich.net/~phoenix/keys/
^ permalink raw reply
* RE: opening a port..
From: Dharmendra.T @ 2003-01-09 6:53 UTC (permalink / raw)
To: mdew; +Cc: netfilter
In-Reply-To: <1042094721.423.15.camel@nirvana>
> >
> > # nc -l -p 4662
> >
> > And then run nmap. You should get listed this port!
> >
> > --
> > Dharmendra.T
> > Linux Enthu
>
> mdew:~# nc -l -p 4662
> ãP<H¹ogÝT'b´\Y6▒http://emule-project.net<6Ñ~ÖEmdew:~#
>
> (some strange characters, then it quits)
>
> mdew:~# netstat -an|grep 4662
> mdew:~#
>
> nirvana:/home/mdew# nmap 10.0.0.6
>
> Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
> Interesting ports on debian (10.0.0.6):
> (The 1591 ports scanned but not shown below are in state: closed)
> Port State Service
> 22/tcp open ssh
> 25/tcp open smtp
> 110/tcp open pop-3
> 111/tcp filtered sunrpc
> 113/tcp open auth
> 135/tcp filtered loc-srv
> 136/tcp filtered profile
> 137/tcp filtered netbios-ns
> 138/tcp filtered netbios-dgm
> 139/tcp filtered netbios-ssn
> 199/tcp filtered smux
> 826/tcp filtered unknown
> 953/tcp filtered rndc
> 8080/tcp open http-proxy
>
>
>
>
nc, I mean to say netcat.?
--
Dharmendra.T
Linux Enthu
^ permalink raw reply
* RE: opening a port..
From: mdew @ 2003-01-09 6:45 UTC (permalink / raw)
To: Dharmendra.T; +Cc: netfilter
In-Reply-To: <1042093627.810.17.camel@india>
On Thu, 2003-01-09 at 19:26, Dharmendra.T wrote:
> On Thu, 2003-01-09 at 11:46, mdew wrote:
> > On Thu, 2003-01-09 at 17:55, Dharmendra.T wrote:
> > > On Thu, 2003-01-09 at 08:11, mdew wrote:
> > > > On Thu, 2003-01-09 at 03:24, Rob Sterenborg wrote:
> > > > > > ok, telnet from another machine to the router.
> > > > > >
> > > > > > telnet 10.0.0.6 4662
> > > > > > Trying 10.0.0.6...
> > > > > > telnet: Unable to connect to remote host: Connection refused
> > > > > >
> > > > > > what "service" should I be running? I simply want 4662 open both ways.
> > > > >
> > > > > # netstat -an|grep 4662
> > > > > should tell you if your box is listening at all on port 4662.
> > > > >
> > > > > If you run eDonkey server on the firewall box, open port in the INPUT
> > > > > chain.
> > > > > If your eDonkey server is *behind* the firewall, open the port in the
> > > > > FORWARD chain, and add a DNAT rule in the nat table -> PREROUTING chain.
> > > >
> > > > the edonkey server is behind the firewall
> > > >
> > > > 210.54.175.12--->eth0 (Router) 10.0.0.6(eth1)--->10.0.0.x
> > > >
> > > > iptables -t nat -A PREROUTING -p tcp -i eth0 -d 210.54.175.12 --dport 4662 -j DNAT --to 10.0.0.6:4662
> > > >
> > >
> > > This should work without the last rule.
> > >
> > > iptables -A FORWARD -p tcp -i eth0 -d 10.0.0.6 --dport 4662 -j ACCEPT
> > > >
> > > > like that?
> >
> > the router isnt picking this up..
> >
> > mdew:~# iptables -t nat -A PREROUTING -p tcp -i eth0 -d 210.54.175.12
> > --dport 4662 -j DNAT --to 10.0.0.6:4662
> > mdew:~# iptables -A FORWARD -p tcp -i eth0 -d 10.0.0.6 --dport 4662 -j
> > ACCEPT
> > mdew:~# netstat -an|grep 4662
> > mdew:~#
> >
> > mdew@nirvana:~$ nmap 10.0.0.6
> >
> > Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
> > Interesting ports on debian (10.0.0.6):
> > (The 1598 ports scanned but not shown below are in state: closed)
> > Port State Service
> > 22/tcp open ssh
> > 25/tcp open smtp
> > 110/tcp open pop-3
> > 113/tcp open auth
> > 135/tcp filtered loc-srv
> > 139/tcp filtered netbios-ssn
> > 8080/tcp open http-proxy
> >
> > Nmap run completed -- 1 IP address (1 host up) scanned in 2.545 seconds
> > >
> >
>
> As said you are not running any service on that port so the port is not
> listening, Try the rules by listening a port using nc(netcat)
>
> # nc -l -p 4662
>
> And then run nmap. You should get listed this port!
>
> --
> Dharmendra.T
> Linux Enthu
mdew:~# nc -l -p 4662
ãP<H¹ogÝT'b´\Y6▒http://emule-project.net<6Ñ~ÖEmdew:~#
(some strange characters, then it quits)
mdew:~# netstat -an|grep 4662
mdew:~#
nirvana:/home/mdew# nmap 10.0.0.6
Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
Interesting ports on debian (10.0.0.6):
(The 1591 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
110/tcp open pop-3
111/tcp filtered sunrpc
113/tcp open auth
135/tcp filtered loc-srv
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
199/tcp filtered smux
826/tcp filtered unknown
953/tcp filtered rndc
8080/tcp open http-proxy
^ permalink raw reply
* Some advice for QoS setup ...
From: Raymond Leach @ 2003-01-09 6:41 UTC (permalink / raw)
To: Netfilter Mailing List
[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]
Hi all
Am I going about this in the right way?
This is what I plan to do :
1. Outgoing www traffic originating from our web servers has priority 1
with min 30% bandwidth and max 60% bandwidth.
2. Outgoing mail traffic (smtp and pop3) originating from our mail
servers has priority 2 with min 5% bandwidth and max 20% bandwidth.
3. Outgoing ftp traffic originating from our ftp servers has priority 3
with min 5% bandwidth and max 10% bandwidth.
4. All other traffic has priority 4 with min 0% bandwidth and max 10%
bandwidth.
I was thinking of using htb and sfq. What should my 'tree that is not a
tree' look like?
I was also planning to use netfilter iptables to mark the traffic and
use tc to filter the packets based on the mark (let's say 1,2,3,4
corresponding to the priorities above).
Any suggestions?
I thought my tree would look something like this:
10: (htb)
|
10:1 (htb)
(rate 512kbps, ceil 512kbps)
|
________________________________________________________
| | | |
10:10 (htb) 10:20 (htb) 10:30 (htb) 10:40 (htb)
(rate 153kbps, (rate 25kbps, (rate 25kbps, (rate 0kbps,
ceil 306kbps) ceil 102kbps) ceil 50kbps) ceil 50kbps)
| | | |
SFQ SFQ SFQ SFQ
Does my tree look correct? Will this tree honour the priorities I want
to set? Is netfilter FWMARK the right way to go here?
Regards
Ray
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
( Raymond Leach )
) Knowledge Factory (
( )
) Tel: +27 11 445 8100 (
( Fax: +27 11 445 8101 )
) (
( http://www.knowledgefactory.co.za/ )
) http://www.saptg.co.za/ (
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
o o
o o
.--. .--.
| o_o| |o_o |
| \_:| |:_/ |
/ / \\ // \ \
( | |) (| | )
/`\_ _/'\ /'\_ _/`\
\___)=(___/ \___)=(___/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: !?!
From: Oleg Drokin @ 2003-01-09 6:40 UTC (permalink / raw)
To: Anton Erofeevskij; +Cc: reiserfs-list
In-Reply-To: <3E1BCAE6.9000408@ap-plastic.ru>
Hello!
On Wed, Jan 08, 2003 at 11:53:26AM +0500, Anton Erofeevskij wrote:
> in reiserfs filesystem
> time cat sd1 | ./a.out > sd2
> 0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
> in ext2 filesystem
> time cat sd1 | ./a.out > sd2
> 0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
> In what the reason?!?
Generally reiserfs might have more CPU overhead over ext2 due to it's
journaling and balanced-tree nature per one operation. For large operations
this is outweight by speed of performing the operation itself, but when you
just write four bytes at a time, and each time that involves statdata (size,
possibly nlinks, times) update, possible rebalancings, journal updates.
And you have not said what ketnel are you using and what is config of the
kernel.
Bye,
Oleg
^ permalink raw reply
* Re: [PATCH] Set TIF_IRET in more places
From: Zack Weinberg @ 2003-01-09 6:49 UTC (permalink / raw)
To: Jamie Lokier; +Cc: linux-kernel, torvalds
In-Reply-To: <20030108162906.GA5995@bjl1.asuk.net>
Jamie Lokier <lk@tantalophile.demon.co.uk> writes:
>
> It would be quite nice just to have dwarf2 unwind information, with an
> unwind handler, for the classic non-vsyscall restorer in Glibc.
A trivial routine that just calls another routine,
extern void g(void);
void f(void) { g(); asm volatile (""); }
[the asm is to prevent sibcall optimization from kicking in] produces
the assembly dump appended to this message when compiled with -O2
-fexceptions -fomit-frame-pointer. I do not know what the stuff put
in .eh_frame means, and it probably isn't exactly right for __restore
or __restore_rt, but it's a start.
> Then MD_FALLBACK_FRAME_STATE_FOR could be removed from GCC on all
> Linux targets, regardless of kernel version.
I think we'd need to keep it around for the sake of older libcs; it
shouldn't do any harm.
zw
.text
.p2align 2,,3
.globl f
.type f,@function
f:
.LFB1:
subl $12, %esp
.LCFI0:
call g
addl $12, %esp
.LCFI1:
ret
.LFE1:
.Lfe1:
.size f,.Lfe1-f
.section .eh_frame,"aw",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string ""
.uleb128 0x1
.sleb128 -4
.byte 0x8
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB1
.long .LFE1-.LFB1
.byte 0x4
.long .LCFI0-.LFB1
.byte 0xe
.uleb128 0x10
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xe
.uleb128 0x4
.align 4
.LEFDE1:
.ident "GCC: (GNU) 3.2.2 20021231 (Debian prerelease)"
^ permalink raw reply
* Connection Tracking
From: Amit Kumar Gupta @ 2003-01-09 6:40 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
Oops ,
I forget to change the subject.
Sorry for inconvenience.
Regards,
Amit
-----Original Message-----
From: Amit Kumar Gupta
Sent: Thursday, January 09, 2003 12:09 PM
To: Amit Kumar Gupta
Cc: Netfilter
Subject: RE: can't load the script
Hi All,
I am getting some problem in Connection tracking.
As soon as I execute a program (Having iptables rules),
It keeps printing the following messages on the screen :-
Ip_contrack: maximum limit of 1016 entries exceeded.
Any the speed becomes damn slow.
Can anybody suggest what is happening?
Thanks & Regards,
Amit Kumar Gupta.
[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 522 bytes --]
**************************Disclaimer**************************************************
Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged'
and 'confidential' and intended for use only by the individual or entity to which it is
addressed. You are notified that any use, copying or dissemination of the information
contained in the E-MAIL in any manner whatsoever is strictly prohibited.
****************************************************************************************
^ permalink raw reply
* RE: can't load the script
From: Amit Kumar Gupta @ 2003-01-09 6:39 UTC (permalink / raw)
To: Amit Kumar Gupta; +Cc: Netfilter
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
Hi All,
I am getting some problem in Connection tracking.
As soon as I execute a program (Having iptables rules),
It keeps printing the following messages on the screen :-
Ip_contrack: maximum limit of 1016 entries exceeded.
Any the speed becomes damn slow.
Can anybody suggest what is happening?
Thanks & Regards,
Amit Kumar Gupta.
[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 522 bytes --]
**************************Disclaimer**************************************************
Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged'
and 'confidential' and intended for use only by the individual or entity to which it is
addressed. You are notified that any use, copying or dissemination of the information
contained in the E-MAIL in any manner whatsoever is strictly prohibited.
****************************************************************************************
^ permalink raw reply
* Re: [PATCH] kallsyms off-by-one and sorting
From: Andi Kleen @ 2003-01-09 6:40 UTC (permalink / raw)
To: Hugh Dickins; +Cc: torvalds, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301090620040.1104-100000@localhost.localdomain>
On Thu, Jan 09, 2003 at 06:22:50AM +0000, Hugh Dickins wrote:
> Beware of kksymoops reports on 2.5.55:
> kallsyms was off-by-one, showing the preceding symbol name. For
> example, if best index 0, no string was copied into the namebuf.
Thanks. Wasn't it there before?
>
> And it seems odd to do stem compression on symbols sorted by value:
> save more space sorting by name. It's harder then to avoid aliases
> for a value; but very few in kernel text, so scrap last_addr check.
Good point, but it works quite well already because prefixes in
source code tend to be clustered (everything in a file called
subsystem_foo etc.). Sorting by name may improve it even more.
Unfortunately these functions are not as performance critical
as previously thought. At least some versions of top read /proc/<pid>/wchan
now and that will always walk the full symbol table for each
address on the stack (in short it is very very costly)
(I guess it would be a good idea to at least make it root readable
only to prevent users from tying up too much cpu time in kernel)
With the strncpy that got added in 2.5.55 it got even more costly,
because due to a stupid definition it will always zero upto 127 bytes.
So the choice would be either to fix top to not do that or
do binary search or some other efficient search method
(the later would prevent sorting by name). Binary search would
make the stem compression more awkward however because it would
need to scan backwards.
Actually best may be to just get rid of /proc/*/wchan again
and keep the lookup symbol function like it is.
As the top incident shows it is just too dangerous to have around.
And having to press the magic keys on the console isn't that bad...
Comments?
-Andi
^ permalink raw reply
* [PATCH][2.5] Clustered APIC setup for >8 CPU systems
From: Pallipadi, Venkatesh @ 2003-01-09 6:39 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, Mallick, Asit K, Nakajima, Jun
[-- Attachment #1: Type: text/plain, Size: 5945 bytes --]
Support for more than 8 CPU non-numa, non-quad based systems. Resend.
Motivation:
The current APIC destination mode ("Flat Logical") used in linux kernel
has an upper limit of 8 CPUs. For more than 8 CPUs, either "Clustered
Logical" or "Physical" mode has to be used.
The attached patch adds support such systems by organizing them into
logical clusters, with each cluster having 4 CPUs.
The patch is made very simple and isolated, thanks to Martin J. Bligh's
patchsets, which has moved all APIC related functions into sub-arch
macros. Has zero impact on standard systems.
Please apply.
Thanks,
-Venkatesh
diff -urN linux-2.5.54.mod/arch/i386/Kconfig
linux-2.5.54.patch/arch/i386/Kconfig
--- linux-2.5.54.mod/arch/i386/Kconfig 2003-01-07 19:31:50.000000000
-0800
+++ linux-2.5.54.patch/arch/i386/Kconfig 2003-01-08
15:24:30.000000000 -0800
@@ -75,6 +75,14 @@
If you don't have one of these computers, you should say N
here.
+config X86_BIGSMP
+ bool "Support for other sub-arch SMP systems with more than 8
CPUs"
+ help
+ This option is needed for the systems that have more than 8
CPUs
+ and if the system is not of any sub-arch type above.
+
+ If you don't have such a system, you should say N here.
+
# Visual Workstation support is utterly broken.
# If you want to see it working mail an VW540 to hch@infradead.org 8)
#config X86_VISWS
diff -urN linux-2.5.54.mod/arch/i386/Makefile
linux-2.5.54.patch/arch/i386/Makefile
--- linux-2.5.54.mod/arch/i386/Makefile 2003-01-01 19:21:44.000000000
-0800
+++ linux-2.5.54.patch/arch/i386/Makefile 2003-01-08
15:24:30.000000000 -0800
@@ -64,6 +64,10 @@
mflags-$(CONFIG_X86_NUMAQ) := -Iinclude/asm-i386/mach-numaq
mcore-$(CONFIG_X86_NUMAQ) := mach-default
+# BIGSMP subarch support
+mflags-$(CONFIG_X86_BIGSMP) := -Iinclude/asm-i386/mach-bigsmp
+mcore-$(CONFIG_X86_BIGSMP) := mach-default
+
# default subarch .h files
mflags-y += -Iinclude/asm-i386/mach-default
diff -urN linux-2.5.54.mod/include/asm-i386/mach-bigsmp/mach_apic.h
linux-2.5.54.patch/include/asm-i386/mach-bigsmp/mach_apic.h
--- linux-2.5.54.mod/include/asm-i386/mach-bigsmp/mach_apic.h
1969-12-31 16:00:00.000000000 -0800
+++ linux-2.5.54.patch/include/asm-i386/mach-bigsmp/mach_apic.h
2003-01-08 20:19:26.000000000 -0800
@@ -0,0 +1,106 @@
+#ifndef __ASM_MACH_APIC_H
+#define __ASM_MACH_APIC_H
+
+#define SEQUENTIAL_APICID
+#ifdef SEQUENTIAL_APICID
+#define xapic_phys_to_log_apicid(phys_apic) ( (1ul << ((phys_apic) &
0x3)) |\
+ ((phys_apic<<2) & (~0xf)) )
+#elif CLUSTERED_APICID
+#define xapic_phys_to_log_apicid(phys_apic) ( (1ul << ((phys_apic) &
0x3)) |\
+ ((phys_apic) & (~0xf)) )
+#endif
+
+#define no_balance_irq (1)
+#define esr_disable (1)
+
+static inline int apic_id_registered(void)
+{
+ return (1);
+}
+
+#define APIC_DFR_VALUE (APIC_DFR_CLUSTER)
+#define TARGET_CPUS ((cpu_online_map < 0xf)?cpu_online_map:0xf)
+
+#define APIC_BROADCAST_ID (0x0f)
+#define check_apicid_used(bitmap, apicid) (0)
+
+static inline unsigned long calculate_ldr(unsigned long old)
+{
+ unsigned long id;
+ id = xapic_phys_to_log_apicid(hard_smp_processor_id());
+ return ((old & ~APIC_LDR_MASK) | SET_APIC_LOGICAL_ID(id));
+}
+
+/*
+ * Set up the logical destination ID.
+ *
+ * Intel recommends to set DFR, LDR and TPR before enabling
+ * an APIC. See e.g. "AP-388 82489DX User's Manual" (Intel
+ * document number 292116). So here it goes...
+ */
+static inline void init_apic_ldr(void)
+{
+ unsigned long val;
+
+ apic_write_around(APIC_DFR, APIC_DFR_VALUE);
+ val = apic_read(APIC_LDR) & ~APIC_LDR_MASK;
+ val = calculate_ldr(val);
+ apic_write_around(APIC_LDR, val);
+}
+
+static inline void clustered_apic_check(void)
+{
+ printk("Enabling APIC mode: %s. Using %d I/O APICs\n",
+ "Cluster", nr_ioapics);
+}
+
+static inline int multi_timer_check(int apic, int irq)
+{
+ return 0;
+}
+
+static inline int apicid_to_node(int logical_apicid)
+{
+ return 0;
+}
+
+extern u8 raw_phys_apicid[];
+
+static inline int cpu_present_to_apicid(int mps_cpu)
+{
+ return (int) raw_phys_apicid[mps_cpu];
+}
+
+static inline unsigned long apicid_to_cpu_present(int phys_apicid)
+{
+ return (1ul << phys_apicid);
+}
+
+static inline int mpc_apic_id(struct mpc_config_processor *m, int quad)
+{
+ printk("Processor #%d %ld:%ld APIC version %d\n",
+ m->mpc_apicid,
+ (m->mpc_cpufeature & CPU_FAMILY_MASK) >> 8,
+ (m->mpc_cpufeature & CPU_MODEL_MASK) >> 4,
+ m->mpc_apicver);
+ return (m->mpc_apicid);
+}
+
+static inline ulong ioapic_phys_id_map(ulong phys_map)
+{
+ /* For clustered we don't have a good way to do this yet - hack
*/
+ return (0x0F);
+}
+
+#define WAKE_SECONDARY_VIA_INIT
+
+static inline void setup_portio_remap(void)
+{
+}
+
+static inline int check_phys_apicid_present(int
boot_cpu_physical_apicid)
+{
+ return (1);
+}
+
+#endif /* __ASM_MACH_APIC_H */
diff -urN linux-2.5.54.mod/include/asm-i386/mach-bigsmp/mach_ipi.h
linux-2.5.54.patch/include/asm-i386/mach-bigsmp/mach_ipi.h
--- linux-2.5.54.mod/include/asm-i386/mach-bigsmp/mach_ipi.h
1969-12-31 16:00:00.000000000 -0800
+++ linux-2.5.54.patch/include/asm-i386/mach-bigsmp/mach_ipi.h
2003-01-01 19:21:13.000000000 -0800
@@ -0,0 +1,24 @@
+#ifndef __ASM_MACH_IPI_H
+#define __ASM_MACH_IPI_H
+
+static inline void send_IPI_mask_sequence(int mask, int vector);
+
+static inline void send_IPI_mask(int mask, int vector)
+{
+ send_IPI_mask_sequence(mask, vector);
+}
+
+static inline void send_IPI_allbutself(int vector)
+{
+ unsigned long mask = cpu_online_map & ~(1 <<
smp_processor_id());
+
+ if (mask)
+ send_IPI_mask(mask, vector);
+}
+
+static inline void send_IPI_all(int vector)
+{
+ send_IPI_mask(cpu_online_map, vector);
+}
+
+#endif /* __ASM_MACH_IPI_H */
<<bigsmp.patch>>
[-- Attachment #2: bigsmp.patch --]
[-- Type: application/octet-stream, Size: 5096 bytes --]
diff -urN linux-2.5.54.mod/arch/i386/Kconfig linux-2.5.54.patch/arch/i386/Kconfig
--- linux-2.5.54.mod/arch/i386/Kconfig 2003-01-07 19:31:50.000000000 -0800
+++ linux-2.5.54.patch/arch/i386/Kconfig 2003-01-08 15:24:30.000000000 -0800
@@ -75,6 +75,14 @@
If you don't have one of these computers, you should say N here.
+config X86_BIGSMP
+ bool "Support for other sub-arch SMP systems with more than 8 CPUs"
+ help
+ This option is needed for the systems that have more than 8 CPUs
+ and if the system is not of any sub-arch type above.
+
+ If you don't have such a system, you should say N here.
+
# Visual Workstation support is utterly broken.
# If you want to see it working mail an VW540 to hch@infradead.org 8)
#config X86_VISWS
diff -urN linux-2.5.54.mod/arch/i386/Makefile linux-2.5.54.patch/arch/i386/Makefile
--- linux-2.5.54.mod/arch/i386/Makefile 2003-01-01 19:21:44.000000000 -0800
+++ linux-2.5.54.patch/arch/i386/Makefile 2003-01-08 15:24:30.000000000 -0800
@@ -64,6 +64,10 @@
mflags-$(CONFIG_X86_NUMAQ) := -Iinclude/asm-i386/mach-numaq
mcore-$(CONFIG_X86_NUMAQ) := mach-default
+# BIGSMP subarch support
+mflags-$(CONFIG_X86_BIGSMP) := -Iinclude/asm-i386/mach-bigsmp
+mcore-$(CONFIG_X86_BIGSMP) := mach-default
+
# default subarch .h files
mflags-y += -Iinclude/asm-i386/mach-default
diff -urN linux-2.5.54.mod/include/asm-i386/mach-bigsmp/mach_apic.h linux-2.5.54.patch/include/asm-i386/mach-bigsmp/mach_apic.h
--- linux-2.5.54.mod/include/asm-i386/mach-bigsmp/mach_apic.h 1969-12-31 16:00:00.000000000 -0800
+++ linux-2.5.54.patch/include/asm-i386/mach-bigsmp/mach_apic.h 2003-01-08 20:19:26.000000000 -0800
@@ -0,0 +1,106 @@
+#ifndef __ASM_MACH_APIC_H
+#define __ASM_MACH_APIC_H
+
+#define SEQUENTIAL_APICID
+#ifdef SEQUENTIAL_APICID
+#define xapic_phys_to_log_apicid(phys_apic) ( (1ul << ((phys_apic) & 0x3)) |\
+ ((phys_apic<<2) & (~0xf)) )
+#elif CLUSTERED_APICID
+#define xapic_phys_to_log_apicid(phys_apic) ( (1ul << ((phys_apic) & 0x3)) |\
+ ((phys_apic) & (~0xf)) )
+#endif
+
+#define no_balance_irq (1)
+#define esr_disable (1)
+
+static inline int apic_id_registered(void)
+{
+ return (1);
+}
+
+#define APIC_DFR_VALUE (APIC_DFR_CLUSTER)
+#define TARGET_CPUS ((cpu_online_map < 0xf)?cpu_online_map:0xf)
+
+#define APIC_BROADCAST_ID (0x0f)
+#define check_apicid_used(bitmap, apicid) (0)
+
+static inline unsigned long calculate_ldr(unsigned long old)
+{
+ unsigned long id;
+ id = xapic_phys_to_log_apicid(hard_smp_processor_id());
+ return ((old & ~APIC_LDR_MASK) | SET_APIC_LOGICAL_ID(id));
+}
+
+/*
+ * Set up the logical destination ID.
+ *
+ * Intel recommends to set DFR, LDR and TPR before enabling
+ * an APIC. See e.g. "AP-388 82489DX User's Manual" (Intel
+ * document number 292116). So here it goes...
+ */
+static inline void init_apic_ldr(void)
+{
+ unsigned long val;
+
+ apic_write_around(APIC_DFR, APIC_DFR_VALUE);
+ val = apic_read(APIC_LDR) & ~APIC_LDR_MASK;
+ val = calculate_ldr(val);
+ apic_write_around(APIC_LDR, val);
+}
+
+static inline void clustered_apic_check(void)
+{
+ printk("Enabling APIC mode: %s. Using %d I/O APICs\n",
+ "Cluster", nr_ioapics);
+}
+
+static inline int multi_timer_check(int apic, int irq)
+{
+ return 0;
+}
+
+static inline int apicid_to_node(int logical_apicid)
+{
+ return 0;
+}
+
+extern u8 raw_phys_apicid[];
+
+static inline int cpu_present_to_apicid(int mps_cpu)
+{
+ return (int) raw_phys_apicid[mps_cpu];
+}
+
+static inline unsigned long apicid_to_cpu_present(int phys_apicid)
+{
+ return (1ul << phys_apicid);
+}
+
+static inline int mpc_apic_id(struct mpc_config_processor *m, int quad)
+{
+ printk("Processor #%d %ld:%ld APIC version %d\n",
+ m->mpc_apicid,
+ (m->mpc_cpufeature & CPU_FAMILY_MASK) >> 8,
+ (m->mpc_cpufeature & CPU_MODEL_MASK) >> 4,
+ m->mpc_apicver);
+ return (m->mpc_apicid);
+}
+
+static inline ulong ioapic_phys_id_map(ulong phys_map)
+{
+ /* For clustered we don't have a good way to do this yet - hack */
+ return (0x0F);
+}
+
+#define WAKE_SECONDARY_VIA_INIT
+
+static inline void setup_portio_remap(void)
+{
+}
+
+static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
+{
+ return (1);
+}
+
+#endif /* __ASM_MACH_APIC_H */
diff -urN linux-2.5.54.mod/include/asm-i386/mach-bigsmp/mach_ipi.h linux-2.5.54.patch/include/asm-i386/mach-bigsmp/mach_ipi.h
--- linux-2.5.54.mod/include/asm-i386/mach-bigsmp/mach_ipi.h 1969-12-31 16:00:00.000000000 -0800
+++ linux-2.5.54.patch/include/asm-i386/mach-bigsmp/mach_ipi.h 2003-01-01 19:21:13.000000000 -0800
@@ -0,0 +1,24 @@
+#ifndef __ASM_MACH_IPI_H
+#define __ASM_MACH_IPI_H
+
+static inline void send_IPI_mask_sequence(int mask, int vector);
+
+static inline void send_IPI_mask(int mask, int vector)
+{
+ send_IPI_mask_sequence(mask, vector);
+}
+
+static inline void send_IPI_allbutself(int vector)
+{
+ unsigned long mask = cpu_online_map & ~(1 << smp_processor_id());
+
+ if (mask)
+ send_IPI_mask(mask, vector);
+}
+
+static inline void send_IPI_all(int vector)
+{
+ send_IPI_mask(cpu_online_map, vector);
+}
+
+#endif /* __ASM_MACH_IPI_H */
^ permalink raw reply
* RE: opening a port..
From: Dharmendra.T @ 2003-01-09 6:26 UTC (permalink / raw)
To: mdew; +Cc: netfilter
In-Reply-To: <1042092980.487.4.camel@nirvana>
On Thu, 2003-01-09 at 11:46, mdew wrote:
> On Thu, 2003-01-09 at 17:55, Dharmendra.T wrote:
> > On Thu, 2003-01-09 at 08:11, mdew wrote:
> > > On Thu, 2003-01-09 at 03:24, Rob Sterenborg wrote:
> > > > > ok, telnet from another machine to the router.
> > > > >
> > > > > telnet 10.0.0.6 4662
> > > > > Trying 10.0.0.6...
> > > > > telnet: Unable to connect to remote host: Connection refused
> > > > >
> > > > > what "service" should I be running? I simply want 4662 open both ways.
> > > >
> > > > # netstat -an|grep 4662
> > > > should tell you if your box is listening at all on port 4662.
> > > >
> > > > If you run eDonkey server on the firewall box, open port in the INPUT
> > > > chain.
> > > > If your eDonkey server is *behind* the firewall, open the port in the
> > > > FORWARD chain, and add a DNAT rule in the nat table -> PREROUTING chain.
> > >
> > > the edonkey server is behind the firewall
> > >
> > > 210.54.175.12--->eth0 (Router) 10.0.0.6(eth1)--->10.0.0.x
> > >
> > > iptables -t nat -A PREROUTING -p tcp -i eth0 -d 210.54.175.12 --dport 4662 -j DNAT --to 10.0.0.6:4662
> > >
> >
> > This should work without the last rule.
> >
> > iptables -A FORWARD -p tcp -i eth0 -d 10.0.0.6 --dport 4662 -j ACCEPT
> > >
> > > like that?
>
> the router isnt picking this up..
>
> mdew:~# iptables -t nat -A PREROUTING -p tcp -i eth0 -d 210.54.175.12
> --dport 4662 -j DNAT --to 10.0.0.6:4662
> mdew:~# iptables -A FORWARD -p tcp -i eth0 -d 10.0.0.6 --dport 4662 -j
> ACCEPT
> mdew:~# netstat -an|grep 4662
> mdew:~#
>
> mdew@nirvana:~$ nmap 10.0.0.6
>
> Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
> Interesting ports on debian (10.0.0.6):
> (The 1598 ports scanned but not shown below are in state: closed)
> Port State Service
> 22/tcp open ssh
> 25/tcp open smtp
> 110/tcp open pop-3
> 113/tcp open auth
> 135/tcp filtered loc-srv
> 139/tcp filtered netbios-ssn
> 8080/tcp open http-proxy
>
> Nmap run completed -- 1 IP address (1 host up) scanned in 2.545 seconds
> >
>
As said you are not running any service on that port so the port is not
listening, Try the rules by listening a port using nc(netcat)
# nc -l -p 4662
And then run nmap. You should get listed this port!
--
Dharmendra.T
Linux Enthu
^ permalink raw reply
* Re: Problem reading directories
From: @ 2003-01-09 6:24 UTC (permalink / raw)
To: Sergey Suleymanov, Linux-MSDOS Mailing list
> >>>>> José Mario Trujillo writes:
>
> José> Hi, I'm running in a Debian Linux dosmeu 1.1.4 and Freedos 8b.
> José> I tried to install a propietary aplication that creates a
> José> directory tree like c:\#$COMPAC.PRO\COMPAC\ and inside create a
I solve the problem using a msdos image on a diferent disk, which FAT16
filesystem.
Tanks a lot.
José Mario Trujillo.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.