Bug 73053 - dpm hangs with BTC parts
Summary: dpm hangs with BTC parts
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 73577 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-26 23:16 UTC by almos
Modified: 2014-07-14 13:01 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
vbios.rom (64.00 KB, application/octet-stream)
2013-12-27 11:14 UTC, almos
no flags Details
dmesg (64.94 KB, text/plain)
2013-12-27 20:17 UTC, almos
no flags Details
Xorg.0.log (42.93 KB, text/plain)
2013-12-27 20:18 UTC, almos
no flags Details
testing patch (1.48 KB, patch)
2014-01-07 18:44 UTC, Alex Deucher
no flags Details | Splinter Review
VBIOS Radeon HD6870 (64.00 KB, application/octet-stream)
2014-01-08 22:19 UTC, Juan Orti Alcaine
no flags Details
Xorg.log Radeon HD6870 (66.03 KB, text/plain)
2014-01-08 22:21 UTC, Juan Orti Alcaine
no flags Details
dmesg Radeon HD6870 (111.30 KB, text/plain)
2014-01-08 22:21 UTC, Juan Orti Alcaine
no flags Details
dmesg 3.13.0-0.rc7.git2.1.fc21.x86_64 + patch 91609 (115.77 KB, text/plain)
2014-01-09 16:45 UTC, Juan Orti Alcaine
no flags Details
cmdline 3.13.0-0.rc7.git2.1.fc21.x86_64 + patch 91609 (297 bytes, text/plain)
2014-01-09 16:46 UTC, Juan Orti Alcaine
no flags Details
Xorg.log 3.13.0-0.rc7.git2.1.fc21.x86_64 + patch 91609 (65.34 KB, text/plain)
2014-01-09 16:46 UTC, Juan Orti Alcaine
no flags Details
radeon 6850 dmesg (150.35 KB, text/plain)
2014-01-12 09:12 UTC, dimitris
no flags Details
possible fix (1.13 KB, patch)
2014-03-06 21:15 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (1.19 KB, patch)
2014-07-01 16:18 UTC, Alex Deucher
no flags Details | Splinter Review
image of panic.jpg (1.39 MB, image/jpeg)
2014-07-12 12:52 UTC, almos
no flags Details

Description almos 2013-12-26 23:16:49 UTC
The monitor goes blank, and the system becomes totally unresponsive as soon as the radeon module is loaded, if I boot 3.12.4 with radeon.dpm=1 or I boot 3.13-rc5 without radeon.dpm=0.

Bug #66963 might be related.
Comment 1 Alex Deucher 2013-12-27 00:42:02 UTC
(In reply to comment #0)
> The monitor goes blank, and the system becomes totally unresponsive as soon
> as the radeon module is loaded, if I boot 3.12.4 with radeon.dpm=1 or I boot
> 3.13-rc5 without radeon.dpm=0.

Did dpm ever work on your board?  Just to clarify, does 3.13-rc5 fail to boot even with radeon.dpm=0?  Please attach a copy of your dmesg output, Xorg log, and vbios.  To get a copy of your vbios:
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom


> 
> Bug #66963 might be related.

Unrelated.  That bug is about rv6xx asics.  Your chip is a BTC part.
Comment 2 almos 2013-12-27 11:14:32 UTC
Created attachment 91215 [details]
vbios.rom

This is the first time I tried dpm, and it didn't work. Without dpm, the card works fine with both kernels.
Comment 3 almos 2013-12-27 20:17:49 UTC
Created attachment 91234 [details]
dmesg
Comment 4 almos 2013-12-27 20:18:19 UTC
Created attachment 91235 [details]
Xorg.0.log
Comment 5 Alex Deucher 2014-01-07 18:44:44 UTC
Created attachment 91609 [details] [review]
testing patch

Does the attached patch help?  If so, try and narrow down which changes fix the issue.
Comment 6 Juan Orti Alcaine 2014-01-08 22:18:23 UTC
I have the same problem with a Radeon HD6870 and kernel 3.12.6-300.fc20.x86_64 in Fedora.

I cannot boot with radeon.dpm=1. I see the kernel booting but the monitor goes black quickly. Sometimes I see the Xorg loading the wallpaper, but suddenly the image gets corrupted and the monitor goes black.

lspci -v:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barts XT [Radeon HD 6870] (prog-if 00 [VGA controller])
        Subsystem: Hightech Information System Ltd. Device 2010
        Flags: bus master, fast devsel, latency 0, IRQ 58
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Memory at f7e20000 (64-bit, non-prefetchable) [size=128K]
        I/O ports at e000 [size=256]
        Expansion ROM at f7e00000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150] Advanced Error Reporting
        Kernel driver in use: radeon


