[PATCH 4/4] ipc/sem.c: Rename try_atomic_semop() to perform_atomic_semop(), docu update

-by: Manfred Spraul --- ipc/sem.c | 32 +--- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index 9ed3853..1dbb2fa 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -153,12 +153,15 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void

[PATCH 2/4] ipc/sem: seperate wait-for-zero and alter tasks into seperate queues

, as in linux <=3.0.9 Signed-off-by: Manfred Spraul --- include/linux/sem.h | 5 +- ipc/sem.c | 209 +--- 2 files changed, 153 insertions(+), 61 deletions(-) diff --git a/include/linux/sem.h b/include/linux/sem.h index 53d4265..55e17f6 100

[PATCH 3/4] ipc/sem.c: Always use only one queue for alter operations.

side effect, do_smart_update_queue() becomes much simpler: No more goto logic. Signed-off-by: Manfred Spraul --- ipc/sem.c | 128 ++ 1 file changed, 88 insertions(+), 40 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index ce25da3..9ed3853 1006

[PATCH 1/4] ipc/sem.c: Fix missing wakeups in do_smart_update_queue()

anned - regardless of the reason for calling do_smart_update_queue() The patch is not optimized, i.e. even completing a wait-for-zero operation causes a rescan. This is done to keep the patch as simple as possible. Avoiding unnecessary scans is implemented in the following patches. Signed-off-by: Ma

[PATCH 0/4] ipc/sem.c: Bug fixes, regression fixes, v3

remain parallelized. Apps that use lots of wait-for-zero semop are probably even faster, because the wait-for-zero ops are now only scanned if a semval is 0. -- Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger

Re: [PATCH] ipc,sem: move restart loop to do_smart_update

uot;sops = NULL", [2] sleeps forever. -- Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] ipc,sem: move restart loop to do_smart_update

] is released Without the sops = NULL, [2] sleeps forever. -- Manfred -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

[PATCH 0/4] ipc/sem.c: Bug fixes, regression fixes, v3

parallelized. Apps that use lots of wait-for-zero semop are probably even faster, because the wait-for-zero ops are now only scanned if a semval is 0. -- Manfred -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More

[PATCH 1/4] ipc/sem.c: Fix missing wakeups in do_smart_update_queue()

- regardless of the reason for calling do_smart_update_queue() The patch is not optimized, i.e. even completing a wait-for-zero operation causes a rescan. This is done to keep the patch as simple as possible. Avoiding unnecessary scans is implemented in the following patches. Signed-off-by: Manfred

[PATCH 2/4] ipc/sem: seperate wait-for-zero and alter tasks into seperate queues

, as in linux =3.0.9 Signed-off-by: Manfred Spraul manf...@colorfullife.com --- include/linux/sem.h | 5 +- ipc/sem.c | 209 +--- 2 files changed, 153 insertions(+), 61 deletions(-) diff --git a/include/linux/sem.h b/include/linux/sem.h index

[PATCH 3/4] ipc/sem.c: Always use only one queue for alter operations.

, do_smart_update_queue() becomes much simpler: No more goto logic. Signed-off-by: Manfred Spraul manf...@colorfullife.com --- ipc/sem.c | 128 ++ 1 file changed, 88 insertions(+), 40 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index ce25da3..9ed3853

[PATCH 4/4] ipc/sem.c: Rename try_atomic_semop() to perform_atomic_semop(), docu update

-by: Manfred Spraul manf...@colorfullife.com --- ipc/sem.c | 32 +--- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index 9ed3853..1dbb2fa 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -153,12 +153,15 @@ static int sysvipc_sem_proc_show

Re: [PATCH v2] ipc/sem.c: fix lockup, restore FIFO behavior

've attached a test case: ./test5.sh linux-3.0.9 completes all operations With Rik's patch, the wait-for-zero remains running. -- Manfred P.S.: Btw, I found some code that uses a semop with 2 ops: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fapis%2Fapiexusmem

[PATCH v2] ipc/sem.c: fix lockup, restore FIFO behavior

wer restarts in update_queue(), because pending wait-for-zero do not force a restart anymore. Other changes: - try_atomic_semop() also performs the semop. Thus rename the function. It passes tests with qemu, but not boot-tested due to EFI problems. Signed-off-by: Manfred Spraul --- diff --

