This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 845388 - kernel-3.5.0-2.fc17.i686 doesn't boot on Dell Latitude D610
kernel-3.5.0-2.fc17.i686 doesn't boot on Dell Latitude D610
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-02 18:04 EDT by Stuart D Gathman
Modified: 2013-01-02 23:08 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-02 12:56:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
lspci output (dell precision m4500) (36.44 KB, application/octet-stream)
2012-08-13 04:54 EDT, Martin Garton
no flags Details
dmesg output (dell precision m4500) (66.73 KB, application/octet-stream)
2012-08-13 04:54 EDT, Martin Garton
no flags Details
lspci.out - Dell Latitude D610 (9.44 KB, text/plain)
2012-08-13 09:11 EDT, Stuart D Gathman
no flags Details
dmesg.out - Dell Latitude D610 (78.30 KB, text/plain)
2012-08-13 09:13 EDT, Stuart D Gathman
no flags Details
lspci.out - Dell Optiplex 170L (**Working**) (8.34 KB, text/plain)
2012-08-13 12:10 EDT, Stuart D Gathman
no flags Details
dmesg.out - Dell Optiplex 170L (**Working**) (48.75 KB, text/plain)
2012-08-13 12:11 EDT, Stuart D Gathman
no flags Details
dmesg output from FC17 3.4 on Acer Ferrari 4006 (76.12 KB, text/plain)
2012-08-13 13:16 EDT, D S
no flags Details
sudo lspci -vvnn output from Acer Ferrari 4006 (21.21 KB, text/plain)
2012-08-13 13:18 EDT, D S
no flags Details
dmesg Latitude-D410 running 3.5.2 32bit with modified grub options. (65.48 KB, text/plain)
2012-08-18 21:01 EDT, Reilly Hall
no flags Details
lspci -v Latitude-D410 running 3.5.2 32bit with modified grub options. (5.54 KB, text/plain)
2012-08-18 21:02 EDT, Reilly Hall
no flags Details
X.org.0.log Latitude-D410 running 3.5.2 32bit with modified grub options. (73.40 KB, text/x-log)
2012-08-18 21:36 EDT, Reilly Hall
no flags Details
dmesg output from FC17 3.5 on Acer Ferrari 4006 (58.01 KB, application/octet-stream)
2012-08-18 22:45 EDT, D S
no flags Details
sudo lspci -vvnn output from FC17 3.5 on Acer Ferrari 4006 (21.18 KB, application/octet-stream)
2012-08-18 22:47 EDT, D S
no flags Details
grub.cfg Latitude-D410 (5.62 KB, application/octet-stream)
2012-08-20 00:19 EDT, Reilly Hall
no flags Details
grub.cfg Latitude D610 (12.68 KB, text/plain)
2012-08-20 08:20 EDT, Stuart D Gathman
no flags Details
3.5 kernels video braindamage - Acer 5670 (445.49 KB, image/jpeg)
2012-08-28 23:16 EDT, Stuart D Gathman
no flags Details
Comment (85.67 KB, text/plain)
2012-08-17 15:23 EDT, Calculici
no flags Details

  None (edit)
Description Stuart D Gathman 2012-08-02 18:04:52 EDT
Description of problem:
Boot hangs after "loading initramfs"

Version-Release number of selected component (if applicable):
kernel-3.5.0-2.fc17.i686

How reproducible:
always

Steps to Reproduce:
1. Update to kernel-3.5.0-2.fc17.i686 on Dell Latitude D610
2. reboot
3.
  
Actual results:
After printing "loading initramfs", screen clears and nothing else happens

Expected results:
normal boot

Additional info:
kernel-3.4.6-2.fc17.i686 still works, so it isn't some other upgraded package.  My guess is that something changed with KMS for Intel.
Comment 1 David L. Crow 2012-08-02 23:04:15 EDT
I see the same thing on an OptiPlex GX620 and the 64-bit kernel: kernel-3.5.0-2.fc17.x86_64.

When I removed the "quiet" kernel flag, the last line that printed was

  fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver

(This is actually a cut-n-paste from dmesg output after booting the 3.4.6-2 kernel, but I am pretty sure it was the last line when the boot failed.)
Comment 2 David L. Crow 2012-08-02 23:19:11 EDT
The 3.5.0-2.fc17.x86_64 does successfully boot on my Thinkpad T510.
Comment 3 Nazar Mishturak 2012-08-03 04:48:59 EDT
I had the same bug. Remove quiet parameter and rhgb from kernel command line.
Comment 4 Josh Boyer 2012-08-03 08:18:00 EDT
Sounds like a duplicate of bug 843826
Comment 5 D S 2012-08-03 13:58:05 EDT
My Ferrari 4006 (Fedora 32 bit intalled) failed to boot after I upgraded from Fedora (3.4.6-2.FC17.i686.PAE) to Fedora (3.5.0-2.FC17.i686.PAE) a couple of days ago.

Fedora (3.4.6-2.FC17.i686.PAE) still boots and works as expected.

3.5.0-2 displays a message that says loading initial ram disk after a few seconds the screen goes blank (these steps always occur).

After about 20 seconds I expect to see a prompt to enter encryption password, but the prompt never appears.

After 30-45 seconds the fan goes into high gear. Waited an additional 60-120 seconds. Still no prompt appeared.
Comment 6 Walter Neumann 2012-08-04 10:38:17 EDT
Same here with Dell latitude D410: Blank screen after "loading initial ramdisk" and no activity. Ctl-alt-del works to restart and 3.4.6 kernel boots fine.
Comment 7 D S 2012-08-04 23:33:32 EDT
*** boot and selected Fedora (3.5.0-2.FC17.i686.PAE)

