Created attachment 57122 [details]
add-TTI-0622-to-ahci.patch

Can you please try the attached patch and post the kernel boot log?

Thank you.

Cc'ing Mark just in case.  I'm shooting in the dark and just added an unknown Highpoint PCI ID as an ahci device.  Mark, I know your contact with marvell is limited but if you know somebody there, please ask them to talk to us.  We really need to sort out this marvell thing.

Thank you.

Created attachment 57692 [details]
kern.log extract shows boot of kernel with initial patch applied.

This is great!  the disks now shows up as /dev/sdf on lsscsi.
I did mkfs.btrfs on it,  what sort of torture test should I apply to ensure that kernel really understands the controller?

Please note, the original patch did not apply cleanly, to ubuntu stock kernel.  It was just offset by a few lines, so did it manually.  I assume ubuntu must have some patches, please provide instructions as to what tree I should be pulling from.

sorry, it shows up as /dev/sdg, not f.  c,d,e & f are being access through an on-board controller I am using to work around not being able to use the rr622.  I put a single disk on the rr622 to be able to test.  That disk shows up as /dev/sdg

Hmmm... the marvell device @ pci 02:00.1 doesn't seem to be an AHCI controller at all and /dev/sdg is not connected to that device.

You have a port multiplier connected to one of the ports coming off AHCI controller @ pci 00:11.0, which looks like the south bridge.  The PMP is Silicon Image 3726 and there are four devices attached to it.

 ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
 ata7.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9
 ...
 ata7.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320)
 ata7.00: ATA-8: WDC WD5000AAKS-00C8A0, 12.01C02, max UDMA/133
 ata7.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
 ata7.00: configured for UDMA/133
 ata7.01: ATA-8: WDC WD5000AAKS-00C8A0, 12.01C02, max UDMA/133
 ata7.01: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
 ata7.01: configured for UDMA/133
 ata7.02: ATA-8: ST31000524NS, SN12, max UDMA/133
 ata7.02: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
 ata7.02: configured for UDMA/133
 ata7.03: ATA-8: ST31000524NS, SN12, max UDMA/133
 ata7.03: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
 ata7.03: configured for UDMA/133

ata7.03 is sd 6:3:0:0, which in turn is /dev/sdg.

So, the marvell controller still isn't working and it doesn't seem to be an ahci controller.

Created attachment 57712 [details]
mounted /dev/sdg as /mnt, and ran bonnie.

Is this good torture?

Peter, the patch didn't do anything.  SBx00 ahci + SIMG3726 is a known working configuration (well, 3726 is known to be flaky too) and doesn't have anything to do with the marvell controller.  I don't know why it didn't work before tho.

Created attachment 57722 [details]
better kernel log.

Sorry, original log had before and after boots.  second boot in the log, from May 12th is with the patch applied. I updated the attachment to remove the may 11th boot without the patch.  so now, /dev/sdg is different!

The RAID tower is a Sans digital tr8m.  It has 8 drive bays, and two PC Link connections. I think that each PC-link connection is for one four-bay module in the RAID unit.  

After booting may 12th, I see:

alu% lsscsi
[0:0:0:0]    disk    ATA      ST3120026AS      3.05  /dev/sda
[2:0:0:0]    disk    ATA      WDC WD1600JS-55N 10.0  /dev/sdb
[4:0:0:0]    disk    ATA      WDC WD5000AAKS-0 12.0  /dev/sdc
[4:1:0:0]    disk    ATA      WDC WD5000AAKS-0 12.0  /dev/sdd
[4:2:0:0]    disk    ATA      ST31000524NS     SN12  /dev/sde
[4:3:0:0]    disk    ATA      ST31000524NS     SN12  /dev/sdf
[6:0:0:0]    disk    ATA      WDC WD7500AAKS-0 30.0  /dev/sdg
[8:0:0:0]    cd/dvd  HL-DT-ST DVDRAM GSA-4082B A201  /dev/sr0
[8:0:1:0]    cd/dvd  HL-DT-ST DVD-ROM GDR8162B 0015  /dev/sr1
[10:0:0:0]   disk    TRUSTED  Mass Storage     1.00  /dev/sdh
alu% 

There are:
via PC link 1 (pm): two WD5000, and two ST31000.  they show up on [4:...]
via PC Link 2 (rr622): a single WD7500.  [6:...]  

