linux-kernel - Re: 2.6.24-rc4-mm1: acpi reboots machine... solved

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] [day] [month] [year] [list]

Message-ID: <20071213212959.GA4522@gollum.tnic>
Date:	Thu, 13 Dec 2007 22:29:59 +0100
From:	Borislav Petkov <bbpetkov@...oo.de>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, len.brown@...el.com,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	trenn@...e.de
Subject: Re: 2.6.24-rc4-mm1: acpi reboots machine... solved

On Thu, Dec 13, 2007 at 09:17:18AM -0700, Bjorn Helgaas wrote:
> On Thursday 13 December 2007 12:09:23 am Borislav Petkov wrote:
> > On Wed, Dec 12, 2007 at 09:21:41AM -0700, Bjorn Helgaas wrote:
> > > On Wednesday 12 December 2007 03:11:23 am Borislav Petkov wrote:
> > > > On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
> > > > > On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
> > > > > > From what i can roughly tell so far it seems like an resource conflict between acpi and
> > > > > > the pnp requested regions in your patch which result in the acpi_thermal code
> > > > > > to read the wrong (0xff) temperature value and halt the machine, but i might be
> > > > > > wrong on the details since acpi is such a big code chunk to swallow.
> > > > > 
> > > I think Alexey is on the right track with the PCI resource allocation
> > > failure.
> > 
> > Then it should be the SMBus controller, PCI id 00:1f:3, which is having problems
> > registering its io ports region 4, AFAICT.
> 
> Yes, it looks like the ioport region 0x540-0x55f is described both in
> PNP and ACPI:
> 
>   /sys/devices/pnp0/00:0d/resources:state = active
>   /sys/devices/pnp0/00:0d/resources:io 0x540-0x55f
>   /sys/devices/pnp0/00:0d/resources:io 0x400-0x47f
> 
>   00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03)
>         Subsystem: ASUSTeK Computer Inc. Unknown device 1869
>         Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Interrupt: pin B routed to IRQ 0
>         Region 4: I/O ports at 0540 [size=32]
> 
> The PCI SMBus device was enabled by a quirk, asus_hides_smbus_lpc().
> 
> This quirk seems dangerous to me, and the comments above asus_hides_smbus
> allude to problems similar to what you're seeing.  It's obvious that a
> lot of blood, sweat, and tears have gone into this quirk, so I'm not
> suggesting that it's time to revert it, but I would be interested in
> knowing whether the critical temperature problem goes away if we leave
> the PCI device hidden, e.g., with the following patch:
> 
> Index: linux-mm/drivers/pci/quirks.c
> ===================================================================
> --- linux-mm.orig/drivers/pci/quirks.c	2007-12-13 09:11:31.000000000 -0700
> +++ linux-mm/drivers/pci/quirks.c	2007-12-13 09:12:27.000000000 -0700
> @@ -1073,12 +1073,7 @@
>  
>  	pci_read_config_word(dev, 0xF2, &val);
>  	if (val & 0x8) {
> -		pci_write_config_word(dev, 0xF2, val & (~0x8));
> -		pci_read_config_word(dev, 0xF2, &val);
> -		if (val & 0x8)
> -			printk(KERN_INFO "PCI: i801 SMBus device continues to play 'hide and seek'! 0x%x\n", val);
> -		else
> -			printk(KERN_INFO "PCI: Enabled i801 SMBus device\n");
> +		printk(KERN_INFO "PCI: Leaving i801 SMBus device hidden\n");
>  	}
>  }
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82801AA_0,	asus_hides_smbus_lpc);

yep, this fixes it. Bootlog attached.

-- 
Regards/Gruß,
    Boris.

Download attachment "bootlog-smbus-hidden.bz2" of type "application/octet-stream" (9010 bytes)