removed "rhgb quiet" from kernel command line

ctrl-x

last line that displayed on my screen was (if I wrote it down correctly):
2.455884 fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver

*** boot fails so I cannot use dmesg - is there a way to retrieve this data (dmesg) after the next boot?

*** rebooted and selected Fedora (3.4.6-2.FC17.i686.PAE)

removed "rhgb quiet" from the kernel command line

ctrl-x

booted

$ dmesg >dmesg.out

[    2.039704] [drm] fb mappable at 0xC80C0000
[    2.039713] [drm] vram apper at 0xC8000000
[    2.039717] [drm] size 7057408
[    2.039721] [drm] fb depth is 24
[    2.039724] [drm]    pitch is 6720
[    2.039858] fbcon: radeondrmfb (fb0) is primary device

Let me know if dmesg.out might be useful
Comment 8 Josh Boyer 2012-08-05 10:30:06 EDT
Do any of you see this "conflicting fb hw.." message in dmesg for 3.4 boots?
Comment 9 Walter Neumann 2012-08-05 12:50:21 EDT
(In reply to comment #8)
> Do any of you see this "conflicting fb hw.." message in dmesg for 3.4 boots?

Not me
Comment 10 D S 2012-08-05 14:22:11 EDT
I don't either. I only see it in 3.5 boots.

Does dmesg text survive a reboot? If so, how do I retrieve it?
Comment 11 David L. Crow 2012-08-05 16:21:27 EDT
I do see the "conflicting fb hw usage ..." message when booting the 3.4.6-2.fc17.x86_64 kernel.  Here are the surrounding lines from dmesg when booted from that kernel

[    6.413595] Freeing unused kernel memory: 1000k freed
[    6.414164] Write protecting the kernel read-only data: 12288k
[    6.421381] Freeing unused kernel memory: 2024k freed
[    6.427605] Freeing unused kernel memory: 1484k freed
[    6.492616] dracut: dracut-018-78.git20120622.fc17
[    6.528405] dracut: rd.luks=0: removing cryptoluks activation
[    6.555614] udevd[110]: starting version 182
[    6.596244] [drm] Initialized drm 1.1.0 20060810
[    6.643718] i915 0000:00:02.0: setting latency timer to 64
[    6.696612] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    6.696619] [drm] Driver supports precise vblank timestamp query.
[    6.696693] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    6.740968] [drm] initialized overlay support
[    6.787802] checking generic (e0000000 760000) vs hw (e0000000 10000000)
[    6.787807] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[    6.787833] Console: switching to colour dummy device 80x25
[    6.788828] fbcon: inteldrmfb (fb0) is primary device
[    6.823504] Console: switching to colour frame buffer device 200x75
[    6.830251] fb0: inteldrmfb frame buffer device
[    6.830254] drm: registered panic notifier
[    6.830263] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[    6.880834] dracut: Starting plymouth daemon
[    6.992562] dracut: rd.dm=0: removing DM RAID activation
[    7.011335] dracut: rd.md=0: removing MD RAID activation
[    7.141675] Initializing USB Mass Storage driver...
Comment 12 David L. Crow 2012-08-05 16:51:51 EDT
Something happened today and the 3.5.0-2.fc17.x86_64 kernel is booting.

Per the suggestion in bug 843826, I added drm.debug=7 to my kernel args, and the kernel booted.  dmesg was too full to get anything interesting from the early boot (the oldest entry was at 490 seconds - I had a 1 TB filesystem that had to be checked on boot), so I tried to boot again without the debug flag and it succeeded.

I have now booted 4 times in the 3.5.0-2.fc17.x86_64 kernel without issue.

I have no idea what changed.
Comment 13 D S 2012-08-06 00:20:11 EDT
After reading David's msg above I tried similar.

1. booted 3.5 without change to kernel command line (using USB kybd and mouse)
2. loading initial ramdisk ...
3. waited 60-120 seconds without response (well beyond the 15 seconds that I usually get a prompt to enter encrypted disk passphrase).
4. boot failed.

5. booted 3.5 replaced "rhgb quiet" with "drm.debug=7" (using USB kybd and mouse)
6. loading inital ramdisk ...
7. 2.456428 fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
8. boot failed

9. bootd 3.5  with "rhgb quiet" replaced with "drm.debug=7" (all USB, firewire devices, speakers and microphone unplugged)
10. loading initial ramdisk ...
11. 1.181911 fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
12. waited 60-120 seconds without response (well beyond the 15 seconds that I usually get a prompt to enter encrypted disk passphrase).
13. boot failed.

14. successfully booted 3.4
Comment 14 David Sugar 2012-08-06 17:23:27 EDT
I believe 845631 is a dup of this or at least related; same issue different hardware
Comment 15 Walter Neumann 2012-08-11 13:55:11 EDT
Still the same problem with Kernel 3.5.1-1.fc17.i686.
Comment 16 Stuart D Gathman 2012-08-11 14:34:05 EDT
Confirmed here also with D610 - kernel-3.5.1 still doesn't boot.
Comment 17 Stuart D Gathman 2012-08-11 14:34:51 EDT
I tried to give bad karma, but bodhi gets an internal error.
Comment 18 Dave Airlie 2012-08-12 21:31:30 EDT
can someone drop a complete dmesg from a working boot with 3.4 as an attachment, and if you can get a 3.5 boot, a full dmesg from it as well.

also lspci -vvnn as root would be nice from an affected system
Comment 19 Martin Garton 2012-08-13 04:54:04 EDT
Created attachment 603899 [details]
lspci output (dell precision m4500)

