Linux 2.4.19-pre5

Linux 2.4.19-pre5

[rwhron]

> This release has -aa writeout scheduling changes, which should improve IO
> performance (and interactivity under heavy write loads).

> _Please_ test that extensively looking for any kind of problems
> (performance, interactivity, etc).

2.4.19-pre5 shows a lot of improvement in the tests
I run.  dbench 128 throughput up over 50%

dbench 128 processes
2.4.19-pre4              8.4 ****************
2.4.19-pre5             13.2 **************************

Tiobench sequential writes: 
10-20% more throughput and latency is lower.  

Tiobench Sequential reads
Down 7-8%.   

Andrew Morton's read_latency2 patch improves tiobench 
sequential reads and writes by 10-35% in the tests I've 
run.  More importantly, read_latency2 drops max latency 
with 32-128 tiobench threads from 300-600+ seconds 
down to 2-8 seconds.  (2.4.19-pre5 is still unfair 
to some read requests when threads >= 32)

I'm happy with pre5 and hope more chunks of -aa show 
up in pre6.  Maybe Andrew will update read_latency2 for 
inclusion in pre6. :)  It helps tiobench seq writes too.
dbench goes down a little though.  

Max latency is the metric that stands out as "needs 
improvement" and "fix exists".

tiobench seq reads 128 threads
                   MB/s     max latency
2.4.19-pre1aa1     6.98     661.3 seconds
2.4.19-pre1aa1rl   9.55       7.8 seconds

tiobench seq writes 32 threads
                   MB/s     max latency
2.4.19-pre1aa1    15.46     26.1 seconds
2.4.19-pre1aa1rl  17.31     18.0 seconds

The read latency issue exists on a 4 way xeon
with 4GB ram too.  Max latency jumps to 270 seconds
with 32 tiobench threads, and is over  500 seconds when
threads >= 128.  (latency in milliseconds below)

Sequential Reads
               Num                    Avg       Maximum     Lat%     Lat% 
Kernel         Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s 
-------------- ---  ------------------------------------------------------
2.4.19-pre5      1   38.46 23.94%     0.302      111.14   0.00000  0.00000
2.4.19-pre5     32   30.24 21.69%     9.883   270391.48   0.01106  0.00915
2.4.19-pre5     64   30.08 21.67%    17.868   357219.21   0.01965  0.01807
2.4.19-pre5    128   30.40 22.77%    30.460   520607.27   0.02714  0.02569
2.4.19-pre5    256   29.07 21.96%    56.444   539381.86   0.05378  0.05197


The behemoth benchmark page:
http://home.earthlink.net/~rwhron/kernel/k6-2-475.html

-- 
Randy Hron

Re: Linux 2.4.19-pre5

[Andrew Morton]

rwhron@earthlink.net wrote:
> 
> > This release has -aa writeout scheduling changes, which should improve IO
> > performance (and interactivity under heavy write loads).
> 
> > _Please_ test that extensively looking for any kind of problems
> > (performance, interactivity, etc).
> 
> 2.4.19-pre5 shows a lot of improvement in the tests
> I run.  dbench 128 throughput up over 50%
> 
> dbench 128 processes
> 2.4.19-pre4              8.4 ****************
> 2.4.19-pre5             13.2 **************************

dbench throughput is highly dependent upon the amount of memory
which you allow it to use.  -pre5 is throttling writers based
on the amount of dirty buffers, not the amount of dirty+locked
buffers.   Hence this change.

It's worth noting that balance_dirty() basically does this:

	if (dirty_memory > size-of-ZONE_NORMAL * ratio)
		write_stuff();

That's rather irrational, because most of the dirty buffers
will be in ZONE_HIGHMEM.  So hmmmm.  Probably we should go
across all zones and start writeout if any of them is getting
full of dirty data.  Which may not make any difference....

> Tiobench sequential writes:
> 10-20% more throughput and latency is lower.

The bdflush changes mean that we're doing more write-behind.
So possibly write throughput only *seems* to be better,
because more of it is happening after the measurement period
has ended.  It depends whether tiobench is performing an
fsync, and is including that fsync time in its reporting.
It should be.

> Tiobench Sequential reads
> Down 7-8%.

Dunno.  I can't immediately thing of anything in pre5
which would cause this.
 
> Andrew Morton's read_latency2 patch improves tiobench
> sequential reads and writes by 10-35% in the tests I've
> run.  More importantly, read_latency2 drops max latency
> with 32-128 tiobench threads from 300-600+ seconds
> down to 2-8 seconds.  (2.4.19-pre5 is still unfair
> to some read requests when threads >= 32)

These numbers are surprising.  The get_request starvation
change should have smoothed things out.   Perhaps there's
something else going on, or it's not working right.  If
you could please send me all the details to reproduce this
I'll take a look.  Thanks.

> I'm happy with pre5 and hope more chunks of -aa show
> up in pre6.  Maybe Andrew will update read_latency2 for
> inclusion in pre6. :)  It helps tiobench seq writes too.
> dbench goes down a little though.

http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.19-pre5/


Nice testing report, BTW.  As we discussed off-list, your
opinions, observations and summary are even more valuable than
columns of numbers :)

Have fun with that quad, but don't break it.

I'll get the rest of the -aa VM patches up at the above URL
soonish.  I seem to have found a nutty workload which is returning
extremely occasional allocation failures for GFP_HIGHUSER
requests, which will deliver fatal SIGBUS at pagefault time.
There's plenty of swap available, so this is a snag.

-

Re: Linux 2.4.19-pre5

[Randy Hron]

> > run.  More importantly, read_latency2 drops max latency
> > with 32-128 tiobench threads from 300-600+ seconds
> > down to 2-8 seconds.  (2.4.19-pre5 is still unfair
> > to some read requests when threads >= 32)
> 
> These numbers are surprising.  The get_request starvation
> change should have smoothed things out.   Perhaps there's
> something else going on, or it's not working right.  If
> you could please send me all the details to reproduce this
> I'll take a look.  Thanks.

There was an improvement (reduction) in max latency
during sequential _writes after get_request starvation 
went in.  Tiobench didn't show an improvement for seq _read 
max latency though.  read_latency2 makes the huge difference.

The sequential read max latency walls for various trees looks like:
tree		# of threads
rmap		128
ac		128
marcelo		32
linus		64
2.5-akpm-everything	>128 
2.4 read latency2	>128

I.E. tiobench with threads > the numbers above would probably
give the impression the machine was locked up or frozen if your
read request was the unlucky max.  The average latencies are 
generally reasonable.  It's the max, and % of high latency
requests that varies most between the trees.

Using the updated tiobench.pl in 
http://prdownloads.sourceforge.net/tiobench/tiobench-0.3.3.tar.gz
(actually - http://home.earthlink.net/~rwhron/kernel/tiobench2.pl
which is very similar to the one in tiobench-0.3.3) 

On the 4 way 4GB box:
./tiobench.pl --size 8192 --numruns 3 --block 16384 --threads 1 \
--threads 32 --threads 64 --threads 128 --threads 256.

On the k6-2 with 384M ram:
/tiobench.pl --size 2048 --numruns 3 --threads 8 --threads 16 \
--threads 32 --threads 64 --threads 128

> http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.19-pre5/

Thanks for updating read_latency2!  I'm trying it and your other
patches on 2.4.19-pre5. :)

Re: Linux 2.4.19-pre5

[Ed Sweetman]

On Sat, 2002-03-30 at 16:33, Randy Hron wrote:
> > > run.  More importantly, read_latency2 drops max latency
> > > with 32-128 tiobench threads from 300-600+ seconds
> > > down to 2-8 seconds.  (2.4.19-pre5 is still unfair
> > > to some read requests when threads >= 32)
> > 
> > These numbers are surprising.  The get_request starvation
> > change should have smoothed things out.   Perhaps there's
> > something else going on, or it's not working right.  If
> > you could please send me all the details to reproduce this
> > I'll take a look.  Thanks.
> 
> There was an improvement (reduction) in max latency
> during sequential _writes after get_request starvation 
> went in.  Tiobench didn't show an improvement for seq _read 
> max latency though.  read_latency2 makes the huge difference.
> 
> The sequential read max latency walls for various trees looks like:
> tree		# of threads
> rmap		128
> ac		128
> marcelo		32
> linus		64
> 2.5-akpm-everything	>128 
> 2.4 read latency2	>128
> 
> I.E. tiobench with threads > the numbers above would probably
> give the impression the machine was locked up or frozen if your
> read request was the unlucky max.  The average latencies are 
> generally reasonable.  It's the max, and % of high latency

Is that to say an ac branch (which uses rmap) can do the 128 but is
non-responsive?   I sent a couple mails of my own preliminary runs and
the feel i got when running the test was absolutely no effect on
responsiveness even as the load hit 110.  Of course this is with riel's
preempt patch for 2.4.19-pre4-ac3.  I guess I'll try with threads = 256
just to see if this frozen feeling occurs in preempt kernels as well. 
You dont seem to test them anywhere on your own site.  

Re: Linux 2.4.19-pre5

[Randy Hron]

> > The sequential read max latency walls for various trees looks like:
> > tree		# of threads
> > rmap		128
> > ac		128
> > marcelo		32
> > linus		64
> > 2.5-akpm-everything	>128 
> > 2.4 read latency2	>128
> > 
> > read request was the unlucky max.  

> Is that to say an ac branch (which uses rmap) can do the 128 but is
> non-responsive?   

Thanks for testing!  The more the merrier. :)

unlucky max is the keyword above.    The average latency is okay
in general.  It's the requests that are waiting to get serviced that
may give the impression "it's locked up".   

> the feel i got when running the test was absolutely no effect on
> responsiveness even as the load hit 110.  

I see you did several runs, but the mail wrapped and it's hard to
read your results.   With 644 MB RAM, I wouldn't expect you to
see the "big latency" phenomenon with these scenerios:

128 MB datafiles 128 threads 
384 MB datafiles 1 thread
2048 MB datafiles 8 threads

