Bug#1057656: firmware-amd-graphics: No display on Raphael in 20230625-1
Hi, This appears to be fixed since the update to 20240709-1. sney
Bug#1057656: firmware-amd-graphics: No display on Raphael in 20230625-1, please revert DMCUB updates
Package: firmware-amd-graphics Version: 20230625-1 Severity: important X-Debbugs-Cc: je...@sney.ca Dear Maintainer, After updating to firmware-amd-graphics 20230625-1 on my trixie system this morning, I found amdgpu unable to use modesetting, instead filling the journal with messages like "[drm:dc_dmub_srv_cmd_run_list [amdgpu]] *ERROR* Error queueing DMUB command: status=2" The GPU is 0e:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c3). I found this commit from the kernel.org firmware repository: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d3f66064cf43bd7338a79174bd0ff60c4ecbdf6d Manually placing this reverted dcn_3_1_5_dmcub.bin in /lib/firmware/amdgpu fixed my display. Please apply this fix, or package a newer linux-firmware that includes the change. Thanks for your work! sney -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.142 -- no debconf information
Bug#1043564: linux: Please Re-enable DC states for drm/i915
Ah, great! If only they were all this easy. Thanks again, sney On Sun, Aug 13, 2023 at 1:44 AM Salvatore Bonaccorso wrote: > > Control: tags -1 + confirmed upstream fixed-upstream pending > > Hi, > > On Sat, Aug 12, 2023 at 10:40:09PM -0400, Jesse Rhodes wrote: > > Source: linux > > Severity: important > > Tags: patch > > X-Debbugs-Cc: je...@sney.ca > > > > Dear debian kernel team, > > > > The upstream commit "drm/i915: Disable DC states for all commits" [1] > > breaks my > > Asus C204M Chromebook's ability to wake the screen after power management > > shuts > > it off. This also produces a kernel stack trace, attached. It's likely that > > it > > has the same effect on other Intel Gemini Lake hardware or UHD 600 video > > devices. > > > > I discovered this commit by bisecting between 6.1.0-7 (6.1.20-2) and > > 6.1.0-8 (6.1.25-1), and confirmed that the current 6.1.0-10 (6.1.38-2) does > > not > > have the issue if intel_display.c is rolled back to its previous state. > > > > Attached is also the lspci output for the affected machine. > > > > I hope that "Tags: patch" is allowed as a tag when the fix is to revert a > > specific commit, and I apologize if this was already reported and I couldn't > > find it in the list. > > > > Please let me know if you need any more information, as I would be happy to > > keep debugging! > > Thanks for the report. The commit was found indeed to cause issues and > was for now reverted upstream in the 6.1.y series and released in > 6.1.45. > > The fix will be contained in the next bookworm point release update, > have just added the bugcloser for this issue as well in the current > rebase work: > > https://salsa.debian.org/kernel-team/linux/-/merge_requests/803/diffs?commit_id=050b84b3c21f5a5b5e15b562da2ffc9f0edfda3a > > Regards, > Salvatore
Bug#962500: firmware-nonfree: Please update firmware-nonfree to >=20200519 to enable support for many modern nics and gpus
Source: firmware-nonfree Severity: important Dear Maintainer, Please consider this a catchall bug report for multiple new debian users who needed to download the linux-firmware tarball from upstream in order to support wifi nics and gpus that are too new to be supported by the binary blobs from July 2019, the most recent available in any debian branch. I see some recent activity in the kernel-team salsa repo, so maybe you are waiting for some milestone, but a release sooner rather than later would be better for everyone. We are linking https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git on a weekly basis in the support channel(s). Thank you for your attention, sney -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#933302: RTL8723DE not working
Hi, I just attempted to help a user in OFTC #debian with this nic and confirmed/discovered the following: - there is no rtl8723de module in buster or bullseye/sid's kernel, despite the binary blob being present in firmware-realtek - Ubuntu's 5.4 kernel *does* have support, but it's via the RTW88 driver that should be unrelated aiui because the 8723DE nic is 802.11n and RTW88 is specifically 802.11ac, and yet: jesse@bivouac:~/temp/ubuntu$ grep -i rtw88 boot/config-5.4.0-21-generic CONFIG_RTW88=m CONFIG_RTW88_CORE=m CONFIG_RTW88_PCI=m CONFIG_RTW88_8822BE=y CONFIG_RTW88_8822CE=y CONFIG_RTW88_8723DE=y The user in #debian confirmed that the ubuntu driver supported their nic. Bullseye's 5.4 and sid's 5.5 have RTW88 as well, but sans 8723DE. See https://salsa.debian.org/kernel-team/linux/-/blob/6ba1f0beb871cf2ba9a12837cf51999692a08c53/debian/config/config for 5.5. Hopefully this information helps get support for the rtl8723de into bullseye. sney
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
I should also note that if I load powernow_k8 *after* my wireless is already working, the bug does not return. It only seems to happen if powernow_k8 loads first. On Sun, Aug 12, 2012 at 9:03 AM, Jesse Rhodes wrote: > Yes, it does! Confirmed on both bcf3655... and 3.2.0-3 from sid. Why would > a cpufreq module break a PCI wireless card like that? > > On Sat, Aug 11, 2012 at 9:43 PM, Ben Hutchings wrote: > >> On Sat, 2012-08-11 at 21:17 -0600, Jesse Rhodes wrote: >> > sney@bivouac:~/data/debian/linux$ git bisect good >> > bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad commit >> > commit bcf3655971d24d7f08f373ed5830e8e11010088a >> > Author: Andi Kleen >> > Date: Thu Jan 26 00:09:12 2012 +0100 >> > >> > cpufreq: Add support for x86 cpuinfo auto loading v4 >> [...] >> >> So does the problem go away if you unload the cpufreq driver >> (powernow_k8)? >> >> Ben. >> >> -- >> Ben Hutchings >> Sturgeon's Law: Ninety percent of everything is crap. >> > >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Yes, it does! Confirmed on both bcf3655... and 3.2.0-3 from sid. Why would a cpufreq module break a PCI wireless card like that? On Sat, Aug 11, 2012 at 9:43 PM, Ben Hutchings wrote: > On Sat, 2012-08-11 at 21:17 -0600, Jesse Rhodes wrote: > > sney@bivouac:~/data/debian/linux$ git bisect good > > bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad commit > > commit bcf3655971d24d7f08f373ed5830e8e11010088a > > Author: Andi Kleen > > Date: Thu Jan 26 00:09:12 2012 +0100 > > > > cpufreq: Add support for x86 cpuinfo auto loading v4 > [...] > > So does the problem go away if you unload the cpufreq driver > (powernow_k8)? > > Ben. > > -- > Ben Hutchings > Sturgeon's Law: Ninety percent of everything is crap. >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
sney@bivouac:~/data/debian/linux$ git bisect good bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad commit commit bcf3655971d24d7f08f373ed5830e8e11010088a Author: Andi Kleen Date: Thu Jan 26 00:09:12 2012 +0100 cpufreq: Add support for x86 cpuinfo auto loading v4 commit fa8031aefec0cf7ea6c2387c93610d99d9659aa2 upstream. This marks all the x86 cpuinfo tables to the CPU specific device drivers, to allow auto loading by udev. This should simplify the distribution startup scripts for this greatly. I didn't add MODULE_DEVICE_IDs to the centrino and p4-clockmod drivers, because those probably shouldn't be auto loaded and the acpi driver be used instead (not fully sure on that, would appreciate feedback) The old nforce drivers autoload based on the PCI ID. ACPI cpufreq is autoloaded in another patch. v3: Autoload gx based on PCI IDs only. Remove cpu check (Dave Jones) v4: Use newly introduce HW_PSTATE feature for powernow-k8 loading Cc: Dave Jones Cc: Kay Sievers Signed-off-by: Andi Kleen Signed-off-by: Thomas Renninger Acked-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman :04 04 9e8261ec125a438b1e1f36930cecbc9e72b55854 b5ede0d25adad661eb02fc4c9126cdf935eb01d5 Mdrivers sney@bivouac:~/data/debian/linux$ git bisect log git bisect start # good: [8499e79e9ee4c946ae38fd12e5d3afe8b68f2dfd] Linux 3.2.21 git bisect good 8499e79e9ee4c946ae38fd12e5d3afe8b68f2dfd # bad: [8846d9ca633324ae8596a13a511b77518061333e] Input: add Synaptics USB device driver git bisect bad 8846d9ca633324ae8596a13a511b77518061333e # good: [d2f0f9a196fe7120062ed23401b24a63609b5c98] x86, efi: Fix endian issues and unaligned accesses git bisect good d2f0f9a196fe7120062ed23401b24a63609b5c98 # good: [118c0878a89079ea69938680e78141169a0a21c1] be2net: Fix traffic stall INTx mode git bisect good 118c0878a89079ea69938680e78141169a0a21c1 # good: [4e197eba189f61cccb5ec25902ae45317d12be76] ethtool: allow ETHTOOL_GSSET_INFO for users git bisect good 4e197eba189f61cccb5ec25902ae45317d12be76 # bad: [7e2a68c51b56ef8a56ee331becb5f01f56b78865] x86/cpu: Fix overrun check in arch_print_cpu_modalias() git bisect bad 7e2a68c51b56ef8a56ee331becb5f01f56b78865 # good: [48532cdd091297c71fffa8a12e0064dc58218ff4] CPU: Introduce ARCH_HAS_CPU_AUTOPROBE and X86 parts git bisect good 48532cdd091297c71fffa8a12e0064dc58218ff4 # good: [e7b92c939bc8690e2c1188be1675aa106cdaf4c4] ACPI: Load acpi-cpufreq from processor driver automatically git bisect good e7b92c939bc8690e2c1188be1675aa106cdaf4c4 # good: [3a5874ab17f55524ec61176a81b5f9448d4eccad] HWMON: Convert coretemp to x86 cpuid autoprobing git bisect good 3a5874ab17f55524ec61176a81b5f9448d4eccad # bad: [bcf3655971d24d7f08f373ed5830e8e11010088a] cpufreq: Add support for x86 cpuinfo auto loading v4 git bisect bad bcf3655971d24d7f08f373ed5830e8e11010088a # good: [d339ab6933c6d8413ac002bda196ff3c0f3455aa] X86: Introduce HW-Pstate scattered cpuid feature git bisect good d339ab6933c6d8413ac002bda196ff3c0f3455aa Hope this helps you find the cause. On Fri, Aug 10, 2012 at 8:32 AM, Jesse Rhodes wrote: > Ok: > > 3.2.0-3 (3.2.23-1) also produces the timeouts. So, just "use the kernel > from sid" isn't even a workaround. I will continue bisecting. > > On Thu, Aug 9, 2012 at 10:41 AM, Ben Hutchings wrote: > >> On Thu, Aug 09, 2012 at 09:57:17AM -0600, Jesse Rhodes wrote: >> > Bisecting away. >> > >> > Is 3.2.0-3 (3.2.23-1) from sid exempt from the freeze? I'm going to try >> > that one as well. If it works, at least it'll likely work for the >> release, >> > though we should probably keep hunting for the cause of this bug lest it >> > surface again. >> >> The kernel and release teams are in close contact, and all linux >> uploads to sid are expected to be eligible for freeze exceptions. >> >> Ben. >> >> -- >> Ben Hutchings >> We get into the habit of living before acquiring the habit of thinking. >> - Albert >> Camus >> > >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Ok: 3.2.0-3 (3.2.23-1) also produces the timeouts. So, just "use the kernel from sid" isn't even a workaround. I will continue bisecting. On Thu, Aug 9, 2012 at 10:41 AM, Ben Hutchings wrote: > On Thu, Aug 09, 2012 at 09:57:17AM -0600, Jesse Rhodes wrote: > > Bisecting away. > > > > Is 3.2.0-3 (3.2.23-1) from sid exempt from the freeze? I'm going to try > > that one as well. If it works, at least it'll likely work for the > release, > > though we should probably keep hunting for the cause of this bug lest it > > surface again. > > The kernel and release teams are in close contact, and all linux > uploads to sid are expected to be eligible for freeze exceptions. > > Ben. > > -- > Ben Hutchings > We get into the habit of living before acquiring the habit of thinking. > - Albert > Camus >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Bisecting away. Is 3.2.0-3 (3.2.23-1) from sid exempt from the freeze? I'm going to try that one as well. If it works, at least it'll likely work for the release, though we should probably keep hunting for the cause of this bug lest it surface again.
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
(iii) broke, (iv) worked. On Tue, Aug 7, 2012 at 1:17 PM, Jonathan Nieder wrote: > Hi again, > > Jesse Rhodes wrote: > > > (i) 3.2.21-1 from snapshot produces the gain calibration timeouts. > > > > (ii) so does a rebuild of debian patched 3.2.21-3. > > Ok, perfect. > > Two more tests: > > (iii) patched 3.2.21-3 with .config used for vanilla 3.2.21? > (iv) vanilla 3.2.21 with Debian .config > > Thanks for your patience, > Jonathan >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
(i) 3.2.21-1 from snapshot produces the gain calibration timeouts. (ii) so does a rebuild of debian patched 3.2.21-3. Other kernels tried so far in order (we'll use "worked" for functional wifi, and "broke" for calibration timeouts): debian 3.2.0-2 (3.2.20-1) worked debian 3.2.0-3 (3.2.21-3) broke vanilla 3.2.20 worked vanilla 3.2.21 worked snapshot.d.o 3.3.0-rc6 (3.3~rc6-1~experimental.1) worked patched 3.2.y (3.2.25 with previous attached patches) worked debian 3.2.0-3 (3.2.21-3) still broke # got paranoid, tried it again On Tue, Aug 7, 2012 at 1:08 AM, Jonathan Nieder wrote: > Jesse Rhodes wrote: > > > Well, it's not going to happen when I'm using 3.2.0-2, and it always > > happens on 3.2.0-3 rendering it basically useless for a working system > > Thanks for clarifying. I missed that you had tried 3.2.21-3 again. > > Could you list the versions you've tested, in order, and what happened > with each for future reference? > > [...] > > Since 3.2.0-3 reports itself as Version: 3.2.21-3, and vanilla 3.2.21 > > worked fine, > > Ok, here are two tests to try. > > (i) Am I correct in guessing 3.2.21-1 from snapshot.debian.org > produces the gain calibration timeouts, too? > > (ii) Here is a way of testing if the build process changed anything, > by building the same source with the same configuration: > > cd linux > > # fetch Debian-patched kernel > git remote add debian \ > git://git.debian.org/kernel/linux.git > git fetch debian > > # configure, build, test > git checkout debian/wheezy > cp /boot/config-3.2.0-3-amd64 .config > scripts/config --disable DEBUG_INFO > make deb-pkg; # optionally with -j for parallel build > dpkg -i ../; # as root > ... test test test ... > > Thanks again, and sorry for the fuss, > Jonathan >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Well, it's not going to happen when I'm using 3.2.0-2, and it always happens on 3.2.0-3 rendering it basically useless for a working system - not only is my network controller unusable, it also constantly spams the console with those "gain calibration timeout" messages. Since 3.2.0-3 reports itself as Version: 3.2.21-3, and vanilla 3.2.21 worked fine, it must be some difference between the debian build and the upstream 3.2.21 that is causing this issue. Right? On Sun, Aug 5, 2012 at 6:41 PM, Jonathan Nieder wrote: > Jesse Rhodes wrote: > > > Steps a. and c.: Neither 3.3.0-rc6 (from snapshots), nor 3.2.21, nor > 3.2.20 > > reproduced the bug. I'm typing this email from 3.2.21 right now with a > > fully functional wireless connection. > > Thanks, Jesse. I'd suggest using whatever kernel is most convenient > and letting us know whether it's happened again in a few days. > > Do you mind if I forward your reply to the bug log? > > Ciao, > Jonathan >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
copying my message to everyone else manually because gmail ate my CC. Hi there, Steps a. and c.: Neither 3.3.0-rc6 (from snapshots), nor 3.2.21, nor 3.2.20 reproduced the bug. I'm typing this email from 3.2.21 right now with a fully functional wireless connection. I skipped step b. due to not having a bad bisect to refer to. Step d.: 3.2.25+ including the attached patches also failed to reproduce the bug. Not sure where to go from here but I'll keep digging if you point me in the right direction. sney On Sun, Aug 5, 2012 at 2:37 AM, Jonathan Nieder wrote: > tags 681232 + patch moreinfo > quit > > Hi, > > Russ Lind wrote: > > > For what it's worth, the 3.5-1 kernel from experimental works for me > [...] > > I'd also built the 3.4.7 kernel from the sources at kernel.org. > [...] > > I've read about a number of people having this issue thru the 3.3 > > kernels with various distros, and read the issue was supposedly > > fixed in the 3.4 branch. I get the impression it's an upstream > > issue. > > Maybe one of the following patches helped. > > v3.3-rc1~182^2~44^2~292 ath5k: Calibration re-work > > v3.4-rc1~177^2~108^2~108 ath5k: do not stop queues for full >calibration > > v3.4-rc1~177^2~108^2~107 ath5k: do not re-run AGC calibration >periodically > > What seems oddest to me is that I'm not aware of any patches from > the range 3.2.20->3.2.21 that might have had this effect. Are you > sure that 3.2.20 did not reproduce the bug? If you have time to try > one of the following, I'd be interested: > > a. Please test v3.2.20 and v3.2.21 from kernel.org, following > instructions from [1] or the following steps: > > # get the kernel history, if you don't already have it > git clone \ > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > # fetch point releases: > cd linux > git remote add stable \ > git:// > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > git fetch stable > > # configure, build, test: > git checkout v3.2.21 > cp /boot/config-$(uname -r) .config; # current configuration > scripts/config --disable DEBUG_INFO > make localmodconfig; # optional: minimize configuration > make deb-pkg; # optionally with -j for parallel build > dpkg -i ../; # as root > reboot > ... test test test ... > > # hopefully it reproduces the bug, so try the older kernel: > cd linux > git checkout v3.2.20 > make deb-pkg; # maybe with -j4 > dpkg -i ../; # as root > reboot > ... test test test ... > > # hopefully it does not reproduce the bug > > b. If (a) goes well, please bisect to find which patch introduced > the bug, as described at [2]: > > cd linux > git bisect start > git bisect good > git bisect bad v3.2.21 > > # a version halfway between is automatically checked out > make deb-pkg; # maybe with -j4 > dpkg -i ../; # as root > reboot > ... test test test ... > cd linux > git bisect good; # if it works well > git bisect bad; # if it reproduces the calibration timeouts > git bisect skip; # if some other bug makes it hard to test > > ... rinse and repeat until it prints the "first bad commit" > or until bored ... > > # at any step, to see the regression range narrowing > apt-get install gitk > git bisect visualize > > # to get a log of revs tested so far, which will let someone > # else pick up where you left off > git bisect log > > c. How does a pre-compiled 3.3 kernel from http://snapshot.debian.org > do? > > d. Please test the three attached patches together against a 3.2.y > kernel, following the directions at [3] or the following > instructions: > > cd linux > git checkout stable/linux-3.2.y > git am -3sc $(ls -1 /path/to/patches/0[123]-*) > make deb-pkg; # maybe with -j4 > dpkg -i ../; # as root > reboot > ... test test test ... > > Hope that helps, > Jonathan > > [1] > http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package > [2] http://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.2.1 > [3] > http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official >
Bug#681232: linux-image-3.2.0-3-amd64: Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
I have this issue as well, my wireless NIC is: 01:07.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212/AR5213 Wireless Network Adapter [168c:0013] (rev 01) Subsystem: D-Link System Inc AirPlus DWL-G520 Wireless PCI Adapter (rev. B) [1186:3a13] Flags: bus master, medium devsel, latency 168, IRQ 17 Memory at fdef (32-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: ath5k
