Bug 964335 - Running 3.9.2-200 kernel leads to kernel panic virt_efi_get_variable
Running 3.9.2-200 kernel leads to kernel panic virt_efi_get_variable
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
18
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
: 964346 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-17 18:08 EDT by Steven Rosenberg
Modified: 2013-06-30 21:32 EDT (History)
28 users (show)

See Also:
Fixed In Version: kernel-3.9.8-100.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-13 02:00:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Kernel panic 1 of 2 (1.25 MB, image/jpeg)
2013-05-22 07:19 EDT, Tom Mannerhagen
no flags Details
Kernel panic 2 of 2 (986.73 KB, image/jpeg)
2013-05-22 07:21 EDT, Tom Mannerhagen
no flags Details
Kernelpanic as text (2.71 KB, text/plain)
2013-05-23 02:46 EDT, josephhenryblack
no flags Details
kernel 3.9.2-200 panic w/ "rhgb quiet" parameters (2.57 MB, image/png)
2013-05-24 18:30 EDT, lu.error
no flags Details
kernel-panic_3.9.2-200.fc18.x86_64.txt on HP Envy dv7- 7240us (2.88 KB, text/plain)
2013-05-25 12:13 EDT, Paul Miller
no flags Details
Screenshot from a kernel panic with HP intel i5 - RadeonHD 7600m series (340.91 KB, image/jpeg)
2013-05-28 12:30 EDT, Paolo Leoni
no flags Details

  None (edit)
Description Steven Rosenberg 2013-05-17 18:08:12 EDT
Description of problem:

This Fedora 18 system will not boot on new 3.9.2-200 Linux kernel. It kernel panics and must be hard-restarted.


Version-Release number of selected component (if applicable):

3.9.2-200.fc18.x86_64

How reproducible:

Boot into the 3.9.2-200.fc18.x86_64 kernel.

Steps to Reproduce:
1. Boot into Fedora 18
2. In grub menu, allow the 3.9.2-200 kernel to boot
3.
  
Actual results:

Kernel panic

Expected results:

System boots normally

Additional info:

My hardware is an HP Pavilion g6-2210us laptop with AMD A4-4300M CPU.

This is a Secure Boot install, and previous kernels, including 3.8.11-200.fc18.x86_64, boot without trouble.
Comment 1 Paul Miller 2013-05-17 20:19:47 EDT
Basically the same scenario as posted above:

Fedora 18 64 bit kernel panics attempting to boot into the 3.9.2-200 kernel.

Hardware: HP ENVY dv7-7240us with Intel i5-3210M cpu and Intel HD 4000 gpu.

Secure Boot is enabled and "acpi_backlight=vendor" is only added kernel boot cmd.

All previous kernels (3.8.11-200 was last) boot normally without issue.
Comment 2 lu.error 2013-05-17 21:21:03 EDT
*** Bug 964346 has been marked as a duplicate of this bug. ***
Comment 3 lu.error 2013-05-17 21:33:23 EDT
(In reply to comment #2)
> *** Bug 964346 has been marked as a duplicate of this bug. ***

I would also like to further add comments about this system:

Hardware: HP ENVY dv6-7302eo, Intel Core i7-3630QM, nVidia 635M with Optimus.

Secure Boot is disabled on this system.
Comment 4 Luke Lockhart 2013-05-18 02:42:26 EDT
Also have this problem on HP Envy Sleekbook 6t-1100, Intel Core i7-3517U, and Intel Ivybridge Mobile graphics (with a secondary ATI card that I don't believe is enabled and I can't recall the specs for offhand.) I have Secure Boot enabled, but I have replicated the bug without it as well.

I also compiled a version of the 3.9 kernel myself while on Debian, and got a kernel panic on boot (secure boot disabled). At the time I wrote it off as inexperience with compiling kernels, but that would lead to me suspecting that this is actually an upstream bug not specific to Fedora/Red Hat.
Comment 5 john5342 2013-05-18 12:49:09 EDT
Same here on HP Envy m6 (Intel Core i3, Intel HD3000, Radeon HD 7670M). UEFI with secure boot enabled. Previous kernel works fine.

Screen capture of trace at: https://www.dropbox.com/s/uzol971x8decz9i/IMAG0213.jpg
Comment 6 Michal Nowak 2013-05-20 04:43:18 EDT
I guess I have a similar problem (thought I can't see the trace). I can avoid the panic if I add acpi=off. Can anyone verify that? Can someone build & test 3.9.3 as it seems there are several ACPI-related fixes?
Comment 7 john5342 2013-05-20 09:49:21 EDT
(In reply to Michal Nowak from comment #6)
> I guess I have a similar problem (thought I can't see the trace). I can
> avoid the panic if I add acpi=off. Can anyone verify that?

acpi=off makes no difference here. Same trace.
Comment 8 lu.error 2013-05-21 08:24:47 EDT
(In reply to Steven Rosenberg from comment #0)
(In reply to Paul Miller from comment #1)
(In reply to Luke Lockhart from comment #4)

Is it possible for You to post an picture of the trace of the kernel panic and a transcript of it? I noticed that john5342's kernel panic is very different from the kernel panic trace I get.
Comment 9 BBQdave 2013-05-21 23:01:04 EDT
Hardware: Toshiba c655-s5503, Intel® Core™ i3-2350M CPU @ 2.30GHz × 4, memory 4 GiB.

Kernel Linux 3.9.2-200.fc18.x86_64, GNOME 3.6.3

System Settings > Power, does not detect notebook battery. No battery power management choices. No battery icon on top desktop bar.

Battery power management functions normal under Kernel Linux 3.8.11-200.fc18.x86_64, GNOME 3.6.3. Screen dims when battery in use and system idle. Choices of Hibernate, Shutdown, on low power is available and function. Battery icon on top desktop bar indicates battery power level.
Comment 10 Michal Nowak 2013-05-22 02:36:19 EDT
I am not able to see the trace. Even when I remove "rhgb quiet" from kernel GRUB2 line, all I see is just a nifty GRUB2 flame with frame in Fedora colors, can't get to the trace. Any idea?
Comment 11 Tom Mannerhagen 2013-05-22 04:22:57 EDT
Hi

I am getting this too.
UEFI enabled

Secure boot enabled / disabled does not change the situation.

I'll try to attach a picture of the messages seen on the display.

BR 

Tom
Comment 12 lu.error 2013-05-22 04:25:45 EDT
(In reply to BBQdave from comment #9)

This is not a kernel panic, and I believe it does not belong in this bug report.

(In reply to Michal Nowak from comment #10)

https://fedoraproject.org/wiki/Common_kernel_problems?rd=KernelCommonProblems

You might want to try:

"Slowing down the speed of text output with boot_delay=1000 (the number may need to be tweaked higher/lower to suit) may allow the user to take a digital camera photo of the last thing on screen."

And/or:

"Booting with vga=791 (or even just vga=1 if the video card won't support 791) will put the framebuffer into high resolution mode to get more lines of text on screen, allowing more context for bug analysis."

Then you should have enough time take images of the boot process, and the trace when the kernel panics.
Comment 13 Tom Mannerhagen 2013-05-22 07:19:56 EDT
Created attachment 751662 [details]
Kernel panic 1 of 2

Kernel panic photo 1 of 2 - console in lowres
Comment 14 Tom Mannerhagen 2013-05-22 07:21:02 EDT
Created attachment 751664 [details]
Kernel panic 2 of 2

Kernel panic photo 2 of 2 - console in lowres
Comment 15 Tom Mannerhagen 2013-05-22 07:22:56 EDT
Hi

Added 2 pics for whatever use they may be.
Please note that I was unable to get my console in highres mode despite use of vga=791 or vga=1 .
Probably I put those lines in the wrong places - it in't easy to know and it's not my area of expertise :)

If You need other shots / info, let me know.

Thanks!
Tom
Comment 16 Michal Nowak 2013-05-22 09:18:57 EDT
Just FYI, there's 3.9.3 kernel update in Koji (http://koji.fedoraproject.org/koji/buildinfo?buildID=420689), thought I had no luck with it. (Still working on the trace.)
Comment 17 josephhenryblack 2013-05-23 02:46:13 EDT
Created attachment 752005 [details]
Kernelpanic as text

Seeing it on a Hewlett Packard Compaq CQ45 Notebook PC/1854. Attached text is message shown on screen.
Comment 18 lu.error 2013-05-24 18:30:48 EDT
Created attachment 752897 [details]
kernel 3.9.2-200 panic w/ "rhgb quiet" parameters

(In reply to lu.error from comment #8)
After removing the "rhgb quiet" from the kernel boot parameters, the kernel now panics with a similar message as john5342. See the attachment.
Comment 19 Paul Miller 2013-05-25 12:11:21 EDT
(In reply to lu.error from comment #8)
> (In reply to Steven Rosenberg from comment #0)
> (In reply to Paul Miller from comment #1)
> (In reply to Luke Lockhart from comment #4)
> 
> Is it possible for You to post an picture of the trace of the kernel panic
> and a transcript of it? I noticed that john5342's kernel panic is very
> different from the kernel panic trace I get.

Adding transcript of kernel panic from screen capture for kernel-3.9.2-200.fc18.x86_64
Comment 20 Paul Miller 2013-05-25 12:13:44 EDT
Created attachment 753128 [details]
kernel-panic_3.9.2-200.fc18.x86_64.txt on HP Envy dv7- 7240us

Hand transcribed from not-so-great photo of screen.
Comment 21 lu.error 2013-05-26 07:20:07 EDT
(In reply to Steven Rosenberg from comment #0)

After upgrading and running kernel-3.9.4-200.fc18.x86_64, the oops and panic still occurs and the same trace is displayed as previously posted.
Comment 22 Paolo Leoni 2013-05-28 12:28:05 EDT
I'm having this issue in Fedora 19 Beta with kernel-3.9.2-301.x86_64
Comment 23 Paolo Leoni 2013-05-28 12:30:29 EDT
Created attachment 753989 [details]
Screenshot from a kernel panic with HP intel i5 - RadeonHD 7600m series
Comment 24 Luke Lockhart 2013-05-28 20:42:14 EDT
(In reply to lu.error from comment #21)
> (In reply to Steven Rosenberg from comment #0)
> 
> After upgrading and running kernel-3.9.4-200.fc18.x86_64, the oops and panic
> still occurs and the same trace is displayed as previously posted.

+1 here.
Comment 25 Paolo Leoni 2013-05-29 05:09:21 EDT
I propose to set this bug as blocker for Fedora 19 Final.
Comment 26 Dale Mosby 2013-05-29 11:00:18 EDT
In reading this I see "HP Envy" quite often.
I hit this with 3.9.2-200 and 3.9.4-200 (fc18 x86_64) also on
an HP ENVY dv7-7323cl 8 gig mem and Intel i5-3230M CPU @ 2.60GHz.
Old kernel 3.8.6-203.fc18.x86_64 will still boot for me.
Can provide lshw output if useful.
I certainly hope bug is a blocker.
Comment 27 John L. Pierce 2013-05-30 11:03:40 EDT
(In reply to Dale Mosby from comment #26)
> In reading this I see "HP Envy" quite often.
> I hit this with 3.9.2-200 and 3.9.4-200 (fc18 x86_64) also on
> an HP ENVY dv7-7323cl 8 gig mem and Intel i5-3230M CPU @ 2.60GHz.
> Old kernel 3.8.6-203.fc18.x86_64 will still boot for me.
> Can provide lshw output if useful.
> I certainly hope bug is a blocker.

I can tell you that it is also occurring with 3.9.4-200.fc18.x86_64 on a Toshiba Satellite L855D-S5117 with UEFI.  This kernel boots without panic on an older Toshiba and HP laptop without UEFI.

Seems to be UEFI related.

I can provide information or screenshots if necessary.
Comment 28 Paolo Leoni 2013-05-30 12:17:45 EDT
Actually I've UEFI disabled, but kernel panic still occurs. 
Maybe it's related to the presence of a Radeon adapter.
Comment 29 Russ Anderson 2013-05-30 22:28:01 EDT
This community discussion could be related.

http://marc.info/?t=136924016400007&r=1&w=2

If it is the same problem, it takes EFI with grub2 to hit it.  The same kernel booted using grub or elilo does not hit the problem.
Comment 30 Fedora Blocker Bugs Application 2013-05-31 04:55:32 EDT
Proposed as a Blocker for 19-final by Fedora user deepsky using the blocker tracking app because:

 Fedora 19 Beta with kernel-3.9.2-301.x86_64 is not able to boot (kernel panic) on some systems with UEFI due to a kernel regression (kernel 3.8.11 is ok). We have same beahviour with kernel-3.9.3 and kernel 3.9.4.

References:
https://bugzilla.redhat.com/show_bug.cgi?id=964335
http://marc.info/?t=136924016400007&r=1&w=2
Comment 31 Ken Tobias 2013-05-31 13:17:43 EDT
(In reply to Luke Lockhart from comment #24)
> (In reply to lu.error from comment #21)
> > (In reply to Steven Rosenberg from comment #0)
> > 
> > After upgrading and running kernel-3.9.4-200.fc18.x86_64, the oops and panic
> > still occurs and the same trace is displayed as previously posted.
> 
> +1 here.

+1 HP dv7 i7 HD4000 display fc18.
Comment 32 Josh Boyer 2013-05-31 15:02:29 EDT
Please test this scratch build when it finishes and let us know if your machine boots again:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5445919
Comment 33 Rohit 2013-05-31 15:05:38 EDT
+1 on HP Envy dv6 on Fedora 18
Core i7, NVidia CPU

UEFI enabled, Secure Boot disabled.

Able to boot 3.8.11 kernel, unable to start with 3.9.2 and 3.9.4
Comment 34 Josh Boyer 2013-05-31 17:19:07 EDT
OK, so assuming the scratch kernel in comment #32 actually makes people's machines boot again, we're back to bug 947142.  The patches we added for that (and that went upstream) seem to be causing this issue, so reverting them fixes this bug but leaves us with the original problem.

One of the alternatives for the original problem was to not do space checks at all, but that leaves us with the er... original original problem.  Some machines will be susceptible to being bricked.  So we have 3 scenarios at the moment:

1) Current state of affairs.  We can install and protect against machine bricking, but some people can't boot.

2) Revert the patches causing people to not be able to boot (the scratch kernel), but then some subset of machines won't be able to install Fedora.  That is bug 947142.

3) Revert the patches and boot with efi_no_storage_paranoia=1 by default.  That fixes the boot issue, and it avoids the space issue in bug 947142, but it means some machines (Samsung and reportedly Lenovo) can be bricked.

None of these are really great scenarios, but that is where we stand.
Comment 35 lu.error 2013-05-31 17:29:17 EDT
(In reply to Josh Boyer from comment #32)
> Please test this scratch build when it finishes and let us know if your
> machine boots again:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5445919

I can confirm that the following kernels boot into userspace on the Fedora 18 distribution:
 kernel-3.9.4-300.4.fc19.x86_64.rpm
 kernel-debug-3.9.4-300.4.fc19.x86_64.rpm
Additional installed packages:
 kernel-modules-extra-3.9.4-300.4.fc19.x86_64.rpm
 kernel-headers-3.9.4-300.4.fc19.x86_64.rpm

Although I would like to make a small note. I poked around and looked a bit in dmesg for new errors in both kernels and found:

[erro@local ~]$ dmesg | grep "HP ENVY"
[    0.000000] DMI: Hewlett-Packard HP ENVY dv6 Notebook PC/181B, BIOS F.24 01/22/2013
[erro@local ~]$ dmesg | grep Warning
[   14.846450] ACPI Warning: 0x0000000000005040-0x000000000000505f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130117/utaddress-251)
[   14.847949] ACPI Warning: 0x0000000000000428-0x000000000000042f SystemIO conflicts with Region \PMIO 1 (20130117/utaddress-251)
[   14.848002] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \GPIO 1 (20130117/utaddress-251)
[   14.848026] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \_SB_.GPIO 2 (20130117/utaddress-251)
[   14.848049] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \_SB_.PCI0.PEG0.PEGP.GPIO 3 (20130117/utaddress-251)
[   14.848074] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \GPIO 1 (20130117/utaddress-251)
[   14.848097] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \_SB_.GPIO 2 (20130117/utaddress-251)
[   14.848119] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \_SB_.PCI0.PEG0.PEGP.GPIO 3 (20130117/utaddress-251)
[erro@local ~]$ dmesg | grep Error
[    0.579031] ACPI Error: No handler for Region [RAM_] (ffff8804a7e2d900) [EmbeddedControl] (20130117/evregion-161)
[    0.579035] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20130117/exfldio-305)
[    0.579059] ACPI Error: Method parse/execution failed [\_SB_.ACCL._STA] (Node ffff8804a7e63140), AE_NOT_EXIST (20130117/psparse-537)
[    0.579126] ACPI Error: Method execution failed [\_SB_.ACCL._STA] (Node ffff8804a7e63140), AE_NOT_EXIST (20130117/uteval-103)
[erro@local ~]$ dmesg | grep Exception
[    1.511317] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130117/hwxface-568)
[    1.511337] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130117/hwxface-568)
[erro@local ~]$ dmesg | grep Firmware
[    1.654811] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    3.373625] [Firmware Bug]: No valid trip found
[    7.688226] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS

While the acpi warnings and errors are not new and have existed since I had installed Fedora 18 on this system, the acpi exceptions and the first firmware bug are new to the afforementioned kernels (but I assume that these are also due to HP broken bios implementation, no?).
Comment 36 lu.error 2013-05-31 18:01:47 EDT
(In reply to Josh Boyer from comment #34)
> OK, so assuming the scratch kernel in comment #32 actually makes people's
> machines boot again, we're back to bug 947142.  The patches we added for
> that (and that went upstream) seem to be causing this issue, so reverting
> them fixes this bug but leaves us with the original problem.
> 
> One of the alternatives for the original problem was to not do space checks
> at all, but that leaves us with the er... original original problem.  Some
> machines will be susceptible to being bricked.  So we have 3 scenarios at
> the moment:
> 
> 1) Current state of affairs.  We can install and protect against machine
> bricking, but some people can't boot.
> 
> 2) Revert the patches causing people to not be able to boot (the scratch
> kernel), but then some subset of machines won't be able to install Fedora. 
> That is bug 947142.
> 
> 3) Revert the patches and boot with efi_no_storage_paranoia=1 by default. 
> That fixes the boot issue, and it avoids the space issue in bug 947142, but
> it means some machines (Samsung and reportedly Lenovo) can be bricked.
> 
> None of these are really great scenarios, but that is where we stand.

I read the mail discussion at http://marc.info/?t=136924016400007&r=1&w=2.
This may be a silly suggestion, but why not _temporarily_ split the kernel build to a build with and without the patch. On kernel updates, detect if the machine is a Samsung/Lenovo, and if it is, update with the patched kernel. Otherwise, do (3), until the problem is hopefully resolved in kernel 3.11. Of course, this should be done by the individual distributions and not in the upstream kernel. Can it be done or is it painful to implement this solution?
Comment 37 Russ Anderson 2013-05-31 18:10:34 EDT
(In reply to Josh Boyer from comment #34)
> 1) Current state of affairs.  We can install and protect against machine
> bricking, but some people can't boot.

Not booting is not an option.  See Ingo's comments in the community discussion.

> 2) Revert the patches causing people to not be able to boot (the scratch
> kernel), but then some subset of machines won't be able to install Fedora. 
> That is bug 947142.

Why is Fedora dependent on writing EFI variables to install?  It certainly did not used to be a dependency.  Why not just install with a warning message?

> 3) Revert the patches and boot with efi_no_storage_paranoia=1 by default. 
> That fixes the boot issue, and it avoids the space issue in bug 947142, but
> it means some machines (Samsung and reportedly Lenovo) can be bricked.

Bricking systems is not an option.

> None of these are really great scenarios, but that is where we stand.

Since #1 and #3 are not options, #2 is the only choice.
Comment 38 Rahul Sundaram 2013-05-31 18:47:49 EDT
@josh.  My laptop hasn't been able to boot with the last few kernel versions but the scratch build fixes the problem for me.  If you need more details, let me know.  Thanks!
Comment 39 Matthew Garrett 2013-05-31 20:05:43 EDT
> Why is Fedora dependent on writing EFI variables to install?  It certainly did not used to be a dependency

It's always been a dependency. You need to write an EFI variable to tell the firmware where your bootloader is, otherwise the system won't boot.

> Since #1 and #3 are not options, #2 is the only choice.

#2 is also not an option. This is unfortunate since it rules out all the options we currently have, so we need to find another option.
Comment 40 Paolo Leoni 2013-06-01 06:38:17 EDT
Actually I'm unable to boot with 3.9.X kernel, also in Legacy Mode (Bios Emulation).

If bug 947142 can be workarouded with legacy mode, I think that the better way is to revert the patches.
Comment 41 Josh Boyer 2013-06-01 15:45:37 EDT
(In reply to lu.error from comment #36)
> I read the mail discussion at http://marc.info/?t=136924016400007&r=1&w=2.
> This may be a silly suggestion, but why not _temporarily_ split the kernel
> build to a build with and without the patch. On kernel updates, detect if
> the machine is a Samsung/Lenovo, and if it is, update with the patched
> kernel. Otherwise, do (3), until the problem is hopefully resolved in kernel
> 3.11. Of course, this should be done by the individual distributions and not
> in the upstream kernel. Can it be done or is it painful to implement this
> solution?

That's not really feasible within Fedora infrastructure.
Comment 42 Ken Tobias 2013-06-01 16:42:10 EDT
(In reply to Matthew Garrett from comment #39)
> > Why is Fedora dependent on writing EFI variables to install?  It certainly did not used to be a dependency
> 
> It's always been a dependency. You need to write an EFI variable to tell the
> firmware where your bootloader is, otherwise the system won't boot.
> 
> > Since #1 and #3 are not options, #2 is the only choice.
> 
> #2 is also not an option. This is unfortunate since it rules out all the
> options we currently have, so we need to find another option.

Seems to be that the only option is to revert the patch. It was an invalid patch that broke the kernel for orders of magnitude more machines that it helped. That sounds to me like a bad patch that needs to be pulled ASAP.
Comment 43 Ken Tobias 2013-06-02 01:53:00 EDT
(In reply to Ken Tobias from comment #42)
> (In reply to Matthew Garrett from comment #39)
> > > Why is Fedora dependent on writing EFI variables to install?  It certainly did not used to be a dependency
> > 
> > It's always been a dependency. You need to write an EFI variable to tell the
> > firmware where your bootloader is, otherwise the system won't boot.
> > 
> > > Since #1 and #3 are not options, #2 is the only choice.
> > 
> > #2 is also not an option. This is unfortunate since it rules out all the
> > options we currently have, so we need to find another option.
> 
> Seems to be that the only option is to revert the patch. It was an invalid
> patch that broke the kernel for orders of magnitude more machines that it
> helped. That sounds to me like a bad patch that needs to be pulled ASAP.

That was a bit abrupt. Apologies.
Comment 44 Russ Anderson 2013-06-02 12:24:01 EDT
(In reply to Matthew Garrett from comment #39)
> > Since #1 and #3 are not options, #2 is the only choice.
> 
> #2 is also not an option. This is unfortunate since it rules out all the
> options we currently have, so we need to find another option.

Looks like you came up with another option.  Boots on SGI UV1 & UV2 systems,
with grub2, grub and elilo.  Thanks!

http://marc.info/?t=137011763400001&r=1&w=2
Comment 45 Josh Boyer 2013-06-03 11:12:28 EDT
(In reply to Russ Anderson from comment #44)
> (In reply to Matthew Garrett from comment #39)
> > > Since #1 and #3 are not options, #2 is the only choice.
> > 
> > #2 is also not an option. This is unfortunate since it rules out all the
> > options we currently have, so we need to find another option.
> 
> Looks like you came up with another option.  Boots on SGI UV1 & UV2 systems,
> with grub2, grub and elilo.  Thanks!
> 
> http://marc.info/?t=137011763400001&r=1&w=2

Here is a different scratch-build with that patch applied instead of the reverts.  Please test and let us know if this resolves booting for you:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5458508
Comment 46 Adam Williamson 2013-06-03 13:55:21 EDT
Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . Accepted as a blocker per https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Expected_installed_system_boot_behavior : "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account." etc (this could be taken under various criteria, really).

As per the kernel team, the situation here is basically: we can't release with the number of systems busted with the current code, so if this proposed fix isn't good, we need another one.
Comment 47 lu.error 2013-06-03 19:00:11 EDT
(In reply to Josh Boyer from comment #45)
> Here is a different scratch-build with that patch applied instead of the
> reverts.  Please test and let us know if this resolves booting for you:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5458508

I can confirm that the following kernels boot into the Fedora 18 distribution on the system I work on:
 kernel-3.9.4-300.8.fc19.x86_64.rpm
 kernel-debug-3.9.8-300.4.fc19.x86_64.rpm
Additional installed packages:
 kernel-modules-extra-3.9.4-300.8.fc19.x86_64.rpm
 kernel-headers-3.9.4-300.8.fc19.x86_64.rpm
Comment 48 Josh Boyer 2013-06-03 19:09:07 EDT
Thank you for testing.  I tested this locally on 3 different EFI machines and while they didn't exhibit any of the problem symptoms the kernel does boot on all of them.

I've added this patch and it will be included in the next set of builds.
Comment 49 Steven Rosenberg 2013-06-04 00:44:56 EDT
(In reply to Josh Boyer from comment #45)
> 
> Here is a different scratch-build with that patch applied instead of the
> reverts.  Please test and let us know if this resolves booting for you:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5458508

This boots fine for me in EFI mode. It doesn't boot with Secure Boot, but there are no problems at all with EFI.

This is the first 3.9.x kernel that hasn't panicked under EFI.
Comment 50 Paolo Leoni 2013-06-04 03:34:59 EDT
I can confirm that kernel-3.9.4-300 is ok for me, boot without panic.

Great work!
Comment 51 Fedora Update System 2013-06-04 08:10:01 EDT
kernel-3.9.4-301.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.9.4-301.fc19
Comment 52 Paolo Leoni 2013-06-04 09:20:48 EDT
Will be updated also package for F18?
Comment 53 Josh Boyer 2013-06-04 09:29:40 EDT
(In reply to Steven Rosenberg from comment #49)
> (In reply to Josh Boyer from comment #45)
> > 
> > Here is a different scratch-build with that patch applied instead of the
> > reverts.  Please test and let us know if this resolves booting for you:
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=5458508
> 
> This boots fine for me in EFI mode. It doesn't boot with Secure Boot, but
> there are no problems at all with EFI.

Secure Boot not working is expected with scratch build kernels.  They aren't signed with the Fedora certs.  The official build should work fine.

(In reply to Paolo Leoni from comment #52)
> Will be updated also package for F18?

Yes.  Bodhi will leave a comment similar to comment #51 when an F18 update is submitted.
Comment 54 Fedora Update System 2013-06-04 22:34:21 EDT
Package kernel-3.9.4-301.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.9.4-301.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10050/kernel-3.9.4-301.fc19
then log in and leave karma (feedback).
Comment 55 Fedora Update System 2013-06-05 11:02:36 EDT
kernel-3.9.4-101.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2013-9123/kernel-3.9.4-101.fc17
Comment 56 Michael McConachie 2013-06-05 22:49:55 EDT
3.9.4-200 (fc18 x86_64) has been a pita for me as well.  I can only confirm a hard lockup (every-time) w/ 3.9.4-200.  All previous kernels boot cleanly.

Specs:
Lenovo T520
Intel core i7 vPro
Comment 57 Michael McConachie 2013-06-05 22:52:12 EDT
So sorry, I meant to say 3.9.4-400 (fc18 x86_64) has been problematic.

3.9.4-200 (fc18 x86_64) boots fine for me, and (for the time being) is what I'm using day to day.
Comment 58 Adam Williamson 2013-06-06 00:37:25 EDT
There is no 3.9.4-400 kernel anywhere that I can see, for f17, f18 or f19. The way the numbering works, 400 would be a Rawhide kernel, but Rawhide is on 3.10. Could you double check what works and what doesn't for you? Thanks.
Comment 59 Michael McConachie 2013-06-06 10:53:38 EDT
(In reply to Adam Williamson from comment #58)
> There is no 3.9.4-400 kernel anywhere that I can see, for f17, f18 or f19.
> The way the numbering works, 400 would be a Rawhide kernel, but Rawhide is
> on 3.10. Could you double check what works and what doesn't for you? Thanks.

(

@Adam, too true. Thanks for catching that, and sorry for the confusion!  I typed it twice in a row, so let's chalk it up to a Peter Griffin moment.

I was referring to these two kernels:

kernel-3.9.4-200.fc18.x86_64
kernel-3.9.2-200.fc18.x86_64

For me, the problematic kernel is: 3.9.4-200.fc18.x86_64.

Very sorry for the dyslexic moment.
Comment 60 Paul Sprague 2013-06-06 11:11:16 EDT
I'm on F18 with an HP Pavilion dv7 (Intel HD graphics).  3.9.2 and 3.9.4 crash at boot for me.  3.8.11 works fine.

Thanks all for all the work on this.  Looking forward to the new kernel with the fix!

Paul
Comment 61 Paolo Leoni 2013-06-06 11:37:23 EDT
Paul, please if you can test this update:

http://koji.fedoraproject.org/koji/buildinfo?buildID=424616

and report here if it fix your problem.

A feedback would be useful.
Comment 62 Paul Sprague 2013-06-06 12:24:46 EDT
I downloaded and installed that kernel (only the kernel, do I need anything else?)

Does not boot, but hangs earlier.  I get three lines from grub:

Booting 'Fedora (3.9.4-302.fc19.i686)'
Loading Fedora (3.9.4-302.fc19.i686)
Loading initial ramdisk ...

Then the screen hangs there.  Maybe a dumb question, can I boot fc19 on Fedora 18?

Paul
Comment 63 Paul Sprague 2013-06-06 12:33:42 EDT
Never mind, and sorry for the churn.  I grabbed the 32 bit kernel in my excitement.  64 bit kernel boots just fine!

[psprague@ringworld:~]$ uname -a
Linux ringworld 3.9.4-302.fc19.x86_64 #1 SMP Tue Jun 4 17:53:56 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 64 Kevin.B.W.lee 2013-06-06 12:34:14 EDT
I have same problem, when I boot with kernel-3.9.4-200.fc18.x86_64
but, 3.6.10-4.fc18.x86_64 is fine.
hope fix it soon...

Kev.
Comment 65 Paul Miller 2013-06-06 12:47:54 EDT
Confirming  kernel-3.9.4-302.fc19.x86_64 also boots on my HP ENVY dv7 7240us with UEFI and Secure Boot enabled in F18.

Paul
Comment 66 Ken Tobias 2013-06-06 15:44:59 EDT
Confirming kernel-3.9.4-301.fc19.x86_64 and kernel-modules-extra-3.9.4-301.fc19.x86_64 boots and runs on my HP ENVY dv7 (i7, HD4000) with UEFI and Secure Boot in F18.
Comment 67 Fedora Update System 2013-06-07 00:32:28 EDT
kernel-3.9.4-301.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 68 tmjee 2013-06-07 08:38:51 EDT
Is this also available in the f18 repository? Tried yum update in f18 and the kernel version is not in the list, yum still says for f18 kernel-3.9.4-200.f18 is the latest and is still broken (kernel panic) on my toshiba p870 notebook.
Comment 69 Adam Williamson 2013-06-07 13:03:46 EDT
It looks pretty clear that this issue is affecting F18 too, so re-opening for F18. Kernel team, it seems indicated at this point to send the fix to F18 too.
Comment 70 Steven Rosenberg 2013-06-07 13:30:30 EDT
This does affect F18, but you can run the F19 kernel in F18 if you want the fix now. That's what I'm doing.
Comment 71 Paolo Leoni 2013-06-10 07:32:32 EDT
Much users don't know how to manually update kernel from F19 branch.
For users affected by this issue, kernel 3.9.2 on F18 is still broken, so it's important to update also in F18.
Comment 72 Josh Boyer 2013-06-10 14:47:07 EDT
(In reply to Adam Williamson from comment #69)
> It looks pretty clear that this issue is affecting F18 too, so re-opening
> for F18. Kernel team, it seems indicated at this point to send the fix to
> F18 too.

We already included it last week.  It'll be in the next f18 update submitted.  The 3.9.5-200 build already has the fix.
Comment 73 Fedora Update System 2013-06-11 05:17:53 EDT
Package kernel-3.9.5-100.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.9.5-100.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-9123/kernel-3.9.5-100.fc17
then log in and leave karma (feedback).
Comment 74 Fedora Update System 2013-06-11 17:55:51 EDT
kernel-3.9.5-201.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.9.5-201.fc18
Comment 75 Rahul Sundaram 2013-06-11 19:40:10 EDT
3.9.4-300.4.fc19.x86_64 works for me but the 3.9.5-201 in Fedora 18 goes into a shutdown sequence automatically and I can't boot into it.  Any ideas?
Comment 76 Josh Boyer 2013-06-11 20:00:46 EDT
(In reply to Rahul Sundaram from comment #75)
> 3.9.4-300.4.fc19.x86_64 works for me but the 3.9.5-201 in Fedora 18 goes
> into a shutdown sequence automatically and I can't boot into it.  Any ideas?

If it is going into a shutdown sequence, it isn't this bug.  This bug is a panic and you don't even boot.  Please file a new bug.
Comment 77 Rahul Sundaram 2013-06-11 22:25:26 EDT
Thanks.  filed #973475
Comment 78 Adam Williamson 2013-06-12 13:59:41 EDT
The F19 update went stable 5 days ago, so dropping the f19 blocker aspects of this, it's now just for f17/f18. Can be closed when those update go stable I guess.
Comment 79 Paul Sprague 2013-06-12 15:03:18 EDT
By the way, currently F19 installer uses 3.9.2-301.fc19.x86_64 for the installer kernel (not what gets installed, but the installer kernel itself).  I tried netinstall and the kde live, I would imagine gnome live would be the same.  I don't know if this gets automatically fixed at some point but for right now if you have a machine affected by this issue these installers will kernel panic.
Comment 80 Adam Williamson 2013-06-12 15:55:23 EDT
Er, what do you mean by 'currently'? Final TC2 included the fixed kernel-3.9.4-301.fc19 . Beta, of course, was built long ago and is not going to change.
Comment 81 Paul Sprague 2013-06-12 16:04:27 EDT
Ok, sorry, yes I was referring to the beta download on the main page.
Comment 82 Adam Williamson 2013-06-12 16:08:35 EDT
Ah, OK. Yeah, there are only three 'official public (pre-)release' milestones per cycle, Alpha, Beta, Final. If you want to get in a faster loop you can join the validation testing of the TC and RC builds, which are the 'test builds' for those three public (pre-)releases.
Comment 83 Paul Sprague 2013-06-12 17:13:00 EDT
TC2 installer up and running just fine of course.  Thanks for your patience and for pointing me in the right direction!
Comment 84 Fedora Update System 2013-06-13 02:00:05 EDT
kernel-3.9.5-201.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 85 Fedora Update System 2013-06-30 21:32:22 EDT
kernel-3.9.8-100.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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