On Wed, Oct 17, 2007 at 08:46:48PM +0200, Willy Tarreau wrote:
> Sincere thanks for your help and review. I'll apply this patch in
> 2.4.36-pre2 and in next 2.4.35.X. An ugly fix is clearly better than
> a massive change at this stage.
You're most welcome. I have no desire to act as maintainer fo
On Wed, Oct 17, 2007 at 10:27:47AM -0600, Matthew Wilcox wrote:
> On Wed, Oct 17, 2007 at 10:53:06AM -0400, Tony Battersby wrote:
> > After looking at it carefully, this is true of pci_map_mem, but not
> > pci_unmap_mem. pci_unmap_mem can be called from both ->detect and
> > ->release. io_request
On Wed, Oct 17, 2007 at 10:53:06AM -0400, Tony Battersby wrote:
> After looking at it carefully, this is true of pci_map_mem, but not
> pci_unmap_mem. pci_unmap_mem can be called from both ->detect and
> ->release. io_request_lock is held in ->detect but not in ->release.
> So, your patch locks u
This patch fixes two problems with sym53c8xx_2.o in 2.4.x kernels:
1) A system hang when loading sym53c8xx_2.o on a SMP system with two
dual-channel LSI HBAs (http://bugzilla.kernel.org/show_bug.cgi?id=3680)
2) A function improperly marked __init.
Signed-off-by: Tony Battersby <[EMAIL PROTECTED]
On Wed, Oct 17, 2007 at 11:44:08AM -0400, Tony Battersby wrote:
> In 2.4, include/linux/init.h has the following:
>
> #ifndef MODULE
> #define __init __attribute__ ((__section__ (".text.init")))
> #else
> #define __init
> #endif
>
> So __init has an effect only if it is built-in.
Ah yes
On Wed, Oct 17, 2007 at 10:53:06AM -0400, Tony Battersby wrote:
> > So we should unconditionally drop the lock (and re-enable
> > interrupts) and re-acquire it.
>
> After looking at it carefully, this is true of pci_map_mem, but not
> pci_unmap_mem. pci_unmap_mem can be called from both ->detect
Willy Tarreau wrote:
> On Wed, Oct 17, 2007 at 10:53:06AM -0400, Tony Battersby wrote:
>
>>> So we should unconditionally drop the lock (and re-enable
>>> interrupts) and re-acquire it.
>>>
>> After looking at it carefully, this is true of pci_map_mem, but not
>> pci_unmap_mem. pci_unmap
> So we should unconditionally drop the lock (and re-enable
> interrupts) and re-acquire it.
After looking at it carefully, this is true of pci_map_mem, but not
pci_unmap_mem. pci_unmap_mem can be called from both ->detect and
->release. io_request_lock is held in ->detect but not in ->release.
8 matches
Mail list logo