I think ata6 is the highpoint rocket raid (rr622).  If it was through port multiplier, it would be 4:4.

very confused now... reverted to original stock ubuntu kernel, cabled using configuration as designed rr622 ESATA plugged into PC Links 1 and 2.  all five drives present themselves in both bays.


May 14 00:40:19 alu kernel: [    4.548948]  sdc: unknown partition table
May 14 00:40:19 alu kernel: [    4.549087] sd 8:0:0:0: [sdc] Attached SCSI disk
May 14 00:40:19 alu kernel: [    4.870184] ata10.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
May 14 00:40:19 alu kernel: [    4.870200] ata10.04: hard resetting link
May 14 00:40:19 alu kernel: [    5.220160] ata10.04: SATA link down (SStatus 0 SControl 320)
May 14 00:40:19 alu kernel: [    5.220186] ata10.05: hard resetting link
May 14 00:40:19 alu kernel: [    5.570186] ata10.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320)
May 14 00:40:19 alu kernel: [    5.582178] ata10.00: ATA-8: WDC WD5000AAKS-00C8A0, 12.01C02, max UDMA/133
May 14 00:40:19 alu kernel: [    5.582181] ata10.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
May 14 00:40:19 alu kernel: [    5.583209] ata10.00: configured for UDMA/133
May 14 00:40:19 alu kernel: [    5.599177] ata10.01: ATA-8: WDC WD5000AAKS-00C8A0, 12.01C02, max UDMA/133
May 14 00:40:19 alu kernel: [    5.599179] ata10.01: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
May 14 00:40:19 alu kernel: [    5.600188] ata10.01: configured for UDMA/133
May 14 00:40:19 alu kernel: [    5.601658] ata10.02: ATA-8: ST31000524NS, SN12, max UDMA/133
May 14 00:40:19 alu kernel: [    5.601661] ata10.02: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
May 14 00:40:19 alu kernel: [    5.603378] ata10.02: configured for UDMA/133
May 14 00:40:19 alu kernel: [    5.604847] ata10.03: ATA-8: ST31000524NS, SN12, max UDMA/133
May 14 00:40:19 alu kernel: [    5.604849] ata10.03: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
May 14 00:40:19 alu kernel: [    5.606546] ata10.03: configured for UDMA/133
May 14 00:40:19 alu kernel: [    5.606580] ata10: EH complete
May 14 00:40:19 alu kernel: [    5.606729] scsi 9:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 12.0 PQ: 0 ANSI: 5
May 14 00:40:19 alu kernel: [    5.606868] sd 9:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/465 GiB)
May 14 00:40:19 alu kernel: [    5.606876] sd 9:0:0:0: Attached scsi generic sg5 type 0
May 14 00:40:19 alu kernel: [    5.606899] sd 9:0:0:0: [sdd] Write Protect is off
May 14 00:40:19 alu kernel: [    5.606901] sd 9:0:0:0: [sdd] Mode Sense: 00 3a 00 00
May 14 00:40:19 alu kernel: [    5.606915] sd 9:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA


The only difference I can think of, is that, on one of the boots I entered <Ctrl-H> to enter the RAID unit BIOS.  I created some raidsets, then exited.

Yeap, you're right.  In the last log, 11.0 is working properly as an AHCI controller.  In the earlier log, the controller was just spitting out 0xffffffff's which often is an indication that the card is not well seated in the PCI slot.  But, it's also possible that the controller changes its programming interface depending on the controller mode in use.  Can you please play with different settings and find out what's going on?

Thanks.

I guess the card moving around is possible, the case has been slid back and forth, and cables plugged in that might have shifted it very slightly.

The card is screwed in to the bracket, and the BIOS utility has always worked properly.  Would the BIOS work if the card were not properly seated?  

OK, on boot, I go into the rr622's BIOS menu, after it does it's scanning devices... for a few minutes...    

I have menu (via Ctrl-H)

Create Delete Add/Remove Spare Settings View Initialize

5 disks show up. the two I originally created a mirrored raidset show up as 'configured' the other three show up as New.

Create:
  no suitable disks

Delete:
  don't dare.

Add/Remove Spare:
  offers me to do remove one of the 'configured' disks from their 1 disk JBOD sets. no thanks.