> preempt patch for 2.4.19-pre4-ac3.  I guess I'll try with threads = 256

That's a good number and maybe a 4096MB datafile based on your RAM.
If you are lucky, only the test's I/O's will win the "unlucky max".
If you're not, just be patient, the machine will survive.

The big latency wall moved from 32 to 128 tiobench threads in 
2.4.19-pre9-ac3 after Alan put in rmap12e.

> just to see if this frozen feeling occurs in preempt kernels as well. 

Yeah, that will be interesting.  

> You dont seem to test them anywhere on your own site.  

Most of the tests I run measure throughput.   Tiobench has the nice
latency metric.  When I tested preempt, it generally had lower 
throughput.  Low latency is important and I'm glad Robert, 
Andrew, Ingo and all the others are improving the kernel in 
that respect.

If you're curious, there is a 2.4.18-pre3 preempt/lockbreak
and low-latency page at 
http://home.earthlink.net/~rwhron/kernel/pe.html

Re: Linux 2.4.19-pre5

[Ed Sweetman]

[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]

Due to evolution's really cool way of wrapping my emails. . i'll attach
the results.   

In this test I wanted to see this lag.  So i switched between virtual
desktops (i have 5) and used irc (eterm + epic).   What i saw was lower
priority (meaning processes with bigger nice values) at one specific
spot in the test would stop responding but all processes at the same
priority level would continue merrily.  I'd say about 5/6 of the way
through the test is where the lower priority processes would stop
responding for a couple seconds.  But they revived pretty quickly, only
paused my typing for a couple moments.  I failed to see any lag at all
during the entire test on like-wise prioritized processes.  I wouldn't
have even known i was running the test if my cpu temp wasn't climbing so
high and the load wasn't 256 on procmeter3.  


As for the throughput debate that always follows the preempt kernel.  I
think it really depends on the kind of io you're doing.  It really
depends on what the program is trying to do with it's io.  
Programs that want to throttle and like to do that sequentially,
probably wont appretiate you stopping it and reading some other part of
the disk for a bit and have it have to go back to where it stopped. 
Almost no userland non-monolithic database apps actually do something
like that.  None that i've come into contact with.  But you choose what
works for your workload.   if i'm running a app that wants control over
the io to itself, i run it with a higher priority than other processes
and you've basically taken away the "preemptiveness" factor and you get
normal kernel performance (theoretically).  seems logical.   

Anyway I digress.   I mean to get into the latency aspect.  Sequential
writes is scary but that's to be expected on ext3.  Random reads is a
concern though.   It shouldn't be that high.  although it was high in
all the tests i ran compared to the other three.    

[-- Attachment #2: ed_tiotest.text --]
[-- Type: text/plain, Size: 2057 bytes --]

Run #2: /usr/bin/tiotest -t 256 -f 8 -r 15 -b 4096 -d . -T    

File size in megabytes, Blk Size in bytes. 
Read, write, and seek rates in MB/sec. 
Latency in milliseconds.
Percent of requests that took longer than 2 and 10 seconds.

Sequential Reads
                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU
Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff
---------------------------- ------ ----- ---  ------------------------------------------------------------
2.4.19-pre4-ac3-preempt       2048  4096  256    9.46 5.271%   181.668    30992.77   3.60280  0.05836   179

Random Reads
                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU
Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff
---------------------------- ------ ----- ---  ------------------------------------------------------------
2.4.19-pre4-ac3-preempt       2048  4096  256    0.67 0.980%  2446.793    14462.86  39.66145  0.00000    68

Sequential Writes
                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU
Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff
---------------------------- ------ ----- ---  ------------------------------------------------------------
2.4.19-pre4-ac3-preempt       2048  4096  256    5.36 5.029%   160.584   209853.98   0.42915  0.37536   107

Random Writes
                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU
Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff
---------------------------- ------ ----- ---  ------------------------------------------------------------
2.4.19-pre4-ac3-preempt       2048  4096  256    0.67 0.533%     0.047        4.50   0.00000  0.00000   125

Re: Linux 2.4.19-pre5

[Andrew Morton]

Andrew Morton wrote:
> 
> ...
> I'll get the rest of the -aa VM patches up at the above URL
> soonish.

http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.19-pre5/aa1/

Rediffed, retested.

>  I seem to have found a nutty workload which is returning
> extremely occasional allocation failures for GFP_HIGHUSER
> requests, which will deliver fatal SIGBUS at pagefault time.
> There's plenty of swap available, so this is a snag.

False alarm.  My test app was not handling SIGBUS inside its SIGBUS
handler. 

-

Re: Linux 2.4.19-pre5

[Randy Hron]

> In this test I wanted to see this lag.  

Just to be clear on what the "max latency" number is, it's the I/O
request within tiobench that waited the longest.  I.E. The process notes
the time before it's ready to make the request, then notes the time
after the request is fullfilled.  With a 2048MB file and a 4096 byte
block, there may be over 500,000 requests.  

It's a relatively small number of requests that have the big latency
wait, so depending on the I/O requests your other applications make
during the test, a long wait may not be obvious, unless one or your
I/O's gets left at the end of the queue for a long time. 

This is sometimes referred to as a "corner case".  

The point where the "# of threads" manifests the "big latency
wall" is to note a dramatic change in longest I/O latency. This
point varies between the kernel trees.

The "big latency phenomenon" has been in the 2.4 tree at least
since 2.4.17 which is the first kernel I have this measurement
for.  It probably goes back much further.

read_latency2
-------------
I tested read_latency2 with 2.4.19-pre5.    pre5 vanilla hits
a wall at 32 tiobench threads for sequential reads.  With
read_latency2, the wall is around 128.

For random reads, pre5 hits a wall at 64 threads.  With
read_latency2, the wall is not apparent even with 128 threads.

read_latency2 appears to reduce sequential write latency
too, but not as dramatically as in the read tests.

Re: Linux 2.4.19-pre5

[Ed Sweetman]

On Sun, 2002-03-31 at 07:42, Randy Hron wrote:
> > In this test I wanted to see this lag.  
> 
> Just to be clear on what the "max latency" number is, it's the I/O
> request within tiobench that waited the longest.  I.E. The process notes
> the time before it's ready to make the request, then notes the time
> after the request is fullfilled.  With a 2048MB file and a 4096 byte
> block, there may be over 500,000 requests.  
> 
> It's a relatively small number of requests that have the big latency
> wait, so depending on the I/O requests your other applications make
> during the test, a long wait may not be obvious, unless one or your
> I/O's gets left at the end of the queue for a long time. 
> 
> This is sometimes referred to as a "corner case".  
> 
> The point where the "# of threads" manifests the "big latency
> wall" is to note a dramatic change in longest I/O latency. This
> point varies between the kernel trees.
> 
> The "big latency phenomenon" has been in the 2.4 tree at least
> since 2.4.17 which is the first kernel I have this measurement
> for.  It probably goes back much further.
> 
> read_latency2
> -------------
> I tested read_latency2 with 2.4.19-pre5.    pre5 vanilla hits
> a wall at 32 tiobench threads for sequential reads.  With
> read_latency2, the wall is around 128.
> 
> For random reads, pre5 hits a wall at 64 threads.  With
> read_latency2, the wall is not apparent even with 128 threads.
> 
> read_latency2 appears to reduce sequential write latency
> too, but not as dramatically as in the read tests.
> 


I think the preempt kernel shows is that the big latency phenomenon does
not manifest. Rather, if there is a latency spike, it's effect does not
hurt the preempt kernel because that latency is contained within that
process only, it will not effect other processes.  At least that's what
I observed with tiobench.   Do you have any tests specifically that
you'd like me to run to somehow show this wall?    I understand that
there is a latency problem in the kernels ... but the factor that makes
the big difference is whether this is detrimental to things not creating
the problem.  You said it makes the box look like it's halted in your
tests, I saw no such thing.  

Heh, maybe i'm confused on your definition of the wall.  I understand
the latency wall as the point where latency makes the computer
unreactive to the user. If this is true then the preempt kernel has no
wall as far as I can see, at normal priorities it is always reactive to
the user with tiobench.  

If it's just a point where latency >2s is above a certain arbituary
number, then it really depends on the media you're running the io test
on.  

Also, how is it possible to get >100% cpu efficiency, as shown in some
of my results for tiobench? 

Perhaps you see this wall because of how the kernel decides what to swap
in and out of it's swap space.  If you keep your swapfile on the drive
you're testing on, you would create periods which nothing responds as
the system tries swapping it back in, as well as slowing down your
test.   I keep swap on a separate drive on a different controller.
Although, I get little swap activity, couple KB during the test after a
few runs.  Ok, i'm out of ideas.

Re: Linux 2.4.19-pre5

[Randy Hron]

> the problem.  You said it makes the box look like it's halted in your
> tests, I saw no such thing.  

I haven't directly observed any box tightening up for
more than a few seconds.  There have been a few reports
on lkml of things like that happening.  Based on tiotest
results, I can see if the I/O request you are waiting for 
is one of those few that isn't serviced for dozens or
hundreds of seconds, you'll be annoyed.  

The number of requests that takes over 10 seconds is 
often just 3 in 10,000.  There may be only 1 request in 
500,000 that takes 500 seconds to service.  The chance 
of your interactive i/o being the "longest" is small, unless
your interactive work is producing enough I/O to compete
with tiotest.  

What I like about read_latency2 is that most latencies
are less, and the highest latency is much less.
 
> Heh, maybe i'm confused on your definition of the wall. 

Sorry if that wasn't clear.  "The wall" is the point where
the highest latency in the test skyrockets.

For instance, in recent ac kernels, the _highest_ latency for 
sequential reads is less than 5 seconds at 64 threads in all 
the ac's I've tested.  At 128 threads, the _lowest_ max
latency figure is 200 seconds.   So, I used the "wall" term 
for 128 in the ac series.

Similarly, in the Marcelo tree, 1.7 seconds is the _highest_
latency with 16 threads in all the mainline kernels I've tested.
At 32 threads, 137 seconds is the _lowest_ maximum latency.
So I used the idea "wall = 32 threads" for 2.4 mainline.

The actual number of seconds will vary depending on the
hardware.  I've observed the "skyrocketing" max latency
or "wall" phenomemon on several boxes though.

The max latency growth before and after "the wall" is similar
as threads increase.  That is max latency grows slowly, then
jumps enormously, then grows gradually again.

A little picture, not to scale:
m                                        x
a                               x
x                       x                *

l
a
t
e
n
c
y

s
e
q
                                         #
r
e ........ the wall ......................
a                               #
d                       #       *
s               x       * 
       x*#      *#
threads 8       16      32      64      128

* = ac
x = mainline
# = read_latency2

The "not to scale" means the distance between points 
above and below "the wall" is actually much greater.

If you feel like it, perhaps you could test ac with preempt 
and 8 16 32 64 128 256 threads and see if exhibits a wall
pattern or not.  

Thanks for your interest.

Re: Linux 2.4.19-pre5

[Andrea Arcangeli]

On Sat, Mar 30, 2002 at 10:52:00PM -0800, Andrew Morton wrote:
> False alarm.  My test app was not handling SIGBUS inside its SIGBUS
> handler. 

Good :). BTW, sigbus should never indicate an oom failure, SIGKILL is
always sent in such a case. If it would came out of a pagefault it would
mean it was a MAP_SHARED access beyond the end of the file.

