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.
Ye
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 her
ages near 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
&g
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 confi
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 t
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
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
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 86
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 include/linu
tually 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
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
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?
> > >
> > > http://us
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:59
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 patc
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 introdu
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 ini
* 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
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
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
neric '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
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
> > > git-
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
> > git-x86
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 conflict
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 &quo
lated but buffered 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
> >>
> >>
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:
http://www.fi.
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
serie
s past that point
> >> 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
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 ht
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 s
> 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 - n
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
what caused this, afaik.
> and 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_thr
d:
Unable to handle kernel NULL pointer 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: :81
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:
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
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:
> 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-
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->mnt_count, &vfsmount_lock)) {
> + while (atomic_dec_and_lock(&mnt->mnt_count, &vfsmount_lock)) {
> if (likely(!mnt->mnt_pinned)) {
> spin_unlock(&v
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 R
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 w
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
;
> 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).
>
> How to reproduce :
> - boot
> - switch to a text console
> - capture dmesg in a
.
Thank you.
include/linux/capability.h | 20 +++-
security/smack/smack.h |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-
e
>>>>>> I shouldn't. Checking ...
>>>>>>
>>>>> Ok, found it. We are blocking even special commands (ie requests with
>>>>> PREEMPT not set)
>>>>> when FAILFAST is set. Which is clearly wrong. The attached patch
gt;>>>> Le 21.11.2007 23:41, Andrew Morton a écrit :
>>>>>>>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>>>>>>>>>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
>>>>>>>>>>>
>>>>>&g
;>>>>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>>>>>>>>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>&
er how we did that.
>>
>> It seems OK here from a quick test (i386, ext3-on-IDE).
>>
>> Maybe device driver/block breakage?
Try revert
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff_plain;h=8655a546c83fc43f0a73416bbd126d02de7ad6c0;hp=5bc717b6bdaaf52
22:45:22 +0100
> >>>>>>>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
> >>>>>>>>
> >>>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
> >>>>>>>>>> ftp://ftp.kernel.org/pub/linux
gt;>>>>>>
>>>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>>>>>>>> Hello,
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 Reinecke <[EMAIL PROTECTED]>
Date: Tue Nov 6 09:23:40 2007 +0100
[SCSI]
On Wed, Nov 21, 2007 at 10:58:21AM +0100, Sam Ravnborg wrote:
> On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote:
> > Kamalesh Babulal wrote:
> > >Andrew Morton wrote:
> > >
> > >>On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> > >><[EMAIL PROTECTED]> wrote:
> > >>
> > >>
> >
gt;>> Laurent Riffard wrote:
> >>>>> Le 21.11.2007 23:41, Andrew Morton a écrit :
> >>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
> >>>>>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>
on a écrit :
>>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>>>>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>>>>>> ftp://ftp.kernel.o
Hi, Andrew
> > Hi, Andrew
> >
> > I got following result in 'sync' command.
> > It was too slow. (memory controller config is off ;)
> > I attaches my .config.
> > ==
(snip)
>
> Well I wonder how we did that.
>
> It seems OK here from a quick test (i386, ext3-on-IDE).
>
> Maybe device driver
0100
> >>>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
> >>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
> >&g
On Tue, Nov 20, 2007 at 10:18:39PM -0800, Andrew Morton wrote:
> On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> > Hi Andrew,
> >
> > Kernel panic's across different architectures like powerpc, x86_64,
>
> powerpc complains about IO-APICs??
>
> > Dentry cache
gt;>>
>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>>>> Hello,
>>>>>
>>>>> My system hangs shortly after I logged in Gnome
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 introd
ages near 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
> > &
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 consolidates this for clarification by
Pavel Emelyanov wrote:
> Well I think you're right. The structure gains 50% in size... Really too
> much to fight for performance in IPC :)
>
> Thanks for checking this thing.
>
> You may put my Acked-by in the original patch.
>
Cool. Thanks !
P.
> Thanks,
> Pavel
>
--
Pierre Peiffer
-
To
gt;>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>>> Hello,
>>>>
>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
>>>> that a bunch of task are blocked in "D"
Pierre Peiffer wrote:
> Ok, I have the patch ready, but before sending it, I worry about the size of
> struct ipc_namespace if we mark struct ipc_ids as ___cacheline_aligned
>
> Of course, you we fall into a classical match: performance vs memory size.
>
> As I don't think that I have the kno
Ok, I have the patch ready, but before sending it, I worry about the size of
struct ipc_namespace if we mark struct ipc_ids as ___cacheline_aligned
Of course, you we fall into a classical match: performance vs memory size.
As I don't think that I have the knowledge to decide what we must focu
Pierre Peiffer wrote:
> Hi,
>
> Thanks for reviewing this !
>
> Pavel Emelyanov wrote:
>> Pavel Emelyanov wrote:
>>> Cedric Le Goater wrote:
Pierre Peiffer wrote:
>> [snip]
>>
Pavel, what do you think of it ?
>>> Looks sane, good catch, Pierre.
>>>
>>> But I'd find out whether th
On Fri, Nov 23, 2007 at 08:05:44AM +0200, Kirill A. Shutemov wrote:
> On [Fri, 23.11.2007 01:48], Thomas Gleixner wrote:
> > On Thu, 22 Nov 2007, Andrew Morton wrote:
> >
> > > On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[EMAIL
> > > PROTECTED]> wrote:
> > >
> > > > On x86_64 'uname
Hi,
Thanks for reviewing this !
Pavel Emelyanov wrote:
> Pavel Emelyanov wrote:
>> Cedric Le Goater wrote:
>>> Pierre Peiffer wrote:
>
> [snip]
>
>>> Pavel, what do you think of it ?
>> Looks sane, good catch, Pierre.
>>
>> But I'd find out whether these three ipc_ids intersect any
>>
Pavel Emelyanov wrote:
> Cedric Le Goater wrote:
>> Pierre Peiffer wrote:
[snip]
>> Pavel, what do you think of it ?
>
> Looks sane, good catch, Pierre.
>
> But I'd find out whether these three ipc_ids intersect any
> cache-line. In other words I'd mark the struct ipc_ids as
> cacheline_a
Laurent Riffard wrote:
> Le 21.11.2007 23:41, Andrew Morton a écrit :
>> On Wed, 21 Nov 2007 22:45:22 +0100
>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
>>
>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>> ftp://ftp.kernel.org/pub/linux/kernel/p
Cedric Le Goater wrote:
> Pierre Peiffer wrote:
>> Each ipc_namespace contains a table of 3 pointers to struct ipc_ids (3 for
>> msg, sem and shm, structure used to store all ipcs)
>> These 'struct ipc_ids' are dynamically allocated for each icp_namespace as
>> the ipc_namespace itself (for the ini
Le 21.11.2007 23:41, Andrew Morton a écrit :
> On Wed, 21 Nov 2007 22:45:22 +0100
> Laurent Riffard <[EMAIL PROTECTED]> wrote:
>
>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-m
Pierre Peiffer wrote:
>
> Each ipc_namespace contains a table of 3 pointers to struct ipc_ids (3 for
> msg, sem and shm, structure used to store all ipcs)
> These 'struct ipc_ids' are dynamically allocated for each icp_namespace as
> the ipc_namespace itself (for the init namespace, they are initi
On [Fri, 23.11.2007 01:48], Thomas Gleixner wrote:
> On Thu, 22 Nov 2007, Andrew Morton wrote:
>
> > On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
> > > and rpm for exampl
s = 2.46 MB/sec
>>
>> /dev/sdb:
>> Timing buffered disk reads: 8 MB in 3.56 seconds = 2.25 MB/sec
>>
>> My IDE discs are fine.
>>
>> Please let me know if you need my config or any other informations.
>>
>
> And you're the se
t;
> > > These messages could indicate a timing problem. You can see the code
> > > that writes the messages near the end of wakeup_rh() in
> > > drivers/usb/host/uhci-hcd.c.
> > >
> > > The message gets written if the controller hardware hasn't tu
buffered disk reads:8 MB in 3.26 seconds = 2.46 MB/sec
>
> /dev/sdb:
> Timing buffered disk reads:8 MB in 3.56 seconds = 2.25 MB/sec
>
> My IDE discs are fine.
>
> Please let me know if you need my config or any other informations.
>
And you're the sec
t; > 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
> > working right, it could cause this problem.
>
> udelay() _is_ OK for
I have some warnings on each SCSI disc:
...
[ 30.724410] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109
PQ: 0 ANSI: 3
[ 30.724419] scsi0:A:0:0: Tagged Queuing enabled. Depth 32
[ 30.724435] target0:0:0: Beginning Domain Validation
[ 30.724446] target0:0:0: Domain Vali
On Thu, 22 Nov 2007, Andrew Morton wrote:
> On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[EMAIL PROTECTED]>
> wrote:
>
> > On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
> > and rpm for example.
> >
>
> Yes, there have been various discussions about this.
On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[EMAIL PROTECTED]>
wrote:
> On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
> and rpm for example.
>
Yes, there have been various discussions about this. I think Sam is cooking up
a fix?
-
To unsubscribe from th
On Thursday 22 November 2007 07:07:00 pm you wrote:
> On Thu, 22 Nov 2007, Kirill A. Shutemov wrote:
> > > > uhci_hcd :00:1d.3: UHCI Host Controller
> > > > uhci_hcd :00:1d.3: new USB bus registered, assigned bus number 4
> > > > uhci_hcd :00:1d.3: irq 7, io base 0xbf20
> > > > usb
On Thu, 22 Nov 2007, Kirill A. Shutemov wrote:
> > > uhci_hcd :00:1d.3: UHCI Host Controller
> > > uhci_hcd :00:1d.3: new USB bus registered, assigned bus number 4
> > > uhci_hcd :00:1d.3: irq 7, io base 0xbf20
> > > usb usb4: configuration #1 chosen from 1 choice
> > > hub 4-0:1.0
Each ipc_namespace contains a table of 3 pointers to struct ipc_ids (3 for
msg, sem and shm, structure used to store all ipcs)
These 'struct ipc_ids' are dynamically allocated for each icp_namespace as
the ipc_namespace itself (for the init namespace, they are initialized with
pointers to static
On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
and rpm for example.
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
signature.asc
Description: Digital signature
On [Wed, 21.11.2007 14:22], Andrew Morton wrote:
> On Wed, 21 Nov 2007 20:23:46 +0200
> "Kirill A. Shutemov" <[EMAIL PROTECTED]> wrote:
>
> > USB mouse(Logitech M-BT58) doesn't work. TouchPad works.
> > dmesg after rmmod usbcore && modprobe uhci_hcd:
> >
> > usbcore: registered new interface driv
On [Wed, 21.11.2007 20:33], Torsten Kaiser wrote:
> On Nov 21, 2007 10:29 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Andrew Morton wrote:
> > > > On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <
was too slow. (memory controller config is off ;)
> > I attaches my .config.
> > ==
> > [2.6.24-rc3-mm1]
> > [EMAIL PROTECTED] ~]$ dd if=/dev/zero of=./tmpfile bs=4096 count=10
> > 10+0 records in
> > 10+0 records out
> > 40960 bytes (410 MB
Andrew Morton пишет:
> On Thu, 22 Nov 2007 01:49:19 +0300
> Dmitri Vorobiev <[EMAIL PROTECTED]> wrote:
>
>> Zach Brown пишет:
> This doesn't look fine. Did you test this?
Oops, my fault. Of course, I tested the patch, but kernel modules are
disabled in my test setup, so I missed the
1 - 100 of 149 matches
Mail list logo
