linux-kernel - Re: Panic from mptspi_dv_renegotiate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 02 Oct 2006 20:32:13 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Andrew Morton <akpm@...l.org>
CC:	"Moore, Eric" <Eric.Moore@...l.com>,
	Martin Bligh <mbligh@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andy Whitcroft <apw@...dowen.org>, linux-scsi@...r.kernel.org
Subject: Re: Panic from mptspi_dv_renegotiate_work in 2.6.18-mm2

Andrew Morton wrote:
> On Mon, 2 Oct 2006 17:21:08 -0600
> "Moore, Eric" <Eric.Moore@...l.com> wrote:
> 
>> On Monday, October 02, 2006 2:40 PM, Andrew Morton wrote: 
>>
>>> Yeah, Bryce@...l is hitting this.  Apparently it can be worked around
>>> by compiling the driver as a module.
>>>
>> What I saw in Bryces trace was the driver was not receiving interrupts
>> for
>> the first command sent after interrutps were enabled.  This was a config
>> page
>> for spi port pages.  Since this command timed out, an internal timeout
>> handler was called,
>> and we issued an internal host reset.  The host reset called each
>> driver,
>> such as mptspi, mptfc, mptsas,  callback handers.  That ended with
>> as pacin in mptspi, due to we assume ioc->hd to be a valid pointer.  
>> We don't allocate ioc->hd to well after mpt_attach, which is where the
>> config
>> page that timed out.    We could prevent the panic in mptspi, but that 
>> doesn't fix the problem why we are not getting interrupts.   
>>
>> I have a 2.6.18 gold kernel, and that works fine with modules.  
>> There are no changes in mpt stack since 2.6.18 that would effect
>> interrupts.  
>> Do you know of any changes in kernel effecting interrupts?   I suspect
>> that
>> modules versus linked drivers into kernel would matter, or would it?
> 
> There are lots and lots of interrupt changes, some now in mainline, some
> not.
> 
> There's a known-problematic PCI resource allocation bug now in mainline
> too.  It appears that this can cause devices to not get assigned an
> interrupt.
> 
> So yes, this is probably the trigger.  But as a secondary thing, it appears
> that the driver will crash if something goes wrong with the interrupt
> setup?

FWIW, I am seeing precisely this problem, in the latest -git.

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/