Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Dec 2012 21:29:11 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Dieter BSD <dieterbsd@engineer.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: FreeBSD for serious performance?
Message-ID:  <CAJ-VmonbwNpykKPCFNxHcyoU7-qLa2LbsREJQ0oci0wL6d1=pg@mail.gmail.com>
In-Reply-To: <20121226025115.91860@gmx.com>
References:  <20121226025115.91860@gmx.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

If the driver is doing something daft like DELAY(x) in a fast
interrupt handler which would lead to that behaviour, it should be
fixed.

If it's doing a DELAY(x) in a critical section, it shuld be fixed.

Otherwise, a DELAY(x) in a driver only chews CPU; the scheduler can
preempt that. I don't agree with this behaviour, but it's possible.

Now, it's quite likely you hit some kind of ata(4) bug which kept it
in a tight loop without some kind of "too many errors; bailing"
behaviour. I'm not an ata driver person; i have no idea why it's doing
that.

The driver shouldn't be disabling interrupts for other devices. That
happens in critical sections and when doing lock operations. ata(4)
doesn't call critical_* in the driver code. So it was likely just spun
in some high priority loop that nothing lower-priority could really do
anything about.

The next time it happens, please break into the debugger and grab some
debugging output. Show alllocks, ps, should be a good couple of things
to start with.

Alternately - please find a currently actively maintained SATA chipset.

(Or Alternatively - step up and help migrate the nvidia chipset
support out of ata(4).)



Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonbwNpykKPCFNxHcyoU7-qLa2LbsREJQ0oci0wL6d1=pg>