Return-Path: MIME-Version: 1.0 In-Reply-To: <20130528071306.GA31172@x220> References: <61DC8CEB-C49A-466F-B5E3-F5B60D398157@holtmann.org> <20130522172213.GA12160@samus.indt.org> <1E509939-3804-43E0-A047-09CCD38A4713@holtmann.org> <20130528071306.GA31172@x220> From: Alex Deymo Date: Wed, 29 May 2013 14:51:48 -0700 Message-ID: Subject: Re: [BUG] Set Powered=true doesn't power up the adapter To: Marcel Holtmann , Vinicius Costa Gomes , BlueZ development , Johan Hedberg Content-Type: text/plain; charset=ISO-8859-1 List-ID: Hi, On Tue, May 28, 2013 at 12:13 AM, Johan Hedberg wrote: > > On Wed, May 22, 2013, Marcel Holtmann wrote: > > In case hci_dev_open() fails and rfkill would be one example for that, > > we do not return an error back to the mgmt command that originates > > this power on. > > > > Of course there is the initial adapter power on and there is the mgmt > > triggered power on. And my guess is that these two are racing against > > each other. > > It seems you're right about the cause. I just sent a patch to fix it. I saw the patch about return an error back to the userspace, but still there is something weird here: I think I omit an important detail on my first email (ups =D.. but it was on our linked bug). After reboot, a power up initiated using the mgmt interface from the bluetoothd will not return, but the previously connected devices do work. So the adapter is connected to, for example, a mouse, and after reboot the adapter will be shown as Powered: False, Set Powered doesn't return, but you can happily move the bt mouse and it works. Do you think that the patch about rfkill ( [PATCH] Bluetooth: Fix mgmt handling of power on failures ) should be enough to fix this issue? I'm still trying to reproduce the problem with dynamic debug enabled for bluetooth and launching bluetoothd with MGMT_DEBUG. The machine keeps rebooting until it faces the problem again... but no luck so far =( Thanks, Alex.