83 replies to this topic

[dukzcry]

FredWst:

Thanks. That's strange to see, if you recompiled from last revision or downloaded the latest one. Got fixed for me: http://pastebin.com/96JgX2gM . Then please set "PreferMSI" property under "Settings" dict in Info.plist to "false" or use previous version. I'm forced to set it to false for futher versions after your report

[Black Knight]

I just wanted to mention, the PERC 6/i that I'm using is using the 11.0.1-0048 bios from LSI and not the dell bios. I don't know if this has anything to do with Fred's being a different result. I have not yet tried your latest driver with MSI handling working yet, but I will shortly.

[FredWst]

dukzcry, on 03 March 2013 - 07:01 PM, said:

FredWst:

Thanks. That's strange to see, if you recompiled from last revision or downloaded the latest one. Got fixed for me: http://pastebin.com/96JgX2gM . Then please set "PreferMSI" property under "Settings" dict in Info.plist to "false" or use previous version. I'm forced to set it to false for futher versions after your report

i've compil from last commit.
With or without drives inside and long waiting for keyboard, i can logon.
I get this in log -> IOHIDSystem: postEvent LLEventQueue overflow.

I try to remove dsdt.aml it's same result.

PreferMSI = No -> back to IRQ.

I hope you'll find what's wrong.

Regards
Fred

Edited by FredWst, 03 March 2013 - 08:16 PM.

[dukzcry]

Black Knight, on 03 March 2013 - 07:09 PM, said:

I have not yet tried your latest driver with MSI handling working yet, but I will shortly.

Thanks, i need your help.

FredWst, on 03 March 2013 - 07:27 PM, said:

With or without drives inside and long waiting for keyboard, i can logon.

Sympoms are awaited, since you're messing the system, which awaits for command completion which never occurs. My system had similar behaviour like your or Black Knight's when tried MSIs, but it got fixed for me with my recent edits.

Quote

PreferMSI = No -> back to IRQ.

Yes.

Quote

I hope you'll find what's wrong.

Unfortunatelly, it's not much i can else do. I've just added missed enabling of interrupt source and interrupt acknowledge (seems to be hw requirement, before it was present only in interrupt filter routine and hence was used only in case of legacy interrupts) for MSI case.

[Black Knight]

Here is my log for the latest driver you uploaded:

3/3/13 7:55:56.000 PM kernel[0]: [SASMegaRAID] IRQ: 17
3/3/13 7:55:56.000 PM kernel[0]: [SASMegaRAID] DMA: 64-bit, max commands: 1008, Max SGE Count: 33
3/3/13 7:55:56.000 PM kernel[0]: rooting via boot-uuid from /chosen: 28FD5F10-AAA9-3B7B-B148-0A42BB91E182
3/3/13 7:55:56.000 PM kernel[0]: Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOResources</string><key>IOResourceMatch</key><string ID="2">boot-uuid-media</string></dict>
3/3/13 7:55:56.000 PM kernel[0]: com.apple.AppleFSCompressionTypeZlib kmod start
3/3/13 7:55:46.111 PM com.apple.launchd[1]: *** Shutdown logging is enabled. ***
3/3/13 7:55:56.000 PM kernel[0]: com.apple.AppleFSCompressionTypeDataless kmod start
3/3/13 7:55:56.000 PM kernel[0]: com.apple.AppleFSCompressionTypeZlib load succeeded
3/3/13 7:55:56.000 PM kernel[0]: com.apple.AppleFSCompressionTypeDataless load succeeded
3/3/13 7:55:56.763 PM com.apple.launchd[1]: (com.apple.automountd) Unknown key for boolean: NSSupportsSuddenTermination
3/3/13 7:55:56.000 PM kernel[0]: AppleIntelCPUPowerManagementClient: ready
3/3/13 7:55:56.000 PM kernel[0]: vendor:device: 0x8086:0x1503.
3/3/13 7:55:56.000 PM kernel[0]: AppleIntelE1000e(Info): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
3/3/13 7:55:56.000 PM kernel[0]: AppleIntelE1000e(Info): changing MTU from 0 to 1500
3/3/13 7:55:56.000 PM kernel[0]: FireWire runtime power conservation disabled. (2)
3/3/13 7:55:56.000 PM kernel[0]: SATA WARNING: IDENTIFY DEVICE checksum not implemented.
3/3/13 7:55:56.000 PM kernel[0]: [SASMegaRAID] 8 physical drive(s) present
3/3/13 7:55:56.000 PM kernel[0]: [SASMegaRAID] Enabled options: Physical Drive Coercion Mode Auto Rebuild Battery Warning
3/3/13 7:55:56.000 PM kernel[0]: Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP08@1C,7/IOPCI2PCIBridge/PXSX@0/AppleAHCI/PRT0@0/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOBlockStorageDriver/Maxtor 6V300F0 Media/IOGUIDPartitionScheme/ML2@2
3/3/13 7:55:56.000 PM kernel[0]: BSD root: disk0s2, major 1, minor 2
3/3/13 7:55:56.000 PM kernel[0]: [SASMegaRAID] BBU type: BBU, status good, 100% charged