lspci output (dell precision m4500) sucessful boot on 3.3.4-5.fc17.x86_64
Comment 20 Martin Garton 2012-08-13 04:54:48 EDT
Created attachment 603901 [details]
dmesg output (dell precision m4500)

dmesg output (dell precision m4500) sucessful boot on 3.3.4-5.fc17.x86_64
Comment 21 Dave Airlie 2012-08-13 06:10:06 EDT
Martin you are seeing this problem with nouveau as well?
Comment 22 Martin Garton 2012-08-13 08:43:49 EDT
As far as I know I am using nouveau, and I yes I see the problem when booting with the newer kernel.
Comment 23 Martin Garton 2012-08-13 08:47:01 EDT
In case it's important, it has occured to me from reading back over the comments above that my hang maybe a bit later in the boot process than some of the other folks (for me the fedora logo appears but never gets aroudn to disappearing), so it's possible there is more than one bug.
Comment 24 Stuart D Gathman 2012-08-13 09:11:56 EDT
Created attachment 604002 [details]
lspci.out - Dell Latitude D610
Comment 25 Stuart D Gathman 2012-08-13 09:13:28 EDT
Created attachment 604004 [details]
dmesg.out - Dell Latitude D610
Comment 26 Stuart D Gathman 2012-08-13 12:10:41 EDT
Created attachment 604037 [details]
lspci.out - Dell Optiplex 170L (**Working**)

This is lspci from a system that *does* boot with 3.5 kernels, for comparison.
Comment 27 Stuart D Gathman 2012-08-13 12:11:43 EDT
Created attachment 604038 [details]
dmesg.out - Dell Optiplex 170L (**Working**)