thanks,

Andrea

Re: Linux 2.4.19-pre5

[Andrea Arcangeli]

On Sat, Mar 30, 2002 at 11:49:06AM -0800, Andrew Morton wrote:
> That's rather irrational, because most of the dirty buffers
> will be in ZONE_HIGHMEM.  So hmmmm.  Probably we should go

You're right it's not the best, but it's intentional and correct. We've
just one single balance_dirty(void) and it has to balance metadata and
data, data will be in highmem too, but metadata will be in normal zone
for most filesystems (even ext[23], modulo direntries for ext2) and
that's why we've to consider only the normal zone as a certain target of
the allocation, to be sure not to overstimate for metadata. OTOH in
particular to take full advantage of the point of view watermarks it
would be really nicer to say if we've to balance_dirty on the normal
zone or on the highmem zone (currently we could overstimate a bit the
amount of ram we can take from the normal zone with an highmem
allocation (we look at the the high watermark from the "normal" point of
view), but OTOH we always understimate the amount of potential highmem
free), so the current way is mostly ok for now (not a showstopper). To
improve that bit we simply need a kind of "zone" argument to
balance_dirty() API, done that the other changes should be a formality.

Andrea

Re: Linux 2.4.19-pre5

[Tom Holroyd]

On Tue, 16 Apr 2002, Andrea Arcangeli wrote:

> there are no mm diffs between pre1 and pre2. The first mm changes are in
> pre5.

I was referring to the changes in mm/, such as mm/filemap.c,
mm/mmap.c, mm/page_alloc.c, etc., all of which were rather extensive
in -pre2, and contained some 64 bit specific stuff.

As I mentioned to Marcelo earlier, I have been able to get ~5 sec
mouse freezes on my Alpha.  Right now I'm running -pre7, and I just
reproduced it.  The only way I know of to do it is run a certain
graphics program that's work-related, plot something, switch screens
(in the 'I have a 4x4 virtual desktop' sense), run a big filter job
that reads about 200-300 meg in, filters it, and writes it back out
(alternatively, I can scroll through a directory full of images, so
maybe it only has to have a few hundred meg read in), then switch
back to the graphics screen and hit "refresh".  It does not work every
time, but I certainly notice it when it happens.  Note that after I've
done it once, it's much harder to reproduce.  Of course, that maybe
depends on the phase of the moon, because I reproduced it twice in a
row this morning, with profiling data the second time.  Here's the
list of routines that got ticks (as reported by readprofile) during
the ~3 sec freeze I just caused:

1 alloc_skb
1 alpha_switch_to
1 cached_lookup
1 collect_sigign_sigcatch
1 copy_page
1 del_timer
1 dentry_open
1 do_no_page
1 do_page_fault
1 do_switch_stack
1 fput
1 generic_file_read
1 generic_file_write
1 get_gendisk
1 iput
1 link_path_walk
1 locks_remove_flock
1 poll_freewait
1 read_aux
1 remove_wait_queue
1 restore_all
1 schedule
1 scsi_dispatch_cmd
1 session_of_pgrp
1 sock_alloc_send_pskb
1 sys_close
1 sys_ioctl
1 sys_select
1 undo_switch_stack
1 unix_poll
1 unix_stream_sendmsg
1 vsprintf
2 clear_page
2 generic_file_readahead
2 number
2 sock_poll
2 tcp_poll
2 update_atime
3 __free_pages
3 add_wait_queue
3 kfree
3 vsnprintf
4 entSys
4 fget
5 do_select
5 handle_IRQ_event
7 __copy_user
7 sys_read
8 __divqu
10 __remqu
10 do_generic_file_read
18 entInt
19 keyboard_interrupt

I've done this quite a few times now, and add_wait_queue &
__free_pages are always there.  (Well, and keyboard_interrupt, but
that's not it.)  Other things are more random, but it's hard to judge
precisely (I'm not sure how the profiling works but I assume short
routines can be easily missed).

This is an AlphaPC 264DP 666 MHz (uniprocessor version, non-SMP
kernel).  1GB RAM.  AHA-2940U/UW SCSI on the PCI bus along
with a Permedia 2 graphics card.

Re: Linux 2.4.19-pre5

[Andrea Arcangeli]

On Fri, Apr 05, 2002 at 01:13:30PM +0900, Tom Holroyd wrote:
> On Thu, 4 Apr 2002, Marcelo Tosatti wrote:
> 
> > Could you please try to reproduce with 2.4.19-pre4 ?
> 
> OK, I could, so I searched back and -pre1 was OK.  This behavior
> showed up in -pre2.  It seems to be related to the mm changes.
> Unfortunately I don't know how to back those out safely to check that.
> 
> To repeat, I set up a window that has to be redrawn (no backing
> store), then use ee (electric eyes) to scroll through 50 or so JPGs
> then go back to redraw the aforementioned window.  In -pre2 I get 5
> sec freezes and no disk IO during the interval, so it seems like a
> memory management thing.
> 
> Any tests I could do?  A -pre2 patch without the mm changes?

there are no mm diffs between pre1 and pre2. The first mm changes are in
pre5.

Andrea

Re: Linux 2.4.19-pre5

[Tom Holroyd]

On Thu, 4 Apr 2002, Marcelo Tosatti wrote:

> Could you please try to reproduce with 2.4.19-pre4 ?

OK, I could, so I searched back and -pre1 was OK.  This behavior
showed up in -pre2.  It seems to be related to the mm changes.
Unfortunately I don't know how to back those out safely to check that.

To repeat, I set up a window that has to be redrawn (no backing
store), then use ee (electric eyes) to scroll through 50 or so JPGs
then go back to redraw the aforementioned window.  In -pre2 I get 5
sec freezes and no disk IO during the interval, so it seems like a
memory management thing.

Any tests I could do?  A -pre2 patch without the mm changes?

> On Thu, 4 Apr 2002, Tom Holroyd wrote:
>
> > AlphaPC 264DP 666 MHz (Tsunami, UP)
> > 1GB RAM
> > gcc version 3.0.3
> > ... a window that should
> > refresh (no backing store) right away causes long (2~5 sec) freezes.

Re: Linux 2.4.19-pre5

[Marcelo Tosatti]

Andre? 

On Thu, 4 Apr 2002, Adrian Bunk wrote:

> Hi Marcelo,
> 
> Configure.help contains the help text below that sounds more like a
> comment to a patch than a helpful help message for a user of a stable
> kernel:
> 
> +CONFIG_IDE_TASKFILE_IO
> +  This is the "Jewel" of the patch.  It will go away and become the new
> +  driver core.  Since all the chipsets/host side hardware deal w/ their
> +  exceptions in "their local code" currently, adoption of a
> +  standardized data-transport is the only logical solution.
> +  Additionally we packetize the requests and gain rapid performance and
> +  a reduction in system latency.  Additionally by using a memory struct
> +  for the commands we can redirect to a MMIO host hardware in the next
> +  generation of controllers, specifically second generation Ultra133
> +  and Serial ATA.
> +
> +  Since this is a major transition, it was deemed necessary to make the
> +  driver paths buildable in separtate models.  Therefore if using this
> +  option fails for your arch then we need to address the needs for that
> +  arch.
> +
> +  If you want to test this functionality, say Y here.
> 
> Could anyone provide a more useful help text?
> 
> TIA
> Adrian
> 
> 

Re: Linux 2.4.19-pre5

[Adrian Bunk]

Hi Marcelo,

Configure.help contains the help text below that sounds more like a
comment to a patch than a helpful help message for a user of a stable
kernel:

+CONFIG_IDE_TASKFILE_IO
+  This is the "Jewel" of the patch.  It will go away and become the new
+  driver core.  Since all the chipsets/host side hardware deal w/ their
+  exceptions in "their local code" currently, adoption of a
+  standardized data-transport is the only logical solution.
+  Additionally we packetize the requests and gain rapid performance and
+  a reduction in system latency.  Additionally by using a memory struct
+  for the commands we can redirect to a MMIO host hardware in the next
+  generation of controllers, specifically second generation Ultra133
+  and Serial ATA.
+
+  Since this is a major transition, it was deemed necessary to make the
+  driver paths buildable in separtate models.  Therefore if using this
+  option fails for your arch then we need to address the needs for that
+  arch.
+
+  If you want to test this functionality, say Y here.

Could anyone provide a more useful help text?

TIA
Adrian

Re: Linux 2.4.19-pre5

[Marcelo Tosatti]

Could you please try to reproduce with 2.4.19-pre4 ?

Thanks

On Thu, 4 Apr 2002, Tom Holroyd wrote:

> AlphaPC 264DP 666 MHz (Tsunami, UP)
> 1GB RAM
> gcc version 3.0.3
> 
> Running stuff as usual, reading large files, I can often get
> very long mouse freezes when redrawing a certain window in X after
> leaving it for a while.  I never saw this behavior in 2.4.18-rc1,
> which I ran for over 1 month doing the same stuff.  vmstat doesn't
> report swapping activity that I can see, just a window that should
> refresh (no backing store) right away causes long (2~5 sec) freezes.

Re: Linux 2.4.19-pre5

[Tom Holroyd]

AlphaPC 264DP 666 MHz (Tsunami, UP)
1GB RAM
gcc version 3.0.3

Running stuff as usual, reading large files, I can often get
very long mouse freezes when redrawing a certain window in X after
leaving it for a while.  I never saw this behavior in 2.4.18-rc1,
which I ran for over 1 month doing the same stuff.  vmstat doesn't
report swapping activity that I can see, just a window that should
refresh (no backing store) right away causes long (2~5 sec) freezes.

Re: Linux 2.4.19-pre5

[Michal Jaegermann]

On Sun, Mar 31, 2002 at 09:34:42AM +1000, Keith Owens wrote:
> On Sat, 30 Mar 2002 13:40:17 -0700, 
> Michal Jaegermann <michal@harddata.com> wrote:
> >
> >On Fri, Mar 29, 2002 at 06:47:39PM -0300, Marcelo Tosatti wrote:
> >> 
> >> Here goes pre5.
> >
> >Tried to recompile that on Alpha and I run into module symbol
> >troubles of that sort:
> >
> >depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 20414130 >= 000000d6
> >depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 74202a2f >= 000000d6
> >depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 0a2f2a20 >= 000000d6
> >depmod: Bad symbol index: 20414130 >= 000000d6
> >depmod: Bad symbol index: 74202a2f >= 000000d6
> >depmod: Bad symbol index: 0a2f2a20 >= 000000d6
> 
> That is almost always caused by bad output from binutils.

Thanks to the helpful comment from Keith the matter is resolved.  The
box in which this happened still has "issues" and apparently decided
that it is time for one of its surprises.  That trident.o module
recreated from scratch looks ok.

  Thanks,
  Michal

Re: Linux 2.4.19-pre5

[Keith Owens]

On Sat, 30 Mar 2002 13:40:17 -0700, 
Michal Jaegermann <michal@harddata.com> wrote:
>
>On Fri, Mar 29, 2002 at 06:47:39PM -0300, Marcelo Tosatti wrote:
>> 
>> Here goes pre5.
>
>Tried to recompile that on Alpha and I run into module symbol
>troubles of that sort:
>
>depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 20414130 >= 000000d6
>depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 74202a2f >= 000000d6
>depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 0a2f2a20 >= 000000d6
>depmod: Bad symbol index: 20414130 >= 000000d6
>depmod: Bad symbol index: 74202a2f >= 000000d6
>depmod: Bad symbol index: 0a2f2a20 >= 000000d6

That is almost always caused by bad output from binutils.  It could be
a modutils bug but I doubt it, every previous occurrence has been a
binutils problem.  Send me (not the list) the output from
readelf -es /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o

Before sending the output, try rebuilding the kernel from scratch.  It
is unlikely to help but worth a try.

Re: Linux 2.4.19-pre5

[Michal Jaegermann]

On Fri, Mar 29, 2002 at 06:47:39PM -0300, Marcelo Tosatti wrote:
> 
> Here goes pre5.

Tried to recompile that on Alpha and I run into module symbol
troubles of that sort:

depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 20414130 >= 000000d6
depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 74202a2f >= 000000d6
depmod: /lib/modules/2.4.19-pre5/kernel/drivers/sound/trident.o: Bad symbol index: 0a2f2a20 >= 000000d6
depmod: Bad symbol index: 20414130 >= 000000d6
depmod: Bad symbol index: 74202a2f >= 000000d6
depmod: Bad symbol index: 0a2f2a20 >= 000000d6

Any ideas where these are coming from?  Nothing of that sort cropped out
in 2.4.19-pre4.  modutils are 2.4.13 which should be good enough if one
believes in Documentation/Changes.

As I am not really using 'trident' module right now this was not a
big obstacle to boot and run that kernel. :-)

  Michal

