* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Linus Torvalds @ 2003-01-09 23:35 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Benjamin Herrenschmidt, Alan Cox, Grant Grundler, Paul Mackerras,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <20030110021904.A15863@localhost.park.msu.ru>
On Fri, 10 Jan 2003, Ivan Kokshaysky wrote:
>
> PCI-PCI, PCI-ISA bridges - probably, but not host bridges. On x86 they
> often have quite a few BARs, like AGP window, AGP MMIO, power management
> etc., which we cannot ignore.
Oh, but we _can_ ignore it.
All those things are stuff that if the kernel doesn't use them, the kernel
doesn't even need to know they are there.
Sure, if we support AGP, we need to see the aperture size etc, but then
we'd have the AGP driver just do the "pci_enable_dev()" thing to work it
out.
The only real reason to worry about BAR sizing is really to do resource
discovery in order to make sure that out bridges have sufficiently big
windows for the IO regions. Agreed?
And that should be a non-issue especially on a host bridge, since we
almost certainly don't want to reprogram the bridge windows there anyway.
So I'd like to make the _default_ be to probe the minimal possible,
_especially_ for host bridges. Then, the PCI quirks could be used to
expand on that default.
Linus
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: yodaiken @ 2003-01-10 0:02 UTC (permalink / raw)
To: Richard Stallman; +Cc: yodaiken, billh, mark, lm, linux-kernel, paul, riel
In-Reply-To: <E18Wlrd-0000Po-00@fencepost.gnu.org>
On Thu, Jan 09, 2003 at 06:13:29PM -0500, Richard Stallman wrote:
> Just for the record, "operating system", and "kernel" are used as
> synonyms in the research literature.
>
> The term "operating system" has been used in both ways for a long
> time. When people speak about the "Linux operating system," most of
> them mean the larger GNU/Linux system--they are not using "operating
> system" to mean "kernel".
My point was just to note that people who look for information about emacs
or gcc in the proceedings of the OSDI or SIGOPS Symposium are going to
be disappointed.
> If you use some other term instead of "operating system" for the
> larger collection of software, it might remove one cause of confusion.
Programming environment. I say "Gnu tools" .
> That won't eliminate the question of what this collection's name
> should properly be, or correct the misinformation about how it was
> developed and by whom.
The bad news is that many of our customers now ask us if we support
"8.0" or "7.3". For them "Red Hat" is the name of the system. Bob Young's
ketchup vision has absorbed the world.
I'm sympathetic, but if there is anyone out there who has contributed
free software and gets full credit and no hate mail, I'd be very surprised.
Envy is emulation adapted to the meanest capacity.
Ambrose Bierce
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
1+ 505 838 9109
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Jeff V. Merkey @ 2003-01-10 1:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, jmerkey
In-Reply-To: <20030109224616.GA6282@gtf.org>
On Thu, Jan 09, 2003 at 05:46:16PM -0500, Jeff Garzik wrote:
> On Thu, Jan 09, 2003 at 04:45:34PM -0700, Jeff V. Merkey wrote:
> >
> >
> > Jeff,
> >
> > They only have to provide it if someone asks for it. I suggest sending them
> > a request asking for it to be disclosed and copy LKML on the request.
>
> I had hoped that a member in good standing of the Linux community would
> not put such roadblocks in place. :(
Jeff,
I do not understand what this means. Just because they did not volunteer it
does not imply some sort of conspiracy. There are a lot of patches I make
locally for my work, but I don't just throw everyone of them out to the
whole planet since a lot of them would probably get rejected, and most folks
probably could care less. At any rate, I was not being an obstructist
or anything. Perhaps they overlooked it or perhaps it's available
somewhere else. Simplest approach is always the best -- just ask them
and post to LKML so they know other folks are probably interested.
Some of the patches I;ve made to Alan's code I am certain he would look
at and say something like "well there's goes Jeff again smoking his
pipe" or something -- but of course only in the nicest sort of way.
:-)
Jeff
>
>
> > Jeff
> > (a great name to have)
>
> agreed :)
>
> Jeff
>
>
>
> -
> 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: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Vlad@Vlad.geekizoid.com @ 2003-01-10 0:12 UTC (permalink / raw)
To: rms; +Cc: mark, lm, linux-kernel, paul, riel, billh
In-Reply-To: <E18WlrH-0000NO-00@fencepost.gnu.org>
Double Plus Good Richard, Double Plus Good.
"Withers, however, was already an unperson. He did not exist: he had never
existed." -- George Orwell's 1984
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Richard Stallman
Sent: Thursday, January 09, 2003 5:13 PM
To: billh@gnuppy.monkey.org
Cc: mark@mark.mielke.cc; lm@bitmover.com; linux-kernel@vger.kernel.org;
paul@clubi.ie; riel@conectiva.com.br; billh@gnuppy.monkey.org
Subject: Re: Why is Nvidia given GPL'd code to use in closed source
drivers?
There is no such thing as an open source community. The people who
founded the open source movement in 1998, and the people who support
it now, are part of the free software community. (We in the free
software movement built the community in the 80s with our determined
effort.)
^ permalink raw reply
* Re: detecting hyperthreading in linux 2.4.19
From: James Cleverdon @ 2003-01-10 0:16 UTC (permalink / raw)
To: John Bradford; +Cc: lunz, linux-kernel
In-Reply-To: <200301092154.h09Ls5SX005123@darkstar.example.net>
On Thursday 09 January 2003 01:54 pm, John Bradford wrote:
> > > Is there a way for a userspace program running on linux 2.4.19 to tell
> > > the difference between a single hyperthreaded xeon P4 with HT enabled
> > > and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos
> > > for the two cases are indistinguishable.
> >
> > I don't know of any way to do this in userland. The whole point is that
> > the sibling processors are supposed to look like real ones.
> >
> > You _could_ try running two processes simultaneously in tight spin loops
> > for 100 million cycles and comparing the amount of real time consumed.
> > That would be rather unreliable and kludgey though.
>
> If /proc/interrupts shows a processor is handling interrupts then it
> is definitely a 'real' one. If it isn't handling interrupts, it may
> or may not be a 'real' one. That's another unreliable and kludgey way
> to tell the difference :-).
>
> John.
> -
Not quite. The "logical" or "sibling" processor has its own local APIC. This
is necessary to send it the Startup IPI and soft IPIs while the system is
running.
However, it is a full function APIC and can receive I/O interrupts. I have
seen this happen many times.
--
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
^ permalink raw reply
* Configuration Questions
From: Brad Morgan @ 2003-01-10 0:11 UTC (permalink / raw)
To: netfilter
In-Reply-To: <200301090258.04071.netfilter@newkirk.us>
I'm doing some volunteer work for a non-profit client that wants to add a
firewall to the following configuration:
T1 to outside --- Cisco 2600 router --- LAN
The LAN has 3 subnets, a.b.c.d/25, d.e.f.g/25, and just recently 10.0.h.i/16
which is NATed in the Cisco router. The first two subnets are public IP
addresses. Although the machines on the LAN have public IP addresses, there
are no "known" public services being offered.
I believe the firewall would be added between the Cisco 2600 router and the
LAN like this:
T1 --- Cisco 2600 --- Firewall --- LAN
The firewall will run RedHat Linux 8.0 with iptables 1.2.6a.
How do you configure the ethernet adapters to pass all the traffic for all
three subnets?
I'm assuming that the router now routes packets between 2 machines in
different subnets on the LAN. Should the firewall assume this role?
If you can point me to any documents or examples on the web that would help
me understand
how to solve this challenge I would be very grateful!
Regards,
Brad Morgan
^ permalink raw reply
* Re: detecting hyperthreading in linux 2.4.19
From: Dave Jones @ 2003-01-10 0:20 UTC (permalink / raw)
To: Jason Lunz; +Cc: linux-kernel
In-Reply-To: <slrnb1rlct.g2c.lunz@stoli.localnet>
On Thu, Jan 09, 2003 at 08:02:33PM +0000, Jason Lunz wrote:
> Is there a way for a userspace program running on linux 2.4.19 to tell
> the difference between a single hyperthreaded xeon P4 with HT enabled
> and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos
> for the two cases are indistinguishable.
Check out x86info[1]. It should do the right thing in both cases.
It counts siblings, and also checks the BIOS MP table.
Dave
[1] http://www.codemonkey.org.uk/x86info/
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: William Lee Irwin III @ 2003-01-10 0:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chris Wood, linux-kernel
In-Reply-To: <3E1DD913.2571469F@digeo.com>
On Thu, Jan 09, 2003 at 12:18:27PM -0800, Andrew Morton wrote:
> These numbers are a little odd. You seem to have only lost 200M of
> lowmem to buffer_heads. Bill, what's your take on this?
He's really low on lowmem. It's <= 16GB or so so mem_map is near-
irrelevant, say 60MB.
My interpretation of the numbers is as follows, where pae_pmd and
kernel_stack are both guessed from pae_pgd:
buffer_head: 166994KB 183768KB 90.87
pae_pmd: 21576KB 21576KB 100.0
kernel_stack: 14384KB 14384KB 100.0
inode_cache: 6904KB 10377KB 66.52
filp: 6539KB 6547KB 99.87
vm_area_struct: 4897KB 4897KB 100.0
size-4096: 3924KB 4044KB 97.3
size-256: 2137KB 2137KB 100.0
signal_act: 1966KB 1966KB 100.0
dentry_cache: 747KB 1758KB 42.47
sock: 1368KB 1368KB 100.0
size-1024: 1080KB 1080KB 100.0
files_cache: 738KB 738KB 100.0
size-2048: 624KB 684KB 91.22
size-64: 323KB 525KB 61.69
size-32: 158KB 445KB 35.54
size-512: 416KB 416KB 100.0
mm_struct: 405KB 405KB 100.0
size-128: 356KB 356KB 100.0
skbuff_head_cache: 171KB 255KB 67.15
ip_dst_cache: 240KB 240KB 100.0
file_lock_cache: 166KB 191KB 87.5
journal_head: 77KB 176KB 43.99
fs_cache: 113KB 123KB 92.3
pae_pgd: 112KB 112KB 100.0
blkdev_requests: 96KB 101KB 94.81
size-16384: 80KB 80KB 100.0
cdev_cache: 45KB 47KB 96.15
arp_cache: 29KB 45KB 64.44
size-8192: 40KB 40KB 100.0
names_cache: 32KB 32KB 100.0
size-32768: 32KB 32KB 100.0
tcp_bind_bucket: 21KB 28KB 77.67
sigqueue: 26KB 26KB 100.0
tcp_tw_bucket: 18KB 18KB 100.0
uid_cache: 15KB 17KB 89.46
tcp_open_request: 15KB 15KB 100.0
kmem_cache: 15KB 15KB 100.0
inet_peer_cache: 6KB 14KB 46.12
size-128(DMA): 0KB 7KB 3.33
size-32(DMA): 2KB 7KB 29.31
ip_fib_hash: 0KB 7KB 6.25
bdev_cache: 0KB 7KB 7.75
mnt_cache: 1KB 7KB 15.51
dnotify_cache: 4KB 6KB 71.68
fasync_cache: 4KB 6KB 68.25
revoke_table: 0KB 2KB 2.80
== grand total of 253.015MB, fragmentation included.
+ 60MB mem_map
== grand total of 313MB or so
Either pollwait tables (invisible in 2.4 and 2.5), kernel stacks of
threads (which don't get pae_pgd's and are hence invisible in 2.4
and 2.5), or pagecache, with a much higher likelihood of pagecache.
Or there might be dark matter in the universe, and he's being bitten by
unaccounted !__GFP_HIGHMEM allocations, e.g. stock 2.4.x pagetables,
which aren't predictable from pae_pgd etc. highpte of any flavor (aa or
otherwise) should fix that. But there's no way to guess, as there's zero
2.4.x PTE accounting or even any hints from this report, like average
RSS and VSZ (which are still underestimates, as 2.4.x pagetables are
leaked over the lifetime of the process vs. 2.5.x's reap-on-munmap()).
Bill
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Adrian Bunk @ 2003-01-10 0:27 UTC (permalink / raw)
To: Philip Dodd; +Cc: Jeff Garzik, linux-kernel
In-Reply-To: <3E1DFB8E.9050805@free.fr>
On Thu, Jan 09, 2003 at 11:45:34PM +0100, Philip Dodd wrote:
> With all due respect, I believe that the terms of the GPL only require
> them to make it available to people who have the binaries, and only then
> upon request.
>...
Why don't you _read_ the GPL instead of making wrong statements?
Section 3 clearly states that your "upon request" is wrong, the part
that matches here is:
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
> Cheers,
>
> Philip
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* RE: access memory mapped registers
From: Kerl, John @ 2003-01-10 0:18 UTC (permalink / raw)
To: 'Muaddi, Cecilia'; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
For what it's worth, I've done a couple of quick-and-dirty
devices, in the way you described (mmap from user space).
And you are right that (1) an app may not crash the kernel as
easily -- but remember that a root application can mmap
*anything*, and (2) you don't have to reboot the kernel to try a
code change. Also (3) I found it easy to code, and (4) I didn't
have to mess with IRQs -- meaning that the person who wrote
the FPGA code had less work to do, & he was already pressed for
time. (Also I've a "proper" device driver, but it was a very
simple one.)
For one project, the mmap worked fine. For the other project,
it also worked OK (the demo ran, and the vendor was pleased,
and the project was done start-to-finish, PPC/Linux & FPGA/VHDL
etc., in a very short amount of time), but it made some coding
awkward, and it affected performance. In particular, my
application was in a loop listening for one of four things:
* Keystrokes at the console
* A PF_UNIX (local) socket
* A PF_INET (UDP) socket
* A packet received at my device (an FPGA)
Thanks to the design of Unix, I could select() for the
first three, and the OS would tell me when any of them
was ready. But since I did the quick-and-dirty mmap()
thing for my FPGA, I had to poll it by reading the mmap.
So I ended up choosing which to service more quickly --
the longer I sat in select(), the less time between checks
to the FPGA, increasing latency there. The less time I sat
in select(), the more CPU time I ate up, and also my latency
worsened for servicing network packets.
Wolfgang can no doubt give you many more reasons, perhaps
some philosophical, to do a "real" driver. However, the above
example is a practical one -- performance.
-----Original Message-----
From: Muaddi, Cecilia [mailto:cecilia.muaddi@alloptic.com]
Sent: Thursday, January 09, 2003 5:06 PM
To: 'Wolfgang Denk'
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: RE: access memory mapped registers
Sorry, forgot to mentioned those devices are T1 framers, custom FPGA, and
ethernet switching chips.
Don't know if that makes any difference.
-Cecilia
-----Original Message-----
From: Muaddi, Cecilia
Sent: Thursday, January 09, 2003 4:04 PM
To: 'Wolfgang Denk'; Muaddi, Cecilia
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: RE: access memory mapped registers
why would it be better to use the device driver than via the mmap from user
space?
one of my criteria was to make sure no software mistake will cause the
kernel to hang, as
in the case of vxWorks we are running. So, if I implement my access to the
device
in the device driver, doesn't that means if there are problem with the
device driver
portion, i will cause the kernel to hang? Furthermore, any enhancement to
the device
driver will require me to reinstall the kernel? whereas if all my user
space
application handles the access to those devices, I can stop the user space
application,
update it with the new application without requiring the system to reboot?
Sorry if those sounded like silly questions.
Thanks
Cecilia
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Thursday, January 09, 2003 3:14 PM
To: Muaddi, Cecilia
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: access memory mapped registers
In message <885489B3B89FB6449F93E525DF78777F06453B@srvnt506.ALLOPTIC.COM>
you wrote:
>
> I will like to access some memory mapped registers through user space
> applications.
> Do i just use the "mmap" function calls to map the physical memory to my
> user space?
You don't. Design a proper device driver interface instead.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
By the way, ALL software projects are done by iterative prototyping.
Some companies call their prototypes "releases", that's all.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Aaron T Porter @ 2003-01-10 0:31 UTC (permalink / raw)
To: Jeff V. Merkey, Jeff Garzik; +Cc: linux-kernel
In-Reply-To: <20030109164534.A6653@vger.timpanogas.org>
On Thu, Jan 09, 2003 at 04:45:34PM -0700, Jeff V. Merkey wrote:
> They only have to provide it if someone asks for it. I suggest sending them
> a request asking for it to be disclosed and copy LKML on the request.
Further, they only have to provide the source to those they
distribute the software to. So go buy a copy, ask for the source then come
share with us too.
^ permalink raw reply
* Re: access memory mapped registers
From: Wolfgang Denk @ 2003-01-10 0:25 UTC (permalink / raw)
To: Muaddi, Cecilia; +Cc: linuxppc-embedded
In-Reply-To: <885489B3B89FB6449F93E525DF78777F06453E@srvnt506.ALLOPTIC.COM>
In message <885489B3B89FB6449F93E525DF78777F06453E@srvnt506.ALLOPTIC.COM> you wrote:
> why would it be better to use the device driver than via the mmap from user
> space?
Reliability, robustnes, clean design, ...
Why do we have a separation into kernel and user space at all?
> one of my criteria was to make sure no software mistake will cause the
> kernel to hang, as
> in the case of vxWorks we are running. So, if I implement my access to the
Then don't weaken the memory protection of the Unix design.
> device
> in the device driver, doesn't that means if there are problem with the
> device driver
> portion, i will cause the kernel to hang? Furthermore, any enhancement to
Don't you think that an application process that will write random
data to your hardware will have a much higher potential to cause harm
than a carefully designed, implementred, reviewed and tested device
driver?
> driver will require me to reinstall the kernel? whereas if all my user
> space
> application handles the access to those devices, I can stop the user space
> application,
> update it with the new application without requiring the system to reboot?
You can dynamically load and unload device drivers.
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"Wish not to seem, but to be, the best." - Aeschylus
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* 2.5.55: Two global symbols driver_lock
From: Adrian Bunk @ 2003-01-10 0:35 UTC (permalink / raw)
To: Simon G. Vogl, linux-i2c, linux-net; +Cc: linux-kernel
I got the following compile error in 2.5.55:
<-- snip -->
...
ld -m elf_i386 -r -o drivers/built-in.o drivers/pci/built-in.o
drivers/acpi/built-in.o drivers/pnp/built-in.o drivers/serial/built-in.o
drivers/parport/built-in.o drivers/base/built-in.o
drivers/char/built-in.o drivers/block/built-in.o drivers/misc/built-in.o
drivers/net/built-in.o drivers/media/built-in.o drivers/atm/built-in.o
drivers/ide/built-in.o drivers/scsi/built-in.o
drivers/ieee1394/built-in.o drivers/cdrom/built-in.o
drivers/video/built-in.o drivers/mtd/built-in.o
drivers/pcmcia/built-in.o drivers/block/paride/built-in.o
drivers/usb/built-in.o drivers/input/built-in.o
drivers/input/gameport/built-in.o drivers/input/serio/built-in.o
drivers/message/built-in.o drivers/i2c/built-in.o
drivers/telephony/built-in.o drivers/md/built-in.o
drivers/bluetooth/built-in.o drivers/hotplug/built-in.o
drivers/mca/built-in.o
drivers/i2c/built-in.o(.data+0x14): multiple definition of `driver_lock'
drivers/net/built-in.o(.data+0xcf14): first defined here
ld: Warning: size of symbol `driver_lock' changed from 4 to 20 in
drivers/i2c/built-in.o
make[1]: *** [drivers/built-in.o] Error 1
<-- snip -->
The offending files are:
drivers/i2c/i2c-core.c
drivers/net/aironet4500_proc.c
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Floppy bug - And fix, kind of :-)
From: Rob Wilkens @ 2003-01-10 0:10 UTC (permalink / raw)
To: linux-kernel
Someone reported a bug in the linux.kernel newsgroup which I presumed
was somehow linked to this mailing list which I finally found my way on
to. Glad to be here.
Anyway, enough of the pleasantries. I'm a newbie to the Linux kernel,
but formerly a professional kernel developer. I left for mental health
reasons, long story.
The bug that someone reported was that when they did a "dd" using the
device "/dev/fd0u1440" and there was no disk in the drive, it would only
fail about half of the time. The rest of the tiem it would succeed,
which is bad because there was no disk and for it so succeed and not get
an ENXIO on openning the device was wrong.
I was able to reproduce this bug, and fix it, on my machine.
The fix isn't pretty, though, and it's a one line fix. I'll leave it to
others here (open for discussion) to suggest the more propper fix, after
all I am a newbie here. My fix may be fine, though. I just don't know.
Basically, the error traced back to the floppy_revalidate(kdev_t dev)
function in drivers/block/floppy.c .. There's a line in there which
reads "if (NO_GEOM) {", and my fix is to change that line to "if (1) {".
Yep, that means that the code inside that block gets executed every
time.
You see, the problem is that only when the code inside that block gets
executed, though, is there some reading done from the drive which tests
the initial drive status.
Of course, if someone is openning a special "u1440" version of the
device (minor number 28 instead of minor number 0), then there may be a
good reason that this code shouldn't be executed. I just don't know
what that is because I don't know what those special device files are
for.
If those files are to specially handle, for example, 720kb disks in a
1440kb drive, then I'm not sure this particular piece of code being
enabled will -break- that. Of course, I only can find one floppy disk,
and it's a 1440kb disk. I don't have tons of floppies hanging around.
Someone may have already addressed this issue, too. I don't know.
If anyone was interested, though, I was able to reproduce this problem
simply by not having a disk in the drive and repeatedly opening the
drive with simple test.c code (with O_WROLY|O_CREAT|O_TRUNC as dd was
using). If I openned "/dev/fd0", I would consistently get a failure as
expected, but if I openned "/dev/fd0u1440" I would less consistently get
a failure.
I haven't checked a 2.5 kernel. This was in 2.4.20.
-Rob
p.s. Sorry for the long message. I figure too much detail is better
than too little.
^ permalink raw reply
* 2.4.20 stability issues
From: Brian May @ 2003-01-10 0:27 UTC (permalink / raw)
To: selinux
Hello,
Has anybody else here used my kernel 2.4.20 source code or binary code?
I had no problems with 2.4.19, but as of 2.4.20 I seem to have
encountered some weird stability issues that I cannot put my finger on.
It only happens after an uptime of several hours (if not days; it
also depends if you count time in suspend mode or not), on my laptop
computer.
This time I noticed that ssh connections would hang; I tried restarting
ssh, but the previous process wouldn't die (for each parant sshd process,
there is a child zombie process). Typing in "killall -9 sshd" does
nothing. Pushing ctrl+alt+del does nothing. However, ironically, local
logins still work fine.
hmmm... now logouts hang. Oh well... Time to push that power switch.
So far this has only ever happened with 2.4.19, not 2.4.20. Weird.
I have compiled 2.4.20 (not my kernel binary online) with the same
configuration as 2.4.19 (evms and acl disabled, FreeSWAN and
SE-LINUX enabled).
--
Brian May <bam@snoopy.apana.org.au>
--
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: access memory mapped registers
From: Muaddi, Cecilia @ 2003-01-10 0:27 UTC (permalink / raw)
To: 'Kerl, John'; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
Given that, do you know what is the convention if I need to address the GPIO
pins in
the 860? I have some FPGA which require me to download the FPGA code
and they are controlled via JTAG from my GPIO pins out of 860. I can use
mmap to map the ppc 860 internal memory (the quick dirty way just to see if
works), or is there a driver already provided which will allow me to control
the GPIO pins from user application?
Thanks
Cecilia
-----Original Message-----
From: Kerl, John [mailto:John.Kerl@Avnet.com]
Sent: Thursday, January 09, 2003 4:19 PM
To: 'Muaddi, Cecilia'
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: RE: access memory mapped registers
For what it's worth, I've done a couple of quick-and-dirty
devices, in the way you described (mmap from user space).
And you are right that (1) an app may not crash the kernel as
easily -- but remember that a root application can mmap
*anything*, and (2) you don't have to reboot the kernel to try a
code change. Also (3) I found it easy to code, and (4) I didn't
have to mess with IRQs -- meaning that the person who wrote
the FPGA code had less work to do, & he was already pressed for
time. (Also I've a "proper" device driver, but it was a very
simple one.)
For one project, the mmap worked fine. For the other project,
it also worked OK (the demo ran, and the vendor was pleased,
and the project was done start-to-finish, PPC/Linux & FPGA/VHDL
etc., in a very short amount of time), but it made some coding
awkward, and it affected performance. In particular, my
application was in a loop listening for one of four things:
* Keystrokes at the console
* A PF_UNIX (local) socket
* A PF_INET (UDP) socket
* A packet received at my device (an FPGA)
Thanks to the design of Unix, I could select() for the
first three, and the OS would tell me when any of them
was ready. But since I did the quick-and-dirty mmap()
thing for my FPGA, I had to poll it by reading the mmap.
So I ended up choosing which to service more quickly --
the longer I sat in select(), the less time between checks
to the FPGA, increasing latency there. The less time I sat
in select(), the more CPU time I ate up, and also my latency
worsened for servicing network packets.
Wolfgang can no doubt give you many more reasons, perhaps
some philosophical, to do a "real" driver. However, the above
example is a practical one -- performance.
-----Original Message-----
From: Muaddi, Cecilia [mailto:cecilia.muaddi@alloptic.com]
Sent: Thursday, January 09, 2003 5:06 PM
To: 'Wolfgang Denk'
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: RE: access memory mapped registers
Sorry, forgot to mentioned those devices are T1 framers, custom FPGA, and
ethernet switching chips.
Don't know if that makes any difference.
-Cecilia
-----Original Message-----
From: Muaddi, Cecilia
Sent: Thursday, January 09, 2003 4:04 PM
To: 'Wolfgang Denk'; Muaddi, Cecilia
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: RE: access memory mapped registers
why would it be better to use the device driver than via the mmap from user
space?
one of my criteria was to make sure no software mistake will cause the
kernel to hang, as
in the case of vxWorks we are running. So, if I implement my access to the
device
in the device driver, doesn't that means if there are problem with the
device driver
portion, i will cause the kernel to hang? Furthermore, any enhancement to
the device
driver will require me to reinstall the kernel? whereas if all my user
space
application handles the access to those devices, I can stop the user space
application,
update it with the new application without requiring the system to reboot?
Sorry if those sounded like silly questions.
Thanks
Cecilia
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Thursday, January 09, 2003 3:14 PM
To: Muaddi, Cecilia
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: access memory mapped registers
In message <885489B3B89FB6449F93E525DF78777F06453B@srvnt506.ALLOPTIC.COM>
you wrote:
>
> I will like to access some memory mapped registers through user space
> applications.
> Do i just use the "mmap" function calls to map the physical memory to my
> user space?
You don't. Design a proper device driver interface instead.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
By the way, ALL software projects are done by iterative prototyping.
Some companies call their prototypes "releases", that's all.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Cort Dougan @ 2003-01-10 0:36 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Philip Dodd, Jeff Garzik, linux-kernel
In-Reply-To: <20030110002705.GZ6626@fs.tum.de>
If people starting doing that what would be have to argue about?
} Why don't you _read_ the GPL instead of making wrong statements?
^ permalink raw reply
* Re: lifecycle of a packet
From: Anders Fugmann @ 2003-01-10 0:33 UTC (permalink / raw)
To: Tony Clayton; +Cc: netfilter
In-Reply-To: <1042152892.3e1dfdbc6f5d1@webmail.enfusion-group.com>
Tony Clayton wrote:
<lots of info on chain traversal>
>
> This is quite interesting, and not at all what I was expecting based on
> what I'd read.
Depends on what you read :-)
>
> I have a list of questions about this behaviour, keeping in mind that
> I'm fairly new to iptables/netfilter:
>
> 1. Why does only the first packet for a TCP/IP connection seem to pass
> through the nat table? Does connection tracking take over if the packet
> is (ESTABLISHED,RELATED) and work some magic under the covers?
Yes. When you change a packet in the nat table, all following packets
are nat'ed automatically. This way you do not have to worry about
natting replys etc.
>
> 2. Why do both OUTPUT and POSTROUTING chains get traversed for packets
> that the firewall sends out? Is this useful at all?
Yes. in POSTROUTING you may not know if the pakcet has been generated
locally or not. However in the mangle-output chain you do. Another usage
that cannot be done in postrouting is alterations to the packet before
it hits the filter-output chain. The can e.g be used un conjunktion with
packet marking:
iptables -t mangle -a OUTPUT -j MARK --set-mark 0x01
iptables -t filter -a OUTPUT -m mark --mark 0x01 -j ACCEPT.
(Ok - this example is very simple, but still - its imposible without the
mangle-output chain)
>
> 3. Most of the documents I looked at were fairly old. Is there a
> somewhat recent document that perhaps might benefit from including these
> tests?
Yes. Take a look at Oskar Andreasson's excellent tutorial at:
http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html
Esp. look at the section named: "Traversing of tables and chains"
Hope it helps.
Anders Fugmann
--
Author of FIAIF
FIAIF is an intelligent firewall
http://fiaif.fugmann.dhs.org
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Brian Tinsley @ 2003-01-10 0:44 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Andrew Morton, Chris Wood, linux-kernel
In-Reply-To: <20030110002548.GG23814@holomorphy.com>
>
>
>Either pollwait tables (invisible in 2.4 and 2.5), kernel stacks of
>threads (which don't get pae_pgd's and are hence invisible in 2.4
>and 2.5), or pagecache, with a much higher likelihood of pagecache.
>
The "kernel stacks of threads" may have some bearing on my incarnation
of this problem. We have several heavily threaded Java applications
running at the time the live-locks occur. At our most problematic site,
one application has a bug that can cause hundreds of timer threads (I
mean like 800 or so!) to be "accidentally" created. This site is
scheduled for an upgrade either tonight or tomorrow, so I will leave the
system as it is and see if I can still cause the live-lock to manifest
itself after the upgrade.
--
-[========================]-
-[ Brian Tinsley ]-
-[ Chief Systems Engineer ]-
-[ Emageon ]-
-[========================]-
^ permalink raw reply
* Need to change my e-mail address
From: Robert Warner @ 2003-01-10 1:12 UTC (permalink / raw)
To: linux-mtd
Was: rwarner1@directvinternet.com
To robert.warner@sbcglobal.net
^ permalink raw reply
* Re: get_pteptr prototype
From: David Gibson @ 2003-01-10 0:42 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: paulus, devel list
In-Reply-To: <1042127751.1021.221.camel@granite.austin.ibm.com>
On Thu, Jan 09, 2003 at 09:55:40AM -0600, Hollis Blanchard wrote:
>
> On Wed, 2003-01-08 at 20:33, David Gibson wrote:
> >
> > Hmm... what's the reason that wakeup_info needs to be reserved in
> > head_4xx.S, rather than just being a normal variable in the data area
> > (which should be writable anyway)? Its not obvious to me from the
> > patch.
>
> Sorry, I was hoping the Documentation file explained it well enough. On
> wake the firmware needs to transfer control back to Linux, so the
> firmware needs to know where to jump to. The only way I could think of
> communicating that information was with a fixed memory location known to
> both the firmware and to Linux. In future processors there will be a
> scratch register (whose contents are saved during sleep) to solve this
> problem.
Ah, ok - I only skimmed the patch I'm afraid, so I didn't notice that.
> > Actually, skimming through the patch I noticed a minor nit: you only
> > have one .long in head_4xx.S reserving space for the wakeup_info
> > struct which is 3 words long. In practice the . = in the exception
> > handlers will give you plenty of space, but I think it would be good
> > form to explicitly reserve the right amount of space.
>
> It's just a (physical) pointer to the structure which is elsewhere in
> memory (actually on the stack).
Hmm... in that case, why does the pointer need to be updated at
runtime: could you just statically allocate the real structure (in the
data segment), and have the value at 0xc00000fc filled in constant at
link time.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [ramune@net-ronin.org: [PATCH] module-init-tools update]
From: carbonated beverage @ 2003-01-10 0:47 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Resend, as I didn't see this one show up on l-k.
Here's a small patch for Documentation/Changes and scripts/ver_linux
to use depmod instead of rmmod as per Rusty's suggestion.
rmmod will exec the old version of the modutils depending on the
command-line, whereas depmod will give its own version instead.
Please apply.
-- DN
Daniel
--- Documentation/Changes.old Thu Jan 9 10:51:36 2003
+++ Documentation/Changes Thu Jan 9 11:27:54 2003
@@ -52,7 +52,7 @@
o Gnu make 3.78 # make --version
o binutils 2.9.5.0.25 # ld -v
o util-linux 2.10o # fdformat --version
-o module-init-tools 0.9 # rmmod -V
+o module-init-tools 0.9 # depmod -V
o e2fsprogs 1.29 # tune2fs
o jfsutils 1.0.14 # fsck.jfs -V
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
--- scripts/ver_linux.old Thu Jan 9 10:52:10 2003
+++ scripts/ver_linux Thu Jan 9 11:27:57 2003
@@ -28,7 +28,7 @@
mount --version | awk -F\- '{print "mount ", $NF}'
-rmmod -V 2>&1 | awk 'NR==1 {print "module-init-tools ",$NF}'
+depmod -V 2>&1 | awk 'NR==1 {print "module-init-tools ",$NF}'
tune2fs 2>&1 | grep "^tune2fs" | sed 's/,//' | awk \
'NR==1 {print "e2fsprogs ", $2}'
^ permalink raw reply
* [PATCH] linux-2.5.55_timer-none_A0
From: john stultz @ 2003-01-10 0:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml
Linus, All,
Just a re-sync against 2.5.55. This patch creates an empty timer_opt
structure (timer_none) which is then used as a default initializer to
the timer pointer. This lets us avoid having to check before
dereferencing the timer in future code.
Please apply.
thanks
-john
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Thu Jan 9 15:21:21 2003
+++ b/arch/i386/kernel/time.c Thu Jan 9 15:21:21 2003
@@ -78,7 +78,8 @@
spinlock_t i8253_lock = SPIN_LOCK_UNLOCKED;
EXPORT_SYMBOL(i8253_lock);
-struct timer_opts* timer;
+extern struct timer_opts timer_none;
+struct timer_opts* timer = &timer_none;
/*
* This version of gettimeofday has microsecond resolution
diff -Nru a/arch/i386/kernel/timers/Makefile b/arch/i386/kernel/timers/Makefile
--- a/arch/i386/kernel/timers/Makefile Thu Jan 9 15:21:21 2003
+++ b/arch/i386/kernel/timers/Makefile Thu Jan 9 15:21:21 2003
@@ -2,6 +2,6 @@
# Makefile for x86 timers
#
-obj-y := timer.o timer_tsc.o timer_pit.o
+obj-y := timer.o timer_none.o timer_tsc.o timer_pit.o
obj-$(CONFIG_X86_CYCLONE) += timer_cyclone.o
diff -Nru a/arch/i386/kernel/timers/timer_none.c b/arch/i386/kernel/timers/timer_none.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/arch/i386/kernel/timers/timer_none.c Thu Jan 9 15:21:21 2003
@@ -0,0 +1,24 @@
+#include <asm/timer.h>
+
+static int init_none(void)
+{
+ return 0;
+}
+
+static void mark_offset_none(void)
+{
+ /* nothing needed */
+}
+
+static unsigned long get_offset_none(void)
+{
+ return 0;
+}
+
+
+/* tsc timer_opts struct */
+struct timer_opts timer_none = {
+ .init = init_none,
+ .mark_offset = mark_offset_none,
+ .get_offset = get_offset_none,
+};
^ permalink raw reply
* [PATCH] linux-2.5.55_delay-cleanup_A1
From: john stultz @ 2003-01-10 0:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml
In-Reply-To: <1042159743.1046.280.camel@w-jstultz2.beaverton.ibm.com>
Linus, All,
This patch applies ontop of linux-2.5.55_timer-none_A0 and tries to
cleanup the delay code by moving the timer-specific implementations into
the timer_ops struct. Thus, rather then doing:
if(x86_delay_tsc)
__rdtsc_delay(loops);
else if(x86_delay_cyclone)
__cyclone_delay(loops);
else if(whatever....
we just simply do:
timer->delay(loops);
Making it much easier to accommodate alternate time sources.
Please apply.
thanks
-john
diff -Nru a/arch/i386/kernel/timers/timer_cyclone.c b/arch/i386/kernel/timers/timer_cyclone.c
--- a/arch/i386/kernel/timers/timer_cyclone.c Thu Jan 9 15:22:13 2003
+++ b/arch/i386/kernel/timers/timer_cyclone.c Thu Jan 9 15:22:13 2003
@@ -150,7 +150,6 @@
}
-#if 0 /* XXX future work */
static void delay_cyclone(unsigned long loops)
{
unsigned long bclock, now;
@@ -162,12 +161,12 @@
now = cyclone_timer[0];
} while ((now-bclock) < loops);
}
-#endif
/************************************************************/
/* cyclone timer_opts struct */
struct timer_opts timer_cyclone = {
.init = init_cyclone,
.mark_offset = mark_offset_cyclone,
- .get_offset = get_offset_cyclone
+ .get_offset = get_offset_cyclone,
+ .delay = delay_cyclone,
};
diff -Nru a/arch/i386/kernel/timers/timer_none.c b/arch/i386/kernel/timers/timer_none.c
--- a/arch/i386/kernel/timers/timer_none.c Thu Jan 9 15:22:13 2003
+++ b/arch/i386/kernel/timers/timer_none.c Thu Jan 9 15:22:13 2003
@@ -15,10 +15,23 @@
return 0;
}
+static void delay_none(unsigned long loops)
+{
+ int d0;
+ __asm__ __volatile__(
+ "\tjmp 1f\n"
+ ".align 16\n"
+ "1:\tjmp 2f\n"
+ ".align 16\n"
+ "2:\tdecl %0\n\tjns 2b"
+ :"=&a" (d0)
+ :"0" (loops));
+}
/* tsc timer_opts struct */
struct timer_opts timer_none = {
.init = init_none,
.mark_offset = mark_offset_none,
.get_offset = get_offset_none,
+ .delay = delay_none,
};
diff -Nru a/arch/i386/kernel/timers/timer_pit.c b/arch/i386/kernel/timers/timer_pit.c
--- a/arch/i386/kernel/timers/timer_pit.c Thu Jan 9 15:22:13 2003
+++ b/arch/i386/kernel/timers/timer_pit.c Thu Jan 9 15:22:13 2003
@@ -27,6 +27,19 @@
/* nothing needed */
}
+static void delay_pit(unsigned long loops)
+{
+ int d0;
+ __asm__ __volatile__(
+ "\tjmp 1f\n"
+ ".align 16\n"
+ "1:\tjmp 2f\n"
+ ".align 16\n"
+ "2:\tdecl %0\n\tjns 2b"
+ :"=&a" (d0)
+ :"0" (loops));
+}
+
/* This function must be called with interrupts disabled
* It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
@@ -129,4 +142,5 @@
.init = init_pit,
.mark_offset = mark_offset_pit,
.get_offset = get_offset_pit,
+ .delay = delay_pit,
};
diff -Nru a/arch/i386/kernel/timers/timer_tsc.c b/arch/i386/kernel/timers/timer_tsc.c
--- a/arch/i386/kernel/timers/timer_tsc.c Thu Jan 9 15:22:13 2003
+++ b/arch/i386/kernel/timers/timer_tsc.c Thu Jan 9 15:22:13 2003
@@ -16,7 +16,6 @@
int tsc_disable __initdata = 0;
-extern int x86_udelay_tsc;
extern spinlock_t i8253_lock;
static int use_tsc;
@@ -107,6 +106,17 @@
delay_at_last_interrupt = (count + LATCH/2) / LATCH;
}
+static void delay_tsc(unsigned long loops)
+{
+ unsigned long bclock, now;
+
+ rdtscl(bclock);
+ do
+ {
+ rep_nop();
+ rdtscl(now);
+ } while ((now-bclock) < loops);
+}
/* ------ Calibrate the TSC -------
* Return 2^32 * (1 / (TSC clocks per usec)) for do_fast_gettimeoffset().
@@ -272,8 +282,6 @@
* We could be more selective here I suspect
* and just enable this for the next intel chips ?
*/
- x86_udelay_tsc = 1;
-
/* report CPU clock rate in Hz.
* The formula is (10^6 * 2^32) / (2^32 * 1 / (clocks/us)) =
* clock/second. Our precision is about 100 ppm.
@@ -310,4 +318,5 @@
.init = init_tsc,
.mark_offset = mark_offset_tsc,
.get_offset = get_offset_tsc,
+ .delay = delay_tsc,
};
diff -Nru a/arch/i386/lib/delay.c b/arch/i386/lib/delay.c
--- a/arch/i386/lib/delay.c Thu Jan 9 15:22:13 2003
+++ b/arch/i386/lib/delay.c Thu Jan 9 15:22:13 2003
@@ -15,54 +15,17 @@
#include <linux/delay.h>
#include <asm/processor.h>
#include <asm/delay.h>
+#include <asm/timer.h>
#ifdef CONFIG_SMP
#include <asm/smp.h>
#endif
-int x86_udelay_tsc = 0; /* Delay via TSC */
-
-
-/*
- * Do a udelay using the TSC for any CPU that happens
- * to have one that we trust.
- */
-
-static void __rdtsc_delay(unsigned long loops)
-{
- unsigned long bclock, now;
-
- rdtscl(bclock);
- do
- {
- rep_nop();
- rdtscl(now);
- } while ((now-bclock) < loops);
-}
-
-/*
- * Non TSC based delay loop for 386, 486, MediaGX
- */
-
-static void __loop_delay(unsigned long loops)
-{
- int d0;
- __asm__ __volatile__(
- "\tjmp 1f\n"
- ".align 16\n"
- "1:\tjmp 2f\n"
- ".align 16\n"
- "2:\tdecl %0\n\tjns 2b"
- :"=&a" (d0)
- :"0" (loops));
-}
+extern struct timer_opts* timer;
void __delay(unsigned long loops)
{
- if (x86_udelay_tsc)
- __rdtsc_delay(loops);
- else
- __loop_delay(loops);
+ timer->delay(loops);
}
inline void __const_udelay(unsigned long xloops)
diff -Nru a/include/asm-i386/timer.h b/include/asm-i386/timer.h
--- a/include/asm-i386/timer.h Thu Jan 9 15:22:13 2003
+++ b/include/asm-i386/timer.h Thu Jan 9 15:22:13 2003
@@ -14,6 +14,7 @@
int (*init)(void);
void (*mark_offset)(void);
unsigned long (*get_offset)(void);
+ void (*delay)(unsigned long);
};
#define TICK_SIZE (tick_nsec / 1000)
^ permalink raw reply
* Re: kswapd CPU usage and heavy disk IO
From: William Lee Irwin III @ 2003-01-10 0:46 UTC (permalink / raw)
To: Dieter N?tzel
Cc: Brian Tinsley, Russell Coker, ReiserFS, Rik van Riel,
Andrea Arcangeli, Linux Kernel List
In-Reply-To: <200301091742.51101.Dieter.Nuetzel@hamburg.de>
[-- Attachment #1: brief message --]
[-- Type: text/plain, Size: 1604 bytes --]
Am Donnerstag, 9. Januar 2003 17:02 schrieb Brian Tinsley:
>> I've been seeing the exact same thing on the same type of system in the
>> same situations. This has been causing all kinds of problems on our
>> clusters: the system live-locks for a minute or two, causes cluster
>> heartbeats to not be received, and falsely fails over when the system
>> recovers from the live-lock. The only thing I can find after the
>> live-lock is that the runtime for kswapd is abnormally high.
>> We started running sar (60 second collection interval) and were able to
>> capture some stats during this live-lock period. I've snipped some I
>> believe may be of interest. Note the missing stats between 03:59:43 and
>> 04:02:03
>> Oh BTW, this is on a stock 2.4.20 kernel (dual P3, 4GB), but I have seen
>> the same behavior on 2.4.19 and 2.4.17.
On Thu, Jan 09, 2003 at 05:42:51PM +0100, Dieter N?tzel wrote:
> I think you should have cc'ed Andrea Arcangeli <andrea@suse.de>,
> LKM and try 2.4.20-aa1. Are you sure it is a ReiserFS and not a
> kernel thing?
There simply aren't enough scenarios for this to be a mystery. Both
-aa and 2.5.x should have something in there for it: memclass-related
buffer_head stuff in -aa, and bh-stripping + "bh-less" operation (for
ext2) in 2.5.x + fewer (if any) bh's outside of actual dirty data.
Bloat monitoring scripts attached, which might provide somewhat more
useful output to capture, though they certainly don't eliminate the
need for /proc/meminfo logging. I'll also see if some of the accounting
patches can be backported and send those to Marcelo and Andrea.
Bill
[-- Attachment #2: bloatmon --]
[-- Type: text/plain, Size: 413 bytes --]
#!/usr/bin/awk -f
BEGIN {
printf "%18s %8s %8s %8s\n", "cache", "active", "alloc", "%util";
}
{
if ($3 != 0.0) {
pct = 100.0 * $2 / $3;
frac = (10000.0 * $2 / $3) % 100;
} else {
pct = 100.0;
frac = 0.0;
}
active = ($2 * $4)/1024;
alloc = ($3 * $4)/1024;
if ((alloc - active) < 1.0) {
pct = 100.0;
frac = 0.0;
}
printf "%18s: %8dKB %8dKB %3d.%-2d\n", $1, active, alloc, pct, frac;
}
[-- Attachment #3: bloatmeter --]
[-- Type: text/plain, Size: 133 bytes --]
#!/bin/sh
while : ; do
grep -v '^slabinfo' /proc/slabinfo \
| bloatmon \
| sort -n -k 4,4 \
| head -22
sleep 5
echo
done
[-- Attachment #4: bloatmost --]
[-- Type: text/plain, Size: 110 bytes --]
#!/bin/sh
while true
do
bloatmon < /proc/slabinfo \
| sort -rn -k 3,3 \
| head -22
sleep 60
echo
done
^ 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.