This is dmesg from a system that *does* boot, for comparison.
Comment 28 Walter Neumann 2012-08-13 12:48:32 EDT
(In reply to comment #23)
> In case it's important, it has occured to me from reading back over the
> comments above that my hang maybe a bit later in the boot process than some
> of the other folks (for me the fedora logo appears but never gets aroudn to
> disappearing), so it's possible there is more than one bug.

This happened to me once in several attempts to boot (and that one time I was then not able to restart using ctl-alt-del; I had to use the power switch).
Comment 29 D S 2012-08-13 13:16:41 EDT
Created attachment 604055 [details]
dmesg output from FC17 3.4 on Acer Ferrari 4006
Comment 30 D S 2012-08-13 13:18:42 EDT
Created attachment 604056 [details]
sudo lspci -vvnn output from Acer Ferrari 4006
Comment 31 Stuart D Gathman 2012-08-15 20:08:21 EDT
kernel-3.5.2 still broken.  You can test and leave karma at https://admin.fedoraproject.org/updates/kernel-3.5.2-1.fc17
Comment 32 Dave Airlie 2012-08-15 20:17:36 EDT
My thinking is the only way we'll track this down is for one or two brave souls to take on an upstream kernel bisection between 3.4 and 3.5

I'm not able to reproduce this here on machines I have, and it seems like some combination of grub2/kernel/hardware is required to trigger it.

One of the kernel guys or myself could probably lead someone through a bisection procedure.
Comment 33 Stuart D Gathman 2012-08-16 13:34:21 EDT
Ok, looking at the lspci outputs, the thing that jumps out at me is that all the failing systems have IDE controllers, and all the working systems have SATA controllers.  Any counterexamples to this?  Note: the Dell m4500 is SATA, but gets much farther in the boot process and is probably a different bug.

Most interesting is the 170L that I posted in comment#26.  That has both an IDE and a SATA controller, and is currently running from the SATA controller.  I wonder if it would fail if I stuck in a PATA disk?

The IDE laptop is returning to college in a few days, so I can't help with the bisection unless the IDE disk turns out to be the trigger so that I can test on the 170L.
Comment 34 Stuart D Gathman 2012-08-16 18:52:04 EDT
It seems the D610 actually has a SATA controller, and uses a SATA->PATA bridge to connect PATA drives.  (Apparently, the T43 thinkpad did the same thing.)  The dmesg output from other failing systems seem to have a similar setup - there is a SATA controller for ata1 - with a PATA drive attached through a bridge.  

(Some people actually modify their T43 to remove the SATA-PATA bridge and install a SATA connector.)
Comment 35 Stuart D Gathman 2012-08-17 10:30:26 EDT
Is there a kernel already built partway between 3.4 and 3.5 I could test?  Or do they have to be built?
Comment 36 Josh Boyer 2012-08-17 11:58:02 EDT
(In reply to comment #35)
> Is there a kernel already built partway between 3.4 and 3.5 I could test? 
> Or do they have to be built?

We have a large number of kernels for the 3.5 development window.  They were built in rawhide, so they end in f18 but should be mostly compatible.  You can find them in koji:

http://koji.fedoraproject.org/koji/packageinfo?packageID=8

There's a koji-bisect script as well:

http://jwboyer.livejournal.com/43007.html
Comment 37 Calculici 2012-08-17 15:23:18 EDT
Created attachment 915484 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Comment 38 wagner17 2012-08-17 21:23:34 EDT
I started a kernel bisection using a kernel.org kernel.  I got a failure to boot on the 7th boot on 3.5.0 and had 20 successful boots on 3.4.0.  I also got a failure to boot on the 3rd boot on the 1st in-between kernel.
Comment 39 Reilly Hall 2012-08-18 20:58:52 EDT
Hi, I'd like to chime in to say I own both a Latitude D410 (that as noted above does not successfully boot a 3.5.x kernel but 3.4.6 boots fine on) as well as an IBM ThinkPad T43 that has the same exact setup with no problems booting the aformentioned 3.5.x kernels.  Both have similar Intel Pentium M CPUs and Intel based video.

But I'm writing to explain how I was able to convince my Latitude-D410 to boot the failing kernels.

I played around with the grub settings that loaded the 3.5.x kernels until I found a combination of settings that work.

First you need to hit 'e' when grub is about to boot the kernel, then remove the first two lines that read:

load_video
set gfxpayload=keep

Then modify the 'linux' line and remove 'rhgb quiet' and replace with 'nomodeset'.

Hit Ctrl-x and the system will proceed to boot in a text mode only form.  If you employ full drive encryption, take note of a simplistic text prompt for your password, then eventually X will load and all is good again.

Only thing I noticed is that the fonts appear different this way and I also suspect video acceleration is gone, unsure why.

I am including a copy of both dmesg and lspci running the 3.5.2 x86 kernel on my Latitude-D410 with the grub modifications I listed.

Please do not hesitate to ask me for more help in testing this as I'd like to be able to boot my Latitude with the same ease as I boot my ThinkPad.
Comment 40 Reilly Hall 2012-08-18 21:01:35 EDT
Created attachment 605436 [details]
dmesg Latitude-D410 running 3.5.2 32bit with modified grub options.
Comment 41 Reilly Hall 2012-08-18 21:02:18 EDT
Created attachment 605437 [details]
lspci -v Latitude-D410 running 3.5.2 32bit with modified grub options.
Comment 42 Reilly Hall 2012-08-18 21:35:09 EDT
Ok I'm writing again to note that while I can get the system to boot with those modifications to the grub config...I just figured out why the fonts appear different and why there doesn't appear to be any video acceleration.

It doesn't appear to be running an Intel X video driver, but rather the VESA driver.  I guess that's better than nothing, but I didn't think VESA was provided with the BIOSes of modern computers.  I suppose my Latitude D410 isn't exactly that new any more.

I am including a copy of X.org.0.log to show how X initialized itself with this kernel and those modified grub options.
Comment 43 Reilly Hall 2012-08-18 21:36:17 EDT
Created attachment 605447 [details]
X.org.0.log Latitude-D410 running 3.5.2 32bit with modified grub options.
Comment 44 Stuart D Gathman 2012-08-18 21:45:19 EDT
Trying the recipie in comment#39, on the D610 with 3.5.2 32bit, nomodeset allows booting to proceed, but Xorg shows a blank screen.  I can switch to a text console, however.

If I leave in the load_video and set gfxpayload=keep lines, then booting proceeds (as evidenced by the disk activity light), but Xorg shows a black screen, and attempting to switch to a text console briefly displays the login menu before blanking the screen again.  Ctrl-Alt-Del does initiate a controlled reboot.

The fact that nomodeset allows booting to proceed seems to rule out the IDE connection.  This is yet another problem with kernel modeset.

lspci and dmesg already posted previously
Comment 45 Stuart D Gathman 2012-08-18 21:54:57 EDT
(In reply to comment #37)
> Same problem with Dell Latitude D410.
> Last working kernel 3.4.5-2.fc17.i686

Could you please add your dmesg as an attachment and delete that humongous comment?
Comment 46 D S 2012-08-18 22:40:58 EDT
Followed the steps listed in comment #39. My laptopp booted with FC17 3.5

The response (keyboard and mouse) is *very* sluggish, but the Gnome 3 GUI *is* working. I'll attach output from dmesg and lspci -vvnn
Comment 47 D S 2012-08-18 22:45:22 EDT
Created attachment 605449 [details]
dmesg output from FC17 3.5 on Acer Ferrari 4006

Gnome 3 GUI is working the mouse and keyboard are *very* sluggish
Comment 48 D S 2012-08-18 22:47:49 EDT
Created attachment 605450 [details]
sudo lspci -vvnn output from FC17 3.5 on Acer Ferrari 4006

Gnome 3 GUI is working, but the mouse and kybd are *very* sluggish
Comment 49 Dave Airlie 2012-08-19 18:14:13 EDT
So does it boot if you remove the grub lines but don't add nomodeset?
Comment 50 D S 2012-08-19 19:54:14 EDT
using my Acer Ferrari 4006 I attempted to boot Fedora (3.5.0-2.fc17.i686.PAE)

(I realize that's not the newest kernel)

Removed:

load_video
set gfxpayload=keep

and removed 'rhgb quiet'

ctrl/x

Last line to appear on the screen was:
1.051600 radeon 0000:01:00.0: radeon: using MSI.

waited a min or two (60-120 seconds) and pressed the ENTER button (expecting the screen to go blank then display a text msg asking for a password to unlock the hard drive), but nothing happened.

failed to boot when I did not use 'nomodeset'

Has anyone tried this that has the newest kernel installed?
Comment 51 Dave Airlie 2012-08-19 22:27:53 EDT
can a few people post their full /boot/grub2/grub.cfg files as well?

want to know if you are getting gfxterm, which I don't see here very often.
Comment 52 Reilly Hall 2012-08-19 23:53:55 EDT
(In reply to comment #49)
> So does it boot if you remove the grub lines but don't add nomodeset?

Not for me.  I had to have ALL 3 modifications before it would even ask for my full drive encryption password and then proceed to a login screen within X using the VESA driver rather than the usual Intel i915GM driver.  I will post my /boot/grub2/grub.cfg here in a few minutes just incase it helps as I do find it strange that my ThinkPad having the same exact software and same CPU video combo don't suffer this.  Only thing I can think of is the BIOSes are different and maybe setting up the hardware environment prior to boot in a manner that is non-ideal on the Dell vs. the IBM?
Comment 53 Reilly Hall 2012-08-20 00:19:02 EDT
Created attachment 605573 [details]
grub.cfg Latitude-D410
Comment 54 Dave Airlie 2012-08-20 00:59:28 EDT
can I also get /etc/default/grub as well?
Comment 55 Dave Airlie 2012-08-20 02:27:40 EDT
can people check if they have

terminal_output=gfxterm

in their /boot/grub2/grub.cfg and see if commenting it out helps things any?
Comment 56 Stuart D Gathman 2012-08-20 08:19:50 EDT
D610 does not boot without nomodeset, even after removing the load_video and set gfxpayload=keep lines.  However, while nomodeset allows booting, the Xorg server does not work - displaying a black screen.  Removing the grub lines (or, from bug#843826, commenting out terminal_output=gfxterm) enables text mode consoles to work when booting with nomodeset (otherwise, text mode displays blank also).  But without nomodeset, there is no disk activity after "loading initramfs".
Comment 57 Stuart D Gathman 2012-08-20 08:20:56 EDT
Created attachment 605691 [details]
grub.cfg Latitude D610
Comment 58 Stuart D Gathman 2012-08-20 08:24:15 EDT
/etc/default/grub  on Latitude D610:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.lvm.lv=vg_laura/f17 rd.md=0 rd.dm=0 SYSFONT=True  KEYTABLE=us rd.luks=0 rd.lvm.lv=vg_laura/SWAP LANG=en_US.UTF-8 rhgb quiet"
#GRUB_THEME="/boot/grub2/themes/system/theme.txt"


While other people noted that it randomly boots with 3.5 sometimes, the D610 has never, ever booted with 3.5 for me - except with nomodeset.
Comment 59 Stuart D Gathman 2012-08-20 11:05:34 EDT
If this could be a BIOS issue, perhaps we should post some part of dmidecode?
Comment 60 Reilly Hall 2012-08-20 23:34:09 EDT
My Latitude-D410 also will NOT boot without nomodeset.  However mine does manage to boot all the way up to a X login which proceeds to my desktop after authenticating.  As noted earlier, in my case I just noticed the fonts were different looking and the general sluggishness of the display and quickly figured out it's because the Intel X.org driver that I'm used to loading up was replaced by a generic possibly fallback VESA driver that at least works to get me to my desktop.

If it's a BIOS issue then in that case there isn't much I can do.  Dell hasn't released newer BIOS for my Latitude-D410 in quite some time and I know I'm running the latest version already.  But even if it were a BIOS issue, begs the question why Linux and the Intel X.org driver have worked fine all this time and now suddenly it doesn't.  At the very least a workaround or shim for the buggy BIOS/firmware should be put into place.

I personally lean towards the BIOS being the likely culprit as I am running nearly the exact same config on my ThinkPad T43 that has been booting the 3.5.x series kernels on a similar Pentium M with the same Intel 915GM video just fine without modifying grub.cfg.  Obviously the BIOS firmware supplied by IBM is quite different than the BIOS supplied by Dell even for the same or similar hardware.

I will post my /etc/defaults/grub here shortly as well.
Comment 61 Reilly Hall 2012-08-20 23:42:44 EDT
Here is my /etc/defaults/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
# GRUB_TERMINAL="serial console"
# GRUB_SERIAL_COMMAND="serial --unit=0 --speed=9600"
GRUB_CMDLINE_LINUX="quiet rhgb"
GRUB_DISABLE_RECOVERY="true"


The only thing I just realized is that this file is different on my ThinkPad than it is on my Latitude.  Unsure if these differences matter however.  The only other configuration difference I just noticed as well is that the ThinkPad is using MSDOS patitioning with Logical Volumes and my Latitude is using GPT and standard GPT partitions with no Logical Volumes.  I don't suppose that would be causing this however...
Comment 62 Reilly Hall 2012-08-20 23:48:03 EDT
(In reply to comment #55)
> can people check if they have
> 
> terminal_output=gfxterm
> 
> in their /boot/grub2/grub.cfg and see if commenting it out helps things any?

Please note I just checked and both my ThinkPad and my Latitude have that line.  I will test tomorrow if the Latitude will boot with that line removed/commented out.  But for now the ThinkPad boots with it just fine.

Here is also the ThinkPad's /etc/defaults/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm.lv=vg_t43/lv_root  KEYTABLE=us SYSFONT=True LANG=en_US.UTF-8 rd.luks.uuid=luks-64275afb-b596-4f28-9ee6-bea5b93df2ca rd.lvm.lv=vg_t43/lv_swap rd.dm=0 rhgb quiet"
#GRUB_THEME="/boot/grub2/themes/system/theme.txt"

As you can see somewhat different than the Latitude, unsure why.
Comment 63 Reilly Hall 2012-08-24 09:04:23 EDT
Hello,

I'm writing to regretfully inform that the latest kernel did NOT work as it claimed in the --changelog output of yum.

Machine still performed exactly the same if you let it boot up as normal (the panel back-light actually turns off on the Latitude-D410).

If you modify the grub parameters, this time, the only change necessary to make it work is the nomodeset.  No need to remove the load_video and set gfxpayload=keep lines.  However it still appears to be using the VESA X.org driver for me, so this is probably only just a step in the right direction and not anywhere near a final solution.
Comment 64 Reilly Hall 2012-08-24 09:06:40 EDT
Oh and I meant to say this is with the latest kernel-3.5.2-3.fc17.i686.PAE released lastnight or early this morning.
Comment 65 Stuart D Gathman 2012-08-28 23:16:37 EDT
Created attachment 607732 [details]
3.5 kernels video braindamage - Acer 5670

This is not the Dell D610, but an Acer 5670 with ATI video.

3.5 kernels cause Xorg to garbage random pixels (enough that it is unusable).  The text mode consoles work.  Please note that the very same Xorg works perfectly with 3.4.x kernels.  #.5.x *really* screws something up.  

lspci:

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
04:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5789 Gigabit Ethernet PCI Express (rev 21)
0a:09.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
0a:09.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
0a:09.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
Comment 66 Stuart D Gathman 2012-08-28 23:26:52 EDT
Also, the rhgb image has black pixels instead of grey at the top.  It switches over to grey in the middle of a pixel row.  Again, this happens with 3.5 kernels, but not with 3.4 kernels.  But since it actually does boot on this box, maybe some more diagnostics can be done.  Remember that on the D610, using nomodeset would allow booting, but Xorg would show a black screen (on 3.5.x kernels).
Comment 67 Dave Airlie 2012-08-28 23:37:40 EDT
please don't do that we have do completly different bugs with completely different symptoms, why would you pile that in here?

please open a separate bug for the radeon problem its not the same thing.
Comment 68 Stuart D Gathman 2012-08-29 06:38:29 EDT
The radeon (and Intel and Nvidia) work perfectly with 3.4 kernels.  Other responders here where it actually hangs have different systems than D610 (the specific model is not the issue).  They all hang at the same spot with the same error message (except reporting different graphics drivers).  For all graphics types, it is "fixed" by adding nomodeset (except you get an inferior and slow graphics mode - although gnome-shell still runs).  They all work with kernel 3.4. 

While you might feel that my last report doesn't belong here because it actually finished booting (albeit with dead graphics), the title change is certainly justified because it is not just a D610 model that you can ignore.  This is a wide spread problem (or set of unrelated problems that all happen with the same kernel change at the same point in the boot process).  The 3.5 kernels kill 2 out the 4 systems I've tried F17 on (which all work great with 3.4 kernels).  Plus the other posters here.

I'm not sure how to report this latest 3.5 problem.  It still goes under "kernel" because that is the component that breaks it when booting 3.5.  (Same Xorg version with both 3.4 and 3.5 kernels.)
Comment 69 Stuart D Gathman 2012-08-29 13:18:41 EDT
Reported the non-hanging graphics problem in bug#852826.
Comment 70 Walter Neumann 2012-09-24 15:34:08 EDT
No change with Kernel 3.5.4-1 

Has anyone found a reasonable workaround (other than sticking to the 3.4.6 kernel, which is what I am doing)?

I have tried booting with 'nomodeset' and an etc/X11/xorg.conf designed to load the intel driver, but I havn't been able to make that work. In particular, just modelling it on the old xorg.conf I used before the kernel started doing the modeset does not work.
Comment 71 Robert Solomon 2012-09-26 15:48:46 EDT
Same results as Walter, D610, kernel-3.5.4-1.fc17.i686

I would like to see this resolved.  Let me know if I can provide and information.  Boot hangs halfway through the shading the the plymouth? fedora logo.

Link to the 3.4.6 kernels Walter mentions:

http://koji.fedoraproject.org/koji/buildinfo?buildID=333970
Comment 72 Robert Solomon 2012-10-02 17:17:48 EDT
kernel-3.5.4-2.fc17.i686 ditto.
Comment 73 Martin Garton 2012-10-11 04:29:21 EDT
I don't know if this helps, but 3.7.0-0.rc0.git3.1.fc19.x86_64 from rawhide Works For Me.  The previous one I tried from rawhide 3.6.0-0.rc6.git0.2.fc18.x86_64 didn't work.
Comment 74 Reilly Hall 2012-10-11 10:06:10 EDT
3.5.6-1.fc17 Still does not boot my Dell Latitude D410.  I may need to try this rawhide kernel mentioned by Martin and report back my findings as well.
Comment 75 D S 2012-10-11 16:39:56 EDT
I'm using a Fedora 4006 with AMD Turion64 processor and ATI Mobility Radeon X700 graphics card.

I attempted to boot (twice) using Fedora-18-Nightly-20121011.09-i686-Live-desktop.iso
ID 4582581

First attempt was with my laptop without the external monitor. Fedora 18 began to start and eventually the screen went gray with an underscore cursor in the upper-left corner. I waited for a while (about 90 seconds) and the fan sped up then the DVD drive started, but only for a second or two. The screen was still gray with nothing on it except the underscore cursor. The fan was still going full speed. I waited another 2 minutes then powered down.

Second attempt was with my laptop and the external monitor. Everything happened the same way as in the first attempt.
Comment 76 Robert Solomon 2012-10-16 20:04:04 EDT
kernel-3.6.1-1.fc17.i686 hangs after loading initial ramdisk.  Screen goes dark, then shuts off.  Fan runs, no HD activity.
Comment 77 Robert Solomon 2012-10-22 11:55:21 EDT
kernel-3.6.2-4.fc17.i686, d610, hangs halfway through shading the logo on the plash screen...
Comment 78 chas 2012-10-24 19:25:58 EDT
Latitude D410.  My favorite traveling laptop.  It has a stick-on penguin over the windows sticker.  Fedora 17.

3.4 kernel still works, 3.5 and 3.6 do not.  I've tried several of the work-arounds presented in the above comments.  No good for me.

I have also seen the message "fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver" just before the black screen.  One piece of information, sometimes the boot process results in a partially filled in 'teardrop' then hangs, most of the time it is a black screen.  Can't find anything to correlate that with.

I just downloaded Fedora 18 alpha live CD xfce.  Unfortunately it also will not boot on my D410.  Very sad.  Black screen after a message about SELinux not being able to find some file or directory.
Comment 79 Martin Garton 2012-10-31 05:14:56 EDT
I guess this means that those of us who are having these problems will not be able to install F18 at all unless this gets fixed in time for the F18 release?

If so, what can any of us do to help get this resolved?

Does anyone have a pointer to documentation that explains how to do an upstream kernel bisection?
Comment 80 Stuart D Gathman 2012-11-02 20:07:05 EDT
The best thing to do is to make time to download the F18 alpha/beta disks, attempt to install, and report that it doesn't work.  This should be a beta blocker for F18 (not that it will be).
Comment 81 chas 2012-11-06 13:06:36 EST
@Stuart

Do you mean for me to override a good install that is still usable using the 3.4 Kernel with a bad one?

Don't wanna do that, since I know that the live version of 18 Alpha does not boot.  Unless you insist...


chas
Comment 82 Stuart D Gathman 2012-11-06 20:17:30 EST
(In reply to comment #81)
> @Stuart
> 
> Do you mean for me to override a good install that is still usable using the
> 3.4 Kernel with a bad one?
> 
> Don't wanna do that, since I know that the live version of 18 Alpha does not
> boot.  Unless you insist...
> 
> 
> chas

No, just boot from the LiveCD - if it doesn't even do that, then report it.  If the LiveCD boots, install to separate LV if you are running LVM and know how to tweak grub.  You could also use an older tiny hard drive that you upgraded years ago (or upgrade your current tiny hard drive with a new one) to [attempt to] install F18 to.
Comment 83 chas 2012-11-07 12:10:53 EST
@stuart

I'm new here.  How do I officially report the live CD problem, what info should I capture and how to capture it?

I really like my little D410 so I want to give all it info I can.

chas
Comment 84 Stuart D Gathman 2012-11-07 13:24:46 EST
(In reply to comment #83)
> @stuart
> 
> I'm new here.  How do I officially report the live CD problem, what info
> should I capture and how to capture it?
> 
> I really like my little D410 so I want to give all it info I can.

Obviously, you already have a bugzilla account.  So click New / Fedora  and select the component LiveCD and report that it doesn't boot, along with your model, lspci from a working kernel, etc.  I have two "clients" (family and friends) with laptops that don't boot with kernel-3.5 and later.  Until the kernel finally gets fixed (if ever), you might want to edit /etc/sysconfig/kernel and change UPDATEDEFAULT=no.  This prevents changing the default boot kernel when the latest kernel is updated.  You can install the latest 3.4 kernel from F16 on F17.

I don't know if it would help to report the problem upstream.  It's pretty bad that 2 out of 6 of the machines I'm responsible for (Dell D610 and Sony something) won't boot with any version of the last 2 major releases of the linux kernel.  Unfortunately, none of the machines I use personally have a problem with the new kernels - so I can't do any in depth debugging to help out.
Comment 85 chas 2012-11-07 19:24:32 EST
Sorry, Have no idea how to fill in the bug report. It is not exactly self-explanatory

I do have the lspci output and a description of what happens.

Start d410 with fedora 18 live xfce cd (downloaded today) in bootable external cd drive. 

CD reads & presents boot menu including "Start Fedora 18"  -- accepted
CD reads, screen is black (15-20 seconds)
Screen -> grey with text cursor (underscore) at upper left for 5 seconds
Screen -> black
CD reads as if it is doing something important...
CD stops, Screen still black.
Still black for over 3 minutes.
No more CD activity 

pressing CD eject button does nothing
Ctrl C does nothing
Ctrl Alt Del does nothing

Must power down to get out of hang condition.

Don't know how to 'attach' a file, so...
lspci output from Kernel 3.4

00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03)
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
02:01.0 CardBus bridge: Texas Instruments PCI6515 Cardbus Controller
02:01.5 Communication controller: Texas Instruments PCI6515 SmartCard Controller
02:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)

chas
Comment 86 chas 2012-11-28 00:55:26 EST
Just tried Fedora 18 Beta (Live xfce) on 11/27/2012,  Same problem,  screen goes blank after CD reads for about 4 seconds.  CD stops, no more action.  

chas
Comment 87 JayJayJazz 2012-11-28 05:11:48 EST
(In reply to comment #78)
> Latitude D410.  My favorite traveling laptop.  It has a stick-on penguin
> over the windows sticker.  Fedora 17.
> 
> 3.4 kernel still works, 3.5 and 3.6 do not.  I've tried several of the
> work-arounds presented in the above comments.  No good for me.
> 
> I have also seen the message "fb: conflicting fb hw usage inteldrmfb vs VESA
> VGA - removing generic driver" just before the black screen.  One piece of
> information, sometimes the boot process results in a partially filled in
> 'teardrop' then hangs, most of the time it is a black screen.  Can't find
> anything to correlate that with.


I can confirm this on my Latitude D410. The machine boots with the Kernel 3.3.4. But after the system-update GRUB will try to boot into Kernel 3.6.7. In most cases I will get the black screen. Sometimes the half-filled Fedora Icon.

Can I provide some more information like Log files?
Comment 88 Walter Neumann 2012-12-02 11:51:03 EST
I just booted successfully with latest kernel 3.6.8-2.fc17.i686 

This is the first kernel since 3.4.6-2.fc17.i686 which has booted on my 
Dell D410 (best laptop I've owned -- it has survived shoulder-high drop onto a cobbled street in Vietnam and a several milder falls).
Comment 89 chas 2012-12-02 15:34:48 EST
kernel 3.6.8-2.fc17.i686 boots my D410 also.  YEA!  

Thanks to the fixers.
Comment 90 Calculici 2012-12-02 15:59:20 EST
kernel 3.6.8-2.fc17.i686 boots my D410 also.
Comment 91 Robert Solomon 2012-12-02 17:02:04 EST
kernel 3.6.8-2.fc17.i686 boots my Dell D610 also.

Thanks to all who made this happen.
Comment 92 Martin Garton 2012-12-02 21:17:30 EST
What can we do to ensure the fix (whatever it was) has made it (or will make it) into F18 final, since F18 beta reportedly fails with this same bug?

(I would try myself, but I dont have access to my dell machine until I return from holiday)
Comment 93 Josh Boyer 2012-12-03 14:32:22 EST
(In reply to comment #92)
> What can we do to ensure the fix (whatever it was) has made it (or will make
> it) into F18 final, since F18 beta reportedly fails with this same bug?

We didn't explicitly add any patches for this issue in Fedora.  Whatever fixed it was brought in through the 3.6.8 rebase if it is really fixed.  The only glaringly related looking commit is:

commit 4d60ac3f136e26522dbdbff28624f59165a27cd9
Author: Igor Murzov <e-mail@date.by>
Date:   Sat Oct 13 04:41:25 2012 +0400

    ACPI video: Ignore errors after _DOD evaluation.
    
    commit fba4e087361605d1eed63343bb08811f097c83ee upstream.


F18 is already rebased to 3.6.8 and will be moving to 3.6.9 soon, so it will get the same set of commits.

If the others in this bug that haven't spoken up yet could report results, that would be appreciated.
Comment 94 cullen d 2012-12-04 07:56:59 EST
(In reply to comment #93)
> If the others in this bug that haven't spoken up yet could report results,
> that would be appreciated.

My Dell E5520 failed to boot with vmlinuz-3.6.8-2.fc17.x86_64.  It will only boot with 3.3.4-5.fc17.x86_64 (or earlier).  All subsequent kernels fail to launch (with or without modifications in <a href="show_bug.cgi?id=845388#c39">comment #39</a>.

The system is a fresh install from an LXDE spin.
Comment 95 Josh Boyer 2012-12-04 09:00:44 EST
(In reply to comment #94)
> (In reply to comment #93)
> > If the others in this bug that haven't spoken up yet could report results,
> > that would be appreciated.
> 
> My Dell E5520 failed to boot with vmlinuz-3.6.8-2.fc17.x86_64.  It will only
> boot with 3.3.4-5.fc17.x86_64 (or earlier).  All subsequent kernels fail to
> launch (with or without modifications in <a
> href="show_bug.cgi?id=845388#c39">comment #39</a>.

Thank you for testing.

Unfortunately, you have different hardware than a dell d410/d610.  Also, "failed to boot" isn't quite descriptive enough.  I would suggest you open a new bug to track your issues.
Comment 96 Reilly Hall 2012-12-04 10:49:44 EST
(In reply to comment #93)
> (In reply to comment #92)
> > What can we do to ensure the fix (whatever it was) has made it (or will make
> > it) into F18 final, since F18 beta reportedly fails with this same bug?
> 
> We didn't explicitly add any patches for this issue in Fedora.  Whatever
> fixed it was brought in through the 3.6.8 rebase if it is really fixed.  The
> only glaringly related looking commit is:
> 
> commit 4d60ac3f136e26522dbdbff28624f59165a27cd9
> Author: Igor Murzov <e-mail@date.by>
> Date:   Sat Oct 13 04:41:25 2012 +0400
> 
>     ACPI video: Ignore errors after _DOD evaluation.
>     
>     commit fba4e087361605d1eed63343bb08811f097c83ee upstream.
> 
> 
> F18 is already rebased to 3.6.8 and will be moving to 3.6.9 soon, so it will
> get the same set of commits.
> 
> If the others in this bug that haven't spoken up yet could report results,
> that would be appreciated.

I am replying to also show that I tested the updated 3.6.8-2.fc17.i686.PAE kernel started booting my Dell Latitude-D410 successfully and without the use of the VESA x.org video driver.

I too was curious as the rpm --changelog for the latest kernel makes no mention of any patch specific to this bug (though previous kernels did despite the fact that they did NOT work).
Comment 97 David Sugar 2012-12-17 04:30:02 EST
I am commenting simply to note and confirm that the kernel on the second test compose of the kde spin for Fedora 18 (3.6.10-4.fc18) boots, installs, and seems to run fine on my D 610.  This seems to be the first to do so for me.
Comment 98 Josh Boyer 2013-01-02 12:56:28 EST
This bug was for the D610 systems and appears to be fixed with the commit referenced above.  For those of you with different hardware that isn't booting still, please open a new bug.
Comment 99 Stuart D Gathman 2013-01-02 23:08:08 EST
I just booted kernel-3.6.10 on my daughters D610, and it works (first since 3.4).  So it is indeed fixed.  Thanks to the fixers.  

P.S.  Is there some kind of tool end-users could use to help debug these kinds of kernel problems sooner?  Perhaps some way of redirecting console output to some kind of media?  I know it is possible to use a serial console and log that on another machine.  How about a USB serial "console" that simulates a USB serial device, and logs console output on the device, then can be mounted as a USB storage drive to retrieve the log.

Note You need to log in before you can comment on or make changes to this bug.