2003-11-05 11:06:20

by Andreas Sundstrom

[permalink] [raw]
Subject: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi, I have a Toshiba Laptop with a Bluetooth USB device integrated in it.
I can use the BT device without problems in 2.4.22, but with 2.6.0-test9=20
it doesn't work for most of the time.

USB seems to be working just fine so that shouldn't be it.

The problem is that most of the time a "hcitool inq/scan" just returns
"Inquiring ..." immediatly, without any delay like it didn't do anything.

If I remove the modules and reload them over and over again it usually=20
works after a while and when it works it stays working until I decide to=20
reboot.

I've tried to enable some debugging in hci_usb.c but I don't understand
what to make out of it.. not much that seems wrong to me..

I get one error when loading the hci_usb module though:
hub 4-0:1.0: new USB device on port 1, assigned address 2
hci_usb: probe of 4-1:1.1 failed with error -5

Don't know if it's related, the device seems fine and this showes up
even when the device happen to work.

Just let me know if there is something I can provide/test debug or=20
whatever..

This is my BT device:
T: Bus=3D04 Lev=3D01 Prnt=3D01 Port=3D00 Cnt=3D01 Dev#=3D 2 Spd=3D12 M=
xCh=3D 0
D: Ver=3D 1.10 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1
P: Vendor=3D0930 ProdID=3D0502 Rev=3D 0.00
S: Manufacturer=3DSiW
S: Product=3DSiW
S: SerialNumber=3D9113087A0300
C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3Da0 MxPwr=3D200mA
I: If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver=
=3Dhci_usb
E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms
E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms
E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms
I: If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver=
=3D(none)
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms
I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver=
=3D(none)
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms
I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver=
=3D(none)
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms
I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver=
=3D(none)
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms
I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver=
=3D(none)
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms
I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver=
=3D(none)
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms

Thanks
/Andreas Sundstr=F6m



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users


2003-11-08 09:53:23

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Marcel Holtmann wrote:
> Hi Andreas,
>
>
>>>Please test this. If the Microsoft is working all the time then your
>>>problem is part of the Silicon Wave chip or some else in the internal
>>>USB stuff of your notebook. However it works in 2.4 this must be some
>>>kind of problem in the Linux USB subsystem which only effects this kind
>>>of device.
>>
>>I just rebooted to check and it actually had the same problem as the
>>internal device. Now I'm starting to guess it maybe is USB that is the
>>problem, what is your opinion(s) ?
>
>
> please check this some more times and then report it to the USB mailing
> list. Some of them should know what is changed in 2.6. Do you have a
> desktop PC running 2.6 to verify that it is your notebook that is some
> kind of buggy?
Well I have now verified the same problem with the MS dongle on one of my
desktop computers (ASUS A7V333 mb), I tested with 2.6.0-test9-bk12.

Do you think it's time to try and report this to the USB people or what?

I get this type of error on both the notebook and desktop computer:
Nov 8 10:46:56 sunkan kernel: hci_usb: probe of 4-1.1:1.1 failed with error -5

/Andreas



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-07 18:50:02

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

--- tmp/linux-2.6.0-test9-stock/drivers/acpi/toshiba_acpi.c 2003-10-25 20:42:52.000000000 +0200
+++ linux-2.6.0-test9/drivers/acpi/toshiba_acpi.c 2003-11-07 19:37:38.000000000 +0100
@@ -81,6 +81,7 @@
#define HCI_VIDEO_OUT 0x001c
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
+#define HCI_BLUETOOTH 0x0056

/* field definitions */
#define HCI_LCD_BRIGHTNESS_BITS 3
@@ -89,6 +90,9 @@
#define HCI_VIDEO_OUT_LCD 0x1
#define HCI_VIDEO_OUT_CRT 0x2
#define HCI_VIDEO_OUT_TV 0x4
+#define HCI_BLUETOOTH_ACTIVATE 0x0080
+#define HCI_BLUETOOTH_ATTACH 0x0040
+#define HCI_BLUETOOTH_DX 0x0001

/* utility
*/
@@ -195,9 +199,9 @@
*/

static acpi_status
-hci_write1(u32 reg, u32 in1, u32* result)
+hci_write1(u32 reg, u32 in1, u32 in2, u32* result)
{
- u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
+ u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(in, out);
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
@@ -205,9 +209,9 @@
}

