Bug 708812

Summary: Regression in Marvel 6440 SAS with the F15 installer kernel
Product: [Fedora] Fedora Reporter: Bryce <root>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, wcronen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-22 11:43:29 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 Flags
screenshot of sas failure none

Description Bryce 2011-05-29 17:58:43 UTC
Description of problem:

I've an F14 system which has a fairly large populated raid array spread out over 5 2Gb drives. I intended to upgrade to F15 but discovered that unlike the F14 kernel


Anyhow,..
F14
[root@blackknight ~]# cat /etc/issue
Fedora release 14 (Laughlin)
Kernel \r on an \m (\l)

[root@blackknight ~]# uname -a
Linux blackknight 2.6.35.13-91.fc14.x86_64 #1 SMP Tue May 3 13:23:06 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

has worked fine right from it was first installed off the ISO image... as for F15,. it seems to have a bit of a crisis with talking to the SAS drives


F14:
[root@blackknight ~]# dmesg | grep ata17
[   12.022827] ata17.00: ATA-8: Hitachi HUA722020ALA330, JKAOA3EA, max UDMA/133
[   12.022832] ata17.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   12.024297] ata17.00: configured for UDMA/133
[root@blackknight ~]# hdparm -i /dev/sdi

/dev/sdi:

 Model=Hitachi HUA722020ALA330, FwRev=JKAOA3EA, SerialNo=JK11A8B9H0GBTF
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
 BuffType=DualPortCache, BuffSize=29999kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=3907029168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

I've had to take a digital pic of the F15 problem which I've attached
ata17.00: failed to IDENTIFY (I/O, err_mask=0x40)
scsi_alloc_sdev: Allocation failure during SCSI scanning....

This becomes highly problematical because it's not possible to bring up the raid5 set and there are no additional sata/sas ports available (6 sata x 2 sas)

Phil
=--=

Comment 1 Bryce 2011-05-29 17:59:30 UTC
Created attachment 501635 [details]
screenshot of sas failure

Comment 2 Bryce 2011-05-29 18:03:25 UTC
I should mention that the mvsas driver is the same version in the F14 and F15 kernels. libsas has a differing srcversion number.

Mmm other than the drives being 2Tb in size (which has previously been ok) I'm a buit lost as to where to go from here especially as this is the boot media which would be a little tricky to rebuild with a differing kernel

Comment 3 Bryce 2011-05-29 18:28:00 UTC
Additional: noapic doesn't help either

Comment 4 wcronen 2011-06-17 20:25:35 UTC
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=705019

Comment 5 Chuck Ebbert 2011-06-22 11:43:29 UTC

*** This bug has been marked as a duplicate of bug 705019 ***