Looks like it's still using IRQ and PreferMSI is Yes in the driver. I have no delays and all seems to be working, other than 2x 2.5TB drives that I attached to the card. The two 300GB Velociraptors in RAID 0 are read/write using Tuxera NTFS, but the other 4x 2TB JBOD drives are read only using mac driver and won't mount at all using Tuxera. I'm guessing these are unrelated issues though. Not sure about the 2.5TB drives though. They show up, just won't mount.

*UPDATE*

Don't really know why, but I moved the 2x 2.5TB drives to the Intel SATA controller and now they show up and mount just fine. The only difference between them and the other drives on the PERC 6/i is that they are partitioned GUID rather than MBR. Don't know if this has anything to do with it, but I figured I'd mention it.

Edited by Black Knight, 04 March 2013 - 06:17 AM.

[dukzcry]

Black Knight, on 04 March 2013 - 06:17 AM, said:

Looks like it's still using IRQ and PreferMSI is Yes in the driver.

I recommend installing kexts by using this utility: http://cvad-mac.narod2.ru/Kext_Utility . Since OS X switched to use kexts cache plus some loaders started to use mkext archive, things got uncomfortable. Looks like you may have load up with old kext from cache.

Quote

...are read only using mac driver and won't mount at all using Tuxera

SASMegaRAID operates a way lower than VFS layer and hence is independend of file system of choice. I have no problems of using both HFS+, and different ZFS implementations (tried both maczfs and zevo, though switched to zevo, as maczfs is generally unstable).

Quote

The only difference between them and the other drives on the PERC 6/i is that they are partitioned GUID rather than MBR.

Sorry, can't help there, i don't use so much different kernel-side file systems. As disclaimer: you're on your own when dealing with 3-rd party FSs.
All of drives on my side are GUIDs.

P.S.: I don't know about PERC6, but LSI firmware brings some hassles to PERC5 card, e.g. 3 Tb+ drives aren't supported.

Edited by dukzcry, 04 March 2013 - 07:01 AM.

[Black Knight]

You're right. I can't believe I totally blanked. I got so used to having everything pretty much working right that I totally forgot to do a -f at reboot. Once I did, I am now using the MSI, but it gets the long delay at boot with no USB input. I can VNC in just fine, but none of the drives mounted and the controller no longer shows up in System Profiler. I'm going to try going back to IRQ to make sure the new driver still works in that mode.

The latest LSI firmware that goes on the PERC 5/i (lsi 8408e) says it supports drives larger than 2TB. I don't see why it wouldn't support 3TB+. http://www.lsi.com/d...8E_PB-Final.pdf

As for the PERC 6/i, it has no trouble supporting the 2.5TB drives in Windows 8. I also have LSI firmware on it. As for Dell's firmware, I doubt they update it very often.

*UPDATE*

