Bug#1069082: Confirm bug
(Resending using "plain text mode due to misunderstanding Google settings to accomplish this.) I can confirm that I have experienced this on a Debian Bookworm install but am unable to duplicate it at the moment. The kernel installed is ```text hbarta@sutyzam:~$ uname -a Linux sutyzam 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux hbarta@sutyzam:~$ ``` In addition to the changing MAC, I recall that the device name (presently `enx0050b6239f84`) was also changing. That seems to make sense as the device name was derived from the MAC address `00:50:b6:23:9f:84`. I was able to work around this using a .link file in `/etc/systemd/network` and matching on the driver, reported by `ethtool` as: ```text root@sutyzam:~# ethtool -i enx0050b6239f84 driver: ax88179_178a version: 6.1.0-18-amd64 firmware-version: expansion-rom-version: bus-info: 2-1.3:1.0 supports-statistics: no supports-test: no supports-eeprom-access: yes supports-register-dump: no supports-priv-flags: no root@sutyzam:~# ``` `lsusb` reports it as ```text root@sutyzam:~# ethtool -i enx0050b6239f84 driver: ax88179_178a version: 6.1.0-18-amd64 firmware-version: expansion-rom-version: bus-info: 2-1.3:1.0 supports-statistics: no supports-test: no supports-eeprom-access: yes supports-register-dump: no supports-priv-flags: no root@sutyzam:~# ``` And this is the "Amazon Basics" USB3/1Gb adapter. best, -- Beautiful Sunny Winfield
Bug#1069082: Confirm bug
I can confirm that I have experienced this on a Debian Bookworm install but am unable to duplicate it at the moment. The kernel installed is ```text hbarta@sutyzam:~$ uname -a Linux sutyzam 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux hbarta@sutyzam:~$ ``` In addition to the changing MAC, I recall that the device name (presently `enx0050b6239f84`) was also changing. That seems to make sense as the device name was derived from the MAC address `00:50:b6:23:9f:84`. I was able to work around this using a .link file in `/etc/systemd/network` and matching on the driver, reported by `ethtool` as: ```text root@sutyzam:~# ethtool -i enx0050b6239f84 driver: ax88179_178a version: 6.1.0-18-amd64 firmware-version: expansion-rom-version: bus-info: 2-1.3:1.0 supports-statistics: no supports-test: no supports-eeprom-access: yes supports-register-dump: no supports-priv-flags: no root@sutyzam:~# ``` `lsusb` reports it as ```text root@sutyzam:~# ethtool -i enx0050b6239f84 driver: ax88179_178a version: 6.1.0-18-amd64 firmware-version: expansion-rom-version: bus-info: 2-1.3:1.0 supports-statistics: no supports-test: no supports-eeprom-access: yes supports-register-dump: no supports-priv-flags: no root@sutyzam:~# ``` And this is the "Amazon Basics" USB3/1Gb adapter. best, -- Beautiful Sunny Winfield
Bug#1019700: testing with 6.1 kernel
On Wed, Dec 7, 2022 at 8:34 PM Hank Barta wrote: > I tested with the 6.1 kernel from testing. > The kernel was from experimental, not testing. Apologies for the error. -- Beautiful Sunny Winfield
Bug#1019700: testing with 6.1 kernel
I tested with the 6.1 kernel from testing. hbarta@boson:~$ uname -a Linux boson 6.1.0-0-arm64 #1 SMP Debian 6.1~rc7-1~exp1 (2022-12-01) aarch64 GNU/Linux hbarta@boson:~$ The problem seems to be worse. It manifests with every cold boot (4 tries.) I was only able to test one warm boot immediately following installation of 6.1 (and shutting down 6.0) and the issue manifested then also. I was unable to further test warm boot because the system never completed shutdown even after waiting 10 minutes. Inserting an SD card got the following message (from dmesg) [ 46.858495] mmc1: new high speed SDIO card at address 0001 That message was followed by a single block from the timeout message referencing mmc1 and which seemed not to be repeated. The /dev/ entry for the SD card was never created. Update: While composing this message it did complete a shutdown and reboot. Unfortunately the SD card was (sort of) bootable and the system tried to boot from it and hung, forcing a power cycle and cold boot. On this subsequent cold boot the timeout did not manifest. A subsequent warm boot also did not manifest. The third warm boot *did* manifest the timeout. best, -- Beautiful Sunny Winfield
Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
Hi Diederik, This may not be the same bug. The one you referenced was provoked when the SD card slot was empty and could be suppressed by putting a card in the slot. Also that bug was fixed and the work around was no longer necessary. The one I experienced could happen with the SD card in place and at various times, the SD card would be recognized or would not be recognized (when a card was in place and the timeout was reported.) Let me clarify the situations I encountered while testing. Again, I performed testing while booting from a USB connected SSD. * Normal boot, no timeout reported and SD card recognized. * Timeout reported following boot and SD card recognized and working. * Timeout reported and SD card not recognized. Repeating the boot process could result in any of the three conditions and it did not seem to matter if a warm or cold boot was involved. I have updated my test install to the 6.0 kernel, identified as hbarta@boson:~$ uname -a Linux boson 6.0.0-5-arm64 #1 SMP Debian 6.0.10-1 (2022-11-26) aarch64 GNU/Linux hbarta@boson:~$ I rebooted and power cycled several times and was ready to declare this fixed, but the most recent reboot is den=monstrating the issue - e.g. MMC timeouts and no SD card in /dev. I inserted an SD card in the slot and the timeout messages are continuing after the card is initialized. [ 274.788978] mmc1: new ultra high speed DDR50 SDHC card at address [ 274.805432] mmcblk1: mmc1: SL16G 14.8 GiB [ 274.837154] mmcblk1: p1 p2 [ 281.828861] mmc0: Timeout waiting for hardware cmd interrupt. [ 281.836160] mmc0: sdhci: SDHCI REGISTER DUMP === [ 281.844122] mmc0: sdhci: Sys addr: 0x | Version: 0x9902 [ 281.852082] mmc0: sdhci: Blk size: 0x | Blk cnt: 0x [ 281.860026] mmc0: sdhci: Argument: 0x0c00 | Trn mode: 0x [ 281.867973] mmc0: sdhci: Present: 0x01ff0001 | Host ctl: 0x0001 [ 281.875905] mmc0: sdhci: Power: 0x000f | Blk gap: 0x [ 281.883839] mmc0: sdhci: Wake-up: 0x | Clock:0x7187 [ 281.891779] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 [ 281.899716] mmc0: sdhci: Int enab: 0x00ff0003 | Sig enab: 0x00ff0003 [ 281.907658] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 [ 281.915602] mmc0: sdhci: Caps: 0x | Caps_1: 0x [ 281.923543] mmc0: sdhci: Cmd: 0x341a | Max curr: 0x0001 [ 281.931481] mmc0: sdhci: Resp[0]: 0x | Resp[1]: 0x [ 281.939414] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 281.947338] mmc0: sdhci: Host ctl2: 0x [ 281.953232] mmc0: sdhci: I'm not sure if this matters, but when the timeouts are reported, orderly shutdown takes several minutes longer than normal but eventually completes. best, On Tue, Dec 6, 2022 at 6:10 PM Diederik de Haas wrote: > Control: tag -1 moreinfo > > Hi Hank, > > On Tuesday, 13 September 2022 17:48:22 CET Hank Barta wrote: > > Package: src:linux > > Version: 5.19.6-1 > > > >* What led up to the situation? > > > > Apparent inability to initialize/connect to the SD card H/W. This leads > to > > the message below that is repeated about every 10s. It can manifest three > > ways. > > > > 1. Failure to boot - continuous retries to read SD card. > > 2. If a USB SSD is connected, it can skip the SD card and boot from the > SATA > > SSD. (That is the coneition as I prepare this report.) > > 3. Completes boot, message repeats and there are no /dev/mmc* entries and > > WiFi H/W is not recognozed. > > 4. Completes boot, messages are repeated but /dev/mmc entries are present > > and can mount/read an SD card. And WiFi appears to be working > > 5. Completes boot, no SD card timeout messages are reported and system > > operates normally. > > > > ** Kernel log: > > [ 723.735217] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 > > [ 723.741743] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 > > [ 723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 > > [ 723.754797] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 > > [ 723.761324] mmc0: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 > > [ 723.767851] mmc0: sdhci: Resp[0]: 0x01aa | Resp[1]: 0x > > [ 723.774379] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x > > [ 723.780905] mmc0: sdhci: Host ctl2: 0x > > [ 723.785404] mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x > > [ 723.791930] mmc0: sdhci: > > [ 733.923993] mmc0: Timeout waiting for hardware cmd interrupt. > > [ 733.929837] mmc0: sdhci: SDHCI REGISTER DUMP === >
Bug#1019700: Info received (Fwd: Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.)
I've gone through "git bisect" on the repo and results are at https://paste.debian.net/1254605/ Each candidate was tested with 6 reboots (including 3 that involved power cycling.) There were four stages that did not build and at which I executed 'git bisect skip' to get a buildable candidate. They are listed in the paste linked above. I have notes on the build errors if that would be useful. -- Beautiful Sunny Winfield
Bug#1019700: Fwd: Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
-- Forwarded message - From: Hank Barta Date: Tue, Sep 13, 2022 at 12:54 PM Subject: Re: Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt. To: Bjørn Mork Hi Bjørn, Many thanks for the prompt reply. In the mean time I have done the following: * Reimaged my SD card with `20220808_raspi_4_bookworm.img.xz` from Debian Tested images. (5.18.14-1 kernel) * Booted and noted *no* SD card timeouts. Rebooted and power cycled 3 times each with the same result. * Performed `apt update && apt upgrade -y` and rebooted. (5.19.6-1 kernel) * First boot - repeated SD timeouts and unable to log in. Power cycled to force reboot * Second reboot - no SD card timeouts. Added `dtparam=sd_poll_once=on` to `/boot/firmware/config.txt` * Third boot - repeated SD card timeouts. Evetually I was able to log in to the console. Network is not fully up. The repeated SD timeouts seem to be slowing normal boot. Actually I may not have been logged in but in the console that presents when there is a problem booting. I exited and now I see a login prompt. And Ethernet finally came up. 737 seconds post boot according to console messages. (It was some time later before I could ssh in.) The SD timeout messages stopped. I have a login prompt at the console but it takes about 30s to login. The system is now responsive, but WiFi modules did not load. I count 52 timeout messages in dmesg output. There is no response to at the console. Tried to shutdown using `shutdown -r now` and the system hangs. The system is most certainly not operating normally. Does Debian use the device tree? This is a Debian system, not R-Pi OS. If I reboot enough times I will get a clean boot followed by normal operation. I have tried different SD cards, USB SSDs and Pi 4Bs all with the same result so I do not believe this is a H/W problem. I do recall the previous SD timeout issue and I worked around that by inserting an SD card post boot but that no longer works. This seems to be a new problem. best, hank On Tue, Sep 13, 2022 at 11:32 AM Bjørn Mork wrote: > Hank Barta writes: > > > ** Kernel log: > > [ 723.735217] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 > > [ 723.741743] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 > > [ 723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 > > [ 723.754797] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 > > [ 723.761324] mmc0: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 > > [ 723.767851] mmc0: sdhci: Resp[0]: 0x01aa | Resp[1]: 0x > > [ 723.774379] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x > > [ 723.780905] mmc0: sdhci: Host ctl2: 0x > > [ 723.785404] mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x > > [ 723.791930] mmc0: sdhci: > > [ 733.923993] mmc0: Timeout waiting for hardware cmd interrupt. > > These repeated messages are normal on the RPi4 if you boot it without an > SD card. E.g. from USB or network. If that's what you intend to do, > then you can avoid the repeated messages by adding > > dtparam=sd_poll_once=on > > to the config.txt file in your firmware partition. Often mounted as > /boot/firmware/. > > The effect depends on which device-tree you are using. I believe it > will only work with the ones coming with the Raspberry Pi firmware. See > > https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README > > for docs. > > > Bjørn > -- Beautiful Sunny Winfield -- Beautiful Sunny Winfield
Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
Behavior not seen before - panic during boot. https://photos.app.goo.gl/txcEsUCJuqMGmK1K6 -- Beautiful Sunny Winfield
Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
Package: src:linux Version: 5.19.6-1 Severity: important X-Debbugs-Cc: hba...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Apparent inability to initialize/connect to the SD card H/W. This leads to the message below that is repeated about every 10s. It can manifest three ways. 1. Failure to boot - continuous retries to read SD card. 2. If a USB SSD is connected, it can skip the SD card and boot from the SATA SSD. (That is the coneition as I prepare this report.) 3. Completes boot, message repeats and there are no /dev/mmc* entries and WiFi H/W is not recognozed. 4. Completes boot, messages are repeated but /dev/mmc entries are present and can mount/read an SD card. And WiFi appears to be working 5. Completes boot, no SD card timeout messages are reported and system operates normally. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? I build kernel 5.19.8 and found the same problem behavior. I booted a different SSD with Bullseye installed and on 5.10.0 kernel and do not see this issue. (Likely unrelated - The 5.10 and 5.19.0 kernels had a lot of vc4 related errors that seem to be fixed in 5.19.8) Additional information: The 5.19.8 kernel was built with the options found at https://github.com/HankB/Debian-Arm64-kernel-for-Pi-4B-on-X86_64 I have saved dmesg output from a normal boot and a boot that exhibted the timeout (but was otherwise able to complete booting) in paste.dmesg.net Normal - https://paste.debian.net/1253718/ Timeout - https://paste.debian.net/1253719/ Since the kernel log below doesn't include the information at the beginning of `dmesg` I will capture again. Or I won't. It already overflowed the dmesg buffer. If needed for this kernel I can dupicate the situation and capture before it overflows. -- Package-specific info: ** Version: Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-09-01) ** Command line: video=HDMI-A-1:1600x1200M@60 dma.dmachans=0x37f5 bcm2709.boardrev=0xc03111 bcm2709.serial=0x44557cae bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:09:C6:71 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait ** Tainted: WC (1536) * kernel issued warning * staging driver was loaded ** Kernel log: [ 723.735217] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 [ 723.741743] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 [ 723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 [ 723.754797] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 [ 723.761324] mmc0: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 [ 723.767851] mmc0: sdhci: Resp[0]: 0x01aa | Resp[1]: 0x [ 723.774379] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 723.780905] mmc0: sdhci: Host ctl2: 0x [ 723.785404] mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x [ 723.791930] mmc0: sdhci: [ 733.923993] mmc0: Timeout waiting for hardware cmd interrupt. [ 733.929837] mmc0: sdhci: SDHCI REGISTER DUMP === [ 733.936364] mmc0: sdhci: Sys addr: 0x | Version: 0x1002 [ 733.942892] mmc0: sdhci: Blk size: 0x | Blk cnt: 0x [ 733.949420] mmc0: sdhci: Argument: 0x | Trn mode: 0x [ 733.955946] mmc0: sdhci: Present: 0x1fff | Host ctl: 0x0001 [ 733.962473] mmc0: sdhci: Power: 0x000f | Blk gap: 0x0080 [ 733.969001] mmc0: sdhci: Wake-up: 0x | Clock:0xfa07 [ 733.975528] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 [ 733.982055] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 [ 733.988582] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 [ 733.995109] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 [ 734.001636] mmc0: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 [ 734.008163] mmc0: sdhci: Resp[0]: 0x01aa | Resp[1]: 0x [ 734.014689] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 734.021216] mmc0: sdhci: Host ctl2: 0x [ 734.025716] mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x [ 734.032242] mmc0: sdhci: [ 744.164283] mmc0: Timeout waiting for hardware cmd interrupt. [ 744.170128] mmc0: sdhci: SDHCI REGISTER DUMP === [ 744.176655] mmc0: sdhci: Sys addr: 0x | Version: 0x1002 [ 744.183183] mmc0: sdhci: Blk size: 0x | Blk cnt: 0x [ 744.189711] mmc0:
