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:	Tue, 13 Mar 2007 04:40:10 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
CC:	tglx@...utronix.de,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Jeff Garzik <jeff@...zik.org>, linux-ide@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	netdev@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: 2.6.21-rc3-git4 ata1.00: qc timeout (cmd 0xef) (crashdump kernel)

Stephen Hemminger wrote:
> On Tue, 13 Mar 2007 04:03:00 +0900
> Tejun Heo <htejun@...il.com> wrote:
> 
>> Stephen Hemminger wrote:
>>>> 1. the controller has IRQ stuck high (infrequent but possible)
>>>> 2. the IRQ is already requested by another device
>>>> 3. the IRQ gets disabled due to screaming interrupts at the moment
>>>> ata_piix does pci_enable_device().
>>>>
>>>> I think we can be much more resilient to screaming interrupts if we
>>>> enable device with IRQ disabled and enable it after the device is
>>>> initialized to some level, possibly when requesting IRQ.
>>> The first thing the skge driver does is do a chip reset, and that should
>>> cause IRQ to be disabled and cleared. The driver has no chance to
>>> fix it if the BIOS left the IRQ screaming...
>> What if we do something like...
>>
>> 	pci_intx(pdev, 0);
>> 	pci_enable_device(pdev);
>> 	/* initialize */
>> 	request_irq(blah blah...);
>> 	pci_intx(pdev, 1);
>>
>> Would this work for skge?
>>
> 
> Okay for testing, but any change like this should be done in the base
> PCI layer, not one off in a particular driver.

Yeap, it was a proof-of-concept pseudo code.  I attached a patch to do
above in skge.  Please point out if it is broken (e.g. intx needs to be
enabled earlier).

Michal, can you apply the attached patch and see whether it fixes the
problem.

Thanks.

-- 
tejun

View attachment "patch" of type "text/plain" (634 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