James Bottomley wrote:
However, there's still devloss_tmo to consider ... even in
multipath, I don't think you want to signal path failure until
devloss_tmo has fired otherwise you'll get too many transient up/down
events which damage performance if the array has an expensive failover
model.
On Mon, 2008-01-07 at 15:05 +0100, Hannes Reinecke wrote:
> James Bottomley wrote:
> > On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
> >> James Bottomley wrote:
> >>> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> OK, thanks. I'll assume that James and Hannes have this
James Bottomley wrote:
> On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
>> James Bottomley wrote:
>>> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
OK, thanks. I'll assume that James and Hannes have this in hand (or will
have, by mid-week) and I won't do anything
James Bottomley wrote:
On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
James Bottomley wrote:
On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
OK, thanks. I'll assume that James and Hannes have this in hand (or will
have, by mid-week) and I won't do anything here.
Just to
James Bottomley wrote:
However, there's still devloss_tmo to consider ... even in
multipath, I don't think you want to signal path failure until
devloss_tmo has fired otherwise you'll get too many transient up/down
events which damage performance if the array has an expensive failover
model.
the end of wakeup_rh() in
> > > > drivers/usb/host/uhci-hcd.c.
> > > >
> > > > The message gets written if the controller hardware hasn't turned off a
> > > > particular bit after a 4-us delay. If the udelay() function wasn't
> > >
if the controller hardware hasn't turned off a
particular bit after a 4-us delay. If the udelay() function wasn't
working right, it could cause this problem.
udelay() _is_ OK for 2.6.24-rc3, so it is not the cause of the problem
But is it OK for 2.6.24-rc3-mm1? Kirill said specifically
On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
> James Bottomley wrote:
> > On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> >> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> >> have, by mid-week) and I won't do anything here.
> >
> > Just to
James Bottomley wrote:
> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
>> OK, thanks. I'll assume that James and Hannes have this in hand (or will
>> have, by mid-week) and I won't do anything here.
>
> Just to confirm what I think I'm going to be doing: rebasing the
> scsi-misc tree
James Bottomley wrote:
On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
OK, thanks. I'll assume that James and Hannes have this in hand (or will
have, by mid-week) and I won't do anything here.
Just to confirm what I think I'm going to be doing: rebasing the
scsi-misc tree to
On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
James Bottomley wrote:
On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
OK, thanks. I'll assume that James and Hannes have this in hand (or will
have, by mid-week) and I won't do anything here.
Just to confirm what I
On Wed, Dec 12 2007, Boaz Harrosh wrote:
> On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> >> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> >> have, by mid-week) and I won't
On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
>> OK, thanks. I'll assume that James and Hannes have this in hand (or will
>> have, by mid-week) and I won't do anything here.
>
> Just to confirm what I
On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
OK, thanks. I'll assume that James and Hannes have this in hand (or will
have, by mid-week) and I won't do anything here.
Just to confirm what I think I'm
On Wed, Dec 12 2007, Boaz Harrosh wrote:
On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
OK, thanks. I'll assume that James and Hannes have this in hand (or will
have, by mid-week) and I won't do anything
On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> have, by mid-week) and I won't do anything here.
Just to confirm what I think I'm going to be doing: rebasing the
scsi-misc tree to remove this commit:
commit
On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
OK, thanks. I'll assume that James and Hannes have this in hand (or will
have, by mid-week) and I won't do anything here.
Just to confirm what I think I'm going to be doing: rebasing the
scsi-misc tree to remove this commit:
commit
Andrew Morton wrote:
On Wed, 21 Nov 2007 12:17:14 +0200 Avi Kivity <[EMAIL PROTECTED]> wrote:
Avi Kivity wrote:
The make headers_check fails,
CHECK include/linux/usb/gadgetfs.h
CHECK include/linux/usb/ch9.h
CHECK include/linux/usb/cdc.h
CHECK
Andrew Morton wrote:
On Wed, 21 Nov 2007 12:17:14 +0200 Avi Kivity [EMAIL PROTECTED] wrote:
Avi Kivity wrote:
The make headers_check fails,
CHECK include/linux/usb/gadgetfs.h
CHECK include/linux/usb/ch9.h
CHECK include/linux/usb/cdc.h
CHECK
in, please. I actually tested this
>>> with an
>>>> aic79xx card, and for me it does cause Domain Validation to succeed
>>>> again.
>>> James,
>>>
>>> Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates
>>> the
>>> BLOCK and
, and for me it does cause Domain Validation to succeed
again.
James,
Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch separates
the
BLOCK and QUIESCE states
correctly (http://lkml.org/lkml/2007/11/24/8).
[...]
[ 25.521256] scsi0 : pata_via
[ 25.521711] scsi1 : pata_via
[ 25.524089
On Wed, 21 Nov 2007 12:17:14 +0200 Avi Kivity <[EMAIL PROTECTED]> wrote:
> Avi Kivity wrote:
> >
> >> The make headers_check fails,
> >>
> >> CHECK include/linux/usb/gadgetfs.h
> >> CHECK include/linux/usb/ch9.h
> >> CHECK include/linux/usb/cdc.h
> >>
On Mon, 26 Nov 2007 15:28:32 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Nov 2007 00:14:17 +0100
> Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
> > On 11/26/2007 11:17 PM, Andrew Morton wrote:
> > >> Maybe if you can emit a broken-out with the fresh pull to test?
> > >
> > >
Miles Lane wrote:
> arch/x86/xen/enlighten.c: In function 'xen_flush_tlb_others':
> arch/x86/xen/enlighten.c:591: error: 'TLB_FLUSH_ALL' undeclared (first
> use in this function)
> arch/x86/xen/enlighten.c:591: error: (Each undeclared identifier is
> reported only once
>
From: Pierre Peiffer <[EMAIL PROTECTED]>
These both commands (SEM_STAT and IPC_STAT) are rather doing the same things
(only the meaning of the id given as input and the return value differ).
However, for the semaphores, they are handled in two different places
(two different functions).
This
sem_exit_ns(), msg_exit_ns() and shm_exit_ns() are all called when an
ipc_namespace is
released to free all ipcs of each type.
But in fact, they do the same thing: they loop around all ipcs to free them
individually by calling a specific routine.
This patch proposes to consolidate this by
Andrew,
Following this discussion http://lkml.org/lkml/2007/11/27/54, I
resend the three patches that I've sent last friday to let you have all of
them in the right order.
Thanks,
--
Pierre Peiffer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
From: Pierre Peiffer <[EMAIL PROTECTED]>
Each ipc_namespace contains a table of 3 pointers to struct ipc_ids (3 for
msg, sem and shm, structure used to store each ipcs)
These pointers are dynamically allocated for each icp_namespace as the
ipc_namespace itself (for the init namespace, they are
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Otherwise, please proceed to work out which diff I need to drop and
> hope like hell that it isn't git-x86..
hm? x86.git is fully bisectable - so a more accurate statement would be
"and hope that it's x86.git, so that it can be properly bisected"
On Tue, 27 Nov 2007 16:25:22 +0800, Dave Young said:
> does boot_delay helps?
It might, if the kernel lived long enough to output a first printk for
us to delay after. :)
Shooting this one would be *easy* if the problem was an boot-time oops that
would otherwise scroll off the screen without a
fic routine to call on each individual ipcs is
> >>> passed as
> >>> parameter. For this, these ipc-specific 'free' routines are reworked to
> >>> take a
> >>> generic 'struct ipc_perm' as parameter.
> >> This conflicts in more-than-tri
On Nov 27, 2007 3:16 PM, <[EMAIL PROTECTED]> wrote:
> On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>
> Finally got both time and motivation to at least start a bi
'struct ipc_perm' as parameter.
>> This conflicts in more-than-trivial ways with Pavel's
>> move-the-ipc-namespace-under-ipc_ns-option.patch, which was in
>> 2.6.24-rc3-mm1.
>>
>
> err, no, it wasn't that patch. For some reason your change assumes that
> msg_exit_
On Tue, 27 Nov 2007 02:54:56 -0500 [EMAIL PROTECTED] wrote:
> On Mon, 26 Nov 2007 23:27:03 PST, Andrew Morton said:
>
> > > git-x86.patch
> > > git-x86-fixup.patch
> > > git-x86-thread_order-borkage.patch
> > > git-x86-thread_order-borkage-fix.patch
> > > git-x86-identify_cpu-fix.patch
> > >
On Tue, 27 Nov 2007 02:54:56 -0500 [EMAIL PROTECTED] wrote:
On Mon, 26 Nov 2007 23:27:03 PST, Andrew Morton said:
git-x86.patch
git-x86-fixup.patch
git-x86-thread_order-borkage.patch
git-x86-thread_order-borkage-fix.patch
git-x86-identify_cpu-fix.patch
is
passed as
parameter. For this, these ipc-specific 'free' routines are reworked to
take a
generic 'struct ipc_perm' as parameter.
This conflicts in more-than-trivial ways with Pavel's
move-the-ipc-namespace-under-ipc_ns-option.patch, which was in
2.6.24-rc3-mm1.
err, no, it wasn't
On Nov 27, 2007 3:16 PM, [EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
Finally got both time and motivation to at least start a bisect..
2.6.23-mm1 works on my D820
-the-ipc-namespace-under-ipc_ns-option.patch, which was in
2.6.24-rc3-mm1.
err, no, it wasn't that patch. For some reason your change assumes that
msg_exit_ns() (for example) doesn't have these lines:
kfree(ns-ids[IPC_MSG_IDS]);
ns-ids[IPC_MSG_IDS] = NULL
On Tue, 27 Nov 2007 16:25:22 +0800, Dave Young said:
does boot_delay helps?
It might, if the kernel lived long enough to output a first printk for
us to delay after. :)
Shooting this one would be *easy* if the problem was an boot-time oops that
would otherwise scroll off the screen without a
* Andrew Morton [EMAIL PROTECTED] wrote:
Otherwise, please proceed to work out which diff I need to drop and
hope like hell that it isn't git-x86..
hm? x86.git is fully bisectable - so a more accurate statement would be
and hope that it's x86.git, so that it can be properly bisected :-)
Andrew,
Following this discussion http://lkml.org/lkml/2007/11/27/54, I
resend the three patches that I've sent last friday to let you have all of
them in the right order.
Thanks,
--
Pierre Peiffer
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
From: Pierre Peiffer [EMAIL PROTECTED]
Each ipc_namespace contains a table of 3 pointers to struct ipc_ids (3 for
msg, sem and shm, structure used to store each ipcs)
These pointers are dynamically allocated for each icp_namespace as the
ipc_namespace itself (for the init namespace, they are
From: Pierre Peiffer [EMAIL PROTECTED]
These both commands (SEM_STAT and IPC_STAT) are rather doing the same things
(only the meaning of the id given as input and the return value differ).
However, for the semaphores, they are handled in two different places
(two different functions).
This patch
sem_exit_ns(), msg_exit_ns() and shm_exit_ns() are all called when an
ipc_namespace is
released to free all ipcs of each type.
But in fact, they do the same thing: they loop around all ipcs to free them
individually by calling a specific routine.
This patch proposes to consolidate this by
Miles Lane wrote:
arch/x86/xen/enlighten.c: In function 'xen_flush_tlb_others':
arch/x86/xen/enlighten.c:591: error: 'TLB_FLUSH_ALL' undeclared (first
use in this function)
arch/x86/xen/enlighten.c:591: error: (Each undeclared identifier is
reported only once
arch/x86/xen/enlighten.c:591:
On Mon, 26 Nov 2007 15:28:32 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 27 Nov 2007 00:14:17 +0100
Jiri Slaby [EMAIL PROTECTED] wrote:
On 11/26/2007 11:17 PM, Andrew Morton wrote:
Maybe if you can emit a broken-out with the fresh pull to test?
On Wed, 21 Nov 2007 12:17:14 +0200 Avi Kivity [EMAIL PROTECTED] wrote:
Avi Kivity wrote:
The make headers_check fails,
CHECK include/linux/usb/gadgetfs.h
CHECK include/linux/usb/ch9.h
CHECK include/linux/usb/cdc.h
CHECK include/linux/usb/audio.h
CHECK
On Mon, 26 Nov 2007 23:27:03 PST, Andrew Morton said:
> > git-x86.patch
> > git-x86-fixup.patch
> > git-x86-thread_order-borkage.patch
> > git-x86-thread_order-borkage-fix.patch
> > git-x86-identify_cpu-fix.patch
> > git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko.patch
> >
On Tue, 27 Nov 2007 02:16:26 -0500 [EMAIL PROTECTED] wrote:
> On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>
> Finally got both time and motivation to at least start a
On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
Finally got both time and motivation to at least start a bisect..
2.6.23-mm1 works on my D820 (x86_64 kernel, Core2 Duo T7200)
24-rc3-mm1 (
t; > that do the job. The specific routine to call on each individual ipcs is
> > passed as
> > parameter. For this, these ipc-specific 'free' routines are reworked to
> > take a
> > generic 'struct ipc_perm' as parameter.
>
> This conflicts in more-than-trivi
ic 'free' routines are reworked to take a
> generic 'struct ipc_perm' as parameter.
This conflicts in more-than-trivial ways with Pavel's
move-the-ipc-namespace-under-ipc_ns-option.patch, which was in
2.6.24-rc3-mm1.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
red disk reads are 2.XX MB/sec
> >> and the box is somewhat laggy.
> >>
> >> hdparm -t on sda and sdb reports :
> >>
> >> /dev/sda:
> >> Timing buffered disk reads:8 MB in 3.26 seconds = 2.46 MB/sec
> >>
> >> /dev/sdb:
>
On Tue, 27 Nov 2007 00:14:17 +0100
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> On 11/26/2007 11:17 PM, Andrew Morton wrote:
> >> Maybe if you can emit a broken-out with the fresh pull to test?
> >
> > http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
> > compile.
>
> Yes it
On 11/26/2007 11:17 PM, Andrew Morton wrote:
>> Maybe if you can emit a broken-out with the fresh pull to test?
>
> http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
> compile.
Yes it did :). And it worked. Both in qemu and on my desktop...
qemu output at:
On 11/26/2007 11:17 PM, Andrew Morton wrote:
> http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
> compile. I'd suggest bisecting 2.6.24-rc3-mm1 would be easier.
Yes, I've bisected this and it pointed to git-x86.patch + 2 pushed fixes from
series, Then tried x
We still don't know what caused this, afaik.
> >
> > yes. Is it a regression? If yes, could someone try to bisect it so that
> > we can fix it? If it's caused by x86.git then the 'mm' branch of the x86
> > git tree can be used for bisection:
> >
> >git://git.
On 11/26/2007 09:45 PM, Ingo Molnar wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 26 Nov 2007 14:39:43 -0500
>> Rik van Riel <[EMAIL PROTECTED]> wrote:
>>
>>> On Tue, 20 Nov 2007 22:18:39 -0800
>>> Andrew Morton <[EMAIL PROTECTED]> wrote:
>>>
> ..MP-BIOS bug: 8254 timer not
On Mon, 26 Nov 2007, Randy Dunlap wrote:
> ARCH_SELECT_MEMORY_MODEL depends on X86_32. Is that too restrictive?
No. X86_64 only has one memory model.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, 26 Nov 2007, Andrew Morton wrote:
> hm. This smells like a startup ordering problem, but everything which
> refresh_zone_stat_thresholds() should be set up by the time we run
> initcalls. Maybe the zone lists are bad?
refresh_zone_stat_thresholds goes through each zone and updates
the
> CPU 0
> > Modules linked in:
> > Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
> > RIP: 0010:[] []
> > refresh_zone_stat_thresholds+0x6d/0x90
> > RSP: :81007fb59ec0 EFLAGS: 00010293
> > RAX: RBX: 0004 RCX:
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Nov 2007 14:39:43 -0500
> Rik van Riel <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 20 Nov 2007 22:18:39 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > > ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> > > > Kernel panic -
On Mon, 26 Nov 2007 11:34:15 -0800 (PST) Christoph Lameter wrote:
> On Mon, 26 Nov 2007, Randy Dunlap wrote:
>
> > On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/p
right to the
> next oops. I'm posting it here because this one is different from the others
> in the thread, yet looks vaguely related:
>
> Unable to handle kernel NULL pointer dereference at 0021 RIP:
> [] refresh_zone_stat_thresholds+0x6d/0x90
> PGD 0
> Oops: 0002
dereference at 0021 RIP:
[] refresh_zone_stat_thresholds+0x6d/0x90
PGD 0
Oops: 0002 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
RIP: 0010:[] []
refresh_zone_stat_thresholds+0x6d/0x90
RSP: :81007fb59ec0 EFLAGS: 00010293
RAX: 00
On Mon, 26 Nov 2007, Randy Dunlap wrote:
> On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>
> allnoconfig on x86_64 gives:
>
> arch/x86/mm/init_64.c:8
On 11/26/2007 07:48 PM, Rik van Riel wrote:
ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
[...]
> FYI, x86_64 has the exact same issue.
yes:
hot-fixes/git-x86-dont-unexport-empty_zero_page.patch
regards,
--
Jiri Slaby ([EMAIL PROTECTED])
Faculty of Informatics, Masaryk
On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
allnoconfig on x86_64 gives:
arch/x86/mm/init_64.c:84: error: implicit declaration of function 'pfn_valid'
mm/page_alloc.c:2533: error: im
> You're a victim of the hasty unexporting fad. Which architecture?
> > x86_64 I guess?
> ia32 instead.
FYI, x86_64 has the exact same issue.
KVM needs the empty_zero_page export reinstated.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
diff -up
linux-2.6.2
8
> security/smack/smack_lsm.c |8
> security/smack/smackfs.c | 12 ++++++--
> 4 files changed, 29 insertions(+), 19 deletions(-)
>
> diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
> linux-2.6.24-rc3-mm1-base/include/linux/capability.h
>
On Wed, Nov 21, 2007 at 03:24:33PM -0800, Andrew Morton wrote:
> -repeat:
> - if (atomic_dec_and_lock(>mnt_count, _lock)) {
> + while (atomic_dec_and_lock(>mnt_count, _lock)) {
> if (likely(!mnt->mnt_pinned)) {
> spin_unlock(_lock);
>
On Wed, Nov 21, 2007 at 03:24:33PM -0800, Andrew Morton wrote:
-repeat:
- if (atomic_dec_and_lock(mnt-mnt_count, vfsmount_lock)) {
+ while (atomic_dec_and_lock(mnt-mnt_count, vfsmount_lock)) {
if (likely(!mnt-mnt_pinned)) {
(+), 19 deletions(-)
diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
linux-2.6.24-rc3-mm1-base/include/linux/capability.h
linux-2.6.24-rc3-mm1-smack/include/linux/capability.h
--- linux-2.6.24-rc3-mm1-base/include/linux/capability.h 2007-11-22
01:51:36.0 -0800
reinstated.
Signed-off-by: Rik van Riel [EMAIL PROTECTED]
diff -up
linux-2.6.24-rc3-mm1/arch/x86/kernel/x8664_ksyms_64.c.export-empty-zero-page
linux-2.6.24-rc3-mm1/arch/x86/kernel/x8664_ksyms_64.c
---
linux-2.6.24-rc3-mm1/arch/x86/kernel/x8664_ksyms_64.c.export-empty-zero-page
2007-11-26
On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
allnoconfig on x86_64 gives:
arch/x86/mm/init_64.c:84: error: implicit declaration of function 'pfn_valid'
mm/page_alloc.c:2533: error: implicit
On 11/26/2007 07:48 PM, Rik van Riel wrote:
ERROR: empty_zero_page [drivers/kvm/kvm.ko] undefined!
[...]
FYI, x86_64 has the exact same issue.
yes:
hot-fixes/git-x86-dont-unexport-empty_zero_page.patch
regards,
--
Jiri Slaby ([EMAIL PROTECTED])
Faculty of Informatics, Masaryk University
-
To
On Mon, 26 Nov 2007, Randy Dunlap wrote:
On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
allnoconfig on x86_64 gives:
arch/x86/mm/init_64.c:84: error: implicit declaration of function
] refresh_zone_stat_thresholds+0x6d/0x90
PGD 0
Oops: 0002 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
RIP: 0010:[8108382a] [8108382a]
refresh_zone_stat_thresholds+0x6d/0x90
RSP: :81007fb59ec0 EFLAGS: 00010293
RAX: RBX
looks vaguely related:
Unable to handle kernel NULL pointer dereference at 0021 RIP:
[8108382a] refresh_zone_stat_thresholds+0x6d/0x90
PGD 0
Oops: 0002 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
RIP: 0010
On Mon, 26 Nov 2007 11:34:15 -0800 (PST) Christoph Lameter wrote:
On Mon, 26 Nov 2007, Randy Dunlap wrote:
On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
allnoconfig on x86_64
* Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 26 Nov 2007 14:39:43 -0500
Rik van Riel [EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2007 22:18:39 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
..MP-BIOS bug: 8254 timer not connected to IO-APIC
Kernel panic - not syncing: IO-APIC +
, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
RIP: 0010:[8108382a] [8108382a]
refresh_zone_stat_thresholds+0x6d/0x90
RSP: :81007fb59ec0 EFLAGS: 00010293
RAX: RBX: 0004 RCX: 0001
RDX: 0001 RSI: 8146fb38
On Mon, 26 Nov 2007, Andrew Morton wrote:
hm. This smells like a startup ordering problem, but everything which
refresh_zone_stat_thresholds() should be set up by the time we run
initcalls. Maybe the zone lists are bad?
refresh_zone_stat_thresholds goes through each zone and updates
the
On Mon, 26 Nov 2007, Randy Dunlap wrote:
ARCH_SELECT_MEMORY_MODEL depends on X86_32. Is that too restrictive?
No. X86_64 only has one memory model.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 11/26/2007 09:45 PM, Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 26 Nov 2007 14:39:43 -0500
Rik van Riel [EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2007 22:18:39 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
..MP-BIOS bug: 8254 timer not connected to IO-APIC
-2.6-x86.git
I did, but it's hard, if you don't know the BAD point. HEAD boots fine and
'x86:
randomize brk' too (the top of git-x86.patch).
So the bug wasn't in git-x86 in 2.6.24-rc3-mm1.
But it might be in there now, as some patches got moved over.
Or it could be git-acpi. Or lots
On 11/26/2007 11:17 PM, Andrew Morton wrote:
http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
compile. I'd suggest bisecting 2.6.24-rc3-mm1 would be easier.
Yes, I've bisected this and it pointed to git-x86.patch + 2 pushed fixes from
series, Then tried x86 git
On 11/26/2007 11:17 PM, Andrew Morton wrote:
Maybe if you can emit a broken-out with the fresh pull to test?
http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
compile.
Yes it did :). And it worked. Both in qemu and on my desktop...
qemu output at:
On Tue, 27 Nov 2007 00:14:17 +0100
Jiri Slaby [EMAIL PROTECTED] wrote:
On 11/26/2007 11:17 PM, Andrew Morton wrote:
Maybe if you can emit a broken-out with the fresh pull to test?
http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
compile.
Yes it did :). And
if you need my config or any other informations.
And you're the second to report very slow scsi throughput in 2.6.24-rc3-mm1.
I found the commit which cause these problems , it is in git-scsi-misc patch
and reverting it fixes both problems for me.
http://git.kernel.org/?p=linux
'struct ipc_perm' as parameter.
This conflicts in more-than-trivial ways with Pavel's
move-the-ipc-namespace-under-ipc_ns-option.patch, which was in
2.6.24-rc3-mm1.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
as
parameter. For this, these ipc-specific 'free' routines are reworked to
take a
generic 'struct ipc_perm' as parameter.
This conflicts in more-than-trivial ways with Pavel's
move-the-ipc-namespace-under-ipc_ns-option.patch, which was in
2.6.24-rc3-mm1.
err, no, it wasn't that patch
On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
Finally got both time and motivation to at least start a bisect..
2.6.23-mm1 works on my D820 (x86_64 kernel, Core2 Duo T7200)
24-rc3-mm1 (plus 3
On Tue, 27 Nov 2007 02:16:26 -0500 [EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
Finally got both time and motivation to at least start a bisect..
2.6.23-mm1 works
On Mon, 26 Nov 2007 23:27:03 PST, Andrew Morton said:
git-x86.patch
git-x86-fixup.patch
git-x86-thread_order-borkage.patch
git-x86-thread_order-borkage-fix.patch
git-x86-identify_cpu-fix.patch
git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko.patch
On Sat, Nov 24, 2007 at 07:44:13PM +0200, James Bottomley wrote:
> Probing intermittent failures in Domain Validation, even with the fixes
> applied leads me to the conclusion that there are further problems with
> this commit:
>
> commit fc5eb4facedbd6d7117905e775cee1975f894e79
> Author: Hannes
t/jejb/scsi-misc-2.6.git;a=commitdiff_plain;h=8655a546c83fc43f0a73416bbd126d02de7ad6c0;hp=5bc717b6bdaaf52edf365eb7d9d8c89fec79df5d
>
> See also :
> http://lkml.org/lkml/2007/11/23/5
>
> and search for '2.6.24-rc3-mm1: I/O error, system hangs' on LKML
>
Thank you!
The problem was fixed b
e it does cause Domain Validation to succeed
>>> again.
>> James,
>>
>> Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates
>> the
>> BLOCK and QUIESCE states
>> correctly" (http://lkml.org/lkml/2007/11/24/8).
>>
>>
--- Andrew Morgan <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Casey Schaufler wrote:
> > diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
> linux-2.6.24-rc3-mm1-base/include/linux/capability.h
> linu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
> diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
> linux-2.6.24-rc3-mm1-base/include/linux/capability.h
> linux-2.6.24-rc3-mm1-smack/include/linux/capability.h
> --- linux-2.6.24-rc3-mm1-base/i
1 - 100 of 297 matches
Mail list logo
