Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Mar 2005 10:43:15 +0400
From:      Vladimir Grebenschikov <vova@fbsd.ru>
To:        Nate Lawson <nate@root.org>
Cc:        acpi@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/acpica acpi_perf.c
Message-ID:  <1112164995.1054.5.camel@localhost>
In-Reply-To: <4247A90C.5050000@root.org>
References:  <200503200351.j2K3pIC8068507@repoman.freebsd.org> <1111516858.1198.2.camel@localhost>  <424737BE.9000808@root.org> <1111985287.1113.0.camel@localhost>  <4247A90C.5050000@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
=F7 =D7=D3, 27/03/2005 =D7 22:49 -0800, Nate Lawson =D0=C9=DB=C5=D4:
> Vladimir Grebenschikov wrote:
> > =F7 =D7=D3, 27/03/2005 =D7 14:46 -0800, Nate Lawson =D0=C9=DB=C5=D4:
> >=20
> >>Vladimir Grebenschikov wrote:
> >>
> >>>=F7 =D7=D3, 20/03/2005 =D7 03:51 +0000, Nate Lawson =D0=C9=DB=C5=D4:
> >>>
> >>>
> >>>>njl         2005-03-20 03:51:18 UTC
> >>>>
> >>>>FreeBSD src repository
> >>>>
> >>>>Modified files:
> >>>>  sys/dev/acpica       acpi_perf.c=20
> >>>>Log:
> >>>>Attach acpi_perf early.  Especially when it is being used to provide =
info
> >>>>to other devices, it needs to be attached first.  (Multi-pass newbus
> >>>>probes would be a better solution.)
> >>>>
> >>>>Revision  Changes    Path
> >>>>1.16      +6 -1      src/sys/dev/acpica/acpi_perf.c
> >>>
> >>>
> >>>I guess this patch makes panic on my notebook:
> >>>
> >>>cpu0: <ACPI CPU (2 Cx states)> on acpi0
> >>>acpi_perf0: <ACPI CPU Frequency Control> on cpu0
> >>>acpi_perf0: failed in PERF_STATUS attach
> >>>device_attach: acpi_perf0 attach returned 6
> >>>panic: resource_list_add: resource entry is busy
> >>
> >>I believe the patch I just committed fully cleans up resources for the=20
> >>error case correctly.  This should fix your panic.  The other question=20
> >>is why your status register fails to attach but the control register=20
> >>succeeds.  Can you send me your acpidump:
> >=20
> >=20
> > Thank you, will try fresh kernel  later today.
> >=20
> >=20
> > Attached
> >
> >=20
> >         Method (_PCT, 0, NotSerialized)
> >         {
> >             If (LEqual (And (PDC0, One), One))
> >             {
> >             ...
> >             }
> >             Else
> >             {
> >                 Return (Package (0x02)
> >                 {
> >                     ResourceTemplate ()
> >                     {
> >                         Register (SystemIO, 0x10, 0x00, 0x0000000000000=
0B2)
> >                     },=20
> >=20
> >                     ResourceTemplate ()
> >                     {
> >                         Register (SystemIO, 0x08, 0x00, 0x0000000000000=
0B3)
> >                     }
> >                 })
> >             }
> >         }
>=20
> I've moved this to the acpi@ list now...
>=20
> Are you sure there isn't a BIOS update for your system available?  It=20
> appears this is a Dell since a number of them have the same problem.=20

It is SONY, and they have no BIOS update for this series.

> The issue is that the control and status registers overlap.  To fix,=20
> change this line:
>=20
> Register (SystemIO, 0x10, 0x00, 0x00000000000000B2)
>=20
> to this:
>=20
> Register (SystemIO, 0x08, 0x00, 0x00000000000000B2)
>=20
> Then, recompile your asl as described in the handbook and load it at=20
> boot.  I'll try to figure out a way to work around this but it looks=20
> difficult to detect since 16 bits is a valid register width.  I seem to=20
> remember imp@ had a means for detecting that a resource alloc failed due=20
> to an overlapping register and then split the previous resource (since=20
> this driver owns both).  I'll ask.

It helps, thank you.

% dmesg=20
...
acpi0: <SONY> on motherboard
acpi_ec0: <Embedded Controller: GPE 0x1c> port 0x62,0x66 on acpi0
Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
cpu0: <ACPI CPU (2 Cx states)> on acpi0
acpi_perf0: <ACPI CPU Frequency Control> on cpu0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_button0: <Power Button> on acpi0
...
% sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU (2 Cx states)
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=3D\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1700
dev.cpu.0.freq_levels: 1700/24500 1487/21437 1400/19500 1275/18375
1225/17062 1200/16000 1062/15312 1000/13000 900/12000 875/12187
850/12250 800/9500 750/10000 700/9750 637/9187 600/6000 525/7312
500/6500 450/6000 425/6125 400/4750 375/4875 350/4875 300/4000 250/3250
212/3062 175/2437 150/2000 125/1625 100/1187 75/750
% sysctl dev.acpi_perf
dev.acpi_perf.0.%desc: ACPI CPU Frequency Control
dev.acpi_perf.0.%driver: acpi_perf
dev.acpi_perf.0.%parent: cpu0
dev.acpi_perf.0.freq_settings: 1700/24500 1400/19500 1200/16000
1000/13000 800/9500 600/6000
%

I have also problem with suspend/resume - on resume notebook does not
show anything on screen, can't be accessed via network or firewire.
Recent VESA patches does not helps.

So question is - can this ASL patch help for suspend/resume or it is
unrelated ?

--=20
Vladimir B. Grebenchikov
vova@fbsd.ru



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1112164995.1054.5.camel>