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
>> 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).
>
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
>> 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
>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
>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
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,
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
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
>[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
>> 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
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
12 matches
Mail list logo