Went back to MSI = No and it works like it did before. No delays and all drives mount save for the 2.5TB's that have been moved to the other controller.

[dukzcry]

Black Knight, on 04 March 2013 - 07:19 AM, said:

Once I did, I am now using the MSI, but it gets the long delay at boot with no USB input.

Thanks. That means MSIs don't work for PERC6 owners. I'll revert to MSI depreference for futher versions and add a note that somebody should try MSIs and switch to them, if everything works (like it works with PERC5) for that one.

Quote

The latest LSI firmware that goes on the PERC 5/i (lsi 8408e) says it supports drives larger than 2TB. I don't see why it wouldn't support 3TB+. http://www.lsi.com/d...8E_PB-Final.pdf

The problem is that LSI firmware on Dell's controller is considered unsupported, causing a bit of troubles, please see:
- from here:

Quote

Note: Since the card uses a Dell Bootloader, there is a possible corruption as defined in Post #1343 (link). It is recommended that you use the Dell firmware unless it does not work.

- here:

Quote

3TB Drives will technically work, but you will only get 2TB of Storage Space...

- and here for example (even mentions PERC6).

So my assumption was that PERC6 with LSI fw may has some dark corners as well.

upd: Backing to your problem with Tuxera NTFS. Again, not much i can do here for you. Paraphrasing myself the driver role in all data path is small. But to secure yourself, did you look in their FAQ? There is an answer section related to mounting problems.

Edited by dukzcry, 04 March 2013 - 09:33 AM.

[dukzcry]

Commented out scsi read(12) command with proper field-accessing. Added support for 64-bit lba (2 Tb+ support).
Anyone having issues with big disk arrays please test new version does it fix anything for you.

Edited by dukzcry, 05 March 2013 - 12:47 PM.

[CycleBurns]

Still following this thread with great interest...


But,.. what should i look for to determine whether a card will work or not?
Will this one work; DELL PERC H310
And,...is it possible to boot from it?

[dukzcry]

CycleBurns, on 05 March 2013 - 12:51 PM, said:

what should i look for to determine whether a card will work or not?

You may look at README.

Quote

Will this one work; DELL PERC H310
And,...is it possible to boot from it?

This one should work. Yes it is.

[CycleBurns]

Sorry for asking stupid questions.
i already read it. And i read it again.... the answer is right there!


Thanks :-)

[FredWst]

dukzcry, on 05 March 2013 - 12:45 PM, said:

Commented out scsi read(12) command with proper field-accessing. Added support for 64-bit lba (2 Tb+ support).
Anyone having issues with big disk arrays please test new version does it fix anything for you.

Hello,

Have update today.
You mean single drive > 2 Tb or mount like me 3 x 2 Tb Raid 5 -> 4Tb ?

Have finished installation PowerEdge T410 booting from raid 1 with clover in legacy mode.(boot7)

Regards.

Fred

Edited by FredWst, 05 March 2013 - 11:13 PM.

[dukzcry]

FredWst, on 05 March 2013 - 11:12 PM, said:

You mean single drive > 2 Tb or mount like me 3 x 2 Tb Raid 5 -> 4Tb ?

I think both schemes are OK. The limit should move from 2 Tb to 128 Pb from now.

Quote

Have finished installation PowerEdge T410 booting from raid 1 with clover in legacy mode.(boot7)

Good

[mr_w]

Any chance of getting mfiutil binary?

[dukzcry]

mr_w, on 21 March 2013 - 01:45 AM, said:

Any chance of getting mfiutil binary?

When i'll find time for that. It currently works, aside of broken linker sets, so it doesn't recognize user commands. I also need to write required part for driver in order to make this tool useful.

udp: Fixed the sets. Now the utility (see first post) is workable.

[CycleBurns]

Hi,



just wanted to let Dukzcry know i'm very grateful for this great project.

• Got me a IBM m5014
  
• Flashed it to the latest FW of a LSI 9260
  
• Installed the driver
  
• It works
  
• I boot from the card
  
