Bug #1878

dsched_fq and occasional console freeze

Added by qhwt.dfly about 4 years ago. Updated about 4 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Hi.
When the current dsched policy is set to fq, the console (or ssh connection)
occasionally freezes (becomes unresponsive, even to ctrl+T). However,
I can still switch between ttyvN terminals by pressing Alt+Fn keys,
and drop to DDB (I remember reading a similar description in the past,
but I couldn't find the message in my mailbox).

Unfortunately, the kernel dumping locks up too in that case
(no progress is printed on the screen), so no vmcore is available
at the moment. FWIW, dsched_fq is loaded as kernel module and the policy
is set via /etc/rc.d/sysctl.

This is on an Atom D510 with 4G bytes of RAM and running a very recent
-DEVELOPMENT x86_64 kernel; I haven't tried it on a PC running 32-bit
version yet.

History

#1 Updated by elekktretterr about 4 years ago

> Hi.
> When the current dsched policy is set to fq, the console (or ssh
> connection)
> occasionally freezes (becomes unresponsive, even to ctrl+T). However,
> I can still switch between ttyvN terminals by pressing Alt+Fn keys,
> and drop to DDB (I remember reading a similar description in the past,
> but I couldn't find the message in my mailbox).
>
> Unfortunately, the kernel dumping locks up too in that case
> (no progress is printed on the screen), so no vmcore is available
> at the moment. FWIW, dsched_fq is loaded as kernel module and the policy
> is set via /etc/rc.d/sysctl.
>
> This is on an Atom D510 with 4G bytes of RAM and running a very recent
> -DEVELOPMENT x86_64 kernel; I haven't tried it on a PC running 32-bit
> version yet.
>

I wonder if this:
http://leaf.dragonflybsd.org/mailarchive/bugs/2010-10/msg00085.html

is related, I did enable DSCHED_FQ via sysctl just before I ran "hammer
cleanup" I remember now, and the symptoms are same - freeze but can switch
between terminals, but can't actually execute any command because they are
all "hanging", for about 5 minutes and eventually freeze completely but
without a kernel dump.

Petr

#2 Updated by dillon about 4 years ago

:I wonder if this:
:http://leaf.dragonflybsd.org/mailarchive/bugs/2010-10/msg00085.html
:
:is related, I did enable DSCHED_FQ via sysctl just before I ran "hammer
:cleanup" I remember now, and the symptoms are same - freeze but can switch
:between terminals, but can't actually execute any command because they are
:all "hanging", for about 5 minutes and eventually freeze completely but
:without a kernel dump.
:
:Petr

I think it might be. A bug in DSCHED_FQ could cause the I/O to not
get properly completed and stall the NFS server.

-Matt
Matthew Dillon
<>

#3 Updated by alexh about 4 years ago

Well, I fail to find anything that might be causing this in dsched_fq. The code
is only around 600 lines, so it'd be good if more people would take a look at it
to see if anyone finds issues.

Cheers,
Alex Hornung

PS: dsched is a framework, so please, people, write some (better fair-share)
disk scheduler!

Also available in: Atom PDF