Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 320571 - Kernel 2.6.22 panic on GDT8546RZ
Summary: Kernel 2.6.22 panic on GDT8546RZ
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 427887
TreeView+ depends on / blocked
 
Reported: 2007-10-05 17:45 UTC by Alexander Shadchnev
Modified: 2008-02-08 04:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-08 04:25:41 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
screenshot of PC monitor when kernel panic (deleted)
2007-10-09 11:52 UTC, Alexander Shadchnev 		no flags Details
screenshot of PC monitor when kernel panic (deleted)
2007-10-09 11:54 UTC, Alexander Shadchnev 		no flags Details
screenshot of PC monitor when kernel panic (deleted)
2007-10-12 06:40 UTC, Alexander Shadchnev 		no flags Details
screenshot of PC monitor when kernel panic (deleted)
2007-10-12 06:43 UTC, Alexander Shadchnev 		no flags Details
Show Obsolete (2) View All

Description Alexander Shadchnev 2007-10-05 17:45:33 UTC 
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 20:07:13 UTC 
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 22:26:55 UTC 
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 11:52:49 UTC 
Created attachment 221171 [details]
screenshot of PC monitor when kernel panic
Comment 4 Alexander Shadchnev 2007-10-09 11:54:50 UTC 
Created attachment 221181 [details]
screenshot of PC monitor when kernel panic
Comment 5 Alexander Shadchnev 2007-10-09 12:38:12 UTC 
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 18:33:33 UTC 
(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 18:48:42 UTC 
This bug can possibly be avoided by booting with the option:

  slub_debug=-

(a single minus sign.)
Comment 8 Alexander Shadchnev 2007-10-12 06:35:17 UTC 
slub_debug doesnt help
Comment 9 Alexander Shadchnev 2007-10-12 06:40:39 UTC 
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 06:43:03 UTC 
Created attachment 225141 [details]
screenshot of PC monitor when kernel panic

screenshot of PC monitor when kernel panic
Comment 11 Jon Stanley 2008-01-08 01:48:11 UTC 
(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-08 04:25:41 UTC 
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.