Re: [PATCH] ipc/sem.c: fix lockup, restore FIFO behavior

Hi Rik, On 05/25/2013 03:49 PM, Rik van Riel wrote: On 05/25/2013 04:54 AM, Manfred Spraul wrote: But: Let's wait if this really exists: An application that does rarely complex operations (and that doesn't prefer FIFO semantics). I do not like that downside at all. The danger of staying

Re: [PATCH 06/10] ipc: Don't allocate a copy larger than max

l msgrcv succeeds. - with MSG_COPY, something else would happen. As far as I can see, it would oops: msg_ctlmax bytes are allocated, then the E2BIG test is against bufsz, and copy_msg() doesn't check the size of the target buffer. I.e.: I would propose to revert the patch.

[PATCH] ipc/sem.c: fix lockup, restore FIFO behavior

semantics). Other changes: - try_atomic_semop() also performs the semop. Thus rename the function. It passes tests with qemu, but not boot-tested due to EFI problems. Signed-off-by: Manfred Spraul --- diff --git a/include/linux/sem.h b/include/linux/sem.h index 53d4265..3f2c6c8 100644 --- a/include

[PATCH] ipc/sem.c: fix lockup, restore FIFO behavior

semantics). Other changes: - try_atomic_semop() also performs the semop. Thus rename the function. It passes tests with qemu, but not boot-tested due to EFI problems. Signed-off-by: Manfred Spraul manf...@colorfullife.com --- diff --git a/include/linux/sem.h b/include/linux/sem.h index 53d4265..3f2c6c8

Re: [PATCH 06/10] ipc: Don't allocate a copy larger than max

. -- Manfred -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] ipc/sem.c: fix lockup, restore FIFO behavior

Hi Rik, On 05/25/2013 03:49 PM, Rik van Riel wrote: On 05/25/2013 04:54 AM, Manfred Spraul wrote: But: Let's wait if this really exists: An application that does rarely complex operations (and that doesn't prefer FIFO semantics). I do not like that downside at all. The danger of staying

[PATCH v2] ipc/sem.c: fix lockup, restore FIFO behavior

restarts in update_queue(), because pending wait-for-zero do not force a restart anymore. Other changes: - try_atomic_semop() also performs the semop. Thus rename the function. It passes tests with qemu, but not boot-tested due to EFI problems. Signed-off-by: Manfred Spraul manf

Re: [PATCH v2] ipc/sem.c: fix lockup, restore FIFO behavior

: ./test5.sh linux-3.0.9 completes all operations With Rik's patch, the wait-for-zero remains running. -- Manfred P.S.: Btw, I found some code that uses a semop with 2 ops: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fapis%2Fapiexusmem.htm /* * Copyright (C) 1999

ipc/sem.c: Lockup with complex ops, comments not updated

ordering of the wakeups: As far as I can see complex ops are now preferred over simple ops. It's not a bug, noone exept linux implements FIFO. But the comment it line 28 should be updated Should I write a patch, do you want to fix it yourself? -- Manfred -- To unsubscribe from this list: send

ipc/sem.c: Lockup with complex ops, comments not updated

ordering of the wakeups: As far as I can see complex ops are now preferred over simple ops. It's not a bug, noone exept linux implements FIFO. But the comment it line 28 should be updated Should I write a patch, do you want to fix it yourself? -- Manfred -- To unsubscribe from this list: send

Re: linux-next: manual merge of the akpm tree with the tree

c: alternatives to preempt_disable()" from the akpm tree. I would propose that 'ipc/sem.c: alternatives to preempt_disable()' is dropped. As explained in the commit: That patch is for CONFIG_PREEMPT_RT, it should go into their tree. -- Manfred -- To unsubscribe from this list: send the line "

Re: linux-next: manual merge of the akpm tree with the tree

() from the akpm tree. I would propose that 'ipc/sem.c: alternatives to preempt_disable()' is dropped. As explained in the commit: That patch is for CONFIG_PREEMPT_RT, it should go into their tree. -- Manfred -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH v4 8/9] IPC: message queue copy feature introduced

