* Re: [PATCH 2.5] speedup kallsyms_lookup
From: Hugh Dickins @ 2003-01-10 16:34 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Andi Kleen, Daniel Ritz, linux-kernel, daniel.ritz, Robert Love
In-Reply-To: <20030110161328.GV23814@holomorphy.com>
On Fri, 10 Jan 2003, William Lee Irwin III wrote:
> At some point in the past, I wrote:
> >> So the end-result of the discussion is, "What should really happen here?"
> >> and "What, if anything, do you want me to do?"
>
> On Fri, Jan 10, 2003 at 05:12:12PM +0100, Andi Kleen wrote:
> > IMHO best would be to get rid of /proc/*/wchan and keep the kallsyms
> > lookup slow, simple and stupid.
>
> Slow, simple, and stupid == "wli, get the Hell out". I'm gone.
Indeed! I think that was Andi volunteering :-}
But we should let rml defend his wchan.
Hugh
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Alan Cox @ 2003-01-10 17:19 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20030110161012.GD2041@holomorphy.com>
On Fri, 2003-01-10 at 16:10, William Lee Irwin III wrote:
> Any specific concerns/issues/wishlist items you want taken care of
> before doing it or is it a "generalized comfort level" kind of thing?
> Let me know, I'd be much obliged for specific directions to move in.
IDE is all broken still and will take at least another three months to
fix - before we get to 'improve'. The entire tty layer locking is terminally
broken and nobody has even started fixing it. Just try a mass of parallel
tty/pty activity . It was problematic before, pre-empt has taken it to dead,
defunct and buried.
Most of the drivers still don't build either.
I think its important that we get to the stage that we can actually say
- It compiles (as close to all the mainstream bits of it as possible)
- The stuff that is destined for the bitbucket is marked in Config and people
agree it should go
- It works (certainly the common stuff)
- Its statistically unlikely to eat your computer
- It passes Cerberus uniprocessor and smp with/without pre-empt
Otherwise everyone wil rapidly decide that ".0-pre" means ".0 as in Windows"
at which point you've just destroyed your testing base.
Given all the new stuff should be in, I'd like to see a Linus the meanie
round of updating for a while which is simply about getting all the 2.4 fixes
and the 2.5 driver compile bugs nailed, and if it doesn't fix a compile bug
or a logic bug it doesn't go in.
No more "ISAPnP TNG" and module rewrites please
Alan
^ permalink raw reply
* Re: Definitions for c_cflag etc. in termbits.h???
From: "David Müller (ELSOFT AG)" @ 2003-01-10 16:25 UTC (permalink / raw)
To: LinuxPPC
In-Reply-To: <3E1EE23F.5BC310F3@imc-berlin.de>
Hi
Steven Scholz wrote:
> Hi there,
>
> I am playing around with UARTs and got completly confused when looking at
> ./include/asm-ppc/termbits.h:
That reminds me of something:
Is it possible that "CMSPAR" is missing in both the 2.4 and 2.5 version
of asm-ppc/termbits.h?
Dave
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Ethernet frame padding bug in several drivers - patch(es) included
From: Jesper Juhl @ 2003-01-10 16:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Donald Becker, Bao C. Ha.
Hi,
I send this mail once before (about 16 hours ago), but it seems it never
reached the list, so I'm resending it. If you recieve it twice I
appologize.
---[ original mail below ]---
Hi,
First of all, please CC me on replies as I'm not subscribed to the list.
I just read a paper by Ofir Arkin and Josh Anderson from @stake
(http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf),
that documents a bug related to incorrect padding of ethernet frames in
many
Linux (and other OS) device drivers.
Briefly, the problem is that when a frame is less than the minimum
required
size, the frame *should* be padded with 0 bytes, but is instead padded
with
kernel memory. This happens since the drivers don't take care to zero
the
padding of the buffer before transmitting it.
I won't repeat the paper here as it does quite a good job explaining the
issue.
After reading the paper I took a look at the source for my 2.4.20
kernel, and
saw that the problem was indeed present in many drivers. I then desided
that
I might as well fix it as anyone else and started on the task.
So far I've only patched 3 drivers (randomly selected), and I would like
to
get some feedback on the patches before I do the rest of them. I would
like
to make sure the fix is correct before spending time implementing a
flawed
fix in all the affected drivers.
The fix is more or less straight from the paper from @stake, so those
people
should get all the credit. I'm just doing the legwork of actually fixing
up
the driver files (patches are against vanilla 2.4.20).
If I get positive feedback on these 3 small patches, then I'll go ahead
and do
the rest of the drivers tomorrow and submit the new patches.
Here are the patches:
patch for drivers/net/3c507.c
--- 3c507.c.orig 2003-01-10 01:51:13.000000000 +0100
+++ 3c507.c 2003-01-10 02:05:30.000000000 +0100
@@ -494,9 +494,16 @@
struct net_local *lp = (struct net_local *) dev->priv;
int ioaddr = dev->base_addr;
unsigned long flags;
- short length = ETH_ZLEN < skb->len ? skb->len : ETH_ZLEN;
+ short length;
unsigned char *buf = skb->data;
+ if (skb->len < ETH_ZLEN) {
+ length = ETH_ZLEN;
+ memset(buf + skb->len, 0, length - skb->len);
+ } else {
+ length = skb->len;
+ }
+
netif_stop_queue (dev);
spin_lock_irqsave (&lp->lock, flags);
patch for drivers/net/atp.c
--- atp.c.orig 2003-01-10 01:51:13.000000000 +0100
+++ atp.c 2003-01-10 02:03:35.000000000 +0100
@@ -553,7 +553,12 @@
int length;
long flags;
- length = ETH_ZLEN < skb->len ? skb->len : ETH_ZLEN;
+ if (skb->len < ETH_ZLEN) {
+ length = ETH_ZLEN;
+ memset(&skb->data + skb->len, 0, length - skb->len);
+ } else {
+ length = skb->len;
+ }
netif_stop_queue(dev);
patch for drivers/net/eepro.c
--- eepro.c.orig 2003-01-10 01:51:13.000000000 +0100
+++ eepro.c 2003-01-10 02:17:00.000000000 +0100
@@ -1138,9 +1138,16 @@
spin_lock_irqsave(&lp->lock, flags);
{
- short length = ETH_ZLEN < skb->len ? skb->len :
ETH_ZLEN;
+ short length;
unsigned char *buf = skb->data;
+ if (skb->len < ETH_ZLEN) {
+ length = ETH_ZLEN;
+ memset(buf + skb->len, 0, length - skb->len);
+ } else {
+ length = skb->len;
+ }
+
if (hardware_send_packet(dev, buf, length))
/* we won't wake queue here because we're out of
space
*/
lp->stats.tx_dropped++;
Best regards,
Jesper Juhl <jju@dif.dk>
^ permalink raw reply
* Re: [Lse-tech] Minature NUMA scheduler
From: Erich Focht @ 2003-01-10 16:34 UTC (permalink / raw)
To: Michael Hohnbaum, Martin J. Bligh
Cc: Robert Love, Ingo Molnar, linux-kernel, lse-tech
In-Reply-To: <1042176966.30434.148.camel@kenai>
Hi Martin & Michael,
indeed, restricting a process to the node on which it was started
helps, as the memory will always be local. The NUMA scheduler allows a
process to move away from it's node, if the load conditions require
it, but in the current form the process will not come back to its
homenode. That's what the "node affine scheduler" tried to realise.
The miniature NUMA scheduler relies on the quality of the initial load
balancer, and that one seems to be good enough. As you mentioned,
multithreaded jobs are disadvantaged as their threads have to stick on
the originating node.
Having some sort of automatic node affinity of processes and equal
node loads in mind (as design targets), we could:
- take the minimal NUMA scheduler
- if the normal (node-restricted) find_busiest_queue() fails and
certain conditions are fulfilled (tried to balance inside own node
for a while and didn't succeed, own CPU idle, etc... ???) rebalance
over node boundaries (eg. using my load balancer)
This actually resembles the original design of the node affine
scheduler, having the cross-node balancing separate is ok and might
make the ideas clearer.
I made some measurements, too, and found basically what I
expected. The numbers are from a machine with 4 nodes of 2 CPUs
each. It's on ia64, so 2.5.52 based.
As the minsched cannot make mistakes (by moving tasks away from their
homenode), it leads to the best results with numa_test. OTOH hackbench
suffers a lot from the limitation to one node. The hackbench tasks are
not latency/bandwidth limited, the faster they spread over the whole
machine, the quicker finishes the job. That's why NUMA-sched is
slightly worse than a stock kernel. But minsched looses >50%. Funilly,
on my machine kernbench is slightly faster with the normal NUMA
scheduler.
Regards,
Erich
Results on a 8 CPU machine with 4 nodes (2 CPUs per node).
kernbench:
elapsed user system
stock52 134.52(0.84) 951.64(0.97) 20.72(0.22)
sched52 133.19(1.49) 944.24(0.50) 21.36(0.24)
minsched52 135.47(0.47) 937.61(0.20) 21.30(0.14)
schedbench/hackbench: time(s)
10 25 50 100
stock52 0.81(0.04) 2.06(0.07) 4.09(0.13) 7.89(0.25)
sched52 0.81(0.04) 2.03(0.07) 4.14(0.20) 8.61(0.35)
minsched52 1.28(0.05) 3.19(0.06) 6.59(0.13) 13.56(0.27)
numabench/numa_test 4
AvgUserTime ElapsedTime TotUserTime TotSysTime
stock52 --- 27.23(0.52) 89.30(4.18) 0.09(0.01)
sched52 22.32(1.00) 27.39(0.42) 89.29(4.02) 0.10(0.01)
minsched52 20.01(0.01) 23.40(0.13) 80.05(0.02) 0.08(0.01)
numabench/numa_test 8
AvgUserTime ElapsedTime TotUserTime TotSysTime
stock52 --- 27.50(2.58) 174.74(6.66) 0.18(0.01)
sched52 21.73(1.00) 33.70(1.82) 173.87(7.96) 0.18(0.01)
minsched52 20.31(0.00) 23.50(0.12) 162.47(0.04) 0.16(0.01)
numabench/numa_test 16
AvgUserTime ElapsedTime TotUserTime TotSysTime
stock52 --- 52.68(1.51) 390.03(15.10) 0.34(0.01)
sched52 21.51(0.80) 47.18(3.24) 344.29(12.78) 0.36(0.01)
minsched52 20.50(0.03) 43.82(0.08) 328.05(0.45) 0.34(0.01)
numabench/numa_test 32
AvgUserTime ElapsedTime TotUserTime TotSysTime
stock52 --- 102.60(3.89) 794.57(31.72) 0.65(0.01)
sched52 21.93(0.57) 92.46(1.10) 701.75(18.38) 0.67(0.02)
minsched52 20.64(0.10) 89.95(3.16) 660.72(3.13) 0.68(0.07)
On Friday 10 January 2003 06:36, Michael Hohnbaum wrote:
> On Thu, 2003-01-09 at 15:54, Martin J. Bligh wrote:
> > I tried a small experiment today - did a simple restriction of
> > the O(1) scheduler to only balance inside a node. Coupled with
> > the small initial load balancing patch floating around, this
> > covers 95% of cases, is a trivial change (3 lines), performs
> > just as well as Erich's patch on a kernel compile, and actually
> > better on schedbench.
> >
> > This is NOT meant to be a replacement for the code Erich wrote,
> > it's meant to be a simple way to get integration and acceptance.
> > Code that just forks and never execs will stay on one node - but
> > we can take the code Erich wrote, and put it in seperate rebalancer
> > that fires much less often to do a cross-node rebalance.
>
> I tried this on my 4 node NUMAQ (16 procs, 16GB memory) and got
> similar results. Also, added in the cputime_stats patch and am
> attaching the matrix results from the 32 process run. Basically,
> all runs show that the initial load balancer is able to place the
> tasks evenly across the nodes, and the better overall times show
> that not migrating to keep the nodes balanced over time results
> in better performance - at least on these boxes.
>
> Obviously, there can be situations where load balancing across
> nodes is necessary, but these results point to less load balancing
> being better, at least on these machines. It will be interesting
> to repeat this on boxes with other interconnects.
>
> $ reportbench hacksched54 sched54 stock54
> Kernbench:
> Elapsed User System CPU
> hacksched54 29.406s 282.18s 81.716s 1236.8%
> sched54 29.112s 283.888s 82.84s 1259.4%
> stock54 31.348s 303.134s 87.824s 1247.2%
>
> Schedbench 4:
> AvgUser Elapsed TotalUser TotalSys
> hacksched54 21.94 31.93 87.81 0.53
> sched54 22.03 34.90 88.15 0.75
> stock54 49.35 57.53 197.45 0.86
>
> Schedbench 8:
> AvgUser Elapsed TotalUser TotalSys
> hacksched54 28.23 31.62 225.87 1.11
> sched54 27.95 37.12 223.66 1.50
> stock54 43.14 62.97 345.18 2.12
>
> Schedbench 16:
> AvgUser Elapsed TotalUser TotalSys
> hacksched54 49.29 71.31 788.83 2.88
> sched54 55.37 69.58 886.10 3.79
> stock54 66.00 81.25 1056.25 7.12
>
> Schedbench 32:
> AvgUser Elapsed TotalUser TotalSys
> hacksched54 56.41 117.98 1805.35 5.90
> sched54 57.93 132.11 1854.01 10.74
> stock54 77.81 173.26 2490.31 12.37
>
> Schedbench 64:
> AvgUser Elapsed TotalUser TotalSys
> hacksched54 56.62 231.93 3624.42 13.32
> sched54 72.91 308.87 4667.03 21.06
> stock54 86.68 368.55 5548.57 25.73
>
> hacksched54 = 2.5.54 + Martin's tiny NUMA patch +
> 03-cputimes_stat-2.5.53.patch +
> 02-numa-sched-ilb-2.5.53-21.patch
> sched54 = 2.5.54 + 01-numa-sched-core-2.5.53-24.patch +
> 02-ilb-2.5.53-21.patch02 +
> 03-cputimes_stat-2.5.53.patch
> stock54 - 2.5.54 + 03-cputimes_stat-2.5.53.patch
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: Randolph Chung @ 2003-01-10 16:29 UTC (permalink / raw)
To: jsoe0708; +Cc: parisc-linux
In-Reply-To: <3E1AA8D5000009DC@ocpmta8.freegates.net>
> Unfortunately this doesn't reproduce the actual problem of which I save
> the following traces (from the evms_vgscan 1.1.0: once again this was fix
> since next release):
i'm not sure i correctly parsed what you wrote... the structure you
posted is fine, but that doesn't mean it cannot cause unaligned accesses
if used incorrectly.
for a simple example:
struct foo {
int bar;
};
this structure if placed on the stack by gcc is always int-aligned. but
you can easily generate unaligned accesses from it:
void botch(void)
{
char buf[1024];
struct foo x;
struct foo *a, *b;
a = &x;
b = (struct foo *)buf[2];
printf("%d\n", a->bar); /* aligned */
printf("%d\n", b->bar); /* unaligned! */
}
in this case, the structure gives you no guarantees that things will be
aligned properly.
it's also possible to have much more involved scenarios, (e.g. with
unions of things with different alignments), where things can get messed
up.... you need to carefully look at how the code works to debug these
things. while gcc may not be bug-free in this area, it's much more
likely to be an application bug than a gcc one.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* Re: [PATCH 2.5] speedup kallsyms_lookup
From: Zwane Mwaikambo @ 2003-01-10 16:37 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Andi Kleen, Hugh Dickins, Daniel Ritz, linux-kernel, daniel.ritz,
Robert Love
In-Reply-To: <20030110161328.GV23814@holomorphy.com>
On Fri, 10 Jan 2003, William Lee Irwin III wrote:
> At some point in the past, I wrote:
> >> So the end-result of the discussion is, "What should really happen here?"
> >> and "What, if anything, do you want me to do?"
>
> On Fri, Jan 10, 2003 at 05:12:12PM +0100, Andi Kleen wrote:
> > IMHO best would be to get rid of /proc/*/wchan and keep the kallsyms
> > lookup slow, simple and stupid.
>
> Slow, simple, and stupid == "wli, get the Hell out". I'm gone.
I don't really see a need for blazing fast lookup here, as long as it gets
done within a reasonable timeframe for common cases. Unless of course your
optimised version also saves space code wise.
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* [PATCH/RFC/CFT 2.4] The trouble with write errors
From: Oliver Xymoron @ 2003-01-10 16:36 UTC (permalink / raw)
To: linux-kernel
As a couple other folks have noted, Linux currently fails to propagate
write errors to userspace, quietly marking page clean. Write IO errors
are extremely uncommon for most systems, thanks to low-level sector
remapping and the like, but with the increasing use of networked and
hotpluggable storage, new scenarios for IO failure are appearing.
I've been looking at this a bit and discussing it with Andrew and
Linus and here's what I've come up with. This patch is against
2.4.21-pre3 and works nicely for all the cases I've tested it with.
I'll whip up a 2.5 version once I get some thoughts on this.
Basic scenario:
Process dirties page in pagecache via write, mapping, etc.
Reader sees current data in pagecache
Pagecache decides to push page to disk due to memory pressure
page is locked, marked clean and submitted to block driver via IO layer
driver reports IO error and ripples failure back to pagecache
pagecache marks page not uptodate and unlocks page
Process calls fsync which reports success
Next reader sees page not uptodate and refetches old data from disk
First let's address readers seeing old data. Ideally we'd like for
readers not to see the new data and then later see the old data again
- this is likely to confuse applications. To accomplish this, we
either have to not allow other apps to see it before it touches the
disk (which is equivalent to turning off write caching) or we have to
retry the write until we encounter a permanent error. Linus argues
that retries are currently the driver's responsibility and not the
pagecache's, so the error should be treated as permanent. Given that
we're unwilling to turn off write caching, we are therefore forced to
address the old data problem by coordination at the application layer.
This leads us to the second problem: the write IO error isn't reported to
the application layer in any form. The code is currently designed for
handling of errors on read, where the failure of the page to be
uptodate is caught synchronously. Further, the pagecache callback is
not able to determine whether its dealing with a read or write
failure, so we need to use different callbacks for read and write.
Andrew points out that a related problem that can occur here is
ENOSPC. Since most filesystems don't implement proper reservations,
it's possible for a write() to return success while the delayed block
allocation fails. This patch detects that case as well.
Passing these error back to userspace turns out to be tricky. We'd like
to report it on the next fsync/fdatasync/msync or close on a given
filehandle. Unfortunately, by the time we've reached the pagecache,
the filehandle is long forgotten and the best we can do without
crippling the pagecache is report the error for the next sync on the
given inode. This means that multiple writers to the same file might
get their error reporting crossed, but apps doing that should probably
be coordinating their activities anyway.
The obvious places to track this error are in the inode, the mapping,
or in the give page struct's bits. The page bits looked promising at
first because they can be safely handled in interrupt context, but
because pages are taken off the dirty list when they hit the IO layer,
it would require a new list for errored pages or searching through the
entire mapping on fsync, etc.
That leaves us with recording the error in the inode/mapping and clearing it
when we get a chance to report it. The mapping appears to be pinned in
memory at the appropriate places, but we're unable to properly protect
it from concurrent users with the inode semaphore from interrupt
context.
Does this matter? Probably not. We already have no guarantee that I/O
is completed when we call close() so we're not particularly concerned
with losing the error in a race here. And for the sync variants, we're
waiting for all I/O for the mapping to complete so we're protected
from races there.
Other loose ends:
Linus suggested that errors could be reported on the next write(),
similar to sockets. I think this would confuse a lot of applications
into thinking the current write failed and not the previous and the
few that would expect it would already be using sync.
This problem doesn't affect writes via rawio or O_DIRECT, but it does
affect metadata stored in the pagecache by filesystems, which are
probably unprepared for dealing with write errors. So if you encounter
IO errors on write, there's currently a fair chance that you'll end up
with a corrupted filesystem, with or without this patch.
diff -urN -x '.patch*' -x '*.orig' orig/drivers/block/ll_rw_blk.c patched/drivers/block/ll_rw_blk.c
--- orig/drivers/block/ll_rw_blk.c 2003-01-09 13:13:18.000000000 -0600
+++ patched/drivers/block/ll_rw_blk.c 2003-01-09 13:15:06.000000000 -0600
@@ -1282,10 +1282,10 @@
/* We have the buffer lock */
atomic_inc(&bh->b_count);
- bh->b_end_io = end_buffer_io_sync;
switch(rw) {
case WRITE:
+ bh->b_end_io = end_buffer_write_sync;
if (!atomic_set_buffer_clean(bh))
/* Hmmph! Nothing to write */
goto end_io;
@@ -1294,6 +1294,7 @@
case READA:
case READ:
+ bh->b_end_io = end_buffer_read_sync;
if (buffer_uptodate(bh))
/* Hmmph! Already have it */
goto end_io;
diff -urN -x '.patch*' -x '*.orig' orig/fs/buffer.c patched/fs/buffer.c
--- orig/fs/buffer.c 2003-01-09 13:13:33.000000000 -0600
+++ patched/fs/buffer.c 2003-01-09 13:15:06.000000000 -0600
@@ -168,13 +168,30 @@
* Default synchronous end-of-IO handler.. Just mark it up-to-date and
* unlock the buffer. This is what ll_rw_block uses too.
*/
-void end_buffer_io_sync(struct buffer_head *bh, int uptodate)
+void end_buffer_read_sync(struct buffer_head *bh, int uptodate)
{
mark_buffer_uptodate(bh, uptodate);
unlock_buffer(bh);
put_bh(bh);
}
+void end_buffer_write_sync(struct buffer_head *bh, int uptodate)
+{
+ mark_buffer_uptodate(bh, uptodate);
+
+ /* Flag failed writes for late fsync/msync */
+ if (!uptodate)
+ {
+ printk(KERN_WARNING "lost page write due to I/O error on %s\n",
+ kdevname(bh->b_dev));
+ /* mapping is pinned by PG_locked */
+ bh->b_page->mapping->error=-EIO;
+ }
+
+ unlock_buffer(bh);
+ put_bh(bh);
+}
+
/*
* The buffers have been marked clean and locked. Just submit the dang
* things..
@@ -183,7 +200,7 @@
{
do {
struct buffer_head * bh = *array++;
- bh->b_end_io = end_buffer_io_sync;
+ bh->b_end_io = end_buffer_write_sync;
submit_bh(WRITE, bh);
} while (--count);
}
@@ -751,7 +768,12 @@
page = bh->b_page;
if (!uptodate)
+ {
+ printk(KERN_WARNING "lost async page write due to I/O error on %s\n",
+ kdevname(bh->b_dev));
+ bh->b_page->mapping->error=-EIO;
SetPageError(page);
+ }
/*
* Be _very_ careful from here on. Bad things can happen if
@@ -2608,7 +2630,7 @@
__mark_buffer_clean(bh);
get_bh(bh);
- bh->b_end_io = end_buffer_io_sync;
+ bh->b_end_io = end_buffer_write_sync;
submit_bh(WRITE, bh);
tryagain = 0;
} while ((bh = bh->b_this_page) != head);
diff -urN -x '.patch*' -x '*.orig' orig/fs/inode.c patched/fs/inode.c
--- orig/fs/inode.c 2003-01-09 13:13:33.000000000 -0600
+++ patched/fs/inode.c 2003-01-09 13:17:41.000000000 -0600
@@ -115,6 +115,7 @@
mapping->a_ops = &empty_aops;
mapping->host = inode;
mapping->gfp_mask = GFP_HIGHUSER;
+ mapping->error = 0;
inode->i_mapping = mapping;
}
return inode;
diff -urN -x '.patch*' -x '*.orig' orig/fs/open.c patched/fs/open.c
--- orig/fs/open.c 2002-11-28 17:53:15.000000000 -0600
+++ patched/fs/open.c 2003-01-09 13:15:06.000000000 -0600
@@ -829,21 +829,41 @@
*/
int filp_close(struct file *filp, fl_owner_t id)
{
- int retval;
+ struct address_space *mapping = filp->f_dentry->d_inode->i_mapping;
+ struct inode *inode = mapping->host;
+ int retval = 0, err;
+
+ /* Report and clear outstanding errors */
+ err = filp->f_error;
+ if (err) {
+ filp->f_error = 0;
+ retval = err;
+ }
+
+ down(&inode->i_sem);
+ err = mapping->error;
+ if (err && !retval) {
+ mapping->error = 0;
+ retval = err;
+ }
+ up(&inode->i_sem);
if (!file_count(filp)) {
printk(KERN_ERR "VFS: Close: file count is 0\n");
- return 0;
+ return retval;
}
- retval = 0;
+
if (filp->f_op && filp->f_op->flush) {
lock_kernel();
- retval = filp->f_op->flush(filp);
+ err = filp->f_op->flush(filp);
unlock_kernel();
+ if (err && !retval)
+ retval = err;
}
dnotify_flush(filp, id);
locks_remove_posix(filp, id);
fput(filp);
+
return retval;
}
diff -urN -x '.patch*' -x '*.orig' orig/include/linux/fs.h patched/include/linux/fs.h
--- orig/include/linux/fs.h 2003-01-09 13:13:37.000000000 -0600
+++ patched/include/linux/fs.h 2003-01-09 13:15:06.000000000 -0600
@@ -410,6 +410,7 @@
struct vm_area_struct *i_mmap_shared; /* list of shared mappings */
spinlock_t i_shared_lock; /* and spinlock protecting it */
int gfp_mask; /* how to allocate the pages */
+ int error; /* write error for fsync */
};
struct char_device {
@@ -1127,7 +1128,8 @@
extern int FASTCALL(try_to_free_buffers(struct page *, unsigned int));
extern void refile_buffer(struct buffer_head * buf);
extern void create_empty_buffers(struct page *, kdev_t, unsigned long);
-extern void end_buffer_io_sync(struct buffer_head *bh, int uptodate);
+extern void end_buffer_read_sync(struct buffer_head *bh, int uptodate);
+extern void end_buffer_write_sync(struct buffer_head *bh, int uptodate);
/* reiserfs_writepage needs this */
extern void set_buffer_async_io(struct buffer_head *bh) ;
diff -urN -x '.patch*' -x '*.orig' orig/mm/filemap.c patched/mm/filemap.c
--- orig/mm/filemap.c 2003-01-09 13:13:39.000000000 -0600
+++ patched/mm/filemap.c 2003-01-09 13:15:06.000000000 -0600
@@ -492,7 +492,7 @@
page_cache_release(page);
}
spin_unlock(&pagecache_lock);
-
+out:
return retval;
}
@@ -587,6 +587,14 @@
spin_lock(&pagecache_lock);
}
spin_unlock(&pagecache_lock);
+
+ /* Check for outstanding write errors */
+ if (mapping->error)
+ {
+ ret = mapping->error;
+ mapping->error = 0;
+ }
+
return ret;
}
diff -urN -x '.patch*' -x '*.orig' orig/mm/vmscan.c patched/mm/vmscan.c
--- orig/mm/vmscan.c 2002-11-28 17:53:15.000000000 -0600
+++ patched/mm/vmscan.c 2003-01-09 13:15:06.000000000 -0600
@@ -400,15 +400,21 @@
* so the direct writes to the page cannot get lost.
*/
int (*writepage)(struct page *);
+ struct address_space *mapping = page->mapping;
- writepage = page->mapping->a_ops->writepage;
+ writepage = mapping->a_ops->writepage;
if ((gfp_mask & __GFP_FS) && writepage) {
+ int err;
+
ClearPageDirty(page);
SetPageLaunder(page);
page_cache_get(page);
spin_unlock(&pagemap_lru_lock);
- writepage(page);
+ err = writepage(page);
+ if (err)
+ mapping->error = err;
+
page_cache_release(page);
spin_lock(&pagemap_lru_lock);
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Alan Cox @ 2003-01-10 17:23 UTC (permalink / raw)
To: fverscheure; +Cc: Linux Kernel Mailing List, Marcelo Tosatti, Andre Hedrick
In-Reply-To: <20030110095558.E144CFF11@postfix4-1.free.fr>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
On Fri, 2003-01-10 at 09:54, Francis Verscheure wrote:
> And by the way how are powered off the IDE drives ?
> Because a FLUSH CACHE or STANDY or SLEEP is MANDATORY before powering off the
> drive with cache enabled or you will enjoy lost data.
We always issue standby or sleep commands to a drive before powering off which means
the cache flush thing should never have been an issue.
Having been over the other stuff here is a fairly paranoid first cut. Marcelo
please *don't* apply this yet, I'd like an Andre review of it and some testing
first.
[-- Attachment #2: a1 --]
[-- Type: text/plain, Size: 2990 bytes --]
--- ../linux.21pre3/drivers/ide/ide-disk.c 2003-01-07 14:03:08.000000000 +0000
+++ drivers/ide/ide-disk.c 2003-01-10 17:15:02.000000000 +0000
@@ -38,9 +38,11 @@
* Version 1.15 convert all calls to ide_raw_taskfile
* since args will return register content.
* Version 1.16 added suspend-resume-checkpower
+ * Version 1.17 do flush on standy, do flush on ATA < ATA6
+ * fix wcache setup.
*/
-#define IDEDISK_VERSION "1.16"
+#define IDEDISK_VERSION "1.17"
#undef REALLY_SLOW_IO /* most systems can safely undef this */
@@ -67,7 +69,7 @@
#include <asm/uaccess.h>
#include <asm/io.h>
-/* FIXME: soem day we shouldnt need to look in here! */
+/* FIXME: some day we shouldnt need to look in here! */
#include "legacy/pdc4030.h"
@@ -716,6 +718,7 @@
MOD_INC_USE_COUNT;
if (drive->removable && drive->usage == 1) {
ide_task_t args;
+ int cf;
memset(&args, 0, sizeof(ide_task_t));
args.tfRegister[IDE_COMMAND_OFFSET] = WIN_DOORLOCK;
args.command_type = ide_cmd_type_parser(&args);
@@ -727,12 +730,40 @@
*/
if (drive->doorlocking && ide_raw_taskfile(drive, &args, NULL))
drive->doorlocking = 0;
+ drive->wcache = 0;
+ /* Cache enabled ? */
+ if (drive->id->csfo & 1)
+ drive->wcache = 1;
+ /* Cache command set available ? */
+ if (drive->id->cfs_enable_1 & (1<<5))
+ drive->wcache = 1;
+ /* ATA6 cache extended commands */
+ cf = drive->id->command_set_2 >> 24;
+ if((cf & 0xC0) == 0x40 && (cf & 0x30) != 0)
+ drive->wcache = 1;
}
return 0;
}
static int do_idedisk_flushcache(ide_drive_t *drive);
+static int ide_cacheflush_p(ide_drive_t *drive)
+{
+ if(drive->wcache)
+ {
+ printk(KERN_INFO "ide: performing cache flush.\n");
+ if (do_idedisk_flushcache(drive))
+ {
+ printk (KERN_INFO "%s: Write Cache FAILED Flushing!\n",
+ drive->name);
+ return -EIO;
+ }
+ return 1;
+ }
+ printk(KERN_INFO "ide: no cache flush required.\n");
+ return 0;
+}
+
static void idedisk_release (struct inode *inode, struct file *filp, ide_drive_t *drive)
{
if (drive->removable && !drive->usage) {
@@ -744,10 +775,7 @@
if (drive->doorlocking && ide_raw_taskfile(drive, &args, NULL))
drive->doorlocking = 0;
}
- if ((drive->id->cfs_enable_2 & 0x3000) && drive->wcache)
- if (do_idedisk_flushcache(drive))
- printk (KERN_INFO "%s: Write Cache FAILED Flushing!\n",
- drive->name);
+ ide_cacheflush_p(drive);
MOD_DEC_USE_COUNT;
}
@@ -1435,7 +1463,7 @@
{
if (drive->suspend_reset)
return 1;
-
+ ide_cacheflush_p(drive);
return call_idedisk_suspend(drive, 0);
}
@@ -1679,10 +1707,7 @@
static int idedisk_cleanup(ide_drive_t *drive)
{
- if ((drive->id->cfs_enable_2 & 0x3000) && drive->wcache)
- if (do_idedisk_flushcache(drive))
- printk (KERN_INFO "%s: Write Cache FAILED Flushing!\n",
- drive->name);
+ ide_cacheflush_p(drive);
return ide_unregister_subdriver(drive);
}
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Shawn Starr @ 2003-01-10 16:39 UTC (permalink / raw)
To: Linux Kernel Mailing List
There will be a new kernel tree that will fit this purpose soon called -xlk
(eXtendable or Extended Linux Kernel). The hope to make it an 'official' like
-ac, -mm tree for stuffing experimental stuff into a post 2.6 (or just before
2.6 goes live) kernel. I will need help in getting this to become a reality
in the coming months to 2.6.
The purpose of the tree is to get experimental code ready for the 2.7 (2.9?)
tree. We want code that will add new drivers / devices and general
improvements to the kernel. The goal is once these are stabilized they can be
submitted to Linus and friends for blessings and inclusion into 2.7 dev
*early* so we won't have a mad rush for features before the next feature
freeze.
>Subject: any chance of 2.6.0-test*?
From: William Lee Irwin III <wli () holomorphy ! com>
>Date: 2003-01-10 16:10:12
>Say, I've been having _smashing_ success with 2.5.x on the desktop and
>on big fat highmem umpteen-way SMP (NUMA even!) boxen, and I was
>wondering if you were considering 2.6.0-test* anytime soon.
>I'd love to get this stuff out for users to hammer on ASAP, and things
>are looking really good AFAICT.
>Any specific concerns/issues/wishlist items you want taken care of
>before doing it or is it a "generalized comfort level" kind of thing?
>Let me know, I'd be much obliged for specific directions to move in.
>Thanks,
>Bill
--
Shawn Starr
UNIX Systems Administrator, Operations
Datawire Communication Networks Inc.
10 Carlson Court, Suite 300
Toronto, ON, M9W 6L2
T: 416-213-2001 ext 179 F: 416-213-2008
shawn.starr@datawire.net
"The power to Transact" - http://www.datawire.net
^ permalink raw reply
* [parisc-linux] new gcc-default for hppa
From: jsoe0708 @ 2003-01-10 16:31 UTC (permalink / raw)
To: parisc-linux, debian-hppa
Hi all,
I do notice that unstable debian for i386 switch (or will very soon) gcc-=
default
to gcc-3.2. Is it also true for hppa? (am I anxious about compiling new
kernel with this because of pb encounter with network connection)
Thanks in advance for advise,
Joel
*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Jeff Garzik @ 2003-01-10 16:40 UTC (permalink / raw)
To: Alan Cox; +Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <1042219147.31848.65.camel@irongate.swansea.linux.org.uk>
On Fri, Jan 10, 2003 at 05:19:08PM +0000, Alan Cox wrote:
> No more "ISAPnP TNG" and module rewrites please
Highlighted and seconded...
^ permalink raw reply
* [parisc-linux] new gcc-default for hppa
From: jsoe0708 @ 2003-01-10 16:31 UTC (permalink / raw)
To: parisc-linux, debian-hppa
Hi all,
I do notice that unstable debian for i386 switch (or will very soon) gcc-=
default
to gcc-3.2. Is it also true for hppa? (am I anxious about compiling new
kernel with this because of pb encounter with network connection)
Thanks in advance for advise,
Joel
*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Zwane Mwaikambo @ 2003-01-10 16:41 UTC (permalink / raw)
To: Dave Jones; +Cc: William Lee Irwin III, torvalds, linux-kernel
In-Reply-To: <20030110162834.GB23375@codemonkey.org.uk>
On Fri, 10 Jan 2003, Dave Jones wrote:
> There's still a boatload of drivers that don't compile,
> a metric shitload of bits that never came over from 2.4 after
> I stopped doing it circa 2.4.18, a lot of little 'trivial'
> patches that got left by the wayside, and a load of 'strange' bits
> that still need nailing down (personally, I have two boxes
> that won't boot a 2.5 kernel currently (One was pnpbios related,
I had a problem with PCI init, pnpbios ordering at some point, but i
haven't tried a kernel with pnpbios in a while.
> other needs more investigation), and another that falls on its
> face after 10 minutes idle uptime. My p4-ht desktop box is the only one
> that runs 2.5 without any problems.
Thats interesting, i have a laptop experiencing the same symptoms, i'll be
looking at it over the weekend.
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* Re: Fixed proken MARK target in POM.
From: Anders Fugmann @ 2003-01-10 16:38 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
In-Reply-To: <3E1EE68C.7030004@fugmann.dhs.org>
Anders Fugmann wrote:
> Harald Welte wrote:
>
>> On Thu, Jan 09, 2003 at 02:07:37PM +0100, Anders Fugmann wrote:
>>
>>
>>> The patch maintains backward compability, and I request that this
>>> patch is applied to mainstream (and pushed to the Andrea for kernel
>>> inclusion),
>>
>>
>>
>> 1) Where is the compatibility? I cannot see how this code change would
>> ensure that
>> a) old, unpatched kernel works with new, patched userspace
>> b) new, patched kernel works with old, unpatched userspace
>> Those two conditions need to be fulfilled, otherwise we cannot make a
>> change during the stable kernel series.
Looking at bit further, this seems non-trivial as I guess that the
userspace should compile no matter kernel-headers version - no?
Are defines tolerated? Something like:
#define MARK_BITOPS
and then in the userspace do a:
#ifdef MARK_BITOPS
Whenever the new fileds in the structure is used.
But IMHO this clutters the code up and I would rather avoid that.
Do you know of modules that had the same problem, or do you regard it as
unresolvable to add an extra field to a structure in the stable series?
Regards
Anders Fugmann
^ permalink raw reply
* Re: Reg iptables Connection tracking
From: Athan @ 2003-01-10 16:39 UTC (permalink / raw)
To: Amit Kumar Gupta; +Cc: netfilter
In-Reply-To: <4223A04BF7D1B941A25246ADD0462FF56477FD@blr-m3-msg.wipro.com>
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
On Fri, Jan 10, 2003 at 04:04:54PM +0530, Amit Kumar Gupta wrote:
> On Friday 10 January 2003 12:37 am, you wrote:
> > Well I am able to see upto this point. I went through the code flow
> > also. But I don't know why it prints the message(Even if increasing
> > the value from 1016 to 4096 by hardcoding it in the kernel). Another
> > issue is I don't know how it is taking 1016. As There is no /proc file
> > system, and by default it shoud take 0.
I missed this before, sorry. Is this due to specifically disabling
/proc and/or specifically not mounting it for security reasons? If not,
just enable it and mount it already.
> Not that this helps much. The real problem is WHAT is the conntrack
> table filling with. And I suspect it may be nothing, that you have a
> problem because it is trying to use /proc/net/conntrack and there IS no
> /proc/net/conntrack. The message may be triggering incorrectly,
> presuming that since it cannot write another entry to
> /proc/net/conntrack that the table is full.
Er, no. That's not what /proc/net/ip_conntrack is. It doesn't EXIST
as such until you try to read from it. All of /proc is virtual. Just
because you have no /proc and can't get at 'files' in it doesn't mean
the SOURCE of their data doesn't exist.
> /proc in order to work. If I think of something else I'll email you
> again. Sorry.
I'd certainly recommend having /proc around as well. There's the
sysctl() interface for querying/changing some values too. Aha! You can
set net/ipv4/ip_conntrack_max from this too *8-):
sysctl -w net/ipv4/ip_conntrack_max=32768
If your kernel doesn't have the sysctl support then, er, you're kind of
shooting yourself in the foot for tuning things at ALL, including things
like turning IP forwarding on and off, global TCP ECN support, SYN
cookies etc....
HTH,
-Ath
--
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Jens Axboe @ 2003-01-10 16:48 UTC (permalink / raw)
To: Alan Cox, Andre Hedrick
Cc: fverscheure, Linux Kernel Mailing List, Marcelo Tosatti
In-Reply-To: <1042207998.28469.98.camel@irongate.swansea.linux.org.uk>
On Fri, Jan 10 2003, Alan Cox wrote:
> On Fri, 2003-01-10 at 13:03, Andre Hedrick wrote:
> > Oh, just let the darn thing barf a 0x51/0x04 is fine with me!
> > Just an abort/unsupported command.
>
> Sounds ok to me. We do need a barfsupressor option so we can issue
> commands that may fail without confusing the user (eg multiwrite setup)
>
> ie
> ide_hwif_barfsupress(hwif);
> ide_command....
>
> That's very much true irrespective of the flush thing
In the barrier patches, I just used drive->quiet to supress ide_error()
complaining too much (on cache flushes, too). Whether that's per-drive
of per-hwif entity, dunno...
--
Jens Axboe
^ permalink raw reply
* [2.5.55, PCI, PCMCIA, XIRCOM]
From: Jochen Hein @ 2003-01-10 16:21 UTC (permalink / raw)
To: linux-kernel
With 2.4.20 the xircom_cb driver works perfectly on my Thinkpad 600.
Loading the driver with 2.5.55 for my IBM ethernet card I get:
Jan 10 11:35:24 gswi1164 kernel: Linux Kernel Card Services 3.1.22
Jan 10 11:35:24 gswi1164 kernel: options: [pci] [cardbus] [pm]
Jan 10 11:35:24 gswi1164 kernel: PCI: Found IRQ 11 for device 00:02.0
Jan 10 11:35:24 gswi1164 kernel: PCI: Sharing IRQ 11 with 00:03.0
Jan 10 11:35:24 gswi1164 kernel: Module yenta_socket cannot be unloaded due to unsafe usage in include/linux/module.h:420
Jan 10 11:35:24 gswi1164 kernel: Yenta IRQ list 06b8, PCI irq11
Jan 10 11:35:24 gswi1164 kernel: Socket status: 30000020
Jan 10 11:35:24 gswi1164 kernel: PCI: Found IRQ 11 for device 00:02.1
Jan 10 11:35:24 gswi1164 kernel: Yenta IRQ list 06b0, PCI irq11
Jan 10 11:35:24 gswi1164 kernel: Socket status: 30000006
Jan 10 11:35:24 gswi1164 kernel: cs: cb_alloc(bus 1): vendor 0x115d, device 0x0003
Jan 10 11:35:24 gswi1164 kernel: PCI: Device 01:00.0 not available because of resource collisions
The message is not helpful at all. Looking at the source in
arch/i386/pci/i386.c I find:
246 int pcibios_enable_resources(struct pci_dev *dev, int mask)
247 {
248 u16 cmd, old_cmd;
249 int idx;
250 struct resource *r;
251
252 pci_read_config_word(dev, PCI_COMMAND, &cmd);
253 old_cmd = cmd;
254 for(idx=0; idx<6; idx++) {
255 /* Only set up the requested stuff */
256 if (!(mask & (1<<idx)))
257 continue;
258
259 r = &dev->resource[idx];
260 if (!r->start && r->end) {
261 printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", dev->slot_name) ;
262 return -EINVAL;
263 }
The following patch should provide some useful hints, why it is
failing:
--- linux-2.5.55/arch/i386/pci/i386.c.jh 2003-01-10 13:57:44.000000000 +0100
+++ linux-2.5.55/arch/i386/pci/i386.c 2003-01-10 14:39:34.000000000 +0100
@@ -258,7 +258,7 @@
r = &dev->resource[idx];
if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", dev->slot_name);
+ printk(KERN_ERR "PCI: Device %s not available because of resource collisions (start: %08lx, end: %08lx)\n", dev->slot_name, r->start, r->end);
return -EINVAL;
}
if (r->flags & IORESOURCE_IO)
Now I get the message:
PCI: Device 01:00.0 not available because of resource collisions (start: 00000000, end: 0000007f)
Looking at the reserved regions:
root@gswi1164:/usr/src# cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
03c0-03df : vesafb
03e8-03ef : serial
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-10ff : PCI CardBus #01
1400-14ff : PCI CardBus #01
1800-18ff : PCI CardBus #04
1c00-1cff : PCI CardBus #04
8400-841f : Intel Corp. 82371AB/EB/MB PIIX4
8400-841f : uhci-hcd
ef00-ef3f : Intel Corp. 82371AB/EB/MB PIIX4
efa0-efbf : Intel Corp. 82371AB/EB/MB PIIX4
fcf0-fcff : Intel Corp. 82371AB/EB/MB PIIX4
fcf0-fcf7 : ide0
fcf8-fcff : ide1
I don't understand, why the PCMCIA services try to claim these io
resources. The /proc/ioports of 2.4.20 are:
root@gswi1164:~# cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vesafb
03e8-03ef : serial(set)
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
4000-40ff : PCI CardBus #01
4000-407f : PCI device 115d:0003
4000-407f : xircom_cb
4400-44ff : PCI CardBus #01
4800-48ff : PCI CardBus #04
4c00-4cff : PCI CardBus #04
8400-841f : Intel Corp. 82371AB/EB/MB PIIX4 USB
8400-841f : usb-uhci
ef00-ef3f : Intel Corp. 82371AB/EB/MB PIIX4 ACPI
efa0-efbf : Intel Corp. 82371AB/EB/MB PIIX4 ACPI
fcf0-fcff : Intel Corp. 82371AB/EB/MB PIIX4 IDE
fcf0-fcf7 : ide0
fcf8-fcff : ide1
I don't know who is to blame, but I guess it's the xircom driver or
the pcmcia layer. Any ideas?
Jochen
--
#include <~/.signature>: permission denied
^ permalink raw reply
* Re: [Lse-tech] Minature NUMA scheduler
From: Martin J. Bligh @ 2003-01-10 16:57 UTC (permalink / raw)
To: Erich Focht, Michael Hohnbaum
Cc: Robert Love, Ingo Molnar, linux-kernel, lse-tech
In-Reply-To: <200301101734.56182.efocht@ess.nec.de>
> Having some sort of automatic node affinity of processes and equal
> node loads in mind (as design targets), we could:
> - take the minimal NUMA scheduler
> - if the normal (node-restricted) find_busiest_queue() fails and
> certain conditions are fulfilled (tried to balance inside own node
> for a while and didn't succeed, own CPU idle, etc... ???) rebalance
> over node boundaries (eg. using my load balancer)
> This actually resembles the original design of the node affine
> scheduler, having the cross-node balancing separate is ok and might
> make the ideas clearer.
This seems like the right approach to me, apart from the trigger to
do the cross-node rebalance. I don't believe that has anything to do
with when we're internally balanced within a node or not, it's
whether the nodes are balanced relative to each other. I think we should
just check that every N ticks, looking at node load averages, and do
a cross-node rebalance if they're "significantly out".
The definintion of "N ticks" and "significantly out" would be a tunable
number, defined by each platform; roughly speaking, the lower the NUMA
ratio, the lower these numbers would be. That also allows us to wedge
all sorts of smarts in the NUMA rebalance part of the scheduler, such
as moving the tasks with the smallest RSS off node. The NUMA rebalancer
is obviously completely missing from the current implementation, and
I expect we'd use mainly Erich's current code to implement that.
However, it's suprising how well we do with no rebalancer at all,
apart from the exec-time initial load balance code.
Another big advantage of this approach is that it *obviously* changes
nothing at all for standard SMP systems (whereas your current patch does),
so it should be much easier to get it accepted into mainline ....
M.
^ permalink raw reply
* [PATCH] ppc_ksyms.c (linuxppc-2.5)
From: "David Müller (ELSOFT AG)" @ 2003-01-10 16:49 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 174 bytes --]
Hello
The attached patch fixes two little problems in ppc_ksyms.c.
- mark "flush_dcache_range" as EXPORT_SYMBOLS
- "__res" is not only used on 8xx, but also on 4xx
Dave
[-- Attachment #2: ppc_ksyms.c.patch.bz2 --]
[-- Type: application/octet-stream, Size: 394 bytes --]
^ permalink raw reply
* Re: Suggestion
From: David Woodhouse @ 2003-01-10 17:00 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Mikael Pettersson, Harry Sileoni, linux-kernel
In-Reply-To: <200301101544.h0AFiBLK009357@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu said:
> The Dell Latitude C840 (what I have) and the (AFAIK) Inspiron 8100
> both use the NVidia geForce4 Go graphics chipset, and apparently the
> posted patches to make nvidia's closed-source drivers work under 2.5
> have issues with ACPI on some platforms. Digging back, I only found
> like one message on the LKML archives that mentioned the nvidia
> drivers don't play nice with ACPI.
Note that you can buy replacement non-nVidia graphics cards for the I8x00
as spare parts fairly cheaply, and they're very easy to install.
--
dwmw2
^ permalink raw reply
* Re: lifecycle of a packet (OT)
From: Anders Fugmann @ 2003-01-10 16:52 UTC (permalink / raw)
To: Oskar Andreasson; +Cc: netfilter
In-Reply-To: <Pine.LNX.4.44.0301101706340.16650-100000@laptop1.agatha>
Oskar Andreasson wrote:
> *shudder* that's an old version/site:). However, I have had so many
> problems with different hosts the last half year, I am not surprised
> people give out those old links. All of that was, hopefully, fixed when I
> moved to my own domain, so here it is:
>
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html
As old version are still spread all over the net, I would suggest that
you somehow try and get owners of old versions to remove these, or at
least give link to the original version. I do remember that you made a
post of the whereabouts of the new tutorial, but thats several hundres
emails ago.
Btw. Thanks for a great tutorial. Keep up the good work.
Regards
Anders Fugmann
^ permalink raw reply
* Linus BK tree crashes with PANIC: INIT: segmentation violation
From: Derek Atkins @ 2003-01-10 17:01 UTC (permalink / raw)
To: linux-kernel
Hi,
I've been trying to get a current 2.5 kernel up and running but I've
hit a wall. When I run my machine with a current kernel I get the
following message to my terminal, repeated ad nausium:
PANIC: INIT: segmentation violation at 0x804a08c (code)! sleeping for 30 seconds!
I've been working off of Linus' BK repository and was finally able to
get a "working" kernel when I backed up to approximately 2002-12-30
(which is sometime between 2.5.53 and 2.5.54). That kernel works just
fine.
Sometime between December 30 and January 1 a patch was added that
causes the kernel to go into an infinite loop of Oopses. Then
sometime later the behavior changed to the INIT problem I mentioned
above.
Does anyone have any clue how to deal with this? I can assure you
that it is NOT a hardware problem (otherwise why would the same
hardware work with 2.4 and 2.5.53+?) The only change being made here
is the kernel.
I have not had a chance to back out each and every ChangeSet
individually between Jan1 and Dec30 to figure out what was causing the
stream of oopses -- nor am I even confident that that would lead me to
a solution for the "PANIC: INIT" problem.
In case anyone cares, the most recent ChangeSet from my
confirmed-working (2.5.53+) tree is labeled:
1.1004 02/12/30 13:47:09 torvalds@home.transmeta.com +2 -0
Make x86 platform choice strings more easily selectable
However I have not guaranteed that this is the Changeset just before
it failed (I'm not enough of a bk guru to figure out how to pull down
one changeset at a time).
Any advice would be greatly appreciated.... I'd be more than happy to
try things out for people if you have tests you want me to run.
Thanks!
-derek
PS: I am not subscribed directly so please CC me on your replies.
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Dave Jones @ 2003-01-10 17:00 UTC (permalink / raw)
To: Shawn Starr; +Cc: Linux Kernel Mailing List
In-Reply-To: <200301101139.57342.shawn.starr@datawire.net>
On Fri, Jan 10, 2003 at 11:39:57AM -0500, Shawn Starr wrote:
> There will be a new kernel tree that will fit this purpose soon called -xlk
> (eXtendable or Extended Linux Kernel). The hope to make it an 'official' like
> -ac, -mm tree for stuffing experimental stuff into a post 2.6 (or just before
> 2.6 goes live) kernel. I will need help in getting this to become a reality
> in the coming months to 2.6.
The effort is really much better spent trying to get to 2.6 first before
worrying about things like 2.7. I hope 2.6 doesn't turn into the
"heres my 2.4+preempt+rmap patchset" monster that we saw six months ago.
> We want code that will add new drivers / devices and general
> improvements to the kernel.
non-core changes (ie, new drivers) still get added during code freeze,
and during 2.6.x, there's no need for a specific tree just for this.
Adding a new driver doesn't (or at least shouldn't) impact any existing
users if done right.
> The goal is once these are stabilized they can be
> submitted to Linus and friends for blessings and inclusion into 2.7 dev
> *early* so we won't have a mad rush for features before the next feature
> freeze.
Nice try. It'll still happen regardless. Bombing Linus with ten zillion
patches when he opens up 2.7.x with "has been tested in 2.6-xyz" isn't
the way to do it. Everything has to happen incrementally, or you end
up with a mess.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: John Bradford @ 2003-01-10 17:02 UTC (permalink / raw)
To: Alan Cox; +Cc: fverscheure, linux-kernel, marcelo, andre
In-Reply-To: <1042219407.31848.71.camel@irongate.swansea.linux.org.uk>
> > And by the way how are powered off the IDE drives ?
> > Because a FLUSH CACHE or STANDY or SLEEP is MANDATORY before
> > powering off the drive with cache enabled or you will enjoy lost
> > data.
>
> We always issue standby or sleep commands to a drive before powering
> off which means the cache flush thing should never have been an
> issue.
I experienced drives spinning back up after they had been flushed on
powerdown, which is not necessarily wrong, (I.E. I never noticed any
data loss), but it's not ideal. Can't we do:
* Standby
* Flush
* Standby
or is there a reason not to? I know there were discussions about the
right order to do the standyby and flush, and as far as I remember, we
never reached a conclusion :-).
John.
^ 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.