"A month of sundays ago Seth Mos wrote:"
> At 16:21 10-7-2001 +0200, Peter T. Breuer wrote:
> >The 2.4.6 patch didn't apply cleanly to a pure kernel source ..
> > linux-2.4.6-xfs-cvs-06212001.patch
> This was a snapshot of the CVS tree in between -pre merging.
> It was never really tested that much AFAIK.
Thanks. Where can I get hold of a clean patch for 2.4.6? I believe I
saw some traffic on that recently, but didn't save the messages. The
official site has:
Current directory is /projects/xfs/download/patches
Jul 5 12:11 text/plain MD5SUM 415 bytes
Jun 9 17:08 text/plain README 439 bytes
Jun 4 07:11 bzip2 linux-2.4.5-xfs-06042001.patch.bz2 816Kb
Jun 4 07:11 GNU Compressed linux-2.4.5-xfs-06042001.patch.gz 1053Kb
Jun 11 08:15 bzip2 linux-2.4.5-xfs-06112001.patch.bz2 816Kb
Jun 11 08:15 GNU Compressed linux-2.4.5-xfs-06112001.patch.gz 1053Kb
Jul 4 22:05 bzip2 linux-2.4.6-xfs-07052001.patch.bz2 817Kb
Jul 5 12:10 GNU Compressed linux-2.4.7-xfs-cvs-07052001.patch.gz 2888Kb
and as you see, there is hobson's choice here.
Sgi's site is certainly not easy to search for this info .. I could
find nothing else on the site that was not aimed at 2.4.2 or 2.4.3.
The FAQ is wrong:
There exists also another way to get an XFS ready kernel - you may get
kernel patches relative to a official kernel from:
and apply then to the kernel sources the patch is for. This is a good
way for all the people who don't want to use CVS or do not have the
bandwidth to checkout the whole kernel tree.
The patch doesn't work well .. and is unsuitable for application to a pure
kernel tree anyway, as it contains the cmd stuff and is against cvs.
> >can't find a likely referant for the failed block. And in any case
> >compilation of the result fails in aic7xxx!
> See FAQ. This is not related to the XFS patch.
Well, I recall something about that too in recent list traffic, but
didn't pay too much attention at the time. I don't mind whether I use
the new or old aic7xxx driver, personally.
> >So I would guess random other patches have been applied. Fair 'nuff.
> >Just give me a clue what they are! Moving the 2.4.5 aic7xxx_reg.h
> >across almost does the trick, but not quite. aic7xxx_seq.h is also
> >needed. That seems to fix it. But what happened?
> The FAQ has a nic entry for this.
I can't find anything related to any of the problems I noted in the FAQ.
Which section did you have in mind? There is a mention of the aic7xxx
driver but not in connection with the problem I noted.
Q: The Adaptec aic7xxx does not compile.
It spits out the following error during compile
gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or
make: *** [aicasm] Error 1
The Adaptec driver in newer 2.4.2 kernels and later need to have the
db headers. These can be found in the db-devel packages.
As I mentioned, it compiled fine once I put in a couple of aic7xxx_FOO.h
files that should have been there already. Without looking at
the patch in detail, I would guess that the patch is against a kernel
with a new aic7xxx driver patch applied, and somehow the patch has
zeroed a couple of headers that it should have left in place?
After slight mending I got a clean kernel compile (still had to fix a
couple of things, but not much). However, building xfs as a module
failed in page_buffer for lack of definitions of things like SLAB_IO.
The basic problem seems to be that the patches are made against CVS.
Is there a clean patch that I should be applying? I'll try patching up
my existing 2.4.5 tree with the 2.4.6 increment, but I really wanted
xfs improvements too.