From: Greg KH <gregkh@linuxfoundation.org>
To: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Cc: daniel.vetter@ffwll.ch, michel@daenzer.net,
dri-devel@lists.freedesktop.org, ppaalanen@gmail.com,
amd-gfx@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
ckoenig.leichtzumerken@gmail.com, alexdeucher@gmail.com
Subject: Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
Date: Wed, 24 Jun 2020 08:11:53 +0200 [thread overview]
Message-ID: <20200624061153.GA933050@kroah.com> (raw)
In-Reply-To: <090c5a35-3088-d6d0-dcaf-5ce5542a4298@amd.com>
On Tue, Jun 23, 2020 at 11:04:30PM -0400, Andrey Grodzovsky wrote:
>
> On 6/23/20 2:05 AM, Greg KH wrote:
> > On Tue, Jun 23, 2020 at 12:51:00AM -0400, Andrey Grodzovsky wrote:
> > > On 6/22/20 12:45 PM, Greg KH wrote:
> > > > On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
> > > > > On 6/22/20 7:21 AM, Greg KH wrote:
> > > > > > On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> > > > > > > On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > > > > > > > Track sysfs files in a list so they all can be removed during pci remove
> > > > > > > > since otherwise their removal after that causes crash because parent
> > > > > > > > folder was already removed during pci remove.
> > > > > > Huh? That should not happen, do you have a backtrace of that crash?
> > > > > 2 examples in the attached trace.
> > > > Odd, how did you trigger these?
> > >
> > > By manually triggering PCI remove from sysfs
> > >
> > > cd /sys/bus/pci/devices/0000\:05\:00.0 && echo 1 > remove
> > For some reason, I didn't think that video/drm devices could handle
> > hot-remove like this. The "old" PCI hotplug specification explicitly
> > said that video devices were not supported, has that changed?
> >
> > And this whole issue is probably tied to the larger issue that Daniel
> > was asking me about, when it came to device lifetimes and the drm layer,
> > so odds are we need to fix that up first before worrying about trying to
> > support this crazy request, right? :)
> >
> > > > > [ 925.738225 < 0.188086>] BUG: kernel NULL pointer dereference, address: 0000000000000090
> > > > > [ 925.738232 < 0.000007>] #PF: supervisor read access in kernel mode
> > > > > [ 925.738236 < 0.000004>] #PF: error_code(0x0000) - not-present page
> > > > > [ 925.738240 < 0.000004>] PGD 0 P4D 0
> > > > > [ 925.738245 < 0.000005>] Oops: 0000 [#1] SMP PTI
> > > > > [ 925.738249 < 0.000004>] CPU: 7 PID: 2547 Comm: amdgpu_test Tainted: G W OE 5.5.0-rc7-dev-kfd+ #50
> > > > > [ 925.738256 < 0.000007>] Hardware name: System manufacturer System Product Name/RAMPAGE IV FORMULA, BIOS 4804 12/30/2013
> > > > > [ 925.738266 < 0.000010>] RIP: 0010:kernfs_find_ns+0x18/0x110
> > > > > [ 925.738270 < 0.000004>] Code: a6 cf ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 41 57 41 56 49 89 f6 41 55 41 54 49 89 fd 55 53 49 89 d4 <0f> b7 af 90 00 00 00 8b 05 8f ee 6b 01 48 8b 5f 68 66 83 e5 20 41
> > > > > [ 925.738282 < 0.000012>] RSP: 0018:ffffad6d0118fb00 EFLAGS: 00010246
> > > > > [ 925.738287 < 0.000005>] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 2098a12076864b7e
> > > > > [ 925.738292 < 0.000005>] RDX: 0000000000000000 RSI: ffffffffb6606b31 RDI: 0000000000000000
> > > > > [ 925.738297 < 0.000005>] RBP: ffffffffb6606b31 R08: ffffffffb5379d10 R09: 0000000000000000
> > > > > [ 925.738302 < 0.000005>] R10: ffffad6d0118fb38 R11: ffff9a75f64820a8 R12: 0000000000000000
> > > > > [ 925.738307 < 0.000005>] R13: 0000000000000000 R14: ffffffffb6606b31 R15: ffff9a7612b06130
> > > > > [ 925.738313 < 0.000006>] FS: 00007f3eca4e8700(0000) GS:ffff9a763dbc0000(0000) knlGS:0000000000000000
> > > > > [ 925.738319 < 0.000006>] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > > [ 925.738323 < 0.000004>] CR2: 0000000000000090 CR3: 0000000035e5a005 CR4: 00000000000606e0
> > > > > [ 925.738329 < 0.000006>] Call Trace:
> > > > > [ 925.738334 < 0.000005>] kernfs_find_and_get_ns+0x2e/0x50
> > > > > [ 925.738339 < 0.000005>] sysfs_remove_group+0x25/0x80
> > > > > [ 925.738344 < 0.000005>] sysfs_remove_groups+0x29/0x40
> > > > > [ 925.738350 < 0.000006>] free_msi_irqs+0xf5/0x190
> > > > > [ 925.738354 < 0.000004>] pci_disable_msi+0xe9/0x120
> > > > So the PCI core is trying to clean up attributes that it had registered,
> > > > which is fine. But we can't seem to find the attributes? Were they
> > > > already removed somewhere else?
> > > >
> > > > that's odd.
> > >
> > > Yes, as i pointed above i am emulating device remove from sysfs and this
> > > triggers pci device remove sequence and as part of that my specific device
> > > folder (05:00.0) is removed from the sysfs tree.
> > But why are things being removed twice?
>
>
> Not sure I understand what removed twice ? I remove only once per sysfs attribute.
This code path shows that the kernel is trying to remove a file that is
not present, so someone removed it already...
thanks,
gre k-h
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Cc: daniel.vetter@ffwll.ch, michel@daenzer.net,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
ckoenig.leichtzumerken@gmail.com
Subject: Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
Date: Wed, 24 Jun 2020 08:11:53 +0200 [thread overview]
Message-ID: <20200624061153.GA933050@kroah.com> (raw)
In-Reply-To: <090c5a35-3088-d6d0-dcaf-5ce5542a4298@amd.com>
On Tue, Jun 23, 2020 at 11:04:30PM -0400, Andrey Grodzovsky wrote:
>
> On 6/23/20 2:05 AM, Greg KH wrote:
> > On Tue, Jun 23, 2020 at 12:51:00AM -0400, Andrey Grodzovsky wrote:
> > > On 6/22/20 12:45 PM, Greg KH wrote:
> > > > On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
> > > > > On 6/22/20 7:21 AM, Greg KH wrote:
> > > > > > On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> > > > > > > On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > > > > > > > Track sysfs files in a list so they all can be removed during pci remove
> > > > > > > > since otherwise their removal after that causes crash because parent
> > > > > > > > folder was already removed during pci remove.
> > > > > > Huh? That should not happen, do you have a backtrace of that crash?
> > > > > 2 examples in the attached trace.
> > > > Odd, how did you trigger these?
> > >
> > > By manually triggering PCI remove from sysfs
> > >
> > > cd /sys/bus/pci/devices/0000\:05\:00.0 && echo 1 > remove
> > For some reason, I didn't think that video/drm devices could handle
> > hot-remove like this. The "old" PCI hotplug specification explicitly
> > said that video devices were not supported, has that changed?
> >
> > And this whole issue is probably tied to the larger issue that Daniel
> > was asking me about, when it came to device lifetimes and the drm layer,
> > so odds are we need to fix that up first before worrying about trying to
> > support this crazy request, right? :)
> >
> > > > > [ 925.738225 < 0.188086>] BUG: kernel NULL pointer dereference, address: 0000000000000090
> > > > > [ 925.738232 < 0.000007>] #PF: supervisor read access in kernel mode
> > > > > [ 925.738236 < 0.000004>] #PF: error_code(0x0000) - not-present page
> > > > > [ 925.738240 < 0.000004>] PGD 0 P4D 0
> > > > > [ 925.738245 < 0.000005>] Oops: 0000 [#1] SMP PTI
> > > > > [ 925.738249 < 0.000004>] CPU: 7 PID: 2547 Comm: amdgpu_test Tainted: G W OE 5.5.0-rc7-dev-kfd+ #50
> > > > > [ 925.738256 < 0.000007>] Hardware name: System manufacturer System Product Name/RAMPAGE IV FORMULA, BIOS 4804 12/30/2013
> > > > > [ 925.738266 < 0.000010>] RIP: 0010:kernfs_find_ns+0x18/0x110
> > > > > [ 925.738270 < 0.000004>] Code: a6 cf ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 41 57 41 56 49 89 f6 41 55 41 54 49 89 fd 55 53 49 89 d4 <0f> b7 af 90 00 00 00 8b 05 8f ee 6b 01 48 8b 5f 68 66 83 e5 20 41
> > > > > [ 925.738282 < 0.000012>] RSP: 0018:ffffad6d0118fb00 EFLAGS: 00010246
> > > > > [ 925.738287 < 0.000005>] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 2098a12076864b7e
> > > > > [ 925.738292 < 0.000005>] RDX: 0000000000000000 RSI: ffffffffb6606b31 RDI: 0000000000000000
> > > > > [ 925.738297 < 0.000005>] RBP: ffffffffb6606b31 R08: ffffffffb5379d10 R09: 0000000000000000
> > > > > [ 925.738302 < 0.000005>] R10: ffffad6d0118fb38 R11: ffff9a75f64820a8 R12: 0000000000000000
> > > > > [ 925.738307 < 0.000005>] R13: 0000000000000000 R14: ffffffffb6606b31 R15: ffff9a7612b06130
> > > > > [ 925.738313 < 0.000006>] FS: 00007f3eca4e8700(0000) GS:ffff9a763dbc0000(0000) knlGS:0000000000000000
> > > > > [ 925.738319 < 0.000006>] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > > [ 925.738323 < 0.000004>] CR2: 0000000000000090 CR3: 0000000035e5a005 CR4: 00000000000606e0
> > > > > [ 925.738329 < 0.000006>] Call Trace:
> > > > > [ 925.738334 < 0.000005>] kernfs_find_and_get_ns+0x2e/0x50
> > > > > [ 925.738339 < 0.000005>] sysfs_remove_group+0x25/0x80
> > > > > [ 925.738344 < 0.000005>] sysfs_remove_groups+0x29/0x40
> > > > > [ 925.738350 < 0.000006>] free_msi_irqs+0xf5/0x190
> > > > > [ 925.738354 < 0.000004>] pci_disable_msi+0xe9/0x120
> > > > So the PCI core is trying to clean up attributes that it had registered,
> > > > which is fine. But we can't seem to find the attributes? Were they
> > > > already removed somewhere else?
> > > >
> > > > that's odd.
> > >
> > > Yes, as i pointed above i am emulating device remove from sysfs and this
> > > triggers pci device remove sequence and as part of that my specific device
> > > folder (05:00.0) is removed from the sysfs tree.
> > But why are things being removed twice?
>
>
> Not sure I understand what removed twice ? I remove only once per sysfs attribute.
This code path shows that the kernel is trying to remove a file that is
not present, so someone removed it already...
thanks,
gre k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-06-24 7:00 UTC|newest]
Thread overview: 194+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-21 6:03 [PATCH v2 0/8] RFC Support hot device unplug in amdgpu Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-21 6:03 ` [PATCH v2 1/8] drm: Add dummy page per device or GEM object Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:35 ` Daniel Vetter
2020-06-22 9:35 ` Daniel Vetter
2020-06-22 14:21 ` Pekka Paalanen
2020-06-22 14:21 ` Pekka Paalanen
2020-06-22 14:24 ` Daniel Vetter
2020-06-22 14:24 ` Daniel Vetter
2020-06-22 14:28 ` Pekka Paalanen
2020-06-22 14:28 ` Pekka Paalanen
2020-11-09 20:34 ` Andrey Grodzovsky
2020-11-09 20:34 ` Andrey Grodzovsky
2020-11-15 6:39 ` Andrey Grodzovsky
2020-11-15 6:39 ` Andrey Grodzovsky
2020-06-22 13:18 ` Christian König
2020-06-22 13:18 ` Christian König
2020-06-22 14:23 ` Daniel Vetter
2020-06-22 14:23 ` Daniel Vetter
2020-06-22 14:32 ` Andrey Grodzovsky
2020-06-22 14:32 ` Andrey Grodzovsky
2020-06-22 17:45 ` Christian König
2020-06-22 17:45 ` Christian König
2020-06-22 17:50 ` Daniel Vetter
2020-06-22 17:50 ` Daniel Vetter
2020-11-09 20:53 ` Andrey Grodzovsky
2020-11-09 20:53 ` Andrey Grodzovsky
2020-11-13 20:52 ` Andrey Grodzovsky
2020-11-13 20:52 ` Andrey Grodzovsky
2020-11-14 8:41 ` Christian König
2020-11-14 8:41 ` Christian König
2020-11-14 9:51 ` Daniel Vetter
2020-11-14 9:51 ` Daniel Vetter
2020-11-14 9:57 ` Daniel Vetter
2020-11-14 9:57 ` Daniel Vetter
2020-11-16 9:42 ` Michel Dänzer
2020-11-16 9:42 ` Michel Dänzer
2020-11-15 6:34 ` Andrey Grodzovsky
2020-11-15 6:34 ` Andrey Grodzovsky
2020-11-16 9:48 ` Christian König
2020-11-16 9:48 ` Christian König
2020-11-16 19:00 ` Andrey Grodzovsky
2020-11-16 19:00 ` Andrey Grodzovsky
2020-11-16 20:36 ` Christian König
2020-11-16 20:36 ` Christian König
2020-11-16 20:42 ` Andrey Grodzovsky
2020-11-16 20:42 ` Andrey Grodzovsky
2020-11-19 10:01 ` Christian König
2020-11-19 10:01 ` Christian König
2020-06-21 6:03 ` [PATCH v2 2/8] drm/ttm: Remap all page faults to per process dummy page Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:41 ` Daniel Vetter
2020-06-22 9:41 ` Daniel Vetter
2020-06-24 3:31 ` Andrey Grodzovsky
2020-06-24 3:31 ` Andrey Grodzovsky
2020-06-24 7:19 ` Daniel Vetter
2020-06-24 7:19 ` Daniel Vetter
2020-11-10 17:41 ` Andrey Grodzovsky
2020-11-10 17:41 ` Andrey Grodzovsky
2020-06-22 19:30 ` Christian König
2020-06-22 19:30 ` Christian König
2020-06-21 6:03 ` [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:45 ` Daniel Vetter
2020-06-22 9:45 ` Daniel Vetter
2020-06-23 5:00 ` Andrey Grodzovsky
2020-06-23 5:00 ` Andrey Grodzovsky
2020-06-23 10:25 ` Daniel Vetter
2020-06-23 10:25 ` Daniel Vetter
2020-06-23 12:55 ` Christian König
2020-06-23 12:55 ` Christian König
2020-06-22 19:37 ` Christian König
2020-06-22 19:37 ` Christian König
2020-06-22 19:47 ` Alex Deucher
2020-06-22 19:47 ` Alex Deucher
2020-06-21 6:03 ` [PATCH v2 4/8] drm/amdgpu: Split amdgpu_device_fini into early and late Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:48 ` Daniel Vetter
2020-06-22 9:48 ` Daniel Vetter
2020-11-12 4:19 ` Andrey Grodzovsky
2020-11-12 4:19 ` Andrey Grodzovsky
2020-11-12 9:29 ` Daniel Vetter
2020-11-12 9:29 ` Daniel Vetter
2020-06-21 6:03 ` [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:51 ` Daniel Vetter
2020-06-22 9:51 ` Daniel Vetter
2020-06-22 11:21 ` Greg KH
2020-06-22 11:21 ` Greg KH
2020-06-22 16:07 ` Andrey Grodzovsky
2020-06-22 16:07 ` Andrey Grodzovsky
2020-06-22 16:45 ` Greg KH
2020-06-22 16:45 ` Greg KH
2020-06-23 4:51 ` Andrey Grodzovsky
2020-06-23 4:51 ` Andrey Grodzovsky
2020-06-23 6:05 ` Greg KH
2020-06-23 6:05 ` Greg KH
2020-06-24 3:04 ` Andrey Grodzovsky
2020-06-24 3:04 ` Andrey Grodzovsky
2020-06-24 6:11 ` Greg KH [this message]
2020-06-24 6:11 ` Greg KH
2020-06-25 1:52 ` Andrey Grodzovsky
2020-06-25 1:52 ` Andrey Grodzovsky
2020-11-10 17:54 ` Andrey Grodzovsky
2020-11-10 17:54 ` Andrey Grodzovsky
2020-11-10 17:59 ` Greg KH
2020-11-10 17:59 ` Greg KH
2020-11-11 15:13 ` Andrey Grodzovsky
2020-11-11 15:13 ` Andrey Grodzovsky
2020-11-11 15:34 ` Greg KH
2020-11-11 15:34 ` Greg KH
2020-11-11 15:45 ` Andrey Grodzovsky
2020-11-11 15:45 ` Andrey Grodzovsky
2020-11-11 16:06 ` Greg KH
2020-11-11 16:06 ` Greg KH
2020-11-11 16:34 ` Andrey Grodzovsky
2020-11-11 16:34 ` Andrey Grodzovsky
2020-12-02 15:48 ` Andrey Grodzovsky
2020-12-02 15:48 ` Andrey Grodzovsky
2020-12-02 17:34 ` Greg KH
2020-12-02 17:34 ` Greg KH
2020-12-02 18:02 ` Andrey Grodzovsky
2020-12-02 18:02 ` Andrey Grodzovsky
2020-12-02 18:20 ` Greg KH
2020-12-02 18:20 ` Greg KH
2020-12-02 18:40 ` Andrey Grodzovsky
2020-12-02 18:40 ` Andrey Grodzovsky
2020-06-22 13:19 ` Christian König
2020-06-22 13:19 ` Christian König
2020-06-21 6:03 ` [PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:56 ` Daniel Vetter
2020-06-22 9:56 ` Daniel Vetter
2020-06-22 19:38 ` Christian König
2020-06-22 19:38 ` Christian König
2020-06-22 19:48 ` Alex Deucher
2020-06-22 19:48 ` Alex Deucher
2020-06-23 10:22 ` Daniel Vetter
2020-06-23 10:22 ` Daniel Vetter
2020-06-23 13:16 ` Christian König
2020-06-23 13:16 ` Christian König
2020-06-24 3:12 ` Andrey Grodzovsky
2020-06-24 3:12 ` Andrey Grodzovsky
2020-06-21 6:03 ` [PATCH v2 7/8] drm/amdgpu: Fix sdma code crash post device unplug Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:55 ` Daniel Vetter
2020-06-22 9:55 ` Daniel Vetter
2020-06-22 19:40 ` Christian König
2020-06-22 19:40 ` Christian König
2020-06-23 5:11 ` Andrey Grodzovsky
2020-06-23 5:11 ` Andrey Grodzovsky
2020-06-23 7:14 ` Christian König
2020-06-23 7:14 ` Christian König
2020-06-21 6:03 ` [PATCH v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:53 ` Daniel Vetter
2020-06-22 9:53 ` Daniel Vetter
2020-11-17 18:38 ` Andrey Grodzovsky
2020-11-17 18:38 ` Andrey Grodzovsky
2020-11-17 18:52 ` Daniel Vetter
2020-11-17 18:52 ` Daniel Vetter
2020-11-17 19:18 ` Andrey Grodzovsky
2020-11-17 19:18 ` Andrey Grodzovsky
2020-11-17 19:49 ` Daniel Vetter
2020-11-17 19:49 ` Daniel Vetter
2020-11-17 20:07 ` Andrey Grodzovsky
2020-11-17 20:07 ` Andrey Grodzovsky
2020-11-18 7:39 ` Daniel Vetter
2020-11-18 7:39 ` Daniel Vetter
2020-11-18 12:01 ` Christian König
2020-11-18 12:01 ` Christian König
2020-11-18 15:43 ` Luben Tuikov
2020-11-18 15:43 ` Luben Tuikov
2020-11-18 16:20 ` Andrey Grodzovsky
2020-11-18 16:20 ` Andrey Grodzovsky
2020-11-19 7:55 ` Christian König
2020-11-19 7:55 ` Christian König
2020-11-19 15:02 ` Andrey Grodzovsky
2020-11-19 15:02 ` Andrey Grodzovsky
2020-11-19 15:29 ` Daniel Vetter
2020-11-19 15:29 ` Daniel Vetter
2020-11-19 21:24 ` Andrey Grodzovsky
2020-11-19 21:24 ` Andrey Grodzovsky
2020-11-18 0:46 ` Luben Tuikov
2020-11-18 0:46 ` Luben Tuikov
2020-06-22 9:46 ` [PATCH v2 0/8] RFC Support hot device unplug in amdgpu Daniel Vetter
2020-06-22 9:46 ` Daniel Vetter
2020-06-23 5:14 ` Andrey Grodzovsky
2020-06-23 5:14 ` Andrey Grodzovsky
2020-06-23 9:04 ` Michel Dänzer
2020-06-23 9:04 ` Michel Dänzer
2020-06-24 3:21 ` Andrey Grodzovsky
2020-06-24 3:21 ` Andrey Grodzovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200624061153.GA933050@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Andrey.Grodzovsky@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=michel@daenzer.net \
--cc=ppaalanen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.