Settings
  Select boot device
  staggerred spinup: Disabled.

View
  shows the two disks each configured as individual JBODS called rr622_0 and rr622_1

Initialize

  shows me the three 'New' disks.
  presumably puts some sort of header on the drive?

didn't touch it.


so, before I submitted the bug, I created two jbod devices using this BIOS menu, but I recall rebooting and never seeing the devices at the OS level.

Since the rr622 started working, I have done a good half-dozen boots, and the disks always appear as individual sata units.

Can you suggest some other settings to tweak?

Hmm... not really.  The earlier log definitely seemed like the hardware was having some problem but I would really appreciate if you can try different RAID / JBOD settings and verify that they all work.  Not having enough info and given the earlier weird failure, I'm a bit reluctant to forward the patch upstream.

Thanks.

The raidsets defined in the bios don't "work." I have two jbod raid sets that show up in the BIOS, but 5 disks are present, and they all look the same at the OS level.  The RAID stuff I didn't want isn't working. That's perfect.  I never wanted the RAID functions, which I believe are implemented in the host-based driver, rather than in firmware/hardware.  The thing that bugs me is that I don't know why it didn't present disks in the first place.  I agree that there is nothing to forward at this point. I'm OK with closing if we don't think we can figure out why it suddenly started working.

Yeah, the RAID is most likely just BIOS / driver thing.  At hardware, it's always just multiple disks attached to a single controller, but I just want to make sure that it works under different BIOS configurations.  Can you please test with JBOD and different RAID configurations and see whether the disks come up regardless of configuration?

I booted a 2.6.39 kernel from the ubuntu PPA set for natty.   With
that kernel, no drives are presented.


On Thu, May 19, 2011 at 9:50 AM,  <bugzilla-daemon@bugzilla.kernel.org> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=34762
>
>
>
>
>
> --- Comment #14 from Tejun Heo <tj@kernel.org>  2011-05-19 13:50:12 ---
> Yeah, the RAID is most likely just BIOS / driver thing.  At hardware, it's
> always just multiple disks attached to a single controller, but I just want
> to
> make sure that it works under different BIOS configurations.  Can you please
> test with JBOD and different RAID configurations and see whether the disks
> come
> up regardless of configuration?
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>

The patch hasn't been committed to the kernel yet so...  Has it been working fine with the patched kernel?  Have you tried different configs from BIOS?

The patch did nothing.  At some point, magically, the controller
started presenting the drives to the OS.
when booted on a kernel without the patch, the drives remain visible.
 No change in observed behaviour.  the kernel is ubuntu natty standard
2.6.38.2.  When I boot a 2.6.39 from ubuntu kernel ppa, I can see none
of the drives attached to that controller.

Peter, without the patch, there's no way the drives connected to the highpoint controller are visible to the operating system.  The controller doesn't have a class code with standard programming interface.  If the ahci driver doesn't have the PCI ID, it just won't detect it.  This patch not being in upstream, trying different/newer distro kernels isn't likely to help either (unless a distro adds the patch itself), so I strongly suggest verifying the test setup and re-test the patch.

Thanks.

Not sure there is anything we can do. It seems it was only supported by some kind of Ubuntu added proprietary driver. One for Ubuntu

This bug report was opened because It works on 2.6.38 using normal open
source drivers.  Something was done to actively break working support,
using open drivers in the >= 2.6.39/3.0 tree.

I have a server accessing these disks, with it's kernel pinned to 2.6.38,
and no proprietary driver in use.

p.s. fwiw... my account is not recoverable on kernel.org.   tried changing
password, but even after pw change, it remains disabled.

On Thu, Aug 23, 2012 at 10:05 AM, <bugzilla-daemon@bugzilla.kernel.org>wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=34762
>
>
> Alan <alan@lxorguk.ukuu.org.uk> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>                  CC|                            |alan@lxorguk.ukuu.org.uk
>          Resolution|                            |WILL_NOT_FIX
>
>
>
>
> --- Comment #19 from Alan <alan@lxorguk.ukuu.org.uk>  2012-08-23 14:05:13
> ---
> Not sure there is anything we can do. It seems it was only supported by
> some
> kind of Ubuntu added proprietary driver. One for Ubuntu
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>