Messages in this thread | | | From | Jani-Matti Hätinen <> | Subject | Re: Lock-up with modprobe sdhci after suspending to ram | Date | Tue, 25 Apr 2006 16:45:57 +0300 |
| |
Pierre Ossman kirjoitti viestissään (lähetysaika tiistai, 25. huhtikuuta 2006 11:42): > Jani-Matti Hätinen wrote: > > Looks like some kind of routing problem. Even pings don't seem to get > > through to mmc.drzeus.cx, or list.drzeus.cx. With http I get a timeout > > from mmc.drzeus.cx. This is from IP 80.221.18.58 > > Most of the domain is down right now (changing ISP). But the mail server > is up at hermes.drzeus.cx:
Ok. That explains it.
> > Unfortunately even text mode is completely speechless about it. The > > modprobe goes through cleanly and I get the regular prompt (with a > > blinking cursor even), but the machine's completely locked up. > > Have you tried pinging it? For some reason the keyboard tends to bail > out when there are outstanding MMC requests. I've only seen this with a > card in the slot though.
Yes, but the thing is deader than the cat I'm sitting on. Even SysRq is dead.
> You could increase the log level sent to console and enable MMC_DEBUG. > If you can find more closely where it hangs I have a better chance of > finding it.
Ok, this is what I get on Loglevel 9. If I try to suspend with the module loaded and with a card in the reader I get: Stopping tasks: ================================| ipw2200: Failed to send CARD_DISABLE: Command timed out ACPI: PCI interrupt for device 0000:01:05.0 disabled sdhci [sdhci_suspend()]: Suspending... MMC: starting cmd 07 arg 00000000 flags 00000000 sdhci [sdhci_send_command()]: Sending cmd (7)
And if I modprobe sdhci after suspend&resume I get the following: First from the modprobe (not all of it is visible): sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff sdhci: Present: 0xffffffff | Host ctl: 0x000000ff sdhci: Power: 0x000000ff | Blk gap: 0x000000ff sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff sdhci: Caps: 0xffffffff | Max curr: 0xffffffff sdhci: =========================================== kobject mmc0: registering. parent: mmc_host, set: class_obj kobject_uevent fill_kobj_path: path = '/class/mmc_host/mmc0' fill_kobj_path: path = '/devices/pci0000:00/0000:00:1e.0/0000:01:03.2' sdhci [sdhci_set_ios()]: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 mmc0: SDHCI at 0xfe8fe000 irq 18 PIO sdhci [sdhci_set_ios()]: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 21 width 0
Plus a prompt and: sdhci [sdhci_set_ios()]: clock 246093Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 sdhci [sdhci_set_ios()]: clock 246093Hz busmode 1 powermode 2 cs 1 Vdd 21 width 0 MMC: starting cmd 00 arg 00000000 flags 00000040 sdhci [sdhci_send_command()]: Sending cmd (0)
Whereas, if I modprobe sdhci in a fresh boot I get: kobject sdhci: registering. parent: <NULL>, set: module kobject_uevent fill_kobj_path: path = '/module/sdhci' sdhci: Secure Digital Host Controller Interface driver, 0.11 sdhci: Copyright(c) Pierre Ossman kobject sdhci: registering. parent: <NULL>, set: drivers kobject_uevent fill_kobj_path: path = '/bus/pci/drivers/sdhci' sdhci [sdhci_probe()]: found at 0000:01:03.2 sdhci [sdhci_probe()]: found 1 slot(s) ACPI: PCI Interrupt 0000:01:03.2[C] -> GSI 20 (level, low) -> IRQ 18 sdhci [sdhci_probe_slot()]: slot 0 at 0xfe8fe000, irq 18 sdhci: ============== REGISTER DUMP ============== sdhci: Sys addr: 0x00000000 | Version: 0x00000200 sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci: Present: 0x01f20000 | Host ctl: 0x00000000 sdhci: Power: 0x00000000 | Blk gap: 0x00000000 sdhci: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci: Timeout: 0x0000000e | Int stat: 0x00000000 sdhci: Int enab: 0xe1ff00cf | Sig enab: 0xe1ff00cf sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci: Caps: 0x018021a1 | Max curr: 0x00000040 kobject mmc0: registering. parent: mmc_host, set: class_obj kobject_uevent fill_kobj_path: path = '/class/mmc_host/mmc0' fill_kobj_path: path = '/devices/pci0000:00/0000:00:1e.0/0000:01:03.2' sdhci [sdhci_set_ios()]: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 mmc0: SDHCI at 0xfe8fe000 irq 18 PIO sdhci [sdhci_set_ios()]: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 21 width 0 sdhci [sdhci_set_ios()]: clock 128906Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 sdhci [sdhci_set_ios()]: clock 128906Hz busmode 1 powermode 2 cs 1 Vdd 21 width 0
Plus a prompt and: MMC: starting cmd 00 arg 00000000 flags 00000040 sdhci [sdhci_tasklet_finish()]: Ending request, cmd (0) MMC: req done (00): 1: 00000000 00000000 00000000 00000000 sdhci [sdhci_set_ios()]: clock 128906Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 MMC: starting cmd 37 arg 00000000 flags 00000015 sdhci [sdhci_tasklet_finish()]: Ending request, cmd (37) MMC: req done (37): 1: 00000000 00000000 00000000 00000000 MMC: starting cmd 37 arg 00000000 flags 00000015 sdhci [sdhci_tasklet_finish()]: Ending request, cmd (37) MMC: req done (37): 1: 00000000 00000000 00000000 00000000 MMC: starting cmd 37 arg 00000000 flags 00000015 sdhci [sdhci_tasklet_finish()]: Ending request, cmd (37) MMC: req done (37): 1: 00000000 00000000 00000000 00000000 MMC: starting cmd 37 arg 00000000 flags 00000015 sdhci [sdhci_tasklet_finish()]: Ending request, cmd (37) MMC: req done (37): 1: 00000000 00000000 00000000 00000000 MMC: starting cmd 01 arg 00000000 flags 00000061 sdhci [sdhci_tasklet_finish()]: Ending request, cmd (1) MMC: req done (01): 1: 00000000 00000000 00000000 00000000 sdhci [sdhci_set_ios()]: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0
So for some reason suspend&resume seems to screw up the registers and double the clock speed. Also I just noticed that if the machine has been through at least one suspend&resume cycle, rebooting no longer works. All processes exit cleanly, but the system just hangs when it should shut down. So it seems quite likely that suspend&resume doesn't really work the way it should in this machine (Asus S5A notebook) and sdhci triggers the problem.
-- Jani-Matti Hätinen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |