| Summary: | Kernel panic - not syncing: Fatal exception, on boot in MRG2.0 on HS21 hardware. | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | IBM Bug Proxy <bugproxy> | ||||||||||
| Component: | realtime-kernel | Assignee: | John Kacur <jkacur> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | David Sommerseth <davids> | ||||||||||
| Severity: | urgent | Docs Contact: | |||||||||||
| Priority: | urgent | ||||||||||||
| Version: | 2.0 | CC: | bhu, jkachuck, lgoncalv, ovasik, wgomerin, williams | ||||||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-02-28 16:39:05 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Attachments: |
|
||||||||||||
|
Description
IBM Bug Proxy
2011-10-18 15:01:05 UTC
Created attachment 528830 [details]
Config file of system
Created attachment 528831 [details]
Console of a failing system
------- Comment From niv.com 2011-10-18 11:51 EDT------- Red Hat -- Clark Williams is aware of the issue and should be added to bug. Clark, please send over ptr to any bits you want us to test on MRG 2.1 train as mentioned offline yesterday. Also, if you're unable to reproduce this issue on your HS21xm, let us know! Just re-provisioned one of my hs21xm's and it comes up properly with the MRG 2.0 kernel. [williams@hs21xm-2 ~]$ lspci | grep -i vga 01:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) [williams@hs21xm-2 ~]$ uname -a Linux hs21xm-2.farm.hsv.redhat.com 2.6.33.9-rt31.76.el6rt.x86_64 #1 SMP PREEMPT RT Tue Oct 4 12:01:48 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux [williams@hs21xm-2 ~]$ cat /proc/cmdline ro root=/dev/mapper/vg_hs21xm2-lv_root rd_LVM_LV=vg_hs21xm2/lv_root rd_LVM_LV=vg_hs21xm2/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto pci=nocrs console=tty0 console=ttyS1,19200 radeon.modeset=0 rhgb quiet Does your kernel command line look similar to the above? ------- Comment From kravetz.com 2011-10-18 15:36 EDT------- The command line on our system did not contain "pci=nocrs" or "radeon.modeset=0". After adding these arguments, we were able to boot MRG 2.0 kernels (well at least 74). Did we miss the mention of these arguments in some release notes or other documentation? the pci=nocrs argument was in the release notes (along with radeon.hw_i2c=0): http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/2/html-single/MRG_Release_Notes/index.html#chap-MRG_Release_Notes-RT I suspect that pci=nocrs is the key here. ------- Comment From kravetz.com 2011-10-18 15:58 EDT------- They are documented in: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/2/pdf/MRG_Release_Notes/Red_Hat_Enterprise_MRG-2-MRG_Release_Notes-en-US.pdf ------- Comment From kravetz.com 2011-10-18 16:13 EDT------- We did not read the release notes. However, upon closer examination the notes say to add "pci=use_crs", and we can not find mention of "pci=nocrs". ------- Comment From niv.com 2011-10-18 17:11 EDT------- I had skimmed the release notes (this is quite a while back now). Nothing I saw had jumped out at me as an urgent or needed item, somehow. I didn't get a "do this else your system will not boot". I'd recommend clarifying the documentation to correct the parameter setting needed (nocrs?) at the very least. ------- Comment From niv.com 2011-10-18 17:19 EDT------- Lowering priority due to workaround via boot params. Created attachment 529544 [details]
HS20 boot hang with pci=nocrs radeon.modeset=0
------- Comment on attachment From pc.com 2011-10-21 13:34 EDT-------
I just hit this problem on an HS20. Adding "pci=nocrs" and "radeon.modeset=0" (I don't see either in the release notes) seems to get further, but it panics, oops, or hangs later on in the boot...attaching a boot log.
------- Comment From pc.com 2011-10-21 15:13 EDT------- (In reply to comment #27) > I just hit this problem on an HS20. Adding "pci=nocrs" and "radeon.modeset=0" > (I don't see either in the release notes) seems to get further, but it panics, > oops, or hangs later on in the boot...attaching a boot log. I posted this too soon. As will be obvious in the attachment, I was running the .67 kernel. I've updated to the .75 kernel, and the HS20 has booted successfully.. Closing as working in the current release reopening to look at adding quirk to deal with HS21 on boot with 2.0 kernel Created attachment 532141 [details]
proposed quirk for HS21 boot issue
the attached patch has not been tested, it is only provided to illustrate how we can catch that we're booting on an HS21 and automagically set pci=nocrs. I know that there is further testing going on so will hold off on adding this patch to the kernel until I hear more about whether it's always needed, whether it's HS21 and not HS21xm, etc.
------- Comment From niv.com 2012-02-21 15:50 EDT------- Will see if we can retest on the MRG 2.0 testing train later this week. ------- Comment From niv.com 2012-02-27 14:56 EDT------- Just wanted to confirm with Clark if there is going to be a MRG 2.0 errata kernel. If there is not, we should close this as WILLNOTFIX. We have no plans to fix this in the 2.6.33.7 kernel. Just confirmed that the 3.0.x rt kernel series boots properly with any combination of radeon.modeset=0 and pci=nocrs on an hs21xm blade. Closing this as WONTFIX ------- Comment From niv.com 2012-02-29 19:33 EDT------- Clark, Closing this from our end as well. The only thing we'll do is make sure the future documentation is right on MRG 2.2. If it's not, we'll open a new bug. |