Problem with kexec on i386, linux-3.5

Christian Schaubschläger christian.schaubschlaeger at gmx.at
Fri Aug 17 02:58:37 EDT 2012


>> I bistcted that down to this patch:
>>
>> commit b566a22c23327f18ce941ffad0ca907e50a53d41
>> Author: Khalid Aziz <khalid.aziz at hp.com>
>> Date:   Fri Apr 27 13:00:33 2012 -0600
>>
>>     PCI: disable Bus Master on PCI device shutdown
>>    
>>     Disable Bus Master bit on the device in pci_device_shutdown() to ensure PCI
>>     devices do not continue to DMA data after shutdown.  This can cause memory
>>     corruption in case of a kexec where the current kernel shuts down and
>>     transfers control to a new kernel while a PCI device continues to DMA to
>>     memory that does not belong to it any more in the new kernel.
>>    
>>     I have tested this code on two laptops, two workstations and a 16-socket
>>     server.  kexec worked correctly on all of them.
>>    
>>     Signed-off-by: Khalid Aziz <khalid.aziz at hp.com>
>>     Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
>>
>>
>> Without this patch, int13 works fine here! If anyone needs more
>> information, just let me know!
> Which leads to an interesting conundrum.
>
> kexec appears to be more reliable for booting another kernel with this
> patch applied.  This patch does kill the entier use case of making BIOS
> calls, and I suspect it also does nasty things to alpha bootloaders.
>
> My gut feel is that the trampoline code should reenable bus mastering
> on the devices that lie behind int13, but I don't know how practical
> that suggestion is in reality.

One could make this patch optional... e.g. let kexec tell the running kernel whether or not to disable bus mastering before booting the new one (something like 'kexec --disable-bus-mastering -l /boot/new_kernel.bin'). Don't know if this would be practicable...

Christian




More information about the kexec mailing list