Eu to achando que está faltando alguma biblioteca de compilação ae!!!
PQ EU ACABEI DE COMPILAR O KERNEL
This is kernel package version 11.001.
for module in ; do \
if test -d $module; then \
(cd $module; \
if ./debian/rules KVERS="2.6.23.17-slash1.1" KSRC="/usr/src/linux" \
KMAINT="Unknown Kernel Package Maintainer" KEMAIL="unknown@unconfigured.in.etc.kernel-pkg.conf" \
KPKG_DEST_DIR="/usr/src/linux/.." \
KPKG_MAINTAINER="Unknown Kernel Package Maintainer" \
KPKG_EXTRAV_ARG="" \
ARCH="i386" \
KDREV="i686" kdist_image; then \
echo "Module $module processed fine"; \
else \
echo "Module $module failed."; \
if [ "X" != "X" ]; then \
echo "Perhaps $module does not understand --rootcmd?"; \
echo "If you see messages that indicate that it is not"; \
echo "in fact being built as root, please file a bug "; \
echo "against $module."; \
fi; \
echo "Hit return to Continue"; \
read ans; \
fi; \
); \
else \
echo "Module $module does not exist"; \
echo "Hit return to Continue?"; \
fi; \
done
root@hqxriven-desktop:/usr/src/linux#
EDIT 1 - Sem brincadeira esse erro foi incrivel estou chateado pq vc não conseguiu!!!
Na imagem abaixo mostro que compilei normalmente e estou ele agora!!!
Se vc notar a imagem ela diz: uname -a
Linux hqxriven-desktop 2.6.23.17-slash1.1 #1 SMP
Thu Feb 28 00:36:15 BRT 2008 i686 GNU/Linux
Que foi justamente a hora em que vc colocou essa mensagem e mandei o kernel compilar
Enviada: Hoje às 00:36 Enviado por: vampire_thunder
uma dúvida, mesmo escolhendo um processador (no meu caso Athlon 64), tenho que compilar com --revision=i686?
E o nome? Não tem que ser diferente por causa do driver ATI?
Me desculpe por não ter conseguido te ajudar...
EDIT 1 - O kernel slash1.1 para a versão 2.6.23.17 está muito boa usando patches ck e também patches do kernel dark além de patches do fedora 8!!!
Como achei que pode ser interessante vou postar o changelog do versão 2.6.23.17 vanila!!!
commit 6531868a73a6c91bf0e3e60ded7d1440ee24dfa8
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date: Mon Feb 25 16:14:28 2008 -0800
Linux 2.6.23.17
commit ecf5d430a4fd11dcb0212ded41e3f31d66807a93
Author: Ingo Molnar <mingo@elte.hu>
Date: Fri Feb 15 20:58:54 2008 +0100
x86_64: CPA, fix cache attribute inconsistency bug
no upstream git id as the code has been rewritten.
fix CPA cache attribute bug in v2.6.23. When phys_base is nonzero
(when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates
the secondary alias address by -14 MB (depending on the configured
offset).
The default 64-bit kernels of Fedora and Ubuntu are affected:
$ grep RELOCA /boot/config-2.6.23.9-85.fc8
CONFIG_RELOCATABLE=y
$ grep RELOC /boot/config-2.6.22-14-generic
CONFIG_RELOCATABLE=y
and probably on many other distros as well.
the bug affects all pages in the first 40 MB of physical RAM that
are allocated by some subsystem that does ioremap_nocache() on them:
if (__pa(address) < KERNEL_TEXT_SIZE) {
Hence we might leave page table entries with inconsistent cache
attributes around (pages mapped at both UnCacheable and Write-Back),
and we can also set the wrong kernel text pages to UnCacheable.
the effects of this bug can be random slowdowns and other misbehavior.
If for example AGP allocates its aperture pages into the first 40 MB
of physical RAM, then the -14 MB bug might mark random kernel texto
pages as uncacheable, slowing down a random portion of the 64-bit
kernel until the AGP driver is unloaded.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 8297886712dafa9bd0f641e27ca5352229d2357e
Author: Jonathan Corbet <corbet@lwn.net>
Date: Mon Feb 11 16:17:33 2008 -0700
Be more robust about bad arguments in get_user_pages()
patch 900cf086fd2fbad07f72f4575449e0d0958f860f in mainline.
So I spent a while pounding my head against my monitor trying to figure
out the vmsplice() vulnerability - how could a failure to check for
*read* access turn into a root exploit? It turns out that it's a buffer
overflow problem which is made easy by the way get_user_pages() is
coded.
In particular, "len" is a signed int, and it is only checked at the
*end* of a do {} while() loop. So, if it is passed in as zero, the loop
will execute once and decrement len to -1. At that point, the loop will
proceed until the next invalid address is found; in the process, it will
likely overflow the pages array passed in to get_user_pages().
I think that, if get_user_pages() has been asked to grab zero pages,
that's what it should do. Thus this patch; it is, among other things,
enough to block the (already fixed) root exploit and any others which
might be lurking in similar code. I also think that the number of pages
should be unsigned, but changing the prototype of this function probably
requires some more careful review.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9afecc5026beec3e3658051a8d02301a614180fb
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu Feb 7 14:29:43 2008 +1100
Disable G5 NAP mode during SMU commands on U3
patch 592a607bbc053bc6f614a0e619326009f4b3829e in mainline.
It appears that with the U3 northbridge, if the processor is in NAP
mode the whole time while waiting for an SMU command to complete,
then the SMU will fail. It could be related to the weird backward
mechanism the SMU uses to get to system memory via i2c to the
northbridge that doesn't operate properly when the said bridge is
in napping along with the CPU. That is on U3 at least, U4 doesn't
seem to be affected.
This didn't show before NO_HZ as the timer wakeup was enough to make
it work it seems, but that is no longer the case.
This fixes it by disabling NAP mode on those machines while
an SMU command is in flight.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9721a3d73f2e4a50caeb94f3a77dd965a6f530b7
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Feb 20 00:29:02 2008 +0100
genirq: do not leave interupts enabled on free_irq
commit 89d694b9dbe769ca1004e01db0ca43964806a611
The default_disable() function was changed in commit:
76d2160147f43f982dfe881404cfde9fd0a9da21
genirq: do not mask interrupts by default
It removed the mask function in favour of the default delayed
interrupt disabling. Unfortunately this also broke the shutdown in
free_irq() when the last handler is removed from the interrupt for
those architectures which rely on the default implementations. Now we
can end up with a enabled interrupt line after the last handler was
removed, which can result in spurious interrupts.
Fix this by adding a default_shutdown function, which is only
installed, when the irqchip implementation does provide neither a
shutdown nor a disable function.
Pointed-out-by: Michael Hennerich <Michael.Hennerich@analog.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Tested-by: Michael Hennerich <Michael.Hennerich@analog.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit ffff62030c0b7de563322eb18fc3fe3fdc01e8de
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Feb 20 01:03:00 2008 +0100
hrtimer: check relative timeouts for overflow
commit: 5a7780e725d1bb4c3094fcc12f1c5c5faea1e988
Various user space callers ask for relative timeouts. While we fixed
that overflow issue in hrtimer_start(), the sites which convert
relative user space values to absolute timeouts themself were uncovered.
Instead of putting overflow checks into each place add a function
which does the sanity checking and convert all affected callers to use
it.
Thanks to Frans Pop, who reported the problem and tested the fixes.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Tested-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 2bacfdb30305ffdea047ce860184ad0e570744b5
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Tue Feb 19 16:24:01 2008 +0100
NETFILTER: nf_conntrack_tcp: conntrack reopening fix
[NETFILTER]: nf_conntrack_tcp: conntrack reopening fix
[Upstream commits b2155e7f + d0c1fd7a]
TCP connection tracking in netfilter did not handle TCP reopening
properly: active close was taken into account for one side only and
not for any side, which is fixed now. The patch includes more comments
to explain the logic how the different cases are handled.
The bug was discovered by Jeff Chua.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9e8927bf96eba0e21206dce478e2867708fa9bd0
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Fri Feb 8 14:12:11 2008 -0500
NFS: Fix a potential file corruption issue when writing
patch 5d47a35600270e7115061cb1320ee60ae9bcb6b8 in mainline.
If the inode is flagged as having an invalid mapping, then we can't rely on
the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
write optimisation in nfs_updatepage(), since that will cause NFS to write
out areas of the page that are no longer guaranteed to be up to date.
A potential corruption could occur in the following scenario:
client 1 client 2
=============== ===============
fd=open("f",O_CREAT|O_WRONLY,0644);
write(fd,"fubar\n",6); // cache last page
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"foo\n",4);
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"bar\n",4);
close(fd);
-----
The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
client 2 does not update the cached page after re-opening the file for
write. Instead it keeps it marked as PageUptodate() until someone calls
invaldate_inode_pages2() (typically by calling read()).
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9ec6dbd16425a0a7c8c112908d24564edb0868cb
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: Sat Feb 2 16:06:23 2008 -0600
SCSI: sd: handle bad lba in sense information
patch 366c246de9cec909c5eba4f784c92d1e75b4dc38 in mainline.
Some devices report medium error locations incorrectly. Add guards to
make sure the reported bad lba is actually in the request that caused
it. Additionally remove the large case statment for sector sizes and
replace it with the proper u64 divisions.
Tested-by: Mike Snitzer <snitzer@gmail.com>
Cc: Stable Tree <stable@kernel.org>
Cc: Tony Battersby <tonyb@cybernetics.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Em breve se eu achar que ficou bom (tenho que fazer testes não acham???) eu faço o upload!!!!
Hqx
