linux-kernel - [REGRESSION] [BISECT] ACPI+Inspiron 1545 = crash at xrstor

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

Message-ID: <4CE25536.9010908@nctritech.com>
Date:	Tue, 16 Nov 2010 04:56:06 -0500
From:	Jody Bruchon <jody@...ritech.com>
To:	linux-kernel@...r.kernel.org
Subject: [REGRESSION] [BISECT] ACPI+Inspiron 1545 = crash at xrstor_state()

  I previously reported an early boot crash on an Inspiron 1545 laptop; 
see previous posts for more details.  I used the parameters "debug vga=6 
earlyprintk=vga" to catch these errors since they happen so early in 
boot that the normal console has not yet initialized.

A picture of the crash dump from 2.6.37-rc2 is available here (2.6.36 
crash is identical except for the reported kernel version):
http://c02ware.com/bugs/dump_c7ff0d9c92435e836e13aaa8d0e56d4000424bcc.jpg

I have experienced similar problems on a small number of other systems 
also.  After confirming that the problem was introduced going from 
2.6.35 to 2.6.36, I have successfully bisected the kernel, and narrowed 
down and tested to verify the commit which introduced the problem.  
Reverting this commit fixes 2.6.36 but 2.6.37-rc2 has the exact same 
crash even if I revert it.  I don't know what to do from here, but 
someone with more knowledge can surely guide me.  I will only have the 
unit to test with for another day or two.  I have attached a suitable 
.config for reference as well.  The commit info is below.

Jody Bruchon

---

The commit which caused the problem in 2.6.36:

commit c7ff0d9c92435e836e13aaa8d0e56d4000424bcc
Author: TAMUKI Shoichi <tamuki@...et.gr.jp>
Date:   Tue Aug 10 18:03:28 2010 -0700

     panic: keep blinking in spite of long spin timer mode

     To keep panic_timeout accuracy when running under a hypervisor, the
     current implementation only spins on long time (1 second) calls to 
mdelay.
      That brings a good effect, but the problem is the keyboard LEDs don't
     blink at all on that situation.

     This patch changes to call to panic_blink_enter() between every 
mdelay and
     keeps blinking in spite of long spin timer mode.

     The time to call to mdelay is now 100ms.  Even this change will keep
     panic_timeout accuracy enough when running under a hypervisor.

View attachment ".config" of type "text/plain" (27720 bytes)