• MSI enabled; speaking of which. I experienced some very strange behavior. Not from MSI but from DMA. After i installed/copied ML to the partition and started working on it and updating it, i ran into an issue. A very serious issue. I eventually started over. At a certain point i realized this behaviour was invoked by enabling write back and / or read ahead AFTER i installed the driver and was working with it. I did some comparative testing to verify and even a untouched partition was displaying problems because of this issue.
  
• To put it short; MSI works/and performs better/more stable. (at least in my config) i7 - Asus P6T board.

i will be testing SSD Cachecade on this setup and migrating both windows and mac to new disks soon.
If there's anything worthy reporting, i'll let you know.


Thanks again!

[dukzcry]

Hi, CycleBurns!

Quote

just wanted to let Dukzcry know i'm very grateful for this great project.

Thanks.

Can you put more on your issue with DMA? *Something* (what exactly?) happens right after you enable mentioned features? I have both "Adaptive Read Ahead" & "Write Back" options enabled and didn't run into issues.

[CycleBurns]

I'll try...


But bare with me, before this issue MSI was a board maker  to me, nothing more.
I did read up on it, and it appears as if the DMA can get into some HW conflict (like the USB issue described before). I guess that depends on how good or bad your DSDT is. In any case... What happened was that my drives on the ICH10R ports would not mount. But are visible to the system. As a result the Tuxera NTFS driver would also yield some errors. The worst was that somehow my system disk (on the card) was also effected. I couldn't rebuild kernel caches, and when booting from another (not raid card partition) disk operations (repair, etc) on the raid partition would fail.

As i said before; it's quite simple to explain it in a generic way. Generic because of the diversity in DSDT's. What i do understand is that MSI is a not DMA related alternative way of doing some signaling. when using DMA the chance of conflicting seems higher.

As i recall;

I made 2 virtual disks.
i thought i enabled write back on both of them. This wasn't the case.
At first i left read ahead on normal (i don't have the adaptive option), after i changed it to read ahead.


So

• Driver install on 2 NOT raid card based partitions (SL & ML)
  
  
• Verified that it works.
  
  
• Cloned ML (10.8.2) to a virtual disk on the card
  
  
• Verified that it works.
  
  
• Updated to 10.8.3 - it still works, but i have some other 10.8.3 issues.
  
  
• Changed some behaviour on the raid card. everything is read ahead and write back now
  
  
• Trouble! It wasn't clear to me this was Raid related.
  
  
• Lot's of other fixes. tries to solve some issues (some of which prevented kextcaches to be rebuild)
  
  
• Wiped the faulty partition.
  
  
• Cloned it again.
  
  
• Now it gets interesting; Still or rather new strange disk related behaviour.
  
  
• verified this behaviour on Untouched partitions, when booted via the Raid virtual disk partitions boot loader.
  
  
• Changed to MSI on 1 partition.
  
  
• Verified the (positive) effect.
  
  
• Changed to MSI on a second partition.
  
  
• Verified the expected behaviour.
  
  
• Never looked back. MSI it is. Read up on MSI, what it does/is/replaces....
  
  
• Drew my conclusions!

I hope this helps!

[dukzcry]

Thanks, now you cleared things for me. As for terms: DMA is direct memory access, this is the way how our raid controllers operate. Looks like you messed it with "legacy interrupts", the thingie now usually displaced with better-performed MSI on modern hw. I've updated readme long ago, it's suggests to try MSI in first:

Quote

Message signaled interrupts are deprefered by default (they don't work for PERC 6 owners according to their reports). I have them working with PERC 5 card. It is worth to try: just set "PreferMSI" key under "Settings" dictionary in kext's plist to "YES", if driver doesn't function correctly, revert back to "NO".

Okay, now what we have:
me, PERC5: both legacy interrupts & MSI behave; LSI firmware
FredWst & Black Knight, PERC6: legacy work, MSI broken; LSI firmware
CycleBurns, M5014: legacy broken, MSI work; LSI firmware

There are problems with interrupts on Xen/Linux too.