Re: MMCCAM hang
- Reply: Bjoern A. Zeeb: "Re: MMCCAM hang"
- In reply to: Søren_Schmidt : "Re: MMCCAM hang"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 09 Jan 2024 10:48:22 UTC
On Tue, 9 Jan 2024 11:36:32 +0100 Søren Schmidt <soren.schmidt@gmail.com> wrote: > > On 28 Dec 2023, at 02.08, Warner Losh <imp@bsdimp.com> wrote: > > On Wed, Dec 27, 2023, 4:55?PM Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net <mailto:bzeeb-lists@lists.zabbadoz.net>> wrote: > >> Hi, > >> > >> sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base 700000000 prescale 1 divisor 14 > >> GEOM: new disk sdda0 > >> sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0 > >> sdda0: Relative addr: 00000002 > >> Card features: <MMC Memory High-Capacity> > >> Card random: unblocking device. > >> GEOM: new disk sdda0boot0 > >> memory OCR: 00ff8080 > >> sdda0: Serial Number ....... > >> sdda0: MMCHC .................................. by 17 0x0000 > >> GEOM: new disk sdda0boot1 > >> uhub0: 2 ports with 2 removable, self powered > >> > >> at which point basically anything hangs. In auto-boot it is > >> before/during file-system checks. > >> In single user mode camcontrol devlist will show sdda0 > >> but > >> > >> root@:/ # gpart show sdda0 > >> load: 6.06 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% 2088k > >> {forever} > >> > >> > >> Unclear at which point I broke to debugger and this is where it seems to > >> hang: > >> > >> db> trace 100088 > >> Tracing pid 4 tid 100088 td 0xffff0000dc527000 > >> ipi_stop() at ipi_stop+0x34 > >> arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 > >> intr_irq_handler() at intr_irq_handler+0x80 > >> handle_el1h_irq() at handle_el1h_irq+0x14 > >> --- interrupt > >> spinlock_exit() at spinlock_exit+0x44 > >> callout_reset_sbt_on() at callout_reset_sbt_on+0x210 > >> sdhci_cam_action() at sdhci_cam_action+0x284 > >> xpt_run_devq() at xpt_run_devq+0x4c8 > >> xpt_action_default() at xpt_action_default+0x470 > >> sddastart() at sddastart+0x1bc > >> xpt_run_allocq() at xpt_run_allocq+0xa8 > >> xpt_done_process() at xpt_done_process+0x610 > >> xpt_done_td() at xpt_done_td+0x1a8 > >> fork_exit() at fork_exit+0x8c > >> fork_trampoline() at fork_trampoline+0x18 > >> > >> > >> Anyone an idea? > > > > > > > > Looks like deadlock with another thread. Anybody else in the time keeping / callout code? > > I think this is related to the MMC driver having issues (MMCCAM or not). > If I try to use a MMC sdcard on any of my rk35X8 boards as the disk device it will eventually hang on first access to the MMC controlled media. > I thought I had an issue here with my dev setup but clealy I'm not alone :) SDCard on RK356X don't use sdhci but dwmmc so it's not related to what bz@ is seeing. That being said I have no problem using dwmmc as the root device on my nanopi r5s or quartz64. -- Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>