Bug 187641 - kernel-2.6.16-1.2069_FC4 SATA panic
kernel-2.6.16-1.2069_FC4 SATA panic
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-01 23:27 EST by Jerry Williams
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-13 23:30:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jerry Williams 2006-04-01 23:27:15 EST
Description of problem: Kernel can't set xfermode on SATA disks and
as a result can't find the volume group and panics.

Version-Release number of selected component (if applicable):
kernel-2.6.16-1.2069_FC4.i686.rpm

How reproducible:
Happens everytime I try and boot that version of kernel.

Steps to Reproduce:
1. Just boot system
2.
3.
  
Actual results:
It tries to boot up normal and then it says:
ata1: failed to set xfermode, disabled
ata2: failed to set xfermode, disabled
Reading all physical volumes. This may take a while...
No volume groups found
Unable to find volume group "V0"
Error: /bin/lvm exited abnormally with value 5 ! (pid 328)
mount: error 6 mounting ext3
Error opening /dev/console!!!!: 2
Error dup2'ing fd of 0 to 0
Error dup2'ing fd of 0 to 1
Error dup2'ing fd of 0 to 2
Switchroot: mount failed: 22
Kernel panic - not syncing: Attempted to kill init!


Expected results:
Should find set xfermode and find volume group and boot.

Additional info:
With 2.6.15-1.1833_FC4 kernel some of dmesg looks like:
CPU: AMD Athlon(tm) XP 2600+ stepping 01
PCI: Bypassing VIA 8237 APIC De-Assert Message
SCSI subsystem initialized
libata version 1.20 loaded.
sata_via 0000:00:0f.0: version 1.1
sata_via 0000:00:0f.0: routed to hard irq line 11
ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma 0xD800 irq 11
ata2: SATA max UDMA/133 cmd 0xE000 ctl 0xDC02 bmdma 0xD808 irq 11
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69 86:3e01 87:4003 88:407f
ata1: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : sata_via
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69 86:3e01 87:4003 88:407f
ata2: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48
ata2: dev 0 configured for UDMA/133
scsi1 : sata_via
  Vendor: ATA       Model: Maxtor 6Y250M0    Rev: YAR5
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
sd 0:0:0:0: Attached scsi disk sda
  Vendor: ATA       Model: Maxtor 6Y250M0    Rev: YAR5
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sdb: drive cache: write back
 sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 sdb7 >
sd 1:0:0:0: Attached scsi disk sdb
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com

Not running any raid or mirroring.
Comment 1 Dave Jones 2006-09-16 22:22:47 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 2 Jerry Williams 2006-09-16 23:24:09 EDT
I am not sure that I can retest with FC5.
If my machine doesn't boot then what good is it?
I will have to see if I can find another way to boot my machine and have it 
work and then I might try FC5.
Comment 3 Jerry Williams 2006-09-20 00:08:36 EDT
I upgraded my machine to FC5 and broke it.
I booted my system with linux rescue and copied over the
kernel-2.6.15-1.1833_FC4.i686.rpm and installed it and it boots fine
with that kernel.  Can't boot with either of the FC5 kernels.
I did find that I appear to be using dmraid.

Booting 'Fedora Core (2.6.15-1.2054_FC5)' 

root (hd0,0) 
 Filesystem type is ext2fs, partition type 0x83 
kernel /vmlinux-2.6.15-1.2054_FC5 ro root=/dev/V0/L1 acpi=off rhgb quiet 
      [Linux-bzImage, setup=0x1e00, size=0x16eb71] 
initrd /initrd-2.6.15-1.2054_FC5.img 
     [Linux-initrd @ 0x37e3c000, 0x1b312a bytes] 

Uncompressing Linux... Ok, booting the kernel. 
Red Hat nash version 5.0.32 starting 
ata1: failed to set xfermode, disabled 
ata2: failed to set xfermode, disabled 
device-mapper: dm-mirror: Device lookup failure 
device-mapper: reload ioctl failed: No such device or address 

Unable to open /dev/mapper/via_jheaibjjh - unrecognised disk label. 
   Reading all physical volumes.  This may take a while... 
   No volume groups found 
   Unable to find volume group "V0" 
Unable to access resume device (/dev/V0/L0) 
mount: could not find filesystem '/dev/root' 
setuproot: moving /dev failed: No such file or directory 
setuproot: error mounting /proc: No such file or directory 
setuproot: error mounting /sys: No such file or directory 
switchroot: mount failed: No such file or directory 
Kernel panic - not syncing: Attempted to kill init! 

With kernel 2.6.17-1.2187_FC5 the message is pretty much the same except for:

ata1: failed to set xfermode (err_mask=0x4) 
ata2: failed to set xfermode (err_mask=0x4)
Comment 4 Jerry Williams 2006-10-13 23:30:13 EDT
Looks like there is something to do with dmraid.
I recompiled the kernel with #define ATA_DEBUG in libata.h and when I ran it I 
expected it to fail, but it didn't.
I am thinking that because of all of the debug info that it slowed things down 
enough for it to do some kind of recover to the raid information.
Once that happened I can now boot from any of the newer kernels.

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