* Re: linuxppc-commit mailing list
From: Hollis Blanchard @ 2002-12-16 20:39 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc embedded
In-Reply-To: <20021213163502.GK19456@opus.bloom.county>
On Fri, 2002-12-13 at 10:35, Tom Rini wrote:
> > If you aren't already on the linuxppc-commit@source.mvista.com list, you
> > might want to join that.
>
> And since this is at a possibly non obvious location:
> http://source.mvista.com/cgi-bin/mailman/listinfo/linuxppc-commit
>
> <hint>Hopefully PenguinPPC.org will have a link to this somewhere.</hint>
Actually it's already been linked to for a while (at
http://penguinppc.org/dev/kernel.shtml), but I've now made it more
obvious.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Support for Arctic platform (405LP based))
From: Tom Rini @ 2002-12-16 20:36 UTC (permalink / raw)
To: Cort Dougan; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20021216131340.D9431@duath.fsmlabs.com>
On Mon, Dec 16, 2002 at 01:13:40PM -0700, Cort Dougan wrote:
``
> Right, changes would keep going. Having many trees all based on the same
> root would make moving patches back and forth much easier.
It's irrelevant what they're based on, Marcelo would never pull from the
'linux-2.4-4xx-walnut' tree, nor the 'linux-2.4-4xx' tree, as there will
be lots of "whoops, lets try it this way now" stuff, etc.
> People would be able to grab what they need (a booting walnut, for example)
> without pulling in >1 years worth of development and unstable changes. I
> definitely think it would be useful.
But that's just it, the >1 year of "development and unstable changes" is
4xx. The largest problem with the _devel tree right now is that once
something becomes stable it hasn't moved up and out to Marcelo (and in
some cases, Linus). It's not because things can't be taken out, it's
been around 80% time / timing, 15% style / cleanliness / minor tweaking,
and maybe 5% of actual unstable code.
> } But more trees with smaller patches doesn't mean that the 'growth'
> } stops. Furthermore, there's only 4 things in _devel right now:
> } 1) 4xx - It's "stable", in that there haven't been any big changes for
> } some time, and as far as I know few "bugs". But there's still a lot to
> } be done.
>
> Exactly my point. It's mired in the next of _devel right now but should be
> shoved up into the stable tree.
4xx should not be shoved up into the 'stable' tree as it's not ready for
Marcelo. I fully expect Paul to want a largescale backport of a lot of
what's been done in 2.5 for 4xx, once it's done.
> } 3) OpenPIC / i8259 cleanups, some backported from 2.5 some original, all
> } of which is quite stable right now. There's just boards which need
> } updating still (!!!). This is ready to go up and out, and will move a
> } large chunk of code out of _devel with it.
> } 4) gt64260 support. What's in _devel now is stale, and this doesn't
> } depend on anything in _devel now anyhow. FWIW, this exists in its own
> } tree anyways :)
>
> All the more reason for a linuxppc_2_4_galileo tree.
Where it has been for some time. IIRC, the linuxpcp_2_4_galileo tree is
rather stable, but in this case it's 99% time of why it hasn't been put
back into _devel where it's more noticable to Paul.
> } Far too much division, which also makes moving things up more painful as
> } each one will conflict on the cpu-specific stuff, the config.in entry,
> } etc.
>
> I don't think so. It just illustrates what is already the case - it's just
> not organized. Each BK tree is its own node in that graph I drew. This
> just formalizes it a bit so people know where to push/pull from when they
> want a specific thing.
But that's just it, the specific thing most people want is a stable 40x
tree so they can modify things for their own custom port. If all of the
40x code is in one place perhaps they will pick up on a similar change
another port needed, and potentially encourage them to think generically
for some quirk they hit.
Which reminds me of another issue, if we have too many trees things it
makes it even harder to get Paul to potentially notice code and comment
on things.
> } But regardless of all of that, there's nothing related to this being a
> } 'marcelo' tree or not as you can't pick and choose bk csets without
> } everything preceeding it. Ideally we can get to the point of not really
> } needing a seperate tree like 2.2 is (which could go if someone wants to
> } sit down and think about the LongTrail-specific changes in there).
>
> Is there a point to this not being based on the Marcelo tree? A good
> cleanout and shift over to it is certainly worthwhile.
A "good cleanout" is bad as we loose all of that history. It came in
quite handy for me to have a copy of the old linuxppc_2_3 and
linuxppc_2_5 trees (until that drive died) when trying to figure out why
something was done. I really don't want to see that happen again for
2.4.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?
From: Charles Manning @ 2002-12-16 21:02 UTC (permalink / raw)
To: David Woodhouse, Wolfgang Denk; +Cc: Paul Nash, Linux-MTD (E-mail)
In-Reply-To: <18190.1040039149@passion.cambridge.redhat.com>
Ooooh flash, my favourite subject.
Yup, our Intel reps also put the hard sell on us too... Remember, Intel own
NOR flash and are losing market share as more people switch to NAND. Already,
most new WinCE devices are using NAND instead - at least for the bulk of
their bytes.
In general, NOR flash is expensive, slow and not very dense.
Because it is slow, you typically need to copy the image into RAM to get
performance. This does not apply to synchronous flash which provides better
bandwidth.
If you're going XIP and want performance, then you need a full bus-width of
flash. The dollars and the board space start to stack up.
Intel's flash is expensive. Figure somwhere over $1 per MB. NAND costs
approx 30c/MB + SDRAM approx 20c/MB. Intel's flash thus costs approx twice
what a NAND/RAM image does.
One NAND flash footprint can give you up to 256MB of storage.
NOR fully sucks for any sort of writeable file system performance. NAND runs
a very usable fs with YAFFS or JFFS2.
The only benefit I can see in NOR is a faster boot. This is becoming less of
an issue as more designs switch to sleep/resume models.
Now that the newer NAND devices support limited direct execution of code
we're going to see the emergence of devices that have no NOR at all.
IMHO, XIP is the past, not the future.
-- CHarles
^ permalink raw reply
* counting shell args
From: Scott Taylor @ 2002-12-16 20:36 UTC (permalink / raw)
To: linux-admin
I'm sure I've seen, probably even use it before, but I can't remember or
find it now; does anyone remember how to count the number of arguments sent
to a bash script?
Like "if [ -z $3 ]; then" ... of corse that's for testing argument 3
exists, but how do I test if 3 arguments and only 3, are passed to the
script (or 1 or 10 or whatever).
Don't you just hate it when that happens. =P
^ permalink raw reply
* Re: Linux v2.5.52
From: Larry McVoy @ 2002-12-16 20:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ben Collins, Christoph Hellwig, Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212160920380.2799-100000@home.transmeta.com>
> Alternatively, never EVER make a patch against the "current kernel
> version". Only make a patch against the _last_ kernel that you merged
> with, and if I cannot apply it I will tell you so. Making a patch just
> between your tree and mine will _always_ end up losing fixes.
I think this is a good approach. If people sent Linus patches with some
indication of the baseline of the patch, such as BASELINE=v2.5.49 in the
header of the patch, I'd be willing to go make bk import -temail do
the right thing, which would probably be to try and patch it in in the
working tree, but if that didn't work, it would do
bk clone -l -r$BASELINE tree tree.$BASELINE
cd tree.$BASLINE
bk import -temail ....
cd ../tree
bk pull ../tree.$BASELINE && rm -rf ../tree.$BASELINE
and you'd get BK to merge most of the work.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: 2.5.51: sleep broken
From: Ducrot Bruno @ 2002-12-16 20:30 UTC (permalink / raw)
To: P. Christeas; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <200212152356.09656.p_christ-U04EIuiosng@public.gmane.org>
On Sun, Dec 15, 2002 at 11:56:09PM +0200, P. Christeas wrote:
> I also noted some perculiarity in the code:
>
> in: linux/arch/i386/kernel/acpi.c
> in: acpi_reserve_bootmem(void)
> ...
> if ((&wakeup_end - &wakeup_start) > PAGE_SIZE)
> printk(KERN_CRIT "ACPI: Wakeup code way too big, will crash on
> attempt to suspend (0x%8.8lx)\n",
> (&wakeup_end - &wakeup_start));
>
> --- I added the parameter to see what's happening. The message indicated an
> 0x3000 size. (12k)
>
> the comment for the fn says:
> * We allocate a page in low memory for the wakeup
> * routine for when we come back from a sleep state. The
> * runtime allocator allows specification of <16M pages, but not
> * <1M pages.
>
> Are the above lines correct? AFAIK macro PAGE_SIZE = 4096
> That would mean that only <4k code is allowed. OK, but the comment suggests
> otherwise...
Search for wakeup_stack under acpi_wakeup.S
I have modified that and it look something like that for me now:
.org 0x800
wakup_stack:
.org 0x900
ENTRY(wakup_end)
.org 0x1000
(hint given by Pavel)
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: success with redneck rampage and a few questions
From: Emmanuel Jeandel @ 2002-12-16 20:25 UTC (permalink / raw)
To: linux-msdos
In-Reply-To: <3DFE2DB5.1000407@yahoo.com>
Stas Sergeev said
> Hello.
> >1. i already read in the mailing list archives that there
> >is no full screen xdosemu. it sounds like there never
> >will be a fullscreen xdosemu either.
> Not obviously. At least I think Emmanuel
> Jeandel wrote an SDL frontend, which can
> be used for full-screen graphics. I wonder
> if it is still being developed or dropped
> (which would be a shame).
Still being developed. The current version is
working, but needs to be cleaned up.
I may post a patch in my webpage ASAP (not
until next month).
Emmanuel
^ permalink raw reply
* Domain transition
From: Richard Mayo @ 2002-12-16 20:09 UTC (permalink / raw)
To: SELinux
I have a few questions, and I hope you good folks can help me out:
1) What is "domain transition"? I've configured my system such that it
doesn't happen, but I'm wondering if it's the best way to go.
2) Is there a text file on my system with the list of user roles or is
that information stored some other way?
3) Can I configure the operating system NOT to ask for a user role on
login? I would much prefer to have user role determined BY the login.
I'm sure I'll have others, but I can't think of anything at this time.
R.
--
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
* HOWTO correction - broken link
From: Peter Jay Salzman @ 2002-12-16 20:23 UTC (permalink / raw)
To: linux-msdos
hi all,
in http://dosemu.sourceforge.net/docs/HOWTO/dosemu-HOWTO-1.html#ss1.4
the link to bochs:
www.bochs.com
should be changed to:
http://bochs.sourceforge.net
looks like www.bochs.com is no more. at least, not anything useful.
:)
pete
--
First they ignore you, then they laugh at you, then they fight you,
then you win. -- Gandhi, being prophetic about Linux.
Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
^ permalink raw reply
* Re: slow NFS performance extracting bits from large files
From: Bruce Allen @ 2002-12-16 20:17 UTC (permalink / raw)
To: Bruce Allan; +Cc: nfs, nfs-admin
In-Reply-To: <OF5780D600.FCFDD312-ON88256C91.005F9A85@us.ibm.com>
Hi Bruce,
Problem solved. The point is that the code requires a lot of disks seeks
(20,000), which cost milliseconds each. This is the dominant cost, not
the read()s. Please see the thread with Paul Haas who nailed the problem
on his first reply.
Bruce Allen
On Mon, 16 Dec 2002, Bruce Allan wrote:
>
>
>
>
> Hi Bruce (good name, btw),
>
> It would help if you posted information about your network. Alternately,
> you could read the "Optimizing NFS Performance" section of the Linux
> NFS-HOWTO located at http://nfs.sourceforge.net/nfs-howto/
>
> Regards,
> ---
> Bruce Allan <bruce.allan@us.ibm.com>
> Software Engineer, Linux Technology Center
> IBM Corporation, Beaverton OR
> 503-578-4187 IBM Tie-line 775-4187
>
>
>
>
> Bruce Allen
> <ballen@gravity.phys To: nfs@lists.sourceforge.net
> .uwm.edu> cc: Bruce Allen <ballen@gravity.phys.uwm.edu>
> Sent by: Subject: [NFS] slow NFS performance extracting bits from large files
> nfs-admin@lists.sour
> ceforge.net
>
>
> 12/15/2002 11:02 PM
>
>
>
>
>
> I've searched/browsed the mail archive and the online documentation but am
> still a bit clueless about where to start.
>
> I am working on a scientific data analysis application which needs to
> extract a little bit of data from around 10,000 files. The files
> themselves are each around 1 MB in size. The application does:
>
> for (i=0; i<10000; i++){
> open() ith file
> read() 32 bytes from beginning
> lseek() to somewhere in the middle of the file
> read() 620 bytes from the middle of the file
> close() ith file
> }
>
> If I run this with the data set on a local disk, the total run time is
> around 1 sec -- very reasonable since I am transferring around 6 MB of
> data.
>
> If I run this on an NFS-mounted disk the performance is 100 times worse.
> Both client and server are stock RH 7.3. Note that if I run it a second
> time, when the data is presumably cached, it takes just a few seconds to
> run.
>
> Is it obvious what needs to be changed/tuned to improve this performance?
> Or if not, could someone suggest a tool and a strategy for tracing down
> the cause of the poor performance?
>
> Sincerely,
> Bruce Allen
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>
>
>
>
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: new kernel patch
From: Russell Coker @ 2002-12-16 20:15 UTC (permalink / raw)
To: Stephen D. Smalley, selinux
In-Reply-To: <200212161827.NAA00650@moss-shockers.ncsc.mil>
On Mon, 16 Dec 2002 19:27, Stephen D. Smalley wrote:
> When an inode is allocated, its SID is initialized to the unlabeled
> initial SID (=> system_u:object_r:unlabeled_t), and its security class
> is initialized to the file class by default. This log message indicates
> that a devfs inode reached a permission check without first being
> initialized by inode_doinit, likely due to a race between
> selinux_inode_post_lookup and a cached lookup. The empty permission
> set is due to an inability to map the requested permission (likely search)
> to a permission in the file class.
>
> As a short term fix, I'd suggest the attached patch. A proper fix requires
> adjusting the inode_init call in d_instantiate and the SELinux hook
> function to properly handle filesystems that rely on genfs_contexts.
This works. I'll add it to my kernel-patch package for Debian.
Also I've updated my kernel-patch-2.5-lsm package to include your latest
patch.
--
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: Unable to mount root fs on 01:00 ...
From: James Don @ 2002-12-16 20:14 UTC (permalink / raw)
To: 'Jean-Denis Boyer', James Don; +Cc: Embedded Linux PPC List
Indeed you were correct ...
No everything seems to work ... bash shell and all ...
-----Original Message-----
From: Jean-Denis Boyer [mailto:jdboyer@mediatrix.com]
Sent: Monday, December 16, 2002 3:00 PM
To: James Don
Cc: Embedded Linux PPC List
Subject: RE: Unable to mount root fs on 01:00 ...
James,
> Kernel panic: VFS: Unable to mount root fs on 01:00
Did you include EXT2 file system in your kernel image?
If not, you would obtain this error.
Regards,
--------------------------------------------
Jean-Denis Boyer, B.Eng., Technical Leader
Mediatrix Telecom Inc.
4229 Garlock Street
Sherbrooke (Québec)
J1L 2C8 CANADA
(819)829-8749 x241
--------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: PPC Tree structures (Was, at some point: Re: Support for Arctic platform (405LP based))
From: Cort Dougan @ 2002-12-16 20:13 UTC (permalink / raw)
To: Tom Rini; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20021216201301.GA2513@opus.bloom.county>
Right, changes would keep going. Having many trees all based on the same
root would make moving patches back and forth much easier.
People would be able to grab what they need (a booting walnut, for example)
without pulling in >1 years worth of development and unstable changes. I
definitely think it would be useful.
} But more trees with smaller patches doesn't mean that the 'growth'
} stops. Furthermore, there's only 4 things in _devel right now:
} 1) 4xx - It's "stable", in that there haven't been any big changes for
} some time, and as far as I know few "bugs". But there's still a lot to
} be done.
Exactly my point. It's mired in the next of _devel right now but should be
shoved up into the stable tree.
} 2) 8xx - This can quite probably all go right on up and out, pending
} time.
Same thing.
} 3) OpenPIC / i8259 cleanups, some backported from 2.5 some original, all
} of which is quite stable right now. There's just boards which need
} updating still (!!!). This is ready to go up and out, and will move a
} large chunk of code out of _devel with it.
} 4) gt64260 support. What's in _devel now is stale, and this doesn't
} depend on anything in _devel now anyhow. FWIW, this exists in its own
} tree anyways :)
All the more reason for a linuxppc_2_4_galileo tree.
} Far too much division, which also makes moving things up more painful as
} each one will conflict on the cpu-specific stuff, the config.in entry,
} etc.
I don't think so. It just illustrates what is already the case - it's just
not organized. Each BK tree is its own node in that graph I drew. This
just formalizes it a bit so people know where to push/pull from when they
want a specific thing.
} But regardless of all of that, there's nothing related to this being a
} 'marcelo' tree or not as you can't pick and choose bk csets without
} everything preceeding it. Ideally we can get to the point of not really
} needing a seperate tree like 2.2 is (which could go if someone wants to
} sit down and think about the LongTrail-specific changes in there).
Is there a point to this not being based on the Marcelo tree? A good
cleanout and shift over to it is certainly worthwhile.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* PPC Tree structures (Was, at some point: Re: Support for Arctic platform (405LP based))
From: Tom Rini @ 2002-12-16 20:13 UTC (permalink / raw)
To: Cort Dougan; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20021216124931.B9431@duath.fsmlabs.com>
On Mon, Dec 16, 2002 at 12:49:31PM -0700, Cort Dougan wrote:
> } I'm not sure how that would stop the growth of the '_devel' tree, it
> } would just split it up into 4xx, and everything else. And my goal of
> } the new few weeks is to try and move everything that's not 4xx that I
> } can get my hands on to test into the _2_4 tree. I'm not sure just how
> } much of that I'll actually be able to do, but I'm going to try.
>
> There would be no _devel tree in that case. They'd all be based on
> Marcelo's so moving back and forth would be easier. There would also be
> more trees and smaller patches.
But more trees with smaller patches doesn't mean that the 'growth'
stops. Furthermore, there's only 4 things in _devel right now:
1) 4xx - It's "stable", in that there haven't been any big changes for
some time, and as far as I know few "bugs". But there's still a lot to
be done.
2) 8xx - This can quite probably all go right on up and out, pending
time.
3) OpenPIC / i8259 cleanups, some backported from 2.5 some original, all
of which is quite stable right now. There's just boards which need
updating still (!!!). This is ready to go up and out, and will move a
large chunk of code out of _devel with it.
4) gt64260 support. What's in _devel now is stale, and this doesn't
depend on anything in _devel now anyhow. FWIW, this exists in its own
tree anyways :)
> Right now, if you want an embedded board to boot your only chance is to try
> the wildly divergent - likely unstable - _devel tree.
But that's just it, it's not "likely unstable" and with a few exceptions
noted above hasn't been for some time (it's either fine or non-compiling
iirc).
> Having something
> like this would be much nicer:
>
>
> marcelo ---> linuxppc_2_4 --- linuxppc_2_4_4xx
> | |
> | ---> linuxppc_2_4_4xx_walnut
> | |
> | ---> linuxppc_2_4_4xx_crazystuff
> | |
> | ---> linuxppc_2_4_4xx_some_whacky_port
Far too much division, which also makes moving things up more painful as
each one will conflict on the cpu-specific stuff, the config.in entry,
etc.
But regardless of all of that, there's nothing related to this being a
'marcelo' tree or not as you can't pick and choose bk csets without
everything preceeding it. Ideally we can get to the point of not really
needing a seperate tree like 2.2 is (which could go if someone wants to
sit down and think about the LongTrail-specific changes in there).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: usbaudio won't do 24-bit or 32-bit i/o...
From: Patrick Shirkey @ 2002-12-16 20:11 UTC (permalink / raw)
Cc: Takashi Iwai, alsa-devel
In-Reply-To: <3DFE2295.2020502@boosthardware.com>
Patrick Shirkey wrote:
> Takashi Iwai wrote:
>
>>
>> hmm, it's weird. it would be nice if we can know at which point the
>> driver became broken...
>>
>
> It was working nicely before the drivers were merged but wouldn't paly
> with jack. Now it likes jack.
>
In additon to this the last version I had from before the merge that
seemed to work well is from September 5. In that version I can record
from inputs 1,2 and playback from all 4 channels.
I also get "sample format non available" when trying to use s24_3le with
this version at any sample rate.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: slow NFS performance extracting bits from large files
From: Bruce Allen @ 2002-12-16 20:10 UTC (permalink / raw)
To: Paul Haas, paulh, nfs; +Cc: Bruce Allen
In-Reply-To: <Pine.GSO.4.21.0212161146420.5571-100000@dirac.phys.uwm.edu>
Hi Paul,
Well, this thread is about to terminate. You nailed it the first
time. The results are (after dirtying the local disk cache):
On local disk: 2 m 45 s = 165 secs.
On NFS disk: 2 min 50 s = 170 secs.
In the long run we may want to reformat/redistribute the data so that
we're not seek-limited like this.
Thank you very much for explaning this to me. I was really puzzled about
what was going on.
Bruce Allen
On Mon, 16 Dec 2002, Bruce Allen wrote:
> Hi Paul,
>
> Thanks for the quick reply.
>
> > > I am working on a scientific data analysis application which needs to
> > > extract a little bit of data from around 10,000 files. The files
> > > themselves are each around 1 MB in size. The application does:
> > >
> > > for (i=0; i<10000; i++){
> > > open() ith file
> > > read() 32 bytes from beginning
> > > lseek() to somewhere in the middle of the file
> > > read() 620 bytes from the middle of the file
> > > close() ith file
> > > }
> >
> > So that's 20,000 reads. Readahead wouldn't help much with this access
> > pattern, so it looks like 20,000 reads and 20,000 seeks.
>
> > > If I run this with the data set on a local disk, the total run time is
> > > around 1 sec -- very reasonable since I am transferring around 6 MB of
> > > data.
> >
> > Ok, 20,000 seeks per second, shows an average seek time of 50
> > microseconds. You can't do that with a spinning disk. You've discovered
> > how well disk caching works.
>
> Thank you very much. This is a reasonable (obvious!) explanation. Let me
> see if I undertand correctly.
>
> I just looked up the specs for the local disk that I was using for the
> comparison testing. It averages around 600 512-byte sectors (300 kB) per
> track, and 1ms average track to track seek time. So (assuming little
> fragmentation) a typical file is spread across 3 to 4 tracks of the disk.
> Thus, if I seek to a data set in the middle of a file, and assuming that
> the files are "more or less" contiguous on the disk, a typical iteration
> of the loop above starting from the first read, should involve:
>
> read 32 bytes
> seek to middle (2 tracks) 2 msec
> read 620 bytes
> seek to next file (2 tracks) 2 msec
>
> hence 4 msec/file x 10k files = 40 sec read time if the kernel disk cache
> buffers are all dirty. Does the estimate above look reasonable?
>
> I'll do the experiment that you suggest, using wc to clear the cache
> first, and see how this compares to what's above.
>
> > > If I run this on an NFS-mounted disk the performance is 100 times worse.
> > > Both client and server are stock RH 7.3. Note that if I run it a second
> > > time, when the data is presumably cached, it takes just a few seconds to
> > > run.
> >
> > 20000 seeks in 100 seconds, that's an average seek time of 5 ms. That's
> > possible on real hardware.
>
> The files on the NFS server live on an ATA RAID array, made of 3-ware 7850
> controller running in hardware RAID-5 with the data striped across 7 disks
> (the 8th disk is a hot spare). I think the stripe size is configured to
> the maximum value, but I have forgotten what that is. I have no idea what
> the equivalent "seek time" on such a system is.
>
> The client and the server are networked via gigabit ethernet, through a
> Foundry Networks switch. Neither the switch nor the client or server are
> oversubscribed.
>
> > > Is it obvious what needs to be changed/tuned to improve this performance?
> > > Or if not, could someone suggest a tool and a strategy for tracing down
> > > the cause of the poor performance?
> >
> > Clear the cache in the system with the local disk and measure the
> > performance. You can clear the cache by reading files bigger than all of
> > RAM. I tend to use "wc *" in a directory with some large tar files. wc
> > kindly tells me how many bytes I've read, so I know if I've read enough.
> >
> > With a clear cache you'll see local performance numbers that are closer to
> > the NFS numbers.
>
> OK, I'll try this. In retrospect, it's obvious.
>
> > What's the ping time? The NFS performance should have a penalty of
> > something like 3 network transactions per file, so your NFS times should
> > be 30,000 packet round trips longer than the local case. (maybe 4 network
> > transactions per file if there is also a stat call, a network trace would
> > show all the transactions).
>
> There's no stat call -- I've used strace to verify that I am only doing
> the operations described in my pseudo-code above.
>
> open("/scratch/xavi/CAL_L1_Data//CAL_SFT.714299460", O_RDONLY) = 3
> read(3, "\0\0\0\0\0\0\360?DX\223*\0\0\0\0\0\0\0\0\0\0N@\270\v\0"..., 32) =
> 32
> lseek(3, 460776, SEEK_CUR) = 460808
> read(3, "\336\203z&\tM\216&/\342\227\244\307\333\352\245\233\27"...,
> 620) = 620
> close(3) = 0
> open("/scratch/xavi/CAL_L1_Data//CAL_SFT.714299520", O_RDONLY) = 3
>
> There's no stat(). So I think it's 3 not 4. Here are the ping times:
>
> [ballen@medusa-slave123 ballen]$ ping storage1
> PING storage1.medusa.phys.uwm.edu (129.89.201.244) from 129.89.200.133
> : 56(84) bytes of data.
> 64 bytes from storage1.medusa.phys.uwm.edu (129.89.201.244): icmp_seq=1
> ttl=255 time=0.197 ms
> 64 bytes from storage1.medusa.phys.uwm.edu (129.89.201.244): icmp_seq=2
> ttl=255 time=0.264 ms
> ....
> --- storage1.medusa.phys.uwm.edu ping statistics ---
> 26 packets transmitted, 26 received, 0% loss, time 25250ms
> rtt min/avg/max/mdev = 0.156/0.230/0.499/0.063 ms
>
> so 230 usec (average) x 30,000 = 7 seconds
>
> OK, so if all is well, then if I run the code locally on the NFS server
> itself (with disk cache buffers all dirty) it should take around 7
> seconds less time than if I run it on an NFS client.
>
> I'll check the numbers and report back.
>
> Thanks again for the help. I'd not thought carefully enough about what
> the disk was really doing. The point being that reading a contiguous 6 MB
> file from the local disk only involves ~20 track-to-track seeks, which is
> negligable in comparison with what I am doing.
>
> Cheers,
> Bruce
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Linux 2.2.24-rc1
From: Alan Cox @ 2002-12-16 20:18 UTC (permalink / raw)
To: linux-kernel
Linux 2.2.24-rc1
o Fix a typo in the maintainers (James Morris)
o Dave Niemi has moved (Dave Niemi)
o Fix incorrect blocking on nonblock pipe (Pete Benie)
o Fix misidentification of some AMD processors (Bruce Robson)
o Fix a very obscure skb_realloc_headroom bug (James Morris)
o Fix warning in lance driver (Thomas Cort)
o Fix sign handling bug in pms driver (Silvio Cesare)
o Drop mmap on /proc/<pid>/mem as 2.4/2.5 did (Michal Zalewski)
(also fixes some bugs)
^ permalink raw reply
* Re: mmap() and NFS server performance
From: Matthew Mitchell @ 2002-12-16 20:04 UTC (permalink / raw)
To: trond.myklebust; +Cc: nfs
In-Reply-To: <15869.59466.167433.194706@charged.uio.no>
Trond Myklebust wrote:
>>>>>>" " == Matthew Mitchell <matthew@geodev.com> writes:
>>>>>
>
> > 1) What would you like to see, tcpdump/snoop wise, to verify
> > this?
>
> nfsstat on the client should normally tell you how often you are
> seeing RPC retransmits.
Ran the program again. In 20 minutes, around 20k total client RPC
requests, with an assortment of retrans, time, and badxid errors. I am
starting to believe that there is a problem using UDP, and that it alone
might be enough to explain the slowness. It seems to have negotiated
an 8k transfer size. Reasonable?
> > 2) Could UDP service really be causing this order of magnitude
> > slowdown?
>
> Certainly: retransmissions follow an *exponential* backoff rule. For
> that reason, it doesn't take a very high percentage of retransmissions
> before you see a large impact.
Seems to be borne out by the evidence.
> > 3) Is TCP server code "ready enough" for production use? In
> > our case we
> > don't mind some occasional bugs, but it needs to be able to
> > stay working under reasonable load for a day or so at a time
> > for us to get anything done ("Stale NFS file handle" is a
> > scourge...).
>
> That is more of a question for Neil Brown, but I personally don't have
> any particularly bad experiences to report.
Any particularly *good* ones? :) Would you recommend the 2.4.20 set, or
some additional patches? I will probably install the new kernel when we
get a little downtime later this week (and then I will promptly go on
vacation; hope it stays up! ha!).
Thanks for the suggestions and assistance. I'll report back with TCP
info for anyone who is interested.
--
Matthew Mitchell
Systems Programmer/Administrator matthew@geodev.com
Geophysical Development Corporation phone 713 782 1234
1 Riverway Suite 2100, Houston, TX 77056 fax 713 782 1829
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: 2.5.52 and modules (lots of unresolved symbols)?
From: Melchior FRANZ @ 2002-12-16 19:22 UTC (permalink / raw)
To: Alex Goddard; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50L0.0212161352240.1154-100000@dust.ebiz-gw.wintek.com>
* Alex Goddard -- Monday 16 December 2002 14:54:
> On Mon, 16 Dec 2002, Melchior FRANZ wrote:
> > Why doesn't the Makefile simply define "DEPMOD = depmod"
> > instead of "DEPMOD = /sbin/depmod" (and likewise for
> > genksyms)?
>
> Ah. That makes sense. Your question is the same as mine, then. Why
> define an absolute path for depmod?
That's because people compiling the kernel as user don't have depmod
in their path. (I didn't think of that before.) Now I've installed
the module_init_tools to /sbin (while I had them in /usr/local/sbin
before, as the README suggests as variant 1a).
m.
^ permalink raw reply
* RE: problem with UN-DNAT, source is same machine
From: Ranjeet Shetye @ 2002-12-16 20:04 UTC (permalink / raw)
To: netfilter
In-Reply-To: <3DF2E9D3.6010006@technologist.com>
Is your Kernel enabled with the LOCAL_NAT option ?
"make xconfig" or "make menuconfig"
Click on "Networking options", click on "IP:NetFilter Configuration",
click on "NAT of local connections".
This is the option "CONFIG_IP_NF_NAT_LOCAL" in your .config file.
Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
771 Vaqueros Avenue
Sunnyvale CA 94085
USA
Ranjeet.Shetye@Zultys.com
http://www.zultys.com/
> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of
> Frank Wallingford
> Sent: Saturday, December 07, 2002 10:42 PM
> To: netfilter@lists.netfilter.org
> Subject: problem with UN-DNAT, source is same machine
>
>
> Here's one I can't quite wrap my head around.
>
> I got tcp port forwarding working from machine 192.168.0.100
> to machine
> 192.168.0.200 with two rules:
>
> iptables -t nat -A PREROUTING -d 192.168.0.100 -p tcp --dport 22 \
> -j DNAT --to 192.168.0.200
> iptables -t nat -A POSTROUTING -d 192.168.0.200 -p tcp --dport 22 \
> -j SNAT --to 192.168.0.100
>
> I realized that I needed the second rule because the hosts
> were on the
> same network, and without it, replies from .200 would go
> straight to the
> source.
>
> This works for all machines *except* 192.168.0.100. I wanted
> to connect
> from .100 to .100 on the port, and have it forwarded to .200.
> First, I
> realized that I needed a rule on OUTPUT, because locally generated
> packets don't traverse PREROUTE. So for testing, I flushed all the
> rules, and started over with:
>
> iptables -t nat -A OUTPUT -d 192.168.0.100 --dport 22 \
> -j DNAT --to 192.168.0.200
>
> Now, I'm only trying to get this one case working:
>
> (from machine 192.168.0.100:) ssh 192.168.0.100
>
> and I'd like it to connect to 192.168.0.200. I'm not sure why
> it isn't.
>
> I've also tried the above rule with a second SNAT rule, which
> doesn't help.
>
> From what I understand, this should be the case:
> (1) The packet starts as
> SOURCE: 192.168.0.100:port_a (some random port)
> DEST: 192.168.0.100:22
> (2) While traversing the OUTPUT chain in the NAT table, it's changed:
> SOURCE: 192.168.0.100:port_a
> DEST: 192.168.0.200:22
> (3) The packet is sent out
> (4) Host 192.168.0.200 sees it and sends the reply
> SOURCE: 192.168.0.200:22
> DEST: 192.168.0.100:port_a
> (5) The packet arrives, and is un-snat'd:
> SOURCE: 192.168.0.100:22
> DEST: 192.168.0.100:port_a
> (6) The local process sees a reply from the local machine,
> and accepts it.
>
> What's actually happening is that it's getting as far as (4), and the
> reply comes in, but the local process doesn't accept it. I'm guessing
> this is because it wasn't un-snat'd correctly, or I'm doing
> something wrong.
>
> I've also tried a few permutations of putting 0 in
> /proc/sys/net/ipv4/conf/eth0/rp_filter, in case something weird was
> happening there.
>
>
> I would be grateful if anyone had any insight into why this doesn't
> work, what I'm doing wrong, or how to forward a tcp port from
> machine A
> to machine B and have it work when the packets originate from
> machine A
> itself.
>
> Thanks,
>
> --
> ----------------------------------
> Frank Wallingford
> frank.wallingford@technologist.com
>
>
^ permalink raw reply
* [PATCH] Remove bogus AGP/DRM assumptions
From: Bjorn Helgaas @ 2002-12-16 20:09 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Dave Jones, linux-kernel
AGP/DRM currently assume that GATT entries can be converted
to physical addresses with a simple mask. Additionally, agpgart
assumes in a couple places that the mask is ~0xfff, i.e., that
all the GART control bits are in the low 12 bits. Both assumptions
are bogus, so:
Make agp_memory.memory[] (exported from agpgart to DRM) contain physical
addresses, not GATT entries.
DRM assumes agp_memory contains GATT entries, and it converts them to
physical addresses with "paddr = agp_memory.memory[i] & mask". 460GX
requires both a shift and a mask, so exporting plain physical addresses
and a mask of ~0UL allows agpgart to add 460GX support without requiring
DRM interface changes.
Applies to 2.4 BitKeeper tree.
--- linux-2.4/drivers/char/agp/agp.h 2002-09-17 11:36:30.000000000 -0600
+++ linux-2.4-agp/drivers/char/agp/agp.h 2002-12-16 12:33:22.000000000 -0700
@@ -87,6 +87,7 @@
u32 *gatt_table;
u32 *gatt_table_real;
unsigned long scratch_page;
+ unsigned long scratch_page_real;
unsigned long gart_bus_addr;
unsigned long gatt_bus_addr;
u32 mode;
@@ -99,7 +100,6 @@
int needs_scratch_page;
int aperture_size_idx;
int num_aperture_sizes;
- int num_of_masks;
int capndx;
int cant_use_aperture;
--- linux-2.4/drivers/char/agp/agpgart_be.c 2002-12-16 10:44:20.000000000 -0700
+++ linux-2.4-agp/drivers/char/agp/agpgart_be.c 2002-12-16 12:33:22.000000000 -0700
@@ -209,7 +209,6 @@
}
if (curr->page_count != 0) {
for (i = 0; i < curr->page_count; i++) {
- curr->memory[i] &= ~(0x00000fff);
agp_bridge.agp_destroy_page((unsigned long)
phys_to_virt(curr->memory[i]));
}
@@ -262,10 +261,7 @@
agp_free_memory(new);
return NULL;
}
- new->memory[i] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new->memory[i]),
- type);
+ new->memory[i] = virt_to_phys((void *) new->memory[i]);
new->page_count++;
}
@@ -311,9 +307,6 @@
int agp_copy_info(agp_kern_info * info)
{
- unsigned long page_mask = 0;
- int i;
-
memset(info, 0, sizeof(agp_kern_info));
if (agp_bridge.type == NOT_SUPPORTED) {
info->chipset = agp_bridge.type;
@@ -329,11 +322,7 @@
info->max_memory = agp_bridge.max_memory_agp;
info->current_memory = atomic_read(&agp_bridge.current_memory_agp);
info->cant_use_aperture = agp_bridge.cant_use_aperture;
-
- for(i = 0; i < agp_bridge.num_of_masks; i++)
- page_mask |= agp_bridge.mask_memory(page_mask, i);
-
- info->page_mask = ~page_mask;
+ info->page_mask = ~0UL;
return 0;
}
@@ -731,7 +720,8 @@
mem->is_flushed = TRUE;
}
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
- agp_bridge.gatt_table[j] = mem->memory[i];
+ agp_bridge.gatt_table[j] =
+ agp_bridge.mask_memory(mem->memory[i], mem->type);
}
agp_bridge.tlb_flush(mem);
@@ -976,7 +966,8 @@
CACHE_FLUSH();
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
OUTREG32(intel_i810_private.registers,
- I810_PTE_BASE + (j * 4), mem->memory[i]);
+ I810_PTE_BASE + (j * 4),
+ agp_bridge.mask_memory(mem->memory[i], mem->type));
}
CACHE_FLUSH();
@@ -1042,10 +1033,7 @@
agp_free_memory(new);
return NULL;
}
- new->memory[0] =
- agp_bridge.mask_memory(
- virt_to_phys((void *) new->memory[0]),
- type);
+ new->memory[0] = virt_to_phys((void *) new->memory[0]);
new->page_count = 1;
new->num_scratch_pages = 1;
new->type = AGP_PHYS_MEMORY;
@@ -1079,7 +1067,6 @@
intel_i810_private.i810_dev = i810_dev;
agp_bridge.masks = intel_i810_masks;
- agp_bridge.num_of_masks = 2;
agp_bridge.aperture_sizes = (void *) intel_i810_sizes;
agp_bridge.size_type = FIXED_APER_SIZE;
agp_bridge.num_aperture_sizes = 2;
@@ -1282,7 +1269,8 @@
CACHE_FLUSH();
for (i = 0, j = pg_start; i < mem->page_count; i++, j++)
- OUTREG32(intel_i830_private.registers,I810_PTE_BASE + (j * 4),mem->memory[i]);
+ OUTREG32(intel_i830_private.registers,I810_PTE_BASE + (j * 4),
+ agp_bridge.mask_memory(mem->memory[i], mem->type));
CACHE_FLUSH();
@@ -1343,7 +1331,7 @@
return(NULL);
}
- nw->memory[0] = agp_bridge.mask_memory(virt_to_phys((void *) nw->memory[0]),type);
+ nw->memory[0] = virt_to_phys((void *) nw->memory[0]);
nw->page_count = 1;
nw->num_scratch_pages = 1;
nw->type = AGP_PHYS_MEMORY;
@@ -1359,7 +1347,6 @@
intel_i830_private.i830_dev = i830_dev;
agp_bridge.masks = intel_i810_masks;
- agp_bridge.num_of_masks = 3;
agp_bridge.aperture_sizes = (void *) intel_i830_sizes;
agp_bridge.size_type = FIXED_APER_SIZE;
agp_bridge.num_aperture_sizes = 2;
@@ -1841,7 +1828,6 @@
static int __init intel_generic_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) intel_generic_sizes;
agp_bridge.size_type = U16_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -1874,7 +1860,6 @@
static int __init intel_815_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) intel_815_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 2;
@@ -1907,7 +1892,6 @@
static int __init intel_820_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) intel_8xx_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -1940,7 +1924,6 @@
static int __init intel_830mp_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) intel_830mp_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 4;
@@ -1972,7 +1955,6 @@
static int __init intel_840_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) intel_8xx_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -2005,7 +1987,6 @@
static int __init intel_845_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) intel_8xx_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -2038,7 +2019,6 @@
static int __init intel_850_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) intel_8xx_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -2071,7 +2051,6 @@
static int __init intel_860_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) intel_8xx_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -2191,7 +2170,6 @@
static int __init via_generic_setup (struct pci_dev *pdev)
{
agp_bridge.masks = via_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) via_generic_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -2305,7 +2283,6 @@
static int __init sis_generic_setup (struct pci_dev *pdev)
{
agp_bridge.masks = sis_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) sis_generic_sizes;
agp_bridge.size_type = U8_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -2643,7 +2620,8 @@
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
addr = (j * PAGE_SIZE) + agp_bridge.gart_bus_addr;
cur_gatt = GET_GATT(addr);
- cur_gatt[GET_GATT_OFF(addr)] = mem->memory[i];
+ cur_gatt[GET_GATT_OFF(addr)] =
+ agp_bridge.mask_memory(mem->memory[i], mem->type);
}
agp_bridge.tlb_flush(mem);
return 0;
@@ -2689,7 +2667,6 @@
static int __init amd_irongate_setup (struct pci_dev *pdev)
{
agp_bridge.masks = amd_irongate_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) amd_irongate_sizes;
agp_bridge.size_type = LVL2_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -2790,7 +2767,7 @@
}
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
- addr = mem->memory[i];
+ addr = agp_bridge.mask_memory(mem->memory[i], mem->type);
tmp = addr;
BUG_ON(tmp & 0xffffff0000000ffc);
@@ -3155,7 +3132,6 @@
static int __init amd_8151_setup (struct pci_dev *pdev)
{
agp_bridge.masks = amd_8151_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) amd_8151_sizes;
agp_bridge.size_type = U32_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -3393,7 +3369,6 @@
static int __init ali_generic_setup (struct pci_dev *pdev)
{
agp_bridge.masks = ali_generic_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) ali_generic_sizes;
agp_bridge.size_type = U32_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -3807,7 +3782,8 @@
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
addr = (j * PAGE_SIZE) + agp_bridge.gart_bus_addr;
cur_gatt = SVRWRKS_GET_GATT(addr);
- cur_gatt[GET_GATT_OFF(addr)] = mem->memory[i];
+ cur_gatt[GET_GATT_OFF(addr)] =
+ agp_bridge.mask_memory(mem->memory[i], mem->type);
}
agp_bridge.tlb_flush(mem);
return 0;
@@ -3964,7 +3940,6 @@
serverworks_private.svrwrks_dev = pdev;
agp_bridge.masks = serverworks_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.aperture_sizes = (void *) serverworks_sizes;
agp_bridge.size_type = LVL2_APER_SIZE;
agp_bridge.num_aperture_sizes = 7;
@@ -4362,7 +4337,6 @@
static int __init hp_zx1_setup (struct pci_dev *pdev)
{
agp_bridge.masks = hp_zx1_masks;
- agp_bridge.num_of_masks = 1;
agp_bridge.dev_private_data = NULL;
agp_bridge.size_type = FIXED_APER_SIZE;
agp_bridge.needs_scratch_page = FALSE;
@@ -5083,17 +5057,17 @@
}
if (agp_bridge.needs_scratch_page == TRUE) {
- agp_bridge.scratch_page = agp_bridge.agp_alloc_page();
+ unsigned long addr;
+ addr = agp_bridge.agp_alloc_page();
- if (agp_bridge.scratch_page == 0) {
+ if (addr == 0) {
printk(KERN_ERR PFX "unable to get memory for "
"scratch page.\n");
return -ENOMEM;
}
+ agp_bridge.scratch_page_real = virt_to_phys((void *) addr);
agp_bridge.scratch_page =
- virt_to_phys((void *) agp_bridge.scratch_page);
- agp_bridge.scratch_page =
- agp_bridge.mask_memory(agp_bridge.scratch_page, 0);
+ agp_bridge.mask_memory(agp_bridge.scratch_page_real, 0);
}
size_value = agp_bridge.fetch_size();
@@ -5135,9 +5109,8 @@
err_out:
if (agp_bridge.needs_scratch_page == TRUE) {
- agp_bridge.scratch_page &= ~(0x00000fff);
agp_bridge.agp_destroy_page((unsigned long)
- phys_to_virt(agp_bridge.scratch_page));
+ phys_to_virt(agp_bridge.scratch_page_real));
}
if (got_gatt)
agp_bridge.free_gatt_table();
@@ -5155,9 +5128,8 @@
vfree(agp_bridge.key_list);
if (agp_bridge.needs_scratch_page == TRUE) {
- agp_bridge.scratch_page &= ~(0x00000fff);
agp_bridge.agp_destroy_page((unsigned long)
- phys_to_virt(agp_bridge.scratch_page));
+ phys_to_virt(agp_bridge.scratch_page_real));
}
}
^ permalink raw reply
* Re: increase base memory
From: Bart Oldeman @ 2002-12-16 20:01 UTC (permalink / raw)
To: linux-msdos
In-Reply-To: <E18O0m8-0000LK-00@seasip.demon.co.uk>
On Mon, 16 Dec 2002, John Elliott wrote:
> Well, at least since the EGA. I suppose if DOSEMU emulated an MDA or a
> CGA, then it would make sense to use the memory up to B000:0 or B800:0
> respectively. On an original XT, it was even possible to do this in
> hardware:
> <ftp://ftp.simtel.net/pub/simtelnet/msdos/info/896k-mem.txt>
right, and this is also true if you run console DOSEMU and lie to it that
you use a CGA graphics card, ie. $_video = "cga", and remove that 640k
check in the parser. Caveat emptor -- your video BIOS might NOT like
this, weird things my happen, and I haven't tried it.
as for xdosemu: it uses vgaemu and I don't think that can be switched off
easily. vgaemu pretty much assumes that it can r/w protect all pages from
0xa000:0 up to 0xc000:0.
Now if you run dosemu in terminal mode you could go up to 736k (b800), and
if you run dosemu in "dumb" mode, well, f000 is even possible, ie., 960k,
if you disable EMS too.
Bart
^ permalink raw reply
* Re: 2 (minor) Alpha probs in 2.5.51
From: Cort Dougan @ 2002-12-16 20:02 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: rth, linux-kernel
In-Reply-To: <20021216124937.GE709@gallifrey>
I had a DS10 here that had, what appeared to be, a bad crystal. The clock
would start at about 1/2 to 3/4 the expected clock rate and over about 20
minutes would move towards what it should be at. It appeared to overshoot
the right clock-rate and then below until the oscillations would dampen
down to the correct rate.
I was doing RTLinux work on it so a bad clock wasn't acceptable. It lives
in the garage now since I had a another DS10 that worked right. I never
found what was actually going wrong with it or found a fix.
I would argue, though, that the Alpha clock itself is a crazy thing and
shouldn't be expected to work right :)
} * Richard Henderson (rth@twiddle.net) wrote:
} > > arch/alpha/kernel/built-in.o(.data+0x3038): undefined reference to
} > > `cia_bwx_inw'
} >
} > Fixed in current TOT.
}
} Great.
}
} > > Unknown HZ value! (831) Assume 1024.
}
} > Dunno. Could be your clock chip is going bad.
}
} Don't think so; with 2.4.19 it seems to be fine, and it returns to the
} low value after restarting a kernel from MILO even without powering the
} machine down or returning to AlphaBIOS.
}
} Dave
}
} ---------------- Have a happy GNU millennium! ----------------------
} / Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
} \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
} \ _________________________|_____ http://www.treblig.org |_______/
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" 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.tux.org/lkml/
^ permalink raw reply
* RE: Unable to mount root fs on 01:00 ...
From: Jean-Denis Boyer @ 2002-12-16 19:59 UTC (permalink / raw)
To: James Don; +Cc: Embedded Linux PPC List
James,
> Kernel panic: VFS: Unable to mount root fs on 01:00
Did you include EXT2 file system in your kernel image?
If not, you would obtain this error.
Regards,
--------------------------------------------
Jean-Denis Boyer, B.Eng., Technical Leader
Mediatrix Telecom Inc.
4229 Garlock Street
Sherbrooke (Québec)
J1L 2C8 CANADA
(819)829-8749 x241
--------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: dosemu 1.1.3.9 user report
From: Stas Sergeev @ 2002-12-16 19:58 UTC (permalink / raw)
To: linux-msdos
Hello.
Peter Jay Salzman wrote:
> IIRC, there was talk about important dosemu related patches that are
> present in the most recent kernels. i think it was said that the
> patches have been in the ac kernels for awhile, but have just recently
> made it into the vanilla 2.4 kernels.
Generally that patches are needed if
you have a "Segmentation fault" crash
without a "(core dumped)" when dosemu
is not in DPMI mode.
Also if you are going to do some weird
thing like starting WinNT installer
under dosemu, you'll need one of those
patches.
Another one is required if you have
problems using a direct hardware access
under dosemu (this one was even considered
a security-related by RedHat:
http://rhn.redhat.com/errata/RHSA-2002-158.html
)
There were also some other work, but in
general (unless the specified sympthomes
are matched) kernel upgrade may not be
necessary to get one or another program
to work under dosemu.
^ 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.