I initially upgraded my kernel from 2.4.2-ac5 to 2.4.3 and the first thing I
noticed was that mysqld was stuck. Killing it left it hanging in a D state.
Then I tried 2.4.2-ac28 (which I am using now), and the got the same result.
My key_buffer was set to 256MB, so I figured maybe it was something to do
with memory usage so I lowered that figured to 128MB and restarted the
system to clear the D state procs. Everything works fine now. 2.4.2-ac5
did not have issues with the larger key_buffer.
Can anyone reproduce this problem?
--
Vibol Hou
KhmerConnection, http://khmer.cc
"Connecting Cambodian Minds, Art, and Culture"
> I initially upgraded my kernel from 2.4.2-ac5 to 2.4.3 and the first thing I
> noticed was that mysqld was stuck. Killing it left it hanging in a D state.
> Then I tried 2.4.2-ac28 (which I am using now), and the got the same result.
I'd expect that bit. 2.4.2-ac28 basically has the same new rwlock VM and
behaviour as 2.4.3pre8. What would be really useful to know is if anyone can
duplicate the problem non x86
> Can anyone reproduce this problem?
Yes
Alan Cox wrote:
>
> > I initially upgraded my kernel from 2.4.2-ac5 to 2.4.3 and the first thing I
> > noticed was that mysqld was stuck. Killing it left it hanging in a D state.
> > Then I tried 2.4.2-ac28 (which I am using now), and the got the same result.
>
> I'd expect that bit. 2.4.2-ac28 basically has the same new rwlock VM and
> behaviour as 2.4.3pre8. What would be really useful to know is if anyone can
> duplicate the problem non x86
>
> > Can anyone reproduce this problem?
>
> Yes
Untested patch:
--- semaphore.c.orig Wed Apr 4 12:54:30 2001
+++ semaphore.c Wed Apr 4 12:54:58 2001
@@ -363,26 +363,26 @@
*/
struct rw_semaphore *down_write_failed(struct rw_semaphore *sem)
{
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
__up_write(sem); /* this takes care of granting the lock
*/
- add_wait_queue_exclusive(&sem->wait, &wait);
+ add_wait_queue_exclusive(&sem->write_bias_wait, &wait);
while (atomic_read(&sem->count) < 0) {
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (atomic_read(&sem->count) >= 0)
break; /* we must attempt to acquire or bias
the lock */
schedule();
}
- remove_wait_queue(&sem->wait, &wait);
+ remove_wait_queue(&sem->write_bias_wait, &wait);
tsk->state = TASK_RUNNING;
return sem;
}
asm(
"
.align 4
Andrew,
I've applied the patch. The processes usually start dying within a few
minutes so it shouldn't be hard to tell if this patch is working or not.
I'll let you know what's up.
-Vibol
-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Andrew Morton
Sent: Wednesday, April 04, 2001 12:57 PM
To: Alan Cox
Cc: Vibol Hou; Linux-Kernel
Subject: Re: mysqld [3.2.23] hangs when key_buffer ~256MB on
[2.4.2-ac28+]
Alan Cox wrote:
>
> > I initially upgraded my kernel from 2.4.2-ac5 to 2.4.3 and the first
thing I
> > noticed was that mysqld was stuck. Killing it left it hanging in a D
state.
> > Then I tried 2.4.2-ac28 (which I am using now), and the got the same
result.
>
> I'd expect that bit. 2.4.2-ac28 basically has the same new rwlock VM and
> behaviour as 2.4.3pre8. What would be really useful to know is if anyone
can
> duplicate the problem non x86
>
> > Can anyone reproduce this problem?
>
> Yes
Untested patch:
--- semaphore.c.orig Wed Apr 4 12:54:30 2001
+++ semaphore.c Wed Apr 4 12:54:58 2001
@@ -363,26 +363,26 @@
*/
struct rw_semaphore *down_write_failed(struct rw_semaphore *sem)
{
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
__up_write(sem); /* this takes care of granting the lock
*/
- add_wait_queue_exclusive(&sem->wait, &wait);
+ add_wait_queue_exclusive(&sem->write_bias_wait, &wait);
while (atomic_read(&sem->count) < 0) {
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (atomic_read(&sem->count) >= 0)
break; /* we must attempt to acquire or bias
the lock */
schedule();
}
- remove_wait_queue(&sem->wait, &wait);
+ remove_wait_queue(&sem->write_bias_wait, &wait);
tsk->state = TASK_RUNNING;
return sem;
}
asm(
"
.align 4