The USB 3.0 NEC/Renesas chipset driver recently published by LaCie floods syslog with status messages during boot. It has a high logging level set by default. I've bin-patched it to reduce the logging level back to sanity.
Attached is the patched kext.
Diff of a binary dump of the change (loglevel bitmask changed from 7 to 1)
Edit (Dec 2nd, 2012) - Attachment removed, see post #7 by shiecldk for combined patch that fixes log flooding + enables super-speed for non-LaCie devices.
Do you know how to remove LaCie's USB 3.0 device check?
Modbin's patch works, but the device speed is showed as 480 Mb/sec in system info.
Also, the transfer speed is slow at the beginning, which is about 35mb/s, because the device is recognized as USB 2.0 device.
Honestly, I haven't a clue what you're talking about. I searched the web for Modbin's patch, and it's dated 11 November 2010 and talks about "removing security". My patch is for LaCie v1.0.11 which was released 22 October 2012 (see link in my post). I have no idea what "security" needs to be removed.
The driver matches statically on the exact NEC/Renesas chip in Info.plist
Now, 0x0c033000 is the universal PCI class code for XHCI USB 3.0 controllers. OTOH, 0x01941033 is the specific ID for Renesas. If you remove the IOPCIPrimaryMatch from Info.plist, it will match on any XHCI controller. Whether the driver code will actually work with other XHCI controllers I haven't a clue. I only searched the code for the logging issue, not completely reverse-engineer it !.
Honestly, I haven't a clue what you're talking about. I searched the web for Modbin's patch, and it's dated 11 November 2010 and talks about "removing security". My patch is for LaCie v1.0.11 which was released 22 October 2012 (see link in my post). I have no idea what "security" needs to be removed.
The driver matches statically on the exact NEC/Renesas chip in Info.plist
Now, 0x0c033000 is the universal PCI class code for XHCI USB 3.0 controllers. OTOH, 0x01941033 is the specific ID for Renesas. If you remove the IOPCIPrimaryMatch from Info.plist, it will match on any XHCI controller. Whether the driver code will actually work with other XHCI controllers I haven't a clue. I only searched the code for the logging issue, not completely reverse-engineer it !.
Sorry, I should have mentioned it in my post...
This is Modbin's patch:
9F 05 74 --> 9F 05 EB
If you don't apply this patch, only USB2.0 drives can be connected.
I know by removing IOPCIPrimaryMatch can make all XHCI controller identified. I have one uPD720202 identified in system info, but it can't work (no response when any drive is connected).
While my uPD720200 works fine.
Modbin's patch works, but the device speed is showed as 480 Mb/sec in system info. Also, the transfer speed is slow at the beginning, which is about 35mb/s, because the device is recognized as USB 2.0 device.
FYI, PXHCD.kext does not support super-speed at all. All super-speed capable devices run at high-speed. Modbin's patch simply allows it to work with non-Lacie devices.
The Real Deal, on 22 December 2012 - 01:36 PM, said:
The result on my setup (Maximus V Formula + 10.6.8)
Notice the line
Quote
Vitesse: Jusqua 480 Mb/s
The drive is being operated at high speed. For super-speed it would say 5 Gb/s. I'm not sure which Transcend Jetflash you have, but some of them are super-speed. PXHCD operates all super-speed capable drives at high-speed. There's no programming in it to support super-speed mode on a device.
Notice the line
The drive is being operated at high speed. For super-speed it would say 5 Gb/s. I'm not sure which Transcend Jetflash you have, but some of them are super-speed. PXHCD operates all super-speed capable drives at high-speed. There's no programming in it to support super-speed mode on a device.
This is what it should look like for super-speed
That explains why the speed sometimes stucks at 40mb/s.
Dose AppleUSBXHCI.kext work well with uPD720200? Have you tried the new driver in OS X 10.8.3?
Btw, these are the results with PXHCD.kext:
System info:
Spoiler
Sometime the USB 3.0 drive can't be mounted on the USB 3.0 port.
When it mounts, kernel log shows these (with the alignment error):
12/23/12 3:19:25.000 PM kernel[0]: USBF: 9976. 5 Endpoint 0x81 of the USB device "Backup+ Desk" at location 0x3c200000: converting Bulk MPS from 1024 to 512 (USB 2.0 Spec section 5.8.3)
12/23/12 3:19:25.000 PM kernel[0]: USBF: 9976. 5 Endpoint 0x2 of the USB device "Backup+ Desk" at location 0x3c200000: converting Bulk MPS from 1024 to 512 (USB 2.0 Spec section 5.8.3)
12/23/12 3:19:25.000 PM kernel[0]: disk6s3: alignment error.
When it doesn't mount:
12/23/12 3:21:45.000 PM kernel[0]: USBF: 10115.590 Endpoint 0x81 of the USB device "Backup+ Desk" at location 0x3c200000: converting Bulk MPS from 1024 to 512 (USB 2.0 Spec section 5.8.3)
12/23/12 3:21:45.000 PM kernel[0]: USBF: 10115.590 Endpoint 0x2 of the USB device "Backup+ Desk" at location 0x3c200000: converting Bulk MPS from 1024 to 512 (USB 2.0 Spec section 5.8.3)
Speed Tests:
Spoiler
It always performed like USB2.0 at the beginning when the USB3.0 drive was connected:
After a few tests, it became more like USB 3.0:
The write speed was 60mb/s at the beginning. Then it became to 150mb/s within 10 seconds:
It's possible PXHCD is reporting the device as high-speed to IOUSBFamily, but running it at super-speed at the port. IOUSBFamily doesn't restrict the speed of bulk transfers, so they can go above the 'official' limit.
Could you share your patch method for AppleUSBXHCI?
Ha? It's in the other thread. If your question is what the patch does, there are 4 changes
Inhibit a check if the xhci chip is either Intel Panther Point or Fresco Logic.
Inhibit a check if xhci version is >= 1.0 (Renesas says 0.96).
Disable option to use PCI messaged interrupts, as this doesn't work with Renesas (PXHCD uses legacy pin interrupt as well.) Strangely Renesas' Windows driver does use messaged interrupts. I guess the Apple code dosn't handle MSI right.
Disable one place where it reads an Intel-specific PCI register (0xD0) that isn't found in other chipsets. Strangely, other places in the code that access these Intel-specific registers do check if the chipset is Intel first. I guess it's an oversight.
Looks like I'm going to have to patch more stuff in the sleep code.
Ha? It's in the other thread. If your question is what the patch does, there are 4 changes
Inhibit a check if the xhci chip is either Intel Panther Point or Fresco Logic.
Inhibit a check if xhci version is >= 1.0 (Renesas says 0.96).
Disable option to use PCI messaged interrupts, as this doesn't work with Renesas (PXHCD uses legacy pin interrupt as well.) Strangely Renesas' Windows driver does use messaged interrupts. I guess the Apple code dosn't handle MSI right.
Disable one place where it reads an Intel-specific PCI register (0xD0) that isn't found in other chipsets. Strangely, other places in the code that access these Intel-specific registers do check if the chipset is Intel first. I guess it's an oversight.
Looks like I'm going to have to patch more stuff in the sleep code.
This is the patched 1.0.11 driver with the removed info.plist entry, just as in 1.0.10.
While it DOES now see a root USB 3.0 HUB, it DOES NOT, however, see any drives attached to the HUB itself. Therefore, one step forward,
1/2 step back.
It DOES generate more logging information ( which could prove useful to some ). At this point, perhaps once the Generic UHCI driver gets more stable,
it might be worth it to switch to it, but I don't see LaCie updating this one much further, boys and girls.
Sign In
Create Account
2
