On 10/18/16 18:57, Greg Kroah-Hartman wrote:
> On Tue, Oct 18, 2016 at 05:52:20PM +0200, Laszlo Ersek wrote:
>> On 10/18/16 08:38, Greg Kroah-Hartman wrote:
>>> On Mon, Oct 17, 2016 at 11:10:28PM +0200, Laszlo Ersek wrote:
>>>> Greg,
>>>>
>>>> On 10/03/16 19:43, Laszlo Ersek wrote:
>>>>> Before commit a325725633c2 ("drm: Lobotomize set_busid nonsense for !pci
>>>>> drivers"), several DRM drivers for platform devices used to expose an
>>>>> explicit "drm_driver.set_busid" callback, invariably backed by
>>>>> drm_platform_set_busid().
>>>>>
>>>>> Commit a325725633c2 removed drm_platform_set_busid(), along with the
>>>>> referring .set_busid field initializations. This was justified because
>>>>> interchangeable functionality had been implemented in drm_dev_alloc() /
>>>>> drm_dev_init(), which DRM_IOCTL_SET_VERSION would rely on going forward.
>>>>>
>>>>> However, commit a325725633c2 also removed drm_virtio_set_busid(), for
>>>>> which the same consolidation was not appropriate: this .set_busid callback
>>>>> had been implemented with drm_pci_set_busid(), and not
>>>>> drm_platform_set_busid(). The error regressed Xorg/xserver on QEMU's
>>>>> "virtio-vga" card; the drmGetBusid() function from libdrm would no longer
>>>>> return stable PCI identifiers like "pci:0000:00:02.0", but rather unstable
>>>>> platform ones like "virtio0".
>>>>>
>>>>> Reinstate drm_virtio_set_busid() with judicious use of
>>>>>
>>>>> git checkout -p a325725633c2^ -- drivers/gpu/drm/virtio
>>>>>
>>>>> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
>>>>> Cc: Daniel Vetter <daniel.vetter@xxxxxxxxx>
>>>>> Cc: David Airlie <airlied@xxxxxxxxxx>
>>>>> Cc: Emil Velikov <emil.l.velikov@xxxxxxxxx>
>>>>> Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>
>>>>> Cc: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx>
>>>>> Cc: Hans de Goede <hdegoede@xxxxxxxxxx>
>>>>> Cc: Joachim Frieben <jfrieben@xxxxxxxxxxx>
>>>>> Cc: stable@xxxxxxxxxxxxxxx
>>>>> Reported-by: Joachim Frieben <jfrieben@xxxxxxxxxxx>
>>>>> Fixes: a325725633c26aa66ab940f762a6b0778edf76c0
>>>>> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1366842
>>>>> Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
>>>>> Reviewed-by: Emil Velikov <emil.l.velikov@xxxxxxxxx>
>>>>> ---
>>>>> drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 10 ++++++++++
>>>>> drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
>>>>> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
>>>>> 3 files changed, 12 insertions(+)
>>>>
>>>> Is there any particular reason this patch hasn't been cherry-picked to
>>>> linux-4.8.y? (I checked v4.8.2.)
>>>
>>> Yes, it just showed up in 4.9-rc1 3 days ago, give me a chance to catch
>>> up! I have 210 patches right now that are in this same status,
>>
>> My apologies; I didn't realize the volume.
>>
>> (
>> BTW I tried to fetch stable-queue this morning, and just now as well --
>> for some reason that git command seems consistently stuck for me. It
>> produces some low network traffic, but makes no progress:
>>
>>> Looking up git.kernel.org ... done.
>>> Connecting to git.kernel.org (port 9418) ... 199.204.44.194 done.
>>> <stuck here>
>>
>> Should I report this elsewhere and/or capture packets with tcpdump?
>
> Can you clone any other git.kernel.org tree?
>
> Works ok for me here...
Ultimately it succeeded from here as well, but it took 24 minutes and 42
seconds. The actual transfer speed was acceptable (2.95 MiB/s) and the
transfer was short:
Looking up git.kernel.org ... done.
Connecting to git.kernel.org (port 9418) ... 198.145.20.140 done.
<looooong wait>
remote: Counting objects: 32528, done.
remote: Compressing objects: 100% (15835/15835), done.
remote: Total 32528 (delta 16858), reused 31765 (delta 16547)
Receiving objects: 100% (32528/32528), 17.21 MiB | 2.95 MiB/s, done.
Resolving deltas: 100% (16858/16858), done.
>From git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue
64bb1fafb84e..4e6b3d9223d7 master -> stable-queue/master
I'm used to some navel gazing while the remote counts objects (also used
to brand new clones), but this time the delay occurred before that. It
could be related to my last pull from stable-queue (64bb1fafb84e) having
likely happened in April 2014... I guess "git fetch --verbose" could
have given me more info in that initial phase. (Using git version 2.9.2
at the moment.)
All the other remotes I regularly or occasionally pull from (Linus's,
kvm, stable, drm...) answer very quickly.
Sorry about the false alarm.
Thanks!
Laszlo
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html