Linux 2.4.19-pre5

[Marcelo Tosatti]

Hi, 

Here goes pre5. I've trimmed down the changelog because its just too big,
and the ones who actually want to see all changelog can get it from
linux.bkbits.net.

This release has -aa writeout scheduling changes, which should improve IO
performance (and interactivity under heavy write loads).

_Please_ test that extensively looking for any kind of problems
(performance, interactivity, etc).



Summary of changes from v2.4.19-pre4 to v2.4.19-pre5
============================================

<sawa@yamamoto.gr.jp> (02/03/15 1.197.1.1)
	Fix bug in at1700 net driver:

<jgarzik@mandrakesoft.com> (02/03/15 1.197.1.2)
	pcnet32 net driver update 1/6:

<anton@samba.org> (02/03/15 1.197.1.3)
	pcnet32 net driver updates 2/6:

<anton@samba.org> (02/03/15 1.197.1.4)
	pcnet32 net driver updates 3/6:

<anton@samba.org> (02/03/15 1.197.1.5)
	pcnet32 net driver updates 4/6:

<anton@samba.org> (02/03/15 1.197.1.6)
	pcnet32 net driver updates 5/6:

<anton@samba.org> (02/03/15 1.197.1.7)
	pcnet32 net driver updates 6/6:

<jes@wildopensource.com> (02/03/15 1.197.1.8)
	acenic gige net driver update:

<jes@wildopensource.com> (02/03/15 1.197.1.9)
	acenic driver fixes:

<jt@bougret.hpl.hp.com> (02/03/15 1.197.1.10)
	Convert hp100 net driver to PCI DMA mapping API.

<jgarzik@mandrakesoft.com> (02/03/15 1.197.1.11)
	Don't include linux/delay.h twice in eepro100 net driver.

<davem@nuts.ninka.net> (02/03/19 1.181.2.10)
	Netfilter enhancement from Harald Welte and Netfilter team.

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.11)
	Remove obsolete confusing instructions on tcp_max_syn_backlog

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.12)
	Make pkt_sched.h:PSCHED_TDIFF_SAFE behave sane when measuring

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.13)
	Remove unused field from TCP struct open_request.

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.14)
	Do not fail creating _new_ NOARP entry with EPERM.

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.15)
	Old bug in skbuff.c, found by someone, but was lost.

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.16)
	IPv4 FIB routing fixes:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.17)
	In IPv4 ICMP:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.18)
	Fix for ipv4 tunnel devices:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.19)
	IP input fixes:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.20)
	Terrible bug in ipv4/route.c, mis-sized ip_rt_acct leads to

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.21)
	TCP Input fixes:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.22)
	UDP fixes:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.23)
	IPV6 addrconf exploit fix:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.24)
	IPv6 neighbour discovery fixes:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.25)
	TCP ipv6 fixes:

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.26)
	Port of 2.2.x AF_PACKET bug fix.

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.27)
	Fix bug in sch_prio.c where wrong handle was

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.28)
	In sch_sfq.c, allow to descrease length of queue

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.29)
	Add new sysctl, medium_id, to devinet.

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.30)
	Forgotten portion of "kill unused struct open_request" changes.

<kuznet@ms2.inr.ac.ru> (02/03/19 1.181.2.31)
	Allow to bind to an already in use local port

<davem@nuts.ninka.net> (02/03/19 1.189.1.1)
	Update sparc64 defconfig.

<kanojsarcar@yahoo.com> (02/03/19 1.189.1.2)
	Move VPTE_BASE_foo definitions to common

<kraxel@bytesex.org> (02/03/20 1.221)
	fix compile error due to recent videodev changes

<kraxel@bytesex.org> (02/03/20 1.222)
	fix compile error due to recent videodev changes

<edward_peng@dlink.com.tw> (02/03/20 1.220.1.3)
	Update dl2k gigabit ethernet driver to watch RX in case of lockup.

<jgarzik@mandrakesoft.com> (02/03/20 1.220.1.4)
	dl2k net driver updates:

<jgarzik@mandrakesoft.com> (02/03/20 1.220.1.5)
	Add pci id to orinoco_plx wireless driver (Brendan McAdams)

<jgarzik@mandrakesoft.com> (02/03/20 1.220.2.2)
	Add two AC97 codec ids to the OSS ac97_codec driver.

<jes@wildopensource.com> (02/03/20 1.220.1.6)
	Update acenic gigabit ethernet driver to clean up VLAN support integration.

<k.kasprzak@box43.pl> (02/03/20 1.220.1.7)
	de620 net driver janitor fixes:

<silicon@falcon.sch.bme.hu> (02/03/20 1.220.2.3)
	Update munich WAN driver to not kfree memory multiple times.

<jgarzik@mandrakesoft.com> (02/03/20 1.220.1.8)
	s/kfree/kfree_skb/ in drivers/s390/net/ctctty.c.

<jgarzik@mandrakesoft.com> (02/03/20 1.220.1.9)
	(sync with 2.5.x.  in 2.4.x, this is just a cosmetic change)

<brownfld@irridia.com> (02/03/20 1.220.1.10)
	Support second port on dual-port SysConnect SK-9844 NICs.

<p_gortmaker@yahoo.com> (02/03/20 1.220.1.11)
	MODULE_DESC net drivers cleanup.

<go@turbolinux.co.jp> (02/03/20 1.220.1.12)
	Update pcnet32 net driver with the following changes:

<arjanv@redhat.com> (02/03/20 1.220.1.13)
	Revert xircom_cb net driver back to earlier version which works in all cases.

<arjanv@redhat.com> (02/03/20 1.220.1.14)
	Increase eepro100 net driver tx/rx ring sizes, to be more appropriate for 100mbit

<arjanv@redhat.com> (02/03/20 1.220.1.15)
	Add eepro100 net driver rx soft reset function.

