Bug#634794: cdrom eject button has stopped working

--- On Wed, 20/7/11, Jonathan Nieder wrote: > Could you attach full output from "dmesg" (so we can see > what model of CD-ROM we are talking about)? There is nothing in dmesg about the drive, but the system has been up a while. Is there some way I can query for the cdrom drive information? I f

Bug#634794: cdrom eject button has stopped working

Package: linux-2.6 Version: 2.6.39-2 Severity: normal File: linux The cdrom eject button appears to have stopped working and the eject command does not work either. eject /dev/cdrom This just returns to a prompt, and the drive stays closed. It used to work before when the drives all had /dev/hd*

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

A strange thing has just happened. I plugged the dongle in to get some information from it, and when I ran hciconfig, it showed as "up running": hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 00:1F:81:00:01:1C ACL MTU: 1021:4 SCO MTU: 180:1 UP RUNNING PSCAN RX

Bug#525220: Nano Tiny USB 2.0 Bluetooth Adapter

There are some mass market USB Bluetooth Dongles available, which are badged as "NANO TINY USB 2.0 BLUETOOTH ADAPTER DONGLE EDR WIRELESS". These adapters have a part number 500792110001, and a package barcode of 200529837. These devices are available from Ebay, and from large online retailer

Bug#525220: Bluetooth problem caused by fake dongles?

--- On Wed, 22/6/11, Ben Hutchings wrote: > There is a standard USB 'device class' for Bluetooth > adapters, which are all handled by the 'btusb' driver. Right. So does that mean that there is a chance that these devices might work in future? Or do we need to be shopping round for replacement a

Bug#525220: Bluetooth problem caused by fake dongles?

--- On Tue, 21/6/11, Alexander Heinz wrote: > 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. Bloody hell Alex. I just took your advise and opened the dongle. And woa

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

I attached a system trace against #628454, so hopefully, someone can interpret this and tell us what is going wrong. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.o

Bug#525220: Bluetooth problem caused by fake dongles?

--- On Tue, 21/6/11, Alexander Heinz wrote: > 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 identica

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

I upgraded the kernel to 2.6.39-1 from experimental and rebooted the system. Initially, After typing hcitool inq, the system showed that my mobile phone was present, so it appeared as though bluetooth was at least momentarily partially working. However, from the mobile phone, the computer was no

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

I have just tested this again with experimental kernel 2.6.39-rc4-486 (Debian 2.6.39~rc4-1~experimental.1). The problem is still occuring with that kernel build: # hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 00:1F:81:00:01:1C ACL MTU: 1021:4 SCO MTU: 180:1 DOWN

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

A! When I try to bring the device into operational mode, the timeout error occurs, so I guess this is still not fixed in 2.6.38-rc6-486: hciconfig hci0 up Can't init device hci0: Connection timed out (110) Mark. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

I have just tested this again with kernel version 2.6.38-rc6-486. This time, no timeout occurs with hciconfig: hciconfig -a hci0 hci0: Type: BR/EDR Bus: USB BD Address: 00:1F:81:00:01:1C ACL MTU: 1021:4 SCO MTU: 180:1 DOWN RX bytes:342 acl:0 sco:0 events:10 errors:0

Bug#525220: Fw: Re: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

--- On Sat, 11/12/10, Ben Hutchings wrote: > Please report this bug upstream at under > product 'Drivers', component 'Bluetooth'.  Let us know > the bug number or URL so we can track it. Issue tracking numbers relating to this bug are: Linux kernel team #10126 Laun

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

I have retested this again. This time with experimental kernel version 2.6.37-rc5 (Debian 2.6.37~rc5-1~experimental.1). The timeout error is still occuring, so the latest attempts at fixing this have not worked. THE KERNEL IS STILL BROKEN: hciconfig -a

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

I have just tested this with the experimental kernel version 2.6.36-rc5-486. I am still getting the timeout error: hciconfig -a hci0 hci0: Type: BR/EDR Bus: USB BD Address: 00:1F:81:00:01:1C ACL MTU: 1021:4 SCO MTU: 180:1 UP RU

Bug#525220: Bluetooth trouble with hci_cmd_task: hci0 command tx timeout

--- On Mon, 16/8/10, mailsanm...@gmx.li wrote: > I have the same problem with the same type of Bluetooth > dongle (even my MAC address is the same). Were you able to > work around this problem? Do you have any working > combination of kernel and bluez that enables you to actually > use this dongl

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

Moritz Muehlenhoff wrote: > The next release of Debian (6.0, code name Squeeze) will be based > on 2.6.32. Please test the current 2.6.32 from unstable/testing and tell > us whether the problem persists. Hello Moritz. I am testing with kernel 2.6.32-5-486 I am getting the timeout here, so I recko

Bug#540074: netfilter leaking traffic when long chains defined

Right, I am trying to capture some traffic using: tcpdump -f -xx '( port 8000 ) and (( ! src net 10.0.0.0/8 ) or ( ! dst net 10.0.0.8 ))' Oops. that should read: tcpdump -f -xx '( port 8000 ) and (( ! src net 10.0.0.0/8 ) or ( ! dst net 10.0.0.0/8 ))' -- To UNSUBSCRIBE, email to debian-

Bug#540074: netfilter leaking traffic when long chains defined

Right, I am trying to capture some traffic using: tcpdump -f -xx '( port 8000 ) and (( ! src net 10.0.0.0/8 ) or ( ! dst net 10.0.0.8 ))' This will capture traffic from the live system, which is using service port 8000, rather than test port , which is from test. (On the live system the se

Bug#540074: netfilter leaking traffic when long chains defined

Hello Bastian. Re: Bug#540074: netfilter leaking traffic when long chains defined Sorry for the delay. For some reason I did not get a copy of your email, and I just found your messages on an internet archive. tcp 0 0 10.0.0.8: 118.168.141.172:3388 ESTABLISHED This is an established connec

Bug#540074: netfilter leaking traffic when long chains defined

Package: linux-image-2.6-486 Version: 2.6.26+17+lenny1 Severity: normal File: linux There appears to be traffic leaking across the netfilter when a long chain of valid ip addresses are used. I am getting connections being established from outside of the valid address list. For example: netstat -

Bug#488022: New findings.

Raúl Sánchez Siles wrote: Make paravirt feature depends on 586/pentium (upstream), since not all 486 support the cpuid needed infrastructure, again upstream advice would be needed. Disable paravirtualization in Debian kernel for 486. This is somewhat thorny. Is paravirtualization absolutely n

Bug#506345: linux-image-2.6-486: Facility to allow falsified information in /proc/cpuinfo

Package: linux-image-2.6-486 Version: 2.6.26+16 Severity: wishlist It would be useul to have the facility to provide a generic entry in /proc/cpuinfo rather than revealing processor specific information. This could possibly be done via a boot option, such as cpuinfo=486 or cpuinfo=pentium Thi

Bug#500158: linux-image-2.6.26-1-486: Upgrade from Debian Etch to Debian Lenny may cause a kernel halt

Package: linux-image-2.6.26-1-486 Version: 2.6.26-5 Severity: important As Debian is upgraded from Debian Etch to Debian Lenny, the kernel may halt with an error as the system is restarted: Booting the Kernel. BUG Int 6: CR2 EDI c0363f8c ESI 4000 EBP c0363f88 ESP c036f44 EBX 00