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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 27 Sep 2013 11:08:51 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Adam Radford <aradford@...il.com>
Subject: Re: [PATCH] PCI: add quirk for 3ware 9650SE controller

On Fri, 6 Sep 2013, Bjorn Helgaas wrote:

> >> >> > Commit d5dea7d95 ("PCI: msi: Disable msi interrupts when we initialize a
> >> >> > pci device") makes MSIs be forcibly disabled at boot time.
> >> >> >
> >> >> > It turns out that this breaks 3ware controller -- if MSIs are disabled
> >> >> > during PCI discovery of this controller, the device doesn't work properly
> >> >> > (it doesn't respond to any commands that are being sent to it after
> >> >> > initialization).
> 
> Is there a bug report for this issue?  

Yes, but unfortunately only in our internal bugzilla.

> It's nice to have a pointer to, e.g., a bugzilla.kernel.org bug report 
> with info such as dmesg logs, lspci output, etc., for future reference.  

It's a customer-reported issue, so I am gathering permission to make this 
information public (I don't think that'll be an issue).

I'll send up a followup afterwards.

> Maybe somebody will figure out a more generic change that could make 
> this quirk unnecessary, and details will help in figuring that out.
> 
> I assume the actual PCI discovery done in the PCI core works fine;
> it's just that the driver doesn't work if MSIs are disabled on the
> device.  If that's the case, can this be fixed by some driver change?
> Maybe the driver needs to enable MSI before it sends commands to the
> device?

I have tried it, but it still doesn't work. It seems like the device 
initialization is not finalized properly with MISs disabled; meaning the 
device is there (discovery has completed), but it "just doesn't work".

> Any description of what this failure looks like to a user?  How can a 
> user or a distro connect a symptom (driver timeout, console message, or 
> whatever) to this patch?

Will be hopefully part of the dmesg I will be providing later ... 
basically any commands sent to it time out.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