on the 10-23-2012 unagi device, enabling bluetooth option triggers this error. Bluetooth is detected correctly, so not sure if this is a benign error. 10-23 14:24:33.039: I/qcom-bluetooth(9024): /system/etc/init.qcom.bt.sh: start hciattach 10-23 14:24:33.059: I/qcom-bluetooth(9026): /system/etc/init.qcom.bt.sh: start_hciattach: pid = 9025 10-23 14:24:33.199: I/Gonk(2124): log_and_free_dbus_error: D-Bus error: org.freedesktop.DBus.Error.ServiceUnknown (The name org.bluez was not provided by any .service files) Repro: 1) 10-23-2012 daily unagi build, buildID: 20121023071141 2) settings > enable bluetooth 3) Verify error: log_and_free_dbus_error: D-Bus error: org.freedesktop.DBus.Error.ServiceUnknown (The name org.bluez was not provided by any .service files) Expected: - no error on enabling

nom for blocking-basecamp just because i dont know what this does. -, if harmless.

Definitly should block. This is bad.

Blocking-basecamp, because Kyle says that we're completely broken until this is resolved.

Ok so Kyle was wrong on this one. Too many errors looking the same when they aren't. :( I'm not sure if this is happening in gaia or gecko, but somewhere soon after bluetooth activation, something is trying to call into bluetooth's DBus functions before the driver has had a chance to finish. We need to figure out what that is. This isn't actually causing a crash or, as far as I can tell, any serious issues with bluetooth functionality. So it may not actually block basecamp. Resetting to ?, will update again in triage tomorrow.

Message doesn't seem to be causing any problems so not a blocker.

This bug only happens after enabling Bluetooth because we try to get adapter path by calling GetDefaultAdapterPath() in BluetoothDBusService::StartInternal() but failed. When Bluetooth is getting up, it requires a short period of time for Manager interface of BlueZ creating a new DefaultAdapter property, which means that it would fail if we try to get DefaultAdapter earlier than it has been created. It seems that we don't have to know what the DefaultAdapter is at the moment, however, we do. We need to get adapter path here to deal with the "cannot get adapter path because we won't get AdapterAdded event after process restarts" problem. Please see bug 797801 for more information. For current design of Bluetooth module in Gecko, I think it's o.k to say this will not affect main functions of BT or the whole system. But in my opinion, it would be better if we could refine this part of code to avoid this error message.

Won't fix for the moment.