From: Colin Beckingham <hidden> Date: 2011-08-04 11:10:01
I'd like to provide some feedback regarding a Samsung WEP475 headset
which fails to connect to linux specifically.
The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR ADAPTER
v2.1 UHE which successfully interconnects with 2 Jabra and 1 Plantronics
headsets, plus a Nokia E71 phone. Samsung WEP475 successfully connects
to a Windows XP machine and to the Nokia E71.
Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails with
2.6.38), bluez 4.96 and bluedevil manager.
Symptoms are that bluedevil sees the headset in pairing mode and
correctly retrieves the name WEP475, connected button flashes green and
then returns to grey (not connected). WEP475 led changes to connected
status but bluedevil shows headset not connected and headset does not work.
With bluetoothd in debug mode, I get the following transactions in
/var/log/messages:
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:conn_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_get_device() 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:remote_features_information() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:remote_name_information() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
audio/headset.c:headset_set_channel() Discovered Handsfree service on
channel 2
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
audio/headset.c:rfcomm_connect() /org/bluez/13226/hci0/dev_00_---_47:
Connecting to 00:---:47 channel 2
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() hci0 dba 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:get_auth_info() hci0 dba 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() kernel auth requirements = 0x04
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() Matching key found
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() link key type 0x04
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:auth_complete() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:bonding_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/event.c:btd_event_bonding_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_get_device() 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/device.c:device_bonding_complete() bonding (nil) status 0x00
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]: Permission denied (13)
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
audio/headset.c:headset_set_state() State changed
/org/bluez/13226/hci0/dev_00_---_47: HEADSET_STATE_CONNECTING ->
HEADSET_STATE_DISCONNECTED
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:disconn_complete() handle 11 status 0x00
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
src/event.c:btd_event_disconn_complete()
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_remove_connection()
I have tried clearing the contents of /var/lib/bluetooth/ forcing the
system to recreate, but no difference.
--
---
Colin Beckingham
From: Colin Beckingham <hidden> Date: 2011-08-04 11:30:24
On 08/04/2011 07:10 AM, Colin Beckingham wrote:
I'd like to provide some feedback regarding a Samsung WEP475 headset
which fails to connect to linux specifically.
The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR ADAPTER
v2.1 UHE which successfully interconnects with 2 Jabra and 1 Plantronics
headsets, plus a Nokia E71 phone. Samsung WEP475 successfully connects
to a Windows XP machine and to the Nokia E71.
Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails with
2.6.38), bluez 4.96 and bluedevil manager.
Symptoms are that bluedevil sees the headset in pairing mode and
correctly retrieves the name WEP475, connected button flashes green and
then returns to grey (not connected). WEP475 led changes to connected
status but bluedevil shows headset not connected and headset does not work.
With bluetoothd in debug mode, I get the following transactions in
/var/log/messages:
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:conn_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_get_device() 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:remote_features_information() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:remote_name_information() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
audio/headset.c:headset_set_channel() Discovered Handsfree service on
channel 2
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
audio/headset.c:rfcomm_connect() /org/bluez/13226/hci0/dev_00_---_47:
Connecting to 00:---:47 channel 2
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() hci0 dba 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:get_auth_info() hci0 dba 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() kernel auth requirements = 0x04
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() Matching key found
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() link key type 0x04
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:auth_complete() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:bonding_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/event.c:btd_event_bonding_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_get_device() 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/device.c:device_bonding_complete() bonding (nil) status 0x00
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]: Permission denied (13)
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
audio/headset.c:headset_set_state() State changed
/org/bluez/13226/hci0/dev_00_---_47: HEADSET_STATE_CONNECTING ->
HEADSET_STATE_DISCONNECTED
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:disconn_complete() handle 11 status 0x00
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
src/event.c:btd_event_disconn_complete()
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_remove_connection()
I have tried clearing the contents of /var/lib/bluetooth/ forcing the
system to recreate, but no difference.
From: Johan Hedberg <hidden> Date: 2011-08-04 12:17:03
Hi Colin,
On Thu, Aug 04, 2011, Colin Beckingham wrote:
I'd like to provide some feedback regarding a Samsung WEP475 headset
which fails to connect to linux specifically.
The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR
ADAPTER v2.1 UHE which successfully interconnects with 2 Jabra and 1
Plantronics headsets, plus a Nokia E71 phone. Samsung WEP475
successfully connects to a Windows XP machine and to the Nokia E71.
Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails
with 2.6.38), bluez 4.96 and bluedevil manager.
Symptoms are that bluedevil sees the headset in pairing mode and
correctly retrieves the name WEP475, connected button flashes green
and then returns to grey (not connected). WEP475 led changes to
connected status but bluedevil shows headset not connected and
headset does not work.
With bluetoothd in debug mode, I get the following transactions in
/var/log/messages:
There seems to be something strange going on with the secure simple
pairing logic. For some reason the initial link key isn't good enough
(auth request + link key negative reply after the initial key has been
generated) and then there's a user confirm negative reply for the second
attempt. It'd be good to get to the bottom of this and fix it properly,
but meanwhile you can probably work around this by disabling SSP on your
side (hciconfig hci0 sspmode 0) and retrying pairing.
Johan
From: Colin Beckingham <hidden> Date: 2011-08-04 13:22:19
On 08/04/2011 08:17 AM, Johan Hedberg wrote:
Hi Colin,
On Thu, Aug 04, 2011, Colin Beckingham wrote:
quoted
I'd like to provide some feedback regarding a Samsung WEP475 headset
which fails to connect to linux specifically.
The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR
ADAPTER v2.1 UHE which successfully interconnects with 2 Jabra and 1
Plantronics headsets, plus a Nokia E71 phone. Samsung WEP475
successfully connects to a Windows XP machine and to the Nokia E71.
Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails
with 2.6.38), bluez 4.96 and bluedevil manager.
Symptoms are that bluedevil sees the headset in pairing mode and
correctly retrieves the name WEP475, connected button flashes green
and then returns to grey (not connected). WEP475 led changes to
connected status but bluedevil shows headset not connected and
headset does not work.
With bluetoothd in debug mode, I get the following transactions in
/var/log/messages:
There seems to be something strange going on with the secure simple
pairing logic. For some reason the initial link key isn't good enough
(auth request + link key negative reply after the initial key has been
generated) and then there's a user confirm negative reply for the second
attempt. It'd be good to get to the bottom of this and fix it properly,
but meanwhile you can probably work around this by disabling SSP on your
side (hciconfig hci0 sspmode 0) and retrying pairing.
Johan
Johan, sspmode 0 did have a positive effect. I have now been able to
pair the headset and use it in a pipe arecord to aplay context with good
results at least two times from scratch. Thanks very much.
What further feedback would be useful to developers to track down the
fundamental issue?
--
---
Colin Beckingham
From: Colin Beckingham <hidden> Date: 2011-08-06 15:33:29
Hi Peter:
On 08/06/2011 10:36 AM, Peter Hurley wrote:
On Thu, 2011-08-04 at 10:54 -0400, Peter Hurley wrote:
quoted
Hi Colin,
On Thu, 2011-08-04 at 08:17 -0400, Johan Hedberg wrote:
quoted
Hi Colin,
On Thu, Aug 04, 2011, Colin Beckingham wrote:
quoted
I'd like to provide some feedback regarding a Samsung WEP475 headset
which fails to connect to linux specifically.
The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR
ADAPTER v2.1 UHE which successfully interconnects with 2 Jabra and 1
Plantronics headsets, plus a Nokia E71 phone. Samsung WEP475
successfully connects to a Windows XP machine and to the Nokia E71.
Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails
with 2.6.38), bluez 4.96 and bluedevil manager.
Symptoms are that bluedevil sees the headset in pairing mode and
correctly retrieves the name WEP475, connected button flashes green
and then returns to grey (not connected). WEP475 led changes to
connected status but bluedevil shows headset not connected and
headset does not work.
With bluetoothd in debug mode, I get the following transactions in
/var/log/messages:
There seems to be something strange going on with the secure simple
pairing logic. For some reason the initial link key isn't good enough
(auth request + link key negative reply after the initial key has been
generated) and then there's a user confirm negative reply for the second
attempt. It'd be good to get to the bottom of this and fix it properly,
but meanwhile you can probably work around this by disabling SSP on your
side (hciconfig hci0 sspmode 0) and retrying pairing.
You're having this problem because the remote device supports SSP but
not MITM protection. Some socket is requiring BT_SECURITY_HIGH (thus
requiring MITM) -- therefore the kernel is correctly disconnecting and
returning 'Authentication Failure' (although returning 'Insufficient
Authentication' would probably be better).
I think the GATT browser is demanding BT_SECURITY_HIGH -- not sure why
though (I don't think it needs to. I'll get back to you on that...)
Colin-
Well, I was wrong about it being related to GATT. I can see some other
possibilities but I'm confused by the syslog relative to the bt capture
(eg., the syslog clearly shows a found key but the hcidump shows link
key negative reply). Were they taken at the same time?!
Regards,
Peter
PS - If you do send another hcidump, please send a binary capture (with
timestamps) as you have an old version of hcidump that doesn't decode
not-automatically-flushable l2cap packets.
I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.
I downloaded and installed the latest hcidump which identifies itself
(hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
Made another attempt to connect, here is the syslog
# tail -n 100 /var/log/messages | grep bluetoothd
Aug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got
disconnected
Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote
device can't provide MITM
Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session
0x7f801d0a6ca0 with :1.4178 activated
Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery
Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13)
and a binary hcidump is attached.
--
---
Colin Beckingham
From: Colin Beckingham <hidden> Date: 2011-08-06 17:22:46
On 08/06/2011 12:50 PM, Peter Hurley wrote:
On Sat, 2011-08-06 at 11:33 -0400, Colin Beckingham wrote:
quoted
Hi Peter:
...<snip>...
quoted
I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.
I downloaded and installed the latest hcidump which identifies itself
(hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
Made another attempt to connect, here is the syslog
# tail -n 100 /var/log/messages | grep bluetoothd
Aug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got
disconnected
Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote
device can't provide MITM
Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session
0x7f801d0a6ca0 with :1.4178 activated
Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery
Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13)
and a binary hcidump is attached.
Hi Colin,
That makes a lot more sense!
Would you please repeat the experiment with bluetoothd in debug mode,
though? That would give me a lot more information to work with about how
bluetoothd got to that point.
As before, please capture hcidump binary at the same time. Also please
include every bluetoothd syslog message starting from the start of the
experiment.
I appreciate your patience helping me to track down this bug.
Regards,
Peter Hurley
Sorry, forgot to set bluetoothd in debug mode.
Attached are my latest logs, 2 files, wep475a.*. Note in the syslog that
the first entry is timestamped way before the experiment was launched,
so the log should have everything that bluetoothd wrote for the current
experiment.
--
---
Colin Beckingham
From: Colin Beckingham <hidden> Date: 2011-08-08 13:31:28
On 08/08/2011 08:38 AM, Peter Hurley wrote:
On Sat, 2011-08-06 at 13:22 -0400, Colin Beckingham wrote:
quoted
On 08/06/2011 12:50 PM, Peter Hurley wrote:
quoted
On Sat, 2011-08-06 at 11:33 -0400, Colin Beckingham wrote:
quoted
Hi Peter:
...<snip>...
quoted
I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.
I downloaded and installed the latest hcidump which identifies itself
(hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
Made another attempt to connect, here is the syslog
# tail -n 100 /var/log/messages | grep bluetoothd
Aug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got
disconnected
Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote
device can't provide MITM
Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session
0x7f801d0a6ca0 with :1.4178 activated
Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery
Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13)
and a binary hcidump is attached.
Hi Colin,
That makes a lot more sense!
Would you please repeat the experiment with bluetoothd in debug mode,
though? That would give me a lot more information to work with about how
bluetoothd got to that point.
As before, please capture hcidump binary at the same time. Also please
include every bluetoothd syslog message starting from the start of the
experiment.
I appreciate your patience helping me to track down this bug.
Regards,
Peter Hurley
Sorry, forgot to set bluetoothd in debug mode.
Attached are my latest logs, 2 files, wep475a.*. Note in the syslog that
the first entry is timestamped way before the experiment was launched,
so the log should have everything that bluetoothd wrote for the current
experiment.
Hi Colin,
Well, the new logs did not recreate the "Rejecting request: remote
device can't provide MITM". However, they did show 2 things:
1. The host controller has a race condition bug which has been seen
before (see this thread
http://comments.gmane.org/gmane.linux.bluez.kernel/14286 for the really
technical discussion)
That's why the initial attempt by the device at connecting an RFCOMM
channel is rejected (@ 13:13:02.533713).
Nevertheless, the headset is found anyway and Bluez connects to the
headset. After establishing an insecure SDP link, Bluez attempts to open
an RFCOMM channel to the device, and
2. the kernel attempts to connect the RFCOMM channel prior to the link
being encrypted, so the device rejects the connection.
There were some last minute changes to 3.0 final that directly impacts
how this is supposed to work. However, even with those changes it's
unclear to me how #2 is happening.
Would you be willing to run the same experiment as before but with the
kernel bluetooth module enabled for debug output? If your kernel is
configured for dynamic debug (Kernel hacking/Enable dynamic printk()
support => Y), doing this is trivial:
# sudo su
# echo -n "module bluetooth +p"
> /sys/kernel/debug/dynamic_debug/control
< perform experiment>
# echo -n "module bluetooth -p"
> /sys/kernel/debug/dynamic_debug/control
Regards,
Peter Hurley
Peter, before I do this, let me just verify that my kernel is set up
right. I checked for dynamic printk and I am not clear that I have the
setting needed. Here is what my .config tells me for dynamic and printk
separately.
> cat .config | grep DYNAMIC
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_DVB_DYNAMIC_MINORS=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_DEBUG=y
> cat .config | grep PRINTK
CONFIG_PRINTK=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_PRINTK_TIME=y
# CONFIG_BOOT_PRINTK_DELAY is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
Could you confirm that I am ok to go?
--
---
Colin Beckingham
From: Colin Beckingham <hidden> Date: 2011-08-08 14:01:43
On 08/08/2011 09:53 AM, Peter Hurley wrote:
On Mon, 2011-08-08 at 09:31 -0400, Colin Beckingham wrote:
quoted
On 08/08/2011 08:38 AM, Peter Hurley wrote:
quoted
On Sat, 2011-08-06 at 13:22 -0400, Colin Beckingham wrote:
quoted
On 08/06/2011 12:50 PM, Peter Hurley wrote:
quoted
On Sat, 2011-08-06 at 11:33 -0400, Colin Beckingham wrote:
quoted
Hi Peter:
...<snip>...
quoted
I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.
I downloaded and installed the latest hcidump which identifies itself
(hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
Made another attempt to connect, here is the syslog
# tail -n 100 /var/log/messages | grep bluetoothd
Aug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got
disconnected
Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote
device can't provide MITM
Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session
0x7f801d0a6ca0 with :1.4178 activated
Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery
Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13)
and a binary hcidump is attached.
Hi Colin,
That makes a lot more sense!
Would you please repeat the experiment with bluetoothd in debug mode,
though? That would give me a lot more information to work with about how
bluetoothd got to that point.
As before, please capture hcidump binary at the same time. Also please
include every bluetoothd syslog message starting from the start of the
experiment.
I appreciate your patience helping me to track down this bug.
Regards,
Peter Hurley
Sorry, forgot to set bluetoothd in debug mode.
Attached are my latest logs, 2 files, wep475a.*. Note in the syslog that
the first entry is timestamped way before the experiment was launched,
so the log should have everything that bluetoothd wrote for the current
experiment.
Hi Colin,
Well, the new logs did not recreate the "Rejecting request: remote
device can't provide MITM". However, they did show 2 things:
1. The host controller has a race condition bug which has been seen
before (see this thread
http://comments.gmane.org/gmane.linux.bluez.kernel/14286 for the really
technical discussion)
That's why the initial attempt by the device at connecting an RFCOMM
channel is rejected (@ 13:13:02.533713).
Nevertheless, the headset is found anyway and Bluez connects to the
headset. After establishing an insecure SDP link, Bluez attempts to open
an RFCOMM channel to the device, and
2. the kernel attempts to connect the RFCOMM channel prior to the link
being encrypted, so the device rejects the connection.
There were some last minute changes to 3.0 final that directly impacts
how this is supposed to work. However, even with those changes it's
unclear to me how #2 is happening.
Would you be willing to run the same experiment as before but with the
kernel bluetooth module enabled for debug output? If your kernel is
configured for dynamic debug (Kernel hacking/Enable dynamic printk()
support => Y), doing this is trivial:
# sudo su
# echo -n "module bluetooth +p"
> /sys/kernel/debug/dynamic_debug/control
< perform experiment>
# echo -n "module bluetooth -p"
> /sys/kernel/debug/dynamic_debug/control
Regards,
Peter Hurley
Peter, before I do this, let me just verify that my kernel is set up
right. I checked for dynamic printk and I am not clear that I have the
setting needed. Here is what my .config tells me for dynamic and printk
separately.
> cat .config | grep DYNAMIC
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_DVB_DYNAMIC_MINORS=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_DEBUG=y
^^^^^^^^
This is the one and it's set correctly.
quoted
> cat .config | grep PRINTK
CONFIG_PRINTK=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_PRINTK_TIME=y
# CONFIG_BOOT_PRINTK_DELAY is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
Could you confirm that I am ok to go?
BTW, I just figured out how the kernel does the wrong thing now. If you
want to wait on running this experiment, that's fine with me. I can
contact you if someone wants proof that this happens.
~Peter
OK, Peter, I will put a hold on this. Let me know if you need further input.
--
---
Colin Beckingham