to copy desired message (instead of unlinking it from the queue). Notes: 1) Return -ENOSYS if MSG_COPY is specified, but CONFIG_CHECKPOINT_RESTORE is not set. How is CONFIG_CHECKPOINT_RESTORE set? I'm not sure, but I think it should be added to Kconfig. -- Manfred -- To unsubscribe from

Re: [PATCH v4 9/9] test: IPC message queue migration test

Hi Stanislav, sorry for the slow reply, I finally got the time to perform tests with your patches. On 08/13/2012 02:32 PM, Stanislav Kinsbursky wrote: This test is a part of CRIU development test suit. --- tools/testing/selftests/ipc/msgque.c | 151 ++ 1

Re: [PATCH v4 9/9] test: IPC message queue migration test

Hi Stanislav, sorry for the slow reply, I finally got the time to perform tests with your patches. On 08/13/2012 02:32 PM, Stanislav Kinsbursky wrote: This test is a part of CRIU development test suit. --- tools/testing/selftests/ipc/msgque.c | 151 ++ 1

Re: [PATCH v4 8/9] IPC: message queue copy feature introduced

to copy desired message (instead of unlinking it from the queue). Notes: 1) Return -ENOSYS if MSG_COPY is specified, but CONFIG_CHECKPOINT_RESTORE is not set. How is CONFIG_CHECKPOINT_RESTORE set? I'm not sure, but I think it should be added to Kconfig. -- Manfred -- To unsubscribe from

Re: [PATCH v3 08/10] IPC: message queue copy feature introduced

Hi Stanislav, 2012/8/11 Stanislav Kinsbursky : > 11.08.2012 15:20, Manfred Spraul пишет: >> a) What about the simpler approach: >> - if MSG_COPY is set, then @mtype is interpreted as the number of the >> message that should be copied. >>If there are less than @m

Re: [PATCH v3 08/10] IPC: message queue copy feature introduced

Hi Stanislav, 2012/8/11 Stanislav Kinsbursky skinsbur...@parallels.com: 11.08.2012 15:20, Manfred Spraul пишет: a) What about the simpler approach: - if MSG_COPY is set, then @mtype is interpreted as the number of the message that should be copied. If there are less than @mtype messages

Re: [PATCH v3 08/10] IPC: message queue copy feature introduced

nd the purpose of the decrease of msq->q_copy_cnt: Do you want to handle normal msgrcv() calls in parallel with msgrcv(|MSG_COPY) calls? I don't think that this will work: What if msq->q_copy_cnt is 1 and and msgrcv() call receives the 20th message in the queue? -- Manfred -- To unsub

Re: [PATCH v3 08/10] IPC: message queue copy feature introduced

of the decrease of msq-q_copy_cnt: Do you want to handle normal msgrcv() calls in parallel with msgrcv(|MSG_COPY) calls? I don't think that this will work: What if msq-q_copy_cnt is 1 and and msgrcv() call receives the 20th message in the queue? -- Manfred -- To unsubscribe from this list: send

Re: [PATCH] ipc/sem.c: prevent ENOMEM in semop() w/ SEM_UNDO flag

and b) change user space visible behavior Thus I would prefer to avoid to implement it unless there are real applications that need this implementation. -- Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kerne

Re: [PATCH] ipc/sem.c: prevent ENOMEM in semop() w/ SEM_UNDO flag

prefer to avoid to implement it unless there are real applications that need this implementation. -- Manfred -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ipc/sem.c: prevent ENOMEM in semop() w/ SEM_UNDO flag

; This patch makes semop() be able to use vmalloc() via ipc_alloc(). > > Signed-off-by: Seiichi Ikarashi -- Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.ker

Re: [PATCH] ipc/sem.c: prevent ENOMEM in semop() w/ SEM_UNDO flag

makes semop() be able to use vmalloc() via ipc_alloc(). Signed-off-by: Seiichi Ikarashi s.ikara...@jp.fujitsu.com -- Manfred -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

__rcu_process_callbacks() in Linux 2.6

cpu cannot both complete the currently pending rcu callbacks and add new callbacks to the next cycle, thus a cpu only takes part in every other rcu cycle. The oocalc file is at http://www.colorfullife.com/~manfred/rcu.ods http://www.colorfullife.com/~manfred/rcu.pdf Is that analysis correct? Perha

__rcu_process_callbacks() in Linux 2.6

