Lock-up with modprobe sdhci after suspending to ram

Lock-up with modprobe sdhci after suspending to ram

[Jani-Matti Hätinen]

        Hello,

For some reason I haven't been able to access sdhci-devel at drzeus.cx
for a week now, so sending this here.

I get a hard lock-up every single time, if I do modprobe sdhci after
waking up from suspend-to-ram. If I compile the module into the kernel
(or if I don't rmmod it before suspending), I get a lock-up either
when going to suspend (if there's a card in the reader) or during
resume (if the reader is empty). With a fresh boot-up the driver works
just fine. The problem occurs only after the machine has been
suspended at least once.
  I've tested this with 2.6.15-gentoo-r1 with the sdhci-0.11 patches
and vanilla 2.6.17-rc2. Sadly nothing gets as far as to the log when
the lock-up occurs.

--------------------------------------------

00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express Processor to DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile
915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML
Express Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) High Definition Audio Controller (rev 04)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #1 (rev 04)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #2 (rev 04)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #3 (rev 04)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #4 (rev 04)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface
Bridge (rev 04)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) IDE Controller (rev 04)
01:03.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3)
01:03.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08)
01:03.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host
Adapter (rev 17)
01:03.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host
Adapter (rev 08)
01:03.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 03)
01:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:05.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)


CONFIG_X86_32=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_SYSCTL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_KALLSYMS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
CONFIG_X86_PC=y
CONFIG_MPENTIUMM=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_NOHIGHMEM=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_MTRR=y
CONFIG_SECCOMP=y
CONFIG_HZ_250=y
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_HOTKEY=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=m
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_ISA_DMA_API=y
CONFIG_PCCARD=m
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_CARDBUS=y
CONFIG_YENTA=m
CONFIG_PCCARD_NONSTATIC=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_FIB_HASH=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_BIC=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_DCCP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_MATCH_STRING=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_TARGET_NFQUEUE=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_TARGET_TTL=y
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_PNP=y
CONFIG_PNPACPI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=m
CONFIG_BLK_DEV_SR=m
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_QLA2XXX=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_BLK_DEV_DM_BBR=y
CONFIG_IEEE1394=y
CONFIG_IEEE1394_OHCI1394=m
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_NET_RADIO=y
CONFIG_NET_WIRELESS=y
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_GAMEPORT=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_RTC=y
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_I915=y
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_HWMON=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_VESA=y
CONFIG_FB_VESA_TNG=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONTS=y
CONFIG_FONT_8x16=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_DEVICE=y
CONFIG_FB_SPLASH=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_HDA_INTEL=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=y
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_MMC=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_SDHCI=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=m
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_FS_POSIX_ACL=y
CONFIG_INOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_NTFS_FS=m
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
CONFIG_CIFS_STATS2=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_CIFS_EXPERIMENTAL=y
CONFIG_CIFS_UPCALL=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_UTF8=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y

Re: Lock-up with modprobe sdhci after suspending to ram

[Pierre Ossman]

Jani-Matti Hätinen wrote:
>         Hello,
> 
> For some reason I haven't been able to access sdhci-devel at drzeus.cx
> for a week now, so sending this here.
> 

I see nothing in the logs from you so I suspect it's in your end. Other
mail coming from pproxy.gmail.com (which is where you seem to be coming
from) are coming through fine.

