Date: Tue, 22 Nov 2011 16:03:32 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-acpi@freebsd.org Subject: Re: regression in power management since r216674 (kern/162578) Message-ID: <201111221603.34026.jkim@FreeBSD.org> In-Reply-To: <201111221505.50918.jhb@freebsd.org> References: <4ECB73F4.4060703@gmail.com> <4ECBFD7A.3090407@gmail.com> <201111221505.50918.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[Forwarding thread regarding kern/162578]
On Tuesday 22 November 2011 03:05 pm, John Baldwin wrote:
> [ Adding jkim@, could probably resend this thread to acpi@. ]
>
> On Tuesday, November 22, 2011 2:52:26 pm kron wrote:
> > On 2011/11/22 14:58, John Baldwin wrote:
> > > On Tuesday, November 22, 2011 5:05:40 am kron wrote:
> > >> Hi John,
> > >>
> > >> I dare to write directly to you because this seems to be
> > >> related to your commit r216674.
> > >>
> > >> I tried to open this on -stable a week ago ("9.0-RC2:
> > >> regression in power management on VIA Samuel 2") but didn't
> > >> attract an attention. In the meanwhile I created kern/162578
> > >> and after some bisecting came to a conclusion that my power
> > >> management issue was caused by r216674. In summary:
> > >>
> > >> With r216673, sysctl shows:
> > >> dev.cpu.0.%desc: ACPI CPU
> > >> dev.cpu.0.%driver: cpu
> > >> dev.cpu.0.%location: handle=\_PR_.CPU0
> > >> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> > >> dev.cpu.0.%parent: acpi0
> > >> dev.cpu.0.freq: 532
> > >> *dev.cpu.0.freq_levels:* 532/-1 266/-1
> > >> *dev.cpu.0.cx_supported:* C1/0 C2/90 C3/900
> > >> dev.cpu.0.cx_lowest: C2
> > >> I can set dev.cpu.0.cx_lowest and run powerd, too.
> > >>
> > >> With r216674:
> > >> dev.cpu.0.%desc: ACPI CPU
> > >> dev.cpu.0.%driver: cpu
> > >> dev.cpu.0.%location: handle=\_PR_.CPU0
> > >> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> > >> dev.cpu.0.%parent: acpi0
> > >> dev.cpu.0.cx_supported: C1/0
> > >> dev.cpu.0.cx_lowest: C1
> > >> dev.cpu.0.cx_usage: 100.00% last 208us
> > >> The C2 and C3 states and frequency levels are away and
> > >> powerd fails to start:
> > >> powerd: lookup freq: No such file or directory
> > >>
> > >> I tried to study acpi.c but it's a totally new area to me
> > >> - I'm 15 years away from C and have zero experience with
> > >> HW, kernels or so. I have a spare machine affected by this
> > >> and I'm willing to work on this issue. I'm going to find
> > >> some help at -users@ but before that, can you give me any
> > >> advice or tip, please?
> > >
> > > Sure, perhaps acpi_cpu() is failing to attach. Can you get
> > > verbose dmesg from before and after the change?
> >
> > Thank you very much!
> >
> > Both dmesgs attached. The difference between r216673
> > and r216674 is as follows:
> >
> > -Calibrating TSC clock ... TSC clock: 532647138 Hz
> > +Calibrating TSC clock ... TSC clock: 532648183 Hz
> >
> > -ACPI timer: 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/4 -> 0
> > -Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> > -acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on
> > acpi0 +acpi_timer0: couldn't allocate resource (port 0x4008)
> >
> > -acpi_throttle0: P_CNT from P_BLK 0x4010
> > +acpi_throttle0: failed to attach P_CNT
> > +device_attach: acpi_throttle0 attach returned 6
>
> So this is the issue, and it seems what happens is that your BIOS
> assigns the resources for this range to the pcib0 device when we
> expect them to be assigned as a system resource (if at all):
>
> pcib0: <ACPI Host-PCI bridge> port
> 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f
> on acpi0
>
> You could try hacking your ASL to not list the 0x4000-0x407f range
> for now, but the real fix is probably to make resources attached to
> Host-PCI bridge devices be treated as if they were system resources
> and put into the ACPI system resource rman instead. That requires
> a fair bit of work however.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201111221603.34026.jkim>