static acpi_status
-hci_read1(u32 reg, u32* out1, u32* result)
+hci_read1(u32 reg, u32* out1, u32 in2, u32* result)
{
- u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
+ u32 in[HCI_WORDS] = { HCI_GET, reg, 0, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(in, out);
*out1 = out[2];
@@ -263,7 +267,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result);
+ hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
value = value >> HCI_LCD_BRIGHTNESS_SHIFT;
p += sprintf(p, "brightness: %d\n", value);
@@ -285,7 +289,7 @@
if (snscanf(buffer, count, " brightness : %i", &value) == 1 &&
value >= 0 && value < HCI_LCD_BRIGHTNESS_LEVELS) {
value = value << HCI_LCD_BRIGHTNESS_SHIFT;
- hci_write1(HCI_LCD_BRIGHTNESS, value, &hci_result);
+ hci_write1(HCI_LCD_BRIGHTNESS, value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -EFAULT;
} else {
@@ -301,7 +305,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_VIDEO_OUT, &value, &hci_result);
+ hci_read1(HCI_VIDEO_OUT, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0;
int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0;
@@ -340,7 +344,7 @@
while ((buffer < buffer_end) && (*(buffer-1) != ';'));
} while (buffer < buffer_end);

- hci_read1(HCI_VIDEO_OUT, &video_out, &hci_result);
+ hci_read1(HCI_VIDEO_OUT, &video_out, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
int new_video_out = video_out;
if (lcd_out != -1)
@@ -364,7 +368,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_FAN, &value, &hci_result);
+ hci_read1(HCI_FAN, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
p += sprintf(p, "running: %d\n", (value > 0));
p += sprintf(p, "force_on: %d\n", force_fan);
@@ -383,7 +387,7 @@

if (snscanf(buffer, count, " force_on : %i", &value) == 1 &&
value >= 0 && value <= 1) {
- hci_write1(HCI_FAN, value, &hci_result);
+ hci_write1(HCI_FAN, value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -EFAULT;
else
@@ -402,7 +406,7 @@
u32 value;

if (!key_event_valid) {
- hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result);
+ hci_read1(HCI_SYSTEM_EVENT, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
key_event_valid = 1;
last_key_event = value;
@@ -412,7 +416,7 @@
/* This is a workaround for an unresolved issue on
* some machines where system events sporadically
* become disabled. */
- hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result);
+ hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result);
} else {
p += sprintf(p, "ERROR\n");
goto end;
@@ -450,6 +454,60 @@
return p;
}

+static char*
+read_bluetooth(char *p)
+{
+ u32 hci_result;
+ u32 value;
+
+ hci_read1(HCI_BLUETOOTH, &value, 0, &hci_result);
+ if (hci_result == HCI_SUCCESS) {
+ p += sprintf(p, "bluetooth_available: %d\n", value);
+ } else {
+ p += sprintf(p, "ERROR\n");
+ goto end;
+ }
+
+ hci_read1(HCI_BLUETOOTH, &value, HCI_BLUETOOTH_DX, &hci_result);
+ if (hci_result == HCI_SUCCESS) {
+ int is_switch = (value & HCI_BLUETOOTH_DX) ? 1 : 0;
+ int is_btooth = (value & HCI_BLUETOOTH_ACTIVATE) ? 1 : 0;
+ p += sprintf(p, "wireless_switch: %d\n", is_switch);
+ p += sprintf(p, "bluetooth_on: %d\n", is_btooth);
+ } else {
+ p += sprintf(p, "ERROR\n");
+ }
+
+end:
+ return p;
+}
+
+static unsigned long
+write_bluetooth(const char* buffer, unsigned long count)
+{
+ int value;
+ u32 hci_result;
+
+ if (snscanf(buffer, count, " bluetooth_on : %i", &value) == 1 &&
+ value >= 0 && value <= 1) {
+ hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ACTIVATE, &hci_result);
+ if (hci_result != HCI_SUCCESS)
+ return -EFAULT;
+
+ hci_write1(0, 0, 0, &hci_result);
+
+ hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ATTACH, &hci_result);
+ if (hci_result != HCI_SUCCESS);
+ return -EFAULT;
+
+ hci_write1(0, 0, 0, &hci_result);
+ } else {
+ return -EINVAL;
+ }
+
+ return count;
+}
+
/* proc and module init
*/

@@ -457,12 +515,13 @@

ProcItem proc_items[] =
{
- { "lcd" , read_lcd , write_lcd },
- { "video" , read_video , write_video },
- { "fan" , read_fan , write_fan },
- { "keys" , read_keys , write_keys },
- { "version" , read_version , 0 },
- { 0 , 0 , 0 },
+ { "lcd", read_lcd, write_lcd },
+ { "video", read_video, write_video },
+ { "fan", read_fan, write_fan },
+ { "keys", read_keys, write_keys },
+ { "version", read_version, 0 },
+ { "bluetooth", read_bluetooth, write_bluetooth },
+ { 0, 0, 0 },
};

static acpi_status
@@ -501,7 +560,7 @@
u32 hci_result;

/* simple device detection: try reading an HCI register */
- hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result);
+ hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -ENODEV;

@@ -511,7 +570,7 @@
key_event_valid = 0;

/* enable event fifo */
- hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result);
+ hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result);