> I get a hard lock-up every single time, if I do modprobe sdhci after
> waking up from suspend-to-ram. If I compile the module into the kernel
> (or if I don't rmmod it before suspending), I get a lock-up either
> when going to suspend (if there's a card in the reader) or during
> resume (if the reader is empty). With a fresh boot-up the driver works
> just fine. The problem occurs only after the machine has been
> suspended at least once.
>   I've tested this with 2.6.15-gentoo-r1 with the sdhci-0.11 patches
> and vanilla 2.6.17-rc2. Sadly nothing gets as far as to the log when
> the lock-up occurs.

The kernel will not write anything to disk once a panic has occurred. To
see what's going wrong need to be in text mode (framebuffer is not
sufficient) when you do the modprobe.

Rgds
Pierre

Re: Lock-up with modprobe sdhci after suspending to ram

[Jani-Matti Hätinen]

Pierre Ossman kirjoitti viestissään (lähetysaika maanantai, 24. huhtikuuta 
2006 15:29):
> Jani-Matti Hätinen wrote:
> >         Hello,
> >
> > For some reason I haven't been able to access sdhci-devel at drzeus.cx
> > for a week now, so sending this here.
>
> I see nothing in the logs from you so I suspect it's in your end. Other
> mail coming from pproxy.gmail.com (which is where you seem to be coming
> from) are coming through fine.

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

jannu@lassi ~ $ ping mmc.drzeus.cx
PING gateway.drzeus.cx (85.8.13.51) 56(84) bytes of data.

--- gateway.drzeus.cx ping statistics ---
202 packets transmitted, 0 received, 100% packet loss, time 201694ms

jannu@lassi ~ $ ping list.drzeus.cx
PING list.drzeus.cx (193.12.253.7) 56(84) bytes of data.

--- list.drzeus.cx ping statistics ---
2226 packets transmitted, 0 received, 100% packet loss, time 2231122ms

> > I get a hard lock-up every single time, if I do modprobe sdhci after
> > waking up from suspend-to-ram. If I compile the module into the kernel
> > (or if I don't rmmod it before suspending), I get a lock-up either
> > when going to suspend (if there's a card in the reader) or during
> > resume (if the reader is empty). With a fresh boot-up the driver works
> > just fine. The problem occurs only after the machine has been
> > suspended at least once.
> >   I've tested this with 2.6.15-gentoo-r1 with the sdhci-0.11 patches
> > and vanilla 2.6.17-rc2. Sadly nothing gets as far as to the log when
> > the lock-up occurs.
>
> The kernel will not write anything to disk once a panic has occurred. To
> see what's going wrong need to be in text mode (framebuffer is not
> sufficient) when you do the modprobe.

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.

-- 
Jani-Matti Hätinen

Re: Lock-up with modprobe sdhci after suspending to ram

[Pierre Ossman]

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:

drzeus.cx.              86393   IN      MX      10 mail.drzeus.cx.
list.drzeus.cx.         86400   IN      MX      10 mail.drzeus.cx.
mail.drzeus.cx.         84586   IN      A       193.12.253.7
hermes.drzeus.cx.       83892   IN      A       193.12.253.7

> 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.

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.

Rgds
Pierre

Re: Lock-up with modprobe sdhci after suspending to ram

[Jani-Matti Hätinen]

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

Re: Lock-up with modprobe sdhci after suspending to ram

[Pierre Ossman]

Jani-Matti Hätinen wrote:
>
> 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: ===========================================
>   

Now this is horribly broken and would explain why things go south. I
guess the chip needs a reset early in the detection sequence to function
properly. Try putting:

    sdhci_reset(host, SDHCI_RESET_ALL);

just before the driver does a readl() on the capabilities register (in
sdhci_probe_slot()).

>   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.
>   

That's just probably a broken ACPI. Laptops tend to be buggy as hell.
File a report with the ACPI guys.

Rgds
Pierre

Re: Lock-up with modprobe sdhci after suspending to ram

[Jani-Matti Hätinen]

Pierre Ossman kirjoitti viestissään (lähetysaika lauantai, 29. huhtikuuta 2006 
18:25):
> Jani-Matti Hätinen wrote:
> > Ok, this is what I get on Loglevel 9.
> > 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: ===========================================
>
> Now this is horribly broken and would explain why things go south. I
> guess the chip needs a reset early in the detection sequence to function
> properly. Try putting:
>
>     sdhci_reset(host, SDHCI_RESET_ALL);
>
> just before the driver does a readl() on the capabilities register (in
> sdhci_probe_slot()).

Sorry for the delay.
  I tried that with 2.6.17-rc3, but it doesn't seem to have any effect. The 
register values stay the same.

> >   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.
>
> That's just probably a broken ACPI. Laptops tend to be buggy as hell.
> File a report with the ACPI guys.

I'm not sure if this has any effect on the sdhci issue, but during a normal 
suspend&resume (i.e. when sdhci has been rmmoded earlier) I get the following 
error about the PCMCIA CardBus slot, which is on the same PCI channel as the 
card reader (01:03.0 and 01:03.2 respectively):

May  4 09:37:38 leevi PCMCIA: socket c14d8828: *** DANGER *** unable to remove 
socket power

And the PCMCIA slot doesn't work either after a suspend&resume. I haven't 
tested FireWire yet (which is also on the same PCI channel 01:03.1), but I 
will shortly.

-- 
Jani-Matti Hätinen

Re: Lock-up with modprobe sdhci after suspending to ram

[Pierre Ossman]

Jani-Matti Hätinen wrote:
> I'm not sure if this has any effect on the sdhci issue, but during a normal 
> suspend&resume (i.e. when sdhci has been rmmoded earlier) I get the following 
> error about the PCMCIA CardBus slot, which is on the same PCI channel as the 
> card reader (01:03.0 and 01:03.2 respectively):
>
> May  4 09:37:38 leevi PCMCIA: socket c14d8828: *** DANGER *** unable to remove 
> socket power
>
> And the PCMCIA slot doesn't work either after a suspend&resume. I haven't 
> tested FireWire yet (which is also on the same PCI channel 01:03.1), but I 
> will shortly.
>
>   

Sounds like there is something fundamentally broken with your suspend.
It seems like we should hold off on the card reader until the more basic
stuff, like the cardbus slot, works properly after resume.

Rgds
Pierre

Re: Lock-up with modprobe sdhci after suspending to ram

[Pekka Enberg]

Hi Jani,

On 4/24/06, Jani-Matti Hätinen <jani-matti.hatinen@iki.fi> wrote:
>   I've tested this with 2.6.15-gentoo-r1 with the sdhci-0.11 patches
> and vanilla 2.6.17-rc2. Sadly nothing gets as far as to the log when
> the lock-up occurs.

If this is a regression from an earlier version, you could try git
bisect to isolate the broken changeset. See the following URL for more
details:

  http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt.

                                              Pekka

Re: Lock-up with modprobe sdhci after suspending to ram

[Jani-Matti Hätinen]

Pekka Enberg kirjoitti viestissään (lähetysaika tiistai, 25. huhtikuuta 2006 
13:12):
> Hi Jani,
>
> On 4/24/06, Jani-Matti Hätinen <jani-matti.hatinen@iki.fi> wrote:
> >   I've tested this with 2.6.15-gentoo-r1 with the sdhci-0.11 patches
> > and vanilla 2.6.17-rc2. Sadly nothing gets as far as to the log when
> > the lock-up occurs.
>
> If this is a regression from an earlier version, you could try git
> bisect to isolate the broken changeset. See the following URL for more
> details:
>
> http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bis
>ect.txt.

AFAIK the sdhci driver in 2.6.17-rc2 is effectively the same as the sdhci-0.11 
patches I used with 2.6.15-gentoo-r1. I haven't tested this with earlier 
versions of the driver, but I will as soon as mmc.drzeus.cx comes back 
online.
  Thanks for the link.

-- 
Jani-Matti Hätinen