<arjanv@redhat.com> (02/03/20 1.220.1.16)
	Implement RX soft reset for certain cases in eepro100 net driver.

<arjanv@redhat.com> (02/03/20 1.220.1.17)
	Update eepro100 net driver to properly enable/disable software timer

<arjanv@redhat.com> (02/03/20 1.220.1.18)
	eepro100 net driver h/w bug workaround updates:

<arjanv@redhat.com> (02/03/20 1.220.1.19)
	Move pci_enable_device and associated code above first PCI resource info access.

<jgarzik@mandrakesoft.com> (02/03/20 1.220.1.20)
	Build fix: include linux/crc32.h in bmac net driver.

<jgarzik@mandrakesoft.com> (02/03/20 1.220.1.21)
	Merge include/asm-i386/checksum.h from 2.5.7.

<jgarzik@mandrakesoft.com> (02/03/20 1.220.1.22)
	Revert 2.4.18 epic100 net driver power-up sequence "fix".

<davem@nuts.ninka.net> (02/03/20 1.189.1.3)
	In sparc64/ebus, handle machines with both RIO and

<davem@nuts.ninka.net> (02/03/20 1.189.1.4)
	On sparc64 Schizo PCI controllers, there is no inofixup

<davem@nuts.ninka.net> (02/03/20 1.189.1.5)
	On sparc64, handle assigning ROM and non-standard resources

<davem@nuts.ninka.net> (02/03/20 1.189.1.6)
	In Sun GEM/HME drivers, if OpenBoot firmware is not

<davem@nuts.ninka.net> (02/03/20 1.189.1.7)
	Model Sparc64 pci_assign_resource more closely to the

<davem@nuts.ninka.net> (02/03/20 1.189.1.8)
	SunHME net driver cleanups:

<davem@nuts.ninka.net> (02/03/20 1.181.2.32)
	Bonding driver updates:

<dwmw2@infradead.org> (02/03/21 1.220.2.5)
	 The safe parts of the newer MTD code:

<davem@nuts.ninka.net> (02/03/21 1.189.1.9)
	In Sun GEM/HME drivers, if pci_assign_resource of PCI ROM fails,

<dwmw2@infradead.org> (02/03/21 1.220.2.6)
	Merge

<davem@nuts.ninka.net> (02/03/21 1.189.1.10)
	Remove debugging printk while probing MAC address.

<davem@nuts.ninka.net> (02/03/21 1.189.1.11)
	Sun HME/GEM driver probing cleanups.

<davem@nuts.ninka.net> (02/03/21 1.181.2.33)
	Add missing KERN_foo printk specifiers to networking.

<uzi@uzix.org> (02/03/21 1.189.1.12)
	Merge 2.4.x VGER sparc32 changes into 2.4.19

<laforge@gnumonks.org> (02/03/21 1.181.2.34)
	Add configure Configure.help message and

<wstinson@infonie.fr> (02/03/21 1.189.1.13)
	Remove explicit initialization of static vars to zero

<cruault@724.com> (02/03/21 1.181.2.35)
	Make sure outgoing ICMP and TCP resets

<davem@nuts.ninka.net> (02/03/21 1.189.1.14)
	Move bootstr_valid/bootstr_buf back into .data section.

<dwmw2@dwmw2.baythorne.internal> (02/03/22 1.220.2.7)
	Add drivers/mtd/mtdconcat.o to export-objs

<dwmw2@infradead.org> (02/03/22 1.220.2.8)
	Make the partial MTD merge actually compile without warnings.

<dwmw2@infradead.org> (02/03/22 1.220.2.9)
	Minor JFFS2 fixes.

<davem@nuts.ninka.net> (02/03/22 1.181.2.36)
	Code (and commentary) in SYN-RECEIVED processing

<marcelo@plucky.distro.conectiva> (02/03/22 1.220.1.24)
	Add Promise 20276 to supported IDE controllers

<kaos@ocs.com.au> (02/03/22 1.220.1.25)
	[PATCH] 2.4.19-pre4 remove include modversions.h

<sfr@canb.auug.org.au> (02/03/22 1.220.1.26)
	[PATCH] APM missing bits from 2.4.19-pre4

<hch@infradead.org> (02/03/22 1.220.1.27)
	[PATCH] Alpha extern inline -> static inline

<hch@infradead.org> (02/03/22 1.220.1.28)
	[PATCH] alpha lseek prototype

<hch@infradead.org> (02/03/22 1.220.1.29)
	[PATCH] Alpha exports

<hch@infradead.org> (02/03/22 1.220.1.30)
	[PATCH] Alpha fixes for hashed page waitqueues from -aa

<davem@nuts.ninka.net> (02/03/22 1.181.2.37)
	Bump TcpPassiveOpens when tcp_create_openreq_child succeeds.

<hch@infradead.org> (02/03/22 1.220.1.32)
	[PATCH] remove wake_up_page

<marcelo@plucky.distro.conectiva> (02/03/22 1.220.1.33)
	Remove Pacific Digital A-DMA support in Config.in

<alfre@IBD.es> (02/03/22 1.220.1.34)
	[PATCH] Too much debug info from ide-tape

<akpm@zip.com.au> (02/03/22 1.220.1.37)
	[PATCH] smaller kernels

<axboe@suse.de> (02/03/22 1.220.1.38)
	[PATCH] UDF read-write 2.4.19-pre4 bug

<rusty@rustcorp.com.au> (02/03/22 1.220.1.39)
	[PATCH] 2.4.19-pre4 Trivial II: APM update

<rusty@rustcorp.com.au> (02/03/22 1.220.1.40)
	[PATCH] 2.4.19-pre4 Trivial III: SAK message.

<marcelo@plucky.distro.conectiva> (02/03/22 1.220.1.42)
	When writing too little (0) or too much (>num_physpages) of microcode data

<bunk@fs.tum.de> (02/03/22 1.220.1.43)
	[PATCH] s/malloc.h/slab.h/ in sis_ds.c

<bunk@fs.tum.de> (02/03/22 1.220.1.44)
	[PATCH] Don't offer CONFIG_INDYDOG on non-ip22 machines

<akpm@zip.com.au> (02/03/22 1.220.1.45)
	[PATCH] x86 BUG handling

<greg@kroah.com> (02/03/22 1.220.6.1)
	USB visor driver

<marcelo@plucky.distro.conectiva> (02/03/22 1.220.1.46)
	Remove option to use the noop elevator

<petkan@mastika.> (02/03/22 1.220.6.2)
	USB pegasus driver

<oliver@oenone.homelinux.org> (02/03/22 1.220.6.3)
	USB hpusbscsi driver

<oliver@oenone.homelinux.org> (02/03/22 1.220.6.4)
	USB kaweth driver

<paschal@rcsis.com> (02/03/22 1.220.6.5)
	USB printer driver

<vojtech@suse.cz> (02/03/22 1.220.6.6)
	USB HID driver

<nemosoft@smcc.demon.nl> (02/03/22 1.220.6.7)
	USB pwc driver

<john@larvalstage.com> (02/03/22 1.220.1.47)
	[PATCH] trivial borken compile fixes for 2.4.19-pre4

<greg@kroah.com> (02/03/22 1.220.6.8)
	USB hub

<greg@kroah.com> (02/03/22 1.220.6.9)
	USB hub

<ganesh@tuxtop.vxindia.veritas.com> (02/03/22 1.220.6.10)
	USB ipaq driver

<david-b@pacbell.net> (02/03/22 1.220.6.11)
	USB ohci and unlink-in-completion

<david-b@pacbell.net> (02/03/22 1.220.6.12)
	USB update documentation

<johannes@erdfelt.com> (02/03/22 1.220.6.13)
	USB uhci driver update

<greg@kroah.com> (02/03/22 1.220.6.14)
	USB core

<david-b@pacbell.net> (02/03/22 1.220.6.15)
	USB usbfs periodic endpoint/bandwidth reporting

<rmk@flint.arm.linux.org.uk> (02/03/23 1.220.7.1)
	Initial update - all ARM files to 2.4.18-rmk3.

<marcelo@plucky.distro.conectiva> (02/03/25 1.220.1.48)
	Import PPC64 port

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.224)
	[PATCH] Neomagic frame buffer author

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.225)
	[PATCH] PATCH: reiserfs stuff

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.226)
	[PATCH] PATCH: updated IDE - docs

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.227)
	[PATCH] PATCH: docs for neomagic fb

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.228)
	[PATCH] PATCH: docs for 3c509

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.229)
	[PATCH] PATCH: docs for RME hammerfall

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.230)
	[PATCH] PATCH: Updated Andre info

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.231)
	[PATCH] PATCH: printk levels

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.232)
	[PATCH] PATCH: comment fix

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.233)
	[PATCH] PATCH: printk level fix

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.234)
	[PATCH] PATCH: ITE8330 IRQ router

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.235)
	[PATCH] PATCH: printk levels ctd

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.236)
	[PATCH] PATCH: more printk levels

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.237)
	[PATCH] PATCH: new XD signature

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.238)
	[PATCH] PATCH: config.in fix

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.239)
	[PATCH] PATCH: add config for mk712 touchscreen

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.240)
	[PATCH] PATCH: config.in for AMD768 rng

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.241)
	[PATCH] PATCH: Ali watchdog

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.242)
	[PATCH] PATCH: mk712 touchscreen

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.243)
	[PATCH] PATCH: natsemi watchdogs

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.244)
	[PATCH] PATCH: update w83 watchdog

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.245)
	[PATCH] PATCH: add wafer watchdog

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.246)
	[PATCH] PATCH: wdt/wdt_pci fixes and cleanup

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.247)
	[PATCH] PATCH: fix timeout in zoran driver

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.248)
	[PATCH] PATCH: fix config/makefile crud

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.249)
	[PATCH] PATCH: fix timeout in arlan

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.250)
	[PATCH] PATCH: update MPT fusion drivers to 2.0 to handle new boards

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.251)
	[PATCH] PATCH: fix iph5526 to relax cpu

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.252)
	[PATCH] PATCH: fix resource bug in lance

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.253)
	[PATCH] PATCH: compile warning fix

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.254)
	[PATCH] PATCH: fix resource handling in wd.c

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.255)
	[PATCH] PATCH: Add ZV bus to Ricoh cards

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.256)
	[PATCH] PATCH: new style initializers for s390 hwcon

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.257)
	[PATCH] PATCH: time_foo for gdth

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.258)
	[PATCH] PATCH: time_fu for qlogic

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.259)
	[PATCH] PATCH: add another sparselun entry

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.260)
	[PATCH] PATCH: rme hammerfall update

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.261)
	[PATCH] PATCH: minor sound bits

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.262)
	[PATCH] PATCH: missing dependancy

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.263)
	[PATCH] PATCH: missing reparent_to_init

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.264)
	[PATCH] PATCH: more time fixes

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.265)
	[PATCH] PATCH: printk level

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.266)
	[PATCH] PATCH: minor number for mk712

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.267)
	[PATCH] PATCH: acct race fix

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.268)
	[PATCH] PATCH: fix strange httpd logging bug

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.269)
	[PATCH] PATCH: help for patch-kernel

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.270)
	[PATCH] PATCH: config changes to enable neomagic to be selected

