[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

[Dave Young]

On Wed, Oct 20, 2010 at 4:44 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Tuesday 19 October 2010 22:29:12 Greg KH wrote:
>> On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
>> > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
>> > > > So no need to clean it up for multiprocessor support.
>> > > >
>> > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf
>> > > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf
>> > >
>> > > Great, we can just drop all calls to lock_kernel() and the like in the
>> > > driver and be done with it, right?
>> >
>> > No,
>> >
>> > you still need to switch off preemption.
>>
>> Hm, how would you do that from within a driver?
>
> I think this would do:
> ---
> drm/i810: remove SMP support and BKL
>
> The i810 and i815 chipsets supported by the i810 drm driver were not
> officially designed for SMP operation, so the big kernel lock is
> only required for kernel preemption. This disables the driver if
> preemption is enabled and removes all calls to lock_kernel in it.
>
> If you own an Acorp 6A815EPD mainboard with a i815 chipset and
> two Pentium-III sockets, and want to run recent kernels on it,
> tell me about it.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b755301..e071bc8 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -73,8 +73,8 @@ source "drivers/gpu/drm/radeon/Kconfig"
>
>  config DRM_I810
>        tristate "Intel I810"
> -       # BKL usage in order to avoid AB-BA deadlocks, may become BROKEN_ON_SMP
> -       depends on DRM && AGP && AGP_INTEL && BKL
> +       # PREEMPT requires BKL support here, which was removed
> +       depends on DRM && AGP && AGP_INTEL && !PREEMPT

be curious, why can't just fix the lock_kernel logic of i810? Fixing
is too hard?

Find a i810 hardware should be possible, even if the hardware does not
support SMP, can't we test the fix with preemption?

-- 
Regards
dave