0 users browsing Discussion. | 41 bots
Pages: 1
| tomman |
Posted on 18-12-25, 20:18
|
|
Dinosaur
 Post: #103 of 1315 Since: 10-30-18 Last post: 58 days Last view: 18 hours |
Recently I was installing updates on one of my Debian laptops, just to discover that, after a reboot, Bluetooth stopped working. Normally I don't even bother with Bluetooth: whenever I need to transfer data between PC and my cellphones, either I take away the memory cards or go wired. I don't have wireless mice/keyboards, and I forgot when it was the last time I played with my Wiimote. But still, broken things that used to work are always a massive annoyance to me, so it's time to dig out and investigate! Once again, the subject it's my trusty ol' Inspiron 6400, with the Dell 355 integrated BT dongle (it lives inside the battery compartment) BTO option. Since Dell has always been cozy with Broadcom wireless solutions, the dongle is based on a BCM2045 IC, very popular in BT dongles of the era. This IC has always been well supported by Linux since the beginning (although it would take some years for BlueZ and friends service offerings to catch up with the Windows/Broadcom BT stack). In my case, since my DE of choice is MATE, I'm using Blueman, which will subtly but clearly tell you when BT is not working, by overlaying a small red X over the trademarked BT icon. I tried turning it on again, and although Blueman cleared the red X, I still got no adapters listed! Tried rebooting, nada. Tried checking the settings on the BIOS (I've had luck with this in the past when dealing with wireless malfunctions on other laptops), but nope. Tried cycling the radio switch (Fn+F2), without results. Maybe the adapter fried and I didn't had noticed? Couldn't be - the BT LED on the laptop was solid blue. And here are when things take a turn to the weird: tried booting Windows 7, and BT was working flawlessly! (ruling out possible hardware issues). Rebooted back to Debian, and noticed not only BT was not working, the BCM2045 device was nowhere to be seen! Not in lsusb, not in the kernel logs. But, it eventually appeared on its own (!?!??!). Toggled it with the Fn+F2 hotkey, it never came back - the kernel was simply ignoring whatever it was plugged on that internal USB port (which according to Windows and lsusb when the device works, it's Bus 004, Port 002). That kernel version is 4.9 (4.9.110-3+deb9u5~deb8u1 from 4.9.0-0.bpo.8-amd64 on jessie-backports). I had got rid of all earlier kernels but the oldest one (3.16, which is the stock kernel for Debian Jessie). Surprise, the USB port works without issues on 3.16! Whatever was happening here is clearly a kernel issue with the USB stack, but that for whatever reason only affects the USB port where the internal BT dongle is plugged in - all other USB devices work as expected. Then, after checking the lsusb output, I've noticed something REALLY odd: when running in verbose mode as root (sudo lsusb -v), the output would pause for a split second when listing the details for Bus 004 (that is, the root hub where the BT dongle resides; it has 2 ports but only one seems to be connected to an actual physical port), and surprisingly the BT device would activate! So... uh, I'm completely dumbfounded here. Unfortunately I can't test newer kernels on this thing (unless if I build them from source, something which is a PITA if done the Debian Way™) because Jessie stopped getting backported kernels at 4.9, and this is one of the systems I am NOT upgrading to Stretch and its highly UXtarded DEs full of insanity, and considering Jessie is now at its LTS phase, filing a bugreport might be useless... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
Pages: 1
