Date: Mon, 06 Jan 2025 23:54:35 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 283896] iwmbtfw(8): [PATCH] Check firmware exists before trying to upload it Message-ID: <bug-283896-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283896 Bug ID: 283896 Summary: iwmbtfw(8): [PATCH] Check firmware exists before trying to upload it Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: gavin@FreeBSD.org Flags: mfc-stable14+ Created attachment 256486 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D256486&action= =3Dedit Patch against head TLDR: Device disconnects and reconnects to the USB bus twice a second. iwmbtfw is the tool used to upload Bluetooth firmware to iwm(4) Intel WiFi cards. It is called from devd(4) via the rules in /etc/devd/iwmbtfw.conf w= hen the device appears. In the case of an Intel 7260 device, the device needs to be put into someth= ing called "manufacturer mode" before the firmware is uploaded. The firmware is then upladed, and the card is taken out of this mode, at which point it disconnects and reconnects to the USB bus, and is at that point usable. However, iwmbtfw(8) puts the device into manufacturer mode before verifying that there exists a copy of the firmware to upload. As a result, in the ca= se where there is no firmware, the device is put into manufacturer mode, the firmware can't be found so isn't uplaoded, and the card is brought out of manufacturer mode, so it disconnects and reconnects to the USB bus. Enter devd(8). There are rules in /etc/devd/iwmbtfw.conf to call iwmbtfw(8) when the device appears. When there's no firmware on disk, devd will call iwmbtfw, iwmbtfw will do its thing and fail, the device will dis/reconnect,= and devd will notice and start the whole loop again. Result of this is: Jan 6 18:47:32 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 Jan 6 18:47:32 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 (disconnected) Jan 6 18:47:32 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 Jan 6 18:47:32 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 (disconnected) Jan 6 18:47:33 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 Jan 6 18:47:33 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 (disconnected) Jan 6 18:47:33 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 Jan 6 18:47:33 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 (disconnected) Jan 6 18:47:34 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 Jan 6 18:47:34 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 (disconnected) Jan 6 18:47:34 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 Jan 6 18:47:34 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 (disconnected) Jan 6 18:47:35 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 Jan 6 18:47:35 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 (disconnected) Jan 6 18:47:35 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 Jan 6 18:47:35 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at us= bus0 (disconnected) Fix (attached) is to verify that the firmware exists before putting the dev= ice into its special mode. The fix only changes things for the 7260 and not the other chips supported, I can't easily test those so don't know if the probl= em exists there or not but I suspect not as those do not need to be switched i= nto manufacturer mode before uplading. This needs backporting to stable/14 (confirmed, I see the same behaviour) a= nd stable/13 (suspected, not confirmed). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283896-227>