Bug#525220: Bluetooth problem caused by fake dongles?
Hello! I also have a problem with Bluetooth. I have recently bought a new USB dongle in the store (instead of on ebay) that does not seem to have this problem. The funny thing is that the USB IDs are identical, so the two devices claim to be identical as well. What also makes me wonder is the fact the MAC address of my dongle does not seem to be unique. I have several dongles, all of them have the address 00:1F:81:00:01:1C. Google for it and you will find more people that have dongles with the same address. I came across the following blog that seems to confirm that there are fake CSR dongles on the market: http://diy-machine.blogspot.com/search/label/Cheap%20ebay%20dongle Is it possible that all of us have bought counterfeit dongles? Best regards, Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525220: Bluetooth problem caused by fake dongles?
My mobile phone showed up as present on one of the release candidate kernels, so mine is not fake. We could always borrow a friends laptop that runs Micros~1youknowwhat and test the dongles for operation. I am not saying that my dongle does not work at all. What I am saying is that my dongle claims to be based on a CSR chip although it is not. The USB IDs corresponds to CSR but the chip label says ASC AS3620QA. This is a counterfeit. Is very easy to tell. Just open your dongle and check the label on the chip. Best regards, Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614786: patch for #614786
Hello!
I also would like to confirm that the patch linked in the initial bug
report fixes this problem.
Please include it in debian.
--- chan_mobile.c 2011-06-20 23:44:18.0 +0200
+++ chan_mobile.c.working 2011-06-20 23:55:07.0 +0200
@@ -1288,7 +1288,7 @@
memset(addr, 0, sizeof(addr));
addr.rc_family = AF_BLUETOOTH;
bacpy(addr.rc_bdaddr, src);
- addr.rc_channel = (uint8_t) 1;
+ addr.rc_channel = (uint8_t) 0;
if (bind(s, (struct sockaddr *)addr, sizeof(addr)) 0) {
ast_debug(1, bind() failed (%d).\n, errno);
close(s);
Best regards,
Alex
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568367: please reopen this issue
This bug report has been closed although it has not been resolved. The suggested solution (to install usb_modeswitch) does not fix the problem. Do you need more information to debug this? What can I do to help? Do you need me to add another bug report or can you reopen the existing one? Thank you! Best regards, Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568367: usb mode switch is not the root cause
please show dmesg of fresh boot with it installed, thanks. thank you for your reply. The UMTS stick was plugged in a couple of minutes after booting the system. Here is the requested dmesg output. r...@p3:/var/log# dmesg [ 0.00] Initializing cgroup subsys cpuset [ 0.00] Initializing cgroup subsys cpu [ 0.00] Linux version 2.6.32-3-686 (Debian 2.6.32-9) (m...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-8) ) #1 SMP Thu Feb 25 06:14:20 UTC 2010 [ 0.00] KERNEL supported cpus: [ 0.00] Intel GenuineIntel [ 0.00] AMD AuthenticAMD [ 0.00] NSC Geode by NSC [ 0.00] Cyrix CyrixInstead [ 0.00] Centaur CentaurHauls [ 0.00] Transmeta GenuineTMx86 [ 0.00] Transmeta TransmetaCPU [ 0.00] UMC UMC UMC UMC [ 0.00] BIOS-provided physical RAM map: [ 0.00] BIOS-e820: - 0009f800 (usable) [ 0.00] BIOS-e820: 0009f800 - 000a (reserved) [ 0.00] BIOS-e820: 000e6c00 - 0010 (reserved) [ 0.00] BIOS-e820: 0010 - 040fd800 (usable) [ 0.00] BIOS-e820: 040fd800 - 040ff800 (ACPI data) [ 0.00] BIOS-e820: 040ff800 - 040ffc00 (ACPI NVS) [ 0.00] BIOS-e820: 040ffc00 - 1000 (usable) [ 0.00] BIOS-e820: fffe6c00 - 0001 (reserved) [ 0.00] DMI 2.1 present. [ 0.00] last_pfn = 0x1 max_arch_pfn = 0x10 [ 0.00] MTRR default type: uncachable [ 0.00] MTRR fixed ranges enabled: [ 0.00] 0-9 write-back [ 0.00] A-B uncachable [ 0.00] C-CBFFF write-protect [ 0.00] CC000-D uncachable [ 0.00] E-F write-protect [ 0.00] MTRR variable ranges enabled: [ 0.00] 0 base 0 mask FF000 write-back [ 0.00] 1 disabled [ 0.00] 2 disabled [ 0.00] 3 disabled [ 0.00] 4 disabled [ 0.00] 5 disabled [ 0.00] 6 disabled [ 0.00] 7 disabled [ 0.00] PAT not supported by CPU. [ 0.00] initial memory mapped : 0 - 0180 [ 0.00] init_memory_mapping: -1000 [ 0.00] 00 - 40 page 4k [ 0.00] 40 - 001000 page 2M [ 0.00] kernel direct mapping tables up to 1000 @ 7000-c000 [ 0.00] RAMDISK: 0294e000 - 030fd9e9 [ 0.00] ACPI: RSDP 000f68b0 00014 (v00 PTLTD ) [ 0.00] ACPI: RSDT 040fd95d 00028 (v01 PTLTD RSDT PTL 0100) [ 0.00] ACPI: FACP 040ff78c 00074 (v01 INTEL SEATTLE2 19990317 PTL 000F4240) [ 0.00] ACPI: DSDT 040fd985 01E07 (v01 Intel AB440ZX MSFT 0104) [ 0.00] ACPI: FACS 040ffbc0 00040 [ 0.00] 0MB HIGHMEM available. [ 0.00] 256MB LOWMEM available. [ 0.00] mapped low ram: 0 - 1000 [ 0.00] low ram: 0 - 1000 [ 0.00] node 0 low ram: - 1000 [ 0.00] node 0 bootmap 2000 - 4000 [ 0.00] (9 early reservations) == bootmem [00 - 001000] [ 0.00] #0 [00 - 001000] BIOS data page == [00 - 001000] [ 0.00] #1 [001000 - 002000] EX TRAMPOLINE == [001000 - 002000] [ 0.00] #2 [006000 - 007000] TRAMPOLINE == [006000 - 007000] [ 0.00] #3 [000100 - 00014a9314] TEXT DATA BSS == [000100 - 00014a9314] [ 0.00] #4 [000294e000 - 00030fd9e9] RAMDISK == [000294e000 - 00030fd9e9] [ 0.00] #5 [09f800 - 10] BIOS reserved == [09f800 - 10] [ 0.00] #6 [00014aa000 - 00014b0120] BRK == [00014aa000 - 00014b0120] [ 0.00] #7 [007000 - 008000] PGTABLE == [007000 - 008000] [ 0.00] #8 [002000 - 004000] BOOTMAP == [002000 - 004000] [ 0.00] Zone PFN ranges: [ 0.00] DMA 0x - 0x1000 [ 0.00] Normal 0x1000 - 0x0001 [ 0.00] HighMem 0x0001 - 0x0001 [ 0.00] Movable zone start PFN for each node [ 0.00] early_node_map[3] active PFN ranges [ 0.00] 0: 0x - 0x009f [ 0.00] 0: 0x0100 - 0x40fd [ 0.00] 0: 0x4100 - 0x0001 [ 0.00] On node 0 totalpages: 65436 [ 0.00] free_area_init_node: node 0, pgdat c1396fc0, node_mem_map c14b2000 [ 0.00] DMA zone: 32 pages used for memmap [ 0.00] DMA zone: 0 pages reserved [ 0.00] DMA zone: 3967 pages, LIFO batch:0 [ 0.00] Normal zone: 480 pages used for memmap [ 0.00] Normal zone: 60957 pages, LIFO batch:15 [ 0.00] Using APIC driver default [ 0.00] ACPI: PM-Timer IO Port: 0x8008 [ 0.00] SMP: Allowing 1 CPUs, 0 hotplug CPUs [ 0.00]
Bug#568367: usb mode switch is not the root cause
USB mode switch does not improve the situation. This makes sense because if usb mode switch was required for this kernel version and device, the virtual serial ports would not even come up. _ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969
Bug#568367: usbmon logs of the vodafone k3520/huawei e169 ttyUSB0-2 disconnect problem
I have created a usbmon log and hope that it helps with the analysis. Logging was started before the stick was plugged in. The disconnect happened 15.1 hours after plugging it in. The file size of the compressed log is 6.6MBytes which is probably too big for sending it via e-mail. So I have uploaded it to rapidshare: http://rapidshare.com/files/346280024/k3520_log.lzma.html Best regards, Alex _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568367: linux-image-2.6.32-trunk-686: vodafone k3520 a.k.a. huawei e169 umts 3g umts usb stick randomly disconnects and reconnects
Package: linux-2.6 Version: 2.6.32-5 Severity: normal Hello! I own 3 Vodafone K3520 UMTS 3G sticks which are also known as Huawei E169 as far as I know Bus 001 Device 007: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem Manufacturer: huawei Model: K3520 Revision: 11.314.21.31.00 I have to face the problem that these devices (I have 3 of them) seem to randomly disconnect and reconnect. Sometimes it takes days for this to happen, sometimes less than an hour. I have tested this with Linux (Debian unstable/sid, kernel 2.6.32-5), but I can also reproduce this with other kernel versions The steps to reproduce this are fairly easy: - boot a recent kernel - deactivate the PIN of your SIM - insert the SIM into the USB stick (tried SIMs of several operators with the same effect) - connect it to your USB port - check the dmesg output from time to time and wait till the problem occurs (no need to establish a connection) The interesting part of the log at the end of this post seems to be: [227101.066954] option: option_instat_callback: error -84 [227101.149935] option: option_instat_callback: error -108 As far as I can tell (I do not know for sure), this seems to trigger the reconnect. I have tested this with 3 different UMTS/3G sticks on 4 different PCs in different scenarios (the stick was always the only device connected to USB, I have also tried to put a USB hub with an external power supply in between, tried both, PCs with USB 1.1 and USB 2.0). Best regards, Alex Here is the full log of such a disconnect/reconnect cycle (output of dmesg) [171258.664103] usb 1-1: new full speed USB device using uhci_hcd and address 4 [171258.824201] usb 1-1: New USB device found, idVendor=12d1, idProduct=1001 [171258.824211] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=1 [171258.824220] usb 1-1: Product: HUAWEI Mobile [171258.824227] usb 1-1: Manufacturer: ������������������������������������������������������������������������������������������������������������������ [171258.824235] usb 1-1: SerialNumber: ������������������������������������������������������������������������������������������������������������������ [171258.827367] usb 1-1: configuration #1 chosen from 1 choice [171258.836035] scsi2 : SCSI emulation for USB Mass Storage devices [171258.837255] usb-storage: device found at 4 [171258.837262] usb-storage: waiting for device to settle before scanning [171259.048129] usb 1-1: USB disconnect, address 4 [171259.288099] usb 1-1: new full speed USB device using uhci_hcd and address 5 [171259.454093] usb 1-1: New USB device found, idVendor=12d1, idProduct=1001 [171259.454102] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=1 [171259.454111] usb 1-1: Product: HUAWEI Mobile [171259.454118] usb 1-1: Manufacturer: ������������������������������������������������������������������������������������������������������������������ [171259.454126] usb 1-1: SerialNumber: ������������������������������������������������������������������������������������������������������������������ [171259.456962] usb 1-1: configuration #1 chosen from 1 choice [171259.474131] scsi6 : SCSI emulation for USB Mass Storage devices [171259.485358] usb-storage: device found at 5 [171259.485368] usb-storage: waiting for device to settle before scanning [171259.612724] usbcore: registered new interface driver usbserial [171259.613344] USB Serial support registered for generic [171259.613960] usbcore: registered new interface driver usbserial_generic [171259.613970] usbserial: USB Serial Driver core [171259.662107] USB Serial support registered for GSM modem (1-port) [171259.663024] option 1-1:1.0: GSM modem (1-port) converter detected [171259.664041] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0 [171259.665362] option 1-1:1.1: GSM modem (1-port) converter detected [171259.668035] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1 [171259.668035] option 1-1:1.2: GSM modem (1-port) converter detected [171259.670784] usb 1-1: GSM modem (1-port) converter now
