* Executing NAT and iptables on SUMSUNG S3C4510B
From: Cheng,Yu-Chin @ 2003-01-09 10:08 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <3E1D44E7.4040205@msa.hinet.net>
Jenny Cheng wrote:
>
>Dear all:
>
> I have some problems in executing kernel 2.4.19 image with NAT and
>iptables supported on SAMSUNG S3C4510b.
>
> Please see the following information and give me some ideas.
> Kernel about NETWORK configure options and system message.
>
>#
>CONFIG_PACKET=y
>
># CONFIG_PACKET_MMAP is not set
>CONFIG_NETLINK_DEV=y
>CONFIG_NETFILTER=y
>CONFIG_NETFILTER_DEBUG=y
>CONFIG_FILTER=y
>CONFIG_UNIX=y
>CONFIG_INET=y
># CONFIG_IP_MULTICAST is not set
># CONFIG_IP_ADVANCED_ROUTER is not set
># CONFIG_IP_PNP is not set
># CONFIG_NET_IPIP is not set
># CONFIG_NET_IPGRE is not set
># CONFIG_INET_ECN is not set
># CONFIG_SYN_COOKIES is not set
>
>#
># IP: Netfilter Configuration
>#
>CONFIG_IP_NF_CONNTRACK=y
>CONFIG_IP_NF_FTP=y
>CONFIG_IP_NF_IRC=y
>CONFIG_IP_NF_IPTABLES=y
># CONFIG_IP_NF_MATCH_LIMIT is not set
>CONFIG_IP_NF_MATCH_MAC=y
># CONFIG_IP_NF_MATCH_MARK is not set
>CONFIG_IP_NF_MATCH_MULTIPORT=y
>CONFIG_IP_NF_MATCH_TOS=y
># CONFIG_IP_NF_MATCH_AH_ESP is not set
># CONFIG_IP_NF_MATCH_LENGTH is not set
># CONFIG_IP_NF_MATCH_TTL is not set
>CONFIG_IP_NF_MATCH_TCPMSS=y
># CONFIG_IP_NF_MATCH_STATE is not set
>CONFIG_IP_NF_FILTER=y
># CONFIG_IP_NF_TARGET_REJECT is not set
>CONFIG_IP_NF_NAT=y
>CONFIG_IP_NF_NAT_NEEDED=y
>CONFIG_IP_NF_TARGET_MASQUERADE=y
>CONFIG_IP_NF_TARGET_REDIRECT=y
>CONFIG_IP_NF_NAT_LOCAL=y
>CONFIG_IP_NF_NAT_IRC=y
>CONFIG_IP_NF_NAT_FTP=y
>CONFIG_IP_NF_MANGLE=m
># CONFIG_IP_NF_TARGET_TOS is not set
># CONFIG_IP_NF_TARGET_MARK is not set
>CONFIG_IP_NF_TARGET_LOG=y
>CONFIG_IP_NF_TARGET_ULOG=y
># CONFIG_IP_NF_TARGET_TCPMSS is not set
>CONFIG_IP_NF_ARPTABLES=y
>CONFIG_IP_NF_ARPFILTER=y
># CONFIG_VLAN_8021Q is not set
># CONFIG_IPX is not set
># CONFIG_ATALK is not set
>
>
>Unhandled fault: alignment exception (13) at 0x00000001
>fault-common.c(97): start_code=0xfc0040, start_stack=0xfdff78)
>Internal error: Oops: 0
>CPU: 0
>pc : [<000bfbbc>] lr : [<00000006>] Not tainted
>sp : 00e039f0 ip : 00000000 fp : 00e03a54
>r10: 00167ee2 r9 : 00000006 r8 : 00000000
>r7 : 00000006 r6 : 00162534 r5 : 00162500 r4 : 00162544
>r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00167ede
>Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel
>Control: 0
>Process dhcpcd (pid: 11, stackpage=00e03000)
>Stack:
>00e039e0: 00000006 000bfbbc 60000013 ffffffff 00000000 00000000
>00166260 00167e
>e8
>00e03a00: 00167ede 00162420 000deea0 000d6fad 00162500 00167ed0
>00000000 000dee
>a0
>00e03a20: 00000000 00000001 00e03ab0 000e0d90 00e03aac 00000001
>000fffe4 000000
>00
>00e03a40: 00072f9c 00e03ab0 00e03a6c 00e03a58 000c1e30 000bf960
>000e0d3c 000000
>00
>00e03a60: 00e03a9c 00e03a70 0007a80c 000c1e10 00072f9c 00000002
>00000001 000000
>00
>00e03a80: 000deea0 00072f9c 00000000 00000000 00e03adc 00e03aa0
>0007ace4 0007a7
>c0
>00e03aa0: 000deea0 00e03aac 00072f9c 000e0d90 00166260 00000004
>00167ee2 001662
>60
>00e03ac0: 000deea0 00167ed0 00000806 000def18 00e03b18 00e03ae0
>000a6a58 0007ab
>b0
>00e03ae0: 000deea0 00072f9c 00000001 6e00a8c0 00000000 00f720a0
>b600a8c0 000dee
>a0
>00e03b00: 00000000 00000000 6e00a8c0 00e03b50 00e03b1c 000a6414
>000a6844 b600a8
>c0
>00e03b20: 00000000 000def18 00000000 00f720a0 000e8d60 001661c0
>000e8d68 00087a
>78
>00e03b40: 00000000 00e03b70 00e03b54 00077314 000a6340 00f73120
>001661c0 00f731
>20
>00e03b60: 00f720a0 00e03ba0 00e03b74 00077c54 00077240 000e00b4
>00e03bcc 00f731
>20
>00e03b80: 001661c0 00000000 000deea0 00087a78 00000000 00e03bbc
>00e03ba4 00087b
>48
>00e03ba0: 00077bd8 00000001 00000004 00000002 00e03bfc 00e03bc0
>0007ad30 00087a
>88
>00e03bc0: 000deea0 00e03bcc 00087a78 0010007c 001661c0 00000001
>00000003 000000
>02
>00e03be0: 000deea0 00087a5c 00000000 00000000 00e03c14 00e03c00
>0008657c 0007ab
>b0
>00e03c00: 000deea0 00087a78 00e03c24 00e03c18 00087a74 00086524
>00e03c64 00e03c
>28
>00e03c20: 0007ad30 00087a6c 000deea0 00e03c34 00087a5c 00100074
>001661c0 001508
>10
>00e03c40: 001661c0 00174a00 00000404 00f73120 00000000 00150824
>00e03ca8 00e03c
>68
>00e03c60: 00087214 0007abb0 000deea0 00087a5c 00000000 00e03d0c
>000a7d88 000000
>00
>00e03c80: 000003e8 00000000 00e03cbc 00e03cd4 00000000 6e00a8c0
>00e03d0c 00e03d
>08
>00e03ca0: 00e03cac 000a7fd4 00086ec4 00e03cd4 00f73120 00000040
>00174a00 00f731
>20
>00e03cc0: 6e00a8c0 b600a8c0 00000000 00000000 00000000 6e00a8c0
>00e03ce4 000000
>00
>00e03ce0: 00166120 00f73080 001013c0 00000001 00000000 00000000
>000deea0 00e03d
>74
>00e03d00: 00e03d0c 000a882c 000a7e38 00166120 00000000 000003e8
>00000000 000000
>00
>00e03d20: 09c12855 00000001 00e03d84 00166120 00000008 00000000
>00000000 000000
>02
>00e03d40: 00000260 00000000 0000004c 00166120 00f73080 001013c0
>00000001 000000
>00
>00e03d60: 00000000 000deea0 00e03d90 00e03d78 000a8cb8 000a87e0
>00166120 000000
>00
>00e03d80: 00000004 00e03db4 00e03d94 00083920 000a8b54 00000001
>00000001 000000
>02
>00e03da0: 00000000 000837fc 00e03df4 00e03db8 0007ad30 0008380c
>00000000 00e03d
>c4
>00e03dc0: 000837fc 00100064 00166120 00150020 000deea0 00166120
>00000000 00083a
>00
>00e03de0: 00000000 000deea0 00e03e0c 00e03df8 0008353c 0007abb0
>00000000 000837
>fc
>00e03e00: 00e03e3c 00e03e10 00083c28 000834e8 000deea0 00000001
>00000000 000000
>02
>00e03e20: 00000000 00000001 00000000 00000002 00e03e7c 00e03e40
>0007ad30 00083a
>10
>00e03e40: 00000000 00e03e4c 00083a00 0010005c 00166120 00000005
>00166120 001661
>20
>00e03e60: 00100ba0 000deea0 000da260 0000012c 00e03ea8 00e03e80
>00083794 0007ab
>b0
>00e03e80: 00000000 00083a00 00000000 00166120 000deea0 00000008
>000ffd80 00e03e
>dc
>00e03ea0: 00e03eac 000739dc 00083558 0000012b 0000012a 000da150
>00000001 000e8d
>60
>00e03ec0: fffffffb 000da140 000e8d60 60000093 00e03f04 00e03ee0
>00023a7c 000737
>cc
>00e03ee0: 00000000 00000011 20000000 000e1ab0 000e1890 00e03f34
>00e03f30 00e03f
>08
>00e03f00: 00017588 00023a0c 00e03f68 03ff4034 00033180 00032de0
>20000013 ffffff
>ff
>00e03f20: 00fdfea4 00e03f8c 00e03f34 00016960 00017454 00155000
>00000241 000001
>b6
>00e03f40: 0000d300 00000241 00000241 000001b6 00155000 00016dc0
>00000005 00fdfe
>a4
>00e03f60: 00e03f8c 00e03f90 00e03f7c 00033180 00032de0 20000013
>ffffffff 000000
>05
>00e03f80: 00e03fac 00e03f90 00033180 00032de0 00fcfd60 00000241
>ffffffff 00e020
>00
>00e03fa0: 00000000 00e03fb0 00016c20 0003314c 00fcfd60 0001df5c
>00fcfd60 000002
>41
>00e03fc0: 000001b6 000001b6 00fcfd60 00000241 ffffffff 00000000
>00fcfd60 000000
>04
>00e03fe0: 00fdfea4 00fdfd48 00000241 00fdfd34 00fc9dc0 00fc9d74
>20000010 00fcfd
>60
>Backtrace:
>Function entered at [<000bf950>] from [<000c1e30>]
> ^^^^^^^^ arpt_do_table
>Function entered at [<000c1e00>] from [<0007a80c>]
> ^^^^^^^^ arpt_hook
>Function entered at [<0007a7b0>] from [<0007ace4>]
> ^^^^^^^^ nf_iterate
>Function entered at [<0007aba0>] from [<000a6a58>]
> ^^^^^^^^ nf_hook_slow
>Function entered at [<000a6834>] from [<000a6414>]
> ^^^^^^^^ arp_send
>Function entered at [<000a6330>] from [<00077314>]
> ^^^^^^^^ arp_solicit
>Function entered at [<00077230>] from [<00077c54>]
> ^^^^^^^^ __neigh_event_send
> r7 = 00F720A0 r6 = 00F73120 r5 = 001661C0 r4 = 00F73120
>Function entered at [<00077bc8>] from [<00087b48>]
> ^^^^^^^^^ neigh_resolve_output
>Function entered at [<00087a78>] from [<0007ad30>]
> ^^^^^^^^ ip_finish_output2
> r6 = 00000002 r5 = 00000004 r4 = 00000001
>Function entered at [<0007aba0>] from [<0008657c>]
> ^^^^^^^^^^ nf_hook_slow
>Function entered at [<00086514>] from [<00087a74>]
> ^^^^^^^^^^ ip_output
>Function entered at [<00087a5c>] from [<0007ad30>]
> ^^^^^^^^^^ output_maybe_reroute
>Function entered at [<0007aba0>] from [<00087214>]
> ^^^^^^^^^^ nf_iterate
>Function entered at [<00086eb4>] from [<000a7fd4>]
> ^^^^^^^^^ ip_build_xmit
>Function entered at [<000a7e28>] from [<000a882c>]
> ^^^^^^^^^ icmp_reply
>Function entered at [<000a87d0>] from [<000a8cb8>]
> ^^^^^^^^ icmp_echo
>Function entered at [<000a8b44>] from [<00083920>]
> ^^^^^^^^^ icmp_rcv
> r6 = 00000004 r5 = 00000000 r4 = 00166120
>Function entered at [<000837fc>] from [<0007ad30>]
> ^^^^^^^^ ip_local_deliver_finish
> r8 = 000837FC r7 = 00000000 r6 = 00000002 r5 = 00000001
> r4 = 00000001
>Function entered at [<0007aba0>] from [<0008353c>]
> ^^^^^^^^^ nf_iterate
>Function entered at [<000834d8>] from [<00083c28>]
> ^^^^^^^^^ ip_local_deliver
>Function entered at [<00083a00>] from [<0007ad30>]
> ^^^^^^^^ ip_rcv_finish
> r6 = 00000002 r5 = 00000000 r4 = 00000001
>Function entered at [<0007aba0>] from [<00083794>]
> ^^^^^^^ nf_iterate
>Function entered at [<00083548>] from [<000739dc>]
> ^^^^^^^^^ ip_rcv
> r8 = 000FFD80 r7 = 00000008 r6 = 000DEEA0 r5 = 00166120
> r4 = 00000000
>Function entered at [<000737bc>] from [<00023a7c>]
> ^^^^^^^^^ net_rx_action
>Function entered at [<000239fc>] from [<00017588>]
> ^^^^^^^^ do_softirq
>Function entered at [<00017444>] from [<00016960>]
> ^^^^^^^^^ do_IRQ
>Function entered at [<00032dd0>] from [<00033180>]
> ^^^^^^^^^ filp_open
> r4 = 00000005
>Function entered at [<0003313c>] from [<00016c20>]
> ^^^^^^^^ sys_open ^^^^^^
>ret_fast_syscall
> r7 = 00E02000 r6 = FFFFFFFF r5 = 00000241 r4 = 00FCFD60
>Code: e51b0054 e5952008 (e5903000) e5951000 e0033002
>Kernel panic: Aiee, killing interrupt handler
>
>In interrupt handler - not syncing
>
>*Best Regards
>Jenny
>*
>
>
>
>
^ permalink raw reply
* Re: 2.4.18-14 kernel stuck during ext3 umount with ping still responding
From: Andrew Morton @ 2003-01-09 10:06 UTC (permalink / raw)
To: yuval yeret; +Cc: linux-kernel, yuval
In-Reply-To: <F12N44yQegpeDBHkKx400013b3e@hotmail.com>
yuval yeret wrote:
>
> Hi,
>
> I'm running a 2.4.18-14 kernel with a heavy IO profile using ext3 over RAID
> 0+1 volumes.
>
> >From time to time I get a black screen stuck machine while trying to umount
> a volume during an IO workload (as part of a failback solution - but after
> killing all IO processes ), with ping still responding, but everything else
> mostly dead.
>
> I tried using the forcedumount patch to solve this problem - to no avail.
> Also tried upgrading the qlogic drivers to the latest drivers from Qlogic.
>
> After one of the occurences I managed to get some output using the sysrq
> keys.
>
> This seems similar to what is described in
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77508 but with a
> different call trace
>
> What I have here is what I managed to copy down (for some reason pgup/pgdown
> didn't work so not all information is full...) together with a manual lookup
> of the call trace
> from /proc/ksyms :
>
> process umount
> EIP c01190b8 (set_running_and_schedule)
> call trace:
> c01144c9 f25f9ec0 IO_APIC_get_PCI_irq_vector
> c010a8b0 f25f9ed0 enable_irq
> c014200c f25f9ef0 fsync_buffers_list
> c0155595 f25f9efc clear_inode
> c015553d f25f9f2c invalidate_inodes
> c01461d8 f25f9f78 get_super
> c014a629 f25f9f94 path_release
> c0157c58 f25f9fc0 sys_umount
> c0108cab sys_sigaltstack
>
> Any idea what can cause this ?
>
If you have a large amount of data against two or more filesystems,
and you try to unmount one of them the kernel can seize up for a
very long time in the fsync_dev()->sync_buffers() function. Under
these circumstances that function has O(n*n) search complexity
and n is quite large.
However your backtrace shows neither of those functions.
Still, as an experiment it would be interesting to see if the below
patch fixes it up. It converts O(n*n) to O(m), where m > n.
fs/buffer.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--- 2420/fs/buffer.c~a Thu Jan 9 02:03:06 2003
+++ 2420-akpm/fs/buffer.c Thu Jan 9 02:04:02 2003
@@ -307,11 +307,11 @@ int sync_buffers(kdev_t dev, int wait)
* 2) write out all dirty, unlocked buffers;
* 2) wait for completion by waiting for all buffers to unlock.
*/
- write_unlocked_buffers(dev);
+ write_unlocked_buffers(NODEV);
if (wait) {
- err = wait_for_locked_buffers(dev, BUF_DIRTY, 0);
+ err = wait_for_locked_buffers(NODEV, BUF_DIRTY, 0);
write_unlocked_buffers(dev);
- err |= wait_for_locked_buffers(dev, BUF_LOCKED, 1);
+ err |= wait_for_locked_buffers(NODEV, BUF_LOCKED, 1);
}
return err;
}
_
^ permalink raw reply
* Re: lk maintainers
From: Denis Vlasenko @ 2003-01-09 9:57 UTC (permalink / raw)
To: Andre Hedrick; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.10.10301090050510.31168-100000@master.linux-ide.org>
On 9 January 2003 10:51, Andre Hedrick wrote:
> Serial ATA Architect [released][backported]
Updated. Thanks
^ permalink raw reply
* Re: fb_imageblit()
From: Geert Uytterhoeven @ 2003-01-09 9:50 UTC (permalink / raw)
To: Antonino Daplas; +Cc: James Simmons, Linux Frame Buffer Device Development
In-Reply-To: <1042043058.982.115.camel@localhost.localdomain>
On 9 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 23:15, Geert Uytterhoeven wrote:
> > > c. Read color information from pseudopalette if directcolor/truecolor.
> >
> > Hoever, pseudopalette has entries for the first 16 colors only!
> > Hence you are limited to the 16 color for directcolor/truecolor modes.
>
> That's why there's an fb_set_logo_directpalette(), for directcolor
> visuals >= 24bpp, and fb_set_logo_truepalette(), for truecolor, in
> fb_set_logo(). Basically, it temporarily replaces info->pseudo_palette
> with one that has 256 entries to match linux_logo. Logo drawing, using
> cfb_imageblit() has always worked for me in directcolor and truecolor
> modes.
I see a small inconsistency here, which may cause problems with some exotic
hardware: info->pseudo_palette is always initialized by the fbdev driver itself
(which knows the hardware), except for logo drawing, where it's done by the
generic code in fbmem.
On virtually all hardware that will work fine. But on some hardware the exact
pixel format cannot be represented by the {red,green,blue,transp} bitfields in
fb_var_screeninfo.
E.g. the Amiga CyberVision64 card has a S3Trio64. Since Amigas are little
endian and PCI is big endian, they swapped the data bus to simplify 256-color
modes. However, this also means that 16-bit pixel values have to be swapped. So
in depth 15, the pixel format is not ARRRRRGGGGGBBBBB, but GGGBBBBBARRRRRGG.
This can be handled fine in cyberfb by setting up a byteswapped pseudo palette,
but the fb_set_logo_{direct,true}palette() don't know about this. And of course
user space doesn't know about this neither.
One possible solution is to extend the pseudo palette to 256+1 entries if the
depth is at least 8. To save memory, we can still use a 16+1 entry pseudo
palette if depth < 8, but then we have to move the cursor inversion value from
index 16 to index -1.
Note that the old logo code suffered from the same problem and cyberfb hasn't
been updated since a while (it lacks pseudo palette support), so it may not be
that important. I just wanted to mention this case.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* RE: opening a port..
From: mdew @ 2003-01-09 9:51 UTC (permalink / raw)
To: Rob Sterenborg; +Cc: netfilter
In-Reply-To: <FD8F124A387AD6119F7900A0D218B321019AA0@hslex01.hslbz.local>
On Thu, 2003-01-09 at 21:21, Rob Sterenborg wrote:
> > > # 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
> > iptables -A FORWARD -p tcp -i eth0 -d 10.0.0.6 --dport 4662 -j ACCEPT
> >
> > like that?
>
> If default policy for FORWARD is ACCEPT then it should work without the
> FORWARD, else you need it.
>
> For me such a setup works.
>
> If you do a netstat -an on the eDonkey box (you don't need netcat to do
> that) and it doesn't report 4662 then eDonkey is not running/listening
> and you can never connect.
>
> About opening ports for eDonkey, from the eDonkey website :
> (http://www.edonkey2000.com/documentation/index.html)
> ====
> 2. Software Firewall
> If you are running software like Norton Personal Firewall, Tiny
> Firewall, Zone Alarm, BlackIce or <...snip...>
> Alternatively, with some more advanced firewalls, or firewall settings
> you will need to open ports 4661 and 4662 TCP for both incoming and out
> going connections, as well as port 4665 UDP for both incoming and
> outgoing connections.
>
> 3. Hardware firewall
> Setting up your hardware firewall is a tad more difficult, but if you
> have one chances are you know what your doing. You will need to set it
> to allow both incoming and outgoing connections on 4661 & 4662 TCP and
> port 4665 UDP.
> ====
> So you need to open more ports than just 4662/tcp I think.
> And IMHO you want a statefull packetfilter, if you haven't made it
> already statefull.
> (iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT)
>
>
> Rob
>
>
ok heres my current script, yes its inefficient, but thats not the major
problem.. 4662 port :/ I relise that theres more ports available for
edonkey to use, but opening ONE port would be a start.
i added "iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j
ACCEPT" without anything happening...
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_conntrack_irc
/sbin/modprobe ip_nat_irc
/sbin/modprobe ip_nat_ftp
# <<<<< COMPLETE-BLOCKAGE SMB/Samba Traffic >>>>>
iptables -A FORWARD -o eth1 -p tcp --dport 135:139 -j REJECT
iptables -A FORWARD -o eth1 -p udp --dport 135:139 -j REJECT
iptables -A FORWARD -o eth1 -p tcp --sport 135:139 -j REJECT
iptables -A FORWARD -o eth1 -p udp --sport 135:139 -j REJECT
iptables -A FORWARD -o eth0 -p tcp --dport 135:139 -j REJECT
iptables -A FORWARD -o eth0 -p tcp --sport 135:139 -j REJECT
iptables -A FORWARD -o eth0 -p udp --sport 135:139 -j REJECT
iptables -A FORWARD -o eth0 -p udp --dport 135:139 -j REJECT
iptables -A INPUT -i eth0 -p tcp --dport 135:139 -j REJECT
iptables -A INPUT -i eth0 -p udp --dport 135:139 -j REJECT
iptables -A INPUT -i eth0 -p tcp --sport 135:139 -j REJECT
iptables -A INPUT -i eth0 -p udp --sport 135:139 -j REJECT
iptables -A INPUT -i eth1 -p tcp --dport 135:139 -j REJECT
iptables -A INPUT -i eth1 -p udp --dport 135:139 -j REJECT
iptables -A INPUT -i eth1 -p tcp --sport 135:139 -j REJECT
iptables -A INPUT -i eth1 -p udp --sport 135:139 -j REJECT
iptables -A OUTPUT -o eth0 -p tcp --dport 135:139 -j REJECT
iptables -A OUTPUT -o eth0 -p udp --dport 135:139 -j REJECT
iptables -A OUTPUT -o eth0 -p tcp --sport 135:139 -j REJECT
iptables -A OUTPUT -o eth0 -p udp --sport 135:139 -j REJECT
iptables -A OUTPUT -o eth1 -p tcp --dport 135:139 -j REJECT
iptables -A OUTPUT -o eth1 -p udp --dport 135:139 -j REJECT
iptables -A OUTPUT -o eth1 -p tcp --sport 135:139 -j REJECT
iptables -A OUTPUT -o eth1 -p udp --sport 135:139 -j REJECT
iptables -A INPUT -i eth0 -p tcp --dport 113 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 113 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 113 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --sport 113 -j ACCEPT
iptables -A FORWARD -p tcp --dport auth -i eth0 -j ACCEPT
iptables -A FORWARD -p tcp --sport auth -i eth0 -j ACCEPT
iptables -A FORWARD -p tcp --dport auth -i eth1 -j ACCEPT
iptables -A FORWARD -p tcp --sport auth -i eth1 -j ACCEPT
iptables -A FORWARD -o eth0 -p tcp --dport 113 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp --dport 113 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 113 -j ACCEPT
iptables -A FORWARD -i eth1 -p tcp --dport 113 -j ACCEPT
iptables -A FORWARD -p tcp -s 10.0.0.9 --dport 4665 -m limit --limit
1/hour -j ACCEPT
iptables -A FORWARD -p udp -s 10.0.0.9 --dport 4665 -m limit --limit
1/hour -j ACCEPT
iptables -A FORWARD -p udp -s 10.0.0.9 --sport 4665 -m limit --limit
1/hour -j ACCEPT
iptables -A FORWARD -p tcp -s 10.0.0.9 --sport 4665 -m limit --limit
1/hour -j ACCEPT
# Block Outside the Network
iptables -A FORWARD -o eth0 -p tcp --dport 111 -j REJECT
iptables -A INPUT -i eth0 -p tcp --dport 111 -j REJECT
iptables -A FORWARD -o eth0 -p tcp --dport 199 -j REJECT
iptables -A INPUT -i eth0 -p tcp --dport 199 -j REJECT
iptables -A FORWARD -o eth0 -p tcp --dport 826 -j REJECT
iptables -A INPUT -i eth0 -p tcp --dport 826 -j REJECT
iptables -A FORWARD -o eth0 -p tcp --dport 953 -j REJECT
iptables -A INPUT -i eth0 -p tcp --dport 953 -j REJECT
# Block Inside the Network
iptables -A FORWARD -o eth1 -p tcp --dport 111 -j REJECT
iptables -A INPUT -i eth1 -p tcp --dport 111 -j REJECT
iptables -A FORWARD -o eth1 -p tcp --dport 199 -j REJECT
iptables -A INPUT -i eth1 -p tcp --dport 199 -j REJECT
iptables -A FORWARD -o eth1 -p tcp --dport 826 -j REJECT
iptables -A INPUT -i eth1 -p tcp --dport 826 -j REJECT
iptables -A INPUT -i eth1 -p tcp --dport 953 -j REJECT
iptables -A INPUT -i eth0 -p tcp --dport 4661 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 4661 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 4661 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 4661 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --sport 4661 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --sport 4661 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --sport 4661 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 4661 -j ACCEPT
iptables -A FORWARD -o eth0 -p tcp --dport 4661 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp --dport 4661 -j ACCEPT
iptables -A FORWARD -o eth1 -p udp --dport 4661 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --dport 4661 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --sport 4661 -j ACCEPT
iptables -A FORWARD -o eth1 -p udp --sport 4661 -j ACCEPT
ptables -A FORWARD -o eth0 -p tcp --sport 4661 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 4662 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 4662 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 4662 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 4662 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --sport 4662 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --sport 4662 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --sport 4662 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 4662 -j ACCEPT
iptables -A FORWARD -o eth0 -p tcp --dport 4662 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp --dport 4662 -j ACCEPT
iptables -A FORWARD -o eth1 -p udp --dport 4662 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --dport 4662 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --sport 4662 -j ACCEPT
iptables -A FORWARD -o eth1 -p udp --sport 4662 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp --sport 4662 -j ACCEPT
iptables -A FORWARD -o eth0 -p tcp --sport 4662 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 4665 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 4665 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 4665 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 4665 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --sport 4665 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --sport 4665 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --sport 4665 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 4665 -j ACCEPT
iptables -A FORWARD -o eth0 -p tcp --dport 4665 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp --dport 4665 -j ACCEPT
iptables -A FORWARD -o eth1 -p udp --dport 4665 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --dport 4665 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --sport 4665 -j ACCEPT
iptables -A FORWARD -o eth1 -p udp --sport 4665 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp --sport 4665 -j ACCEPT
iptables -A FORWARD -o eth0 -p tcp --sport 4665 -j ACCEPT
^ permalink raw reply
* Re: [Linux-fbdev-devel] Re: rotation.
From: Helge Hafting @ 2003-01-09 10:00 UTC (permalink / raw)
To: Sven Luther, linux-kernel
In-Reply-To: <20030108104817.GA10165@iliana>
Sven Luther wrote:
>
> So, we also support fbcon for not left to righ locales ?
This looks like a high-level thing to me.
Ideally something like ansi escape sequences to switch between
left-to-right, right-to-left, and up-to-down advancing of
the cursor. Then the same multilingual apps will work with
fbdev, xterm, and other terminals and emulators that
implement those operations.
Helge Hafting
^ permalink raw reply
* Re: 2.4.18-14 kernel stuck during ext3 umount with ping still responding
From: Arjan van de Ven @ 2003-01-09 9:58 UTC (permalink / raw)
To: yuval yeret; +Cc: linux-kernel, yuval
In-Reply-To: <F12N44yQegpeDBHkKx400013b3e@hotmail.com>
[-- Attachment #1: Type: text/plain, Size: 562 bytes --]
On Thu, 2003-01-09 at 10:38, yuval yeret wrote:
> Hi,
>
> I'm running a 2.4.18-14 kernel with a heavy IO profile using ext3 over RAID
> 0+1 volumes.
>
> >From time to time I get a black screen stuck machine while trying to umount
> a volume during an IO workload (as part of a failback solution - but after
> killing all IO processes ), with ping still responding, but everything else
> mostly dead.
>
> I'm hoping the ext3fix.patch will solve this problem... am trying that now.
this got fixed in the recent erratum kernel 2.4.18-19.8.0
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: More than one battery
From: Mattia Dongili @ 2003-01-09 9:47 UTC (permalink / raw)
To: Pavel Machek
Cc: thoma-iYtK5bfT9M8b1SvskN2V4Q, danielk-L9gzEf+okJWVc3sceRu5cw,
heatload-general-0fE9KPoRgkgATYTw5x5z8w,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
acpi-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20030107174331.GB893-XqDnSF8rrUM@public.gmane.org>
On Tue, 7 Jan 2003 18:43:31 +0100
Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:
> > QUESTION TO THE GURUS:
> > Are there more things (excpt the battery) that could me multiple?
>
> Yes.
>
> Thermal zones and CPUs, IIRC.
> Pavel
and buttons
--
mattia
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: disabling module version support
From: Toby Fisher @ 2003-01-09 9:46 UTC (permalink / raw)
To: ransom .; +Cc: linux-admin
In-Reply-To: <F150GOkevWWGxegIqun00000162@hotmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 8 Jan 2003, ransom . wrote:
>
>
>
>
> How does one compile a kernel without version support? [ie- one that won't
> complain if a module with a different version number is loaded]
> Basically, I want a kernel that allows me to
>
> # insmod ./hello.o
>
> without this:
> # insmod hellomodule.o
> hellomodule.o: kernel-module version mismatch
> hellomodule.o was compiled for kernel version 2.4.18
> while this kernel is version 2.4.20.
>
> as described in the first couple of paragraphs in chapter 2 of oreilly's
> "Linux device drivers, which can be found here:
> http://www.xml.com/ldd/chapter/book/ch02.html
>
> I've tried the following:
> # insmod -f hellomodule.o
> Warning: kernel-module version mismatch
> hellomodule.o was compiled for kernel version 2.4.18
> while this kernel is version 2.4.20
> Warning: loading hellomodule.o will taint the kernel: no license
> See http://www.tux.org/lkml/#export-tainted for information about tainted
> modules
> Warning: loading hellomodule.o will taint the kernel: forced load
> Module hellomodule loaded, with warnings
> # rmmod hellomodule
>
> so that's great, EXCEPT I didn't get the messages printed to stdout that I
> was supposed to as described in the Linux Device Drivers book
> (http://www.xml.com/ldd/chapter/book/ch02.html)
> eg-
> save
>
> #define MODULE
> #include <linux/module.h>
>
> int init_module(void) { printk("<1>Hello, world\n"); return 0; }
> void cleanup_module(void) { printk("<1>Goodbye cruel world\n"); }
>
> as hello.c (or whatever name), then
>
>
> root# gcc -c hello.c
> root# insmod ./hello.o
> Hello, world
> root# rmmod hello
> Goodbye cruel world
> root#
>
> "Hello, world", as you can see in my ACTUAL output, didn't appear on screen.
>
> Perhaps this is a programming issue? But it seems as though a proper
> configuration would allow me to duplicate what's in the book.
You'll need to recompile your kernel.
When doing a make config, it's about the 3rd question in, "Set version
information on all module symbols"
and here is what the kernel config help has to say.
CONFIG_MODVERSIONS:
Usually, modules have to be recompiled whenever you switch to a new
kernel. Saying Y here makes it possible, and safe, to use the
same modules even after compiling a new kernel; this requires the
program modprobe. All the software needed for module support is in
the modutils package (check the file Documentation/Changes
for location and latest version). NOTE: if you say Y here but don't
have the program genksyms (which is also contained in the above
mentioned modutils package), then the building of your kernel will
fail. If you are going to use modules that are generated from
non-kernel sources, you would benefit from this option. Otherwise
it's not that important. So, N ought to be a safe bet.
HTH
- --
Toby Fisher Email: toby@tjfisher.co.uk
Tel.: +44(0)1480 417272 Mobile: +44(0)7974 363239
ICQ: #61744808
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/
iD8DBQE+HUUYKl9qIwuqk+IRAhiNAKCyhuDysnHaxNCGkQUp+D9NUobU4QCeIVvP
LjoM1CTBUI0YcM6+iDZLrdY=
=6Tmr
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PREFIX is non-empty
From: Miles Bader @ 2003-01-09 9:49 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-kernel
Since these are just symbols in the module object, they need symbol name
munging to find the symbol from the parameter name.
[I guess using the stack is bad in general, but parameter names should be
very short, and hey if they're obsolete, it seems pointless to spend
much effort.]
diff -ruN -X../cludes linux-2.5.55-moo.orig/kernel/module.c linux-2.5.55-moo/kernel/module.c
--- linux-2.5.55-moo.orig/kernel/module.c 2003-01-09 13:44:25.000000000 +0900
+++ linux-2.5.55-moo/kernel/module.c 2003-01-09 14:07:36.000000000 +0900
@@ -685,13 +685,18 @@
num, obsparm[i].name, obsparm[i].type);
for (i = 0; i < num; i++) {
+ char sym_name[strlen (obsparm[i].name) + 2];
+
+ strcpy (sym_name, MODULE_SYMBOL_PREFIX);
+ strcat (sym_name, obsparm[i].name);
+
kp[i].name = obsparm[i].name;
kp[i].perm = 000;
kp[i].set = set_obsolete;
kp[i].get = NULL;
obsparm[i].addr
= (void *)find_local_symbol(sechdrs, symindex, strtab,
- obsparm[i].name);
+ sym_name);
if (!obsparm[i].addr) {
printk("%s: falsely claims to have parameter %s\n",
name, obsparm[i].name);
^ permalink raw reply
* [PATCH] Prevent .gnu.linkonce.this_module section from being merged with other sections
From: Miles Bader @ 2003-01-09 9:49 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-kernel
As I mentioned in an earlier email, this is necessary on the v850
because the default -r linker-script merges .gnu.linkonce.t* into the
.text output section. I don't think it will hurt any other platforms.
diff -ruN -X../cludes linux-2.5.55-moo.orig/Makefile linux-2.5.55-moo/Makefile
--- linux-2.5.55-moo.orig/Makefile 2003-01-09 14:03:45.000000000 +0900
+++ linux-2.5.55-moo/Makefile 2003-01-09 14:07:36.000000000 +0900
@@ -163,7 +164,7 @@
MODFLAGS = -DMODULE
CFLAGS_MODULE = $(MODFLAGS)
AFLAGS_MODULE = $(MODFLAGS)
-LDFLAGS_MODULE = -r
+LDFLAGS_MODULE = -r --unique=.gnu.linkonce.this_module
CFLAGS_KERNEL =
AFLAGS_KERNEL =
^ permalink raw reply
* [PATCH] Update v850 module support for 2.5.55
From: Miles Bader @ 2003-01-09 9:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
diff -ruN -X../cludes linux-2.5.55-moo.orig/include/asm-v850/module.h linux-2.5.55-moo/include/asm-v850/module.h
--- linux-2.5.55-moo.orig/include/asm-v850/module.h 2002-11-28 10:25:08.000000000 +0900
+++ linux-2.5.55-moo/include/asm-v850/module.h 2003-01-09 15:31:06.000000000 +0900
@@ -1,9 +1,9 @@
/*
* include/asm-v850/module.h -- Architecture-specific module hooks
*
- * Copyright (C) 2001,02 NEC Corporation
- * Copyright (C) 2001,02 Miles Bader <miles@gnu.org>
- * Copyright (C) 2001 Rusty Russell
+ * Copyright (C) 2001,02,03 NEC Corporation
+ * Copyright (C) 2001,02,03 Miles Bader <miles@gnu.org>
+ * Copyright (C) 2001,03 Rusty Russell
*
* This file is subject to the terms and conditions of the GNU General
* Public License. See the file COPYING in the main directory of this
@@ -27,16 +27,28 @@
struct mod_arch_specific
{
- /* How much of the core is actually taken up with core (then
- we know the rest is for the PLT). */
- unsigned int core_plt_offset;
-
- /* Same for init. */
- unsigned int init_plt_offset;
+ /* Indices of PLT sections within module. */
+ unsigned int core_plt_section, init_plt_section;
};
#define Elf_Shdr Elf32_Shdr
#define Elf_Sym Elf32_Sym
#define Elf_Ehdr Elf32_Ehdr
+/* Make empty sections for module_frob_arch_sections to expand. */
+#ifdef MODULE
+asm(".section .plt,\"ax\",@nobits; .align 3; .previous");
+asm(".section .init.plt,\"ax\",@nobits; .align 3; .previous");
+#endif
+
+/* We don't do exception tables. */
+struct exception_table_entry;
+static inline const struct exception_table_entry *
+search_extable(const struct exception_table_entry *first,
+ const struct exception_table_entry *last,
+ unsigned long value)
+{
+ return 0;
+}
+
#endif /* __V850_MODULE_H__ */
diff -ruN -X../cludes linux-2.5.55-moo.orig/arch/v850/kernel/module.c linux-2.5.55-moo/arch/v850/kernel/module.c
--- linux-2.5.55-moo.orig/arch/v850/kernel/module.c 2003-01-06 10:50:58.000000000 +0900
+++ linux-2.5.55-moo/arch/v850/kernel/module.c 2003-01-09 14:42:47.000000000 +0900
@@ -1,9 +1,9 @@
/*
* arch/v850/kernel/module.c -- Architecture-specific module functions
*
- * Copyright (C) 2002 NEC Corporation
- * Copyright (C) 2002 Miles Bader <miles@gnu.org>
- * Copyright (C) 2001 Rusty Russell
+ * Copyright (C) 2002,03 NEC Electronics Corporation
+ * Copyright (C) 2002,03 Miles Bader <miles@gnu.org>
+ * Copyright (C) 2001,03 Rusty Russell
*
* This file is subject to the terms and conditions of the GNU General
* Public License. See the file COPYING in the main directory of this
@@ -100,18 +100,31 @@
return ret;
}
-long module_core_size (const Elf32_Ehdr *hdr, const Elf32_Shdr *sechdrs,
- const char *secstrings, struct module *mod)
+int module_frob_arch_sections(Elf32_Ehdr *hdr,
+ Elf32_Shdr *sechdrs,
+ char *secstrings,
+ struct module *me)
{
- mod->arch.core_plt_offset = (mod->core_size + 3) & ~3;
- return mod->core_size + get_plt_size (hdr, sechdrs, secstrings, 1);
-}
+ unsigned int i;
-long module_init_size (const Elf32_Ehdr *hdr, const Elf32_Shdr *sechdrs,
- const char *secstrings, struct module *mod)
-{
- mod->arch.init_plt_offset = (mod->init_size + 3) & ~3;
- return mod->init_size + get_plt_size (hdr, sechdrs, secstrings, 1);
+ /* Find .plt and .pltinit sections */
+ for (i = 0; i < hdr->e_shnum; i++) {
+ if (strcmp(secstrings + sechdrs[i].sh_name, ".init.plt") == 0)
+ me->arch.init_plt_section = i;
+ else if (strcmp(secstrings + sechdrs[i].sh_name, ".plt") == 0)
+ me->arch.core_plt_section = i;
+ }
+ if (!me->arch.core_plt_section || !me->arch.init_plt_section) {
+ printk("Module doesn't contain .plt or .plt.init sections.\n");
+ return -ENOEXEC;
+ }
+
+ /* Override their sizes */
+ sechdrs[me->arch.core_plt_section].sh_size
+ = get_plt_size(hdr, sechdrs, secstrings, 0);
+ sechdrs[me->arch.init_plt_section].sh_size
+ = get_plt_size(hdr, sechdrs, secstrings, 1);
+ return 0;
}
int apply_relocate (Elf32_Shdr *sechdrs, const char *strtab,
@@ -123,7 +136,8 @@
}
/* Set up a trampoline in the PLT to bounce us to the distant function */
-static uint32_t do_plt_call(void *location, Elf32_Addr val, struct module *mod)
+static uint32_t do_plt_call (void *location, Elf32_Addr val,
+ Elf32_Shdr *sechdrs, struct module *mod)
{
struct v850_plt_entry *entry;
/* Instructions used to do the indirect jump. */
@@ -137,10 +151,10 @@
/* Init, or core PLT? */
if (location >= mod->module_core
- && location < mod->module_core + mod->arch.core_plt_offset)
- entry = mod->module_core + mod->arch.core_plt_offset;
+ && location < mod->module_core + mod->core_size)
+ entry = (void *)sechdrs[mod->arch.core_plt_section].sh_addr;
else
- entry = mod->module_init + mod->arch.init_plt_offset;
+ entry = (void *)sechdrs[mod->arch.init_plt_section].sh_addr;
/* Find this entry, or if that fails, the next avail. entry */
while (entry->tramp[0])
@@ -199,7 +213,7 @@
/* Maybe jump indirectly via a PLT table entry. */
if ((int32_t)(val - (uint32_t)loc) > 0x1fffff
|| (int32_t)(val - (uint32_t)loc) < -0x200000)
- val = do_plt_call (loc, val, mod);
+ val = do_plt_call (loc, val, sechdrs, mod);
val -= (uint32_t)loc;
^ permalink raw reply
* [PATCH] Small update to arch/v850/README
From: Miles Bader @ 2003-01-09 9:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
diff -ruN -X../cludes linux-2.5.55-moo.orig/arch/v850/README linux-2.5.55-moo/arch/v850/README
--- linux-2.5.55-moo.orig/arch/v850/README 2002-11-05 11:25:21.000000000 +0900
+++ linux-2.5.55-moo/arch/v850/README 2003-01-09 14:07:36.000000000 +0900
@@ -1,7 +1,6 @@
This port to the NEC V850E processor supports the following platforms:
- + The gdb v850e simulator (CONFIG_V850E_SIM); see the subdirectory `sim'
- for some more support files for this.
+ + The gdb v850e simulator (CONFIG_V850E_SIM).
+ The Midas labs RTE-V850E/MA1-CB evaluation board (CONFIG_RTE_CB_MA1),
with untested support for the RTE-V850E/NB85E-CB board
^ permalink raw reply
* Re: PIC programming question
From: Wilbert Knol @ 2003-01-09 9:38 UTC (permalink / raw)
To: Phil; +Cc: linux-hams
In-Reply-To: <200301062005.06383.phil@spiderweb.com.au>
On Tue, 7 Jan 2003, Phil wrote:
> An Internet search didn't reveal very many programmers for Linux. One
A programmer for DOS will likely run in an XDOS box. With FreeDOS, you
don't even need a MS copy of DOS....
The same applies for Windows apps under the Wine emulator (although
the results can be a bit less predictable here). Again: you don't
even need to own Windows.
A collegue of mine uses a programmer bought at Dick Smith's, which, he
says, is one of the better ones. No doubt you can get them in Oz, too.
Wilbert, ZL2BSJ
^ permalink raw reply
* [PATCH] Define `read_barrier_depends' on v850
From: Miles Bader @ 2003-01-09 9:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
diff -ruN -X../cludes linux-2.5.55-moo.orig/include/asm-v850/system.h linux-2.5.55-moo/include/asm-v850/system.h
--- linux-2.5.55-moo.orig/include/asm-v850/system.h 2002-11-05 11:25:32.000000000 +0900
+++ linux-2.5.55-moo/include/asm-v850/system.h 2003-01-09 14:07:36.000000000 +0900
@@ -1,8 +1,8 @@
/*
* include/asm-v850/system.h -- Low-level interrupt/thread ops
*
- * Copyright (C) 2001,02 NEC Corporation
- * Copyright (C) 2001,02 Miles Bader <miles@gnu.org>
+ * Copyright (C) 2001,02,03 NEC Corporation
+ * Copyright (C) 2001,02,03 Miles Bader <miles@gnu.org>
*
* This file is subject to the terms and conditions of the GNU General
* Public License. See the file COPYING in the main directory of this
@@ -67,6 +67,7 @@
#define mb() __asm__ __volatile__ ("" ::: "memory")
#define rmb() mb ()
#define wmb() mb ()
+#define read_barrier_depends() ((void)0)
#define set_rmb(var, value) do { xchg (&var, value); } while (0)
#define set_mb(var, value) set_rmb (var, value)
#define set_wmb(var, value) do { var = value; wmb (); } while (0)
^ permalink raw reply
* [PATCH] Include <asm/posix_types.h> in the v850's asm/stat.h
From: Miles Bader @ 2003-01-09 9:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
This is needed by some includers of <asm/stat.h>.
diff -ruN -X../cludes linux-2.5.55-moo.orig/include/asm-v850/stat.h linux-2.5.55-moo/include/asm-v850/stat.h
--- linux-2.5.55-moo.orig/include/asm-v850/stat.h 2002-11-28 10:25:08.000000000 +0900
+++ linux-2.5.55-moo/include/asm-v850/stat.h 2003-01-09 14:07:36.000000000 +0900
@@ -1,6 +1,21 @@
+/*
+ * include/asm-v850/stat.h -- v850 stat structure
+ *
+ * Copyright (C) 2001,02,03 NEC Corporation
+ * Copyright (C) 2001,02,03 Miles Bader <miles@gnu.org>
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * Written by Miles Bader <miles@gnu.org>
+ */
+
#ifndef __V850_STAT_H__
#define __V850_STAT_H__
+#include <asm/posix_types.h>
+
struct stat {
__kernel_dev_t st_dev;
__kernel_ino_t st_ino;
^ permalink raw reply
* sed-1.3 problems [WAS: Re: ash and String Manipulation]
From: jb1 @ 2003-01-09 9:37 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linux-8086
In-Reply-To: <20030107125209.GD29126@raq465.uk2net.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2638 bytes --]
On Tue, 7 Jan 2003, Paul Nasrat wrote:
> diff -ruN sed-minix/Makefile sed/Makefile
> --- sed-minix/Makefile Mon Jun 1 17:46:50 1998
> +++ sed/Makefile Tue Jan 7 12:45:24 2003
> @@ -2,14 +2,16 @@
>
> VERSION=1.3
>
> -CFLAGS=-g
> -LFLAGS=-lg
> +CFLAGS=-0
> +CC=bcc
> +CPP=gcc -E
> +#LFLAGS=-lg
>
> sed: sedcomp.o sedexec.o
> - cc $(LFLAGS) sedcomp.o sedexec.o -o sed
> + bcc $(LFLAGS) sedcomp.o sedexec.o -o sed
>
> mnsed: mnsed.c
> - cc $(LFLAGS) mnsed.c -o mnsed
> + bcc $(LFLAGS) mnsed.c -o mnsed
>
> sedcomp.o: sedcomp.c sed.h
> sedexec.o: sedexec.c sed.h
> -
Paul Nasrat's diff patch to sed-1.3's Makefile seemed inappropriate for
ELKS, so I edited the Makefile to this:
------ cut ------ cut ------ cut ------ cut ------ cut ------ cut ------
# Makefile for the GNU/MINIX sed utility
## Modified for ELKS:
## eliminate all references to "CFLAGS" and "LFLAGS" then do it like an
## elkscmd program, but from a subdirectory at the same level as the
## elkscmd subdirectory
## -- JB
VERSION=1.3
BASEDIR=../elkscmd
include $(BASEDIR)/Make.defs
include $(BASEDIR)/Make.rules
sed: sedcomp.o sedexec.o
bcc sedcomp.o sedexec.o -o sed
mnsed: mnsed.c
bcc mnsed.c -o mnsed
sedcomp.o: sedcomp.c sed.h
sedexec.o: sedexec.c sed.h
FILES = READ.ME BUGS Makefile sed.h sedcomp.c sedexec.c mnsed.c ctrans sedtest sed.1 sed.lsm
sed-$(VERSION).tar: $(FILES)
tar -cvf sed-$(VERSION).tar $(FILES)
sed-$(VERSION).tar.gz: sed-$(VERSION).tar
gzip sed-$(VERSION).tar
clean:
rm -f sed sedcomp.o sedexec.o mnsed
------ cut ------ cut ------ cut ------ cut ------ cut ------ cut ------
The command "make sed" compiled a program that works correctly under
elksemu for both "sedtest" included in sed-1.3.tar.gz and a
similarly-constructed test I cobbled from "BUGS" in sed-1.3.tar.gz (note:
the reported bug is *not* present). However, when run under ELKS (with
"meminfo" reporting 166KB free) both test programs fail with the error
message "not enough memory". Issuing the first "script" of "sedtest" from
the keyboard:
sed -e "s/test file/result file/" sedtest
works correctly, but doing the same with the second "script":
sed -e "/delete/d" sedtest
just hangs. Reducing POOLSIZE (the size of the string-pool space) in
sedcomp.c from 10000 to 6000 (as it is in mnsed.c) didn't help.
Issuing the command "make mnsed" spews error messages.
I've attached "bugstest" as a zip file so that the tab characters aren't
altered.
Note: When running "sedtest" or "bugtest" under elksemu the sed command in
each *must* be edited to "./sed" or similar, otherwise the Linux version
rather than the ELKS version will be executed.
[-- Attachment #2: Type: APPLICATION/zip, Size: 301 bytes --]
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Fabio Massimo Di Nitto @ 2003-01-09 9:43 UTC (permalink / raw)
To: Wichert Akkerman; +Cc: Andrew McGregor, netdev, linux-kernel
In-Reply-To: <20030109093836.GG22951@wiggy.net>
On Thu, 9 Jan 2003, Wichert Akkerman wrote:
> Previously Fabio Massimo Di Nitto wrote:
> > Is the WinXP client located in the same place where you are?
>
> Yes. (Well, not my place but a friend who had both linux and XP did
> that test).
>
> Wichert.
>
>
hmmmm strange because now I have forced the route to ipv6.lkml.org via
another ISP (bypassing xs26.net) and it is more than 3 hours that xmms is
streaming without interruptions.
Fabio
^ permalink raw reply
* Re: Re: 2.5 fbdev & driver initial mode
From: Geert Uytterhoeven @ 2003-01-09 9:30 UTC (permalink / raw)
To: James Simmons; +Cc: Benjamin Herrenschmidt, Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0301090027200.4976-100000@phoenix.infradead.org>
On Thu, 9 Jan 2003, James Simmons wrote:
> > How is a driver supposed to set the default mode on init lately ?
> >
> > Looking at rivafb, it fills info->var from fb_find_mode with the mode
> > option if any, but then does nothing with it (and does nothing if
> > no mode option is passed).
> >
> > On radeonfb, I fill a var with the default mode obtained
> > from EDID or the option if any. Then, I basically do
> >
> > info->var = var;
> > var.activate = FB_ACTIVATE_NOW;
> > fb_set_var(&var, info);
> >
> > before calling register_framebuffer.
> >
> > What is the right way to do ?
>
> Sorry about the confusion. The answer depends on the driver. For the
> rivafb driver because it has a VGA core we have it NOT switch to a
> graphics state. The reason is
>
>
> 1) If we run a /dev/fb app was can save the hardware text mode state and
> restore it on closing /dev/fb. You can see this in rivafb_open and
> rivafb_release.
>
> 2) We can test loading it as a module as see debugging info while still
> having a VGA text mode. Makes life a little easier. The other thing
> I like to do is run mdacon and just the fbdev driver by itself. I can
> then test the fbdev driver. When I get really brave I test fbcon.c and
> can debug it.
>
> Now for graphics hardware built in that has no hardware text mode. It is
> better to set the video mode right away.
Note: on some platforms graphics chips with VGA cores are _not_ initialized to
VGA mode by the firmware. So great care should be taken when not explicitly
switching to graphics mode on those platforms.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: Helge Hafting @ 2003-01-09 9:42 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
In-Reply-To: <200301082133.h08LXlRA014406@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
> $ DIR FOO.TXT;*
> FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
>
> VMS-style file versioning, anybody? ;)
This certainly lets you recover old overwritten files,
but VMS didn't protect against a "rm *". It'd
delete all revisions in one go.
Helge Hafting
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Wichert Akkerman @ 2003-01-09 9:38 UTC (permalink / raw)
To: Fabio Massimo Di Nitto; +Cc: Andrew McGregor, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.51.0301090822001.19862@trider-g7.ext.fabbione.net>
Previously Fabio Massimo Di Nitto wrote:
> Is the WinXP client located in the same place where you are?
Yes. (Well, not my place but a friend who had both linux and XP did
that test).
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> http://www.wiggy.net/
A random hacker
^ permalink raw reply
* [BENCHMARK]unixbench result for kernel 2.5.55.
From: Sowmya Adiga @ 2003-01-09 9:38 UTC (permalink / raw)
To: linux-kernel
Hi,
Here are the unixbench result for kernel 2.5.55. when compared
with kernel 2.5.54 there was no significant differnece in the test
results.
------------------------------------------------------------------------
----
kernel 2.5.55
------------------------------------------------------------------------
----
BYTE UNIX Benchmarks (Version 4.1.0)
System -- Linux access1 2.5.55 #10 Thu Jan 9 10:29:24 IST 2003 i686
unknown
Start Benchmark Run: Thu Jan 9 11:57:05 IST 2003
1 interactive users.
11:57am up 1 min, 1 user, load average: 0.13, 0.08, 0.03
lrwxrwxrwx 1 root root 4 Oct 22 00:35 /bin/sh ->
bash/bin/sh: symbolic link to bash
/dev/hda2 8262068 3815592 4026780 49% /data
Dhrystone 2 using register variables 1804749.6lps (10.0 secs,10
samples)
Double-Precision Whetstone 476.9 MWIPS (10.0 secs,10
samples)
System Call Overhead 449629.7lps (10.0 secs,10
samples)
Pipe Throughput 450120.7 lps (10.0 secs,10
samples)
Pipe-based Context Switching 201606.5 lps (10.0 secs,10
samples)
Process Creation 4297.4 lps (30.0 secs, 3
samples)
Execl Throughput 899.9 lps (30.0 secs, 3
samples)
File Read 1024 bufsize 2000 maxblocks 243970.0KBps (30.0 secs, 3
samples)
File Write 1024 bufsize 2000 maxblocks 96131.0 KBps (30.0 secs, 3
samples)
File Copy 1024 bufsize 2000 maxblocks 67314.0 KBps (30.0 secs, 3
samples)
File Read 256 bufsize 500 maxblocks 112911.0KBps (30.0 secs, 3
samples)
File Write 256 bufsize 500 maxblocks 52060.0KBps (30.0 secs, 3
samples)
File Copy 256 bufsize 500 maxblocks 32760.0 KBps (30.0 secs, 3
samples)
File Read 4096 bufsize 8000 maxblocks 336476.0KBps (30.0 secs, 3
samples)
File Write 4096 bufsize 8000 maxblocks 124355.0KBps (30.0 secs, 3
samples)
File Copy 4096 bufsize 8000 maxblocks 89195.0 KBps (30.0 secs, 3
samples)
Shell Scripts (1 concurrent) 892.4 lpm (60.0 secs, 3
samples)
Shell Scripts (8 concurrent) 116.0 lpm (60.0 secs, 3
samples)
Shell Scripts (16 concurrent) 58.0 lpm (60.0 secs, 3
samples)
Arithmetic Test (type = short) 208076.5lps (10.0 secs, 3
samples)
Arithmetic Test (type = int) 225163.1lps (10.0 secs, 3
samples)
Arithmetic Test (type = long) 225115.3lps (10.0 secs, 3
samples)
Arithmetic Test (type = float) 227406.3lps (10.0 secs, 3
samples)
Arithmetic Test (type = double) 227413.1lps (10.0 secs, 3
samples)
Arithoh 3996379.5lps (10.0 secs, 3
samples)
C Compiler Throughput 409.0 lpm (60.0 secs, 3
samples)
Dc: sqrt(2) to 99 decimal places 34733.6 lpm (30.0 secs, 3
samples)
Recursion Test--Tower of Hanoi 28911.6 lps (20.0 secs, 3
samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 1804749.6 154.6
Double-Precision Whetstone 55.0 476.9 86.7
Execl Throughput 43.0 899.9 209.3
File Copy 1024 bufsize 2000 maxblocks 3960.0 67314.0 170.0
File Copy 256 bufsize 500 maxblocks 1655.0 32760.0 197.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 89195.0 153.8
Pipe Throughput 12440.0 450120.7 361.8
Process Creation 126.0 4297.4 341.1
Shell Scripts (8 concurrent) 6.0 116.0 193.3
System Call Overhead 15000.0 449629.7 299.8
=========
FINAL SCORE 200.3
------------------------------------------------------------------------
----Regards
Sowmya Adiga
Project Engineer
Wipro Technologies
53/1,Hosur Road,Madivala
Bangalore-560 068,INDIA
Tel: +91-80-5502001 Extn.5086
sowmya.adiga@wipro.com
^ permalink raw reply
* 2.4.18-14 kernel stuck during ext3 umount with ping still responding
From: yuval yeret @ 2003-01-09 9:38 UTC (permalink / raw)
To: linux-kernel; +Cc: yuval
Hi,
I'm running a 2.4.18-14 kernel with a heavy IO profile using ext3 over RAID
0+1 volumes.
>From time to time I get a black screen stuck machine while trying to umount
a volume during an IO workload (as part of a failback solution - but after
killing all IO processes ), with ping still responding, but everything else
mostly dead.
I tried using the forcedumount patch to solve this problem - to no avail.
Also tried upgrading the qlogic drivers to the latest drivers from Qlogic.
After one of the occurences I managed to get some output using the sysrq
keys.
This seems similar to what is described in
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77508 but with a
different call trace
What I have here is what I managed to copy down (for some reason pgup/pgdown
didn't work so not all information is full...) together with a manual lookup
of the call trace
from /proc/ksyms :
process umount
EIP c01190b8 (set_running_and_schedule)
call trace:
c01144c9 f25f9ec0 IO_APIC_get_PCI_irq_vector
c010a8b0 f25f9ed0 enable_irq
c014200c f25f9ef0 fsync_buffers_list
c0155595 f25f9efc clear_inode
c015553d f25f9f2c invalidate_inodes
c01461d8 f25f9f78 get_super
c014a629 f25f9f94 path_release
c0157c58 f25f9fc0 sys_umount
c0108cab sys_sigaltstack
Any idea what can cause this ?
I'm hoping the ext3fix.patch will solve this problem... am trying that now.
Thanks,
Yuval
P.S. please CC me for questions/replies as I'm not currently subscribed to
the list.
--
Yuval Yeret
Exanet
http://www.exanet.com
Tel. 972-9-9717782
Fax. 972-9-9717778
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
^ permalink raw reply
* Re: Booting Linux from an already running linux
From: Wolfgang Denk @ 2003-01-09 9:18 UTC (permalink / raw)
To: Anders Blomdell; +Cc: linuxppc embedded
In-Reply-To: <8CD0F4AF-23B1-11D7-98E2-0003931C2BFA@control.lth.se>
In message <8CD0F4AF-23B1-11D7-98E2-0003931C2BFA@control.lth.se> you wrote:
>
> Now that I have a Linux running with networking on a PrPMC800 running as
> NON-MONARCH, I wonder if anybody knows about a program that can start a
> fresh linux kernel from the filesystem. The reason I need this, is that the
That's Magnus Damm's "relf" (Reload ELF file) package.
> In theory it should be simple (given that we have enough RAM):
>
> 1. Load the new image into RAM (userspace)
> 2. Disable interrupts
> 3. Copy image from userspace RAM to contiguous (physical) memory
> 4. Jump to code in the contiguos (physical) memory
>
> Does anybody know of such a program?
Freom the relf README:
A driver to load and start a new elf file from within Linux.
Released under the terms of GPL, see COPYING.
Right now is only mpc8xx supported, patches are welcome.
I've started vxWorks(tm), pSOS(tm) and Linux(tm) with it.
This driver implements two character devices:
/dev/relf c 242 0
/dev/relf_cmdline c 242 1
Usage:
Simply write the elf-file to /dev/relf (cat, dd or whatever).
When /dev/relf is closed the zImage will be started.
Optionally you can first write an argument string to /dev/relf_cmdline.
You can read back the current argument string from /dev/relf_cmdline
at any time. Opening /dev/relf_cmdline for writing will clear the
argument string (use echo -n >/dev/relf_cmdline to remove a previously
written argument string).
x86 Notes:
The driver works with arch/i386/boot/compressed/bvmlinux.out kernel
image, rather than arch/i386/boot/bzImage.
So, arch/i386/boot/compressed/bvmlinux.out is the file that is to be
copied to the /dev/relf node.
Also, there is no support for ramdisk images (yet).
Credits:
Magnus Damm <damm@opensource.se> - maintainer
Marcus Sundberg <marcus@cendio.se> - command line support
DENX <wd@denx.de> - x86 support
Sorry, I don't know a URL for download. Ask Magnus for help; if he
does not reply I can help with a copy, too (but probably not the
latest version).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
When the ax entered the forest, the trees said, "The handle is one of
us!" -- Turkish proverb
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [BENCHMARK]AIM benchmark result for kernel 2.5.55
From: Sowmya Adiga @ 2003-01-09 9:18 UTC (permalink / raw)
To: linux-kernel
Hi,
Here are the AIM benchmark result for kernel 2.5.55.Kernel 2.5.55 when
compared with kernel 2.5.54 showed difference of performance in
following tests:-
Kernel 2.5.55 showed better performance in 1)signal traps/second and
2)Dynamic memory operation/second when compared with 2.5.54.
========================================================================
Test Elapsed Iteration Iteration Operation
Name Time (sec) Count Rate(loops/sec) Rate (ops/sec)
------------------------------------------------------------------------
System Memory Allocations/second
brk_test
[2.5.55] 60.02 3417 56.93102 967827.39
[2.5.54] 60.01 3500 58.32361 991501.42
Signal Traps/second
signal_test
[2.5.55] 60.00 9651 160.85000 160850.00
[2.5.54] 60.00 9282 154.70000 154700.00
Dynamic Memory Operations/second
mem_rtns_1
[2.5.55] 60.01 1838 30.62823 918846.86
[2.5.54] 60.04 1441 24.00067 720019.99
========================================================================
*There is no much significant difference in other test result.
------------------------------------------------------------------------
----
kernel 2.5.55
------------------------------------------------------------------------
----
Machine's name : access1
Machine's configuration : PIII/868MHZ/128MB
Number of seconds to run each test [2 to 1000] : 60
Path to disk files : /tmp
------------------------------------------------------------------------
----
TestTest Elapsed Iteration Iteration Operation
NumberName Time (sec) Count Rate(loops/sec) Rate(ops/sec)
------------------------------------------------------------------------
----
1 add_double 60.02 716 11.92936 214728.42
Thousand Double Precision Additions/second
2 add_float 60.05 1075 17.90175 214820.98
Thousand Single Precision Additions/second
3 add_long 60.03 1768 29.45194 1767116.44
Thousand Long Integer Additions/second
4 add_int 60.01 1768 29.46176 1767705.38
Thousand Integer Additions/second
5 add_short 60.01 4419 73.63773 1767305.45
Thousand Short Integer Additions/second
6 creat-clo 60.00 2149 35.81667 35816.67
File Creations and Closes/second
7 page_test 60.00 8556 142.60000 242420.00
System Allocations & Pages/second
8 brk_test 60.02 3417 56.93102 967827.39
System Memory Allocations/second
9 jmp_test 60.00 318222 5303.70000 5303700.00
Non-local gotos/second
10signal_test 60.00 9651 160.85000 160850.00
Signal Traps/second
11 exec_test 60.02 2084 34.72176 173.61
Program Loads/second
12 fork_test 60.05 1192 19.85012 1985.01
Task Creations/second
13 link_test 60.00 9858 164.30000 10350.90
Link/Unlink Pairs/second
14 disk_rr 60.01 500 8.33194 42659.56
Random Disk Reads (K)/second
15 disk_rw 0.11 397 6.60456 33815.34
Random Disk Writes (K)/second
16 disk_rd 60.02 2833 47.20093 241668.78
Sequential Disk Reads (K)/second
17 disk_wrt 60.05 634 10.55787 54056.29
Sequential Disk Writes (K)/second
18 disk_cp 60.04 500 8.32778 42638.24
Disk Copies (K)/second
19sync_disk_rw 61.18 1 0.01635 41.84
Sync Random Disk Writes (K)/second
20sync_disk_wrt 76.86 2 0.02602 66.61
Sync Sequential Disk Writes (K)/second
21 sync_disk_cp 77.09 2 0.02594 66.42
Sync Disk Copies (K)/second
22 disk_src 60.00 10478 174.63333 13097.50
Directory Searches/second
23 div_double 60.02 1322 22.02599 66077.97
Thousand Double Precision Divides/second
24 div_float 60.01 1322 22.02966 66088.99
Thousand Single Precision Divides/second
25 div_long 60.03 1592 26.52007 23868.07
Thousand Long Integer Divides/second
26 div_int 60.03 1592 26.52007 23868.07
Thousand Integer Divides/second
27 div_short 60.02 1592 26.52449 23872.04
Thousand Short Integer Divides/second
28 fun_cal 60.00 4362 72.70000 37222400.00
Function Calls (no arguments)/second
29 fun_cal1 60.00 10230 170.50000 87296000.00
Function Calls (1 argument)/second
30 fun_cal2 60.00 7971 132.85000 68019200.00
Function Calls (2 arguments)/second
31 fun_cal15 60.02 2455 40.90303 20942352.55
Function Calls (15 arguments)/second
32 sieve 60.51 41 0.67757 3.39
Integer Sieves/second
33 mul_double 60.00 836 13.93333 167200.00
Thousand Double Precision Multiplies/second
34 mul_float 60.03 836 13.92637 167116.44
Thousand Single Precision Multiplies/second
35 mul_long 60.00 75700 1261.66667 302800.00
Thousand Long Integer Multiplies/second
36 mul_int 60.00 76021 1267.01667 304084.00
Thousand Integer Multiplies/second
37 mul_short 60.00 60568 1009.46667 302840.00
Thousand Short Integer Multiplies/second
38 num_rtns_1 60.00 32604 543.40000 54340.00
Numeric Functions/second
39 new_raph 60.00 79918 1331.96667 266393.33
Zeros Found/second
40 trig_rtns 60.00 2165 36.08333 360833.33
Trigonometric Functions/second
41 matrix_rtns 60.00 349604 5826.73333 582673.33
Point Transformations/second
42 array_rtns 60.01 958 15.96401 319.28
Linear Systems Solved/second
43 string_rtns 60.01 851 14.18097 1418.10
String Manipulations/second
44 mem_rtns_1 60.01 1838 30.62823 918846.86
Dynamic Memory Operations/second
45 mem_rtns_2 60.00 131060 2184.33333 218433.33
Block Memory Operations/second
46 sort_rtns_1 60.01 2424 40.39327 403.93
Sort Operations/second
47 misc_rtns_1 60.00 31890 531.50000 5315.00
Auxiliary Loops/second
48 dir_rtns_1 60.00 13086 218.10000 2181000.00
Directory Operations/second
49 shell_rtns_1 60.02 2541 42.33589 42.34
Shell Scripts/second
50 shell_rtns_2 60.01 2541 42.34294 42.34
Shell Scripts/second
51 shell_rtns_3 60.00 2540 42.33333 42.33
Shell Scripts/second
52 series_1 60.00 1463914 24398.56667 2439856.67
Series Evaluations/second
53 shared_memory 60.00 165217 2753.61667 275361.67
Shared Memory Operations/second
54 tcp_test 60.00 16148 269.13333 24222.00
TCP/IP Messages/second
55 udp_test 60.00 48569 809.48333 80948.33
UDP/IP DataGrams/second
56 fifo_test 60.00 88536 1475.60000 147560.00
FIFO Messages/second
57 stream_pipe 60.00 76223 1270.38333 127038.33
Stream Pipe Messages/second
58 dgram_pipe 60.00 75782 1263.03333 126303.33
DataGram Pipe Messages/second
59 pipe_cpy 60.00 254680 4244.66667 424466.67
Pipe Messages/second
60 ram_copy 60.00 1496330 24938.83333 623969610.00
Memory to Memory Copy/second
------------------------------------------------------------------------
----
Regards
Sowmya Adiga
Project Engineer
Wipro Technologies
53/1,Hosur Road,Madivala
Bangalore-560 068,INDIA
Tel: +91-80-5502001 Extn.5086
sowmya.adiga@wipro.com
^ 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.