/proc/cmdline (without radeon.dpm=1):
BOOT_IMAGE=/root/boot/vmlinuz-3.12.6-300.fc20.x86_64 root=UUID=cd8d5bd5-5d01-4bfc-b417-f766e7ad643b ro rootflags=subvol=root rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=es vconsole.font=latarcyrheb-sun16 crashkernel=128M radeon.audio=1 libahci.ignore_sss=1 rhgb quiet
Comment 7 Juan Orti Alcaine 2014-01-08 22:19:53 UTC
Created attachment 91710 [details]
VBIOS Radeon HD6870
Comment 8 Juan Orti Alcaine 2014-01-08 22:21:17 UTC
Created attachment 91711 [details]
Xorg.log Radeon HD6870

Without radeon.dpm=1
Comment 9 Juan Orti Alcaine 2014-01-08 22:21:57 UTC
Created attachment 91712 [details]
dmesg Radeon HD6870

Without radeon.dpm=1
Comment 10 Alex Deucher 2014-01-08 22:45:02 UTC
Can anyone test my patch and try and narrow down the problem as per comment 5?  I'm not table to reproduce this on any of the BTC cards I have access to.
Comment 11 almos 2014-01-08 23:52:39 UTC
(In reply to comment #10)
> Can anyone test my patch and try and narrow down the problem as per comment
> 5?  I'm not table to reproduce this on any of the BTC cards I have access to.

I'll test it in the weekend.
Comment 12 Matt Novenstern 2014-01-09 03:00:28 UTC
I built a patched version of the 3.13rc7 kernel using the source from the fedora rawhide-nodebug repo, using the patch provided.  I was able to boot to a desktop and use it for a handful of seconds and then it froze/blanked the screen as usual.
Comment 13 Alexandre Demers 2014-01-09 05:29:22 UTC
Some symptoms look like what was encountered in bug 68235 and possibly what is encountered in bug 69723.
Comment 14 Juan Orti Alcaine 2014-01-09 16:44:38 UTC
(In reply to comment #5)
> Created attachment 91609 [details] [review] [review]
> testing patch
> 
> Does the attached patch help?  If so, try and narrow down which changes fix
> the issue.

I have added this patch to the Fedora kernel 3.13.0-0.rc7.git2.1.fc21.x86_64 and the results are the same, sometimes it halts while the kernel is booting, and other times I can even login in KDE, but suddenly the screen is corrupted and goes black.

I attach some logs of when I was able to boot and take them.
Comment 15 Juan Orti Alcaine 2014-01-09 16:45:43 UTC
Created attachment 91769 [details]
dmesg 3.13.0-0.rc7.git2.1.fc21.x86_64 + patch 91609
Comment 16 Juan Orti Alcaine 2014-01-09 16:46:07 UTC
Created attachment 91770 [details]
cmdline 3.13.0-0.rc7.git2.1.fc21.x86_64 + patch 91609
Comment 17 Juan Orti Alcaine 2014-01-09 16:46:31 UTC
Created attachment 91771 [details]
Xorg.log 3.13.0-0.rc7.git2.1.fc21.x86_64 + patch 91609
Comment 18 Alex Deucher 2014-01-11 15:58:38 UTC
Are things any better with my 3.14 branch?
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.14
Comment 19 dimitris 2014-01-12 09:12:25 UTC
Created attachment 91892 [details]
radeon 6850 dmesg

radeon 6850 dmesg
Comment 20 dimitris 2014-01-12 09:13:53 UTC
i am using 
Linux Saturn 3.13.0-rc7 #1 SMP PREEMPT Sun Jan 5 12:00:06 EET 2014 x86_64 GNU/Linux

but it seems my card doesn't have any issue.
Comment 21 dimitris 2014-01-12 09:24:02 UTC
Comment on attachment 91892 [details]
radeon 6850 dmesg

i am using 
Linux Saturn 3.13.0-rc7 #1 SMP PREEMPT Sun Jan 5 12:00:06 EET 2014 x86_64
GNU/Linux

but it seems my card doesn't have any issue.

03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barts PRO [Radeon HD 6850] (prog-if 00 [VGA controller])
        Subsystem: PC Partner Limited / Sapphire Technology Device 174b
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 44
        Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at fbfc0000 (64-bit, non-prefetchable) [size=128K]
        Region 4: I/O ports at e000 [size=256]
        Expansion ROM at fbfa0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0f00c  Data: 41d1
        Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
        Kernel driver in use: radeon
        Kernel modules: radeon
Comment 22 Juan Orti Alcaine 2014-01-12 18:17:51 UTC
With (In reply to comment #18)
> Are things any better with my 3.14 branch?
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.14

I've been using that branch at commit 0279ed19bd962434d334f5eeb16d14fdd9459a00 and things seems a little better but it keeps crashing with my Radeon HD 6870.

Most of the time, the kernel boots, but sometimes it freezes right at the start.
First thing I notice with that kernel it's that I see the Tuxs for a second before Plymouth, maybe it's something related to the initrd, I don't know.
I'm able to log in and even sometimes load a 3D game and play, but it always end crashing after a few seconds.

I've trying to do a kdump, but the system is totally unresponsive.

What can I do to help?
Comment 23 Alex Deucher 2014-01-14 13:52:24 UTC
*** Bug 73577 has been marked as a duplicate of this bug. ***
Comment 24 Alex Deucher 2014-01-15 21:14:28 UTC
Does disabling hyperZ help?  E.g., set env var R600_DEBUG=nohyperz in /etc/environment or however your distro handles global env vars.
Comment 25 Juan Orti Alcaine 2014-01-17 15:11:06 UTC
(In reply to comment #24)
> Does disabling hyperZ help?  E.g., set env var R600_DEBUG=nohyperz in
> /etc/environment or however your distro handles global env vars.

With that variable set the behaviour is the same. I can log in KDE, but crash in a few minutes.
Comment 26 Alex Deucher 2014-01-17 15:55:15 UTC
Does using glamor for acceleration help?  Make sure you have an glamor enabled ddx (xf86-video-ati), and then add:
Option "AccelMethod" "glamor"
to the device section of your xorg config.
Comment 27 almos 2014-01-19 21:56:18 UTC
(In reply to comment #18)
> Are things any better with my 3.14 branch?
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.14

I don't know if this helps, but I tried your branch (at 4a8ee429cab), and it fails different. For some reason it calls itself 3.13-rc4+, and it defaults to dpm=0, I hope these are not a problem. When I enable dpm, the screen doesn't turn off when the radeon module is loaded, but as X starts, the screen goes black with 1px blue vertical lines at every 8th pixel. I tried 3 times, the same result.

I don't have glamor now, when I'll have some time I'll try with it.
Comment 28 Alex Deucher 2014-03-06 21:15:34 UTC
Created attachment 95246 [details] [review]
possible fix

Does this patch help?
Comment 29 almos 2014-03-08 20:25:44 UTC
(In reply to comment #28)
> Created attachment 95246 [details] [review] [review]
> possible fix
> 
> Does this patch help?

I checked out the newest state of your drm-next-3.14 git branch (at 78fe9e545), and applied the patch. I still get the vertical stripes and complete lockup.
Comment 30 Juan Orti Alcaine 2014-03-09 16:36:31 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > Created attachment 95246 [details] [review] [review] [review]
> > possible fix
> > 
> > Does this patch help?
> 
> I checked out the newest state of your drm-next-3.14 git branch (at
> 78fe9e545), and applied the patch. I still get the vertical stripes and
> complete lockup.


The same here with a Radeon HD 6870. I can start KDE, but it crashes with vertical white strips over a dark background.
Comment 31 Alex Deucher 2014-07-01 16:18:27 UTC
Created attachment 102081 [details] [review]
possible fix

Does this patch fix the issues?
Comment 32 Juan Orti Alcaine 2014-07-01 21:11:52 UTC
(In reply to comment #31)
> Created attachment 102081 [details] [review] [review]
> possible fix
> 
> Does this patch fix the issues?

Great! it works very well, I've been using it for an hour, playing 3D games with no stability problems. The temperature also is 10-20 ºC lower than before.

This kernel is your branch drm-next-3.16 at commit 4366f3b5f5a971cf348c298716b2cb29aab6ef4f + patch 102081
Comment 33 Stan Trzmiel 2014-07-07 13:16:04 UTC
Patch applied to 3.15.3 from fedora testing fixed issues with Radeon 7600M (AMD Turks).
Tested on  glxgears, schorched3d and flightgear.
Comment 34 Rpnpif 2014-07-10 08:45:27 UTC
Hi,
Same issue with my system on motherboard MSI A78M-E35 with AMD APU A4-5300.
But my system reboots some 3 seconds after initramfs is loaded. So no Xorg and no logs.

00:00.2 IOMMU: Advanced Micro Devices [AMD] Family 15h (Models 10h-1fh) I/O Memory Management Unit
	Subsystem: Micro-Star International Co., Ltd. Device 7721
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Capabilities: [40] Secure device <?>
	Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+

00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Device 9993 (prog-if 00 [VGA controller])
	Subsystem: Micro-Star International Co., Ltd. Device 7721
	Flags: bus master, fast devsel, latency 0, IRQ 49
	Memory at c0000000 (32-bit, prefetchable) [size=256M]
	I/O ports at f000 [size=256]
	Memory at feb00000 (32-bit, non-prefetchable) [size=256K]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Root Complex Integrated Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: radeon

I wrote a bug issue on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748615
Same issue on linux 3.13 to 3.15.1.
radeon.dpm=0 fix it.

I does not yet try your last patch.

Regards.
Comment 35 Rpnpif 2014-07-10 12:09:57 UTC
(In reply to comment #34)

I have trying some minutes ago 3.14.12 kernel that have your patches included, I think. But same issue : the system reboots early in the sequence boot.

Or my bug is different or it is the same and your patches does not fix it. Only radeon.dpm=0 on the kernel command line fix it.
Comment 36 Alex Deucher 2014-07-10 12:54:52 UTC
(In reply to comment #34)
> Hi,
> Same issue with my system on motherboard MSI A78M-E35 with AMD APU A4-5300.
> But my system reboots some 3 seconds after initramfs is loaded. So no Xorg
> and no logs.
> 

You have an APU.  This bug is specifically about dpm on BTC discrete GPUs.  It sounds like you are seeing bug 72921.  Please try the patch on that bug.
Comment 37 Rpnpif 2014-07-10 16:56:31 UTC
(In reply to comment #36)
> You have an APU.  This bug is specifically about dpm on BTC discrete GPUs. 
> It sounds like you are seeing bug 72921.  Please try the patch on that bug.

You are right and the last patch of bug 72921 fixes my bug issue.
Thank you very much.
Comment 38 almos 2014-07-11 22:32:27 UTC
Attachment 102081 [details] fixes the "hard lockup with small vertical blue stripes" issue, when applied to 3.15.4, and AFAICS dpm works fine.

The new problem is that I get kernel panic after a few hours if dpm is enabled. With the good old profile method the system is stable.
Comment 39 Alexandre Demers 2014-07-12 00:10:33 UTC
(In reply to comment #38)
> Attachment 102081 [details] fixes the "hard lockup with small vertical blue
> stripes" issue, when applied to 3.15.4, and AFAICS dpm works fine.
> 
> The new problem is that I get kernel panic after a few hours if dpm is
> enabled. With the good old profile method the system is stable.

Could you test with latest kernel 3.16 RC (the patch is already included)? I have been running kernel 3.16-RC4 with this patch for Cayman and I don't get any lockups anymore. I've been running my system for a few days (games, movies and so on) without problem.
Comment 40 Alex Deucher 2014-07-12 00:35:29 UTC
(In reply to comment #38)
> The new problem is that I get kernel panic after a few hours if dpm is
> enabled. With the good old profile method the system is stable.

Can you get a copy of the panic?  I think it may be related to the page flipping changes in the last couple kernels.  It's not likely dpm would cause a panic.
Comment 41 almos 2014-07-12 12:49:36 UTC
(In reply to comment #40)
> (In reply to comment #38)
> > The new problem is that I get kernel panic after a few hours if dpm is
> > enabled. With the good old profile method the system is stable.
> 
> Can you get a copy of the panic?  I think it may be related to the page
> flipping changes in the last couple kernels.  It's not likely dpm would
> cause a panic.

It seems I spoke too soon. 3.15.4 panics even without dpm.
Comment 42 almos 2014-07-12 12:52:41 UTC
Created attachment 102669 [details]
image of panic.jpg
Comment 43 Alexandre Demers 2014-07-13 01:43:52 UTC
(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #38)
> > > The new problem is that I get kernel panic after a few hours if dpm is
> > > enabled. With the good old profile method the system is stable.
> > 
> > Can you get a copy of the panic?  I think it may be related to the page
> > flipping changes in the last couple kernels.  It's not likely dpm would
> > cause a panic.
> 
> It seems I spoke too soon. 3.15.4 panics even without dpm.

So it is a different bug from the current one. Alex Deucher may be able to tell you if your screeshot confirms his suspicions. However, if everything still runs fine about dpm with the patch applied, I suggest you close the current bug and, if needed, you open a new one.
Comment 44 almos 2014-07-13 10:29:47 UTC
3.14.12 also panics after a few hours. It seems I have to return to the 3.12 series.
Comment 45 Alex Deucher 2014-07-13 21:15:19 UTC
(In reply to comment #44)
> 3.14.12 also panics after a few hours. It seems I have to return to the 3.12
> series.

I'm not sure this panic has anything to do with the GPU driver.
Comment 46 almos 2014-07-14 13:01:17 UTC
(In reply to comment #45)
> (In reply to comment #44)
> > 3.14.12 also panics after a few hours. It seems I have to return to the 3.12
> > series.
> 
> I'm not sure this panic has anything to do with the GPU driver.

Me neither, but it makes testing a bit difficult. Not to mention daily work.

Anyway, I'm closing the bug, because the fix for the hang has been found, and it's already landed in most of the stable branches. A big thanks to everyone who contributed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.