[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#826629: Possible offb unload fix.



Control: tags -1 + patch

On Tue, Oct 4, 2016 at 11:37 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Tue, Oct 04, 2016 at 09:39:12PM +0200, Mathieu Malaterre wrote:
>> Here is what I see:
>>
>> [   52.270154] bus: 'pci': add driver radeonfb
>> [   52.270224] bus: 'pci': driver_probe_device: matched device
>> 0000:00:10.0 with driver radeonfb
>> [   52.270233] bus: 'pci': really_probe: probing driver radeonfb with
>> device 0000:00:10.0
>> [   52.270256] devices_kset: Moving 0000:00:10.0 to end of list
>> [   52.270264] radeonfb_pci_register BEGIN
>> [   52.270267] radeonfb: MM1
>> [   52.275001] radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
>> [   52.279727] radeonfb: MM2
>> [   52.295202] radeonfb: MM3
>> [   52.299816] radeonfb: MM4
>> [   52.304934] radeonfb: MM0 98000000 8000000 radeonfb
>> [   52.309768] checking generic (9c008000 96000) vs hw (98000000 8000000)
>> [   52.309776] fb: switching to radeonfb from OFfb ATY,RockHo
>> [   52.315075] Console: switching to colour dummy device 80x25
>> [   52.315595] device: 'fb0': device_unregister
>> [   52.315736] PM: Removing info for No Bus:fb0
>> [   52.317348] device: 'fb0': device_create_release
>> [   52.317407] radeonfb: MM5 0
>> [   52.317447] device: 'vtcon1': device_unregister
>> [   52.317500] PM: Removing info for No Bus:vtcon1
>> [   52.317565] device: 'vtcon1': device_create_release
>> [   52.318992] radeonfb 0000:00:10.0: BAR 0: can't reserve [mem
>> 0x98000000-0x9fffffff pref]
>> [   52.319029] radeonfb (0000:00:10.0): cannot request region 0.
>> [   52.319066] radeonfb: probe of 0000:00:10.0 failed with error -16
>
> So offb_destroy is NOT called.  Well that explains the problem.
>
> Unfortunately it seems the reason it isn't called is that the
> fb->info->count is not zero, because it is still open.  I am not sure
> how the ability to unregister a conflicting framebuffer is supposed to
> work if it stays active until it is replaced.
>
> The kick out appears to successfully remove offb from being the active
> fb, but since the release hasn't been called yet, the resources are not
> yet freed, so radeonfb fails when trying to reserve them.  If offb_destroy
> had been called the resources would be free and there would almost
> certainly not be a problem.
>
> Now the radeon.ko gets away with this because it doesn't try to reserve
> the memory and never calls pci_request_region at all.
>
> How about adding this to your patch:
>
> --- a/drivers/video/fbdev/aty/radeon_base.c
> +++ b/drivers/video/fbdev/aty/radeon_base.c
> @@ -2319,14 +2319,14 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
>         if (ret < 0) {
>                 printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
>                         pci_name(rinfo->pdev));
> -               goto err_release_fb;
> +               //goto err_release_fb;
>         }
>
>         ret = pci_request_region(pdev, 2, "radeonfb mmio");
>         if (ret < 0) {
>                 printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
>                         pci_name(rinfo->pdev));
> -               goto err_release_pci0;
> +               //goto err_release_pci0;
>         }
>
>         /* map the regions */
>
> So it will still complain, but it will ignore the fact the memory
> reservation failed, and still continue and do the ioremap and try to
> use it.
>
> That is how radeon.ko works as far as I can tell.
>
> Of course once that is done, then the changes to offb.c become irrelevant.

Very impressive ! I'll clean it up and ask upstream for review.


Reply to: