aults". The library must touch pages
ahead to make them present in the memory; occasional page faults is
acceptable. It will retry.
Bulent
From: "Sukadev Bhattiprolu"
To: "Christophe Leroy"
Cc: "Will Springer" ,
linuxppc-dev@lists.ozlabs.org, dan...@oct
copied verbatim from P9 DD2 Nest Accelerators Workbook Version 3.2
Table 4-36. CSB Non-zero CC Reported Error Types
CC=5, Error Type: Translation,
Comment: Unused, defined by RFC02130 (footnote: DMA controller uses this
CC internally in translation fault handling. Do not reuse for other
help
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I get an occasional panic in __tcp_inherit_port(sk,child). I believe the
reason is tb=sk->prev is NULL.
sk->prev is set to NULL in only few places including __tcp_put_port(sk).
Perhaps there is a serialization problem between __tcp_inherit_port and
__tcp_put_port ??? One possibility is that
I get an occasional panic in __tcp_inherit_port(sk,child). I believe the
reason is tb=sk-prev is NULL.
sk-prev is set to NULL in only few places including __tcp_put_port(sk).
Perhaps there is a serialization problem between __tcp_inherit_port and
__tcp_put_port ??? One possibility is that
>> I am running in to a problem, seemingly a deadlock situation, where
almost
>> all the processes end up in the TASK_UNINTERRUPTIBLE state. All the
>
>could you try to reproduce with this patch applied on top of
>2.4.6pre5aa1 or 2.4.6pre5 vanilla?
Andrea,
I would like try your patch but so
I am running in to a problem, seemingly a deadlock situation, where
almost
all the processes end up in the TASK_UNINTERRUPTIBLE state. All the
could you try to reproduce with this patch applied on top of
2.4.6pre5aa1 or 2.4.6pre5 vanilla?
Andrea,
I would like try your patch but so far I
>[EMAIL PROTECTED] said:
>> I am running in to a problem, seemingly a deadlock situation, where
>> almost all the processes end up in the TASK_UNINTERRUPTIBLE state.
>> All the process eventually stop responding, including login shell, no
>> screen updates, keyboard etc. Can ping and sysrq key
keywords: tux, aic7xxx, 2.4.5-ac4, specweb99, __wait_on_page, __lock_page
Greetings,
I am running in to a problem, seemingly a deadlock situation, where almost
all the processes end up in the TASK_UNINTERRUPTIBLE state. All the
process eventually stop responding, including login shell, no
keywords: tux, aic7xxx, 2.4.5-ac4, specweb99, __wait_on_page, __lock_page
Greetings,
I am running in to a problem, seemingly a deadlock situation, where almost
all the processes end up in the TASK_UNINTERRUPTIBLE state. All the
process eventually stop responding, including login shell, no
[EMAIL PROTECTED] said:
I am running in to a problem, seemingly a deadlock situation, where
almost all the processes end up in the TASK_UNINTERRUPTIBLE state.
All the process eventually stop responding, including login shell, no
screen updates, keyboard etc. Can ping and sysrq key works.
Justin,
Your patch works for me. printk "Temporary Resource Shortage"
has to go, or may be you can make it a debug option.
Here is the cleaned up patch for 2.4.5-ac15 with TAILQ
macros replaced with LIST macros. Thanks for the help.
Bulent
--- aic7xxx_linux.c.save Mon Jun 18 20:25:35 2001
Justin,
Your patch works for me. printk Temporary Resource Shortage
has to go, or may be you can make it a debug option.
Here is the cleaned up patch for 2.4.5-ac15 with TAILQ
macros replaced with LIST macros. Thanks for the help.
Bulent
--- aic7xxx_linux.c.save Mon Jun 18 20:25:35 2001
Justin,
When free memory is low, I get a series of aic7xxx messages followed by
panic.
It appears to be a race condition in the code. Should you panic? I tried
the following
patch to not panic. But I am not sure if it is functionally correct.
Bulent
scsi0: Temporary Resource Shortage
scsi0:
Justin,
When free memory is low, I get a series of aic7xxx messages followed by
panic.
It appears to be a race condition in the code. Should you panic? I tried
the following
patch to not panic. But I am not sure if it is functionally correct.
Bulent
scsi0: Temporary Resource Shortage
scsi0:
>The fix is to kill the dead/orphaned swap pages before we get to
>swapoff. At shutdown time there is practically nothing active in
> ...
>Once the dead swap pages problem is fixed it is time to optimize
>swapoff.
I think fixing the orphaned swap pages problem will eliminate the
problem all
The fix is to kill the dead/orphaned swap pages before we get to
swapoff. At shutdown time there is practically nothing active in
...
Once the dead swap pages problem is fixed it is time to optimize
swapoff.
I think fixing the orphaned swap pages problem will eliminate the
problem all
>Bulent,
>
>Could you please check if 2.4.6-pre2+the schedule patch has better
>swapoff behaviour for you?
Marcelo,
It works as expected. Doesn't lockup the box however swapoff keeps burning
the CPU cycles. It took 4 1/2 minutes to swapoff about 256MB of swap
content. Shutdown took just
Bulent,
Could you please check if 2.4.6-pre2+the schedule patch has better
swapoff behaviour for you?
Marcelo,
It works as expected. Doesn't lockup the box however swapoff keeps burning
the CPU cycles. It took 4 1/2 minutes to swapoff about 256MB of swap
content. Shutdown took just as
>> I looked at try_to_unuse in swapfile.c. I believe that the algorithm is
>> broken.
>> For each and every swap entry it is walking the entire process list
>> (for_each_task(p)). It is also grabbing a whole bunch of locks
>> for each swap entry. It might be worthwhile processing swap entries
I looked at try_to_unuse in swapfile.c. I believe that the algorithm is
broken.
For each and every swap entry it is walking the entire process list
(for_each_task(p)). It is also grabbing a whole bunch of locks
for each swap entry. It might be worthwhile processing swap entries in
swap entries in
batches instead of one entry at a time.
In any case, I think having this patch is worthwhile as a quick and dirty
remedy.
Bulent Abali
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
>> O.k. I think I'm ready to nominate the dead swap pages for the big
>> 2.4.x VM bug award. So we are burning cpu cycles in sys_swapoff
>> instead of being IO bound? Just wanting to understand this the cheap
way :)
>
>There's no IO being done whatsoever (that I can see with only a blinky).
O.k. I think I'm ready to nominate the dead swap pages for the big
2.4.x VM bug award. So we are burning cpu cycles in sys_swapoff
instead of being IO bound? Just wanting to understand this the cheap
way :)
There's no IO being done whatsoever (that I can see with only a blinky).
I can
is worthwhile as a quick and dirty
remedy.
Bulent Abali
-
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/
Interrupt service routine of a driver makes a wake_up_interruptible_all()
call to wake up a kernel thread. Is that legitimate? Thanks for any
advice
you might have. please cc: your response to me if you decide to post to
the mailing list.
Bulent
-
To unsubscribe from this list: send
Interrupt service routine of a driver makes a wake_up_interruptible_all()
call to wake up a kernel thread. Is that legitimate? Thanks for any
advice
you might have. please cc: your response to me if you decide to post to
the mailing list.
Bulent
-
To unsubscribe from this list: send
27 matches
Mail list logo
