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: