Bug#826629: Possible offb unload fix.
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.
--
Len Sorensen
Reply to: