From owner-freebsd-mobile@FreeBSD.ORG Fri Jan 2 12:34:30 2004 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7239216A4CE for ; Fri, 2 Jan 2004 12:34:30 -0800 (PST) Received: from opus.bloomcounty.org (opus.bloomcounty.org [64.202.6.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D42C43D60 for ; Fri, 2 Jan 2004 12:34:25 -0800 (PST) (envelope-from t12@bloomcounty.org) Received: by opus.bloomcounty.org (Postfix, from userid 1020) id 38A8669; Fri, 2 Jan 2004 12:34:23 -0800 (PST) Date: Fri, 2 Jan 2004 12:34:23 -0800 From: t12 To: freebsd-mobile@freebsd.org Message-ID: <20040102203423.GA8924@bloomcounty.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: thinkpad t41, acpi + ICH4 woes X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 20:34:30 -0000 I recently got a new thinkpad t41 (23739FU), and have been working on FreeBSD 5.2-RC2. Everything has been excelent, except of course for suspend/resume. In both ACPI and APM suspends, I get a hang on resume. With APM, occasionally it would resume safely. This appears to be a common problem, across multiple fbsd releases. I've been tinkering with that ata driver, which seems to be at least involved with the problems. I'm at an impasse at this point, and am wondering if anyone would like to help, or has input. Here are my findings: with both ACPI and APM, if i suspend in single user mode, resume works fine. in multiuser mode, booted normally it crashes on resume. Notibly the hard drive light stays on during this crash. I cannot escape to the kernel debugger from this state. According to intel's docs on the ICH4-M: (http://www.intel.com/design/mobile/datashts/25233701.pdf section 5.15.2.4) " Native Mode IDE/ACPI S3 Resume Hang Avoidance: System BIOS must clear the interrupt bit (Bit 2) in Bus Master IDE Status Register for BOTH primary and secondary channels prior to passing control to the OS during resume from S3 state (STR). This ensures that the pending IDE interrupt(s) are cleared when the control is passed to the OS. The registers are locked in I/O space via BM_BASE register (Bus 0: Device 31: Register 20- 23h) at offset 02h and offset 0Ah, respectively. Failure to do this may result in system hang when the OS starts executing resume sequence from S3 (STR) under certain conditions. These conditions include a combination of the following: - Only a single channel of IDE is enabled (either Primary or Secondary) - Native IDE Mode capability is reported by the BIOS - OS is capable of dynamically switching from Legacy IDE Mode to Native IDE Mode. A system hang may occur if there exists a pending IDE Interrupt status bit during the legacy IDE Mode to Native IDE mode sequence, the OS software may not clear the IDE interrupt(s), resulting in an apparent hang condition (interrupt storm). " This seems to be about whats happening. Of course I dont really have the ability to change things like that in the BIOS, but I attempted to clear those bits in the ata driver on in ata_resume(). It did't make a difference. I noted that sometimes the interrupt bit is set before I change it, but most of the time it isnt. Another thing I ran across, which could possibly be related: (http://support.microsoft.com/default.aspx?scid=kb;EN-US;323153) " SYMPTOMS A computer with two IDE drives on one cable may stop responding (hang) when the computer resumes from standby. CAUSE The IDE disk driver does not check the busy bit in the drive status before resetting the drive. This creates a problem with computers that use the S3 sleep state for standby. This state cuts power to the drive instead of issuing a sleep command to the drive as in the S2 standby state. This causes the drives to be reset before the drive negotiation is finished when the drives restart. The specification for ATAPI drives calls for checking the busy bit before resetting the drive. The specification also states that the drive ignore resets until the drives are synchronized and ready to operate after negotiation. Some drives that are currently being sold do not do this. This can cause computers with two drives to start with both drives programmed to be the master on the same cable, causing the computer to hang. " Its really not the same situation, but it seemed related enough to include. >From what I can tell, ata_reset() does not check the busy bit before issuing a reset, but does wait for it afterwards. As far as i can tell from kernel debugging attempts, the system hangs immediately after queueing the command to change the master device on ata0 from PIO_MAX to DMA_MAX. A paraphrased trace looks something like: ata_controlcmd() ata_intel_new_setmode() ata_identify_devices() ata_reinit() ata_resume() ... Other related ACPI problems: usb is unhappy on resume. This is also documented in the ICH4-M spec, something about "SE0 during Resume Causes Disconnect". It implies that depneding on OS handling, the device will latently resume or not resume at all. when i acpiconf -s 3, the system actually doesnt really go to sleep. the harddrive spins down, the LCD backlight powers off, the fan spins down, but at the right angle you can tell that the LCD is still displaying text. The sleep light doesnt come on, The dvd drives power light stays on. with APM, the system really goes to sleep. I cant find it this moment, but i ran across something that mentioned that if the AC97 Audio stuff is enabled on shutdown, that the machine will not really enter acpi S3. If i remember right, the document reffered to the ICH4 rather then the ICH4-M, but they seem pretty similar. I've run into and read about a few problems with X11/AGP and APM/ACPI resume, and have run into them occasionally, but i'm trying to tackle the possible ata problems first. It'd be great if anyone has advice on insight into any of this stuff, I have plenty of time to work on this, but i'm running low on knowledge. Feel free to email me for other/further info. Thanks much, -t12