Could not find/resolve named package element

vasek	# 4 года, 6 месяцев назад (отредактировано 4 года, 6 месяцев назад)
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	stn Я перетыкал свой HDD в систему, где Ubuntu грузится без варнингов, дак вот ТАМ эти мой ошибки остались, или местные "умельцы" напишут, что биос на жестком диске хранится )))))) Вот и спрашивал про полную переустановку системы. Решение вопроса я не вижу. BIOS он и есть BIOS и он один и тот же для всех систем и это целый программный комплекс, включающий кучу таблиц ACPI с описанием оборудования и его управлением. Таблица DSDT (Differentiated System Description Table) является самой сложной. Она содержит описание методов выполнения типовых системных операций, информацию об устройствах, шинах, всех системных объектах и методах взаимодействия с ними. Операционная система узнает о твоем оборудовании на стадии загрузки, считывая эту информацию из BIOS, под ее же управлением, иницилизирует и готовит к работе. BIOS (читай программу) пишут человеки и пишут они ее под определенную систему, что им закажут, а это в основном Windows. А потому частенько в винде все работает, а в Linux частенько что то отваливается, то подсветка, то еще что-нибудь. Кроме того, информация в BIOS не меняется, не меняется также и твое железо, а ядро постоянно обновляется, привносится что то новенькое. Попробуй загрузи старый комп с новым ядром Linux, получишь кучу проблем. Также можно получить кучу ошибок и варнингов (и даже проблемы загрузки) после обновления BIOS на старом железе. Так что обновление BIOS то же не всегда полезно. А потому будут разные варнинги при загрузке разных систем на одном компе. И обычно это не ошибки, а просто сообщения системы о том, что ей что то не понравилось, а сообщает она то, что ей запрограммируют те же человеки. А если хочешь понять эти сообщения, то нужно получить эти таблицы и покапаться в них, а если хватит знаний, то можешь и исправить. А не хочешь, тогда смирись. stn но не по возрасту Это как сказать ... если тебе 8-ой десяток с гаком, то вполне возможно. Ошибки не исчезают с опытом - они просто умнеют

# 4 года, 6 месяцев назад (отредактировано 4 года, 6 месяцев назад)

Сообщения: 11340

Участник с: 17 февраля 2013

stn
Я перетыкал свой HDD в систему, где Ubuntu грузится без варнингов, дак вот ТАМ эти мой ошибки остались, или местные "умельцы" напишут, что биос на жестком диске хранится )))))) Вот и спрашивал про полную переустановку системы.
Решение вопроса я не вижу.

BIOS он и есть BIOS и он один и тот же для всех систем и это целый программный комплекс, включающий кучу таблиц ACPI с описанием оборудования и его управлением.
Таблица DSDT (Differentiated System Description Table) является самой сложной. Она содержит описание методов выполнения типовых системных операций, информацию об устройствах, шинах, всех системных объектах и методах взаимодействия с ними. Операционная система узнает о твоем оборудовании на стадии загрузки, считывая эту информацию из BIOS, под ее же управлением, иницилизирует и готовит к работе.
BIOS (читай программу) пишут человеки и пишут они ее под определенную систему, что им закажут, а это в основном Windows. А потому частенько в винде все работает, а в Linux частенько что то отваливается, то подсветка, то еще что-нибудь. Кроме того, информация в BIOS не меняется, не меняется также и твое железо, а ядро постоянно обновляется, привносится что то новенькое. Попробуй загрузи старый комп с новым ядром Linux, получишь кучу проблем. Также можно получить кучу ошибок и варнингов (и даже проблемы загрузки) после обновления BIOS на старом железе. Так что обновление BIOS то же не всегда полезно.
А потому будут разные варнинги при загрузке разных систем на одном компе.

И обычно это не ошибки, а просто сообщения системы о том, что ей что то не понравилось, а сообщает она то, что ей запрограммируют те же человеки. А если хочешь понять эти сообщения, то нужно получить эти таблицы и покапаться в них, а если хватит знаний, то можешь и исправить. А не хочешь, тогда смирись.

stn
но не по возрасту

