linux-kernel - Re: mptsas, msi and the dl585 g2

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:	Thu, 9 Jul 2009 12:59:46 -0600
From:	dann frazier <dannf@...com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	linux-scsi@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: mptsas, msi and the dl585 g2

On Sat, Jul 04, 2009 at 12:30:36PM -0700, Yinghai Lu wrote:
> dann frazier wrote:
> > On Tue, Jun 30, 2009 at 11:35:45AM -0700, Yinghai Lu wrote:
> >> dann frazier wrote:
> >>> hey,
> >>>  I'm finding problems when booting a dl585g2 w/ an LSISAS1068
> >>> controller. In brief, this system system stopped booting once MSI
> >>> became disabled by default in mptbase. Passing the parameter
> >>> 'mpt_msi_enable_sas=1' to mptbase allows it to work again (tested w/
> >>> 2.6.30).
> >>>
> >>>  The symptom is that the system starts up, and we see the following:
> >>>
> >>> ======== SNIP =========
> >>> [    6.941489] hub 3-2:1.0: USB hub found
> >>> [    6.943705] hub 3-2:1.0: 7 ports detected
> >>> [    6.992639] Copyright (c) 1999-2008 LSI Corporation
> >>> [    7.014262] Fusion MPT SAS Host driver 3.04.07
> >>> [    7.021685] mptsas 0000:42:01.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
> >>> [    7.026597] usb 1-6.3: new full speed USB device using ehci_hcd and address 3
> >>> [    7.071143] mptbase: ioc0: Initiating bringup
> >>> [    7.102198] usb 1-6.3: New USB device found, idVendor=0e34, idProduct=0204
> >>> [    7.119107] usb 1-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> >>> [    7.128171] usb 1-6.3: Product: iPort/USB I2C Host Adapter
> >>> [    7.160994] usb 1-6.3: Manufacturer: Silicon Labs
> >>> [    7.171468] usb 1-6.3: SerialNumber: 0001248
> >>> [    7.174931] usb 1-6.3: configuration #1 chosen from 1 choice
> >>> [    7.360010] ioc0: LSISAS1068 B0: Capabilities={Initiator}
> >>> [   40.581020] mptbase: ioc0: Initiating recovery
> >>> [   71.190560] Clocksource tsc unstable (delta = 4398041105588 ns)
> >>> [   81.190160] mptbase: ioc0: Initiating recovery
> >>> ======== SNIP =========
> >>>
> >>> These "Initiating recovery" messages are printed periodically, and the
> >>> system never recovers.
> >> Dann, that could be : ioapic routing in ACPI DSDT is not right somehow.
> >>
> >> please try to move the card to other slot to get some luck.
> >> or pci=routeirq could help too sometimes.
> > 
> > For the record, I tried moving the card to the other PCI-X slot and
> > the pci=routeirq boot param, but neither helped.
> > 
> 
> so 2.6.22.1 works on that system with pci=nomsi?
> 
> maybe your BIOS is too new, you may try the old BIOS.
> 
> updating BIOS is not always a option to deployed systems. maybe sustaining team could break sth.

Back with more info.

Both of the original bisects I did with cciss and mptsas appeared to
land on commits that just masked the issue. e.g., a cciss hang caused
by a bug w/ no logical drives, and mptsas switching toggling the MSI
default.

I tried to avoid these issues by doing another bisect w/ storage
attached to the cciss controller, and landed on this commit:

  --------------------------------------------------------------------
  commit 8d539108560ec121d59eee05160236488266221c
  Author: Linus Torvalds <torvalds@...ux-foundation.org>
  Date:   Thu May 8 18:41:48 2008 -0700

      Revert "PCI: remove default PCI expansion ROM memory allocation"

  This reverts commit 9f8daccaa05c14e5643bdd4faf5aed9cc8e6f11e, which
  was  reported to break X startup (xf86-video-ati-6.8.0).
  --------------------------------------------------------------------

>From that, I found that pci=norom avoids the problem. But, again, this
is just a masking commit - things used to work before 9f8dacc was
there.

I did another bisect, this time keeping the norom patches out
entirely. This landed on:

  --------------------------------------------------------------------
  commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029
  Author: Yinghai Lu <Yinghai.Lu@....COM>
  Date:   Tue Feb 19 03:21:20 2008 -0800

      x86: multi pci root bus with different io resource range, on
      64-bit
  --------------------------------------------------------------------

This appears to be the commit that actually introduced the issue.
I've attached dmesg w/ PCI DEBUG enabled from both sides of this
changeset, as well as a diff w/o printk timestamps.

Also note that #ifdef'ing out x86_pci_root_bus_res_quirks() in
amd_bus.c seems to avoid the problem as well.

-- 
dann frazier


View attachment "pre.dmesg" of type "text/plain" (81476 bytes)

View attachment "post.dmesg" of type "text/plain" (82111 bytes)

View attachment "dmesg.diff" of type "text/x-diff" (16104 bytes)