Re: Common boot/shutdown issues with the latest 2.6.37 (Mostly Asuslaptops)
From: Lionel Debroux
Date: Thu Jan 27 2011 - 02:58:48 EST
On 26.01.2011 08:41, Lionel Debroux wrote:
>>>>>> * 2.6.35 series: .4 and .6 boot successfully, .8 and .10 fail;
>>>>>> * 2.6.36 series: -rc2 boots successfully, .1 fails;
>>>>>> * 2.6.37 series: -rc4 fails.
>>>>> So it's probably a commit to the mainline tree which was picked
>>>>> by 2.6.35 maintainer to the stable tree (probably it was CC'ed)
>>>>> cause this.
>>>>> Does passing nolapic or acpi=off cures the issue?
>>>> IIRC, I tested at least one of these, without improvement.
>>>> I'll test again tonight, when I can physically access the
>>> None of nolapic, acpi=off, nolapic acpi=off enables 22.214.171.124 to
>>> boot on my ASUS F3Jv-AS022P.
>>> The kernel line is
>>> kernel /boot/vmlinuz root=/dev/sda9 nomce vga=791 nomodeset
>>> I've attached the 126.96.36.199 config.
>> looks like you've bisected as far as:
>> 188.8.131.52 good
>> 184.108.40.206 bad
>> can you try 220.127.116.11 and continue on to find which specific patch
>> in .stable broke your machine?
> The bisection between 18.104.22.168 and 22.214.171.124 is in progress, two steps
> left and no good kernel found yet (?!)
> Due to not having physical access to the computer during work time, I
> won't be able to finish until tonight.
Bisection log of the
$ git bisect log
git bisect start
# good: [7273c1c64b2d4cb0ddfa7682ec7ab71dfe906398] Linux 126.96.36.199
git bisect good 7273c1c64b2d4cb0ddfa7682ec7ab71dfe906398
# bad: [f16e6e4df8ec41328d7e0841bc17f2a587eb2c67] Linux 188.8.131.52
git bisect bad f16e6e4df8ec41328d7e0841bc17f2a587eb2c67
# bad: [cd1bbdfed8ff5047d96ed27a3ee7b881069daf03] reiserfs: fix
dependency inversion between inode and reiserfs mutexes
git bisect bad cd1bbdfed8ff5047d96ed27a3ee7b881069daf03
# bad: [74352c5c9e2e5c914254d2588876c0c13333c6f5] V4L/DVB: gspca -
sn9c20x: Bad transfer size of Bayer images
git bisect bad 74352c5c9e2e5c914254d2588876c0c13333c6f5
# bad: [dc7237c6b7b529c5da2776cbb8b68cc74d1555c3] HID: hidraw, fix a
NULL pointer dereference in hidraw_ioctl
git bisect bad dc7237c6b7b529c5da2776cbb8b68cc74d1555c3
# bad: [e5d843fbf633dc65353bc08ee28f6b08ce651a4d] ALSA: hda - Add Dell
Latitude E6400 model quirk
git bisect bad e5d843fbf633dc65353bc08ee28f6b08ce651a4d
# bad: [9f09ac68e7af2001a24242cbe0f6e40e89dd6c62] x86, cpu: After
uncapping CPUID, re-run CPU feature detection
git bisect bad 9f09ac68e7af2001a24242cbe0f6e40e89dd6c62
--- up to this point, all kernels reboot ~1s after the messsage noting
vmlinuz being loaded disappears
# bad: [ea8a52f9f4bcc3420c38ae07f8378a2f18443970] Linux 184.108.40.206
git bisect bad ea8a52f9f4bcc3420c38ae07f8378a2f18443970
--- at this point, one commit before
9f09ac68e7af2001a24242cbe0f6e40e89dd6c62, the behaviour changes: the
computer does not reboot anymore, but it doesn't boot either. It hangs
with a backlit but black LCD. I let it alone for several minutes, it
I double-checked by swapping twice between this kernel and the previous
one (9f09ac68e7af2001a24242cbe0f6e40e89dd6c62), falling back to the
220.127.116.11 compiled in late September 2010 to get the computer to boot and
# bad: [b0dd220aefe1ab80823cf13e9588c64fec151488] Xen: fix typo in
git bisect bad b0dd220aefe1ab80823cf13e9588c64fec151488
--- at this point, the kernel reboots again as most of the kernels in
this bisection did. The problem is,
ea8a52f9f4bcc3420c38ae07f8378a2f18443970 is a tag commit...
And obviously, bisection ends in:
b0dd220aefe1ab80823cf13e9588c64fec151488 is the first bad commit
Author: James Dingwall <james.dingwall@xxxxxxxxxx>
Date: Mon Sep 27 09:37:17 2010 +0100
Xen: fix typo in previous patch
Correctly name the irq_chip structure to fix an immediate failure
as a xen pv_ops guest with a NULL pointer exception. The missing 'x' was
introduced in commit [fb412a178502dc498430723b082a932f797e4763]
2.6.3-stable trees. The commit to mainline was
[aaca49642b92c8a57d3ca5029a5a94019c7af69f] which did not have the
Signed-off-by: James Dingwall <james@xxxxxxxxxxxxxx>
Reported-by: Pawel Zuzelski <pawelz@xxxxxxxxxxxxx>
Tested-by: Pawel Zuzelski <pawelz@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
:040000 040000 81981a3f0c89adbdf28306b2dc23c631c815935f
ca642d7b5a94ad56c6179ba4d90e2281076672b9 M drivers
But none of that makes any sense for multiple reasons...
I guess it's time for me to:
* try recompiling older kernel versions that I previously successfully
compiled to a kernel in proper booting state. But the package
installation history in Synaptic between September 27th 2010 (last
working kernel so far) and November 23th 2010 (first bad kernel) doesn't
show any upgrade of binutils or gcc...
* try out other kernel series: 2.6.32, 2.6.34, 2.6.37 and the 2.6.38-rc
Sorry for the noise...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/