From owner-freebsd-hackers Tue Aug 11 16:02:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23210 for freebsd-hackers-outgoing; Tue, 11 Aug 1998 16:02:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA23180 for ; Tue, 11 Aug 1998 16:02:12 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id TAA25098 for hackers@freebsd.org; Tue, 11 Aug 1998 19:04:58 -0400 From: Bill Paul Message-Id: <199808112304.TAA25098@skynet.ctr.columbia.edu> Subject: PCI BIOSes and power management To: hackers@FreeBSD.ORG Date: Tue, 11 Aug 1998 19:04:57 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a question which I'm somebody familiar with PCI issues might be able to answer. I recently ran into an unusual problem with the 3c905B driver. The 905B (unlike the 905) supports power management. There's a 'CapID' register in the PCI register space of the 3c905B ASIC which indicates that the device supports power manament, and there are also Power Management Control and Power Management Status registers. The 3c905B supports a couple of different power states: D0 'full power' mode; normal NIC operating mode D1 'light sleep' mode D2 Partial power down (still responds to PCI config accesses) D3(hot) Full power down state (loses PCI config info) D3(cold) Power off state (i.e. card unplugged or system turned off) When the NIC is in the D3(hot) state, it loses all of its PCI configuration settings except the value of the power state register. The NIC responds to PCI configuration accesses so that the power mode can be changed back to D0 for normal operation. My understanding is that the PCI BIOS is supposed to set the device back to the D0 state prior to configuring it. Normally I wouldn't care about this, however the Lose95/98/NT 3c905B drivers appear to place the NIC in the D3(hot) state during shutdown. This can cause the following sequence of events: - User has a dual-boot system with Lose95/98/NT and FreeBSD installed. - User boots Lose95/98/NT and fiddles for a while. - User gets tired of listening to disk thrash and selects 'Shutdown and restart' from the Shutdown menu. - Lose95/98/NT places 3c905B NIC in D3(hot) power down state. - Machine warm boots. - PCI BIOS goes out and starts configuring PCI devices. - PCI BIOS, apparently not being clever enough to know how to deal with power management capable devices, fails to set the NIC back to the D0 state. - PCI BIOS tries to configure adapter but fails because the NIC doesn't preserve PCI config data in the D3(hot) state. - System finishes its startup regimen, brings up boot mangler prompt. - User selects FreeBSD, kernel loads and probes for devices. - XL driver detects a card, but pukes with the following error: xl0 <3Com 3c905B Fast Etherlink XL 10/100BaseTX> rev 36 int a irq 10 on pci0:9:0 mapreg[10] type=1 addr=0000d400 size=0080. mapreg[14] type=0 addr=e6000000 size=0080. xl0: chip is in D3 power mode -- setting to D0 int line register not set by bios xl0: couldn't map interrupt The 'setting to D0' message comes from the driver trying to set the card back to a usable state, which it can do, however it's still not properly configured. Now that the chip is back in the D0 state, warm booting again will allow the PCI BIOS to correctly configure the NIC. Cold booting the system would also fix the problem. My question is: is it possible to get the card programmed correctly during the attach routine, and if so, how? I don't see any way to get the BIOS to reconfigure the device once the OS is running, and I don't think the driver is supposed to do it. Does anybody know the correct way to deal with this? It's a minor problem as long as you don't mind cold starting your machine after running an M$ operating system, or if you don't run one to begin with, but I'd like to find a way to solve this if possible. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message