* Re: need for benchmarking system?
From: Russell Coker @ 2002-12-20 7:37 UTC (permalink / raw)
To: grobe, reiserfs-list
In-Reply-To: <9135.1040347243@www36.gmx.net>
On Fri, 20 Dec 2002 02:20, grobe@gmx.net wrote:
> As we are going to get a quite big new server in january, and as I have
> taken a lot of advantage from the reiserfs development, I wonder if I could
> contribute a bit by making a "reiserfs-large-server-test-day"?
I'm not sure that 2TB is really a large server any more. I know people with
home machines of 1TB, and on the IDE-arrays list about half the regulars are
pushing up against the 2TB block device limit in kernel 2.4 (and a 2TB limit
in 3Ware hardware).
That said, my latest servers are at ~220G. But that's due to not wanting any
external storage and wanting a hot-spare, combined with the limit of 76G for
a SCSI disk.
> The system will be a redundant fibrechannel storage with two dual processor
> systems, about 2 Terabytes raid5. I am going to install SuSE ES8 (I usually
> install on LVM).
I'll be interested to see the results of that. Every time I've checked out
the performance of FC devices in the past I've been very unimpressed by the
results. The best I've seen from FC is 60MB/s sustained for a single process
(which isn't THAT much better than a single new IDE hard drive).
> If the reiserfs-team thinks this could be useful, please tell me the
> configuration you need (e.g. kernel 2.4.xx, 2.5.xx, reiserfs 3.xx or 4?)
> and how we should do this (benchmark scripts etc), I will try to get the
> specs of the system and see how to put this into the schedule.
I suggest benchmarking 2.4.x vs 2.5.x. 2.5.x has many changes that should
improve performance. Also see if you can show the benefits of the
pre-emptable kernel support in recent 2.5.x.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
^ permalink raw reply
* Re: How to load these modules?
From: Vincent Lim @ 2002-12-20 7:32 UTC (permalink / raw)
To: bobo; +Cc: netfilter@lists.netfilter.org, bobowd@sohu.com
In-Reply-To: <20021220032315.3B1701D110BCC@sm181.163.com>
bobo wrote:
>
> Hello all:
>
> While I am studying iptables,I read such contents from a tutorial as bellow:
>
> "the rc.firewall.txt neede the following options to be compiled to kernel or as modules..
>
> .CONFIG_PACKET
> .CONFIG_NETFILTER
> .CONFIG_IP_NF_CONNTRACK
> ..........
>
> I find some moudles of REDHAT 7.2 in /lib/modules/2.4.7-10/kernel/net/ipv4/netfilter,
> but the modules'name are not the same as the above. There are about 20 modules in the directory.
>
> Why?
>
> How could I do? How could I get these modules?
I did a check on /usr/src/linux/net/ipv4/netfilter/Makefile and found
the following line:
obj-$(CONFIG_IP_NF_CONNTRACK) += ip_conntrack.o
This (I think) means that if "CONFIG...." is selected, then the module
that corresponds to this selection is ip_conntrack.o
then in /usr/src/linux/net/Makefile
subdir-$(CONFIG_NETFILTER) += ipv4/netfilter
I think this meant that all modules in ipv4/netfilter would be needed
for that selection.
--
Vincent Lim
Software Engineer
NESTAC Solution Sdn Bhd
vincent.lim@nestac.com | +(6012) 659-6609
^ permalink raw reply
* Re: [ISN] Music file flaws could threaten traders
From: Russell Coker @ 2002-12-20 7:23 UTC (permalink / raw)
To: Brian May; +Cc: selinux
In-Reply-To: <20021220001646.GD15409@snoopy.apana.org.au>
On Fri, 20 Dec 2002 01:16, Brian May wrote:
> I think it should be possible to write a program that checks to source
> file, makes sure it is valid and doesn't contain any errors or other
> potentially dangerous stuff (eg. a multimedia tag with too much data, as
> per article), and then relabels it with a file label that allows the
> user to freely use that file.
If that is the approach that you want then why not just audit the source code
to all the programs that use such files?
Surely auditing source code to applications is easier than writing
virus-scanners for every type of file that MIGHT break some buggy program
somewhere and cause a security hole.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: reiserfs and TUX2 - 2.4.18 or 2.4.19?
From: Dirk Mueller @ 2002-12-20 7:11 UTC (permalink / raw)
To: reiserfs-list
In-Reply-To: <20021220091717.A10948@namesys.com>
On Fre, 20 Dez 2002, Oleg Drokin wrote:
> If you'd have canilla 2.4.18, you'd need
> 2.4.18.pending and 2.4.19.pending
> With RedHat some of these patches might be already included, so
> you probably need to try and see it for yourself which ones are missing.
Wouldn't it be better to push the changes into the vanilla kernel to save
everyone from this patch nightmare?
--
Dirk (received 116 mails today)
^ permalink raw reply
* What is the difference between modprobe and insmod?
From: bobo @ 2002-12-20 7:11 UTC (permalink / raw)
To: netfilter, netfilter; +Cc: bobowd, bobowd
While writing IPtables scripts,there are two command: modprobe and insmod.
In some example,some use : modprobe ip_tables,but others use: insmod ip_tables.
Why? Is there difference between them?
Thanks
^ permalink raw reply
* Re: IBM graphics / VNC
From: Bart Oldeman @ 2002-12-20 7:03 UTC (permalink / raw)
To: Stephen Lee; +Cc: dosemu
In-Reply-To: <1040364305.7864.144.camel@ralph.plexio.private>
On 19 Dec 2002, Stephen Lee wrote:
> I've now got Foxpro running on Dosemu 1.1.4 in an xdosemu session.
> Unlike the previous version used (1.1.3.7), xdosemu in a VNC terminal
> under 1.1.4 does not show the IBM block graphics correctly. I have
> included $_term_char_set = "ibm" and the graphics characters display
> correctly under xdosemu but not xdosemu displayed on VNC. Are there new
> settings in ~/.dosemurc or in VNC itself I need to change?
$_term_char_set is mostly meant for terminals ("dosemu"); it does not
affect the visibility of block characters in xdosemu (ie, "DOS in a BOX").
Do you have the vga font available under VNC, ie., can you use
xterm -font vga
?
If you did "install_systemwide" instead of "make install" your fonts
are probably not setup correctly.
Maybe this could do the trick for the setup you described yesterday:
xset +fp /usr/local/dosemu/Xfonts
Bart
^ permalink raw reply
* Re: Minicom fails
From: Peter @ 2002-12-20 7:00 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <200212190804.04757.sotl155360@earthlink.net>
Peter said:
> After I run a RH7.3 upgrade I can't access anymore minicom as a user.
> I get the following message: ]$ minicom Device /dev/ttyS0 lock failed:
> Operation not permitted.
Thanks Frank!
The first thing I did was reading the man pages after the opening failure. I
got nothing out of it.
What I did now was setting the group of /var/lock to user and I can open
minicom again.
Was this the right way to do it?
Regards
--
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [ISN] Music file flaws could threaten traders
From: Russell Coker @ 2002-12-20 6:45 UTC (permalink / raw)
To: Paul Krumviede, selinux
In-Reply-To: <18223383.1040308887@localhost>
On Thu, 19 Dec 2002 23:41, Paul Krumviede wrote:
> <russell@coker.com.au> wrote:
> > This type of thing could affect Linux in the same way as it affects
> > Windows.
>
> i'm not so sure. the bugtraq posting about the windows XP bug
> indicated that it could be exploited even without downloading
> a file to the user's computer. if using explorer, the file had to be
> on the local machine, but didn't need to be "played" to allow
> an exploit. i don't think that either case is relevant to selinux
> (but would like to know if i'm wrong).
KDE supports creating "thumbnail" pictures to represent different types of
files on the desktop and could also be vulnerable to "list a directory and
have some code executed" type bugs.
The problem with KDE is that everything seems to be run from one process that
just forks off copies of itself and mmap's executables (thus avoiding
automatic domain transitions).
I think that this is relevant to people who are writing SE Linux policy. It
does not affect Linux, yet, AFAIK... But sometimes it's best to lock down
things that look dangerous rather than waiting for proof that they are
dangerous (you never get absolute proof that anything is safe).
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* UDP packet forwarding
From: Colin @ 2002-12-20 6:32 UTC (permalink / raw)
To: netfilter
Hi,
I am running Linux Kernel 2.4.20 and iptables 1.2.7a, with a Linux server
doing primarly SNAT work for masquerading. I don't seem to be able to
forward UDP packets with iptables. I am able to forward TCP packets through
the firewall, such as identd requests, like so:
iptables -t nat -A PREROUTING -j DNAT -p tcp --destination-port 113
--to-destination xxx.xxx.xxx.xxx
What I'm doing here is forwarding a packet from an external system to a
machine on an internal network, so that it can answer an identd request.
The above works fine for that. However, it doesn't seem to work for UDP
packets. Even when I forward all data from the source IP address to an
internal host (as opposed to limiting it by --destination-port), the UDP
data refuses to be forwarded, and my linux machine sends out ICMP port
unreachable errors to the external machine. No data is sent across the
local ethernet at all.
Is there any reason for this? Anything I'm doing wrong or can change to
correct it? Any help would be greatly appreciated.
^ permalink raw reply
* pr_debug() and #define DEBUG usage
From: Randy.Dunlap @ 2002-12-20 6:38 UTC (permalink / raw)
To: linux-kernel
Hi,
Some drivers, filesystems, subsystems, and libraries #define or use
DEBUG locally in their source files. This can conflict with DEBUG
in include/linux/kernel.h, specifically the "pr_debug" macro, which
has over 300 uses (invocations, calls) in 2.5.52 spread throughout
drivers, libraries, and filesystems.
Question:
How should DEBUG be enabled for use by include/linux/kernel.h ?
a. change CFLAGS_KERNEL in linux/Makefile to include "-DDEBUG"
b. #define DEBUG in include/linux/kernel.h
c. #define DEBUG in each file where someone wants to enable it
d. others?
"DEBUG" seems heavily used (or overused, misused, abused) and too
generic.
And in one place, it keeps a kernel build from completing when
DEBUG is defined. In lib/inflate.c, line 999:
fprintf(stderr, "<%u> ", h);
gcc just doesn't like this line.
--
~Randy
^ permalink raw reply
* Re: reiserfs and TUX2 - 2.4.18 or 2.4.19?
From: Dieter Nützel @ 2002-12-20 6:25 UTC (permalink / raw)
To: Oleg Drokin, darren; +Cc: reiserfs-list
In-Reply-To: <20021219185805.A6905@namesys.com>
Am Donnerstag, 19. Dezember 2002 16:58 schrieb Oleg Drokin:
> Hello!
>
> On Thu, Dec 19, 2002 at 11:53:49PM +0800, darren wrote:
> > I want to run TUX2 to serve files off my ReiserFS partition.
> > But I cannot seem to get TUX2 on kernel 2.4.19, which I would like to
> > run my reiserfs partition on.
>
> We cannot tell you anything about Tux2 because we do not know anything
> about it ;)
I think Darren should try 2.4.20aa1, Andrea Arcangeli's (SuSE) -AA VM kernel.
It has TUX (the web server; TUX2 is a new file system with phase tree under
construction) on board.
cat /usr/src/linux/net/tux/Config.in
tristate ' Threaded linUX application protocol accelerator layer (TUX)'
CONFIG_TUX
if [ "$CONFIG_TUX" = "y" -o "$CONFIG_TUX" = "m" ]; then
bool ' External CGI module' CONFIG_TUX_EXTCGI
bool ' extended TUX logging format' CONFIG_TUX_EXTENDED_LOG
bool ' debug TUX' CONFIG_TUX_DEBUG
fi
Regards,
Dieter
^ permalink raw reply
* Re: Re: reiserfs and TUX2 - 2.4.18 or 2.4.19?
From: Oleg Drokin @ 2002-12-20 6:17 UTC (permalink / raw)
To: darren; +Cc: reiserfs-list
In-Reply-To: <1040346481.bb5f0760teodarren@myrealbox.com>
Hello!
Usually RedHat kernels version are in very little relation with
vanilla kernel with same version.
If you'd have canilla 2.4.18, you'd need
2.4.18.pending and 2.4.19.pending
With RedHat some of these patches might be already included, so
you probably need to try and see it for yourself which ones are missing.
Bye,
Oleg
On Fri, Dec 20, 2002 at 01:08:01AM +0000, darren wrote:
> Hi!
>
> Thanx for responding to my ques.
>
> So, to make my reiserfs on my RedHat7.3 kernel the same one as the one in Kernel 2.4.20, all i have to do is to patch:
>
> 2.4.18-pre1.pending
> 2.4.18-pre2.pending
> .
> .
> 2.4.18-rc1.pending
> 2.4.18.pending
> 2.4.19
> 2.4.20
>
> and so on??
>
> -----Original Message-----
> From: Oleg Drokin <green@namesys.com>
> To: darren <teodarren@myrealbox.com>
> Date: Thu, 19 Dec 2002 18:58:05 +0300
> Subject: Re: reiserfs and TUX2 - 2.4.18 or 2.4.19?
>
> Hello!
>
> On Thu, Dec 19, 2002 at 11:53:49PM +0800, darren wrote:
>
> > I want to run TUX2 to serve files off my ReiserFS partition.
> > But I cannot seem to get TUX2 on kernel 2.4.19, which I would like to
> > run my reiserfs partition on.
>
> We cannot tell you anything about Tux2 because we do not know anything
> about it ;)
>
> > Should I just stick to 2.4.18 and somehow patch the reiserfs there??
>
> If you plan to run not current 2.4 kernels, you might want to
> get patches from ftp://ftp.namesys.com/pub/reiserfs-for-2.4/<version>.pending
>
> Where <version> next kernel version. (repeat that until you reach latest
> kernel).
>
> But actually 2.4.18 is pretty stable and you may not want to patch it if you
> want.
>
> Bye,
> Oleg
>
>
>
^ permalink raw reply
* 2.4.21-pre2 assertion errer in af_inet.c/tcp.c
From: Ralf Hildebrandt @ 2002-12-20 6:14 UTC (permalink / raw)
To: linux-kernel
>From my syslog this night:
Dec 20 05:46:59 hummus kernel: KERNEL: assertion (newsk->state != TCP_SYN_RECV) failed at tcp.c(2229)
Dec 20 05:46:59 hummus kernel: KERNEL: assertion ((1<<sk2->state)&(TCPF_ESTABLISHED|TCPF_CLOSE_WAIT|TCPF_CLOSE)) failed at af_inet.c(689)
Dec 20 05:46:59 hummus kernel: KERNEL: assertion (newsk->state != TCP_SYN_RECV) failed at tcp.c(2229)
Dec 20 05:46:59 hummus kernel: KERNEL: assertion ((1<<sk2->state)&(TCPF_ESTABLISHED|TCPF_CLOSE_WAIT|TCPF_CLOSE)) failed at af_inet.c(689)
Dec 20 05:56:24 hummus kernel: KERNEL: assertion (newsk->state != TCP_SYN_RECV) failed at tcp.c(2229)
Dec 20 05:56:24 hummus kernel: KERNEL: assertion ((1<<sk2->state)&(TCPF_ESTABLISHED|TCPF_CLOSE_WAIT|TCPF_CLOSE)) failed at af_inet.c(689)
Dec 20 05:56:24 hummus kernel: KERNEL: assertion (newsk->state != TCP_SYN_RECV) failed at tcp.c(2229)
Dec 20 05:56:24 hummus kernel: KERNEL: assertion ((1<<sk2->state)&(TCPF_ESTABLISHED|TCPF_CLOSE_WAIT|TCPF_CLOSE)) failed at af_inet.c(689)
Linux hummus 2.4.21-pre2 #1 Thu Dec 19 00:16:41 CET 2002 i686 unknown unknown GNU/Linux
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Now that we know Microsoft's plan for world domination isn't superman
suppost to come out and kick some ass?
^ permalink raw reply
* IBM graphics / VNC
From: Stephen Lee @ 2002-12-20 6:05 UTC (permalink / raw)
To: dosemu
I've now got Foxpro running on Dosemu 1.1.4 in an xdosemu session.
Unlike the previous version used (1.1.3.7), xdosemu in a VNC terminal
under 1.1.4 does not show the IBM block graphics correctly. I have
included $_term_char_set = "ibm" and the graphics characters display
correctly under xdosemu but not xdosemu displayed on VNC. Are there new
settings in ~/.dosemurc or in VNC itself I need to change?
Thanks,
Stephen
^ permalink raw reply
* Re: PATCH 2.5.x disable BAR when sizing
From: Linus Torvalds @ 2002-12-20 6:05 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <15874.32773.829438.109509@napali.hpl.hp.com>
In article <15874.32773.829438.109509@napali.hpl.hp.com>,
David Mosberger <davidm@napali.hpl.hp.com> wrote:
> Alan> And yes this happens on some PC class systems.
>
>And yet it's OK to remap that memory? That seems unlikely.
Alan is right, however "unlikely" you think it is.
Turning off stuff in the config register not only turns off the standard
BAR's, it can turn off _everything_. Including stuff that isn't even
covered by the standard BARs that are beng probed.
It's like shutting off the power for the whole house because you want to
change a lightbulb. Sure, it's safer for the lightbulb, but if you
don't know what -else- needs power in the house, it sure as hell isn't
a good idea. Maybe you just trashed your wifes work because she happened
to be in front of the computer when you turned off the lights.
Linus
^ permalink raw reply
* Re: pcibios functions left in m68knommu port
From: Greg Ungerer @ 2002-12-20 6:02 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
In-Reply-To: <20021219174236.GE6380@kroah.com>
Hi Greg,
Greg KH wrote:
> Great, here's a patch against 2.5.52 that removes the unneeded
> functions. I think you might be able to remove a few of the static
> variables in this file now too, but I don't want to break anything, as I
> don't have a machine to test this on.
>
> Hm, I think I have a uCsimm around here somewhere...
You could on that, but it doesn't have a PCI bus, so you
couldn't really test with that. The only 2 boards I know
of that this supports are the Motorola M5407C3 and the
Moreton Bay eLIA.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: gerg@snapgear.com
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com
^ permalink raw reply
* Re: PATCH 2.5.x disable BAR when sizing
From: Linus Torvalds @ 2002-12-20 5:57 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021219213712.0518B12CB2@debian.cup.hp.com>
In article <20021219213712.0518B12CB2@debian.cup.hp.com>,
Grant Grundler <grundler@cup.hp.com> wrote:
>
>In April 2002, turukawa@icc.melco.co.jp sent a 2.4.x patch to disable
>BARs while the BARs were being sized. I've "forward ported" this patch
>to 2.5.x (appended). turukawa's excellent problem description and
>original posting are here:
> https://lists.linuxia64.org/archives//linux-ia64/2002-April/003302.html
>
>David Mosberger agrees this is an "obvious fix".
It is NOT an "obvious fix".
It breaks stuff horribly. When you turn off the MEM bit on the
northbridge, there are northbridges that will stop forwarding RAM<->PCI.
>We've been using this in the ia64 2.4 code stream since about August.
And it's CRAP.
DO NOT DO THIS. It locks up some machines at bootup. Hard. Total bus
lockup if you have legacy USB enabled (or anything else that does DMA,
for that matter) at the same time as probing the northbridge with this.
Trust me. If you have some new silly ia64-specific bug, the fix is
_not_ to break real and existing hardware out there.
We've had this "obviously correct" patch floating around several times,
and it even made it into the kernel at least once. It was reverted
because it is WRONG.
Linus
^ permalink raw reply
* Re: Apache virtualhost not working behind firewall.
From: Joel Newkirk @ 2002-12-20 5:33 UTC (permalink / raw)
To: Chip Upsal, netfilter
In-Reply-To: <3E0274C5.7080000@CyberWolf.com>
On Thursday 19 December 2002 08:39 pm, Chip Upsal wrote:
> I have a windows 2000 server running apache 2.0.43 with virtual hosts
> behind an iptables firewall doing NAT.
> I am running iptables v1.2.5 on a redhat 7.3 server.
> # PWWEB
> #
> $IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $PWWEB_IP
> --dport 80 \
> -j DNAT --to-destination $DMZ_PWWEB_IP
>
> $IPTABLES -t nat -A PREROUTING -p ICMP -i $INET_IFACE -d $PWWEB_IP \
> -j DNAT --to-destination $DMZ_PWWEB_IP
> The problem....
> When the server is connected directly to the internet all works well.
> However, when it is behind the firewall the virtualhost are not
> working (you can only access the default web site.
>
> Furthermore i am getting the following errors when starting iptables;
>
> [root@iptables init.d]# ./iptables restart
> Flushing all current rules and user defined chains: [ OK ]
> Clearing all current rules and user defined chains: [ OK ]
> Applying iptables firewall rules: [ OK ]
> iptables v1.2.5: Unknown arg `--to-destination'
> Try `iptables -h' or 'iptables --help' for more information.
My money is on a failure to load the nat module. Try "insmod iptable_nat"
from a root console, then restart. If that's it, just put it somewhere
at the top of your script.
j
^ permalink raw reply
* RE: [LARTC] Using HTB as an ISP "provisioning engine"
From: S Mohan @ 2002-12-20 5:24 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104033114505084@msgid-missing>
You can go one step further. If you are charging differential rates to
customers, the you can fine tune as per scenario discussed under:
Let us say customer A has paid more for bandwidth than customer B, then
customer should have a greater lien on spare bandwidth than customer B. This
is achieved by prio in qdisc. Let us give customer A prio 1 and B prio 2. If
customer A and B have used their rattes and 400Kb spare bandwidth is
available, then the full 400kb goes to A. If customer A is at 800kb and B at
250Kb, then 300Kb (1.1 ceiling-0.8 actual) goes to A so that he hits ceiling
and the balance 100kb goes to B.
Stef is this scenario correct. In case I'm wrong, please let me know.
Mohan
-----Original Message-----
From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]On
Behalf Of Stef Coene
Sent: 20 December 2002 02:40
To: Brian Capouch; lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Using HTB as an ISP "provisioning engine"
On Thursday 19 December 2002 21:51, Brian Capouch wrote:
> I am new to shaping but not to routing; forgive me if this request is
> inappropriate for this list.
>
> I am a very small ISP and would like to use HTB to enforce contractual
> bandwidth limits on my customers. I am trying to think through one
> aspect of this that is vexing me. I'm sure it's no great secret that
> many ISPs oversell their bandwidth, and in our case we have a
> combination of accounts that total approximately 2.2Mbs on our feed,
> which is 1.2Mbs. (Concentrating right now on our download stream)
>
> How could something like this be accomodated? The documentation says
> that the total bandwidth allocations of a set of subclasses should total
> that assigned to the class.
>
> But my understanding is that if I bump up the bandwidth on the primary
> class to a value greater than my actual bandwidth, then I'm going to be
> filling up queues at the upstream ISP and negatively affecting my
> performance.
>
> I'm sure there is something I'm missing, but I've discussed this with a
> couple of fellow network engineers and neither was able to posit how
> such thing might work, although they both said they were sure that it is
> a common scenario.
You can create a root class with rate = ceil = 1.2 Mbps. Create a class for
each customer with ceil = selled bandwidth and the sum of the rates=1.2Mbps.
Example :
You selled 1.1 Mbps to customer1 and 0.37 (=2.2Mbps/6) to 3 other customers.
So you have a total bandwidth of 2.2Mbps. But you have only 1.2 Mbps
available.
class rate = ceil = 1.2 Mbps
class1 rate = 0.6, ceil = 1.1Mbps
class2 rate = 0.2, ceil = 0.37Mbps
class3 rate = 0.2, ceil = 0.37Mbps
class4 rate = 0.2, ceil = 0.37Mbps
The bandwidth you selled to the customers is the ceil. They never can use
more then the ceil. If one customer is using no bandwidth, the remaining
bandwidth is given to the other customers.
If all customers are using all bandwidth, each customer is "punished" in the
same way.
You can also give the customers a possibility to use as much bandwidth as
available. To do so, give each class ceil = 1.2Mbps, but that bandwidth is
not guaranteed. In this case, the rate is the minimum bandwidth they can
get. So for a SLA, you can say to the customer : "You have a minimum
bandwidth of 0.6Mbps and a maximum bandwidth of 1.2Mbps."
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* read blocking for really long time on /dev/scd?
From: Gregory Stark @ 2002-12-20 5:30 UTC (permalink / raw)
To: linux-kernel
I'm having a problem with ogle glitching. It seems what's happening is it
isn't able to read data from the dvd fast enough to feed the decoder.
Sometimes read system calls block for seconds at a time. That doesn't seem
normal.
In the following straces fd 3 is /dev/scd1. I'm using an ide dvd-rom with
ide-scsi. DMA is enabled on the ide device.
Most read calls return in about 26us. But a significant chunk seem to take up
to 150ms to return. Those slow reads don't cause ogle any problem but they
seem to indicate a problem already. But every now and then a read will hang
for a really long time, I've seen as much as 10s.
Here's an example that was correlated with a glitch in video playback:
read(3, "\0\0\1\272D\0-C6E\1\211\303\370\0\0\1\340\7\354\221\300"..., 288768) = 288768 <2.747268>
My question is I guess: Do other people observe the same issue? Is it
expected? What is the path from the read syscall through the ide-scsi layer to
the ide driver that the read syscall is waiting on? How do I go about tracking
down where in the scd or atapi ide driver this hang is happening?
Background info:
This is a custom build from pristine source from linux.kernel.org:
bash-2.05b# uname -a
Linux stark.dyndns.tv 2.4.19 #6 Tue Sep 10 22:08:51 EDT 2002 i686 unknown unknown GNU/Linux
bash-2.05b# hdparm /dev/hdd
/dev/hdd:
HDIO_GET_MULTCOUNT failed: Input/output error
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
BLKRAGET failed: Input/output error
HDIO_GETGEO failed: Invalid argument
bash-2.05b# hdparm -i /dev/hdd
/dev/hdd:
Model=LG DVD-ROM DRD-8160B, FwRev=1.01, SerialNo=
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:227,w/IORDY:120}, tDMA={min:120,rec:150}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
Here are the modules loaded, however I have tested this problem with a fresh
reboot with hardly any of these modules loaded and the problem definitely
still occurs. I had openafs, pcmcia, parport, mga, agpgar, pppoe all unloaded.
bash-2.05b# lsmod
Module Size Used by Tainted: PF
sr_mod 12304 4 (autoclean)
openafs 403712 2
pcmcia_core 39872 0
serial 50884 0 (autoclean)
isa-pnp 28708 0 (autoclean) [serial]
parport_pc 25288 1 (autoclean)
lp 6432 0 (autoclean)
parport 25024 1 (autoclean) [parport_pc lp]
mga_vid 7800 0
mga 98104 3
agpgart 16552 3
ide-scsi 7632 2
scsi_mod 51356 2 [sr_mod ide-scsi]
pppoe 6924 2
pppox 1128 1 [pppoe]
ppp_generic 16416 3 [pppoe pppox]
slhc 4480 0 [ppp_generic]
ne2k-pci 4800 1
8390 5968 0 [ne2k-pci]
rtc 5916 0 (autoclean)
--
greg
^ permalink raw reply
* [PATCH] [v850] Reduce redundancy in v850 linker scripts
From: Miles Bader @ 2002-12-20 5:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
This patch moves most of the duplicated text in the various v850
platform-specific linker scripts (each of which was previously completely
standalone) into cpp macros in vmlinux.lds.S, which are then used by the
platform linker scripts as appropriate. This should make the scripts a lot
easier to maintain.
Also, a number of linker-script bugs are fixed.
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/vmlinux.lds.S arch/v850/vmlinux.lds.S
--- ../orig/linux-2.5.52-uc0/arch/v850/vmlinux.lds.S 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/vmlinux.lds.S 2002-12-19 19:54:31.000000000 +0900
@@ -1,5 +1,201 @@
+/*
+ * arch/v850/vmlinux.lds.S -- kernel linker script for v850 platforms
+ *
+ * Copyright (C) 2002 NEC Electronics Corporation
+ * Copyright (C) 2002 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>
+ */
+
#include <linux/config.h>
+
+/* The following macros contain the usual definitions for various data areas.
+ The prefix `RAMK_' is used to indicate macros suitable for kernels loaded
+ into RAM, and similarly `ROMK_' for ROM-resident kernels. Note that all
+ symbols are prefixed with an extra `_' for compatibility with the v850
+ toolchain. */
+
+
+/* Interrupt vectors. */
+#define INTV_CONTENTS \
+ __intv_start = . ; \
+ *(.intv.reset) /* Reset vector */ \
+ *(.intv.common) /* Vectors common to all v850e proc */\
+ *(.intv.mach) /* Machine-specific int. vectors. */ \
+ __intv_end = . ;
+
+/* Kernel text segment, and some constant data areas. */
+#define TEXT_CONTENTS \
+ __stext = . ; \
+ *(.text) \
+ *(.exit.text) /* 2.5 convention */ \
+ *(.text.exit) /* 2.4 convention */ \
+ *(.text.lock) \
+ *(.exitcall.exit) \
+ __real_etext = . ; /* There may be data after here. */ \
+ *(.rodata) \
+ . = ALIGN (0x4) ; \
+ *(.kstrtab) \
+ . = ALIGN (4) ; \
+ *(.call_table_data) \
+ *(.call_table_text) \
+ . = ALIGN (16) ; /* Exception table. */ \
+ ___start___ex_table = . ; \
+ *(__ex_table) \
+ ___stop___ex_table = . ; \
+ ___start___ksymtab = . ;/* Kernel symbol table. */ \
+ *(__ksymtab) \
+ ___stop___ksymtab = . ; \
+ . = ALIGN (4) ; \
+ __etext = . ;
+
+/* Kernel data segment. */
+#define DATA_CONTENTS \
+ __sdata = . ; \
+ *(.data) \
+ *(.exit.data) /* 2.5 convention */ \
+ *(.data.exit) /* 2.4 convention */ \
+ . = ALIGN (16) ; \
+ *(.data.cacheline_aligned) \
+ . = ALIGN (0x2000) ; \
+ *(.data.init_task) \
+ . = ALIGN (0x2000) ; \
+ __edata = . ;
+
+/* Kernel BSS segment. */
+#define BSS_CONTENTS \
+ __sbss = . ; \
+ *(.bss) \
+ *(COMMON) \
+ . = ALIGN (4) ; \
+ __init_stack_end = . ; \
+ __ebss = . ;
+
+/* `initcall' tables. */
+#define INITCALL_CONTENTS \
+ . = ALIGN (16) ; \
+ ___setup_start = . ; \
+ *(.init.setup) /* 2.5 convention */ \
+ *(.setup.init) /* 2.4 convention */ \
+ ___setup_end = . ; \
+ ___start___param = . ; \
+ *(__param) \
+ ___stop___param = . ; \
+ ___initcall_start = . ; \
+ *(.initcall.init) \
+ *(.initcall1.init) \
+ *(.initcall2.init) \
+ *(.initcall3.init) \
+ *(.initcall4.init) \
+ *(.initcall5.init) \
+ *(.initcall6.init) \
+ *(.initcall7.init) \
+ . = ALIGN (4) ; \
+ ___initcall_end = . ;
+
+/* Contents of `init' section for a kernel that's loaded into RAM. */
+#define RAMK_INIT_CONTENTS \
+ RAMK_INIT_CONTENTS_NO_END \
+ __init_end = . ;
+/* Same as RAMK_INIT_CONTENTS, but doesn't define the `__init_end' symbol. */
+#define RAMK_INIT_CONTENTS_NO_END \
+ . = ALIGN (4096) ; \
+ __init_start = . ; \
+ *(.init.text) /* 2.5 convention */ \
+ *(.init.data) \
+ *(.text.init) /* 2.4 convention */ \
+ *(.data.init) \
+ INITCALL_CONTENTS \
+ INITRAMFS_CONTENTS
+
+/* The contents of `init' section for a ROM-resident kernel which
+ should go into RAM. */
+#define ROMK_INIT_RAM_CONTENTS \
+ . = ALIGN (4096) ; \
+ __init_start = . ; \
+ *(.init.data) /* 2.5 convention */ \
+ *(.data.init) /* 2.4 convention */ \
+ __init_end = . ; \
+ . = ALIGN (4096) ;
+
+/* The contents of `init' section for a ROM-resident kernel which
+ should go into ROM. */
+#define ROMK_INIT_ROM_CONTENTS \
+ *(.init.text) /* 2.5 convention */ \
+ *(.text.init) /* 2.4 convention */ \
+ INITCALL_CONTENTS \
+ INITRAMFS_CONTENTS
+
+/* A root filesystem image, for kernels with an embedded root filesystem. */
+#define ROOT_FS_CONTENTS \
+ __root_fs_image_start = . ; \
+ *(.root) \
+ __root_fs_image_end = . ;
+/* The initramfs archive. */
+#define INITRAMFS_CONTENTS \
+ . = ALIGN (4) ; \
+ ___initramfs_start = . ; \
+ *(.init.ramfs) \
+ ___initramfs_end = . ;
+/* Where the initial bootmap (bitmap for the boot-time memory allocator)
+ should be place. */
+#define BOOTMAP_CONTENTS \
+ . = ALIGN (4096) ; \
+ __bootmap = . ; \
+ . = . + 4096 ; /* enough for 128MB. */
+
+/* The contents of a `typical' kram area for a kernel in RAM. */
+#define RAMK_KRAM_CONTENTS \
+ __kram_start = . ; \
+ TEXT_CONTENTS \
+ DATA_CONTENTS \
+ BSS_CONTENTS \
+ RAMK_INIT_CONTENTS \
+ __kram_end = . ; \
+ BOOTMAP_CONTENTS
+
+
+/* Define output sections normally used for a ROM-resident kernel.
+ ROM and RAM should be appropriate memory areas to use for kernel
+ ROM and RAM data. This assumes that ROM starts at 0 (and thus can
+ hold the interrupt vectors). */
+#define ROMK_SECTIONS(ROM, RAM) \
+ .rom : { \
+ INTV_CONTENTS \
+ TEXT_CONTENTS \
+ ROMK_INIT_ROM_CONTENTS \
+ ROOT_FS_CONTENTS \
+ } > ROM \
+ \
+ __rom_copy_src_start = . ; \
+ \
+ .data : { \
+ __kram_start = . ; \
+ __rom_copy_dst_start = . ; \
+ DATA_CONTENTS \
+ ROMK_INIT_RAM_CONTENTS \
+ __rom_copy_dst_end = . ; \
+ } > RAM AT> ROM \
+ \
+ .bss ALIGN (4) : { \
+ BSS_CONTENTS \
+ __kram_end = . ; \
+ BOOTMAP_CONTENTS \
+ } > RAM
+
+
+/* The 32-bit variable `jiffies' is just the lower 32-bits of `jiffies_64'. */
+_jiffies = _jiffies_64 ;
+
+
+/* Include an appropriate platform-dependent linker-script (which
+ usually should use the above macros to do most of the work). */
+
#ifdef CONFIG_V850E_SIM
# include "sim.ld"
#endif
@@ -21,15 +217,17 @@
#endif
#ifdef CONFIG_V850E_AS85EP1
-# include "as85ep1.ld"
+# ifdef CONFIG_ROM_KERNEL
+# include "as85ep1-rom.ld"
+# else
+# include "as85ep1.ld"
+# endif
#endif
#ifdef CONFIG_RTE_CB_MA1
# ifdef CONFIG_ROM_KERNEL
# include "rte_ma1_cb-rom.ld"
-# elif CONFIG_RTE_CB_MA1_KSRAM
-# include "rte_ma1_cb-ksram.ld"
-# else /* !CONFIG_ROM_KERNEL && !CONFIG_RTE_CB_MA1_KSRAM */
+# else
# include "rte_ma1_cb.ld"
-# endif /* CONFIG_ROM_KERNEL */
-#endif /* CONFIG_RTE_CB_MA1 */
+# endif
+#endif
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/anna-rom.ld arch/v850/anna-rom.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/anna-rom.ld 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/anna-rom.ld 2002-12-18 18:08:31.000000000 +0900
@@ -1,132 +1,16 @@
/* Linker script for the Midas labs Anna V850E2 evaluation board
(CONFIG_V850E2_ANNA), with kernel in ROM (CONFIG_ROM_KERNEL). */
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
MEMORY {
- /* 8MB of flash ROM. */
- ROM : ORIGIN = 0, LENGTH = 0x00800000
+ /* 8MB of flash ROM. */
+ ROM : ORIGIN = 0, LENGTH = 0x00800000
- /* 1MB of static RAM. This memory is mirrored 64 times. */
- SRAM : ORIGIN = 0x04000000, LENGTH = 0x00100000
- /* 64MB of DRAM. */
- SDRAM : ORIGIN = 0x08000000, LENGTH = 0x04000000
+ /* 1MB of static RAM. This memory is mirrored 64 times. */
+ SRAM : ORIGIN = 0x04000000, LENGTH = 0x00100000
+ /* 64MB of DRAM. */
+ SDRAM : ORIGIN = 0x08000000, LENGTH = 0x04000000
}
SECTIONS {
- .intv : {
- __intv_start = . ;
- *(.intv.reset) /* Reset vector */
- *(.intv.common) /* Vectors common to all v850e proc. */
- *(.intv.mach) /* Machine-specific int. vectors. */
- __intv_end = . ;
- } > ROM
-
- .text ALIGN (0x10) : {
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
-
- . = ALIGN (0x4) ;
- *(.kstrtab)
-
- . = ALIGN (4) ;
- *(.call_table_data)
- *(.call_table_text)
-
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
- } > ROM
-
- .init_text ALIGN (4096) : {
- *(.init.text) /* 2.5 convention */
- *(.text.init) /* 2.4 convention */
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
- } > ROM
-
- /* Device contents for the root filesystem. */
- .root ALIGN (4096) : {
- __root_fs_image_start = . ;
- *(.root)
- __root_fs_image_end = . ;
-
- . = ALIGN (4) ;
- ___initramfs_start = . ;
- *(.init.ramfs)
- ___initramfs_end = . ;
- } > ROM
-
- __rom_copy_src_start = . ;
-
- .data : {
- __kram_start = . ;
- __rom_copy_dst_start = . ;
-
- __sdata = . ;
- ___data_start = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > SRAM AT> ROM
-
- .init_data ALIGN (4096) : {
- __init_start = . ;
- *(.init.data) /* 2.5 convention */
- *(.data.init) /* 2.4 convention */
- __init_end = . ;
- __rom_copy_dst_end = . ;
- } > SRAM AT> ROM
-
- .bss ALIGN (4096) : {
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
-
- __kram_end = . ;
- } > SRAM
-
- .bootmap ALIGN (4096) : {
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
- } > SRAM
+ ROMK_SECTIONS(ROM, SRAM)
}
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/anna.ld arch/v850/anna.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/anna.ld 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/anna.ld 2002-12-19 14:21:49.000000000 +0900
@@ -1,128 +1,20 @@
/* Linker script for the Midas labs Anna V850E2 evaluation board
(CONFIG_V850E2_ANNA). */
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
MEMORY {
- /* 256KB of internal memory (followed by one mirror). */
- iMEM0 : ORIGIN = 0, LENGTH = 0x00040000
- /* 256KB of internal memory (followed by one mirror). */
- iMEM1 : ORIGIN = 0x00040000, LENGTH = 0x00040000
-
- /* 1MB of static RAM. This memory is mirrored 64 times. */
- SRAM : ORIGIN = 0x04000000, LENGTH = 0x00100000
- /* 64MB of DRAM. */
- SDRAM : ORIGIN = 0x08000000, LENGTH = 0x04000000
+ /* 256KB of internal memory (followed by one mirror). */
+ iMEM0 : ORIGIN = 0, LENGTH = 0x00040000
+ /* 256KB of internal memory (followed by one mirror). */
+ iMEM1 : ORIGIN = 0x00040000, LENGTH = 0x00040000
+
+ /* 1MB of static RAM. This memory is mirrored 64 times. */
+ SRAM : ORIGIN = 0x04000000, LENGTH = 0x00100000
+ /* 64MB of DRAM. */
+ SDRAM : ORIGIN = 0x08000000, LENGTH = 0x04000000
}
SECTIONS {
- .intv : {
- __intv_start = . ;
- *(.intv.reset) /* Reset vector */
- *(.intv.common) /* Vectors common to all v850e proc. */
- *(.intv.mach) /* Machine-specific int. vectors. */
- __intv_end = . ;
- } > iMEM0
-
- .text : {
- __kram_start = . ;
-
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
-
- . = ALIGN (0x4) ;
- *(.kstrtab)
-
- . = ALIGN (4) ;
- *(.call_table_data)
- *(.call_table_text)
-
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
- } > SRAM
-
- .data ALIGN (0x4) : {
- __sdata = . ;
- ___data_start = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > SRAM
-
- .bss ALIGN (0x4) : {
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
- } > SRAM
-
- .init ALIGN (4096) : {
- __init_start = . ;
- *(.init.text) /* 2.5 convention */
- *(.init.data)
- *(.text.init) /* 2.4 convention */
- *(.data.init)
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
-
- . = ALIGN (4) ;
- ___initramfs_start = . ;
- *(.init.ramfs)
- ___initramfs_end = . ;
-
- __init_end = . ;
-
- __kram_end = . ;
- } > SRAM
-
- .bootmap ALIGN (4096) : {
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
- } > SRAM
-
- /* Device contents for the root filesystem. */
- .root : {
- __root_fs_image_start = . ;
- *(.root)
- __root_fs_image_end = . ;
- } > SDRAM
+ .intv : { INTV_CONTENTS } > iMEM0
+ .sram : { RAMK_KRAM_CONTENTS } > SRAM
+ .root : { ROOT_FS_CONTENTS } > SDRAM
}
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/as85ep1-rom.ld arch/v850/as85ep1-rom.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/as85ep1-rom.ld 1970-01-01 09:00:00.000000000 +0900
+++ arch/v850/as85ep1-rom.ld 2002-12-18 18:05:14.000000000 +0900
@@ -0,0 +1,24 @@
+/* Linker script for the NEC AS85EP1 V850E evaluation board
+ (CONFIG_V850E_AS85EP1), with kernel in ROM (CONFIG_ROM_KERNEL). */
+
+/* Note, all symbols are prefixed with an extra `_' for compatibility with
+ the existing linux sources. */
+
+MEMORY {
+ /* 4MB of flash ROM. */
+ ROM : ORIGIN = 0, LENGTH = 0x00400000
+
+ /* 1MB of static RAM. */
+ SRAM : ORIGIN = 0x00400000, LENGTH = 0x00100000
+
+ /* About 58MB of DRAM. This can actually be at one of two
+ positions, determined by jump JP3; we have to use the first
+ position because the second is partially out of processor
+ instruction addressing range (though in the second position
+ there's actually 64MB available). */
+ SDRAM : ORIGIN = 0x00600000, LENGTH = 0x039F8000
+}
+
+SECTIONS {
+ ROMK_SECTIONS(ROM, SRAM)
+}
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/as85ep1.ld arch/v850/as85ep1.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/as85ep1.ld 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/as85ep1.ld 2002-12-19 14:25:40.000000000 +0900
@@ -1,23 +1,19 @@
/* Linker script for the NEC AS85EP1 V850E evaluation board
(CONFIG_V850E_AS85EP1). */
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
MEMORY {
- /* 1MB of internal memory (^[$BFbB"L?Na^[(BRAM). */
- iMEM0 : ORIGIN = 0, LENGTH = 0x00100000
+ /* 1MB of internal memory (^[$BFbB"L?Na^[(BRAM). */
+ iMEM0 : ORIGIN = 0, LENGTH = 0x00100000
- /* 1MB of static RAM. */
- SRAM : ORIGIN = 0x00400000, LENGTH = 0x00100000
+ /* 1MB of static RAM. */
+ SRAM : ORIGIN = 0x00400000, LENGTH = 0x00100000
- /* About 58MB of DRAM. This can actually be at one of two positions,
- determined by jump JP3; we have to use the first position because the
- second is partially out of processor instruction addressing range
- (though in the second position there's actually 64MB available). */
- SDRAM : ORIGIN = 0x00600000, LENGTH = 0x039F8000
+ /* About 58MB of DRAM. This can actually be at one of two
+ positions, determined by jump JP3; we have to use the first
+ position because the second is partially out of processor
+ instruction addressing range (though in the second position
+ there's actually 64MB available). */
+ SDRAM : ORIGIN = 0x00600000, LENGTH = 0x039F8000
}
SECTIONS {
@@ -26,87 +22,8 @@
*(.intv.reset) /* Reset vector */
} > iMEM0
- .text : {
- __kram_start = . ;
-
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
-
- . = ALIGN (0x4) ;
- *(.kstrtab)
-
- . = ALIGN (4) ;
- *(.call_table_data)
- *(.call_table_text)
-
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
- } > SRAM
-
- .data ALIGN (0x4) : {
- __sdata = . ;
- ___data_start = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > SRAM
-
- .bss ALIGN (0x4) : {
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
- } > SRAM
-
- .init ALIGN (4096) : {
- __init_start = . ;
- *(.init.text) /* 2.5 convention */
- *(.init.data)
- *(.text.init) /* 2.4 convention */
- *(.data.init)
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
-
- . = ALIGN (4) ;
- ___initramfs_start = . ;
- *(.init.ramfs)
- ___initramfs_end = . ;
+ .sram : {
+ RAMK_KRAM_CONTENTS
/* We stick most of the interrupt vectors here; they'll be
copied into the proper location by the early init code (we
@@ -121,27 +38,12 @@
*(.intv.mach) /* Machine-specific int. vectors. */
. = ALIGN (0x10) ;
__intv_copy_src_end = . ;
-
- /* This is here so that when we free init memory, the initial
- load-area of the interrupt vectors is freed too. */
- __init_end = . ;
- __kram_end = . ;
-
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
} > SRAM
/* Where we end up putting the vectors. */
__intv_copy_dst_start = 0x10 ;
__intv_copy_dst_end = __intv_copy_dst_start + (__intv_copy_src_end - __intv_copy_src_start) ;
-
__intv_end = __intv_copy_dst_end ;
- /* Device contents for the root filesystem. */
- .root : {
- . = ALIGN (4096) ;
- __root_fs_image_start = . ;
- *(.root)
- __root_fs_image_end = . ;
- } > SDRAM
+ .root : { ROOT_FS_CONTENTS } > SDRAM
}
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/fpga85e2c.ld arch/v850/fpga85e2c.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/fpga85e2c.ld 2002-11-05 11:25:21.000000000 +0900
+++ arch/v850/fpga85e2c.ld 2002-12-18 18:07:30.000000000 +0900
@@ -1,108 +1,36 @@
/* Linker script for the FPGA implementation of the V850E2 NA85E2C cpu core
(CONFIG_V850E2_FPGA85E2C). */
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
MEMORY {
- /* Reset vector. */
- RESET : ORIGIN = 0, LENGTH = 0x10
- /* Interrupt vectors. */
- INTV : ORIGIN = 0x10, LENGTH = 0x470
- /* The `window' in RAM were we're allowed to load stuff. */
- RAM_LOW : ORIGIN = 0x480, LENGTH = 0x0005FB80
- /* Some more ram above the window were we can put bss &c. */
- RAM_HIGH : ORIGIN = 0x00060000, LENGTH = 0x000A0000
- /* This is the area visible from the outside world (we can use
- this only for uninitialized data). */
- VISIBLE : ORIGIN = 0x00200000, LENGTH = 0x00060000
+ /* Reset vector. */
+ RESET : ORIGIN = 0, LENGTH = 0x10
+ /* Interrupt vectors. */
+ INTV : ORIGIN = 0x10, LENGTH = 0x470
+ /* The `window' in RAM were we're allowed to load stuff. */
+ RAM_LOW : ORIGIN = 0x480, LENGTH = 0x0005FB80
+ /* Some more ram above the window were we can put bss &c. */
+ RAM_HIGH : ORIGIN = 0x00060000, LENGTH = 0x000A0000
+ /* This is the area visible from the outside world (we can use
+ this only for uninitialized data). */
+ VISIBLE : ORIGIN = 0x00200000, LENGTH = 0x00060000
}
SECTIONS {
.reset : {
- __kram_start = . ;
+ __kram_start = . ;
__intv_start = . ;
*(.intv.reset) /* Reset vector */
} > RESET
- .r0_ram : {
- __r0_ram = . ;
+ .ram_low : {
+ __r0_ram = . ; /* Must be near address 0. */
. = . + 32 ;
- } > RAM_LOW
-
- .text : {
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
- . = ALIGN (0x4) ;
- *(.kstrtab)
-
- . = ALIGN (4) ;
- *(.call_table_data)
- *(.call_table_text)
-
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
- } > RAM_LOW
-
- .data : {
- __sdata = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > RAM_LOW
-
- /* Device contents for the root filesystem. */
- .root : {
- . = ALIGN (4096) ;
- __root_fs_image_start = . ;
- *(.root)
- __root_fs_image_end = . ;
- } > RAM_LOW
- .init ALIGN (4096) : {
- __init_start = . ;
- *(.init.text) /* 2.5 convention */
- *(.init.data)
- *(.text.init) /* 2.4 convention */
- *(.data.init)
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
+ TEXT_CONTENTS
+ DATA_CONTENTS
+ ROOT_FS_CONTENTS
+ RAMK_INIT_CONTENTS_NO_END
+ INITRAMFS_CONTENTS
} > RAM_LOW
/* Where the interrupt vectors are initially loaded. */
@@ -114,26 +42,16 @@
__intv_end = . ;
} > INTV AT> RAM_LOW
- .bss : {
+ .ram_high : {
/* This is here so that when we free init memory the
load-time copy of the interrupt vectors and any empty
space at the end of the `RAM_LOW' area is freed too. */
. = ALIGN (4096);
__init_end = . ;
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
-
- __kram_end = . ;
- } > RAM_HIGH
-
- .bootmap ALIGN (4096) : {
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
+ BSS_CONTENTS
+ __kram_end = . ;
+ BOOTMAP_CONTENTS
} > RAM_HIGH
.visible : {
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/rte_ma1_cb-ksram.ld arch/v850/rte_ma1_cb-ksram.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/rte_ma1_cb-ksram.ld 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/rte_ma1_cb-ksram.ld 1970-01-01 09:00:00.000000000 +0900
@@ -1,157 +0,0 @@
-/* Linker script for the Midas labs RTE-V850E/MA1-CB evaluation board
- (CONFIG_RTE_CB_MA1), with kernel in SRAM, under Multi debugger. */
-
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
-MEMORY {
- /* 1MB of SRAM; we can't use the last 32KB, because it's used by
- the monitor scratch-RAM. This memory is mirrored 4 times. */
- SRAM : ORIGIN = 0x00400000, LENGTH = 0x000F8000
- /* Monitor scratch RAM; only the interrupt vectors should go here. */
- MRAM : ORIGIN = 0x004F8000, LENGTH = 0x00008000
- /* 32MB of SDRAM. */
- SDRAM : ORIGIN = 0x00800000, LENGTH = 0x02000000
-}
-
-SECTIONS {
- .text : {
- __kram_start = . ;
-
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
-
- . = ALIGN (0x4) ;
- *(.kstrtab)
-
- . = ALIGN (4) ;
- *(.call_table_data)
- *(.call_table_text)
-
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
- } > SRAM
-
- .data ALIGN (0x4) : {
- __sdata = . ;
- ___data_start = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > SRAM
-
- .bss ALIGN (0x4) : {
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
- } > SRAM
-
- .init ALIGN (4096) : {
- __init_start = . ;
- *(.init.text) /* 2.5 convention */
- *(.init.data)
- *(.text.init) /* 2.4 convention */
- *(.data.init)
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
-
- . = ALIGN (4) ;
- ___initramfs_start = . ;
- *(.init.ramfs)
- ___initramfs_end = . ;
- } > SRAM
-
- /* This provides address at which the interrupt vectors are
- initially loaded by the loader. */
- __intv_load_start = ALIGN (0x10) ;
-
- /* Interrupt vector space. Because we're using the monitor
- ROM, Instead of the native interrupt vector, we must use the
- `alternate interrupt vector' area. Note that this is in
- `SRAM' space, which is not currently used by the kernel (the
- kernel uses `SDRAM' space). */
-
- /* We can't load the interrupt vectors directly into their
- target location, because the monitor ROM for the GHS Multi
- debugger barfs if we try. Unfortunately, Multi also doesn't
- deal correctly with ELF sections where the LMA and VMA differ
- (it just ignores the LMA), so we can't use that feature to
- work around the problem! What we do instead is just put the
- interrupt vectors into a normal section, and have the
- `mach_early_init' function for Midas boards do the necessary
- copying and relocation at runtime (this section basically
- only contains `jr' instructions, so it's not that hard).
-
- This the section structure I initially tried to use (which more
- accurately expresses the intent):
-
- .intv 0x007F8000 : AT (ADDR (.init) + SIZEOF (.init)) {
- ...
- } > MRAM
- */
-
- .intv ALIGN (0x10) : {
- __intv_start = . ;
- *(.intv.reset) /* Reset vector */
- *(.intv.common) /* Vectors common to all v850e proc. */
- *(.intv.mach) /* Machine-specific int. vectors. */
- __intv_end = . ;
-
- /* This is here so that when we free init memory, the initial
- load-area of the interrupt vectors is freed too. */
- __init_end = __intv_end;
-
- __kram_end = __init_end ;
- } > SRAM
-
- .bootmap ALIGN (4096) : {
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
- } > SRAM
-
- /* Device contents for the root filesystem. */
- .root : {
- __root_fs_image_start = . ;
- *(.root)
- __root_fs_image_end = . ;
- } > SDRAM
-}
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/rte_ma1_cb-rom.ld arch/v850/rte_ma1_cb-rom.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/rte_ma1_cb-rom.ld 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/rte_ma1_cb-rom.ld 2002-12-18 18:08:27.000000000 +0900
@@ -1,120 +1,14 @@
/* Linker script for the Midas labs RTE-V850E/MA1-CB evaluation board
(CONFIG_RTE_CB_MA1), with kernel in ROM. */
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
MEMORY {
- ROM : ORIGIN = 0x00000000, LENGTH = 0x00100000
- /* 1MB of SRAM. This memory is mirrored 4 times. */
- SRAM : ORIGIN = 0x00400000, LENGTH = 0x00100000
- /* 32MB of SDRAM. */
- SDRAM : ORIGIN = 0x00800000, LENGTH = 0x02000000
+ ROM : ORIGIN = 0x00000000, LENGTH = 0x00100000
+ /* 1MB of SRAM. This memory is mirrored 4 times. */
+ SRAM : ORIGIN = 0x00400000, LENGTH = 0x00100000
+ /* 32MB of SDRAM. */
+ SDRAM : ORIGIN = 0x00800000, LENGTH = 0x02000000
}
SECTIONS {
- /* Interrupt vector space. */
- .intv {
- __intv_start = . ;
- *(.intv.reset) /* Reset vector */
- *(.intv.common) /* Vectors common to all v850e proc. */
- *(.intv.mach) /* Machine-specific int. vectors. */
- __intv_end = . ;
- } > ROM
-
- .text : {
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
- . = ALIGN (0x4) ;
- *(.kstrtab)
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
-
- . = ALIGN (4) ;
- ___initramfs_start = . ;
- *(.init.ramfs)
- ___initramfs_end = . ;
- } > ROM
-
- __rom_copy_src_start = . ;
-
- .data : {
- __kram_start = . ;
-
- __sdata = . ;
- ___data_start = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > SRAM AT> ROM
-
- .bss ALIGN (0x4) : {
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
- } > SRAM
-
- .init ALIGN (4096) : {
- __init_start = . ;
- *(.init.text) /* 2.5 convention */
- *(.init.data)
- *(.text.init) /* 2.4 convention */
- *(.data.init)
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
- __init_end = . ;
-
- __kram_end = . ;
- } > SRAM
-
- .bootmap ALIGN (4096) : {
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
- } > SRAM
-
- /* device contents for the root filesystem. */
- .root ALIGN (4096) {
- __root_fs_image_start = . ;
- *(.root)
- __root_fs_image_end = . ;
- } > SDRAM
+ ROMK_SECTIONS(ROM, SRAM)
}
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/rte_ma1_cb.ld arch/v850/rte_ma1_cb.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/rte_ma1_cb.ld 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/rte_ma1_cb.ld 2002-12-20 11:24:13.000000000 +0900
@@ -1,157 +1,57 @@
/* Linker script for the Midas labs RTE-V850E/MA1-CB evaluation board
(CONFIG_RTE_CB_MA1), with kernel in SDRAM, under Multi debugger. */
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
MEMORY {
- /* 1MB of SRAM; we can't use the last 32KB, because it's used by
- the monitor scratch-RAM. This memory is mirrored 4 times. */
- SRAM : ORIGIN = 0x00400000, LENGTH = 0x000F8000
- /* Monitor scratch RAM; only the interrupt vectors should go here. */
- MRAM : ORIGIN = 0x004F8000, LENGTH = 0x00008000
- /* 32MB of SDRAM. */
- SDRAM : ORIGIN = 0x00800000, LENGTH = 0x02000000
+ /* 1MB of SRAM; we can't use the last 32KB, because it's used by
+ the monitor scratch-RAM. This memory is mirrored 4 times. */
+ SRAM : ORIGIN = 0x00400000, LENGTH = 0x000F8000
+ /* Monitor scratch RAM; only the interrupt vectors should go here. */
+ MRAM : ORIGIN = 0x004F8000, LENGTH = 0x00008000
+ /* 32MB of SDRAM. */
+ SDRAM : ORIGIN = 0x00800000, LENGTH = 0x02000000
}
+#ifdef CONFIG_RTE_CB_MA1_KSRAM
+# define KRAM SRAM
+#else
+# define KRAM SDRAM
+#endif
+
SECTIONS {
- .bootmap : {
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
- } > SRAM
+ /* We can't use RAMK_KRAM_CONTENTS because that puts the whole
+ kernel in a single ELF segment, and the Multi debugger (which
+ we use to load the kernel) appears to have bizarre problems
+ dealing with it. */
.text : {
- __kram_start = . ;
-
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
-
- . = ALIGN (0x4) ;
- *(.kstrtab)
-
- . = ALIGN (4) ;
- *(.call_table_data)
- *(.call_table_text)
-
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
- } > SDRAM
-
- .data ALIGN (0x4) : {
- __sdata = . ;
- ___data_start = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > SDRAM
-
- .bss ALIGN (0x4) : {
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
- } > SDRAM
-
- .init ALIGN (4096) : {
- __init_start = . ;
- *(.init.text) /* 2.5 convention */
- *(.init.data)
- *(.text.init) /* 2.4 convention */
- *(.data.init)
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
-
- . = ALIGN (4) ;
- ___initramfs_start = . ;
- *(.init.ramfs)
- ___initramfs_end = . ;
- } > SDRAM
-
- /* The address at which the interrupt vectors are initially
- loaded by the loader. */
- __intv_load_start = ALIGN (0x10) ;
-
- /* Interrupt vector space. Because we're using the monitor
- ROM, Instead of the native interrupt vector, we must use the
- `alternate interrupt vector' area. Note that this is in
- `SRAM' space, which is not currently used by the kernel (the
- kernel uses `SDRAM' space). */
-
- /* We can't load the interrupt vectors directly into their
- target location, because the monitor ROM for the GHS Multi
- debugger barfs if we try. Unfortunately, Multi also doesn't
- deal correctly with ELF sections where the LMA and VMA differ
- (it just ignores the LMA), so we can't use that feature to
- work around the problem! What we do instead is just put the
- interrupt vectors into a normal section, and have the
- `mach_early_init' function for Midas boards do the necessary
- copying and relocation at runtime (this section basically
- only contains `jr' instructions, so it's not that hard).
-
- This the section structure I initially tried to use (which more
- accurately expresses the intent):
-
- .intv 0x007F8000 : AT (ADDR (.init) + SIZEOF (.init)) {
- ...
- } > MRAM
- */
-
- .intv ALIGN (0x10) : {
- __intv_start = . ;
- *(.intv.reset) /* Reset vector */
- *(.intv.common) /* Vectors common to all v850e proc. */
- *(.intv.mach) /* Machine-specific int. vectors. */
- __intv_end = . ;
-
- /* This is here so that when we free init memory, the initial
- load-area of the interrupt vectors is freed too. */
- __init_end = __intv_end;
-
+ __kram_start = . ;
+ TEXT_CONTENTS
+ } > KRAM
+
+ .data : {
+ DATA_CONTENTS
+ BSS_CONTENTS
+ RAMK_INIT_CONTENTS
__kram_end = . ;
- } > SDRAM
+ BOOTMAP_CONTENTS
+
+ /* The address at which the interrupt vectors are initially
+ loaded by the loader. We can't load the interrupt vectors
+ directly into their target location, because the monitor
+ ROM for the GHS Multi debugger barfs if we try.
+ Unfortunately, Multi also doesn't deal correctly with ELF
+ sections where the LMA and VMA differ (it just ignores the
+ LMA), so we can't use that feature to work around the
+ problem! What we do instead is just put the interrupt
+ vectors into a normal section, and have the
+ `mach_early_init' function for Midas boards do the
+ necessary copying and relocation at runtime (this section
+ basically only contains `jr' instructions, so it's not
+ that hard). */
+ . = ALIGN (0x10) ;
+ __intv_load_start = . ;
+ INTV_CONTENTS
+ } > KRAM
- /* Device contents for the root filesystem. */
- .root ALIGN (4096) : {
- __root_fs_image_start = . ;
- *(.root)
- __root_fs_image_end = . ;
- } > SDRAM
+ .root ALIGN (4096) : { ROOT_FS_CONTENTS } > SDRAM
}
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/sim.ld arch/v850/sim.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/sim.ld 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/sim.ld 2002-12-19 14:23:24.000000000 +0900
@@ -1,114 +1,14 @@
/* Linker script for the gdb v850e simulator (CONFIG_V850E_SIM). */
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
MEMORY {
- /* Interrupt vectors. */
- INTV : ORIGIN = 0x0, LENGTH = 0xe0
- /* 16MB of RAM.
- This must match RAM_ADDR and RAM_SIZE in include/asm-v580/sim.h */
- RAM : ORIGIN = 0x8F000000, LENGTH = 0x01000000
+ /* Interrupt vectors. */
+ INTV : ORIGIN = 0x0, LENGTH = 0xe0
+ /* 16MB of RAM.
+ This must match RAM_ADDR and RAM_SIZE in include/asm-v850/sim.h */
+ RAM : ORIGIN = 0x8F000000, LENGTH = 0x01000000
}
SECTIONS {
- .intv : {
- __intv_start = . ;
- *(.intv.reset) /* Reset vector */
- *(.intv.common) /* Vectors common to all v850e proc. */
- *(.intv.mach) /* Machine-specific int. vectors. */
- __intv_end = . ;
- } > INTV
-
- .text : {
- __kram_start = . ;
-
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
- . = ALIGN (0x4) ;
- *(.kstrtab)
-
- . = ALIGN (4) ;
- *(.call_table_data)
- *(.call_table_text)
-
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
- } > RAM
-
- .data ALIGN (0x4) : {
- __sdata = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > RAM
-
- .bss ALIGN (0x4) : {
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
- } > RAM
-
- .init ALIGN (4096) : {
- __init_start = . ;
- *(.init.text) /* 2.5 convention */
- *(.init.data)
- *(.text.init) /* 2.4 convention */
- *(.data.init)
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
-
- . = ALIGN (4) ;
- ___initramfs_start = . ;
- *(.init.ramfs)
- ___initramfs_end = . ;
-
- __init_end = . ;
-
- __kram_end = . ;
- } > RAM
-
- .bootmap ALIGN (4096) : {
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
- } > RAM
+ .intv : { INTV_CONTENTS } > INTV
+ .ram : { RAMK_KRAM_CONTENTS } > RAM
}
diff -ruN -X../cludes ../orig/linux-2.5.52-uc0/arch/v850/sim85e2c.ld arch/v850/sim85e2c.ld
--- ../orig/linux-2.5.52-uc0/arch/v850/sim85e2c.ld 2002-11-28 10:24:54.000000000 +0900
+++ arch/v850/sim85e2c.ld 2002-12-18 18:06:50.000000000 +0900
@@ -1,141 +1,44 @@
/* Linker script for the sim85e2c simulator, which is a verilog simulation of
the V850E2 NA85E2C cpu core (CONFIG_V850E2_SIM85E2C). */
-/* Note, all symbols are prefixed with an extra `_' for compatibility with
- the existing linux sources. */
-
-_jiffies = _jiffies_64 ;
-
MEMORY {
- /* 1MB of `instruction RAM', starting at 0.
- Instruction fetches are much faster from IRAM than from DRAM.
- This should match IRAM_ADDR in "include/asm-v580/sim85e2c.h". */
- IRAM : ORIGIN = 0x00000000, LENGTH = 0x00100000
-
- /* 1MB of `data RAM', below and contiguous with the I/O space.
- Data fetches are much faster from DRAM than from IRAM.
- This should match DRAM_ADDR in "include/asm-v580/sim85e2c.h". */
- DRAM : ORIGIN = 0xfff00000, LENGTH = 0x000ff000
- /* We have to load DRAM at a mirror-address of 0x1ff00000,
- because the simulator's preprocessing script isn't smart
- enough to deal with the above LMA. */
- DRAM_LOAD : ORIGIN = 0x1ff00000, LENGTH = 0x000ff000
-
- /* `external ram' (CS1 area), comes after IRAM.
- This should match ERAM_ADDR in "include/asm-v580/sim85e2c.h". */
- ERAM : ORIGIN = 0x00100000, LENGTH = 0x07f00000
+ /* 1MB of `instruction RAM', starting at 0.
+ Instruction fetches are much faster from IRAM than from DRAM.
+ This should match IRAM_ADDR in "include/asm-v580/sim85e2c.h". */
+ IRAM : ORIGIN = 0x00000000, LENGTH = 0x00100000
+
+ /* 1MB of `data RAM', below and contiguous with the I/O space.
+ Data fetches are much faster from DRAM than from IRAM.
+ This should match DRAM_ADDR in "include/asm-v580/sim85e2c.h". */
+ DRAM : ORIGIN = 0xfff00000, LENGTH = 0x000ff000
+ /* We have to load DRAM at a mirror-address of 0x1ff00000,
+ because the simulator's preprocessing script isn't smart
+ enough to deal with the above LMA. */
+ DRAM_LOAD : ORIGIN = 0x1ff00000, LENGTH = 0x000ff000
+
+ /* `external ram' (CS1 area), comes after IRAM.
+ This should match ERAM_ADDR in "include/asm-v580/sim85e2c.h". */
+ ERAM : ORIGIN = 0x00100000, LENGTH = 0x07f00000
}
SECTIONS {
- .intv : {
- __intv_start = . ;
- *(.intv) /* Interrupt vectors. */
- *(.intv.reset) /* Reset vector */
- *(.intv.common) /* Vectors common to all v850e proc. */
- *(.intv.mach) /* Machine-specific int. vectors. */
- __intv_end = . ;
- } > IRAM
-
- .text : {
- __stext = . ;
- *(.text)
- *(.exit.text) /* 2.5 convention */
- *(.text.exit) /* 2.4 convention */
- *(.text.lock)
- *(.exitcall.exit)
- __real_etext = . ; /* There may be data after here. */
- *(.rodata)
- . = ALIGN (0x4) ;
- *(.kstrtab)
-
- . = ALIGN (4) ;
- *(.call_table_data)
- *(.call_table_text)
-
- . = ALIGN (16) ; /* Exception table. */
- ___start___ex_table = . ;
- *(__ex_table)
- ___stop___ex_table = . ;
-
- ___start___ksymtab = . ;/* Kernel symbol table. */
- *(__ksymtab)
- ___stop___ksymtab = . ;
- . = ALIGN (4) ;
- __etext = . ;
+ .iram : {
+ INTV_CONTENTS
+ TEXT_CONTENTS
+ RAMK_INIT_CONTENTS
} > IRAM
-
- .init ALIGN (4096) : {
- __init_start = . ;
- *(.init.text) /* 2.5 convention */
- *(.init.data)
- *(.text.init) /* 2.4 convention */
- *(.data.init)
- . = ALIGN (16) ;
- ___setup_start = . ;
- *(.init.setup) /* 2.5 convention */
- *(.setup.init) /* 2.4 convention */
- ___setup_end = . ;
- ___initcall_start = . ;
- *(.initcall.init)
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- . = ALIGN (4) ;
- ___initcall_end = . ;
-
- . = ALIGN (4) ;
- ___initramfs_start = . ;
- *(.init.ramfs)
- ___initramfs_end = . ;
-
- __init_end = . ;
- } > IRAM
-
.data : {
- __kram_start = . ;
+ __kram_start = . ;
+ DATA_CONTENTS
+ BSS_CONTENTS
+ ROOT_FS_CONTENTS
- __sdata = . ;
- *(.data)
- *(.exit.data) /* 2.5 convention */
- *(.data.exit) /* 2.4 convention */
- . = ALIGN (16) ;
- *(.data.cacheline_aligned)
- . = ALIGN (0x2000) ;
- *(.data.init_task)
- . = ALIGN (0x2000) ;
- __edata = . ;
- } > DRAM AT> DRAM_LOAD
-
- .bss ALIGN (0x4) : {
- __sbss = . ;
- *(.bss)
- *(COMMON)
- . = ALIGN (4) ;
- __init_stack_end = . ;
- __ebss = . ;
- } > DRAM AT> DRAM_LOAD
-
- /* Device contents for the root filesystem. */
- .root ALIGN (4096) : {
- __root_fs_image_start = . ;
- *(.root)
- __root_fs_image_end = . ;
- } > DRAM AT> DRAM_LOAD
-
- .memcons : {
+ /* We stick console output into a buffer here. */
_memcons_output = . ;
. = . + 0x8000 ;
_memcons_output_end = . ;
- __kram_end = . ;
- } > DRAM AT> DRAM_LOAD
-
- .bootmap ALIGN (4096) : {
- __bootmap = . ;
- . = . + 4096 ; /* enough for 128MB. */
+ __kram_end = . ;
+ BOOTMAP_CONTENTS
} > DRAM AT> DRAM_LOAD
}
^ permalink raw reply
* [PATCH] 2.4.20 fs/partitions/Config.in
From: Richard Russon @ 2002-12-20 5:01 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
Hi Marcelo,
You have already accepted the new LDM Driver into 2.4 (thanks :-)
but a little part of it got lost.
This patch removes the "experimental" tag and dependency.
(The new LDM Driver is not experimental).
Please can you apply this patch to 2.4.20.
Cheers,
FlatCap (Richard Russon)
ldm@flatcap.org
diff -urN linux-2.4.20/fs/partitions/Config.in linux-2.4.20-ldm/fs/partitions/Config.in
--- linux-2.4.20/fs/partitions/Config.in 2002-11-29 00:13:16.000000000 +0000
+++ linux-2.4.20-ldm/fs/partitions/Config.in 2002-12-20 04:41:32.000000000 +0000
@@ -25,7 +25,7 @@
bool ' Solaris (x86) partition table support' CONFIG_SOLARIS_X86_PARTITION
bool ' Unixware slices support' CONFIG_UNIXWARE_DISKLABEL
fi
- dep_bool ' Windows Logical Disk Manager (Dynamic Disk) support (EXPERIMENTAL)' CONFIG_LDM_PARTITION $CONFIG_EXPERIMENTAL
+ bool ' Windows Logical Disk Manager (Dynamic Disk) support' CONFIG_LDM_PARTITION
if [ "$CONFIG_LDM_PARTITION" = "y" ]; then
bool ' Windows LDM extra logging' CONFIG_LDM_DEBUG
fi
^ permalink raw reply
* Re: RFC: bus_type and device_class merge (or partial merge)
From: Patrick Mochel @ 2002-12-20 4:29 UTC (permalink / raw)
To: Adam J. Richter; +Cc: linux-kernel
In-Reply-To: <200212192244.OAA06433@adam.yggdrasil.com>
> A philosophical musing is not substitute for identifying real
> technical advantages or disadvantages, but thanks for the response.
Ouch.
> If my proposed changes shrink kernel memory footprint, improve
> code maintainability, allow multiple drivers per device (e.g., scsi
> generic and scsi disk), users will be better off with those advantages
> than being lost in a doctrine for which they've lost track of the benefits.
You're trying to pinch pennies with the footprint you're talking about.
The extra structure definition costs nothing, and the code to interface
those objects with the other driver model objects is trivial.
Plus, you'd be overloading the object to behave differently depending on
how it was referenced, causing more code. That certainly wouldn't improve
code maintainability.
A device belongs to exactly one bus type and exactly one class type. This
is easy to express. If you combine the objects, you either reference each
instance explicitly, kinda like they are now, or you represent it in some
list, which will complicate the existing code immensely.
What problem would that solve? How would that allow you to bind multiple
drivers to a device? Why would you want to do that anyway?
To support scsi-generic? I've talked with SCSI people before about this.
It's bad to treat it as a driver, because it causes the core to special
case these wacky instances where you have an extension of the bus driver
apply to each device registered with it. I've gotten verbal confirmation
that scsi-generic will change in this regard, and I've offered to provide
hooks to make this easier to express.
For the record, both USB and PCI do similar things. USB creates procfs
entries, and can create device nodes. IIRC, USB makes an explicit call to
the function that does this. PCI makes an explicit call to create procfs
entries for each PCI device. They could all be implemented as 'drivers'
but it doesn't make sense to overload the objects to do it this way.
> >They're not the same, though. They may be similar, but they are
> >fundamentally different.
>
> There are also differences between USB and PCI, but that
> doesn't mean that the part that is handled by drivers/base has to be
> different. The question is whether having separate implementations
> for a set of differences make the code smaller, faster, more
> functional, or delivers other real benefits that tip the trade-off.
Why? Why try to micro-optimize the core now? You'll gain much more by
converting bus and class drivers to use the driver model objects, and
reducing the replication in the dusty corners of the kernel.
> Perhaps it would help you to understand the impetus that made
> me think about this. I want to have a mechanism for race-free module
> unloading without a new lowest level locking primitive (i.e., just by
> using rw_semaphore). To make its use transparent for most cases, I
> want add a field to struct device_driver and add a couple of lines to
> {,un}register_driver, and I see that if I have to duplicate this
> effort if I want the same thing for, say, converting filesystems to
> use the generic driver interface. I don't see that duplication buying
> any real improvement in speed, kernel footprint, source code size,
> etc. In other words, having two separate interfaces makes it harder
> to write other facilities that are potentially generic to
> driver/target rendezvous.
Fine. That would be nice. You definitely have good intentions, but there
is much more work to be done, that is far less glamorous, that I am
concerned with.
> >Consolidation is possible, but I would not recommend doing it by merging
> >the structures. Look for other ways to create common objects that the two
> >can share.
>
> I'm thinking about this. I just wonder if there would be any
> remaining fields that would not be common.
Even if there are not, they have different purposes, and different
semantics for dealing with them. Please do not play God on them, they are
there for specific purposes.
> >Especially during the continuing evolution
> >of the model. At least for now, and for probably a very long time, I will
> >not consider patches to consolidate the two object types.
>
> Linux will be better if we decide things by weighing technical
> benefits rather than by attempts at diktat. I recommend you keep an
> open mind about it.
I like to think I do have an open mind. I listen to what everyone says,
good or bad, and save it all. Well, most. I am definitely not the one to
have a closed mind, since I know for a fact most of the people that rant
and rave have much more experience with this stuff than I do.
I may not respond to everything, and it may appear I ignore things, but
it's only because I am weighing and contemplating them, and their
responses. I may not know the low-level details about many things, but
I've spent enough of the last two years comparing and analyzing the
behavior of drivers to mean it when I say I will not consider patches of
that type. :)
-pat
^ permalink raw reply
* hpt366
From: Pete Popov @ 2002-12-20 4:43 UTC (permalink / raw)
To: linux-mips
Anyone else having problems with the hpt366 driver in 2_4? The previous
revision,which apparently goes back to 2.4.9, works fine.
Pete
^ permalink raw reply
* RE: firewall failover / cluster
From: freedom @ 2002-12-20 4:21 UTC (permalink / raw)
To: 'Hauser Marcel', netfilter
In-Reply-To: <3E028951.8090800@gmx.ch>
Partially along this same subject, I am curious what is currently being
used in a fault tolerant AND load-balanced iptables configuration.
Perhaps a better question...is anybody using iptables in a HA, Load
balancing scenario?
Thanks!
Kameron
> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org [mailto:netfilter-
> admin@lists.netfilter.org] On Behalf Of Hauser Marcel
> Sent: Thursday, December 19, 2002 9:07 PM
> To: netfilter@lists.netfilter.org
> Subject: firewall failover / cluster
>
> hi all
>
> What are you guys using in order to provide a fault toleranced
iptables
> firewall (master / slave ?)
>
> Cheers Marcel
>
>
>
^ 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.