Bug 320571 - Kernel 2.6.22 panic on GDT8546RZ
Kernel 2.6.22 panic on GDT8546RZ
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 427887
  Show dependency treegraph
 
Reported: 2007-10-05 13:45 EDT by Alexander Shadchnev
Modified: 2008-02-07 23:25 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-07 23:25:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of PC monitor when kernel panic (694.50 KB, image/jpeg)
2007-10-09 07:52 EDT, Alexander Shadchnev
no flags Details
screenshot of PC monitor when kernel panic (658.71 KB, image/jpeg)
2007-10-09 07:54 EDT, Alexander Shadchnev
no flags Details
screenshot of PC monitor when kernel panic (663.20 KB, image/jpeg)
2007-10-12 02:40 EDT, Alexander Shadchnev
no flags Details
screenshot of PC monitor when kernel panic (656.02 KB, image/jpeg)
2007-10-12 02:43 EDT, Alexander Shadchnev
no flags Details

  None (edit)
Description Alexander Shadchnev 2007-10-05 13:45:33 EDT
Description of problem:
When i try to upgrade to kernel-2.6.22.x I can't boot into system
I think this is because of raid controller
Version-Release number of selected component (if applicable):
Raid controller GDT8546RZ. Simple mirroring on 2 SATA drives
CPU Pentium-D 945 


How reproducible:
When i boot into any kernel 2.6.22 series i can't boot

After grub menu i see next screen
-----------------------------------
Redhat nash version 5.1.19.0.3 starting
kobject_add failed for :d-0000512 with -EEXIST, dont try to register things with
the same name in the same directory
Kernel panic - not- syncing: creation of kmalloc slab kmalloc_dma_512 size=512
failed
----------------------------------


When I boot into 2.6.20 kernel i see
--------------------------------------
Redhat nash version 5.1.19.0.3 starting

sda: assuming drive cache: write through
sda: assuming drive cache: write through
---------------
i.e. I this string printed 2 times
And after boot normal into OS.
Comment 1 Chuck Ebbert 2007-10-05 16:07:13 EDT
Can you remove kernel's the "quiet" option? Edit /etc/grub.conf and remove that
from the "kernel" line for the new kernel. Then boot and see what the last few
lines before the panic say. Or take a picture with a digital camera and attach that.
Comment 2 Lamont Peterson 2007-10-06 18:26:55 EDT
I've experienced a similar problem on my AMD64 box.  Installing F7 errata
kernels for 2.6.22..x all failed to boot properly.  The kernel panic would come
because the root LVM volume could not be found.  This was because the lvm driver
(from the initrd) couldn't see the SATA drive, which was because the kernel was
trying to load the wrong (I think) driver (again, in initrd).  It was loading
the pata_amd.ko module, but I have a sil_sata on my Tyan K8W (S2875 or S2885,
don't remember which off the top of my head) motherboard.

When errata kernels were being installed (via yum or rpm, doesn't matter), there
was an SELinux denial occuring which prevented depmod from reading  the
/boot/System-map-2.6.22.x-x.fc7 file.

I was able to successfully install errata and boot errata kernels by placing the
system in Permissive mode before running "yum update kernel" (on an otherwise
freshly booted box, no other changes).  I did this with the 2.6.22.9-91.fc7
kernel.  I would guess that this workaround would have helped other 2.6.22.x
kernels, but I have not tested that.

My filesystem is on LVM, I have carved up the system into a few logical volumes,
which are using either ext3 or xfs filesystems.  There are no other SELinux
related issues occurring.
Comment 3 Alexander Shadchnev 2007-10-09 07:52:49 EDT
Created attachment 221171 [details]
screenshot of PC monitor when kernel panic
Comment 4 Alexander Shadchnev 2007-10-09 07:54:50 EDT
Created attachment 221181 [details]
screenshot of PC monitor when kernel panic
Comment 5 Alexander Shadchnev 2007-10-09 08:38:12 EDT
I put system in permisive mode and reboot into 2.6.22 
 and again kernel panic
I reinstall last kernel in permisive mode and reboot intp 2.6.22
  kernel panic

Comment 6 Chuck Ebbert 2007-10-09 14:33:33 EDT
(In reply to comment #4)
> Created an attachment (id=221181) [edit]
> screenshot of PC monitor when kernel panic
> 

Still can't see the whole trace. Can you boot with the kernel option "vga=792"
and capture the entire thing?
Comment 7 Chuck Ebbert 2007-10-09 14:48:42 EDT
This bug can possibly be avoided by booting with the option:

  slub_debug=-

(a single minus sign.)
Comment 8 Alexander Shadchnev 2007-10-12 02:35:17 EDT
slub_debug doesnt help
Comment 9 Alexander Shadchnev 2007-10-12 02:40:39 EDT
Created attachment 225111 [details]
screenshot of PC monitor when kernel panic

screenshot of PC monitor when kernel panic
Comment 10 Alexander Shadchnev 2007-10-12 02:43:03 EDT
Created attachment 225141 [details]
screenshot of PC monitor when kernel panic

screenshot of PC monitor when kernel panic
Comment 11 Jon Stanley 2008-01-07 20:48:11 EST
(This is a mass-update to all current FC6 kernel bugs in NEW state)

Hello,

I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug, however this version of Fedora is no longer
maintained.

Please attempt to reproduce this bug with a current version of Fedora (presently
Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a
few days if there is no further information lodged.

Thanks for using Fedora!
Comment 12 Jon Stanley 2008-02-07 23:25:41 EST
Per the previous comment in this bug, I am closing it as INSUFFICIENT_DATA,
since no information has been lodged for over 30 days.

Please re-open this bug or file a new one if you can provide the requested data,
and thanks for filing the original report!

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