<alan@lxorguk.ukuu.org.uk> (02/03/25 1.271)
	[PATCH] PATCH: char Makefile - new watchdogs, mk712 etc

<marcelo@plucky.distro.conectiva> (02/03/25 1.273)
	Re-add all asserts removed by akpm's out-of-line-BUG patch

<marcelo@plucky.distro.conectiva> (02/03/25 1.274)
	ieee1394 update

<marcelo@plucky.distro.conectiva> (02/03/25 1.275)
	Makes rd_load_image() return 0 if it had failed and 1 if it was

<marcelo@plucky.distro.conectiva> (02/03/25 1.276)
	initrd_load() moved to do_mounts.c; assigning DEV_ROOT in case of

<marcelo@plucky.distro.conectiva> (02/03/25 1.277)
	code that deals with spawning /linuxrc, waiting for it, calling

<marcelo@plucky.distro.conectiva> (02/03/25 1.278)
	new helper - mount_block_root() (code that goes through the list

<marcelo@plucky.distro.conectiva> (02/03/25 1.279)
	minor cleanups - mount_root() used to be followed by the same code

<marcelo@plucky.distro.conectiva> (02/03/25 1.280)
	branch after the successful initrd_load() taken into a helper

<marcelo@plucky.distro.conectiva> (02/03/25 1.281)
	instead of mounting/umounting devfs on /dev (rootfs one) in

<marcelo@plucky.distro.conectiva> (02/03/25 1.282)
	new helper - create_dev(name, dev, devfs_name).  It either

<marcelo@plucky.distro.conectiva> (02/03/25 1.283)
	change_root() merged into its caller (handle_initrd()).  More

<marcelo@plucky.distro.conectiva> (02/03/25 1.284)
	rd_load() and rd_load_secondary() merged into their resp. callers.

<marcelo@plucky.distro.conectiva> (02/03/25 1.285)
	new helper - mount_nfs_root().  Yup, attempt to mount nfsroot.

<marcelo@plucky.distro.conectiva> (02/03/25 1.286)
	new helper - change_floppy().  Ejects floppy, asks to replace it

<marcelo@plucky.distro.conectiva> (02/03/25 1.287)
	preparation to cleanup of rd_load_image() (actual loading of

<marcelo@plucky.distro.conectiva> (02/03/25 1.288)
	straightforward switch of rd_load_image() to normal syscalls -

<akpm@reardensteel.com> (02/03/25 1.290)
	[PATCH] The inline-BUG patch

<akpm@zip.com.au> (02/03/25 1.291)
	[PATCH] tunable request queue size

<cyeoh@samba.org> (02/03/25 1.292)
	[PATCH] msync writing when MS_INVALIDATE set and memory locked

<davem@nuts.ninka.net> (02/03/25 1.189.1.15)
	QFE interrupts are mapped INTB/INTC/INTD/INTA.

<davem@nuts.ninka.net> (02/03/25 1.189.1.16)
	In Sparc64 PCI IRQ routing, remove QFE special case.

<uzi@uzix.org> (02/03/25 1.189.1.17)
	Sparc32 cleanups.

<rmk@flint.arm.linux.org.uk> (02/03/26 1.294)
	Sync ARM syscall tables.  Also try to get people to stop adding

<davem@nuts.ninka.net> (02/03/26 1.189.1.18)
	Do the slot mapping adjustment to PROM interrupt

<davem@nuts.ninka.net> (02/03/26 1.181.2.38)
	Fix device list locking.

<marcelo@plucky.distro.conectiva> (02/03/26 1.292.1.3)
	Remove asm/proc_fs.h include from fs/proc/root.c

<marcelo@plucky.distro.conectiva> (02/03/26 1.292.1.4)
	Added ppc64 init proc declarations

<marcelo@plucky.distro.conectiva> (02/03/26 1.292.1.5)
	Added ITE_IT8330G PCI ID

<marcelo@plucky.distro.conectiva> (02/03/26 1.292.1.6)
	Added missing ";" to iSeries_proc_create definition

<jaharkes@cs.cmu.edu> (02/03/27 1.292.1.7)
	[PATCH] Coda update for 2.4.19-pre4

<hch@pentafluge.infradead.org> (02/03/27 1.296)
	[PATCH] fix firewire compilation

<mj@ucw.cz> (02/03/27 1.297)
	[PATCH] PATCH: PCI ID's

<adam@nmt.edu> (02/03/27 1.298)
	[PATCH] 3ware driver update for 2.4.19-pre5

<rth@are.twiddle.net> (02/03/28 1.292.2.1)
	Fix single denorm -> double conversion.

<rth@are.twiddle.net> (02/03/28 1.292.2.2)
	Update NR_SYSCALLS.

<akpm@zip.com.au> (02/03/29 1.299)
	Various changes to the dirty buffer flushing code.

<akpm@zip.com.au> (02/03/29 1.300)
	1: Introduces two new bdflush tunables:

<akpm@zip.com.au> (02/03/29 1.302)
	[PATCH] speed up ext2 synchronous mounts

<akpm@zip.com.au> (02/03/29 1.303)
	[PATCH] speed up ext3 synchronous mounts

<arjanv@redhat.com> (02/03/29 1.304)
	[PATCH] more scsi whitelist entries

<dougg@torque.net> (02/03/29 1.305)
	[PATCH] scsi generic (sg) driver, lk 2.4.18

<bcollins@debian.org> (02/03/29 1.306)
	[PATCH] MAINTAINERS update for 1394

<vojtech@suse.cz> (02/03/29 1.307)
	[PATCH] Update the VIA driver to support the vt8233a

<hch@pentafluge.infradead.org> (02/03/29 1.308)
	[PATCH] include compiler.h in kernel.h

<jt@bougret.hpl.hp.com> (02/03/29 1.309)
	[PATCH] New wireless driver API part 1

<marcelo@plucky.distro.conectiva> (02/03/29 1.310)
	Changed EXTRAVERSION to pre5

Summary of changes from v2.4.19-pre3 to v2.4.19-pre4
============================================

<marcelo@plucky.distro.conectiva> (02/03/13 1.163)
	Update aic7xxx to 6.2.5

<sfr@canb.auug.org.au> (02/03/13 1.164)
	[PATCH] Trivial APM update part 1

<sfr@canb.auug.org.au> (02/03/13 1.165)
	[PATCH] APM patch: change implementation of ALWAYS_CALL_BUSY

<sfr@canb.auug.org.au> (02/03/13 1.166)
	[PATCH] APM patch: apm_cpu_idle cleanups

<jgarzik@mandrakesoft.com> (02/03/13 1.167)
	[PATCH] PATCH: add MWI support to PCI

<jgarzik@mandrakesoft.com> (02/03/13 1.168)
	[PATCH] PATCH: starfire updates

<jgarzik@mandrakesoft.com> (02/03/13 1.169)
	[PATCH] PATCH: tulip use pci_set_mwi

<jgarzik@mandrakesoft.com> (02/03/13 1.170)
	[PATCH] PATCH: starfire use pci_set_mwi

<akpm@zip.com.au> (02/03/14 1.171)
	[PATCH] fix layout of mapped files

<greg@kroah.com> (02/03/14 1.172)
	[PATCH] export IO_APIC_get_PCI_irq_vector for IBM PCI Hotplug driver

<kaos@ocs.com.au> (02/03/14 1.173)
	[PATCH] 2.4.19-pre3 rename duplicate partition_name()

<rml@tech9.net> (02/03/14 1.174)
	[PATCH] more lseek cleanup

<rml@tech9.net> (02/03/14 1.175)
	[PATCH] 2.4: UFS lseek cleanup

<bcrl@redhat.com> (02/03/14 1.176)
	[PATCH] ns83820 0.17 (Re: Broadcom 5700/5701 Gigabit Ethernet Adapters)

<sfr@canb.auug.org.au> (02/03/14 1.177)
	[PATCH] dnotify

<trond.myklebust@fys.uio.no> (02/03/14 1.178)
	[PATCH] Fix 2.4.19-pre3 NFS client file creation

<trond.myklebust@fys.uio.no> (02/03/14 1.179)
	[PATCH] Fix 2.4.19-pre3 NFS reads from holding a write leases.

<trond.myklebust@fys.uio.no> (02/03/14 1.180)
	[PATCH] 2.4.19-pre3 NFS close-to-open fixes

<trond.myklebust@fys.uio.no> (02/03/14 1.181)
	[PATCH] 2.4.19-pre3 NFS close-to-open fix part 2 (VFS change)

<davem@nuts.ninka.net> (02/03/13 1.182)
	Sparc64 updates and fixes:

<davem@nuts.ninka.net> (02/03/13 1.183)
	Fix unterminated comment in asm-sparc64/ide.h

<marcelo@plucky.distro.conectiva> (02/03/14 1.181.1.1)
	Remove off-by-one Davej's fix in bluesmoke.c: it causes some 

<davem@nuts.ninka.net> (02/03/14 1.184)
	Missed this add during sparc64 updates.

<davem@nuts.ninka.net> (02/03/14 1.185)
	Sparc64 build fix: add nop flush_icache_user_range definition.

<davem@nuts.ninka.net> (02/03/14 1.186)
	Kill unused variable warnings in sunlance driver.

<davem@nuts.ninka.net> (02/03/14 1.181.2.1)
	Networking updates and fixes:

<davem@nuts.ninka.net> (02/03/14 1.181.2.2)
	Fix "performance optimization" that breaks the build

<davem@nuts.ninka.net> (02/03/14 1.187)
	Kill unused variable warnings in sunbmac.c and sunqe.c

<davem@nuts.ninka.net> (02/03/14 1.188)
	SunGEM driver updates:

<davem@nuts.ninka.net> (02/03/14 1.189)
	Fix unterminated comment in asm-sparc/ide.h

<davem@nuts.ninka.net> (02/03/14 1.181.2.3)
	New driver for Tigon3 gigabit chipsets, written by

<geert@linux-m68k.org> (02/03/14 1.181.1.2)
	[PATCH] Yearly m68k update (part 41)

<geert@linux-m68k.org> (02/03/14 1.181.1.3)
	[PATCH] Yearly m68k update (part 40)

<geert@linux-m68k.org> (02/03/14 1.181.1.4)
	[PATCH] Yearly m68k update (part 39)

<geert@linux-m68k.org> (02/03/14 1.181.1.5)
	[PATCH] Yearly m68k update (part 36)

<geert@linux-m68k.org> (02/03/14 1.181.1.6)
	[PATCH] Yearly m68k update (part 31)

<geert@linux-m68k.org> (02/03/14 1.181.1.7)
	[PATCH] Yearly m68k update (part 27)

<geert@linux-m68k.org> (02/03/14 1.181.1.8)
	[PATCH] Yearly m68k update (part 35)

<geert@linux-m68k.org> (02/03/14 1.181.1.9)
	[PATCH] Yearly m68k update (part 24)

<geert@linux-m68k.org> (02/03/14 1.181.1.10)
	[PATCH] Yearly m68k update (part 38)

<geert@linux-m68k.org> (02/03/14 1.181.1.11)
	[PATCH] Yearly m68k update (part 28)

<geert@linux-m68k.org> (02/03/14 1.181.1.12)
	[PATCH] Yearly m68k update (part 13)

<geert@linux-m68k.org> (02/03/14 1.181.1.13)
	[PATCH] Yearly m68k update (part 37)

<geert@linux-m68k.org> (02/03/14 1.181.1.14)
	[PATCH] Yearly m68k update (part 7)

<geert@linux-m68k.org> (02/03/14 1.181.1.15)
	[PATCH] Yearly m68k update (part 32)

<geert@linux-m68k.org> (02/03/14 1.181.1.16)
	[PATCH] Yearly m68k update (part 34)

<geert@linux-m68k.org> (02/03/14 1.181.1.17)
	[PATCH] Yearly m68k update (part 25)

<geert@linux-m68k.org> (02/03/14 1.181.1.18)
	[PATCH] Yearly m68k update (part 11)

<geert@linux-m68k.org> (02/03/14 1.181.1.19)
	[PATCH] Yearly m68k update (part 30)

<geert@linux-m68k.org> (02/03/14 1.181.1.20)
	[PATCH] Yearly m68k update (part 6)

<geert@linux-m68k.org> (02/03/14 1.181.1.21)
	[PATCH] Yearly m68k update (part 33)

<geert@linux-m68k.org> (02/03/14 1.181.1.22)
	[PATCH] Yearly m68k update (part 4)

<geert@linux-m68k.org> (02/03/14 1.181.1.23)
	[PATCH] Yearly m68k update (part 2)

<geert@linux-m68k.org> (02/03/14 1.181.1.24)
	[PATCH] Yearly m68k update (part 8)

<geert@linux-m68k.org> (02/03/14 1.181.1.25)
	[PATCH] Yearly m68k update (part 12)

<geert@linux-m68k.org> (02/03/14 1.181.1.26)
	[PATCH] Yearly m68k update (part 16)

<geert@linux-m68k.org> (02/03/14 1.181.1.27)
	[PATCH] Yearly m68k update (part 3)

<geert@linux-m68k.org> (02/03/14 1.181.1.28)
	[PATCH] Yearly m68k update (part 29)

<geert@linux-m68k.org> (02/03/14 1.181.1.29)
	[PATCH] Yearly m68k update (part 19)

<geert@linux-m68k.org> (02/03/14 1.181.1.30)
	[PATCH] Yearly m68k update (part 21)

<geert@linux-m68k.org> (02/03/14 1.181.1.31)
	[PATCH] Yearly m68k update (part 17)

<geert@linux-m68k.org> (02/03/14 1.181.1.32)
	[PATCH] Yearly m68k update (part 5)

<geert@linux-m68k.org> (02/03/14 1.181.1.33)
	[PATCH] Yearly m68k update (part 15)

<geert@linux-m68k.org> (02/03/14 1.181.1.34)
	[PATCH] Yearly m68k update (part 26)

<geert@linux-m68k.org> (02/03/14 1.181.1.35)
	[PATCH] Yearly m68k update (part 22)

<geert@linux-m68k.org> (02/03/14 1.181.1.36)
	[PATCH] Yearly m68k update (part 1)

<geert@linux-m68k.org> (02/03/14 1.181.1.37)
	[PATCH] Yearly m68k update (part 23)

<geert@linux-m68k.org> (02/03/14 1.181.1.38)
	[PATCH] Yearly m68k update (part 9)

<geert@linux-m68k.org> (02/03/14 1.181.1.39)
	[PATCH] Yearly m68k update (part 10)

<geert@linux-m68k.org> (02/03/14 1.181.1.40)
	[PATCH] Yearly m68k update (part 18)

<geert@linux-m68k.org> (02/03/14 1.181.1.41)
	[PATCH] Yearly m68k update (part 20)

<kraxel@bytesex.org> (02/03/14 1.181.1.42)
	[PATCH] v4l: video4linux API doc update

<kraxel@bytesex.org> (02/03/14 1.181.1.43)
	[PATCH] vmalloc_to_page() backport for 2.4

<kraxel@bytesex.org> (02/03/14 1.181.1.44)
	[PATCH] v4l: videodev redesign

<kai@tp1.ruhr-uni-bochum.de> (02/03/14 1.181.1.45)
	[PATCH] ISDN fixes / update

<kai@tp1.ruhr-uni-bochum.de> (02/03/14 1.181.1.46)
	[PATCH] ISDN fixes / update

<kai@tp1.ruhr-uni-bochum.de> (02/03/14 1.181.1.47)
	[PATCH] ISDN fixes / update

<kai@tp1.ruhr-uni-bochum.de> (02/03/14 1.181.1.48)
	[PATCH] ISDN fixes / update

<kai-germaschewski@uiowa.edu> (02/03/14 1.181.1.49)
	[PATCH] ISDN fixes / update

<greg@kroah.com> (02/03/14 1.181.1.50)
	[PATCH] USB Config.in update

<greg@kroah.com> (02/03/14 1.181.1.51)
	[PATCH] USB edgeport driver bugfix

<greg@kroah.com> (02/03/14 1.181.1.52)
	[PATCH] USB usbfs name added

<greg@kroah.com> (02/03/14 1.181.1.53)
	[PATCH] USB ipaq driver bugfix

<greg@kroah.com> (02/03/14 1.181.1.54)
	[PATCH] USB catc ethtool support

<greg@kroah.com> (02/03/14 1.181.1.55)
	[PATCH] USB CREDITS and MAINTAINERS update

<greg@kroah.com> (02/03/14 1.181.1.56)
	[PATCH] USB pegasus ethtool support

<greg@kroah.com> (02/03/14 1.181.1.57)
	[PATCH] USB em26 driver added

<davem@nuts.ninka.net> (02/03/14 1.181.2.4)
	Allow ARP packets to be seen by netfilter.

<kai@tp1.ruhr-uni-bochum.de> (02/03/14 1.181.1.58)
	Put back the option to support AVM A1 / Fritz! PCMCIA cards inside hisax.

<davem@nuts.ninka.net> (02/03/14 1.181.2.5)
	Include linux/netfilter_arp.h

<marcelo@plucky.distro.conectiva> (02/03/14 1.192)
	Add missing aic7xxx updates

<axboe@suse.de> (02/03/14 1.193)
	[PATCH] cciss driver pci_*_consistent(NULL,...) fix for 2.4.19-pre2 (1 of 4)

<axboe@suse.de> (02/03/14 1.194)
	[PATCH] cciss driver GETLUNINFO ioctl (2 of 4)

<axboe@suse.de> (02/03/14 1.195)
	[PATCH] cciss driver HDIO_GETGEO_BIG ioctl for 2.4.19-pre2 (3 of 4)

<axboe@suse.de> (02/03/14 1.196)
	[PATCH] remove CCISS_REVALIDVOLS ioctl for 2.4.19-pre2 (4 of 4)

<marcelo@plucky.distro.conectiva> (02/03/14 1.197)
	The problem is that both the sd and sr drivers treat an

<davem@nuts.ninka.net> (02/03/14 1.181.2.6)
	From Harald Welte and the Netfilter team:

<davem@nuts.ninka.net> (02/03/14 1.181.2.7)
	From Harald Welte and the Netfilter team:

<EdV@macrolink.com> (02/03/15 1.198)
	This patch corrects PCI device id in pci_ids.h for Oxford Semi OX16PCI952

<jgarzik@mandrakesoft.com> (02/03/15 1.199)
	Remove VT8233 pci ids from via82cxxx_audio sound driver.

<nahshon@actcom.co.il> (02/03/15 1.200)
	Fix via audio recording, when frag size < page size.

<silicon@falcon.sch.bme.hu> (02/03/15 1.201)
	Add new slicecom/munich WAN driver.

<hch@caldera.de> (02/03/15 1.197.2.1)
	[PATCH] remove superflous assignment in mmap()

<hch@caldera.de> (02/03/15 1.197.2.2)
	[PATCH] Error return fixes

<hch@caldera.de> (02/03/15 1.197.2.3)
	[PATCH] missing include in net/sunrpc/stats.c

<davem@nuts.ninka.net> (02/03/15 1.181.2.8)
	Add arptables netfilter module for registering ARP

<bfennema@falcon.csc.calpoly.edu> (02/03/15 1.197.2.4)
	Missing byte swaps needed for big endian archs

<mikpe@csd.uu.se> (02/03/15 1.197.2.5)
	[PATCH] boot_cpu_data corruption on SMP x86

<bfennema@falcon.csc.calpoly.edu> (02/03/15 1.197.2.7)
	Fix videodev build warning

<davem@nuts.ninka.net> (02/03/17 1.181.2.9)
	Fix netfilter IPv4 conntrack build.

<marcelo@plucky.distro.conectiva> (02/03/19 1.204)
	Changed EXTRAVERSION in Makefile to pre4

<stelian.pop@fr.alcove.com> (02/03/19 1.205)
	[PATCH] videodev.c oopses in video_exclusive_register

<stelian.pop@fr.alcove.com> (02/03/19 1.206)
	[PATCH] meye driver update to new V4L API.

<rusty@rustcorp.com.au> (02/03/19 1.207)
	[PATCH] 2.4.19-pre3 Trivial I: seq_file.h update

<rusty@rustcorp.com.au> (02/03/19 1.208)
	[PATCH] Trivial I: fs_exec.c core fix

<rusty@rustcorp.com.au> (02/03/19 1.209)
	[PATCH] 2.4.19-pre3 Trivial III: -ENOTTY for nvram

<rusty@rustcorp.com.au> (02/03/19 1.210)
	[PATCH] 2.4.19-pre3 Trivial IV: -ENOTTY

<rusty@rustcorp.com.au> (02/03/19 1.211)
	[PATCH] 2.4.19-pre3 Trivial VI: MSDOS options

<marcelo@plucky.distro.conectiva> (02/03/19 1.212)
	If setup_arg_pages() fails, we continue

<rmk@arm.linux.org.uk> (02/03/19 1.213)
	[PATCH] 2.4 and 2.5: remove Alt-Sysrq-L

<rmk@arm.linux.org.uk> (02/03/19 1.214)
	[PATCH] 2.5 and 2.4: fix PCI IO BAR flags

<marcelo@plucky.distro.conectiva> (02/03/19 1.215)
	Remove unused videodev_register_lock

<marcelo@plucky.distro.conectiva> (02/03/19 1.216)
	Avoid page_to_phys() from truncating the physical addresses to 32bit,

<hch@caldera.de> (02/03/19 1.217)
	[PATCH] fix Config.in breakage

<hch@caldera.de> (02/03/19 1.218)
	[PATCH] kill slow-path micro-optimization

<hch@caldera.de> (02/03/19 1.219)
	[PATCH] export rbtree routines

<paulus@samba.org> (02/03/19 1.220)
	[PATCH] Re: [PATCH] zlib double-free bug

<trond.myklebust@fys.uio.no> (02/03/20 1.220.3.2)
	[PATCH] Fix bug in sunrpc code...

Summary of changes from v2.4.19-pre2 to v2.4.19-pre3
============================================

<marcelo@plucky.distro.conectiva> (02/03/13 1.162)
	- -ac merge (including new IDE)                         (Alan Cox)
	- S390 merge                                            (IBM)
	- More cciss fixes                                      (Stephen Cameron)
	- Eicon SMP race fix                                    (Armin Schindler)
	- w9966 driver update                                   (Jakob Kemi)
	- Unify crc32 routine (removes lots of duplicated
	  code from drivers)                                    (Matt Domsch)
	- Lanstreamer bugfixes                                  (Kent Yoder)
	- Update scsi_debug                                     (Douglas Gilbert)
	- MCE Configure.help update                             (Paul Gortmaker)
	- Fix SMB NLS oops                                      (Urban Widmark)
	- AGP Config.in update                                  (Daniele Venzano)
	- Fix small thinko in UFS set_blocksize return handling (me)
	- Avoid unecessary cache flushes on PPC                 (Paul Mackerras)
	- PPP deadlock fixes                                    (Paul Mackerras)
	- Signal changes for thread groups                      (Dave McCracken)
	- Make max_threads be based on normal zone size         (Dave McCracken)
	- ray_cs wireless extension fix                         (Jean Tourrilhes)
	- irda bugfixes and enhancements                        (Jean Tourrilhes)
	- USB update                                            (Greg KH)
	- Fix through-8259A mode for IRQ0 routing on APIC       (Maciej W. Rozycki/Joe Korty)
	- Add Dell Inspiron 2500 to broken APM blacklist        (Arjan van de Ven)
	- Fix off-by-one error in bluesmoke                     (Dave Jones)
	- Reiserfs update                                       (Oleg Drokin)
	- Fix PCI compile without /proc support                 (Eric Sandeen)
	- Fix problem with bad inode handling                   (Alexander Viro)
	- aic7xxx update                                        (Justin T. Gibbs)
	- Do not consider SCSI recovered errors as fatal errors (Justin T. Gibbs)
	- Add Memory-Write-Invalidate support to PCI            (Jeff Garzik)
	- Starfire update                                       (Ion Badulescu)
	- tulip update                                          (Jeff Garzik)


Summary of changes from v2.4.19-pre1 to v2.4.19-pre2
============================================

<marcelo@plucky.distro.conectiva> (02/03/13 1.161)
	- -ac merge                                             (Alan Cox)
	- Huge MIPS/MIPS64 merge                                (Ralf Baechle)
	- IA64 update                                           (David Mosberger)
	- PPC update                                            (Tom Rini)
	- Shrink struct page                                    (Rik van Riel)
	- QNX4 update (now its able to mount QNX 6.1 fses)      (Anders Larsen)
	- Make max_map_count sysctl configurable                (Christoph Hellwig)
	- matroxfb update                                       (Petr Vandrovec)
	- ymfpci update                                         (Pete Zaitcev)
	- LVM update                                            (Heinz J . Mauelshagen)
	- btaudio driver update                                 (Gerd Knorr)
	- bttv update                                           (Gerd Knorr)
	- Out of line code cleanup                              (Keith Owens)
	- Add watchdog API documentation                        (Christer Weinigel)
	- Rivafb update                                         (Ani Joshi)
	- Enable PCI buses above quad0 on NUMA-Q                (Martin J. Bligh)
	- Fix PIIX IDE slave PCI timings                        (Dave Bogdanoff)
	- Make PLIP work again                                  (Tim Waugh)
	- Remove unecessary printk from lp.c                    (Tim Waugh)
	- Make parport_daisy_select work for ECP/EPP modes      (Max Vorobiev)
	- Support O_NONBLOCK on lp/ppdev correctly              (Tim Waugh)
	- Add PCI card hooks to parport                         (Tim Waugh)
	- Compaq cciss driver fixes                             (Stephen Cameron)
	- VFS cleanups and fixes                                (Alexander Viro)
	- USB update (including USB 2.0 support)                (Greg KH)
	- More jiffies compare cleanups                         (Tim Schmielau)
	- PCI hotplug update                                    (Greg KH)
	- bluesmoke fixes                                       (Dave Jones)
	- Fix off-by-one in ide-scsi                            (John Fremlin)
	- Fix warnings in make xconfig                          (René Scharfe)
	- Make x86 MCE a configure option                       (Paul Gortmaker)
	- Small ramdisk fixes                                   (Christoph Hellwig)
	- Add missing atime update to pipe code                 (Christoph Hellwig)
	- Serialize microcode access                            (Tigran Aivazian)
	- AMD Elan handling on serial.c                         (Robert Schwebel)


Summary of changes from v2.4.18 to v2.4.19-pre1
============================================

<marcelo@plucky.distro.conectiva> (02/03/13 1.160)
	- Add tape support to cciss driver                      (Stephen Cameron)
	- Add Permedia3 fb driver                               (Romain Dolbeau)
	- meye driver update                                    (Stelian Pop)
	- opl3sa2 update                                        (Zwane Mwaikambo)
	- JFFS2 update                                          (David Woodhouse)
	- NBD deadlock fix                                      (Steven Whitehouse)
	- Correct sys_shmdt() return value on failure           (Adam Bottchen)
	- Apply the SET_PERSONALITY patch missing from 2.4.18   (me)
	- Alpha update                                          (Jay Estabrook)
	- SPARC64 update                                        (David S. Miller)
	- Fix potential blk freelist corruption                 (Jens Axboe)
	- Fix potential hpfs oops                               (Chris Mason)
	- get_request() starvation fix                          (Andrew Morton)
	- cramfs update                                         (Daniel Quinlan)
	- Allow binfmt_elf as module                            (Paul Gortmaker)
	- ymfpci Configure.help update                          (Pete Zaitcev)
	- Backout one eepro100 change made in 2.4.18: it
	  was causing slowdowns on some cards                   (Jeff Garzik)
	- Tridentfb compilation fix                             (Jani Monoses)
	- Fix refcounting of directories on renames in tmpfs    (Christoph Rohland)
	- Add Fujitsu notebook to broken APM implementation
	  blacklist                                             (Arjan Van de Ven)
	- "do { ... } while(0)" cleanups on some fb drivers     (Geert Uytterhoeven)
	- Fix natsemi's ETHTOOL_GLINK ioctl                     (Tim Hockin)
	- Fix clik! drive detection code in ide-floppy          (Paul Bristow)
	- Add additional support for the 82801 I/O controller   (Wim Van Sebroeck)
	- Remove duplicates in pci_ids.h                        (Wim Van Sebroeck)