Date: Wed, 12 Aug 1998 16:49:08 -0700 From: Mike Smith <mike@smith.net.au> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@FreeBSD.ORG Subject: Re: PCI BIOSes and power management Message-ID: <199808122349.QAA01146@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 11 Aug 1998 19:04:57 EDT." <199808112304.TAA25098@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. This is actually more of an ACPI issue; you can obtain the ACPI standard from www.teleport.com/~acpi. > 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 seems to violate the ACPI spec, although it's notably thin on the ground when it comes to talking about restarts. Section 3.2 says "Computers that support legacy BIOS power management interfaces boot in the Legacy state and transition to the Working state when an ACPI OS loads." > 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. It may also be that the BIOS is not getting it right. If you're using NT4.0 and Win95 of the non-OSR2 variety, you may also not have an ACPI BIOS. I presume that Win95/NT will recognise the adapter OK when they restart? > - 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 We don't support this because (for whatever reason) we don't use the BIOS-provided routines for enumeration and configuration. We should be able to do this. > 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. What you're effectively doing here is trying to deal with a hot-inserted PCI card, and we don't have any infrastructure in place to support that. You might want to talk to Stefan in case he has any neat ideas. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808122349.QAA01146>