Contribute
Register

[Guide] Dell XPS 13 9360 on MacOS Sierra 10.12.x - LTS (Long-Term Support) Guide

Status
Not open for further replies.
RehabMan said:
Check kernel logs from BrcmPatchRAM.
Click to expand...

These are from the time of crash. What do 0xe00002ed and 0xe0005000 relate to?

Code: 
2017-05-27 10:19:10.412820-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: Version 2.2.7 starting on OS X Darwin 16.6.
2017-05-27 10:19:10.412872-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: USB [184F32F21474 v274] "BCM20702A0" by "Broadcom Corp"
2017-05-27 10:19:10.621815-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:10.624499-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
2017-05-27 10:19:10.624580-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe0005000 (UNDEFINED)" 0xe0005000).
2017-05-27 10:19:10.627498-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
...
2017-05-27 10:19:10.921623-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe0005000 (UNDEFINED)" 0xe0005000).
2017-05-27 10:19:10.924548-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
2017-05-27 10:19:10.924833-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: device request failed ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:10.927518-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
...
2017-05-27 10:19:15.621951-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: device request failed ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:15.622193-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: continuousRead - Failed to queue read (0xe00002d8)
 
fv316 said:
These are from the time of crash. What do 0xe00002ed and 0xe0005000 relate to?

Code: 
2017-05-27 10:19:10.412820-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: Version 2.2.7 starting on OS X Darwin 16.6.
2017-05-27 10:19:10.412872-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: USB [184F32F21474 v274] "BCM20702A0" by "Broadcom Corp"
2017-05-27 10:19:10.621815-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:10.624499-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
2017-05-27 10:19:10.624580-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe0005000 (UNDEFINED)" 0xe0005000).
2017-05-27 10:19:10.627498-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
...
2017-05-27 10:19:10.921623-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe0005000 (UNDEFINED)" 0xe0005000).
2017-05-27 10:19:10.924548-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
2017-05-27 10:19:10.924833-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: device request failed ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:10.927518-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
...
2017-05-27 10:19:15.621951-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: device request failed ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:15.622193-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: continuousRead - Failed to queue read (0xe00002d8)
Click to expand...

You would need to look those errors up in the OS X SDK header files...

Suffice it to say, BrcmPatchRAM is not able to communicate with the BT controller at that point, and is probably not very graceful at dealing with the error.

You might want to go back one or two versions, because I remember there being some changes with the way it starts a firmware upload... maybe the fix was good for some devices, and bad for others...
 
RehabMan said:
Check kernel logs from BrcmPatchRAM.
The way BrcmPatchRAM works may need some modifications. It would be better if it hooked IOUSB vtable (if possible), such that all work was done upon open being called. But it might be tricky...
With the way it is now, a race condition is all too easy to cause. Possibility exists of race condition between native bluetooth drivers and the firmware uploader code.

Try also with normal XCPM (eg. SMBIOS that is not HWP enabled).

Note: SSDT-SMBUS.aml probably not needed.



Bluetooth controller is probably in a bad state after the race condition occuring.



Try setting with Clover. See if it survives boot and sleep/wake cycle.



Fn+Insert should probably be trapped and handled natively (it is likely native ACPI code taking over...)
Click to expand...

Side note: Fn+insert=sleep always works consistently and correctly for me.
 
fv316 said:
These are from the time of crash. What do 0xe00002ed and 0xe0005000 relate to?

Code: 
2017-05-27 10:19:10.412820-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: Version 2.2.7 starting on OS X Darwin 16.6.
2017-05-27 10:19:10.412872-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: USB [184F32F21474 v274] "BCM20702A0" by "Broadcom Corp"
2017-05-27 10:19:10.621815-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:10.624499-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
2017-05-27 10:19:10.624580-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe0005000 (UNDEFINED)" 0xe0005000).
2017-05-27 10:19:10.627498-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
...
2017-05-27 10:19:10.921623-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Failed to write to bulk pipe ("0xe0005000 (UNDEFINED)" 0xe0005000).
2017-05-27 10:19:10.924548-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
2017-05-27 10:19:10.924833-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: device request failed ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:10.927518-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Not responding - Delaying next read.
...
2017-05-27 10:19:15.621951-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: device request failed ("0xe00002ed (UNDEFINED)" 0xe00002ed).
2017-05-27 10:19:15.622193-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: continuousRead - Failed to queue read (0xe00002d8)
Click to expand...

