Ok, it's a bloody large -rc (as was 24-rc1, for that matter), probably because the 2.6.24 release cycle dragged out, so people had a lot of things pending. The full diff is something like 11MB and 1.4M lines of diffs, with the bulk of the stuff being in architecture updates and drivers. Just to have some fun, I did trivial statistics, and of the 1.4M lines of diffs, about 38% - 530k lines - were in architecture files (400k+ lines of diffs in arch/, 100k+ lines of diffs in include/asm-*), and another big chunk is in drivers (including sound) at about 44% - 610k lines - of changes. The rest comes in much smaller, but still noticeable is networking (8% - 110k lines), with filesystems at 4%, and documentation at about 2%. The remaining crumbles being spread out mostly over block layer, crypto, kernel core, and security layer updates (ie SElinux and smack). [ Just to make it more obvious how driver and architecture-dominated the kernel changelogs are: just the network driver changes were 200kloc, and even just infiniband - which came way behind not just networking drivers, but also DVB, SCSI, char and ide - generated more lines of code changed than the "core" kernel code under the kernel/ subdirectory. And that's despite the fact that the "core" code was actually under a fairly active merge cycle, with a lot of namespace- and scheduling- related stuff. ] Now, some of that is files moving about and other reorganizations (SH and to a lesser degree sparc starting to merge 32-bit and 64-bit architectures), but most of it really is just the normal flood of changes and new driver or platform support. The full shortlog is half a meg in size (and the diffstat is even bigger), so I won't be including that here, but some things that may be worth pointing out not because they are big in line sizes, but because they have potential to be noticed by more people: - the intel graphics driver is starting to do suspend/resume natively (ie even wit...
hm, ata_port_wait_eh() started crashing on a testsystem (8-way box): [ 39.324116] Calling initcall 0xc09f41eb: legacy_init+0x0/0x888() [ 39.331868] BUG: unable to handle kernel NULL pointer dereference at 000000e4 [ 39.338811] IP: [<c04a4e11>] ata_port_wait_eh+0x77/0xa2 [ 39.344115] *pde = 00000000 [ 39.347778] Oops: 0000 [#1] SMP [ 39.350769] [ 39.350769] Pid: 1, comm: swapper Not tainted (2.6.25-rc1 #5) [ 39.350769] EIP: 0060:[<c04a4e11>] EFLAGS: 00010246 CPU: 1 [ 39.350769] EIP is at ata_port_wait_eh+0x77/0xa2 [ 39.350769] EAX: f72e5d9c EBX: f7340000 ECX: c035eb18 EDX: 00000000 [ 39.350769] ESI: f73424f0 EDI: 00000246 EBP: f7c63efc ESP: f7c63edc [ 39.350769] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 39.350769] Process swapper (pid: 1, ti=f7c62000 task=f7c60000 task.ti=f7c62) [ 39.350769] Stack: 00000000 f7c60000 c012fd31 f7c63ee8 f7c63ee8 f7340000 f73 [ 39.350769] f7c63f18 c049c4b1 f72e5d9c 00000000 f7340000 00810001 000 [ 39.350769] c09f4a60 00000000 00000000 c0b79a9c 00000001 00000001 000 [ 39.350769] Call Trace: [ 39.350769] [<c012fd31>] ? autoremove_wake_function+0x0/0x30 [ 39.350769] [<c049c4b1>] ? ata_host_detach+0x4c/0x13b [ 39.350769] [<c09f4a60>] ? legacy_init+0x875/0x888 [ 39.350769] [<c0133fa6>] ? getnstimeofday+0x35/0xc0 [ 39.350769] [<c09d7465>] ? kernel_init+0x12a/0x277 [ 39.350769] [<c09d7300>] ? do_early_param+0x34/0x6f [ 39.350769] [<c09d733b>] ? kernel_init+0x0/0x277 [ 39.350769] [<c0104b17>] ? kernel_thread_helper+0x7/0x10 [ 39.350769] ======================= [ 39.350769] Code: e8 82 0f 21 00 8b 43 08 e8 28 2c 21 00 89 c7 f6 43 10 03 8 [ 39.350769] EIP: [<c04a4e11>] ata_port_wait_eh+0x77/0xa2 SS:ESP 0068:f7c63edc[ 39.350793] ---[ end trace 07a6e399b623c9d0 ]--- [ 39.354119] Kernel panic - not syncing: Attempted to kill init! no particular commit stands out at me - so i Cc:-ed various PATA folks. Config...
Does the following patch fix the above problem? pata_isapnp is the
only one which can have NULL ctl_addr and libata SFF layer wasn't
ready for that.
Thanks.
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 4e31071..c6c04dc 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2150,6 +2150,15 @@ int ata_eh_reset(struct ata_link *link, int classify,
ap->ops->set_piomode(ap, dev);
}
+ if (!softreset && !hardreset) {
+ if (verbose)
+ ata_link_printk(link, KERN_INFO, "no reset method "
+ "available, skipping reset\n");
+ if (!(lflags & ATA_LFLAG_ASSUME_CLASS))
+ lflags |= ATA_LFLAG_ASSUME_ATA;
+ goto done;
+ }
+
/* Determine which reset to use and record in ehc->i.action.
* prereset() may examine and modify it.
*/
@@ -2254,6 +2263,7 @@ int ata_eh_reset(struct ata_link *link, int classify,
lflags |= ATA_LFLAG_ASSUME_ATA;
}
+ done:
ata_link_for_each_dev(dev, link) {
/* After the reset, the device state is PIO 0 and the
* controller state is undefined. Reset also wakes up
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 60cd4b1..93ea0db 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -56,7 +56,8 @@ u8 ata_irq_on(struct ata_port *ap)
ap->ctl &= ~ATA_NIEN;
ap->last_ctl = ap->ctl;
- iowrite8(ap->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(ap->ctl, ioaddr->ctl_addr);
tmp = ata_wait_idle(ap);
ap->ops->irq_clear(ap);
@@ -81,7 +82,8 @@ void ata_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
if (tf->ctl != ap->last_ctl) {
- iowrite8(tf->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(tf->ctl, ioaddr->ctl_addr);
ap->last_ctl = tf->ctl;
ata_wait_idle(ap);
}
@@ -167,13 +...Ping. -- tejun --
Pong. Please consider it fixed and merge the fix upstream - i havent
seen these problems since i put your fix into my qa tree (and forgot
about it completely). If there's any problem left i'll follow up on it.
(For the record, the patch below is the one i tested with various x86
hardware.)
Ingo
------------->
Subject: Re: Re: Linux 2.6.25-rc1
From: Tejun Heo <htejun@gmail.com>
Date: Wed, 13 Feb 2008 18:51:39 +0900
Does the following patch fix the above problem? pata_isapnp is the
only one which can have NULL ctl_addr and libata SFF layer wasn't
ready for that.
Thanks.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
drivers/ata/libata-eh.c | 10 ++++++++++
drivers/ata/libata-sff.c | 22 ++++++++++++++--------
2 files changed, 24 insertions(+), 8 deletions(-)
Index: linux/drivers/ata/libata-eh.c
===================================================================
--- linux.orig/drivers/ata/libata-eh.c
+++ linux/drivers/ata/libata-eh.c
@@ -2150,6 +2150,15 @@ int ata_eh_reset(struct ata_link *link,
ap->ops->set_piomode(ap, dev);
}
+ if (!softreset && !hardreset) {
+ if (verbose)
+ ata_link_printk(link, KERN_INFO, "no reset method "
+ "available, skipping reset\n");
+ if (!(lflags & ATA_LFLAG_ASSUME_CLASS))
+ lflags |= ATA_LFLAG_ASSUME_ATA;
+ goto done;
+ }
+
/* Determine which reset to use and record in ehc->i.action.
* prereset() may examine and modify it.
*/
@@ -2254,6 +2263,7 @@ int ata_eh_reset(struct ata_link *link,
lflags |= ATA_LFLAG_ASSUME_ATA;
}
+ done:
ata_link_for_each_dev(dev, link) {
/* After the reset, the device state is PIO 0 and the
* controller state is undefined. Reset also wakes up
Index: linux/drivers/ata/libata-sff.c
===================================================================
--- linux.orig/drivers/ata/libata-sff.c
+++ linux/drivers/ata/libata-sff.c
@@ -56,7 +56,8 @@ u8 ata_irq_on(struct ata_port *ap)
ap->ctl &= ~ATA_NI...i didnt get very far with bisection. .23 definitely did not crash and booted up fine - but it produced the "Bad IO ..." messages - so my automated bisector scripts which turned that warning into a crash&reboot honed in on the wrong (and probably uninteresting) area. .24 had timeouts but no crash. .25-rc1 had the crash. So it seems like multiple IDE regressions building up a concert of failures here, and it's hard to sort them out. If an IDE/PATA/SATA person could take a look at the various logs i posted and could suggest the most efficient way to proceed it could save me from having to blindly spend hours on this problem. Ingo --
ata_host_detach() detaches an attached port and shouldn't be called on a port which hasn't been attached yet. pata_legacy incorrectly calls ata_host_detach() on unattached port after initialization failure causing oops. Fix it. Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Cc: Arjan van de Ven <arjan@infradead.org> --- drivers/ata/pata_legacy.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c index 333dc15..7383f19 100644 --- a/drivers/ata/pata_legacy.c +++ b/drivers/ata/pata_legacy.c @@ -1278,8 +1278,6 @@ static __init int legacy_init_one(struct legacy_probe *probe) } } fail: - if (host) - ata_host_detach(host); platform_device_unregister(pdev); return ret; } --
applied --
thanks, i'll try this! Ingo --
My mm-mystery-crash has now sneaked into mainline: [ 1463.829078] BUG: unable to handle kernel NULL pointer dereference at 0000000000000378 [ 1463.832141] IP: [<ffffffff8047af18>] ether1394_dg_complete+0x28/0xa0 [ 1463.834616] PGD 7955e067 PUD 7955d067 PMD 0 [ 1463.836148] Oops: 0000 [1] SMP [ 1463.836148] CPU 0 [ 1463.836148] Modules linked in: radeon drm w83792d ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761 tvaudio msp3400 bttv videodev v4l1_compat ir_common compat_ioctl32 v4l2_common videobuf_dma_sg videobuf_core btcx_risc usbhid tveeprom sg i2c_nforce2 hid pata_amd [ 1463.836148] Pid: 519, comm: khpsbpkt Not tainted 2.6.25-rc1 #1 [ 1463.836148] RIP: 0010:[<ffffffff8047af18>] [<ffffffff8047af18>] ether1394_dg_complete+0x28/0xa0 [ 1463.836148] RSP: 0000:ffff81007eeb1e80 EFLAGS: 00010282 [ 1463.836148] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 1463.836148] RDX: ffff81004bc62d80 RSI: 0000000000000000 RDI: ffff810051873e40 [ 1463.836148] RBP: ffff81007eeb1eb0 R08: 0000000000000000 R09: 0000000000000001 [ 1463.836148] R10: 0000000000000001 R11: 0000000000000001 R12: ffff810051873e40 [ 1463.836148] R13: ffff81007e1f7200 R14: 0000000000000001 R15: ffff810051873e40 [ 1463.836148] FS: 00007f727d6d4700(0000) GS:ffffffff807e8000(0000) knlGS:0000000000000000 [ 1463.836148] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b [ 1463.836148] CR2: 0000000000000378 CR3: 0000000079559000 CR4: 00000000000006e0 [ 1463.836148] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1463.836148] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1463.836148] Process khpsbpkt (pid: 519, threadinfo ffff81007eeb0000, task ffff81007ee9e000) [ 1463.836148] Stack: ffff81007eeb1e90 ffff81004bc62b40 ffff810051873e40 0000000000000000 [ 1463.836148] 0000000000000001 0000000000000000 ffff81007eeb1ee0 ffffffff8047b233 [ 1463.836148] ffff81007eeb1ec8 ffff81007eeb1ef0 ffffffff8046c280 ffff81007ff6df10 [ ...
On Mon, 11 Feb 2008 22:46:18 +0100 But this is a crash inside the 1394 code. So if you're getting a crash with plain-old-ethernet then it is a different crash. It'd be good if we --
2.6.24-rc3-mm2: http://marc.info/?l=linux-kernel&m=119636996902805 -> crash in ether1394 and another one in sunrpc http://marc.info/?l=linux-kernel&m=119671371413299 -> crash in tcp v4 http://marc.info/?l=linux-kernel&m=119888251227487 -> crash in sunrpc (first oops in mail) 2.6.24-rc6-mm1: http://marc.info/?l=linux-kernel&m=119888251227487 -> crash net-core (skb_release_data) (second oops in mail) http://marc.info/?l=linux-kernel&m=119898573229965 -> another one in net-core (skb_release_data) http://marc.info/?l=linux-kernel&m=119910705115373 -> crash in sunrpc http://marc.info/?l=linux-kernel&m=119921272203686 -> crash in tcp v4 http://marc.info/?l=linux-kernel&m=119933661810303 -> crash in sunrpc http://marc.info/?l=linux-kernel&m=119946018207746 -> crash in firewire thread http://marc.info/?l=linux-kernel&m=119958976409612 -> crash in sunrpc 2.6.24-rc8-mm1: http://marc.info/?l=linux-kernel&m=119671371413299 -> unknown, but some list check triggered (kernel BUG at lib/list_debug.c:33!) 2.6.25-rc1: http://marc.info/?l=linux-kernel&m=120276641105256&w=2 -> crash in ether1394 All looks network related, and my testcase did stress the network somewhat because it was reading large files from a NFSv4 share. But I agree with Stefan, that its not looking like a ether1394 bug. The code did not change and looking at the code from these crashed in my eyes it can't crash. The list is checked before calling into the processing functions and the locking also looks right. It very much looks like the list itself got corrupted somehow. And that the other network system also suffer from a similar corruption. But I have no clue where to look for the corruptor. I tried slub_debug=FZP, but that also crashed (after several days of working) without the slub debugging catching anything. The corruptor also might be in the disk subsystem, as testcase also stresses the disks. My current best gue...
There are no bugs in 1394. :-) Here are two postings from Torsten which I found in my mail archive. 2007-11-29, an IP-over-1394 backtrace + an ethernet backtrace: http://marc.info/?l=linux-kernel&m=119636996902805 2007-12-03, a backtrace in the TCP code: http://marc.info/?l=linux-kernel&m=119671371413299 -- Stefan Richter -=====-==--- --=- -=-== http://arcgraph.de/sr/ --
Hi Linus. A kbuild bug sneaked in. Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/kbuild.git to fix the following bug. Sam From 49af821e4b1c07e756cbc2e389eba9d885912602 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg <sam@ravnborg.org> Date: Mon, 11 Feb 2008 14:26:26 +0100 Subject: [PATCH] kbuild: fix make V=1 When make -s support were added to filechk to combination created with make V=1 were not covered. Fix it by explicitly cover this case too. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Mike Frysinger <vapier@gentoo.org> --- scripts/Kbuild.include | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index da3559e..d64e6ba 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -39,10 +39,13 @@ escsq = $(subst $(squote),'\$(squote)',$1) # - If they are equal no change, and no timestamp update # - stdin is piped in from the first prerequisite ($<) so one has # to specify a valid file as first prerequisite (often the kbuild file) + chk_filechk = : quiet_chk_filechk = echo ' CHK $@' silent_chk_filechk = : + upd_filechk = : quiet_upd_filechk = echo ' UPD $@' silent_upd_filechk = : + define filechk $(Q)set -e; \ $($(quiet)chk_filechk); \ -- 1.5.4.rc3.14.g44397 --
Mike spotted another missing thing from his initial patch so I folded it into the fix and pushed out a new kbuild.git tree. See updated patch below. Sam From 49af821e4b1c07e756cbc2e389eba9d885912602 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg <sam@ravnborg.org> Date: Mon, 11 Feb 2008 14:26:26 +0100 Subject: [PATCH] kbuild: fix make V=1 When make -s support were added to filechk to combination created with make V=1 were not covered. Fix it by explicitly cover this case too. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Mike Frysinger <vapier@gentoo.org> --- scripts/Kbuild.include | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/init/Makefile b/init/Makefile index c5f157c..4a243df 100644 --- a/init/Makefile +++ b/init/Makefile @@ -27,6 +27,7 @@ $(obj)/version.o: include/linux/compile.h # mkcompile_h will make sure to only update the # actual file if its content has changed. + chk_compile.h = : quiet_chk_compile.h = echo ' CHK $@' silent_chk_compile.h = : include/linux/compile.h: FORCE diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index da3559e..d64e6ba 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -39,10 +39,13 @@ escsq = $(subst $(squote),'\$(squote)',$1) # - If they are equal no change, and no timestamp update # - stdin is piped in from the first prerequisite ($<) so one has # to specify a valid file as first prerequisite (often the kbuild file) + chk_filechk = : quiet_chk_filechk = echo ' CHK $@' silent_chk_filechk = : + upd_filechk = : quiet_upd_filechk = echo ' UPD $@' silent_upd_filechk = : + define filechk $(Q)set -e; \ $($(quiet)chk_filechk); \ --
* Date: Mon, 11 Feb 2008 17:47:09 +0100 Sam, do you agree my fix was more reliable (yea, not only efficient:)? On cost of one new line in silent mode, one gets working "V=1" (and all others). _____ --
You more or less just reverted the original patch - so it was obviously more reliable than introducing new stuff as the fix did. But we are at -r1 so I prefer to get the inteded behaviour and not the minmal fix. Sam --
Processing below changes arguments, not semantics of generated shell code. And IMHO this is more reliable way of doing things. If one really wants silence without commonly accepted ">/dev/null 2>&1" practice, then choose portable "-n" argument for `echo`. - quiet_chk_filechk = echo ' CHK $@' -silent_chk_filechk = : - quiet_upd_filechk = echo ' UPD $@' -silent_upd_filechk = : +quiet_chk_filechk = ' CHK $@' +quiet_upd_filechk = ' UPD $@' + define filechk $(Q)set -e; \ - $($(quiet)chk_filechk); \ + echo $($(quiet)chk_filechk); \ mkdir -p $(dir $@); \ $(filechk_$(1)) < $< > $@.tmp; \ if [ -r $@ ] && cmp -s $@ $@.tmp; then \ rm -f $@.tmp; \ else \ - $($(quiet)upd_filechk); \ + echo $($(quiet)upd_filechk); \ mv -f $@.tmp $@; \ fi endef ______ --
The way we do this in other places in kbuild is a simple: $(if $($(quiet)chk_filechk),echo ' $($(quiet)chk_filechk)' And I think we should have done so originally here. Sam --
i dont see how yours is more efficient when it always runs echo. nor does = it=20 give the same behavior ... your propposed change will echo blank lines in t= he=20 silent mode which is incorrect. it also does not seem to follow the standa= rd=20 convention of other kconfig commands that have quiet/silent prefixes ... su= ch=20 commands do not define arguments to an unknown program/function, nor do the= y=20 add arbitrary redirection which gets leads to confusion as to final=20 expansion, they define the entire command. what Sam posted (and what was merged) makes sense to me. =2Dmike
On Feb 12, 2008 4:07 PM, Mike Frysinger <vapier@gentoo.org> wrote: At least this will not crash, if you don't have some variable set. Efficiency there is lesser number of variables(-2 vs +2), that are copied Right. Seems like you are talking about "[quite_]cmd_*", which are commands. Here you've invented such rules for ordinary utility in `filechk`. And by try they've failed due to mixing functionality dependency on having arbitrary variable being set. Shell syntax tried to avoid this, but `make` syntax and ``convention'' did a boom. Boom, where hacker's V=1 mode failed itself and failed to give a clue about problem (at least, when i saw Sam's message in -- -o--=O`C #oo'L O <___=E M --
and by "arbitrary" you mean "like every other kconfig consumer". sounds=20 shell syntax is irrelevant. a bug was introduced and it was fixed. saying= a=20 bug existed is poor reasoning to introduce worse code. =2Dmike
And here comes "no comments" part. ______ --
erp, i wondered if there was another case i was missing ... you'll also nee= d=20 the attached fixed ... =2D-- When make -s support was added to compile.h, it broke make V=3D1. Signed-off-by: Mike Frysinger <vapier@gentoo.org> =2D-- diff --git a/init/Makefile b/init/Makefile index c5f157c..781f102 100644 =2D-- a/init/Makefile +++ b/init/Makefile @@ -26,7 +26,7 @@ $(obj)/version.o: include/linux/compile.h # so we regenerate it always. # mkcompile_h will make sure to only update the # actual file if its content has changed. =2D + chk_compile.h =3D : quiet_chk_compile.h =3D echo ' CHK $@' silent_chk_compile.h =3D : include/linux/compile.h: FORCE
Hi,
in building 2.6.25-rc1:
CC arch/parisc/kernel/asm-offsets.s
In file included from include/asm/pgtable.h:13,
from arch/parisc/kernel/asm-offsets.c:36:
include/linux/mm.h: In function 'is_vmalloc_addr':
include/linux/mm.h:243: error: 'VMALLOC_START' undeclared (first use in this function)
include/linux/mm.h:243: error: (Each undeclared identifier is reported only once
include/linux/mm.h:243: error: for each function it appears in.)
include/linux/mm.h:243: error: 'VMALLOC_END' undeclared (first use in this function)
make[1]: *** [arch/parisc/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
bisected to commit 9e2779fa281cfda13ac060753d674bbcaa23367e. it looks
like is_vmalloc_addr() did not arrive down to the parisc stuff.
cheers,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--Now that __ioremap isn't available anymore, is there anything in the new pageattr stuff to replace a manual __ioremap with __PAGE_PCD or __PAGE_PSE? or do we have to wait for 2.6.26 to bring PAT support? I don't see any new function accepting random page attributes as __ioremap did. thanks, Brice --
On Mon, 11 Feb 2008 08:39:11 +0100 __PAGE_PSE is the large page bit... that should be managed by the core for sure. (yes I know that the same bit may have different meanings, but it's not __PAGE_PSE then). PAT has a bunch of complications that really need to be resolved in the core correct -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --
I just did, and while non-x seems stable, the latest nvidia driver, about a week old, will not build a valid kernel module, so X bails out with a failed to load it, even though its sitting in /lib/modules/`uname -r`/kernel/drivers/video with exactly the same length as the one built for 2.6.24. The nvidia-installer log recommends doing a 'make prepare' which I did, but nvidia still errors out during the module build. So obviously I am back to 2.6.24, and my next stop is the nvidia web site to see if they have a fix. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Idleness is the holiday of fools. --
Hello All , grabbed using git just moments ago . make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install modules_install ...snip... make -f scripts/Makefile.clean obj=sound/usb/usx2y make -f scripts/Makefile.clean obj=usr rm -rf .tmp_versions rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso arch/x86/boot/mtools.conf vmlinux System.map .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map rm -f include/config/kernel.release echo 2.6.25-rc1 > include/config/kernel.release set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp include/linux/version.h; fi /bin/sh: -c: line 0: syntax error near unexpected token `;' /bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp include/linux/version.h; fi' make: *** [include/linux/version.h] Error 2 # scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux filesrv2 2.6.23-rc9 #1 SMP Wed Oct 3 02:12:33 UTC 2007 i686 pentium4 i386 GNU/Linux Gnu C 3.4.6 Gnu make 3.81 binutils 2.15.92.0.2 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs ...
Please use following fix. Sam diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index da3559e..d64e6ba 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -39,10 +39,13 @@ escsq = $(subst $(squote),'\$(squote)',$1) # - If they are equal no change, and no timestamp update # - stdin is piped in from the first prerequisite ($<) so one has # to specify a valid file as first prerequisite (often the kbuild file) + chk_filechk = : quiet_chk_filechk = echo ' CHK $@' silent_chk_filechk = : + upd_filechk = : quiet_upd_filechk = echo ' UPD $@' silent_upd_filechk = : + define filechk $(Q)set -e; \ $($(quiet)chk_filechk); \ --
Hello Sam , Thank You . that got me past that error . 2.6.25-rc1 is compiling as I write this . Tnx Agn , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ --
On Feb 10, 2008 5:47 PM, Mr. James W. Laferriere Please send your .config as well so someone can try to reproduce this. And have you done a make mrproper first before trying to compile? --
>> set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE http://mid.gmane.org/20080211024640.GF24008@flower.upol.cz _____ --
Just compiled it and I still see the same lguest problem reported here http://lkml.org/lkml/2008/2/3/118 Kernel: arch/x86/boot/bzImage is ready (#1) ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_cr3" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_idt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_gdt" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_sp" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs_trapnum" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_idt_desc" [drivers/lguest/lg.ko] undefined! WARNING: modpost: Found 16 section mismatch(es). config attached. -sergio
| Martin Schwidefsky | Re: x86 arch updates also broke s390 |
| Chuck Ebbert | Why do so many machines need "noapic"? |
| Greg KH | Re: [BUG] 2.6.24-git usb reset problems |
| Rafael J. Wysocki | [Bug #11822] ACPI Warning (nspredef-0858): _SB_.PCI0.LPC_.EC__.BAT0._BIF: Return P... |
git: | |
| Nicolas Bock | error: cannot lock ref 'refs/remotes/origin/*' |
| Peter Karlsson | RCS keyword expansion |
| Matthieu Moy | git push to a non-bare repository |
| Oliver Kullmann | "bash: git-upload-pack: command not found" ?? |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| Daniel Ouellet | identifying sparse files and get ride of them trick available? |
| Richard Stallman | Real men don't attack straw men |
| Christian Weisgerber | Re: libiconv problem |
| Dushan Tcholich | Re: ksoftirqd high cpu load on kernels 2.6.24 to 2.6.27-rc1-mm1 |
| Larry McVoy | Re: tcp bw in 2.6 |
| Jeff Garzik | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
