Re: Power Patches
Hi, > On Fri, 02 Jan 2004 11:23:11 -0700 (MST) > "M. Warner Losh" <[EMAIL PROTECTED]> said: imp> This looks like it isn't mapping the cis in correctly. Can you turn imp> on hw.cardbus.debug_cis=1? I assumed you meant hw.cardbus.cis_debug. ;) cardbus0: Resource not specified in CIS: id=10, size=800 cardbus0: Resource not specified in CIS: id=14, size=2 cardbus0: Resource not specified in CIS: id=18, size=80 cardbus0: Non-prefetchable memory at 8800-9001 cardbus0: IO port at 1000-107f cardbus0: at device 0.0 (no driver attached) cbb0: CardBus card activation failed Full output of dmesg is also attached in this mail. imp> : imp> 1) You are using hw.pci.unsupported_io=1. Turn it off and use imp> : imp>these patches. Let me know if it doesn't. Typically it imp> : imp>appears that this helps people hitting the double imp> : imp>allocation problem. imp> : imp> : I used to set hw.pci.unsupported_io=1. Changing this value doesn't imp> : help. imp> Dang. I'd like to get to the bottom of this. Aha, I made sure to set hw.pci.allow_unsupported_io_range. But, I did just copy&paste it from your message. :-) Sincerely, dmesg.out Description: Binary data -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
On Sat, Jan 03, 2004 at 06:47:13PM -0800, Nate Lawson wrote: > I get a panic on my T23 due to the ATA driver not being detected so no > rootvp. Same here on a Dell Latitude C640. Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
On 04-Jan-2004 Nate Lawson wrote: > I get a panic on my T23 due to the ATA driver not being detected so no > rootvp. Attached are dmesg both before and after the patch. The cbb0 > issue is a regression since I have specified it to use an unused IO range > via this tunable (the same range Windows uses): > >hw.cbb.start_memory=0xc0203000 > > I commented out that tunable while testing the power kernel. > > One thing you should fix is calling the acpi set methods with a NULL > pointer: > > pci2: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER > > You should probably just skip the call to the acpi set power state if it's > null. Well, see, I'm not sure yet what pointer is null. That is the output of acpi_name() on a handle. It would help to know what bus/device/func that is and if your ASL has a correspondnig device in the tree or not. It may be that acpi_handle() is returning NULL and in that case I guess we should just not try to adjust ACPI power resources/_PSx but just stick to the pci powerstate stuff. If you could verify what is actually NULL that could help however. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
In message: <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: : Could you provide an updated patch? I've been working on creating an updated one, but I need to patch a couple of things before it will be ready. If all goes well, I'll have it out this afternoon (I'm testing a couple of last things). If it doesn't, then later in the week. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
Hi Warner, M. Warner Losh wrote on Thu, Jan 01, 2004 at 11:30:09PM -0700: [..] > http://people.freebsd.org/~imp/power.20040101.diff [..] Hmmm, alas, the patch does not apply clean any more. It seems a recent commit to dev/pccbb/pccbb.c breaks this part of the patch. Not patching the file breaks the build because CBB_KLUDE_ALLOC is no longer defined. Applying the patch reverse doesn't work, either (no surprise, I guess). I've cvsupped and built the source today (Jan 5, 2003) and tried to test the patch. Could you provide an updated patch? Thanks & best regards, Daniel -- IRCnet: Mr-Spock - In dieser Mail ist ein Geist, der Dich in den Hintern beisst - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ smime.p7s Description: S/MIME cryptographic signature
Re: Power Patches
Hi Warner, M. Warner Losh wrote on Thu, Jan 01, 2004 at 11:30:09PM -0700: [..] > http://people.freebsd.org/~imp/power.20040101.diff [..] Hmmm, alas, the patch does not apply clean any more. It seems a recent commit to dev/pccbb/pccbb.c breaks this part of the patch. Not patching the file breaks the build because CBB_KLUDE_ALLOC is no longer defined. Applying the patch reverse doesn't work, either (no surprise, I guess). I've cvsupped and built the source today (Jan 5, 2003) and tried to test the patch. Could you provide an updated patch? Thanks & best regards, Daniel -- IRCnet: Mr-Spock - In dieser Mail ist ein Geist, der Dich in den Hintern beisst - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
In message: <[EMAIL PROTECTED]> Nate Lawson <[EMAIL PROTECTED]> writes: : I get a panic on my T23 due to the ATA driver not being detected so no : rootvp. Attached are dmesg both before and after the patch. The cbb0 : issue is a regression since I have specified it to use an unused IO range : via this tunable (the same range Windows uses): : :hw.cbb.start_memory=0xc0203000 : : I commented out that tunable while testing the power kernel. Yes. I think I understand why unsupported ranges is needed for some bridges and not others. We need to learn about subtractive decoders in pci_pci.c, which is what I'm working on. Subtractive decoders should allow allocations through mostly untouched. If the range of the nominally decoded area is a subset of the requested range, however, we should clip it. If it isn't a superset, then it should pass through w/o molestation. This should allow things to work w/o these ugly hacks. It gives people that don't care (0, ~0) a sensible range, while allowing the BIOS to preallocate 'weird' locations for the cardbus bridge. Linux recently grew this ability and more recently got the Intel mobile quirks: /* * For some reasons Intel decided that certain parts of their * 815, 845 and some other chipsets must look like PCI-to-PCI bridges * while they are obviously not. The 82801 family (AA, AB, BAM/CAM, * BA/CA/DB and E) PCI bridges are actually HUB-to-PCI ones, according * to Intel terminology. These devices do forward all addresses from * system to PCI bus no matter what are their window settings, so they are * "transparent" (or subtractive decoding) from programmers point of view. */ This quirk is what we need to implement. Most of the pciconf dumps people have sent me have these parts in common and it wasn't until I went searching for information about them that I ran across a very extensive discussion about the issues which happened a few months ago. Of course, this explains what I thought was unexplainable: how a non-subtractive bridge could pass cycles. It really is a subtractive one, it just lies in its ProgIf. In addition, I'm starting to think that the cardbus bridge might want to reserve a certain amount of resources for possible children. This would obviate the need for the start_memory tunable as well (or at least make it a footnote rather than a checklist item in troubleshooting). However, this issue is orthogonal to the other issues and can be dealt with on its own. At some point we'll also have to deal with bus numbering too. I have a machine (my FIVA) that has no working cardbus as all, and I've had at least one other report of this on a new DELL laptop. : One thing you should fix is calling the acpi set methods with a NULL : pointer: : : pci2: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER : : You should probably just skip the call to the acpi set power state if it's : null. I didn't write that part of the code. It exists solely in the p4 power tree. It isn't in my p4 newcard tree. I suspect that null functions shouldn't be called. I also hope that integrating it into my newcard tree will make my dell happier on suspend/resume (right now it really really cranky when I suspend/resume). I'll look into fixing it if someone else doesn't beat me to it. Despite the negative reports, the testing has been good in a number of ways. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
On Thu, 01 Jan 2004 23:30:09 -0700 (MST) "M. Warner Losh" <[EMAIL PROTECTED]> wrote: > You should try it if: > 1) You are using hw.pci.unsupported_io=1. Turn it off and use > these patches. Let me know if it doesn't. Typically it > appears that this helps people hitting the double > allocation problem. > 2) You have suspend/resume issues. This should make them suck > less if they are with a specific device (not ata). > 3) You have hacks in drivers to turn the power on for your > laptop because FreeBSD didn't used to do that. While I've > not yet removed all the hacks from the tree, nearly all of > them should now be redundant. I am sad to say it has some problems. # SHARP Mebius MURAMASA PC-MT2-F1 (i830MG chipset) 1. After this patch was applied, Cardbus/PCMCIA is not available. I tested following Compact Flash card. uart0: at port 0x2f8-0x2ff irq 10 function 0 config 9 on pccard1 | hw.pci.allow_unsupported_io_range = 0 | = 1 --++- on boot | NG | NG --++- any point | NG | NG on boot = card was inserted on boot. any point = after boot, card was inserted. 2. Firewire is not available on hw.pci.allow_unsupported_io_range=0. fwohci0: mem 0xe0202000-0xe02027ff irq 10 at device 0.2 on pci2 fwohci0: Bus reserved 0x800 bytes for rid 0x10 type 3 at 0xe0202000 fwohci0: OHCI version 0.0 (ROM=0) fwohci0: invalid OHCI version fwohci0: FireWire init failed device_probe_and_attach: fwohci0 attach returned 5 3. USB EHCI is same too like firewire. But I don't use it... usb2: EHCI version 0.0 usb2: wrong number of companions (0 != 2) ehci0: USB init failed err=13 device_probe_and_attach: ehci0 attach returned 5 Unfortunately, my note can't resume S3, yet. I affix dmesgs of 1's pattern, and acpidump -d -t. allow_unsupported_io_range=0_with_b-mobile_on_boot.dmesg.bz2 Description: Binary data allow_unsupported_io_range=0_without_b-mobile_on_boot.dmesg.bz2 Description: Binary data allow_unsupported_io_range=1_with_b-mobile_on_boot.dmesg.bz2 Description: Binary data allow_unsupported_io_range=1_without_b-mobile_on_boot.dmesg.bz2 Description: Binary data acpidump.txt.bz2 Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
I installed your power patches dated 20040101 on my Dell D-800. The boot fails in a curious way. It finds the ATA controller, but doesn't find either the disk or the CDROM in the machine. I did a -v boot, but I didn't see anything more significant. I don't know what you need to proceed on this one. Maybe setting everything to D3 is dangerous. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
Hi, all. From: "M. Warner Losh" <[EMAIL PROTECTED]> Subject: Power Patches Date: Thu, 01 Jan 2004 23:30:09 -0700 (MST) Message-ID: <[EMAIL PROTECTED]> imp> John Baldwin, Nate and I are putting the final touches on the imp> power/resource patches. Please try them out and let me know how well imp> they work for you. imp> imp> http://people.freebsd.org/~imp/power.20040101.diff I'm testing this patch on FMV-LOOX T70E(Chipset 855GM). This machine need to set hw.pci.allow_unsurpported_io_range=1, if not set, kernel was panic. After this patch, my machine doesn't panic when unset hw.pci.allow_unsurpported_io_range=1. Thank you! But, some problem is occur. 1) my ath cardbus card(FMV-JW481) is not recoginzed. When insert it, machine was freeze. But after eject it, machine was free. And output messages about attach failed. Before apply power patch, my external ath card was recognized as below: ath0: mem 0x8801-0x8801 irq 11 at device 0.0 on cardbus0 ath0: mac 5.6 phy 4.1 5ghz radio 3.6 ath0: bpf attached (snip) After patch, my external ath card was not recognized as below: ath0: mem 0xd020-0xd020 irq 11 at device 0.0 on cardbus0 ath0: mac 5.6 phy 4.1 5ghz radio 4.6 ath0: unable to collect channel list from hal (snip) This messages is very similar to internal ath device attach fail at radio revison number. My machine has internal ath device, but it attach fail to this message: ath0: mem 0xd020-0xd020 irq 11 at device 13.0 on pci1 ath0: Bus reserved 0x1000 buytes for rid 0x10 type 3 at 0xd020 ath0: mac 5.6 phy 4.1 5ghz radio 4.6 ath0: unable to collect channel list from hal device_probe_and_attach: ath0 attach returned 22 I think, recognize insert external ath card, but try to attach internal ath and faild. 2) LCD was not wakeup This problem was occur before patch ;-). My machine's LCD is not wake up from acpi S3 with hw.acpi.reset_video=0. If hw.acpi.reset_video=1, machine was freeze, and I can only power off. But hw.acpi.reset_video=0, LCD was not light, but other device like keyborad, NIC, CardBus Slot was wake and works fine. I can reboot it from network or keyborad typeing w/o LCD ;-) Someone comment about it? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
On Fri, 2 Jan 2004, M. Warner Losh wrote: > Can you send me the results of the following command: > > pciconf -r pci0:30:0 0:0xff Here it is: # pciconf -r pci0:30:0 0:0xff 24488086 80800107 06040081 0001 40080200 22808040 cff0c020 eff0e800 0004 00202802 7402 0040 0041 00080010 00020001 00c0 0f60 4632 regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
In message: <[EMAIL PROTECTED]> Lukas Ertl <[EMAIL PROTECTED]> writes: : *) I still need to set hw.pci.allow_unsupported_io_range="1", otherwise :cbb0 wouldn't attach: OK. Can you send me the results of the following command: pciconf -r pci0:30:0 0:0xff Thanks! And thank you for testing. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
In message: <[EMAIL PROTECTED]> Hajimu UMEMOTO <[EMAIL PROTECTED]> writes: : It fails to attach my Atheros card (I/O-Data WN-AG/CB): : : Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=10, size=800 : Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=14, size=2 : Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=18, size=80 : Jan 3 01:34:04 lyrics kernel: cardbus0: at device 0.0 (no driver attached) : Jan 3 01:34:04 lyrics kernel: cbb0: CardBus card activation failed This looks like it isn't mapping the cis in correctly. Can you turn on hw.cardbus.debug_cis=1? : imp> 1) You are using hw.pci.unsupported_io=1. Turn it off and use : imp> these patches. Let me know if it doesn't. Typically it : imp> appears that this helps people hitting the double : imp> allocation problem. : : I used to set hw.pci.unsupported_io=1. Changing this value doesn't : help. Dang. I'd like to get to the bottom of this. : My Aeronet 340 card is working fine. However, the card is inserted at : boot, it doesn't attached at boot and after boot with following : message: : : Jan 3 01:49:48 lyrics kernel: cbb1: Unsupported card type detected : : I'm using Victor InterLink MP-XP7210 (SiS 630 chipset). OK. Thanks! Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
Hi, > On Thu, 01 Jan 2004 23:30:09 -0700 (MST) > "M. Warner Losh" <[EMAIL PROTECTED]> said: imp> John Baldwin, Nate and I are putting the final touches on the imp> power/resource patches. Please try them out and let me know how well imp> they work for you. imp> http://people.freebsd.org/~imp/power.20040101.diff It fails to attach my Atheros card (I/O-Data WN-AG/CB): Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=10, size=800 Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=14, size=2 Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=18, size=80 Jan 3 01:34:04 lyrics kernel: cardbus0: at device 0.0 (no driver attached) Jan 3 01:34:04 lyrics kernel: cbb0: CardBus card activation failed imp>1) You are using hw.pci.unsupported_io=1. Turn it off and use imp> these patches. Let me know if it doesn't. Typically it imp> appears that this helps people hitting the double imp> allocation problem. I used to set hw.pci.unsupported_io=1. Changing this value doesn't help. My Aeronet 340 card is working fine. However, the card is inserted at boot, it doesn't attached at boot and after boot with following message: Jan 3 01:49:48 lyrics kernel: cbb1: Unsupported card type detected I'm using Victor InterLink MP-XP7210 (SiS 630 chipset). Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
On Thu, 1 Jan 2004, M. Warner Losh wrote: > You should try it if: > > 1) You are using hw.pci.unsupported_io=1. Turn it off and use > these patches. Let me know if it doesn't. Typically it > appears that this helps people hitting the double > allocation problem. > 2) You have suspend/resume issues. This should make them suck > less if they are with a specific device (not ata). Hi Warner, I experienced the following with this patch: *) I still need to set hw.pci.allow_unsupported_io_range="1", otherwise cbb0 wouldn't attach: cbb0: mem 0xb000-0xbfff irq 4 at device 0.0 on pci2 cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 cbb0: mem 0xb100-0xb1000fff irq 5 at device 0.1 on pci2 cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 *) My UHCI controller finally survives suspend/resume - YAY! :-) But there is still something bogus with EHCI: *) boot - kldload usb -> ehci0 fails to attach. *) boot - suspend/resume - kldload usb -> ehci0 attaches successfully Failing looks like this: uhci0: port 0x1800-0x181f irq 4 at device 29.0 on pci0 uhci0: Bus reserved 0x20 bytes for rid 0x20 type 4 at 0x1800 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 9 at device 29.1 on pci0 uhci1: Bus reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 6 at device 29.2 on pci0 uhci2: Bus reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc000-0xc3ff irq 11 at device 29.7 on pci0 ehci0: Bus reserved 0x400 bytes for rid 0x10 type 3 at 0xc000 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version ff.ff usb3: wrong number of companions (15 != 3) ehci0: USB init failed err=13 device_probe_and_attach: ehci0 attach returned 5 *) I'm seeing some "Failed to set ACPI power state" on boot, dmesg is attached. *) Otherwise, everything seems fine. Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-CURRENT #80: Fri Jan 2 13:45:19 CET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KORBEN Preloaded elf kernel "/boot/kernel/kernel" at 0xc0852000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc085226c. Preloaded acpi_dsdt "/boot/DSDT.aml" at 0xc08522bc. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0852300. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1300MHz (598.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf real memory = 536215552 (511 MB) avail memory = 514973696 (491 MB) Pentium Pro MTRR support enabled ACPI: DSDT was overridden. ACPI-0374: *** Info: Table [DSDT] replaced by host OS npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi_ec0: port 0x66,0x62 on acpi0 pcibios: BIOS version 2.10 Using $PIR table, 15 entries at 0xc00fdea0 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_tz0: port 0x530-0x537 on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0:0:0: setting power state D0 pci0:29:0: setting power state D0 pcib0: slot 29 INTA is routed to irq 4 pci0:29:1: setting power state D0 pcib0: slot 29 INTB is routed to irq 9 pci0:29:2: setting power state D0 pcib0: slot 29 INTC is routed to irq 6 pci0:29:7: setting power state D0 pcib0: slot 29 INTD is routed to irq 11 pci0:31:0: setting power state D0 pci0:31:1: setting power state D0 pci0:31:3: setting power state D0 pcib0: slot 31 INTB is routed to irq 5 pci0:31:5: setting power state D0 pcib0: slot 31 INTB is routed to irq 5 pci0:31:6: setting power state D0 pcib0: slot 31 INTB is routed to irq 5 agp0: mem 0xd000-0xdfff at device 0.0 on pci0 agp0: Bus reserved 0x1000 bytes for rid 0x10 type 3 at 0xd000 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1:0:0: setting power state D0 pcib1: slot 0 INTA is routed to irq 4 pci1: at device 0.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0:29:0: setting power state D3 pci0: at device 29.1 (no driver attached) pci0:29:1: setting power state D3 pci0: at device 29.2 (no driver attached) pci0:29:2: setting power state D3 pci0: a
Power Patches
John Baldwin, Nate and I are putting the final touches on the power/resource patches. Please try them out and let me know how well they work for you. http://people.freebsd.org/~imp/power.20040101.diff These patches do the following: 1) reserves resources on child enumeration. This means that we will stop allocating the same resource to multiple devices. There may be issues on driver detach and subsequent reattach, so be careful there. 2) Assign on a lazy basis, resources that a driver requests (if it is possible). This means we can remove the kludges from all the drivers that try to work around BIOSes not assigning resources. 3) Power state management. We set devices to power state D0 before we try to probe/attach them (proerply preserving the config space that the standards say we should preserve). We set the device's power state to D0 with the same restore on resume. Drivers that aren't attached get set to state D3 (if it is supported) to conserve power. 4) Some ACPI changes to improve power state transitions. 5) Misc cardbus changes to remove the kludges that were in there related to the above cleanup. Plus minor changes to when we turn on OE for 16-bit cards. 6) pci bridge tweaks necessary for #2 plus minor reformatting to style(9). I may have also broken 64 bit BAR support for the lazy evaluation. You should try it if: 1) You are using hw.pci.unsupported_io=1. Turn it off and use these patches. Let me know if it doesn't. Typically it appears that this helps people hitting the double allocation problem. 2) You have suspend/resume issues. This should make them suck less if they are with a specific device (not ata). 3) You have hacks in drivers to turn the power on for your laptop because FreeBSD didn't used to do that. While I've not yet removed all the hacks from the tree, nearly all of them should now be redundant. Let me know how this works out... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
