From owner-freebsd-bugs Mon Oct 8 18:50: 9 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E07B037B406 for ; Mon, 8 Oct 2001 18:50:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f991o0h41592; Mon, 8 Oct 2001 18:50:00 -0700 (PDT) (envelope-from gnats) Received: from CRWdog.demon.co.uk (adsl-216-103-105-71.dsl.snfc21.pacbell.net [216.103.105.71]) by hub.freebsd.org (Postfix) with ESMTP id 579D537B405 for ; Mon, 8 Oct 2001 18:48:46 -0700 (PDT) Received: by CRWdog.demon.co.uk (Postfix, from userid 1001) id 2A7393E94; Mon, 8 Oct 2001 18:48:40 -0700 (PDT) Message-Id: <20011009014840.2A7393E94@CRWdog.demon.co.uk> Date: Mon, 8 Oct 2001 18:48:40 -0700 (PDT) From: Andy Sparrow Reply-To: Andy Sparrow To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.113 Subject: kern/31149: New Intel disk controller chip ID 0x248a Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 31149 >Category: kern >Synopsis: New Intel disk controller chip ID 0x248a >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Oct 08 18:50:00 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Andy Sparrow >Release: FreeBSD 4.4-STABLE i386 >Organization: None >Environment: System: FreeBSD omni.geek4food.org 4.4-STABLE FreeBSD 4.4-STABLE #64: Sat Oct 6 17:16:06 CDT 2001 root@omni.geek4food.org:/usr/src/sys/compile/tureg i386 >Description: The (fairly new) HP Omnibook 6100 has an Intel UltraATA controller chip probed as vendor=0x8086 id=0x248a, which isn't included in the files 'ata-all.c' & 'ata-dma.c'. This causes it to get attached as a "Generic PCI ATA controller". Unfortunately, when attached thus, this device will subsequently fail to resume after a suspend: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices . ata0: mask=01 ostat0-58 ostat2=00 ata0-master: ATAPI probe a=bd b=00 ata0-slave: ATAPI probe a=bd b=00 ata0: mask=01 status0=58 status1=58 ata0-master: ATA probe a=00 b=00 ata0: devices=00 done ad0s2a: hard error reading fsbn 51472 of 3056-3059 (ad0s2 bn 51472; cn 3 tn 97 sn 1) ata0-master: success setting PIO4 on generic chip ad0s2a: hard error reading fsbn 51472 of 3056-3059 (ad0s2 bn 51472; cn 3 tn 97 sn 1) status=51 error=04 ad0: DMA problem fallback to PIO mode spec_getpages:(#ad/0x30000) I/O read failure: (error=5) bp 0xc64b12d4 vp 0xcc045ec0 size: 2048, resid: 2048, a_count: 1891, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 1 pcic0: Event mask 0x9 stat 0x30000459 the drive is then completely dead, and you have to resort to the paperclip to reboot (because you can't load halt & friends)... >How-To-Repeat: Acquire an Omnibook 6100 (or other laptop with same chipset), install 4.4-STABLE, set up APM, suspend/resume. :) >Fix: Couldn't find any docs on Intel's web site, although chip id was listed on the PCI/Vendor device lists found at http://www.yourvote.com/pci (0where it is simply described as an "Intel UltraDMA controller"). I guessed that it was similar to the comparitively-recent ICH2 Mobile chipset (which also does UltraATA and seems to have similar capabilities), and duly applied the following trivial patch: --- sys/dev/ata/ata-all.c.orig Mon Oct 8 18:13:29 2001 +++ sys/dev/ata/ata-all.c Mon Oct 8 18:12:57 2001 @@ -261,6 +261,9 @@ case 0x24218086: return "Intel ICH0 ATA33 controller"; + case 0x248a8086: + return "Intel UltraATA controller"; + case 0x24118086: return "Intel ICH ATA66 controller"; --- sys/dev/ata/ata-dma.c.orig Mon Oct 8 18:13:45 2001 +++ sys/dev/ata/ata-dma.c Mon Oct 8 18:13:04 2001 @@ -111,6 +111,7 @@ switch (scp->chiptype) { + case 0x248a8086: /* Intel UltraATA mobile */ case 0x244a8086: /* Intel ICH2 mobile */ case 0x244b8086: /* Intel ICH2 */ if (udmamode >= 5) { Which works for me. Machine runs at least as well as before ('dmesg' now reports the drive as using UDMA100, rather than BIOSDMA), and the laptop now correctly resumes post-suspend. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message