Это как сказать ... если тебе 8-ой десяток с гаком, то вполне возможно.

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 4 года, 6 месяцев назад (отредактировано 4 года, 6 месяцев назад)
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	Нужно было меньше писать, а больше анализировать. Ты хотя бы выяснил, что это за объекты LNK* (A,B,C,D…..)? Я не поленился и посмотрел свою таблицу DSDT и понял, что эти объекты *LNK связаны с таблицей прерываний PCI*, например, для объекта LNKA Device (LNKA) { Name (_HID, EisaId ("PNP0C0F") / PCI Interrupt Link Device /) // _HID: Hardware ID Name (_UID, 0x01) // _UID: Unique ID Method (_DIS, 0, Serialized) // _DIS: Disable Device { PARC \|= 0x80 } Name (_PRS, ResourceTemplate () // _PRS: Possible Resource Settings { IRQ (Level, ActiveLow, Shared, ) {1,3,4,5,6,7,10,12,14,15} }) Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings { Name (RTLA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, _Y15) {} }) CreateWordField (RTLA, \_SB.LNKA._CRS._Y15._INT, IRQ0) // _INT: Interrupts IRQ0 = Zero IRQ0 = (0x01 << (PARC & 0x0F)) Return (RTLA) / \_SB_.LNKA._CRS.RTLA / } Method (_SRS, 1, Serialized) // _SRS: Set Resource Settings { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Local0-- PARC = Local0 } Method (_STA, 0, Serialized) // _STA: Status { If ((PARC & 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Проверяем вывод dmesg и убеждаемся, что это так и есть dmesg \| grep -i LNK* [ 0.554468] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 12 14 15) [ 0.554559] ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 11 12 14 15) [ 0.554648] ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 12 14 15) [ 0.554736] ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 11 12 14 15) 10 [ 0.554824] ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12 14 15) 0, disabled. [ 0.554915] ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) 0, disabled. [ 0.555006] ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12 14 15) 11 [ 0.555095] ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 11 12 14 15) 0, disabled. То есть проблема связана с прерываниями, точнее с описанием имени LNK* - возможно используется не правильный путь к объекту, типа _SB.PCI0.LNKA, а должно быть, например, как в моем выводе _SB.LNKA._ (смотри выше). И если ты посмотришь вывод dmesg, то увидишь, что объекты LNK* не смотря ни на что создаются, а значит, как и писал выше, на это можно забить. А вот на время загрузки это ну никак не должно влиять, так что здесь я с тобой не согласен. Кстати, все интервалы времени загрузки хороши выводятся и можно посмотреть и узнать где у тебя затык. Можешь анализировать дальше самостоятельно. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 4 года, 6 месяцев назад (отредактировано 4 года, 6 месяцев назад)

Темы: 48

Сообщения: 11340

Участник с: 17 февраля 2013

Нужно было меньше писать, а больше анализировать. Ты хотя бы выяснил, что это за объекты LNK* (A,B,C,D…..)?
Я не поленился и посмотрел свою таблицу DSDT и понял, что эти объекты LNK* связаны с таблицей прерываний PCI, например, для объекта LNKA

Device (LNKA)
                    {
                        Name (_HID, EisaId ("PNP0C0F") /* PCI Interrupt Link Device */)  // _HID: Hardware ID
                        Name (_UID, 0x01)  // _UID: Unique ID
                        Method (_DIS, 0, Serialized)  // _DIS: Disable Device
                        {
                            PARC |= 0x80
                        }

                        Name (_PRS, ResourceTemplate ()  // _PRS: Possible Resource Settings
                        {
                            IRQ (Level, ActiveLow, Shared, )
                                {1,3,4,5,6,7,10,12,14,15}
                        })
                        Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
                        {
                            Name (RTLA, ResourceTemplate ()
                            {
                                IRQ (Level, ActiveLow, Shared, _Y15)
                                    {}
                            })
                            CreateWordField (RTLA, \_SB.LNKA._CRS._Y15._INT, IRQ0)  // _INT: Interrupts
                            IRQ0 = Zero
                            IRQ0 = (0x01 << (PARC & 0x0F))
                            Return (RTLA) /* \_SB_.LNKA._CRS.RTLA */
                        }

                        Method (_SRS, 1, Serialized)  // _SRS: Set Resource Settings
                        {
                            CreateWordField (Arg0, 0x01, IRQ0)
                            FindSetRightBit (IRQ0, Local0)
                            Local0--
                            PARC = Local0
                        }

                        Method (_STA, 0, Serialized)  // _STA: Status
                        {
                            If ((PARC & 0x80))
                            {
                                Return (0x09)
                            }
                            Else
                            {
                                Return (0x0B)
                            }
                        }
                    }

Проверяем вывод dmesg и убеждаемся, что это так и есть
dmesg | grep -i LNK

[    0.554468] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 12 14 15)
[    0.554559] ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 11 12 14 15)
[    0.554648] ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 12 14 15)
[    0.554736] ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 11 12 14 15) *10
[    0.554824] ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12 14 15) *0, disabled.
[    0.554915] ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled.
[    0.555006] ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
[    0.555095] ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled.

То есть проблема связана с прерываниями, точнее с описанием имени LNK* - возможно используется не правильный путь к объекту, типа _SB.PCI0.LNKA, а должно быть, например, как в моем выводе _SB.LNKA._ (смотри выше).
И если ты посмотришь вывод dmesg, то увидишь, что объекты LNK* не смотря ни на что создаются, а значит, как и писал выше, на это можно забить.
А вот на время загрузки это ну никак не должно влиять, так что здесь я с тобой не согласен. Кстати, все интервалы времени загрузки хороши выводятся и можно посмотреть и узнать где у тебя затык.
Можешь анализировать дальше самостоятельно.

Ошибки не исчезают с опытом - они просто умнеют

ban_zay	# 4 года, 3 месяца назад (отредактировано 4 года, 3 месяца назад)
Темы: 1 Сообщения: 11 Участник с: 07 ноября 2015	железо не AMDшное? вывод вот этой команды покажи... `dd if=/dev/mem bs=64k skip=15 count=1 \| strings \| more` возможно тебе туда https://bugzilla.kernel.org/show_bug.cgi?id=198167