Bug 12703
Summary: | Intel X25-E 32GB+MCP55_nvidia_sata+2.6.28=it not work together | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Dusan Pavlik (dusan_pavlik) |
Component: | Serial ATA | Assignee: | Tejun Heo (tj) |
Status: | RESOLVED CODE_FIX | ||
Severity: | high | CC: | david, per.wigren |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.28.4 - mandriva 2009.1beta | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Boot from live cd
not booting with new kernel _1 not booting with new kernel _2 opensuse 11.1 -mesage dmesg from 2.6.29.1 nv-deb-long.patch 2.6.30-rc6 dmesg patched nohrst dmesg 2.6.30-rc6 patched 2.6.30-rc6 kernel config dmesg with force 1.5 no-ipm-on-resume.patch dmesg with second patch added nv-hardreset-only-on-probing.patch nv-hardreset-only-on-probing.patch dmesg with the patch, it appears to work updated dmesg with detatch and reconnect |
Description
Dusan Pavlik
2009-02-14 08:58:04 UTC
Created attachment 20247 [details]
Boot from live cd
When it not work. Mandriva 2009
The /dev/sdc is not created. (is pluget on sata6). But is isn´t work when is pluget in SATA1. Is not important.
Hello, Dusan. I'm having a difficult time understanding your last sentence. So, the ssd works if it's connected to ata1 but doesn't when it's plugged into ata6? Created attachment 20259 [details]
not booting with new kernel _1
Is not work with every sata ports (SATA1, SATA2,....)
I sending new experiment with it. I´m installing MAndriva2008.1(when it´s work)
and I make upgrade to 2009.1beta(kernel mdv2.6.28.4). Everything is ok when I booting on old kernel (mdv2.6.24.7). When I booting in new kernel mdv2.6.28.4 it don´t booting and is only writing which is in attachment.
Ps. sorry for my new account and English
Created attachment 20260 [details]
not booting with new kernel _2
Nah.. My English isn't that good either. Don't worry about it. Hmm... you're using IDE drivers and I'm not too familiar with mandravia. Can you please give a shot at openSUSE 11.1 live CD? Pressing alt-f4 will give you the kernel message console once the kernel is loaded. It may be the same problem. http://bugs.archlinux.org/task/12361 http://bugzilla.kernel.org/show_bug.cgi?id=12176 But why other standard sata disk is working? With Mandriva kernel 2.6.28.4. I send new experiences when I will be home 28.2.2009. Those two bug reports are different ones and happens no matter which device is attached. Yours seems to be PHY compatibility problem between the SSD and the controller. Does specifying "libata.force=1.5Gbps" help? Created attachment 20391 [details] opensuse 11.1 -mesage Attachment 4 [details]. I use Opensuse live cd 11.1. It working like as in fedora 10. "libata.force=1.5Gbps" is not working Dusan, can you please elaborate a bit? From the posted log from openSUSE 11.1, it looks like everything is fine, right? Also, what do you mean by "libata.force=1.5Gbps" is not working? The linked attachment doesn't seem to be related? libata.force=1.5Gbps is not working with kernel MDV 2.6.28.4, MDV 2.6.29 rc6, Fed11(alpha)2.6.29. (I´m try which you writing in Comment 7) In Opensuse live is kernel 2.6.27.7=its work In Fedora 10 2.6.27.5 =its work In Mandriva kernel 2.6.24 =its work Its may problem with patch for kernel 2.6.28 (its may be old because MDV with 2.6.27.0 is doesn't work) http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.28.y.git&a=search&h=HEAD&st=commit&s=amd74xx http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.28.y.git&a=search&h=HEAD&st=commit&s=MCP55 Thanks. Dusan, I'm sorry but I'm still having problem understanding what you're reporting. According to the log posted in comment#8, the intel SSD is working fine on ata8 at 3Gbps without libata.force=1.5Gbps, so I take it that the SSD works fine on both openSUSE 11.1 without any parameter, right? I don't really understand what you mean by "libata.force=1.5Gbps is not working". Do you mean that without it the detection is fine but with it detection doesn't work? Or the parameter libata.force=1.5Gbps isn't effective at all? So, to sum it up, * openSUSE 2.6.27.7, fedora 2.6.27.5 and Mandravia 2.6.25 work fine. * MDV 2.6.28.4 and 2.6.29rc6 and Fedora 2.6.28 don't work. Am I getting it right? Yes, you are right. In first report I writing "Latest working kernel version:MDV 2.6.24.7, Fed10 2.6.27.5 Earliest failing kernel version:MDV 2.6.27.0, MDV 2.6.28.4, Fed11(alpha)2.6.29" I´m add in grub parameter "libata.force=1.5Gbps" and is not working for kernels MDV 2.6.27.0, MDV 2.6.28.4, Fed11(alpha)2.6.29. (MDV is short cut for mandriva) Do you mean I must buy new motherboard with chipset from AMD or Intel processor? I´ts really not good. I have AMD processor with TDP 35W(I have passive cooling for this processor). Ah.. okay, so libata.force doesn't make any difference and later kernels don't work. And no, you shouldn't need to buy a new board. We're having some trouble with nv device detection. Are you comfortable with building your own kernel? If so, can you please give a shot at 2.6.28.7? There have been several nv reset related updates. Thanks. I compiling kernel 2.6.28.7 (from kernel.org - make xconfig, make, make modules_install, make install) and instaling kernel-linus-2.6.29.0 rc7.1(from mandriva -rpm) its looking good when is starting initrd.img. (its very fast but I see it make the sda device) But when loading the kernel modules the system is not start. It may be problem with "nash" script because when I install this kernels its working with 100% load. ( make install is stoping with errors) I wait for updait nash and I report if work Intel SSD with this kernels. Thanks. If you include all the drivers and filesystem for root fs in the kernel proper (y instead of m), you won't need initrd or nash. It's usually easier to test that way. FYI, this problem still exists in 2.6.29.1. I still can't use my Intel X-25-E in kernels newer than 2.6.28.3 :( Can you please post failing boot log from 2.6.29.1? We presumably should have all nv detection problems fixed now. Created attachment 20906 [details]
dmesg from 2.6.29.1
As I have cloned the SSD to a standard SATA disk temporarily until I can get the SSD, the boot didn't fail, but there is no trace of the Intel SSD disk. The Intel X-25-E is on SATA-port 1 and I have a 300 GB Maxtor on SATA port 2 which I booted from, which is seen as /dev/sda. (an iSCSI disk on /dev/sdb get added later on in the init scripts) This is the related dmesg lines from 2.6.28.3: ata6: SATA max UDMA/133 cmd 0xc000 ctl 0xbc00 bmdma 0xb808 irq 23 ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.00: ATA-7: SSDSA2SH032G1GN INTEL, 045C8621, max UDMA/133 ata6.00: 62500000 sectors, multi 1: LBA48 NCQ (depth 31) ata6.00: configured for UDMA/133 sd 6:0:0:0: [sdf] 62500000 512-byte hardware sectors: (32.0 GB/29.8 GiB) sd 6:0:0:0: [sdf] Write Protect is off sd 6:0:0:0: [sdf] Mode Sense: 00 3a 00 00 sd 6:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 6:0:0:0: [sdf] Attached SCSI disk sd 6:0:0:0: Attached scsi generic sg5 type 0 (I had more disks connected then) Does "libata.force=6:nohrst" make nay difference? Yes! With that option it works! Is it safe to use the disk with that option until a proper fix is available? Yeap, it's safe to run with the option. Hmm... I wonder why it isn't working without the option. :-( I'll try to think of something. Created attachment 20932 [details]
nv-deb-long.patch
Can you please give a shot at the attached patch and see whether there's any difference? Thanks.
I will give it a try after Easter. I don't have time at the moment. Thanks! This parameter "libata.force=6:nohrst" for installation CD mandriva 2009.1 RC2 (kernel 2.6.29) is not work. System is doesn't see the Intel disk. Do you mean problem is only with chip-set driver? Or problem is between new kernel sata system and Intel SSD disk? Because I can´t try this disk in other PC with other chip-set. Nash script problem is still her for upgrading new kernel. (It may be problem with upgrade from mdv2008.1) https://qa.mandriva.com/show_bug.cgi?id=48790 Thanks. Dusan, you'll probably need to do something inside initrd image. It differs between distros and I don't know much about mandriva. Yes, it's highly likely to be chipset-specific. I am seeing the same problem on 2.6.29.3 I have not yet tried the parameter or patch, I will try to do so later today. adding libata.force=1:nohrst lets it detect the intel drive on the first sata connector. In my case I am using a monolithic kernel. applying the patch (nv-deb-long.patch) does not help David, can you please post kernel boot log with the patch applied? Thanks. And boot log with nohrst workaround. Created attachment 21442 [details]
2.6.30-rc6 dmesg patched nohrst
Created attachment 21443 [details]
dmesg 2.6.30-rc6 patched
Created attachment 21444 [details]
2.6.30-rc6 kernel config
Strange. Interface is active but there's no sign of device (DET is zero). I don't have much idea what's going on. Does "libata.force=2:1.5Gbps" make any difference? Thanks. adding libata.force=2:1.5Gbps doesn't make any difference to the link down message, it still shows SStatus 100 when you say 'DET is zero', what are you looking at to see that? The SStatus has three four-bit fields IPM, SPD and DET, so SStatus 0x123 indicates IPM=1, SPD=2, DET=3 which means interface is active at Gen2 speed with device present and Phy communication established. The port the ssd is attached to is reporting 0x100 which says link is powered up but nothing seems to be attached to the port. Unfortunately, I don't have much idea how to proceed on this. Ergh... Can you please post the boot log with 1.5Gbps parameter just in case? Thanks. Created attachment 21476 [details]
dmesg with force 1.5
Created attachment 21477 [details]
no-ipm-on-resume.patch
Can you please give a shot at this patch?
no difference Can you please attach boot log? Even if it doesn't look useful now, it might turn out to be later, so... Created attachment 21478 [details]
dmesg with second patch added
one interesting thing I noticed is that the order of the ports reporting has changed since the initial runs, it was in numerical order, now it's not. is this the result of the prior patch?
No, it's not. The order is non-deterministic depending on the timing of things. If you unplug and replug the drive after detection failed, does it get detected? Release Date: 06/26/2007 it is detected on a replug from dmesg ata2: exception Emask 0x10 SAct 0x0 SErr 0x150000 action 0xe frozen ata2: SError: { PHYRdyChg CommWake Dispar } ata2: hard resetting link ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata2.00: ATA-7: SSDSA2SH032G1GN INTEL, 045C8621, max UDMA/133 ata2.00: 62500000 sectors, multi 1: LBA48 NCQ (depth 31) ata2.00: configured for UDMA/133 ata2: EH complete scsi 1:0:0:0: Direct-Access ATA SSDSA2SH032G1GN 045C PQ: 0 ANSI: 5 sd 1:0:0:0: Attached scsi generic sg2 type 0 sd 1:0:0:0: [sdb] 62500000 512-byte hardware sectors: (32.0 GB/29.8 GiB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: unknown partition table sd 1:0:0:0: [sdb] Attached SCSI disk anything else for me to try? Created attachment 21646 [details]
nv-hardreset-only-on-probing.patch
Can you please try this patch? Thanks.
Created attachment 21648 [details]
nv-hardreset-only-on-probing.patch
Oops, inverted condition. Please test this one. Thanks.
Created attachment 21716 [details]
dmesg with the patch, it appears to work
Can you please try the followings? 1. Boot with the patch applied. 2. Disconnect the SSD. 3. echo - - - > /sys/class/scsi_host/host2/scan 4. Wait for the device to be detached. 5. Replug the SSD. 6. echo - - - > /sys/class/scsi_host/host2/scan 7. Wait for the device to be attached. 8. Attach dmesg. Thanks. Created attachment 21722 [details]
updated dmesg with detatch and reconnect
This patch from comment #48 is good? It will be on kernel 2.6.31? (this kernel will be in mandriva 2010.0). Thanks. OK I see it on change log on http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.31-rc1. If I want it using for my SSD, I must add any parameter to grub or anything else? no, with the patch no grub changes are needed Resolving as FIXED. |