Cout d'etat
Alkuperäinen juliste- 4. huhtikuuta 2007
- 4. marraskuuta 2021
Joka kerta kun Mac menee nukkumaan telakointiaseman ollessa kytkettynä, se käynnistyy uudelleen muutaman minuutin kuluttua seuraavan ytimen paniikin kanssa.
panic(cpu 2 caller 0xfffffe002d557c40): 'pci-bridge: pci-palautus virheellinen laitetunnus 0x15d48086 ' @IOPCIBridge.cpp:1524
Debuggerin viesti: paniikki
Muistin tunnus: 0x6
Käyttöjärjestelmän julkaisutyyppi: Käyttäjä
Käyttöjärjestelmän versio: 21A559
Ytimen versio: Darwin Kernel -versio 21.1.0: ke 13. lokakuuta 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
Tiedostojoukon Kernelcache UUID: 3B2CA3833A09A383D66FB36667ED9CBF
Ytimen UUID: 67BCB41B-BAA4-3634-8E51-B0210457E324
Kopioin tähän pari esimerkkiä: https://pastebin.com/4Vx83HQ6 .
Liitetyt kohteet:
Keskitin (TB3)
-> LG 38WN95C (TB3) päänäyttö
-> LG 32UN880-B (DP) toinen näyttö
-> Sensei Series 10 Mouse (USB A)
-> Ethernet
En voi antaa täydellistä valurautatakuuta tässä vaiheessa, mutta irrottamalla telakan ja kytkemällä kaikki suoraan tai näyttökeskittimien kautta, en näytä pystyvän toistamaan tätä enää, joten olen melko varma. se on laituri.
Otin yhteyttä CalDigitiin, joka kertoi minulle, että heidän telakointinsa ovat periaatteessa epäluotettavia kaikissa mac-ohjelmistoissa BigSurin jälkeen – eikä heillä ole minkäänlaista korjausta, vaan se on Applen vastuulla.
Onko muilla samanlaisia kokemuksia? TO
Cout d'etat
Alkuperäinen juliste- 4. huhtikuuta 2007
- 4. marraskuuta 2021
Kiitos yhteydenotostasi. Valitettavasti 11.0:ssa tai uudemmassa versiossa on tunnettuja ytimen paniikkiin liittyviä ongelmia, tässä on virallinen foorumiviesti ytimen panikoista/kaatumisista Big Surissa: https://developer.apple.com/forums/thread/678644
Ytimen paniikki- ja kaatumisongelmat ovat valitettavasti puhtaasti Mac-ongelmia, ja niitä on esiintynyt Big Surin alusta lähtien. Sitä ei ole vieläkään korjattu tähän päivään mennessä, ja siitä on tullut yhä enemmän raportteja käyttäjiltä, jotka käyttävät erimerkkisiä telakointiasemia ja jotkut jopa muodostavat yhteyden suoraan käyttämällä suoraa sovitinta tai ilman sovitinta. Eeternal on raportoinut siitä, virallisilla foorumeilla on raportteja siitä, Redditillä on raportteja siitä ja olemme yrittäneet pakottaa Applea itse korjaamaan, jotta voimme nähdä, voimmeko saada heidät toimimaan, mutta mitään ei ole tapahtunut viime aikoina. Kernalin paniikki/kaatumiset ovat pahentuneet jokaisen julkaiseman Big Sur OS -version myötä, ja ne alkoivat alun perin Catalinan lopussa versioilla 10.15.6 ja 10.15.7.
Aiomme olla rehellisiä sinulle, emme voi tarjota mitään laiteohjelmistopäivityksiä tai vianmääritystä, joita emme ole jo yrittäneet ja kaikki on epäonnistunut. Otimme yrityksenä tehtäväksemme yrittää auttaa asiakkaita näissä ongelmissa, mutta tuloksetta. Riippumatta siitä, mitä teimme, olipa kyse laiteohjelmistosta, ohjelmistosta tai ohjaimista, ongelma ilmeni silti, koska se johtuu Big Surin taustaprosesseista ja jostain heidän käyttöjärjestelmäkoodistaan joka aiheuttaa sen. Kun tämä ongelma ilmeni ensimmäisen kerran, meillä oli tästä tietokannan artikkeli: https://www.caldigit.com/my-intel-based-mac-crashes-when-un-docking-or-re-docking/ .
Big Sur on rehellisesti sanottuna ollut käyttöjärjestelmän sotku. Niin monia ongelmia ja bugeja ja paljon uusia raportteja eri ongelmista päivittäin Big Surin eri käyttöjärjestelmäversioilla (11.1:stä 11.4:ään). Kyse ei ole vain ytimen paniikkista, vaan myös näyttöongelmista, joista Eeternal on raportoinut täällä: https://www.macrumors.com/2021/02/03/macos-big-sur-external-display-issues/ . Tässä vaiheessa meillä ei ole aavistustakaan, päättääkö tai milloin Apple päättää korjata tämän, ja niin monien raporttien vuoksi on huolestuttavaa, etteivät he ole ryhtyneet toimiin.
Vastaus CalDigitiltä. Nämä linkit ovat hämmentäviä, koska ne näyttävät keskittyvän Intel-koneisiin, enkä todellakaan näytä saavan samoja pinojälkiä. Pyysin heitä katsomaan uudelleen. J
joevt
Osallistuja
- 21. kesäkuuta 2012
- 4. marraskuuta 2021
https://opensource.apple.com/source/IOPCIFamily/IOPCIFamily-428.80.2/IOPCIBridge.cpp.auto.html
Arvo 0x15d48086 on tallennettu muuttujaan nimeltä |_+_| ja edustaa Thunderbolt-telakointiasemassa olevan Alpine Ridge Thunderbolt -ohjaimen laitetunnusta/toimittajatunnusta:
https://pci-ids.ucw.cz/read/PC/8086/15d4
Datamuuttuja alustetaan seuraavasti:
pci restore invalid deviceid Arvo näyttää olevan normaali ja kelvollinen (jos se olisi 0xffffffff, se tarkoittaa, että laite saattaa olla nukkumassa tai pois käytöstä tai piilossa ja 0xffff0001 tarkoittaisi, että laite ei ole vielä valmis).
Mukaan https://en.wikipedia.org/wiki/PCI_configuration_space , toimittajatunnuksen (8086) odotetaan seuraavan laitetunnusta (15d4), joten se on ok.
Arvoa verrataan laitteen |_+_|-kenttään osavaltio. Ilmeisesti siinä on epäsuhta, joka aiheuttaa paniikkia. Paniikki esiintyy vain ei-Intel Mac -tietokoneissa (M1 Macissa ei ole |_+_|, jota luulisin käyttävän laitteen herättämiseen loppuun Intel Macissa).
Paniikkiviestin ongelmana on, että se ei kerro meille, mikä on tallennettu Config-arvo (odotettu laite/toimittajatunnus), joka auttaisi löytämään ongelman todellisen syyn. savedConfigin oletetaan olevan kopio PCI-määritystilarekistereistä. Oletan, että joidenkin Thunderbolt-ohjainten omituisuus voi olla, että toimittaja tai laitetunnus saattaa muuttua. Esimerkiksi isäntä Thunderbolt-ohjain voi piilottaa itsensä asettamalla toimittajansa ja laitetunnuksensa arvoon 0xffff, kunnes thunderbolt-ohjain laiteohjelmistossa tai macOS:ssä mahdollistaa virran kytkemisen Thunderbolt-ohjaimeen. Mutta CalDigit on oheislaite, ei isäntälaite.
Ehkä jotain outoa tapahtui, kuten väylän numerot muuttuivat niin, että toimittajaa/laitetta luetaan toisesta PCIe-laitteesta.
Ehkä väylänumero on oikea, mutta se lukee eri PCIe-verkkoalueelta. Luulen, että M1 Macit ovat ensimmäiset Macit, joissa on useita PCIe-verkkotunnuksia siten, että eri toimialueissa olevilla laitteilla voi olla sama väylä/laite/toimintonumero. Mielestäni on epätodennäköistä, että Apple sotkee tätä. Varmasti savedConfigin arvo kertoisi meille, onko tämä ongelma.
Joka tapauksessa käyttäisin Apple Feedback Assistantia lähettääkseni tiedot Applelle ja käskeäkseni heitä korjaamaan paskansa. Sitten poistaisin unen ja odotin puoli vuosikymmentä.
Cout d'etat
Alkuperäinen juliste- 4. huhtikuuta 2007
- 4. marraskuuta 2021
joevt sanoi: Tein haun |_+_| osoitteessa opensource.apple.com. Uusin versio (Big Sur 11.5:lle) on tämä:Hieno postaus ja kiitos salapoliisityöstä. Olen jo avannut tapauksen Applen kanssa ja lähettänyt palautetta.
https://opensource.apple.com/source/IOPCIFamily/IOPCIFamily-428.80.2/IOPCIBridge.cpp.auto.html
Arvo 0x15d48086 on tallennettu muuttujaan nimeltä |_+_| ja edustaa Thunderbolt-telakointiasemassa olevan Alpine Ridge Thunderbolt -ohjaimen laitetunnusta/toimittajatunnusta:
https://pci-ids.ucw.cz/read/PC/8086/15d4
Datamuuttuja alustetaan seuraavasti:data
Arvo näyttää olevan normaali ja kelvollinen (jos se olisi 0xffffffff, se tarkoittaa, että laite saattaa olla nukkumassa tai pois käytöstä tai piilossa ja 0xffff0001 tarkoittaisi, että laite ei ole vielä valmis).
Mukaan https://en.wikipedia.org/wiki/PCI_configuration_space , toimittajatunnuksen (8086) odotetaan seuraavan laitetunnusta (15d4), joten se on ok.
Arvoa verrataan laitteen |_+_|-kenttään osavaltio. Ilmeisesti siinä on epäsuhta, joka aiheuttaa paniikkia. Paniikki esiintyy vain ei-Intel Mac -tietokoneissa (M1 Macissa ei ole |_+_|, jota luulisin käyttävän laitteen herättämiseen loppuun Intel Macissa).
Paniikkiviestin ongelmana on, että se ei kerro meille, mikä on tallennettu Config-arvo (odotettu laite/toimittajatunnus), joka auttaisi löytämään ongelman todellisen syyn. savedConfigin oletetaan olevan kopio PCI-määritystilarekistereistä. Oletan, että joidenkin Thunderbolt-ohjainten omituisuus voi olla, että toimittaja tai laitetunnus saattaa muuttua. Esimerkiksi isäntä Thunderbolt-ohjain voi piilottaa itsensä asettamalla toimittajansa ja laitetunnuksensa arvoon 0xffff, kunnes laiteohjelmiston tai macOS:n thunderbolt-ohjain ottaa käyttöön Thunderbolt-ohjaimen virran. Mutta CalDigit on oheislaite, ei isäntälaite.
Ehkä jotain outoa tapahtui, kuten väylän numerot muuttuivat niin, että toimittajaa/laitetta luetaan toisesta PCIe-laitteesta.
Ehkä väylänumero on oikea, mutta se lukee eri PCIe-verkkoalueelta. Luulen, että M1 Macit ovat ensimmäiset Macit, joissa on useita PCIe-verkkotunnuksia siten, että eri toimialueissa olevilla laitteilla voi olla sama väylä/laite/toimintonumero. Mielestäni on epätodennäköistä, että Apple sotkee tätä. Varmasti savedConfigin arvo kertoisi meille, onko tämä ongelma.
Joka tapauksessa käyttäisin Apple Feedback Assistantia lähettääkseni tiedot Applelle ja käskeäkseni heitä korjaamaan paskansa. Sitten poistaisin unen ja odotin puoli vuosikymmentä.
Tässä vaiheessa on luultavasti helpompaa ostaa uusi telakka, kun tiedämme, että tietyt mallit toimivat luotettavasti. :huokaus:.
Yksi asia, jonka olen huomannut, on, että järjestelmä näyttää vakaammalta, jos pidän telakan kytkettynä mutta laitan näytöt suoraan usb/tb-portteihin. Onko mahdollista, että näyttö + telakka -yhdistelmä on perimmäinen syy? J
joevt
Osallistuja
- 21. kesäkuuta 2012
- 5. marraskuuta 2021
KuDeTa sanoi: Onko mahdollista, että näyttö + telakka -yhdistelmä ovat perimmäinen syy?En usko. Thunderbolt-telakointiaseman näyttömateriaali on erillään PCI-materiaalista. TAI
kahdeksan mahtavaa
- 19. marraskuuta 2014
- 8. marraskuuta 2021
Joskus MBP:n herättyä unesta näytöt eivät voi herätä. THE
kuten gadgeteja
- 22. heinäkuuta 2008
- MEILLE
- 8. marraskuuta 2021
kahdeksan mahtavaa
- 19. marraskuuta 2014
- 8. marraskuuta 2021
likegadgets sanoi: FWIW Minulla on samanlainen asennus. M1 Max, 64 Mt ja 4 Tt. Minulla on Caldigit TS3+, jossa lähes kaikki portit käytössä. Siihen on liitetty LG 5K. Apple XDR on kytketty Macin toiseen Thunderbolt-porttiin. Toistaiseksi hyvin - ei kaatumisia ja se on jatkuvasti päällä (ja menee nukkumaan) yli viikonM1M 64GB & 4TB myös lol.. ratkaisuni on kytkin, jolla voin kytkeä Caldigit-telakan päälle ja pois, jotta minun ei tarvitse irrottaa TB-kaapelia ja lyhentää USB C -portin käyttöikää
Suosittu Viestiä