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 s
>> 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 f
>[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 sc
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:
>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 to
>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
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).
>
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 th
12 matches
Mail list logo