toshiba_proc_dir = proc_mkdir(PROC_TOSHIBA, acpi_root_dir);
if (!toshiba_proc_dir) {


Attachments:
patch-2.6.0-test9-toshiba-acpi-bt-2-stock.patch (6.07 kB)

2003-11-07 15:27:26

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

--- tmp/linux-2.6.0-test9-stock/drivers/acpi/toshiba_acpi.c 2003-10-25 20:42:52.000000000 +0200
+++ linux-2.6.0-test9/drivers/acpi/toshiba_acpi.c 2003-11-07 16:21:39.174442800 +0100
@@ -81,6 +81,7 @@
#define HCI_VIDEO_OUT 0x001c
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
+#define HCI_BLUETOOTH 0x0056

/* field definitions */
#define HCI_LCD_BRIGHTNESS_BITS 3
@@ -89,6 +90,9 @@
#define HCI_VIDEO_OUT_LCD 0x1
#define HCI_VIDEO_OUT_CRT 0x2
#define HCI_VIDEO_OUT_TV 0x4
+#define HCI_BLUETOOTH_ACTIVATE 0x0080
+#define HCI_BLUETOOTH_ATTACH 0x0040
+#define HCI_BLUETOOTH_DX 0x0001

/* utility
*/
@@ -195,9 +199,9 @@
*/

static acpi_status
-hci_write1(u32 reg, u32 in1, u32* result)
+hci_write1(u32 reg, u32 in1, u32 in2, u32* result)
{
- u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
+ u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(in, out);
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
@@ -205,9 +209,9 @@
}

static acpi_status
-hci_read1(u32 reg, u32* out1, u32* result)
+hci_read1(u32 reg, u32* out1, u32 in2, u32* result)
{
- u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
+ u32 in[HCI_WORDS] = { HCI_GET, reg, 0, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(in, out);
*out1 = out[2];
@@ -263,7 +267,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result);
+ hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
value = value >> HCI_LCD_BRIGHTNESS_SHIFT;
p += sprintf(p, "brightness: %d\n", value);
@@ -285,7 +289,7 @@
if (snscanf(buffer, count, " brightness : %i", &value) == 1 &&
value >= 0 && value < HCI_LCD_BRIGHTNESS_LEVELS) {
value = value << HCI_LCD_BRIGHTNESS_SHIFT;
- hci_write1(HCI_LCD_BRIGHTNESS, value, &hci_result);
+ hci_write1(HCI_LCD_BRIGHTNESS, value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -EFAULT;
} else {
@@ -301,7 +305,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_VIDEO_OUT, &value, &hci_result);
+ hci_read1(HCI_VIDEO_OUT, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0;
int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0;
@@ -340,7 +344,7 @@
while ((buffer < buffer_end) && (*(buffer-1) != ';'));
} while (buffer < buffer_end);

- hci_read1(HCI_VIDEO_OUT, &video_out, &hci_result);
+ hci_read1(HCI_VIDEO_OUT, &video_out, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
int new_video_out = video_out;
if (lcd_out != -1)
@@ -364,7 +368,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_FAN, &value, &hci_result);
+ hci_read1(HCI_FAN, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
p += sprintf(p, "running: %d\n", (value > 0));
p += sprintf(p, "force_on: %d\n", force_fan);
@@ -383,7 +387,7 @@

if (snscanf(buffer, count, " force_on : %i", &value) == 1 &&
value >= 0 && value <= 1) {
- hci_write1(HCI_FAN, value, &hci_result);
+ hci_write1(HCI_FAN, value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -EFAULT;
else
@@ -402,7 +406,7 @@
u32 value;

if (!key_event_valid) {
- hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result);
+ hci_read1(HCI_SYSTEM_EVENT, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
key_event_valid = 1;
last_key_event = value;
@@ -412,7 +416,7 @@
/* This is a workaround for an unresolved issue on
* some machines where system events sporadically
* become disabled. */
- hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result);
+ hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result);
} else {
p += sprintf(p, "ERROR\n");
goto end;
@@ -450,6 +454,58 @@
return p;
}

+static char*
+read_bluetooth(char *p)
+{
+ u32 hci_result;
+ u32 value;
+
+ hci_read1(HCI_BLUETOOTH, &value, 0, &hci_result);
+ if (hci_result == HCI_SUCCESS) {
+ p += sprintf(p, "bluetooth_available: %d\n", value);
+ } else {
+ p += sprintf(p, "ERROR\n");
+ goto end;
+ }
+
+ hci_read1(HCI_BLUETOOTH, &value, HCI_BLUETOOTH_DX, &hci_result);
+ if (hci_result == HCI_SUCCESS) {
+ p += sprintf(p, "wireless_switch: %d\n", value & 1);
+ p += sprintf(p, "bluetooth_on: %d\n", (value & 128) == 128);
+ } else {
+ p += sprintf(p, "ERROR\n");
+ }
+
+end:
+ return p;
+}
+
+static unsigned long
+write_bluetooth(const char* buffer, unsigned long count)
+{
+ int value;
+ u32 hci_result;
+
+ if (snscanf(buffer, count, " bluetooth_on : %i", &value) == 1 &&
+ value >= 0 && value <= 1) {
+ hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ACTIVATE, &hci_result);
+ if (hci_result != HCI_SUCCESS)
+ return -EFAULT;
+
+ hci_write1(0, 0, 0, &hci_result);
+
+ hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ATTACH, &hci_result);
+ if (hci_result != HCI_SUCCESS);
+ return -EFAULT;
+
+ hci_write1(0, 0, 0, &hci_result);
+ } else {
+ return -EINVAL;
+ }
+
+ return count;
+}
+
/* proc and module init
*/

@@ -457,12 +513,13 @@

ProcItem proc_items[] =
{
- { "lcd" , read_lcd , write_lcd },
- { "video" , read_video , write_video },
- { "fan" , read_fan , write_fan },
- { "keys" , read_keys , write_keys },
- { "version" , read_version , 0 },
- { 0 , 0 , 0 },
+ { "lcd", read_lcd, write_lcd },
+ { "video", read_video, write_video },
+ { "fan", read_fan, write_fan },
+ { "keys", read_keys, write_keys },
+ { "version", read_version, 0 },
+ { "bluetooth", read_bluetooth, write_bluetooth },
+ { 0, 0, 0 },
};

static acpi_status
@@ -501,7 +558,7 @@
u32 hci_result;

/* simple device detection: try reading an HCI register */
- hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result);
+ hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -ENODEV;

@@ -511,7 +568,7 @@
key_event_valid = 0;

/* enable event fifo */
- hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result);
+ hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result);