the currently pending rcu callbacks and add new callbacks to the next cycle, thus a cpu only takes part in every other rcu cycle. The oocalc file is at http://www.colorfullife.com/~manfred/rcu.ods http://www.colorfullife.com/~manfred/rcu.pdf Is that analysis correct? Perhaps the whole code should be rewritten

[PATCH] forcedeth msi bugfix

accesses to netdevice->irq with pci_dev->irq. The patch is against 2.6.23.1. IMHO suitable for both 2.6.23 and 2.6.24 Signed-Off-By: Manfred Spraul <[EMAIL PROTECTED]> --- 2.6/drivers/net/forcedeth.c 2007-10-17 21:36:36.0 +0200 +++ build-2.6/drivers/net/forcedeth.c 2007-10-

Re: MSI interrupts and disable_irq

e crash, thus I would propose to apply it to 2.6.23 and 2.6.24. I'll send a seperate mail. All other problem [reduce code duplication, less ugly locking, ...] should be fixed with independant patches. -- Manfred YH - To unsubscribe from this list: send the line "unsubs

Re: MSI interrupts and disable_irq

seems to fix the crash, thus I would propose to apply it to 2.6.23 and 2.6.24. I'll send a seperate mail. All other problem [reduce code duplication, less ugly locking, ...] should be fixed with independant patches. -- Manfred YH - To unsubscribe from this list: send the line

[PATCH] forcedeth msi bugfix

to netdevice-irq with pci_dev-irq. The patch is against 2.6.23.1. IMHO suitable for both 2.6.23 and 2.6.24 Signed-Off-By: Manfred Spraul [EMAIL PROTECTED] --- 2.6/drivers/net/forcedeth.c 2007-10-17 21:36:36.0 +0200 +++ build-2.6/drivers/net/forcedeth.c 2007-10-17 21:54:58.0 +0200

Re: MSI interrupts and disable_irq

Yinghai Lu wrote: On 10/13/07, Manfred Spraul <[EMAIL PROTECTED]> wrote: Someone around with a MSI capable board? The forcedeth driver does dev->irq = pci_dev->irq in nv_probe(), especially before pci_enable_msi(). Does pci_enable_msi() change pci_dev->irq? Then w

Re: MSI interrupts and disable_irq

Yinghai Lu wrote: On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote: Someone around with a MSI capable board? The forcedeth driver does dev-irq = pci_dev-irq in nv_probe(), especially before pci_enable_msi(). Does pci_enable_msi() change pci_dev-irq? Then we would disable the wrong

Re: MSI interrupts and disable_irq

ci_enable_msi(). Does pci_enable_msi() change pci_dev->irq? Then we would disable the wrong interrupt -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.o

Re: MSI interrupts and disable_irq

pci_enable_msi() change pci_dev-irq? Then we would disable the wrong interrupt -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

Re: MSI interrupts and disable_irq

