Contribute
Register

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

Have you looked at this thread ? Headkaze offers a solution to get BT working again.

thanks for the answer
Just checked the thread and its very interesting!
But my problem is with WiFi and not BT

But
Have you tried moving the card to a different PCIe slot?
:shifty::shifty::shifty: This worked for me!
Thank you guys
I don't remember why I put Fenvi in PCIEX8
Now back to PCIEX1_2 its working again!

EDIT:
Just noticed that Fenvi at PCIEX8 created white noise into my studio monitors!!
 
Last edited:
[/USER]@CaseySJ[/USER]


could you lock for optimize egpu ? Maybe a imac 1,1, what do you think,
 
Hi @CaseySJ

"Also avoid BIOS F9j because USB 3.x devices will not connect to Thunderbolt ports."

Is this a bug which got introduced in this update, or do you think this is done intentionally? I'm just staying away from this version since it's not necessary (thank goodness I checked your start-post :lol: ).
 
Hi @CaseySJ

"Also avoid BIOS F9j because USB 3.x devices will not connect to Thunderbolt ports."

Is this a bug which got introduced in this update, or do you think this is done intentionally? I'm just staying away from this version since it's not necessary (thank goodness I checked your start-post :lol: ).
Apparently this is a widespread problem with the newest Gigabyte firmware across many of their motherboards, not just the Z390 Designare. It seems that BIOSes which implement Resizeable Base Address Register (BAR) suffer from this problem.
 
Hi people

I've just notice something odd.
I just made a bootable clone of my system drive on a new SSD.
My system is on a samsung 970 PRO 1TB pcie SSD, while the backup is on a brand new 970 EVO 1TB.

When I tested the backup for bootabilty, I noticed that the clone boots MUCH faster than the original drive.
It boots about twice as fast.

With the original drive, booting seems to hang before this line:
spaceman_trim_free_blocks_3327: scan took 12.963286 s, trims took 10.030928 s

It seems to hang for about 13s on that line, while the clone SSD scrolls right over it.
While it may seem normal for a brand new SSD to be a little faster during TRIM process,
I'm pretty sure my original SSD has never booted even nearly that fast.

Could I do anything to make the original drive also boot that fast?
Maybe a firmware upgrade on the drive?
Or has anyone seen this before, where an exact clone boots so much faster?

best wishes
 

Attachments

  • Screen Shot 2021-03-02 at 17.04.05.png
    Screen Shot 2021-03-02 at 17.04.05.png
    1.6 MB · Views: 42
Last edited:
Hi people

I've just notice something odd.
I just made a bootable clone of my system drive on a new SSD.
My system is on a samsung 970 PRO 1TB pcie SSD, while the backup is on a brand new 970 EVO 1TB.

When I tested the backup for bootabilty, I noticed that the clone boots MUCH faster than the original drive.
It boots about twice as fast.

With the original drive, booting seems to hang before this line:
spaceman_trim_free_blocks_3327: scan took 12.963286 s, trims took 10.030928 s

It seems to hang for about 13s on that line, while the clone SSD scrolls right over it.
While it may seem normal for a brand new SSD to be a little faster during TRIM process,
I'm pretty sure my original SSD has never booted even nearly that fast.

Could I do anything to make the original drive also boot that fast?
Maybe a firmware upgrade on the drive?
Or has anyone seen this before, where an exact clone boots so much faster?

best wishes
Hello @habibelhabab1,

Please check if the two EVO 970 drives have the same Used and Available capacity (Finder --> Get Info). If you are absolutely confident in the clone drive, you have the option to try the following (at your own discretion and risk):
  • Boot from the clone drive
  • Then use Disk Utility to format the old drive:
    • Name: Any name
    • Format: APFS
    • Scheme: GUID Partition Map
  • Then clone the backup to the original
  • Check if original drive boots normally now
  • Again, please exercise independent judgment in deciding whether or not to do this!
 
OpenCore 0.6.7 is unable to boot my Gigabyte B550 Vision D. Currently investigating, but also waiting for OpenCore Configurator to support 0.6.7 Release version. Planning to provide OC 0.6.7 EFI folders for Z390 Designare and Z490 Vision D/G in the next couple of days. (B550 Vision D will have to wait longer.)
I can't vouch for B550, but it took minimal changes for me to update Z390 Designare to 0.6.7 and boot successfully.

For some reason Hackintool detects it as 0.6.6 though. Looking at the release notes makes me think they changed the way versioning works or something.
 
Please check if the two EVO 970 drives have the same Used and Available capacity (Finder --> Get Info). If you are absolutely confident in the clone drive, you have the option to try the following (at your own discretion and risk):
  • Boot from the clone drive
  • Then use Disk Utility to format the old drive:
    • Name: Any name
    • Format: APFS
    • Scheme: GUID Partition Map
  • Then clone the backup to the original
  • Check if original drive boots normally now
  • Again, please exercise independent judgment in deciding whether or not to do this!
Hi Casey
Thank you very much for your reply.
I'm thinking about trying this but not before making a 2nd backup.
So do you think that during the 12 second trim thing nothing useful is actually happening?

I did find another user here who did this for faster boot time: https://www.tonymacx86.com/threads/solved-boot-hangs-at-fipspost_post.247544/

I'm just wondering what could be the cause of this
I've also found here that CCC (what I use for clone) will actually leave some files out of the clone:
Maybe that somehow "helps"?
 
Hi @CaseySJ

"Also avoid BIOS F9j because USB 3.x devices will not connect to Thunderbolt ports."

Is this a bug which got introduced in this update, or do you think this is done intentionally? I'm just staying away from this version since it's not necessary (thank goodness I checked your start-post :lol: ).
I would guess it’s a mistake from Gigabyte, and it happens in Windows, too... Waiting for a BIOS update. Bummer as there was a microcode update with this one (Security fixes), and I’m unable to flash a modified version with the updated microcode...

**Oh, sorry, Casey already answered...
 
Back
Top