Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Apr 2013 21:00:27 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        Peter Wemm <peter@wemm.org>
Cc:        svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-9@freebsd.org
Subject:   Re: svn commit: r249611 - in stable/9/sys/cam: ata scsi
Message-ID:  <517AC0BB.4040207@FreeBSD.org>
In-Reply-To: <CAGE5yCrdLUmgDOkFy7u8PpwUgtCcD4=kv0UVO79RPMR80mJ1xQ@mail.gmail.com>
References:  <201304180944.r3I9i05t093967@svn.freebsd.org> <CAGE5yCrdLUmgDOkFy7u8PpwUgtCcD4=kv0UVO79RPMR80mJ1xQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 26.04.2013 19:47, Peter Wemm wrote:
> On Thu, Apr 18, 2013 at 2:44 AM, Alexander Motin <mav@freebsd.org> wrote:
>> Author: mav
>> Date: Thu Apr 18 09:44:00 2013
>> New Revision: 249611
>> URL: http://svnweb.freebsd.org/changeset/base/249611
>>
>> Log:
>>    MFC r248872, r249048:
>>    Make pre-shutdown flush and spindown routines to not use xpt_polled_action(),
>>    but execute the commands in regular way.  There is no any reason to cook CPU
>>    while the system is still fully operational.  After this change polling in
>>    CAM is used only for kernel dumping.
>
> FYI, this causes some drivers to deadlock when you attempt to cleanly
> reboot the machine.  eg: mpt based systems.

Thank you for the report, but I've seen your first email 23.04 and 
replied you with proposed solution the same day.

> Adding new assumptions about interrupt-driven hooks continuing to work
> after the post-sync shutdown hooks don't seem like a -stable
> candidate.

That is not "after the post-sync", but the post-sync itself. Is it 
written somewhere that it should not work? Because several GEOM modules 
are also doing some disk writes at post-sync stage and they expect to be 
handled in normal way.

> This breaks a number of machines in the freebsd.org cluster.  I have
> to back out both of these changes to get them to reboot.

I've made a search though the base system and found only two drivers 
affected by this change: mpt and hptmv. I've patched both at head 
r249849 and going to merge fix to stable/9 tomorrow unless objected. 
Have you tried that patch instead of reverting?

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?517AC0BB.4040207>