mit() and ->poll() within local_irq_save(). Thus it seems that spin_lock_irqsave() must be used in the poll() and hard_start_xmit() callbacks, at least in nics that support POLL_CONTROLLER :-( -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel&q

Re: MSI interrupts and disable_irq

() and -poll() within local_irq_save(). Thus it seems that spin_lock_irqsave() must be used in the poll() and hard_start_xmit() callbacks, at least in nics that support POLL_CONTROLLER :-( -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: MSI interrupts and disable_irq

. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: MSI interrupts and disable_irq

. -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

Andrew Morton wrote: On Sun, 29 Jul 2007 19:05:05 +0200 Manfred Spraul <[EMAIL PROTECTED]> wrote: Hi Andrew, poll() returns -EINTR if a signal is pending. EINTR is a bad choice: it means that poll returns to user space if the task is stopped by SIGSTOP/SIGCONT or by the freezer.

Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

Andrew Morton wrote: On Sun, 29 Jul 2007 19:05:05 +0200 Manfred Spraul [EMAIL PROTECTED] wrote: Hi Andrew, poll() returns -EINTR if a signal is pending. EINTR is a bad choice: it means that poll returns to user space if the task is stopped by SIGSTOP/SIGCONT or by the freezer. select

[PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

by the kernel. The patch switches poll() to ERESTARTNOHAND. Tested with FC6. Patch against 2.6.23-rc1-mm1. Signed-off-by: Manfred Spraul <[EMAIL PROTECTED]> --- 2.6/fs/select.c 2007-07-28 20:31:51.0 +0200 +++ build-2.6/fs/select.c 2007-07-28 21:21:52.0 +0200 @@ -621,7

[PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

by the kernel. The patch switches poll() to ERESTARTNOHAND. Tested with FC6. Patch against 2.6.23-rc1-mm1. Signed-off-by: Manfred Spraul [EMAIL PROTECTED] --- 2.6/fs/select.c 2007-07-28 20:31:51.0 +0200 +++ build-2.6/fs/select.c 2007-07-28 21:21:52.0 +0200 @@ -621,7 +621,7

Re: which signal is sent to freeze process?

a poll test app. Boot tested with FC6. What do you think? With ERESTARTNOHAND, poll would only return to user space if the app has a SIGCONT handler installed. -- Manfred --- 2.6/fs/select.c 2007-05-20 09:52:32.0 +0200 +++ build-2.6/fs/select.c 2007-07-23 22:10:21.000

Re: which signal is sent to freeze process?

. Boot tested with FC6. What do you think? With ERESTARTNOHAND, poll would only return to user space if the app has a SIGCONT handler installed. -- Manfred --- 2.6/fs/select.c 2007-05-20 09:52:32.0 +0200 +++ build-2.6/fs/select.c 2007-07-23 22:10:21.0 +0200

RE: which signal is sent to freeze process?

l, I'm afraid we can't place try_to_freeze() in every system call that does something like that ... I don't understand why the poll() system call returns to user space. poll() uses ERESTARTNOHAND, thus it should not return to user space. Any ideas why ERESTARTNOHAND doesn't work? -- M

Re: which signal is sent to freeze process?

at sys_ppoll(). sys_ppoll() and select() use ERESTARTNOHAND, sys_poll uses EINTR. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please re

Re: which signal is sent to freeze process?

at sys_ppoll(). sys_ppoll() and select() use ERESTARTNOHAND, sys_poll uses EINTR. -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

RE: which signal is sent to freeze process?

we can't place try_to_freeze() in every system call that does something like that ... I don't understand why the poll() system call returns to user space. poll() uses ERESTARTNOHAND, thus it should not return to user space. Any ideas why ERESTARTNOHAND doesn't work? -- Manfred

mptscsi timeout error

1. mptscsi timeout error 2. problem/report = I want to configure a parallel file system. I checked 'lustre', 'GFS' and 'PVFS2' on different systems and found always the same or a similary errors. Wenn I try to write 50 files on the filesystem parallel

mptscsi timeout error

: 00 Id: 08 Lun: 04 Vendor: IFT Model: A16F-G2430 Rev: 348B Type: Direct-AccessANSI SCSI revision: 04 I am able to make further test or to give further informations. Regards M. Schultz ___ Manfred Schultz, Astrophysikalisches Institut

Re: preempt_rt bug or warn on arm v4t

what is wrong. thanks regards manfred Am Freitag, 20. April 2007 15:26 schrieben Sie: > hi jan ! > > Am Freitag, 20. April 2007 15:01 schrieben Sie: > > > I am using 2.6.21-rc7 with Preempt_rt Patch 2.6.20-rc6-rt0 on ep93xx. > > > > Do you mean 2.6.21-rc6-rt0

Re: preempt_rt bug or warn on arm v4t

what is wrong. thanks regards manfred Am Freitag, 20. April 2007 15:26 schrieben Sie: hi jan ! Am Freitag, 20. April 2007 15:01 schrieben Sie: I am using 2.6.21-rc7 with Preempt_rt Patch 2.6.20-rc6-rt0 on ep93xx. Do you mean 2.6.21-rc6-rt0? sorry yes 2.6.21-rc6-rt0. This oops does

Re: preempt_rt bug or warn on arm v4t

t does only appear, when the preempt_rt patch is applied. Did I get you > right? correct regards manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Pleas

preempt_rt bug or warn on arm v4t

here: https://dev.contec.at/dev/micro/micro9/LINUX/trunk/kernel/linux-2.6/patches/ thanks regards manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.ht

preempt_rt bug or warn on arm v4t

manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: preempt_rt bug or warn on arm v4t

is applied. Did I get you right? correct regards manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[CFT] forcedeth backport to 2.4

ethtool support - 64-bit dma support - support for additional nforce versions. It compiles and boots, but I can't test it properly. Could you give it a try? -- Manfred --- 2.4/drivers/net/forcedeth.c 2005-01-19 15:09:56.0 +0100 +++ build-2.4/drivers/net/forcedeth.c 2005-09-04 13:58

[CFT] forcedeth backport to 2.4

ethtool support - 64-bit dma support - support for additional nforce versions. It compiles and boots, but I can't test it properly. Could you give it a try? -- Manfred --- 2.4/drivers/net/forcedeth.c 2005-01-19 15:09:56.0 +0100 +++ build-2.4/drivers/net/forcedeth.c 2005-09-04 13:58

Re: [PATCH 2/2] pipe: do not return POLLERR for fifo_poll

with a comment that Linux fifos behave exactly like pipes, unlike the behavior of most unices. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo

Re: [PATCH 2/2] pipe: do not return POLLERR for fifo_poll

with a comment that Linux fifos behave exactly like pipes, unlike the behavior of most unices. -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please

[PATCH] slab: removes local_irq_save()/local_irq_restore() pair

Proposed by and based on a patch from Eric Dumazet <[EMAIL PROTECTED]>: This patch removes unnecessary critical section in ksize() function, as cli/sti are rather expensive on modern CPUS. It additionally adds a docbook entry for ksize() and further simplifies the code. Signed-Off-By: M

[PATCH] slab: removes local_irq_save()/local_irq_restore() pair

Proposed by and based on a patch from Eric Dumazet [EMAIL PROTECTED]: This patch removes unnecessary critical section in ksize() function, as cli/sti are rather expensive on modern CPUS. It additionally adds a docbook entry for ksize() and further simplifies the code. Signed-Off-By: Manfred

Re: ACPI Standby and nvidia ethernet driver causes network errors and drops

fixed. -- Manfred --- 2.6/drivers/net/forcedeth.c 2005-08-14 11:17:03.0 +0200 +++ build-2.6/drivers/net/forcedeth.c 2005-08-14 11:16:53.0 +0200 @@ -93,6 +93,8 @@ * 0.40: 19 Jul 2005: Add support for mac address change. * 0.41: 30 Jul 2005: Write back original

Re: ACPI Standby and nvidia ethernet driver causes network errors and drops

fixed. -- Manfred --- 2.6/drivers/net/forcedeth.c 2005-08-14 11:17:03.0 +0200 +++ build-2.6/drivers/net/forcedeth.c 2005-08-14 11:16:53.0 +0200 @@ -93,6 +93,8 @@ * 0.40: 19 Jul 2005: Add support for mac address change. * 0.41: 30 Jul 2005: Write back original

Re: Opening of blocking FIFOs not reliable?

. This one is decreased during close(). PIPE_WCOUNTER counts how often a writer was seen. It's never decreased. Readers that wait for a writer wait until PIPE_WCOUNTER changes, they do not look at PIPE_WRITERS. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-k

Re: Opening of blocking FIFOs not reliable?

. This one is decreased during close(). PIPE_WCOUNTER counts how often a writer was seen. It's never decreased. Readers that wait for a writer wait until PIPE_WCOUNTER changes, they do not look at PIPE_WRITERS. -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [SLAB] __builtin_return_address use without FRAME_POINTER causes boot failure

pointers that are in kernel_text_address(). See store_stack_info() in mm/slab.c. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html P

Re: [SLAB] __builtin_return_address use without FRAME_POINTER causes boot failure

pointers that are in kernel_text_address(). See store_stack_info() in mm/slab.c. -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: [SLAB] __builtin_return_address use without FRAME_POINTER causes boot failure

frame pointers, but slab only uses __builtin_return_addresse(0), which should always work. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo

Re: Fw: two 2.6.13-rc3-mm3 oddities

Dipankar Sarma wrote: Hugh, could you please try this with the experimental patch below ? Manfred, is it safe to decrement nr_files in file_free() instead of the destructor ? I can't see any problem. The ctor/dtor are only called when new objects are created, not on every kmem_cache_alloc

Re: Fw: two 2.6.13-rc3-mm3 oddities

Dipankar Sarma wrote: Hugh, could you please try this with the experimental patch below ? Manfred, is it safe to decrement nr_files in file_free() instead of the destructor ? I can't see any problem. The ctor/dtor are only called when new objects are created, not on every kmem_cache_alloc

Re: [SLAB] __builtin_return_address use without FRAME_POINTER causes boot failure

frame pointers, but slab only uses __builtin_return_addresse(0), which should always work. -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please

Re: [PATCH] forcedeth: TX handler changes (experimental)

Daniel Drake wrote: So, you want this instead: #define DEV_HAS_LARGEDESC0x0004 Autsch. Yes, you are right. Sorry for that, I should have reread the patch once more. I've fixed it on my website. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-k

Re: [PATCH] forcedeth: TX handler changes (experimental)

Daniel Drake wrote: Hi, Manfred Spraul wrote: Attached is a patch that modifies the tx interrupt handling of the nForce nic. It's part of the attempts to figure out what causes the nic hangs (see bug 4552). The change is experimental: It affects all nForce versions. I've tested it on my

[PATCH] forcedeth: TX handler changes (experimental)

versions. I've tested it on my nForce 250-Gb. Please test it. And especially: If you experince a nic hang, please send me the debug output. That's the block starting with << NETDEV WATCHDOG: eth1: transmit timed out eth1: Got tx_timeout. irq: eth1: Ring at ... << Thanks

[PATCH] forcedeth: TX handler changes (experimental)

: If you experince a nic hang, please send me the debug output. That's the block starting with << NETDEV WATCHDOG: eth1: transmit timed out eth1: Got tx_timeout. irq: eth1: Ring at ... << Thanks, Manfred - To unsubscribe from this list: send the line "unsubsc

[PATCH] forcedeth: TX handler changes (experimental)

: If you experince a nic hang, please send me the debug output. That's the block starting with NETDEV WATCHDOG: eth1: transmit timed out eth1: Got tx_timeout. irq: eth1: Ring at ... Thanks, Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

[PATCH] forcedeth: TX handler changes (experimental)

versions. I've tested it on my nForce 250-Gb. Please test it. And especially: If you experince a nic hang, please send me the debug output. That's the block starting with NETDEV WATCHDOG: eth1: transmit timed out eth1: Got tx_timeout. irq: eth1: Ring at ... Thanks, Manfred

Re: [PATCH] forcedeth: TX handler changes (experimental)

Daniel Drake wrote: Hi, Manfred Spraul wrote: Attached is a patch that modifies the tx interrupt handling of the nForce nic. It's part of the attempts to figure out what causes the nic hangs (see bug 4552). The change is experimental: It affects all nForce versions. I've tested it on my

Re: [PATCH] forcedeth: TX handler changes (experimental)

Daniel Drake wrote: So, you want this instead: #define DEV_HAS_LARGEDESC0x0004 Autsch. Yes, you are right. Sorry for that, I should have reread the patch once more. I've fixed it on my website. -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: Patch for slab leak debugging

. No, I never wrote a proper /proc interface. But I think the bufctl approach is the better solution than storing the first 5 entries in the slab structure: What if there is a leak on a cache with more than 5 entries per slab? -- Manfred - To unsubscribe from this list: send the line

Re: Patch for slab leak debugging

. No, I never wrote a proper /proc interface. But I think the bufctl approach is the better solution than storing the first 5 entries in the slab structure: What if there is a leak on a cache with more than 5 entries per slab? -- Manfred - To unsubscribe from this list: send the line

Re: [patch 1/9] GFP_ZERO fix

). Should I write a patch? -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [patch 1/9] GFP_ZERO fix

? -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched

On Sat, 9 Apr 2005, Francois Romieu wrote: > Manfred Spraul <[EMAIL PROTECTED]> : > > [Jeff added to cc list - it's a network driver question] > [...] > > I haven't read the whole driver, but what about > > spin_unlock_wait(>xmit_lock); > > ? > >

Re: [RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched

spin_unlock_wait(>xmit_lock); ? hard_start_xmit is called under dev->xmit_lock, waiting until the lock is free would guarantee that all running instances of hard_start_xmit have completed. Jeff: Is that still correct? -- Manfred - To unsubscribe from this list: send the line "

<    4   5   6   7   8   9   10   11   12   13   >