Just to check, @fv316, are you working with a clean 10.12 install? Because these PatchRam errors were exactly what I was seeing when the Logitech driver was interfering. It very well may be that the Logitech driver was only exacerbating the issue. If it's a race condition indeed - and that would explain the fact that not everyone has BT issues - the cause may be the uploader itself, and Logitech drivers may only be a contributory cause.
 
RehabMan said:
You might want to go back one or two versions, because I remember there being some changes with the way it starts a firmware upload... maybe the fix was good for some devices, and bad for others...
Click to expand...

I think at this point I'd rather just go back to disabling/enabling bluetooth at sleep/wake with sleepwatcher + blueutil as that circumvented the error from ever arising.

bozma88 said:
Side note: Fn+insert=sleep always works consistently and correctly for me.
Click to expand...

Do you inject fake EC device for AppleBusPowerControllerUSB to load and PluginType-1 for X86PlatformPlugin? I think my Fn+insert sleep also worked before these two.

bozma88 said:
Just to check, @fv316, are you working with a clean 10.12 install?
Click to expand...

Well no, not quite. Last clean wipe was beginning of May, since then I've installed Java, Python, a fair bit of apps but no 3rd-party device drivers. What would be great is if we could do some broad sweep that would indicate exactly what is interfering with the PatchRam..

FWIW bluetooth just survived a 30min unpowered sleep, with the following log:

Code: 
2017-05-27 16:26:26.258918-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: Version 2.2.7 starting on OS X Darwin 16.6.
2017-05-27 16:26:26.258949-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: uploadFirmware could not open the device!
2017-05-27 16:26:26.260792-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Found existing IOKit personality "com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport".
2017-05-27 16:26:26.260799-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: Processing time 0.1 seconds.

So I guess it's something that is unique to waking from a deeper sleep that causes it to crash
 
fv316 said:
Do you inject fake EC device for AppleBusPowerControllerUSB to load and PluginType-1 for X86PlatformPlugin? I think my Fn+insert sleep also worked before these two.
Click to expand...

Fake EC not required when you have a real EC.

Well no, not quite. Last clean wipe was beginning of May,
Click to expand...

Probably should test with a clean install (easy to create an extra partition and test).

FWIW bluetooth just survived a 30min unpowered sleep, with the following log:

Code: 
2017-05-27 16:26:26.258918-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: Version 2.2.7 starting on OS X Darwin 16.6.
2017-05-27 16:26:26.258949-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: uploadFirmware could not open the device!
2017-05-27 16:26:26.260792-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: [0a5c:216f]: Found existing IOKit personality "com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport".
2017-05-27 16:26:26.260799-0400  localhost kernel[0]: (BrcmPatchRAM2) BrcmPatchRAM2: Processing time 0.1 seconds.
Click to expand...

It actually, didn't work... clear contention for the device (the driver couldn't open it).
No firmware loaded.

It could be something changed in 10.12.x somewhere... and the timing is tighter, not leaving much time for BrcmPatchRAM to get going. I don't really have 10.12 running on a machine where bluetooth is there... at least not regularly. I should probably update my Lenovo u430 now that 10.12 isn't horrible like it was...

So I guess it's something that is unique to waking from a deeper sleep that causes it to crash
Click to expand...

With hibernate disabled there is no such thing as "deep" vs. "light" sleep.
And sleep duration would have no bearing (nothing is happening during sleep).
Only difference between (extremely) short sleep and longer is whether you go to the lock screen vs. desktop.
 
bozma88 said:
Side note: Fn+insert=sleep always works consistently and correctly for me.
Click to expand...
fn + insert works if you dont have PluginType-1 for X86PlatformPlugin or cpupm related