toshiba_proc_dir = proc_mkdir(PROC_TOSHIBA, acpi_root_dir);
if (!toshiba_proc_dir) {


Attachments:
patch-2.6.0-test9-toshiba-acpi-bt-stock.patch (5.97 kB)

2003-11-07 13:22:10

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Marcel Holtmann wrote:
> Hi Andreas,
>
>
>>This is when I have successfully enabled bluetooth and USB has noticed
>>that the dongle has been plugged in.
>>
>>root@swe248:/proc/acpi/toshiba# cat bluetooth
>>bluetooth_available: 15
>>wireless_switch: 705
>>bluetooth_on: 1
>>
>>By accident I noticed that when I changed the switched from Off to On it
>>went up to 577 so I that is now the highest number I've seen without the
>>bluetooth dongle actually working.
>
>
> don't think of highest number. You should start thinking in which bit is
> set and which is not. It seems that the bluetooth_available register
> will always be 15 and can be ignored at this point. The important part
> is the value of wireless_switch.
>
> It seems that we have some variables to fill in.
>
> The hardware switch on/off
> Bluetooth activated/deactivated through software
> Bluetooth dongle found/disabled by USB subsystem
>
> So you should make a table with all possible combinations and fill in
> the values (in hex) for it. This is what I need to see which bit gets
> toggled and which not.

Now I've done some testing, and with hex numbers it seems to clarify a bit.

When the notebook is freshly booted I get the following values:
sw-off: 0x200
sw-on: 0x201

After I have sent a bluetooth_on:1 the values changes to:
sw-off: 0x240
sw-on: 0x241

When the switch is on and bluetooth is enabled (plugged in):
sw-on bt-on: 0x2c1

If I then move the switch back to off it goes back to 0x240

This is essentially the same numbers as earlier but in hex form, but it
seems to me that the first bit is responsible for reporting if the
switch is on or off. If I convert it to binary I get the following:

sw-off bt-off
1000000000
1001000000

sw-on bt-off
1000000001
1001000001

sw-on bt-on
1011000001

I'm not sure if I answered all your (three) questions, if not.. please
explain a bit further beacause then I didn't understand it.

/Andreas



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-07 12:12:14

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi Andreas,

> This is when I have successfully enabled bluetooth and USB has noticed
> that the dongle has been plugged in.
>
> root@swe248:/proc/acpi/toshiba# cat bluetooth
> bluetooth_available: 15
> wireless_switch: 705
> bluetooth_on: 1
>
> By accident I noticed that when I changed the switched from Off to On it
> went up to 577 so I that is now the highest number I've seen without the
> bluetooth dongle actually working.

don't think of highest number. You should start thinking in which bit is
set and which is not. It seems that the bluetooth_available register
will always be 15 and can be ignored at this point. The important part
is the value of wireless_switch.

It seems that we have some variables to fill in.

The hardware switch on/off
Bluetooth activated/deactivated through software
Bluetooth dongle found/disabled by USB subsystem

So you should make a table with all possible combinations and fill in
the values (in hex) for it. This is what I need to see which bit gets
toggled and which not.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-07 12:00:35

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Marcel Holtmann wrote:
> Hi Andreas,
>
>
>>It looks like this with my changes from my last mail apllied.
>>This is done with the switch on the notebook in the "Off" position.
>
>
> and how do it look with the switch in "On" position?
This is when I have successfully enabled bluetooth and USB has noticed
that the dongle has been plugged in.

root@swe248:/proc/acpi/toshiba# cat bluetooth
bluetooth_available: 15
wireless_switch: 705
bluetooth_on: 1

By accident I noticed that when I changed the switched from Off to On it
went up to 577 so I that is now the highest number I've seen without the
bluetooth dongle actually working.

Since I'm not used to "research" these kind of things I might not be
doing it the most efficient way, if you suggest that I shall try things
in a specific order and document it I can do it for you..

>
>>I'm afraid I don't have a 802.b module in my computer, it's an option
>>and currently I'm using BT as a cheap alternative :)
>>
>>Maybe someonelse on the list have access to a Toshiba with wlan card in it?
>
>
> I really need this information :(
I hope that someone will notice this thread and fill in the blanks for
this.. The topic/subject is not the best though..

/Andreas



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-07 11:41:18

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi Andreas,

> It looks like this with my changes from my last mail apllied.
> This is done with the switch on the notebook in the "Off" position.

and how do it look with the switch in "On" position?

> I'm afraid I don't have a 802.b module in my computer, it's an option
> and currently I'm using BT as a cheap alternative :)
>
> Maybe someonelse on the list have access to a Toshiba with wlan card in it?

I really need this information :(

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-07 11:34:10

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Marcel Holtmann wrote:
> The problem here are the information about these values. Try to play a
> little bit with the switch on your notebook and get the values of the
> wireless_switch and bluetooth_available registers for Bluetooth on/off
> and Wirless LAN on/off.
>
> Maybe this register could also be used to switch the Wireless LAN card
> on/off and so I tend to rename the complete proc entry to wireless and
> redo some parts of the patch.

I played with it in all possible ways on my notebook and the highest
value I saw without bluetooth getting enabled was 576, and that was when
I tried to enable bluetooth without first flipping the switch on the
side of the notebook.

It looks like this with my changes from my last mail apllied.
This is done with the switch on the notebook in the "Off" position.

root@swe248:/proc/acpi/toshiba# cat bluetooth ; echo "bluetooth_on:1" >
bluetooth ; cat bluetooth

bluetooth_available: 15
wireless_switch: 512
bluetooth_on: 0
bluetooth_available: 15
wireless_switch: 576
bluetooth_on: 0

I'm afraid I don't have a 802.b module in my computer, it's an option
and currently I'm using BT as a cheap alternative :)

Maybe someonelse on the list have access to a Toshiba with wlan card in it?

/Andreas



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-07 11:25:14

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi Andreas,

> Ok, first of all I want to say that it works ok for me. I have tried
> everything except the "keys" proc entry.

this is good to hear, so I don't break anything else ;)

> Which means that when you have learnd how they function you should be
> able to guess what to do with the bluetooth entry if it for example
> looked like this:
> #cat bluetooth
> bluetooth_available: 15
> wireless_switch: 512
> bluetooth_on: 0
>
> I have here changed the parameter to echo into "bluetooth" from
> bluetooth to bluetooth_on, and added an entry that shows the status of
> it. This makes it easy to guess that "echo bluetooth_on:1 > bluetooth"
> should enable the device if you know how the other entris work.
> Without this you want be able to guess that "bluetooth:1/0" is used
> for enabling/disabling the device.

The problem here are the information about these values. Try to play a
little bit with the switch on your notebook and get the values of the
wireless_switch and bluetooth_available registers for Bluetooth on/off
and Wirless LAN on/off.

Maybe this register could also be used to switch the Wireless LAN card
on/off and so I tend to rename the complete proc entry to wireless and
redo some parts of the patch.

Regards

Marcel





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-07 10:04:08

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

--- tmp/linux-2.6.0-test9-stock/drivers/acpi/toshiba_acpi.c 2003-10-25 20:42:52.000000000 +0200
+++ linux-2.6.0-test9/drivers/acpi/toshiba_acpi.c 2003-11-07 10:07:39.629578024 +0100
@@ -81,6 +81,7 @@
#define HCI_VIDEO_OUT 0x001c
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
+#define HCI_BLUETOOTH 0x0056

/* field definitions */
#define HCI_LCD_BRIGHTNESS_BITS 3
@@ -89,6 +90,9 @@
#define HCI_VIDEO_OUT_LCD 0x1
#define HCI_VIDEO_OUT_CRT 0x2
#define HCI_VIDEO_OUT_TV 0x4
+#define HCI_BLUETOOTH_ACTIVATE 0x0080
+#define HCI_BLUETOOTH_ATTACH 0x0040
+#define HCI_BLUETOOTH_DX 0x0001

/* utility
*/
@@ -195,9 +199,9 @@
*/

static acpi_status
-hci_write1(u32 reg, u32 in1, u32* result)
+hci_write1(u32 reg, u32 in1, u32 in2, u32* result)
{
- u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
+ u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(in, out);
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
@@ -205,9 +209,9 @@
}

static acpi_status
-hci_read1(u32 reg, u32* out1, u32* result)
+hci_read1(u32 reg, u32* out1, u32 in2, u32* result)
{
- u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
+ u32 in[HCI_WORDS] = { HCI_GET, reg, 0, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(in, out);
*out1 = out[2];
@@ -263,7 +267,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result);
+ hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
value = value >> HCI_LCD_BRIGHTNESS_SHIFT;
p += sprintf(p, "brightness: %d\n", value);
@@ -285,7 +289,7 @@
if (snscanf(buffer, count, " brightness : %i", &value) == 1 &&
value >= 0 && value < HCI_LCD_BRIGHTNESS_LEVELS) {
value = value << HCI_LCD_BRIGHTNESS_SHIFT;
- hci_write1(HCI_LCD_BRIGHTNESS, value, &hci_result);
+ hci_write1(HCI_LCD_BRIGHTNESS, value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -EFAULT;
} else {
@@ -301,7 +305,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_VIDEO_OUT, &value, &hci_result);
+ hci_read1(HCI_VIDEO_OUT, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0;
int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0;
@@ -340,7 +344,7 @@
while ((buffer < buffer_end) && (*(buffer-1) != ';'));
} while (buffer < buffer_end);

- hci_read1(HCI_VIDEO_OUT, &video_out, &hci_result);
+ hci_read1(HCI_VIDEO_OUT, &video_out, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
int new_video_out = video_out;
if (lcd_out != -1)
@@ -364,7 +368,7 @@
u32 hci_result;
u32 value;

- hci_read1(HCI_FAN, &value, &hci_result);
+ hci_read1(HCI_FAN, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
p += sprintf(p, "running: %d\n", (value > 0));
p += sprintf(p, "force_on: %d\n", force_fan);
@@ -383,7 +387,7 @@

if (snscanf(buffer, count, " force_on : %i", &value) == 1 &&
value >= 0 && value <= 1) {
- hci_write1(HCI_FAN, value, &hci_result);
+ hci_write1(HCI_FAN, value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -EFAULT;
else
@@ -402,7 +406,7 @@
u32 value;

if (!key_event_valid) {
- hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result);
+ hci_read1(HCI_SYSTEM_EVENT, &value, 0, &hci_result);
if (hci_result == HCI_SUCCESS) {
key_event_valid = 1;
last_key_event = value;
@@ -412,7 +416,7 @@
/* This is a workaround for an unresolved issue on
* some machines where system events sporadically
* become disabled. */
- hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result);
+ hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result);
} else {
p += sprintf(p, "ERROR\n");
goto end;
@@ -450,6 +454,61 @@
return p;
}

+static char*
+read_bluetooth(char *p)
+{
+ u32 hci_result;
+ u32 value;
+
+ hci_read1(HCI_BLUETOOTH, &value, 0, &hci_result);
+ if (hci_result == HCI_SUCCESS) {
+ p += sprintf(p, "bluetooth_available: %d\n", value);
+ } else {
+ p += sprintf(p, "ERROR\n");
+ goto end;
+ }
+
+ hci_read1(HCI_BLUETOOTH, &value, HCI_BLUETOOTH_DX, &hci_result);
+ if (hci_result == HCI_SUCCESS && value > 576) {
+ p += sprintf(p, "wireless_switch: %d\n", value);
+ p += sprintf(p, "bluetooth_on: 1\n");
+ } else if (hci_result == HCI_SUCCESS) {
+ p += sprintf(p, "wireless_switch: %d\n", value);
+ p += sprintf(p, "bluetooth_on: 0\n");
+ } else {
+ p += sprintf(p, "ERROR\n");
+ }
+
+end:
+ return p;
+}
+
+static unsigned long
+write_bluetooth(const char* buffer, unsigned long count)
+{
+ int value;
+ u32 hci_result;
+
+ if (snscanf(buffer, count, " bluetooth_on : %i", &value) == 1 &&
+ value >= 0 && value <= 1) {
+ hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ACTIVATE, &hci_result);
+ if (hci_result != HCI_SUCCESS)
+ return -EFAULT;
+
+ hci_write1(0, 0, 0, &hci_result);
+
+ hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ATTACH, &hci_result);
+ if (hci_result != HCI_SUCCESS);
+ return -EFAULT;
+
+ hci_write1(0, 0, 0, &hci_result);
+ } else {
+ return -EINVAL;
+ }
+
+ return count;
+}
+
/* proc and module init
*/

@@ -457,12 +516,13 @@

ProcItem proc_items[] =
{
- { "lcd" , read_lcd , write_lcd },
- { "video" , read_video , write_video },
- { "fan" , read_fan , write_fan },
- { "keys" , read_keys , write_keys },
- { "version" , read_version , 0 },
- { 0 , 0 , 0 },
+ { "lcd", read_lcd, write_lcd },
+ { "video", read_video, write_video },
+ { "fan", read_fan, write_fan },
+ { "keys", read_keys, write_keys },
+ { "version", read_version, 0 },
+ { "bluetooth", read_bluetooth, write_bluetooth },
+ { 0, 0, 0 },
};

static acpi_status
@@ -501,7 +561,7 @@
u32 hci_result;

/* simple device detection: try reading an HCI register */
- hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result);
+ hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result);
if (hci_result != HCI_SUCCESS)
return -ENODEV;

@@ -511,7 +571,7 @@
key_event_valid = 0;

/* enable event fifo */
- hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result);
+ hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result);

toshiba_proc_dir = proc_mkdir(PROC_TOSHIBA, acpi_root_dir);
if (!toshiba_proc_dir) {


Attachments:
patch-2.6.0-test9-toshiba-acpi-bt-mh.patch (994.00 B)
patch-2.6.0-test9-toshiba-acpi-bt-stock.patch (6.11 kB)
Download all attachments

2003-11-06 23:48:34

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi Andreas,

> > this should be included in the mainstream kernel source, but the code
> > must be a little bit cleaned up. I will check this later and send you a
> > patch for testing. After that I'll forward it to the maintainer.
> >
> I'll appreciate that, just let me know when you have gone over it and
> I'll check that it works as expected.

here is my patch for it. I changed some stuff and left some stupid
things out. It is now switched on/off with "bluetooth:1"/"bluetooth:0"
and please check that I don't break the other stuff like fan or screen
brightness.

Regards

Marcel


Attachments:
patch-toshiba-acpi-bluetooth (5.89 kB)

2003-11-05 14:33:02

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes



Marcel Holtmann wrote:
> Hi Andreas,
>
>
>>>>This is what I'v run:
>>>>
>>>>//inserts the device into the USB hub
>>>># echo blue_on:1 > /proc/acpi/toshiba/bluetooth
>>>
>>>
>>>Where is this documented?
>>
>>Apparently many notebooks (atleast many toshiba's) have devices that can
>>be plugged in and out via software. The USB BT dongle in my notebook is
>>one of these.. There's a button on the side of the notebook that can be
>>used to be sure that the device is off (like in an airplane).
>>I found a patch for linux/driver/acpi/toshiba_acpi.c on this site:
>>
>>http://nicolas.bettenburg.free.fr/linux/#c4
>>
>>I hade to fiddle alot with it to make it work with 2.4.22 (I guess he
>>has not written it against a recent kernel). I came up with a patch that
>>worked ok with 2.4.22, and to my surprice it worked fine with 2.6.0 too.
>>
>>My guess is that the ACPI stuff has been backported into 2.4.22 and
>>that's why it's almost the same.. I put the patch I use here so you can
>>look if you want: ftp://zappa.cx/pub/echinacea/toshiba_bluetooth.patch
>>It currently doesn't apply cleanly on 2.6.0-test9 but not important
>>stuff just comments doesn't apply.
>
>
> this should be included in the mainstream kernel source, but the code
> must be a little bit cleaned up. I will check this later and send you a
> patch for testing. After that I'll forward it to the maintainer.
>
I'll appreciate that, just let me know when you have gone over it and
I'll check that it works as expected.

> Regards
>
> Marcel
>



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-05 14:31:33

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Marcel Holtmann wrote:
> Hi Andreas,
>
>
>>>Please test this. If the Microsoft is working all the time then your
>>>problem is part of the Silicon Wave chip or some else in the internal
>>>USB stuff of your notebook. However it works in 2.4 this must be some
>>>kind of problem in the Linux USB subsystem which only effects this kind
>>>of device.
>>
>>I just rebooted to check and it actually had the same problem as the
>>internal device. Now I'm starting to guess it maybe is USB that is the
>>problem, what is your opinion(s) ?
>
>
> please check this some more times and then report it to the USB mailing
> list. Some of them should know what is changed in 2.6. Do you have a
> desktop PC running 2.6 to verify that it is your notebook that is some
> kind of buggy?

Will do..

>
> Regards
>
> Marcel
>



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-05 14:15:09

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi Andreas,

> >>This is what I'v run:
> >>
> >>//inserts the device into the USB hub
> >># echo blue_on:1 > /proc/acpi/toshiba/bluetooth
> >
> >
> > Where is this documented?
> Apparently many notebooks (atleast many toshiba's) have devices that can
> be plugged in and out via software. The USB BT dongle in my notebook is
> one of these.. There's a button on the side of the notebook that can be
> used to be sure that the device is off (like in an airplane).
> I found a patch for linux/driver/acpi/toshiba_acpi.c on this site:
>
> http://nicolas.bettenburg.free.fr/linux/#c4
>
> I hade to fiddle alot with it to make it work with 2.4.22 (I guess he
> has not written it against a recent kernel). I came up with a patch that
> worked ok with 2.4.22, and to my surprice it worked fine with 2.6.0 too.
>
> My guess is that the ACPI stuff has been backported into 2.4.22 and
> that's why it's almost the same.. I put the patch I use here so you can
> look if you want: ftp://zappa.cx/pub/echinacea/toshiba_bluetooth.patch
> It currently doesn't apply cleanly on 2.6.0-test9 but not important
> stuff just comments doesn't apply.

this should be included in the mainstream kernel source, but the code
must be a little bit cleaned up. I will check this later and send you a
patch for testing. After that I'll forward it to the maintainer.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-05 14:03:47

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi Andreas,

> > Please test this. If the Microsoft is working all the time then your
> > problem is part of the Silicon Wave chip or some else in the internal
> > USB stuff of your notebook. However it works in 2.4 this must be some
> > kind of problem in the Linux USB subsystem which only effects this kind
> > of device.
> I just rebooted to check and it actually had the same problem as the
> internal device. Now I'm starting to guess it maybe is USB that is the
> problem, what is your opinion(s) ?

please check this some more times and then report it to the USB mailing
list. Some of them should know what is changed in 2.6. Do you have a
desktop PC running 2.6 to verify that it is your notebook that is some
kind of buggy?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-05 13:49:02

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Marcel Holtmann wrote:
>>>This is a question for the USB guys. Do you have another USB Bluetooth
>>>dongle to test with your notebook?
>>
>>I inserted a MS Wireless Transceiver for Bluetooth and it gave the same
>>error.. but seems to work alright. Havn't done much testing yet though.
>
>
> Please test this. If the Microsoft is working all the time then your
> problem is part of the Silicon Wave chip or some else in the internal
> USB stuff of your notebook. However it works in 2.4 this must be some
> kind of problem in the Linux USB subsystem which only effects this kind
> of device.
I just rebooted to check and it actually had the same problem as the
internal device. Now I'm starting to guess it maybe is USB that is the
problem, what is your opinion(s) ?

/Andreas

2003-11-05 12:54:25

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Marcel Holtmann wrote:
> and what is the model of your notebook?
Toshiba Satellite S5200-801

>>I inserted a MS Wireless Transceiver for Bluetooth and it gave the same
>>error.. but seems to work alright. Havn't done much testing yet though.
>
>
> Please test this. If the Microsoft is working all the time then your
> problem is part of the Silicon Wave chip or some else in the internal
> USB stuff of your notebook. However it works in 2.4 this must be some
> kind of problem in the Linux USB subsystem which only effects this kind
> of device.
I will do some testing of this and report back if it works all the time
or if it has the same intermittend problems as my internal USB device.

>>This is what I'v run:
>>
>>//inserts the device into the USB hub
>># echo blue_on:1 > /proc/acpi/toshiba/bluetooth
>
>
> Where is this documented?
Apparently many notebooks (atleast many toshiba's) have devices that can
be plugged in and out via software. The USB BT dongle in my notebook is
one of these.. There's a button on the side of the notebook that can be
used to be sure that the device is off (like in an airplane).
I found a patch for linux/driver/acpi/toshiba_acpi.c on this site:

http://nicolas.bettenburg.free.fr/linux/#c4

I hade to fiddle alot with it to make it work with 2.4.22 (I guess he
has not written it against a recent kernel). I came up with a patch that
worked ok with 2.4.22, and to my surprice it worked fine with 2.6.0 too.

My guess is that the ACPI stuff has been backported into 2.4.22 and
that's why it's almost the same.. I put the patch I use here so you can
look if you want: ftp://zappa.cx/pub/echinacea/toshiba_bluetooth.patch
It currently doesn't apply cleanly on 2.6.0-test9 but not important
stuff just comments doesn't apply.

I would be glad if this is the problem (though I think it's not since I
guess it's only job is to logically insert the USB dongle).
I'm no programmer so I might have done a poor conversion so it won't
hurt to check.

> The resubmit means that the previous URB fails and this is causing the
> problems. But at the moment I have no idea how to track this in detail.
Will it help if I attach a session when it works to see if it's any
different?



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-05 12:18:56

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi Andreas,

> > from the devices output I see that this device is based on a Silicon
> > Wave chip and it seems that I don't have this device in my list. So what
> > kind of model do you have and what is the output of "hciconfig -a".
> hci0: Type: USB
> BD Address: 00:03:7A:08:13:91 ACL MTU: 60:20 SCO MTU: 64:0
> UP RUNNING PSCAN ISCAN
> RX bytes:63 acl:0 sco:0 events:7 errors:0
> TX bytes:28 acl:0 sco:0 commands:7 errors:0
> Features: 0xff 0x02 0x04 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1
> Link policy:
> Link mode: SLAVE ACCEPT
> Name: ''
> Class: 0x000000
> Service Classes: Unspecified
> Device Class: Miscellaneous,
> HCI Ver: 1.1 (0x1) HCI Rev: 0x0 LMP Ver: 1.1 (0x1) LMP Subver:
> 0x514
> Manufacturer: Silicon Wave (11)

and what is the model of your notebook?

> > This is a question for the USB guys. Do you have another USB Bluetooth
> > dongle to test with your notebook?
> I inserted a MS Wireless Transceiver for Bluetooth and it gave the same
> error.. but seems to work alright. Havn't done much testing yet though.

Please test this. If the Microsoft is working all the time then your
problem is part of the Silicon Wave chip or some else in the internal
USB stuff of your notebook. However it works in 2.4 this must be some
kind of problem in the Linux USB subsystem which only effects this kind
of device.

> Here's the output from a "bad" session:
>
> This is what I'v run:
>
> //inserts the device into the USB hub
> # echo blue_on:1 > /proc/acpi/toshiba/bluetooth

Where is this documented?

> Here's the dmesg output:
> hub 4-0:1.0: new USB device on port 1, assigned address 2
> hci_usb_probe: udev d8436c00 ifnum -1069408960
> hci_usb_probe: udev d8436c00 ifnum -1069408960
> hci_usb: probe of 4-1:1.1 failed with error -5
> hci_usb_open: hci0
> hci_usb_intr_rx_submit: hci0
> hci_usb_bulk_rx_submit: hci0 urb d947f694
> hci_usb_send_frame: hci0 type 1 len 3
> hci_usb_tx_process: hci0
> hci_usb_send_ctrl: hci0 skb da07f880 len 3
> __tx_submit: hci0 urb d8fd3c14 type 1
> hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
> hci_usb_tx_process: hci0
> hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 14 flags 0
> __recv_frame: hci0 type 4 data da088dc0 count 14
> __recv_frame: new packet len 14
> hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0

The resubmit means that the previous URB fails and this is causing the
problems. But at the moment I have no idea how to track this in detail.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-05 12:07:33

by Andreas Sundstrom

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

First, thanks for taking your time to look at my problem, I appreciate it!

Here goes...

Marcel Holtmann wrote:
> Hi Andreas,
...
> from the devices output I see that this device is based on a Silicon
> Wave chip and it seems that I don't have this device in my list. So what
> kind of model do you have and what is the output of "hciconfig -a".
hci0: Type: USB
BD Address: 00:03:7A:08:13:91 ACL MTU: 60:20 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN
RX bytes:63 acl:0 sco:0 events:7 errors:0
TX bytes:28 acl:0 sco:0 commands:7 errors:0
Features: 0xff 0x02 0x04 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1
Link policy:
Link mode: SLAVE ACCEPT
Name: ''
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x0 LMP Ver: 1.1 (0x1) LMP Subver:
0x514
Manufacturer: Silicon Wave (11)

> What are your kernel config settings for the HCI USB driver. I prefer
> you try it with these.
>
> CONFIG_BT_HCIUSB=m
> # CONFIG_BT_USB_SCO is not set
> # CONFIG_BT_USB_ZERO_PACKET is not set
Right now I have CONFIG_BT_HCIUSB=y beacause I checked if that would
make things better, it did not.
SCO,Zeropacket is off

>>I've tried to enable some debugging in hci_usb.c but I don't understand
>>what to make out of it.. not much that seems wrong to me..
>
>
> Include a "#define HCI_USB_DEBUG" after the last include directive.
That's what I did.. I meant that the output I got from it didn't say
much to mee.. I'll attach it in the end of the mail so you can check it.

>>I get one error when loading the hci_usb module though:
>>hub 4-0:1.0: new USB device on port 1, assigned address 2
>>hci_usb: probe of 4-1:1.1 failed with error -5
>>
>>Don't know if it's related, the device seems fine and this showes up
>>even when the device happen to work.
>
>
> This is a question for the USB guys. Do you have another USB Bluetooth
> dongle to test with your notebook?
I inserted a MS Wireless Transceiver for Bluetooth and it gave the same
error.. but seems to work alright. Havn't done much testing yet though.

>
> Regards
>
> Marcel
>
Here's the output from a "bad" session:

This is what I'v run:

//inserts the device into the USB hub
# echo blue_on:1 > /proc/acpi/toshiba/bluetooth

# hciconfig
hci0: Type: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0

# hciconfig hic0 up

//No delay and no detected devices
# hcitool inq
Inquiring ...


Here's the dmesg output:
hub 4-0:1.0: new USB device on port 1, assigned address 2
hci_usb_probe: udev d8436c00 ifnum -1069408960
hci_usb_probe: udev d8436c00 ifnum -1069408960
hci_usb: probe of 4-1:1.1 failed with error -5
hci_usb_open: hci0
hci_usb_intr_rx_submit: hci0
hci_usb_bulk_rx_submit: hci0 urb d947f694
hci_usb_send_frame: hci0 type 1 len 3
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb da07f880 len 3
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 14 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 14
__recv_frame: new packet len 14
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 3
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb d843bb80 len 3
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 13 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 13
__recv_frame: new packet len 13
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 3
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb da07f980 len 3
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 12 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 12
__recv_frame: new packet len 12
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 5
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb dd748980 len 5
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 6 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 6
__recv_frame: new packet len 6
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 5
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb d843bc80 len 5
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 6 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 6
__recv_frame: new packet len 6
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 5
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb d843ba80 len 5
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 6 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 6
__recv_frame: new packet len 6
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 4
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb da07f680 len 4
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 6 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 6
__recv_frame: new packet len 6
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 3
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb de339380 len 3
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
__recv_frame: new packet len 254
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 16
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 14 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 14
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 3
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb d51d8080 len 3
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 9 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 9
__recv_frame: new packet len 9
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0
hci_usb_send_frame: hci0 type 1 len 3
hci_usb_tx_process: hci0
hci_usb_send_ctrl: hci0 skb de339a80 len 3
__tx_submit: hci0 urb d8fd3c14 type 1
hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0
hci_usb_tx_process: hci0
hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 14 flags 0
__recv_frame: hci0 type 4 data da088dc0 count 14
__recv_frame: new packet len 14
hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0

Hope you can make something out of it.

/Andreas



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

2003-11-05 11:22:46

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-users] 2.6.0-test9 SiW works sometimes

Hi Andreas,

> I have a Toshiba Laptop with a Bluetooth USB device integrated in it.
> I can use the BT device without problems in 2.4.22, but with 2.6.0-test9
> it doesn't work for most of the time.

from the devices output I see that this device is based on a Silicon
Wave chip and it seems that I don't have this device in my list. So what
kind of model do you have and what is the output of "hciconfig -a".

> USB seems to be working just fine so that shouldn't be it.
>
> The problem is that most of the time a "hcitool inq/scan" just returns
> "Inquiring ..." immediatly, without any delay like it didn't do anything.
>
> If I remove the modules and reload them over and over again it usually
> works after a while and when it works it stays working until I decide to
> reboot.

What are your kernel config settings for the HCI USB driver. I prefer
you try it with these.

CONFIG_BT_HCIUSB=m
# CONFIG_BT_USB_SCO is not set
# CONFIG_BT_USB_ZERO_PACKET is not set

> I've tried to enable some debugging in hci_usb.c but I don't understand
> what to make out of it.. not much that seems wrong to me..

Include a "#define HCI_USB_DEBUG" after the last include directive.

> I get one error when loading the hci_usb module though:
> hub 4-0:1.0: new USB device on port 1, assigned address 2
> hci_usb: probe of 4-1:1.1 failed with error -5
>
> Don't know if it's related, the device seems fine and this showes up
> even when the device happen to work.

This is a question for the USB guys. Do you have another USB Bluetooth
dongle to test with your notebook?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users