> > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=201647 > > > > > > > > Bug ID: 201647 > > > > Summary: Intel Wireless card 3165 does not get detected but > > > > bluetooth works > > > > Product: Drivers > > > > Version: 2.5 > > > > Kernel Version: 4.19.1 > > > > Hardware: Intel > > > > OS: Linux > > > > Tree: Mainline > > > > Status: NEW > > > > Severity: high > > > > Priority: P1 > > > > Component: PCI > > > > Assignee: drivers_...@kernel-bugs.osdl.org > > > > Reporter: mertar...@gmail.com > > > > Regression: No > > > > > > > > This bug affects most of the devices with a Celeron N4000 and an > > > > Intel wifi 3165 Ac adapter. > > > > > > > > When using Linux wifi is not working however, Bluetooth is working > > > > fine. Also, Bluetooth part of this chip is connected via btusb > > > > and the wifi part of this chip is connected via PCIe. > > > > > > Can you attach a screenshot of the Windows 10 device manager info > > > for the wifi adapter to the bugzilla? If you can get a raw hex dump > > > of its config space, that would be awesome. > > > > > > Also attach a copy of your kernel .config file (typically in /boot/). > > > > > > My only guess is that maybe the system keeps wifi completely powered > > > down and uses hotplug to add it when needed. [1] mentions wifi > > > being on pcibus 1 under Windows. Your lspci does show bridge > > > 00:13.0 leading to bus 01, but Linux doesn't find any devices on bus 01. > > > > > > Hotplug could be done via either acpiphp (ACPI mediated hotplug) or > > > pciehp (native PCIe hotplug). Your dmesg shows you do have acpiphp. > > > > > > I can't tell about pciehp (your .config will show that), but I think > > > pciehp will only claim bridges where SltCap contains HotPlug+, and > > > yours shows HotPlug- , so I don't think pciehp will do anything on your > system. > > > > > > Even if the system does use hotplug, I don't know what mechanism the > > > OS would use to wake up the device, since we don't know it even > > > exists. I guess there could be some magic switch accessible via USB. > > > But if that were the case, I'm sure Emmanuel would know about it. > > > > Hm... Don't be so sure... :) > > I don't think we have anything as fancy as this. > > I guess you can try to dig into the BIOS settings? > > I have heard of such a switch that would make the device disappear. > > It's worth looking, but I don't understand how a BIOS switch would solve this > problem. I assume that with the same BIOS settings, Windows works and > Linux fails.
I guess I had a typo there... I have *not* heard of such a switch. > > Maybe there would be a clue in an acpidump from affected machines, e.g., > maybe we'd see some kind of ACPI hotplug notification. That seems like a > long shot because we do have acpiphp in the kernel, and it *should* be > handling such notifications, but it could always be broken. > > The Windows device manager info (requested above) would be interesting. > Indeed. FWIW: I saw another problem like this with a 9650 device. PS: PCI folks don't use bugzilla's anymore? It's all over the mailing list?