#125
 
azlvda said:
fn + insert works if you dont have PluginType-1 for X86PlatformPlugin or cpupm related

#125
Click to expand...

It is probably best to stick with macOS/OS X native methods for shutdown/sleep/restart.
 
RehabMan said:
Fake EC not required when you have a real EC.
Click to expand...

This EC won't do will it?

Code: 
    Scope (_SB.PCI0.LPCB)
    {
        Device (H_EC)
        {
            Name (_HID, EisaId ("PNP0C09"))  // _HID: Hardware ID
            Name (_UID, One)  // _UID: Unique ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (Zero)
            }

            Name (B1CC, Zero)
            Name (B1ST, Zero)
            Name (B2CC, Zero)
            Name (B2ST, Zero)
            Name (CFAN, Zero)
            Name (CMDR, Zero)
            Name (DOCK, Zero)
            Name (EJET, Zero)
            Name (MCAP, Zero)
            Name (PLMX, Zero)
            Name (PECH, Zero)
            Name (PECL, Zero)
            Name (PENV, Zero)
            Name (PINV, Zero)
            Name (PPSH, Zero)
            Name (PPSL, Zero)
            Name (PSTP, Zero)
            Name (RPWR, Zero)
            Name (LIDS, Zero)
            Name (LSTE, Zero)
            Name (SLPC, Zero)
            Name (VPWR, Zero)
            Name (WTMS, Zero)
            Name (AWT2, Zero)
            Name (AWT1, Zero)
            Name (AWT0, Zero)
            Name (DLED, Zero)
            Name (IBT1, Zero)
            Name (ECAV, Zero)
            Name (SPT2, Zero)
            Name (PB10, Zero)
            Name (IWCW, Zero)
            Name (IWCR, Zero)
            Method (ECMD, 1, Serialized)
            {
                If (ECON)
                {
                    While (CMDR)
                    {
                        Stall (0x14)
                    }

                    Store (Arg0, CMDR)
                }
            }

            Method (ECRD, 1, Serialized)
            {
                Return (DerefOf (Arg0))
            }

            Method (ECWT, 2, Serialized)
            {
                Store (Arg0, Arg1)
            }
        }
    }

RehabMan said:
With hibernate disabled there is no such thing as "deep" vs. "light" sleep.
And sleep duration would have no bearing (nothing is happening during sleep).
Only difference between (extremely) short sleep and longer is whether you go to the lock screen vs. desktop.
Click to expand...

I understand the facts as they are laid out on paper, but it remains that the bluetooth controller does not fail after a short sleep (5-30min?) but does reliably fail after an over-night sleep (8+ hours?) where the only variable between the two situations is the duration of sleep. If it's true that there is absolutely no difference between *-length sleeps, then possibly something happens to the bluetooth controller itself after x-amount of time? Maybe something unloads it after a certain period of time?
 
fv316 said:
This EC won't do will it?
Click to expand...

It is not an active EC.
It returns zero from _STA. That means "not present".
Read ACPI spec.

Your real EC is here:
Code: 
        Device (ECDV)
        {
            Name (_HID, EisaId ("PNP0C09"))  // _HID: Hardware ID
            Name (_UID, Zero)  // _UID: Unique ID
            Name (ECRS, ResourceTemplate ()
            {
                IO (Decode16,
                    0x0000,             // Range Minimum
                    0x0000,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    _Y37)
                IO (Decode16,
                    0x0000,             // Range Minimum
                    0x0000,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    _Y38)
            })
            Method (_STA, 0, Serialized)  // _STA: Status
            {
                Return (0x0F)
            }


I understand the facts as they are laid out on paper, but it remains that the bluetooth controller does not fail after a short sleep (5-30min?) but does reliably fail after an over-night sleep (8+ hours?) where the only variable between the two situations is the duration of sleep.
Click to expand...

Not true.
In the case of sleep over 8 hours there are numerous dark wakes during that time frame, followed by some checks, followed by re-enter to sleep.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top