No screens after (WW) Falling back to old probe method for modesetting
Rafał Miłecki
zajec5 at gmail.com
Tue Jun 12 08:35:56 PDT 2012
2012/6/12 Rafał Miłecki <zajec5 at gmail.com>:
> 2012/6/11 Rafał Miłecki <zajec5 at gmail.com>:
>> I'm trying to switch from fbdev to modesetting for my AMD Southern
>> Islands VERDE card. Of course I've KMS running just fine, radeon
>> module loads and sets correct resolution, dmesg looks alright
>>
>> Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU
>> the driver doesn't provide any screens/modes. It looks like this:
>> (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
>> (WW) Falling back to old probe method for modesetting
>> (II) UnloadModule: "modesetting"
>> (II) Unloading modesetting
>> (EE) Screen(s) found, but none have a usable configuration.
>>
>> Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm
>> using xf86-video-modesetting from today's git. Any patch/trick to
>> debug this issue?
>
> I don't think old X server is an issue here. The function to focus on
> is probe_hw_pci.
>
> This function calls "open_hw" which opens /dev/dri/card0 and return fd
> (9 in my case, irrelevant). Then comes the moment when probe_hw_pci
> calls:
> id = drmGetBusid(fd);
> devid = ms_DRICreatePCIBusID(pdev);
>
> The first one returns NULL, the second one returns "pci:0000:03:00.0".
> As the "id" is NULL (empty string) probe_hw_pci returns false and the
> rest fails.
>
> I can't say why drmGetBusid returns NULL. My drm is from yesterday's
> git and DRM_IOCTL_GET_UNIQUE isn't something bleeding edge AFAIK.
> Hacking probe_hw_pci to return TRUE allows me start X with
> modesetting.
I've hacked xf86drm.c::drmGetBusid to print some debugging messages.
When we call "drmGetBusid" in "probe_hw_pci", u.unique_len gets 0 and
u.unique gets "\0".
However I've noticed there's one more call to "drmGetBusid". The stacktrace is:
PreInit → drmOpen(NULL, BusID) → drmOpenByBusid → drmGetBusid
In the above call, drmGetBusid gets u.unique_len gets 16 and u.unique
gets "pci:0000:03:00.0\0".
Does it give you any hint what can happen here?
--
Rafał
More information about the dri-devel
mailing list