Control: tags -1 + patch On Tue, Oct 4, 2016 at 11:37 PM, Lennart Sorensen <[email protected]> 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.
